Hello,
I was pleasantly surprised with the response to recent post about
MicroPython implementation details
(https://mail.python.org/pipermail/python-dev/2014-June/134718.html). I
hope that discussion means that posts about alternative implementations
are not unwelcome here, so I would like to br
Hello,
On Tue, 10 Jun 2014 13:03:03 +1000
Steven D'Aprano wrote:
> On Tue, Jun 10, 2014 at 05:23:12AM +0300, Paul Sokolovsky wrote:
>
> > execfile() builtin function was removed in 3.0. This brings few
> > problems:
> >
> > 1. It hampers interactive mode
Hello,
On Tue, 10 Jun 2014 17:36:02 +1000
Nick Coghlan wrote:
> On 10 June 2014 12:23, Paul Sokolovsky wrote:
> > 1. It hampers interactive mode - instead of short and easy to type
> > execfile("file.py") one needs to use exec(open("file.py").read()).
> &
Hello,
As explained in
https://docs.python.org/3/reference/compound_stmts.html#the-try-statement ,
except E as N:
foo
is actually compiled as:
except E as N:
try:
foo
finally:
del N
But looking at the generated bytecode, it's worse than that:
16 STORE_
Hello,
On Sun, 6 Jan 2019 22:19:39 +1100
Chris Angelico wrote:
> > It's clear that what happens there is that first None is stored to
> > N, just to del it as the next step. Indeed, that's what done in the
> > compile.c:
> >
> > https://github.com/python/cpython/blob/master/Python/compile.c#L290
Hello,
On Sun, 6 Jan 2019 23:10:24 +1100
Steven D'Aprano wrote:
[]
> > # Where's my *global* variable?
> > # Worse, my variable can be gone or not, depending on whether
> > exception # triggered or not.
> > print(e)
>
> That's not "worse", that's BETTER.
>
> With e deleted, you get an immed
Hello,
On Sun, 6 Jan 2019 17:26:09 +0200
Serhiy Storchaka wrote:
[]
> Because there is a reason for such code.
>
> See issue1631942 [1] and the thread with the subject "self-contained
> exceptions" on the Python-3000 mailing list [2] for the rationale.
>
> In short, the code
>
> try:
>
Hello,
On Mon, 7 Jan 2019 01:14:55 +1100
Steven D'Aprano wrote:
[]
> > Thanks, that summarizes it well. And well, my interest is also how
> > non-compliant would be for another Python implementation to act
> > differently, specifically to skip wrapping an except handler body in
> > try-finally
Hello,
On Tue, 29 Jan 2019 18:55:37 +
MRAB wrote:
[]
> > https://stackoverflow.com/questions/25445439/what-does-syntaxerror-missing-parentheses-in-call-to-print-mean-in-python
> >
> I have a vague recollection that a certain computer system (Amiga?)
> had a 'why' command. If it reported a
Hello,
I'm sorry for posting here and not to python-announce, somehow I think
(perhaps naively) that it may be of interest to people who are
interested in Python development. At the very least, creation of the
original package is (very likely, I didn't trace up to that) was
discussed on python-dev
Hello,
On Tue, 20 Oct 2020 00:00:49 +0200
Thomas Wouters wrote:
> One of the problems I have with the Pattern Matching proposal (PEP 622
> originally, now PEPs 634, 635, 636) is the special-casing of '_' to
> not actually assign to the name, which is a subtle but meaningful
> divergence from the
Hello,
On Sat, 31 Oct 2020 02:37:14 +0100
Tin Tvrtković wrote:
[]
> async def ws_proxy(client: WebSocket):
> await client.accept()
> async with ClientSession() as session:
> async with session.ws_connect("wss://echo.websocket.org") as
> s: c = starlette_websocket_iterator(clien
Hello,
On Sat, 31 Oct 2020 18:01:16 +1000
Nick Coghlan wrote:
> On Sat, 31 Oct 2020 at 17:49, Paul Sokolovsky
> wrote:
> > Alternatively, can add "inline guard sigils" for the most common
> > guard conditions, which would be equality, period:
> >
&g
Hello,
On Sat, 31 Oct 2020 12:16:09 +
Paul Moore wrote:
> On Sat, 31 Oct 2020 at 11:25, Steven D'Aprano
> wrote:
> >
> > Thank you for the well-written PEP, although I don't agree with it.
> > My response below is quite long. Here is my opinionated TL;DR:
>
> For what it's worth, I find
Hello,
On Sat, 31 Oct 2020 18:53:57 +1000
Nick Coghlan wrote:
> On Sat, 31 Oct 2020 at 18:20, Paul Sokolovsky
> wrote:
> > I blame it on my Saturday's hazy mind, but also for the interest of
> > other readers, could you elaborate on "`==` interacts poorly with
>
Hello,
On Tue, 3 Nov 2020 10:30:22 +0100
Federico Salerno wrote:
> Re: symbol for lookup
>
> Whatever happened to the proposal of using . as prefix?
I guess, the same that happened with the proposals to use "+" as a
prefix, or proposals to change sides and use
"->"
(https://mail.python.org/ar
Hello,
On Thu, 12 Nov 2020 09:55:10 -0800
Guido van Rossum wrote:
> The position of PEP 622/634/535/636 authors is clear: we see this as a
> necessary feature to support using enums (e.g. Color.RED) or constants
> defined in other modules (e.g. re.I) when simple switch functionality
> is being m
Hello,
[Re-routed back to python-dev.]
On Thu, 12 Nov 2020 20:04:57 +0100
Piotr Duda wrote:
[]
> > match foo:
> > case ("foo", >val1):
> > ...
> > case ("bar", >val2):
> > ...
> >
>
> I agree with that, though I would prefer using other symbol than > (?
> or $), one
Hello,
On Thu, 12 Nov 2020 20:19:13 +
MRAB wrote:
[]
> > Question of "what to mark with sigils - terms-used-as-values or
> > terms-used-for-capturing" is orthogonal to the question of "what to
> > use as match-all symbol", though I understand the desire to
> > repurpose the same symbol for
Hello,
On Thu, 12 Nov 2020 12:51:19 -0800
Guido van Rossum wrote:
> I have a meta-observation. Clearly there are too many cooks here. The
> same suggestions keep getting brought up. We will never converge on a
> design this way.
Right, it's not a Python decision unless it's forced thru like PEP
Hello,
On Fri, 13 Nov 2020 21:51:49 +1100
Steven D'Aprano wrote:
> > match foo:
> > case ("foo", >val1):
> > ...
> > case ("bar", >val2):
> > ...
>
> > 1. Much more intuitive for beginners. (If Python adopts it, I see
> > other "user-friendly" languages adopting the sa
Hello,
On Thu, 12 Nov 2020 19:38:38 -0400
David Mertz wrote:
[]
> One idea that I cannot recall seeing, but that seems to make sense to
> me and fit with Python's feel is using a WORD to distinguish between a
> variable value and a binding target. That is, instead of a special
> case value
Hello,
On Fri, 13 Nov 2020 18:45:55 -
"Brandt Bucher" wrote:
> Paul Sokolovsky wrote:
> > Use punctuation ("sigils") to mark as-binding terms. This choice
> > still seems to be under-considered. (As in: it doesn't seem like
> > many people, i
Hello,
On Sun, 15 Nov 2020 00:22:01 -0500
Kyle Stanley wrote:
[]
> FWIW, I'd like to add my +1 to usage of "as" for spelling class
> capture patterns.
If you want to use "as" in spelling of class capture patterns, you
don't need to worry about anything, because PEP634 already allows that:
ca
Hello,
As was mentioned many times on the list, PEP634-PEP636 are thoroughly
prepared and good materials, many thanks to their authors. PEP635
"Motivation and Rationale" (https://www.python.org/dev/peps/pep-0635/)
stands out among the 3 however: while reading it, chances that you'll
get a feeling
Hello,
On Sun, 15 Nov 2020 22:05:46 +1100
Steven D'Aprano wrote:
> On Sun, Nov 15, 2020 at 12:48:50PM +0300, Paul Sokolovsky wrote:
>
> > Just to give one example, literally at the very beginning, at the
> > "Pattern Matching and OO" section (3rd heading)
alternative approaches
(as Brandt mentioned, there were such), and try to look into those
alternatives again.
Thanks!
>
> Of course, we encourage anyone interested in it to read the academic
> paper. Since its focus is somewhat complementary to the PEPs, it
> might highlight some
Hello,
On Sun, 15 Nov 2020 16:58:09 +
MRAB wrote:
[]
> >> Pattern matching is complimentary to the object-oriented
> >> paradigm.
> >
> That looks like a mistake to me; it should be "complementary".
This way or that, my point is that even the word "orthogonal" wouldn't
give it fairnes
Hello,
On Mon, 16 Nov 2020 08:39:30 +1100
Steven D'Aprano wrote:
[]
> > The baseline of my version is much simpler:
> >
> > # This makes "const" a kind of hard keyword for this module
> > from __future__ import const
> >
> > FOO: const = 1 # obviously, this is constant
> Oh, well,
To star
Hello,
On Mon, 16 Nov 2020 12:21:35 +1300
Greg Ewing wrote:
[]
> > please explain why you chose to proceed anyway (and apply
> > workarounds), instead of first introducing the concept of constants
> > to the language. (Given that amount of work to implement pattern
> > matching is certainly an
Hello,
On Sun, 29 Nov 2020 11:36:45 +1100
Steven D'Aprano wrote:
> On Sun, Nov 29, 2020 at 12:10:39AM +0300, Paul Sokolovsky wrote:
>
> > And we don't speak about some obscure "innovative" idea. Const'ness
> > aka immutability is well-known and widel
Hello,
On Mon, 30 Nov 2020 01:54:53 +0900
"Stephen J. Turnbull" wrote:
> Paul Sokolovsky writes:
>
> > Well, I'd call that "cowboy attitude in programming language
> > design" ;-).
>
> That was uncalled for, especially since you're sel
Hello,
On Mon, 30 Nov 2020 14:45:26 +0900
"Stephen J. Turnbull" wrote:
> Paul Sokolovsky writes:
>
> > Also to clarify, [cowboy attitude] referred to difference in
> > approaches in response to particular issue(s) raised. One thing is
> > to say "it
Hello,
On Fri, 4 Dec 2020 15:52:01 -0800
Guido van Rossum wrote:
> I hope more of the regulars here jump on this bandwagon. It will be a
> great day when Paul posts one of his offensive posts and there is
> just deafening silence.
And I maintain my hopes where they always were - that there will
Hello,
I would easily bet 10 bucks that vars() is the least known, and least
used, of the Python builtin functions.
My mental model of it was: it was introduced (perhaps in Python3) to
"harmonize" all the existing .__dict__ stuff, and provide more
abstract interface for it, with .__dict__ patient
Hello,
On Tue, 22 Dec 2020 01:10:17 +1300
Greg Ewing wrote:
> On 22/12/20 12:36 am, Paul Sokolovsky wrote:
> > Expected clarification on ".__dict__ breaking object
> > encapsulation":
>
> Encapsulation is not something that Python has ever been big
> on
Hello,
On Sun, 27 Dec 2020 14:10:59 +0100
Dave Halter wrote:
> I'm late, but I still wanted to add that I share some of the criticism
> that Mark has brought up.
>
> I'm in love with Rust's pattern matching, so I feel like I'm not
> against pattern matching generally. However I feel like while
Hello,
On Sun, 3 Jan 2021 16:50:33 +
Paul Moore wrote:
> On Sun, 3 Jan 2021 at 16:26, Barry Scott
> wrote:
> > I read the above and believe I know what it meant without needing
> > to read the PEP in detail. I like that a lot.
>
> Personally, I read it and was horribly confused. I worked
Hello,
On Mon, 4 Jan 2021 21:07:23 +0400
Abdur-Rahmaan Janhangeer wrote:
> @Christopher Barker
>
> You nailed it! I've used the conda activate command many times.
> It should in theory be possible in Python
>
> @Chris Angelico
>
> Yes mere shell commands passing via Py does not work,
> mayb
Hello,
On Tue, 5 Jan 2021 20:37:27 +1000
Nick Coghlan wrote:
> > > object(host=as host, port=as port}:", but that couldn't ever be
I'd like to point out the weirdness of the "as" syntax when applied to
positional arguments, e.g.:
case [as x, as y]:
case Cls(as x, as y):
That feels unnatural,
Hello,
On Sat, 9 Jan 2021 12:27:45 +1000
Nick Coghlan wrote:
> On Sat, 9 Jan 2021, 7:07 am Joseph Martinot-Lagarde,
> wrote:
>
> > Paul Sokolovsky wrote:
> > > Hello,
> > > On Tue, 5 Jan 2021 20:37:27 +1000
> > > Nick Coghlan ncogh...@gmail.com wro
Hello,
On Sat, 9 Jan 2021 14:49:19 +0100
Antoine Pitrou wrote:
> On Sat, 9 Jan 2021 12:17:32 +
> Paul Moore wrote:
>
> > On Sat, 9 Jan 2021 at 10:52, Paul Sokolovsky
> > wrote:
> > > > case {"host" as host, "port" as port}
Hello,
On Sun, 10 Jan 2021 01:42:25 +1000
Nick Coghlan wrote:
> On Sat, 9 Jan 2021, 8:50 pm Paul Sokolovsky,
> wrote:
>
> > >
> > > The key difference relative to PEP 634 is that even when the code
> > > author uses the shorthand form, *readers* will still
Hello,
On Sun, 10 Jan 2021 12:08:05 +1000
Nick Coghlan wrote:
[]
> PEP 634 doesn't have that feature for class patterns in general, only
> for classes like data classes, where the constructor signature is
> carefully aligned with the match arguments.
You see, if PEP622/PEP634 contained clause
Hello,
On Tue, 12 Jan 2021 00:11:33 +1000
Nick Coghlan wrote:
> On Sun, 10 Jan 2021, 7:37 pm Paul Sokolovsky,
> wrote:
>
> > And I patiently continue this thread, hoping that people whose
> > argument would be along the lines of "I teach Python, and I don't
Hello,
On Mon, 11 Jan 2021 13:44:45 -0800
Larry Hastings wrote:
> The control-flow exclusion is for /module//attribute/ or /class
> attribute/ annotations:
>
> class C:
> if random.random() > 0.5:
> my_attr:int=3
> else:
> my_attr2:float=3.5
Ok, let's take
Hello,
On Wed, 13 Jan 2021 05:04:36 -
"Jim J. Jewett" wrote:
> Paul Sokolovsky wrote:
> > Ok, let's take "module attribute" as an example. Why do you think
> > there's anything wrong with this code:
> > ==
> > import con
Hello,
On Wed, 13 Jan 2021 18:27:07 +1100
Chris Angelico wrote:
[]
> > Optimizations are an implementation detail, and implementation
> > details should not change the language.
>
> The language can also be defined in an optimization-friendly way,
> though. Consider how we got positional-only
ccepted annotations to be a
part of Python's nature, so wanting to use them more shouldn't come as
surprise).
>
> -Em
>
> On Wed, Jan 13, 2021 at 12:18 AM Paul Sokolovsky
> wrote:
>
> > Hello,
> >
> > On Wed, 13 Jan 2021 18:27:07 +1100
> > C
Hello,
On Thu, 14 Jan 2021 03:29:35 +1100
Steven D'Aprano wrote:
> On Wed, Jan 13, 2021 at 02:08:01AM -0800, Emily Bowman wrote:
> > Even if you define __bool__() as returning a bool, and
> > error/undefined behavior otherwise, that doesn't eliminate side
> > effects. Is it even possible to nai
Hello,
On Thu, 14 Jan 2021 12:45:11 +1300
Greg Ewing wrote:
> On 14/01/21 6:17 am, Paul Sokolovsky wrote:
> > For
> > example, print() would be considered "pure", as its purpose is to
> > provide program output, not arbitrarily change program state
>
&g
Hello,
On Thu, 14 Jan 2021 23:00:06 +1300
Greg Ewing wrote:
> On 14/01/21 3:32 pm, Terry Reedy wrote:
> > I say 'yes', because the purpose of logging is to document what
> > happens, and if nothing happens, there is nothing to document.
> > Wrapping a .__bool__ in a logging decorator might be pa
Hello,
On Thu, 14 Jan 2021 22:05:37 +1100
Steven D'Aprano wrote:
> On Wed, Jan 13, 2021 at 08:17:26PM +0300, Paul Sokolovsky wrote:
>
> > > Besides, we probably don't want to prohibit side-effects in
> > > `__bool__`. That would prohibit useful tricks such as
Hello,
On Tue, 19 Jan 2021 14:31:49 +1300
Greg Ewing wrote:
> On 19/01/21 1:13 pm, Inada Naoki wrote:
> > I don't want to import modules used only in type hints. I don't want
> > to import even "typing".
>
> How about having a pseudo-module called __typing__ that is
> ignored by the compiler:
Hello,
Everyone knows how hard to find a compelling usecase for the assignment
expression operator (":=", colloquially "walrus operator").
https://www.python.org/dev/peps/pep-0572/ examples never felt
compelling and we all remember the split it caused.
I finally found a usecase where *not* using
Hello,
Thanks for the reply.
On Fri, 5 Feb 2021 13:32:25 -0500
Terry Reedy wrote:
> On 2/5/2021 2:51 AM, Paul Sokolovsky wrote:
>
> > https://www.python.org/dev/peps/pep-0572/
> ...
>
> >>>> ((a, b) := (1, 2))
> >File "", line 1
&
Hello,
On Sat, 06 Feb 2021 12:35:09 +1300
Greg Ewing wrote:
> On 5/02/21 8:51 pm, Paul Sokolovsky wrote:
> > a = 0
> > while a < 5:
> > a += 1
> >
> >
> > becomes:
> >
> >
> > a0 = 0
> > while (a1 := phi(a
Hello,
On Sat, 6 Feb 2021 10:46:54 +0200
Serhiy Storchaka wrote:
> 05.02.21 09:51, Paul Sokolovsky пише:
> > a0 = 0
> > b0 = 10
> > while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5:
> > a2 = a1 + 1
> > b2 = b1 + 1
>
> Such code quickly beco
Hello,
On Sun, 7 Feb 2021 00:00:41 +0300
Ivan Pozdeev via Python-Dev wrote:
> Who said "__future__"?
Other people said __future__. And yet other said "it's ok the way it
is, it's better to have it like that then keep not having it". And yet
other said something else (multiple else's).
> I sai
Hello,
On Sun, 7 Feb 2021 01:17:31 +
Paul Bryan wrote:
> On Sat, 2021-02-06 at 22:00 -0300, Luciano Ramalho wrote:
>
> > A __future__ import would make clear to all that the feature is
> > experimental, and maybe there could be __future__ imports for
> > different parts of the proposal.
>
Hello,
On Sun, 7 Feb 2021 13:21:08 +1100
Steven D'Aprano wrote:
> On Sat, Feb 06, 2021 at 10:00:16PM -0300, Luciano Ramalho wrote:
> > On Sat, Feb 6, 2021 at 6:23 PM Chris Angelico
> > wrote:
> > > How will a __future__ import help here? Are there syntactic or
> > > behavioural changes that w
Hello,
On Sun, 07 Feb 2021 13:32:17 +1300
Greg Ewing wrote:
> On 7/02/21 9:58 am, Steve Holden wrote:
> > My suggestion that it be introduced via __future__ due to its
> > contentious nature met immediate resistance.
>
> __future__ is for things that are changing in incompatible ways.
> This
yet, and there could be small incompatible changes going forward").
>
> On Sat, Feb 6, 2021 at 22:44 Paul Sokolovsky
> wrote:
>
> > Hello,
> >
> > On Sun, 7 Feb 2021 01:17:31 +
> > Paul Bryan wrote:
> >
> > > On Sat, 2021-02-06 at 22:00
Hello,
On Sun, 7 Feb 2021 04:53:43 +0300
Ivan Pozdeev wrote:
> On 07.02.2021 0:24, Paul Sokolovsky wrote:
> > Hello,
> >
> > On Sun, 7 Feb 2021 00:00:41 +0300
> > Ivan Pozdeev via Python-Dev wrote:
> >
> >> Who said "__future__"?
> &
Hello,
On Sun, 7 Feb 2021 19:09:14 +1100
Chris Angelico wrote:
> On Sun, Feb 7, 2021 at 6:25 PM Paul Sokolovsky
> wrote:
> >
> > Hello,
> >
> > On Sat, 6 Feb 2021 23:05:19 -0800
> > Guido van Rossum wrote:
> >
> > > That’s i
Hello,
On Sun, 7 Feb 2021 20:02:48 +1100
Chris Angelico wrote:
> On Sun, Feb 7, 2021 at 7:54 PM Paul Sokolovsky
> wrote:
> >
> > So, you're saying that, by the benevolence of divine providence,
> > most (can you truly vouch for "all" and provide
ing within index expression useful, up to reporting it, and
then other people ack it and fix it, then why not fix parallel
assignment case? Implementation-wise they *seem* to be of the
similar effort/complexity - just a one-term grammar change. (I still
need to run the testsuite, yeah).
>
" on the language level is
still first on my list, and I'm pretty far from a PEP for it either ;-).
>
> On Sun, Feb 7, 2021 at 23:58 Paul Sokolovsky
> wrote:
>
> > Hello,
> >
> > On Sun, 7 Feb 2021 13:10:55 -0800
> > Guido van Rossum wrote:
> >
Hello,
On Tue, 9 Feb 2021 08:56:02 +1000
Nick Coghlan wrote:
> > After much deliberation, the Python Steering Council is happy to
> > announce that we have chosen to accept PEP 634, and its companion
> > PEPs 635 and 636, collectively known as the Pattern Matching PEPs.
> > We acknowledge that P
Hello,
On Sat, 13 Feb 2021 18:08:30 +1100
Steven D'Aprano wrote:
> On Fri, Feb 12, 2021 at 10:27:01AM +, Mark Shannon wrote:
>
> > It impairs readability, because it muddles the return type.
> > The function in the example returns a bool.
> > The annotation is also misleading as the annotat
Hello,
On Sat, 13 Feb 2021 23:10:59 +0900
"Stephen J. Turnbull" wrote:
> Chris Angelico writes:
>
> > Can you explain what would be improved by having a formalized
> > standard?
>
> The Language Reference together with the Library Reference *already*
> constitute a formalized standard. Th
Hello,
On Sat, 13 Feb 2021 19:48:10 -
"Eric Traut" wrote:
[]
> Paul said:
> >...to work around deficiencies in the current generation of Python
> >typecheckers
>
> It sounds like you're implying that this functionality will be no
> longer needed at some point in the future when type chec
Hello,
On Tue, 16 Feb 2021 18:22:00 -0600
Skip Montanaro wrote:
> > If someone knows how to get the original Usenet messages from what
> > Google published, let me know.
>
> Seems the original shar is there buried in a Javascript string toward
> the end of the file. I think I've got a handle
Hello,
On Wed, 17 Feb 2021 18:53:46 -0600
Skip Montanaro wrote:
> > If we can get a clean copy of the original sources I think we
> > should put them up under the Python org on GitHub for posterity.
>
> Did that earlier today:
>
> https://github.com/python/pythondotorg/issues/1734
I think t
Hello,
On Fri, 19 Feb 2021 06:29:35 -0300
Luciano Ramalho wrote:
> On Fri, Feb 19, 2021 at 4:08 AM Guido van Rossum
> wrote:
> > Can you try this?
> >
> > async def __sleep(self):
> > await None
>
> That didn't work*, but this does:
>
> async def __sleep():
> return None
>
> Was th
Hello,
Here's example:
Traceback (most recent call last):
File "pseudoc_tool.py", line 91, in
first_class_function_value(func, **pass_params)
TypeError: print() got an unexpected keyword argument 'noann'
Ok, which "print" do you mean, dear CPython? I have a dozen of print
functions (most
Hello,
On Mon, 22 Feb 2021 09:20:46 +0100
Michał Górny wrote:
> On Sun, 2021-02-21 at 13:04 -0800, Gregory P. Smith wrote:
> > The main thing from a project maintenance perspective is for
> > platforms to
> > not become a burden to other code maintainers. PRs need to be
> > reviewed.
> > Every
Hello,
On Mon, 22 Feb 2021 10:44:19 +0100
Peter Otten <__pete...@web.de> wrote:
> On 21/02/2021 23:06, Terry Reedy wrote:
> > On 2/21/2021 12:04 PM, Paul Sokolovsky wrote:
> >
> >> Traceback (most recent call last):
> >>
Hello,
On Mon, 22 Feb 2021 19:47:04 +
Barry Scott wrote:
> > On 22 Feb 2021, at 10:15, Paul Sokolovsky wrote:
> >
> > It looks like:
> >
> > Traceback (most recent call last):
> > File "pseudoc_tool.py", line 91, in
> > File "..
Hello,
On Fri, 26 Mar 2021 16:19:26 -0700
Guido van Rossum wrote:
> Everyone,
>
> Given the resounding silence I'm inclined to submit this to the
> Steering Council. While I'm technically a co-author, Irit has done
> almost all the work, and she's done a great job. If there are no
> further iss
nctionality in
PEP654, because again, it tries to codify rather complex and "magic"
behavior. Where complex and magic behavior in exception handling is
itself of concern, so making it more explicit may be a good idea. (A
good "how other languages deal with it") review would m
y PoV, a solution which doesn't add particular complex behavior
into the language core, but allows to plug it in, and keep whole thing
more explicit, is something that "works better".
Again, I wanted to mention that point, as between the initial PEP
version and the latest one, I don&#x
Hello,
On Sat, 27 Mar 2021 20:01:27 +
Irit Katriel wrote:
[]
> > you gentlemen come up with the "ultimate" way to deal with multiple
> > errors,
>
> I've been mistaken for a man before, but no-one has ever confused me
> for gentle. I'll take that as a compliment.
Sorry, was just a figure
Hello,
On Mon, 19 Apr 2021 20:23:08 -0700
Guido van Rossum wrote:
[]
> > How does this "similar thing" compare to the recently announced
> > imphook module?
> >
>
> For one, pyxl is a better name. :-)
I would humbly disagree ;-).
> Seriously, as long as the purpose is to allow using a diff
Hello,
On Tue, 20 Apr 2021 11:08:56 +0200
Victor Stinner wrote:
> I proposed PEP 511 "API for code transformers" for Python 3.6 (in
> 2016) and it was rejected:
> https://www.python.org/dev/peps/pep-0511/#rejection-notice
Well, it wasn't rejected, it was self-rejected on the thought-crime
groun
Hello,
On Tue, 7 Jun 2016 17:31:19 -0400
Barry Warsaw wrote:
> On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote:
>
> >* Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and
> > ``memoryview.iterbytes`` alternative iterators
>
> +1 but I want to go just a little farther.
>
> We can't change
Hello,
On Tue, 07 Jun 2016 13:28:13 -0700
Ethan Furman wrote:
> Minor changes: updated version numbers, add punctuation.
>
> The current text seems to take into account Guido's last comments.
>
> Thoughts before asking for acceptance?
>
>
[]
> Deprecation of current "zero-initialised sequen
Hello,
On Tue, 07 Jun 2016 15:46:00 -0700
Ethan Furman wrote:
> On 06/07/2016 02:33 PM, Paul Sokolovsky wrote:
>
> >> This PEP proposes to deprecate that behaviour in Python 3.6, and
> >> remove it entirely in Python 3.7.
> >
> > Why the desire to break app
Hello,
On Wed, 8 Jun 2016 11:53:06 +0300
Serhiy Storchaka wrote:
> On 08.06.16 11:04, Victor Stinner wrote:
> >> Currently, the ``bytes`` and ``bytearray`` constructors accept an
> >> integer argument and interpret it as meaning to create a
> >> zero-initialised sequence of the given size::
> >>
Hello,
On Wed, 8 Jun 2016 14:05:19 +0300
Serhiy Storchaka wrote:
> On 08.06.16 13:37, Paul Sokolovsky wrote:
> >> The obvious way to create the bytes object of length n is b'\0' *
> >> n.
> >
> > That's very inefficient: it requires allocati
Hello,
On Wed, 8 Jun 2016 14:45:22 +0300
Serhiy Storchaka wrote:
[]
> > $ ./run-bench-tests bench/bytealloc*
> > bench/bytealloc:
> > 3.333s (+00.00%) bench/bytealloc-1-bytes_n.py
> > 11.244s (+237.35%) bench/bytealloc-2-repeat.py
>
> If the performance of creating an immutable array
Hello,
On Tue, 14 Jun 2016 16:51:44 +0100
Paul Moore wrote:
> On 14 June 2016 at 16:19, Steven D'Aprano wrote:
> > Why does base64 encoding in Python return bytes?
>
> I seem to recall there was a debate about this around the time of the
> Python 3 move. (IIRC, it was related to the fact that
Hello,
On Tue, 14 Jun 2016 14:02:02 -0400
Random832 wrote:
> On Tue, Jun 14, 2016, at 13:19, Paul Sokolovsky wrote:
> > Well, it's easy to remember the conclusion - it was decided to
> > return bytes. The reason also wouldn't be hard to imagine -
> > regardle
Hello,
On Tue, 14 Jun 2016 18:13:11 +
Daniel Holth wrote:
> IMO this is more a philosophical problem than a programming problem.
> base64 has a dual-nature. It is both text and bytes. At least it
> should fit in a 1-byte-per-character efficient Python 3 unicode
> string also.
You probably m
Hello,
On Sun, 25 Jun 2017 10:33:20 +0200
Antoine Pitrou wrote:
[]
> Hmm. If it were so easy, you wouldn't have felt the need to add that
> functionality to blurb, right? :-)
>
> This is touching a more general problem, though. Before GitHub, we
> (core developers) would take the patch submi
Hello,
On Tue, 24 Mar 2020 19:14:16 +0100
Victor Stinner wrote:
[]
> The behavior of tuple containing an empty string is a little bit
> surprising.
>
> cutsuffix("Hello World", ("", " World")) returns "Hello World",
> whereas cutsuffix("Hello World", (" World", "")) returns "Hello".
>
> cutpr
Hello,
On Tue, 24 Mar 2020 22:51:55 +0100
Victor Stinner wrote:
> > === config.something ===
> > # If you'd like to remove some prefix from your lines, set it here
> > REMOVE_PREFIX = ""
> > ==
> >
> > === src.py ===
> > ...
> > line = line.cutprefix(config.REMOVE_PREFIX)
> > ...
> > ==
Hello,
On Sun, 26 Apr 2020 19:51:18 -0700
Skip Montanaro wrote:
[]
> I think it's worse that this though, as it seems that in gen_send_ex()
> it actually pushes a value onto the stack. That can't be solved by
> simply adding a state attribute to the generator object struct.
At the higher level
Hello,
Shouldn't such feedback be also cross-posted to the python-dev mailing
list? Also note the original pull request,
https://github.com/python/peps/pull/1470, and differences of what was
written in the pull request description and what went in the commit
message.
On Sun, 28 Jun 2020 22:10:14
Hello,
On Mon, 29 Jun 2020 14:35:08 +0300
"Jim F.Hilliard" wrote:
> I believe I'm not the only one with this question but, how is Strunk &
> White connected with white supremacy?
I wouldn't be surprised if the only connection between them is the word
"white".
>
> Scanning through this thread,
101 - 200 of 208 matches
Mail list logo
