On Mon, Jan 17, 2022 at 03:27:33PM -0500, David Mertz, Ph.D. wrote:
> Here's a better idea: Use parens for all the levels of nesting, as
> currently, but convince your editor to substitute various other bracket-ish
> things for levels of nesting.
This is approximately what I do, except that I use
I would be more sympathetic to this idea if:
1. I knew how to easily type all those brackets on the keyboard, without having
to use a GUI character picker.
2. I had a guarantee that all of the bracket characters would be both available
and easily distinguishable in any typeface I used.
On Mon, Jan 17, 2022 at 07:19:17AM -0800, Jelle Zijlstra wrote:
> > That is in the global scope, which will be much slower than a local scope.
>
> Global builtins do a hash table lookup; local lookups just follow a
> pointer.
Yes, that is correct, frozenset is a builtin, not a local variable, so
On Mon, Jan 17, 2022 at 3:22 PM John Sturdy wrote:
> But it might be handled better in the display in editors and IDEs (perhaps
> syntax coloring brackets by their depth).
>
VSCode already supports this out of the box. Just search "bracket pair" in
the settings and check (tick) the box for
Perhaps the time isn't ripe for this, and perhaps it never will be, but
UTF8 seems to be handled by just about everything these days. I suspect
this is a crazy suggestion, but on the other hand perhaps people looking
back from 2100 will think "It was crazy that they stuck exclusively with
ASCII
This is clearly one for me to abandon! Thanks for the explanations.
John
On Mon, Jan 17, 2022 at 7:04 PM Paul Moore wrote:
> On Mon, 17 Jan 2022 at 18:51, John Sturdy wrote:
> >
> > My idea is to support the style in which each variable comes into
> existence at a single well-defined point,
On Mon, 17 Jan 2022 at 18:51, John Sturdy wrote:
>
> My idea is to support the style in which each variable comes into existence
> at a single well-defined point, whatever path is taken through the code, and
> so in the case of that example, it would be encouraging the use of
> conditional
My idea is to support the style in which each variable comes into existence
at a single well-defined point, whatever path is taken through the code,
and so in the case of that example, it would be encouraging the use of
conditional expressions.
A worse case of what can be done with the scope rules
On 1/17/22 7:33 AM, John Sturdy wrote:
> One of the few things I don't like about Python is that variable scope
continues after
> the end of the suite the variable was created in --- probably because I think
of local
> variable declarations as equivalent to lambdas that are called immediately,
On Mon, Jan 17, 2022 at 3:50 AM Steven D'Aprano wrote:
> If you saw this code in a review:
>
> t = tuple([1, 2, 3, 4, 5])
>
> would you say "that is okay, because the name lookup is smaller than the
> cost of building the list"?
>
> I wouldn't. I would change the code to `(1, 2, 3, 4, 5)`.
>
On Mon, 17 Jan 2022 at 17:27, Christopher Barker wrote:
> But this is not how Python works, and it never has, it would be a really
> massive change, and I for one, would not like it :-(
I agree with this.
> I guess what I'm getting at is that I'm pretty sure I would find this useful
>
On Mon, Jan 17, 2022 at 9:07 AM Ronald Oussoren
wrote:
>
> For example:
>
> If flag in {‘the’, ‘allowable’, ‘flags’}:
> …
>
> If a frozen set was even a little bit faster or used less memory, it would
> be nice to be able to create one directly.
>
>
> Not really relevant for the discussion,
On Mon, Jan 17, 2022 at 7:36 AM John Sturdy wrote:
> For example, it bugs me that you can write:
>
> if a:
> b = f(x)
> else:
> b = g(y)
>
> and get the same variable 'b' from it in the lines of code following that,
> regardless of which path was taken.
>
Really? But that is a VERY
On 2022-01-17 06:07, Greg Ewing wrote:
U+2744 Snowflake, anyone?
my_frozenset = ❄{1, 2, 3}
That makes me think about using '@':
my_frozenset = @{1, 2, 3}
It's currently used as a prefix for decorators, but that's at the start
of a line.
It could be a problem for the REPL, though:
> On 16 Jan 2022, at 18:44, Christopher Barker wrote:
>
> Is there no way to optimize the byte code without adding to the language?
>
> Not that it’s a bad idea anyway, but I wonder if frozen sets are common
> enough to warrant a change.
>
> Are there any performance advantages to a frozen
Hello,
On Sun, 16 Jan 2022 17:31:48 +0200
Iyad Ahmed wrote:
> Example use cases:
>
>- Loop variables and similar, it is sometimes more comfortable to
> scope it to the loop body only
>- Not having to name variables var1, var2, var3, or makeup
> unnecessarily unique variable names, in
Earlier today in https://bugs.python.org/issue46393, Serhiy Storchaka wrote:
As Steven have noted the compiler-time optimization is not applicable here
because name frozenset is resolved at run-time.
In these cases where a set of constants can be replaced with a frozenset of
constants (in "x in
One of the few things I don't like about Python is that variable scope
continues after the end of the suite the variable was created in ---
probably because I think of local variable declarations as equivalent to
lambdas that are called immediately, which works for most modern
programming
El lun, 17 ene 2022 a las 7:11, Steven D'Aprano ()
escribió:
> On Mon, Jan 17, 2022 at 11:18:13PM +0900, Inada Naoki wrote:
> > On Mon, Jan 17, 2022 at 8:49 PM Steven D'Aprano
> wrote:
> > >
> > > On Mon, Jan 17, 2022 at 08:04:50PM +0900, Inada Naoki wrote:
> > >
> > > > Name lookup is faster
On Mon, Jan 17, 2022 at 11:18:13PM +0900, Inada Naoki wrote:
> On Mon, Jan 17, 2022 at 8:49 PM Steven D'Aprano wrote:
> >
> > On Mon, Jan 17, 2022 at 08:04:50PM +0900, Inada Naoki wrote:
> >
> > > Name lookup is faster than building set in most case.
> > > So I don't think cost to look name up is
On Mon, Jan 17, 2022 at 8:49 PM Steven D'Aprano wrote:
>
> On Mon, Jan 17, 2022 at 08:04:50PM +0900, Inada Naoki wrote:
>
> > Name lookup is faster than building set in most case.
> > So I don't think cost to look name up is important at all.
>
> But the cost to look up the name is *in addition*
The compiler can figure out that the value of
{1, 2, 3}
is a set containing the elements 1, 2 and 3.
The problem with the value of
frozenset({1, 2, 3})
is that the value of frozenset depends on the context. This is because
frozenset = print
is allowed.
According to help(repr):
On Mon, Jan 17, 2022 at 08:04:50PM +0900, Inada Naoki wrote:
> Name lookup is faster than building set in most case.
> So I don't think cost to look name up is important at all.
But the cost to look up the name is *in addition* to building the set.
If you saw this code in a review:
t =
On Sun, Jan 16, 2022 at 05:53:19PM -0800, Brendan Barnwell wrote:
> > f{1, 2, 3}
>
> I don't like that syntax. In the first place, as others have noted,
> it treads too close to existing function-call and indexing syntax. In
> those syntaxes, `f` is a name, whereas here it is
On Mon, Jan 17, 2022 at 7:10 PM Steven D'Aprano wrote:
>
> Out of those 29 calls, I think that probably 13 would be good candidates
> to use a frozenset display form (almost half). For example:
>
> ast.py:binop_rassoc = frozenset(("**",)) # f{("**",)}
> asyncore.py:
On Mon, Jan 17, 2022 at 7:44 PM Paul Moore wrote:
>
> On Mon, 17 Jan 2022 at 10:12, Steven D'Aprano wrote:
> > That would make the creation of frozensets more efficient, possibly
> > encourage people who currently are writing slow and inefficient code
> > like
> >
> > targets = (3, 5, 7, 11,
On Mon, Jan 17, 2022 at 07:07:51PM +1300, Greg Ewing wrote:
> U+2744 Snowflake, anyone?
>
> my_frozenset = ❄{1, 2, 3}
If I knew how to type that, I'd be more impressed :-)
--
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To
On Sun, Jan 16, 2022 at 06:10:58PM -0800, Christopher Barker wrote:
> In a way, what this might do is open the door to interning (some) frozen
> sets, like cPython does for some ints and strings.
I don't think that interning is relevant here. Interning is orthogonal
to the existence of a
On Mon, 17 Jan 2022 at 10:12, Steven D'Aprano wrote:
> That would make the creation of frozensets more efficient, possibly
> encourage people who currently are writing slow and inefficient code
> like
>
> targets = (3, 5, 7, 11, 12, 18, 27, 28, 30, 35, 57, 88)
> if n in targets:
>
Iyad Ahmed writes:
> Example use cases:
>
>- Loop variables and similar, it is sometimes more comfortable to scope
>it to the loop body only
>- Not having to name variables var1, var2, var3, or makeup unnecessarily
>unique variable names, in some situations
I am not
On Mon, Jan 17, 2022 at 12:54:58AM +, Oscar Benjamin wrote:
> A more relevant question right now is if any other set syntax should apply
> to frozensets e.g. should this work:
>
> >>> squares = f{x**2 for x in range(10)}
If display syntax for frozensets were to be approved, then we
On Sun, Jan 16, 2022 at 10:33:41PM -0800, Christopher Barker wrote:
> On Sun, Jan 16, 2022 at 7:05 PM Steven D'Aprano wrote:
>
> >
> > I never suggested adding this "for consistency".
> >
>
> Then what ARE you suggesting it for?
Apologies if my initial post was not clear enough:
On Mon, Jan 17, 2022 at 7:12 PM Paul Moore wrote:
>
> On Mon, 17 Jan 2022 at 01:11, Chris Angelico wrote:
> >
> > On Mon, Jan 17, 2022 at 10:14 AM Paul Moore wrote:
> > >
> > > On Sun, 16 Jan 2022 at 22:55, Steven D'Aprano wrote:
> > > > >>> def f():
> > > > ... return frozenset({1, 2, 3})
On Mon, Jan 17, 2022 at 03:05:36AM +, MRAB wrote:
> How about doubling-up the braces:
>
> {{1, 2, 3}}
I mentioned that earlier. Its not *awful*, but as you point out
yourself, it does run into the problem that nested sets suffer from
brace overflow.
# A set of sets.
}},
On Mon, 17 Jan 2022 at 01:11, Chris Angelico wrote:
>
> On Mon, Jan 17, 2022 at 10:14 AM Paul Moore wrote:
> >
> > On Sun, 16 Jan 2022 at 22:55, Steven D'Aprano wrote:
> > > >>> def f():
> > > ... return frozenset({1, 2, 3})
> > > ...
> > > >>> a = f.__code__.co_consts[1]
> > > >>> a
> > >
35 matches
Mail list logo
