Hello,
On Wed, 2 Dec 2020 19:26:22 +1100
Chris Angelico wrote:
[]
> > > > A sufficiently smart JIT is sufficiently hard to develop. As an
> > > > example, a most well-known and most-used Python implementation,
> > > > CPython, doesn't have any JIT at all, not only "sufficiently
> > > > advanced
On Wed, 2 Dec 2020 at 09:27, Chris Angelico wrote:
> But you can make your own private research project without asking
> anyone else for information. Why try to synchronize with anyone else?
> Why not just make your own thing and find out what constness can do
> for Python?
I agree. I think it wi
On Wed, Dec 2, 2020 at 7:18 PM Paul Sokolovsky wrote:
>
> Hello,
>
> On Wed, 2 Dec 2020 18:39:42 +1100
> Chris Angelico wrote:
>
> > On Wed, Dec 2, 2020 at 6:37 PM Paul Sokolovsky
> > wrote:
> > > A sufficiently smart JIT is sufficiently hard to develop. As an
> > > example, a most well-known an
Hello,
On Wed, 2 Dec 2020 18:39:42 +1100
Chris Angelico wrote:
> On Wed, Dec 2, 2020 at 6:37 PM Paul Sokolovsky
> wrote:
> > A sufficiently smart JIT is sufficiently hard to develop. As an
> > example, a most well-known and most-used Python implementation,
> > CPython, doesn't have any JIT at a
On Wed, Dec 2, 2020 at 6:37 PM Paul Sokolovsky wrote:
> A sufficiently smart JIT is sufficiently hard to develop. As an example,
> a most well-known and most-used Python implementation, CPython, doesn't
> have any JIT at all, not only "sufficiently advanced", but even
> "simple". But simple would
Hello,
On Wed, 02 Dec 2020 12:36:23 +1300
Greg Ewing wrote:
> On 2/12/20 6:43 am, Paul Sokolovsky wrote:
> > That's why I don't make such claims, and instead making a very
> > different one: that idea with absolute certainty will remove *one*
> > of 50 problems which keep Python slow.
>
> But
On 2/12/20 6:43 am, Paul Sokolovsky wrote:
That's why I don't make such claims, and instead making a very
different one: that idea with absolute certainty will remove *one* of
50 problems which keep Python slow.
But without an implementation demonstrating an actual speed
improvement, you're onl
On Tue, Dec 1, 2020 at 5:43 PM Paul Sokolovsky wrote:
> That's in the eye of the beholder, I'm afraid. So, if you don't want to
> be convinced of those clarity improvements, you'll never be.
>
It's hard to be convinced by something that neither you nor anyone else on
the thread has actually pres
Hello,
On Tue, 1 Dec 2020 16:41:36 +
David Mertz wrote:
> On Tue, Dec 1, 2020 at 10:38 AM Paul Sokolovsky
> wrote:
>
> > And the const is the cheapest way to make Python a tad faster (for
> > sure open up possibilities for further optimizations), which should
> > be accessible even to such
On Tue, Dec 1, 2020 at 10:38 AM Paul Sokolovsky wrote:
> And the const is the cheapest way to make Python a tad faster (for
> sure open up possibilities for further optimizations), which should be
> accessible even to such an old clumsy behemoth as CPython.
>
This is at least the 50th idea I've
On Tue, 1 Dec 2020 at 13:16, Paul Sokolovsky wrote:
> If you want immutable dict you [know whom to thank for the lack of it -
> stroked thru] can use types.MappingProxyType, as was explained (it's
> all about PEP603).
>
> The last case with immutable dict also shows that proliferation of both
> mu
Hello,
On Tue, 1 Dec 2020 15:16:11 +0300
Paul Sokolovsky wrote:
[]
> If you want immutable dict you [know whom to thank for the lack of it
> - stroked thru] can use types.MappingProxyType, as was explained (it's
> all about PEP603).
No, apparently I meant PEP416
https://www.python.org/dev/peps
Hello,
On Tue, 1 Dec 2020 11:43:07 +
Rob Cliffe wrote:
[]
> >> Somehow "dire" doesn't strike me as the right word Maybe you
> >> were looking for "conceivably useful in niche cases."?
> > Perhaps we can bargain on "really useful in many cases".
> >
> >
> Can I echo Chris Angelico's
Hello,
On Mon, 30 Nov 2020 17:26:00 -0500
David Mertz wrote:
> On Mon, Nov 30, 2020, 5:20 AM Paul Sokolovsky
>
> > So, if anything, we're re-tracing JavaScript steps. We're in dire
> > need of const'ness in the language.
>
>
> Somehow I've used Python for 22 years without experiencing that
"Immutable", like C. Not rebound has another keyword, in Java for
example (final). If we want to only avoid rebounding, I think const
will be a bit confusing for C/C++ people.
(I wrote "immutable" because in C constness can be removed)
On Tue, 1 Dec 2020 at 01:12, Chris Angelico wrote:
>
> On Tu
On Tue, Dec 1, 2020 at 10:25 AM Marco Sulla
wrote:
>
> On Mon, 30 Nov 2020 at 23:26, David Mertz wrote:
> > Somehow "dire" doesn't strike me as the right word Maybe you were
> > looking for "conceivably useful in niche cases."?
>
> Well, I think const can be useful for:
> * multiprocessing.
On Mon, 30 Nov 2020 at 23:26, David Mertz wrote:
> Somehow "dire" doesn't strike me as the right word Maybe you were looking
> for "conceivably useful in niche cases."?
Well, I think const can be useful for:
* multiprocessing. Now, for example, dict is passed between processes
using MappingP
On Mon, Nov 30, 2020, 5:20 AM Paul Sokolovsky
> So, if anything, we're re-tracing JavaScript steps. We're in dire need
> of const'ness in the language.
Somehow I've used Python for 22 years without experiencing that direness.
I've taught thousands of students already experienced in other langua
Hello,
On Mon, 30 Nov 2020 12:26:53 +
Rob Cliffe wrote:
> On 30/11/2020 08:01, Paul Sokolovsky wrote:
> > Hello,
> >
> > On Sun, 29 Nov 2020 18:53:57 -0800
> > Christopher Barker wrote:
> >
> >> This is a massively less ambitious idea, and doesn't solve the
> >> original problem, but:
> >
Hello,
On Mon, 30 Nov 2020 08:48:21 +
Paul Moore wrote:
[]
> > > > On the other hand, block-scoped variables are implemented in:
> > > > * C
> > > > * C++
> > > > * Java
> > > > * Rust
> > > > * Lua
> > > > * JavaScript (not by default, as opt-in)
> > > > * Scheme
> > > > * Common Lisp (as o
On Mon, 30 Nov 2020 at 08:29, Paul Sokolovsky wrote:
>
> Hello,
>
> On Mon, 30 Nov 2020 08:11:07 +
> Paul Moore wrote:
>
> > On Mon, 30 Nov 2020 at 08:03, Paul Sokolovsky
> > wrote:
> > > On the other hand, block-scoped variables are implemented in:
> > >
> > > * C
> > > * C++
> > > * Java
>
Hello,
On Mon, 30 Nov 2020 08:11:07 +
Paul Moore wrote:
> On Mon, 30 Nov 2020 at 08:03, Paul Sokolovsky
> wrote:
> > On the other hand, block-scoped variables are implemented in:
> >
> > * C
> > * C++
> > * Java
> > * Rust
> > * Lua
> > * JavaScript (not by default, as opt-in)
> > * Scheme
On Mon, 30 Nov 2020 at 08:03, Paul Sokolovsky wrote:
> On the other hand, block-scoped variables are implemented in:
>
> * C
> * C++
> * Java
> * Rust
> * Lua
> * JavaScript (not by default, as opt-in)
> * Scheme
> * Common Lisp (as opt-in)
> * ML
> * Ocaml
> * Haskell
> * very long list of other
Hello,
On Mon, 30 Nov 2020 12:56:59 +1300
Greg Ewing wrote:
> On 29/11/20 11:02 pm, Paul Sokolovsky wrote:
> > It will be much more obvious if there's a general (standalone)
> > "const",
>
> I don't think it will. There's nothing about the problem
> that points towards constness as a solution
Hello,
On Sun, 29 Nov 2020 18:53:57 -0800
Christopher Barker wrote:
> This is a massively less ambitious idea, and doesn't solve the
> original problem, but:
>
> I'd like to see a scope for names that are "obviously ;-)" meant to be
> short lived. At the moment that's the for loop "counters" an
Wouldn't `local` make sense as the opposite of `global` - personally I would
rather see that than LET.
-Original Message-
From: Cameron Simpson
Sent: 30 November 2020 07:13
To: sairamkumar2...@gmail.com
Cc: python-ideas@python.org
Subject: [Python-ideas] Re: Making the for stat
On 30Nov2020 04:00, sairamkumar2...@gmail.com wrote:
>This is quite good but remove the new keyword, it's not necessary
>there.
The idea is to introduce names which are not previously present, and
_expire_ and the end of the enclosed suite. Without the "new" is valid
Python right now and does
On Sun, Nov 29, 2020, 11:52 PM Greg Ewing
wrote:
> On 30/11/20 9:46 am, David Mertz wrote:
> > def f(a, b, c=21, _foo=foo, _bar=bar):
> >
> > Of course I know that users COULD call `f(1, 2, _foo=something_else)`.
> > But we have asked them not to politely, and "we're all consenting
> adults."
>
On 30/11/20 9:46 am, David Mertz wrote:
def f(a, b, c=21, _foo=foo, _bar=bar):
Of course I know that users COULD call `f(1, 2, _foo=something_else)`.
But we have asked them not to politely, and "we're all consenting adults."
This doesn't work so well if the function takes *args or **kwds
ar
This is quite good but remove the new keyword, it's not necessary there.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
This is a massively less ambitious idea, and doesn't solve the
original problem, but:
I'd like to see a scope for names that are "obviously ;-)" meant to be
short lived. At the moment that's the for loop "counters" and those created
by context managers:
for i in something:
# use i as usual
mo
On 29/11/20 11:02 pm, Paul Sokolovsky wrote:
It will be much more obvious if there's a general (standalone) "const",
I don't think it will. There's nothing about the problem
that points towards constness as a solution, so it doesn't
matter how many other places in the language "const" appears.
On Sun, 29 Nov 2020 at 23:34, Guido van Rossum wrote:
> OTOH if we were to introduce 'let' or 'const' in the language, it would
> surely be usable to solve a whole bunch of other problems, in addition to
> giving us a cleaner way to solve the value capture problem.
Well, IMHO let could help the
On Sun, Nov 29, 2020 at 12:28 PM Brendan Barnwell
wrote:
> For me the only problem with the `x=x` default argument "fix" is
> that.
> . . well, it's in the argument signature. That means it effectively
> becomes part of the function's public API, and people can pass in other
> values, wh
On Sun, Nov 29, 2020 at 8:28 PM Brendan Barnwell
wrote:
> After following this thread I'm still not convinced changing the for
> loop is really a good idea. I basically agree with Steven D'Aprano that
> the supposed benefits of "protecting" against accidental name shadowing
> are marginal at bes
On 2020-11-25 22:07, Guido van Rossum wrote:
Hmm... In the end I think the language design issue is with functions
(and how they capture variable references rather than values), and
fixing it by changing the for-loop is still just a band-aid, with other
problems and inconsistencies. Agreed that t
Hello,
On Sat, 28 Nov 2020 18:59:14 -0800
Guido van Rossum wrote:
> I'm definitely being nerd-sniped here, so take this with a grain of
> salt.
>
> The reason why Python currently doesn't have block scopes is the rule
> that assignment creates or updates a variable in the closest scope.
> This
Hello,
On Sun, 29 Nov 2020 13:39:37 +1300
Greg Ewing wrote:
> On 29/11/20 4:14 am, Paul Sokolovsky wrote:
> >
> > On Fri, 27 Nov 2020 13:06:56 +1300
> > Greg Ewing wrote:
> >
> > There was no mix-up on my side, and neither seems there was on
> > yours. Block-level scoping and const'ness are o
I'm definitely being nerd-sniped here, so take this with a grain of salt.
The reason why Python currently doesn't have block scopes is the rule that
assignment creates or updates a variable in the closest scope. This rule
has taken Python far, because it means you can create a local variable by
as
On 29/11/20 4:14 am, Paul Sokolovsky wrote:
On Fri, 27 Nov 2020 13:06:56 +1300
Greg Ewing wrote:
There was no mix-up on my side, and neither seems there was on yours.
Block-level scoping and const'ness are orthogonal, well composable
features.
Someone (maybe not you) suggested "for const i =
Hello,
On Fri, 27 Nov 2020 13:06:56 +1300
Greg Ewing wrote:
> On 27/11/20 12:11 am, Paul Sokolovsky wrote:
> >
> > On Thu, 19 Nov 2020 18:53:01 +1300
> > Greg Ewing wrote:
> >
> >> Note that this is *not* the same as introducing a new scope.
> >
> > And that's very sad. That means instea
On Sat, Nov 28, 2020 at 12:57:12PM +1100, Cameron Simpson wrote:
> Got a nice example of somewhere where shadowing would be useful and hard
> to do some task otherwise?
Mocking. For example:
https://docs.python.org/3/library/unittest.mock.html#patch-builtins
Monkey-patching. One nice trick I'v
On 27Nov2020 21:13, Steven D'Aprano wrote:
>On Fri, Nov 27, 2020 at 08:32:04AM +1100, Cameron Simpson wrote:
>> On 27Nov2020 00:25, Steven D'Aprano wrote:
>> >Block scoping allows shadowing within a function.
>>
>> Just to this: it needn't.
>
>Yes, I'm aware of that, and discussed languages such
> bow = Ribbon(colour='yellow')
> tie(bow, old_oak_tree)
> for archer in troop:
> let bow = get_weapon()
> archer.take(bow)
> assert bow.colour = 'yellow'
>
I had just this problem yesterday, and on many other days. However, I
don't think the opt-in block scoping w
On Fri, Nov 27, 2020 at 10:33:17PM +1100, Steven D'Aprano wrote:
> On Fri, Nov 27, 2020 at 01:36:00PM +0300, Paul Sokolovsky wrote:
>
> > So, the alternative opinion you hear is that we could allow *optional*
> > block-level scoping.
>
> No such thing.
That dismissal (which made sense in my head
On Fri, Nov 27, 2020 at 01:36:00PM +0300, Paul Sokolovsky wrote:
> So, the alternative opinion you hear is that we could allow *optional*
> block-level scoping.
No such thing.
Even if I don't use it myself, I still have to read code that uses it, I
need to learn about it, there will surely be t
On Fri, Nov 27, 2020 at 01:05:45AM +1100, Chris Angelico wrote:
> On Fri, Nov 27, 2020 at 12:28 AM Steven D'Aprano wrote:
> > Block scoping adds semantic and implementation complexity and annoyance,
> > while giving very little benefit. No thank you.
[...]
> > Is there a shortage of variable names
Hello,
On Fri, 27 Nov 2020 21:21:48 +1100
Steven D'Aprano wrote:
[]
> We can have too many scopes as well as too few:
>
> - a single process-wide global scope is too few;
>
> - every (sub-)expression being its own scope is too many;
>
> so we're just arguing about where the Goldilocks Zone i
On Fri, Nov 27, 2020 at 01:17:07PM +1300, Greg Ewing wrote:
> On 27/11/20 2:25 am, Steven D'Aprano wrote:
> >Block scoping adds semantic and implementation complexity and annoyance,
> >while giving very little benefit.
>
> Yet in *certain situations* it seems that block scoping
> is what people su
On Fri, Nov 27, 2020 at 08:32:04AM +1100, Cameron Simpson wrote:
> On 27Nov2020 00:25, Steven D'Aprano wrote:
> >Block scoping allows shadowing within a function.
>
> Just to this: it needn't.
Yes, I'm aware of that, and discussed languages such as Java which
prohibit name shadowing within a fu
Hello Guido,
On Thu, 26 Nov 2020 14:18:20 -0800
Guido van Rossum wrote:
> On Thu, Nov 26, 2020 at 3:11 AM Paul Sokolovsky
> wrote:
>
> > [...]
> >
>
> Hi Paul,
>
> I think there is a case to be made for adding "let" to Python. Would
> you like to write a PEP? I recommend that you find a co
Hello,
On Fri, 27 Nov 2020 18:32:54 +1300
Greg Ewing wrote:
> On 27/11/20 1:23 pm, Chris Angelico wrote:
> >>
> >> That makes no sense as a phrase in English.
> >
> > Nor do lots of other constructs when they get combined. English
> > doesn't really have good parallels for most computing conc
On Fri, Nov 27, 2020 at 4:34 PM Greg Ewing wrote:
>
> On 27/11/20 1:23 pm, Chris Angelico wrote:
> >>
> >> That makes no sense as a phrase in English.
> >
> > Nor do lots of other constructs when they get combined. English
> > doesn't really have good parallels for most computing concepts.
>
> Pyt
On 27/11/20 1:23 pm, Chris Angelico wrote:
That makes no sense as a phrase in English.
Nor do lots of other constructs when they get combined. English
doesn't really have good parallels for most computing concepts.
Python manages to not be wildly ungrammatical with the bits
of English that i
On Fri, Nov 27, 2020 at 11:08 AM Greg Ewing wrote:
> > I'd suggest that it should be "for let"
>
> That makes no sense as a phrase in English.
>
Nor do lots of other constructs when they get combined. English
doesn't really have good parallels for most computing concepts.
How will this "new assi
On 27/11/20 2:25 am, Steven D'Aprano wrote:
Block scoping adds semantic and implementation complexity and annoyance,
while giving very little benefit.
Yet in *certain situations* it seems that block scoping
is what people subconsciously assume. For example, loop
variables in list comprehensions
On 27/11/20 12:11 am, Paul Sokolovsky wrote:
On Thu, 19 Nov 2020 18:53:01 +1300
Greg Ewing wrote:
Note that this is *not* the same as introducing a new scope.
And that's very sad. That means instead of solving the root of the
problem, adhoc workarounds are proliferated.
I'd be open to the
On Thu, Nov 26, 2020 at 3:11 AM Paul Sokolovsky wrote:
> [...]
>
Hi Paul,
I think there is a case to be made for adding "let" to Python. Would you
like to write a PEP? I recommend that you find a co-author who can help you
write a convincing motivation to sway the Steering Council (not me).
(W
On 27Nov2020 00:25, Steven D'Aprano wrote:
>Block scoping allows shadowing within a function.
Just to this: it needn't.
You could forbid shadowing of the _static_ outer scope easily enough at
parse/compile time. That would prevent a certain class of easy misuse.
i = 9
{ new scope here
On 25Nov2020 22:07, Guido van Rossum wrote:
>Hmm... In the end I think the language design issue is with functions (and
>how they capture variable references rather than values), and fixing it by
>changing the for-loop is still just a band-aid, with other problems and
>inconsistencies. Agreed that
On Thu, Nov 26, 2020, 5:12 AM Greg Ewing
> Then we just need a way to specify that particular names are
> captured by value. Not sure how to do that in a way that doesn't look ugly
> and/or obscure.
>
Isn't that EXACTLY what you call "default argument abuse"?!
To me, that is concise, obvious, an
Hello,
On Fri, 27 Nov 2020 00:25:21 +1100
Steven D'Aprano wrote:
> On Thu, Nov 26, 2020 at 02:11:10PM +0300, Paul Sokolovsky wrote:
>
> > Using "let" will then give natural way to introduce proper
> > block-level lexical scoping in Python:
>
> Why would we want to do that?
Because without t
On Fri, Nov 27, 2020 at 12:28 AM Steven D'Aprano wrote:
> Block scoping adds semantic and implementation complexity and annoyance,
> while giving very little benefit. No thank you.
>
>
> > def foo():
> > let x = 1
> > if bar:
> > let x = 2
> > ...
> > # x is 1 again her
On Thu, Nov 26, 2020 at 02:11:10PM +0300, Paul Sokolovsky wrote:
> Using "let" will then give natural way to introduce proper block-level
> lexical scoping in Python:
Why would we want to do that?
Block-level scoping is too much of a good thing. The right level of
scoping is the function, not t
Hello,
On Thu, 19 Nov 2020 18:53:01 +1300
Greg Ewing wrote:
> Starting a new thread for this as suggested by Guido.
>
> On 18/11/20 7:20 pm, Guido van Rossum wrote:
> > On Tue, Nov 17, 2020 at 22:12 Greg Ewing
> > mailto:greg.ew...@canterbury.ac.nz>>
> > wrote:
> >
> > If there's anything
On 26/11/20 7:07 pm, Guido van Rossum wrote:
Hmm... In the end I think the language design issue is with functions
(and how they capture variable references rather than values)
Well, every other language I know of that has a notion of closures
captures variables exactly the same way that Python
Hmm... In the end I think the language design issue is with functions (and
how they capture variable references rather than values), and fixing it by
changing the for-loop is still just a band-aid, with other problems and
inconsistencies. Agreed that the fix 'x=x' essentially always works, and
that
On Wed, Nov 18, 2020 at 9:54 PM Greg Ewing
wrote:
> Essentially the idea is this: If the loop body contains a def or lambda
> that captures the loop variable, then on each iteration, a new binding
> is created, instead of changing an existing binding.
>
> Note that this is *not* the same as intro
68 matches
Mail list logo
