08.04.21 19:58, [email protected] пише:
> I would like to propose adding literal syntax to allow creation of an empty
> set without the need to call the type constructor. I believe the best choice
> for such a literal, and one that has been proposed before, is `{,}`.
You can now use `{*()}` as a
08.04.21 17:59, anthony.flury via Python-ideas пише:
> I was wondering whether a worthwhile extension might be to allow the
> `with` statement to have an `except` and `else` clauses which would
> have the same
> semantics as wrapping the `with` block with a try - for example the
> above would now
I think the best alias for "empty set" would be the Unicode character
"Empty set" or U+2205, i.e. "∅".
Alas, it's not a valid identifier in Python:
>>> ∅ = set()
File "", line 1
∅ = set()
^
SyntaxError: invalid character '∅' (U+2205)
It works with the similarly looking "ϕ" or 'GREEK PH
On Fri, Apr 9, 2021 at 6:09 PM Stéfane Fermigier wrote:
>
> I think the best alias for "empty set" would be the Unicode character "Empty
> set" or U+2205, i.e. "∅".
>
> Alas, it's not a valid identifier in Python:
>
> >>> ∅ = set()
> File "", line 1
> ∅ = set()
> ^
> SyntaxError: invali
Oh god, Stephane, you're giving me flashbacks to PEP 3117 (
https://www.python.org/dev/peps/pep-3117/). But not in a good way. Please
pretty please let's keep unicode characters out of our code.
With regards to the original proposal, for what it's worth, I like it well
enough. I think sets are th
09.04.21 12:50, Matt del Valle пише:
> I think sets are the only type in the builtins module
> without a dedicated literal syntax?
Not only. bytearray, frozenset, slice. It is difficult to create some
complex objects without using constructor. Not counting range,
memoryview and dict views, descrip
Sorry, I really should have had my morning coffee before making that reply.
Big-time thinko :)
What I meant to say is that the other comparable builtin types
(comma-delimited containers of some description) that have literals built
into the language (list, tuple, dict) also have a literal that rep
I was wondering if it might be reasonable to consider adding a set of Greek
letters to the constants in the `string` module. In my mind, the format would
follow the existing convention—constants for both `greek_lowercase` and
`greek_uppercase`, as well as a combined constant `greek_letters`.
Ju
Would it include digamma, san, koppa, or sampi... Or strictly Koine letters?
To a lesser extent than Greek, Hebrew letters are also used commonly in
math. What about the double struck capitals like ℤ, ℚ, and ℕ?
It kinda feels like a very simple third party module couple give many such
names for
This sounds more like a Unicode thing than a generic string thing. And,
in Uncode, Greek characters are included in multiple groupings.
Searching for "Theta" to see what we get:
Greek and Coptic:
U+0398 GREEK CAPITAL LETTER THETA
U+03B8 GREEK SMALL LETTER THETA
U+03D1 GREEK THETA SYMBOL
U+03F4 GRE
On Sat, Apr 10, 2021 at 12:15 AM Paul Bryan wrote:
>
> This sounds more like a Unicode thing than a generic string thing. And, in
> Uncode, Greek characters are included in multiple groupings. Searching for
> "Theta" to see what we get:
>
> Greek and Coptic:
> U+0398 GREEK CAPITAL LETTER THETA
>
I agree. It would be great to get something more than what the
simplistic `unicodedata.category(...)` returns; for example, what
Unicode group a character falls in.
On Sat, 2021-04-10 at 00:29 +1000, Chris Angelico wrote:
> On Sat, Apr 10, 2021 at 12:15 AM Paul Bryan wrote:
> >
> > This sounds m
>
>
> You can now use `{*()}` as a syntax for empty set.
>
> I saw that in the ast module and think it's clever, mainly in a good way.
I don't think it is the same as having dedicated syntax for the empty set
partly because I think it needs to be taught. I don't think a new
pythonista would turn to
On Fri, Apr 9, 2021 at 3:20 AM Serhiy Storchaka wrote:
> 08.04.21 19:58, [email protected] пише:
> > I would like to propose adding literal syntax to allow creation of an
> empty set without the need to call the type constructor. I believe the best
> choice for such a literal, and one that has be
On Fri, Apr 9, 2021 at 6:06 AM Matt del Valle wrote:
>
> What I meant to say is that the other comparable builtin types
> (comma-delimited containers of some description) that have literals built
> into the language (list, tuple, dict) also have a literal that represents
> an empty version of the
On Sat, Apr 10, 2021 at 2:44 AM Ricky Teachey wrote:
>
> On Fri, Apr 9, 2021 at 3:20 AM Serhiy Storchaka wrote:
>>
>> 08.04.21 19:58, [email protected] пише:
>> > I would like to propose adding literal syntax to allow creation of an
>> > empty set without the need to call the type constructor. I
I don't do twitter, so hadn't seen Raymond's comment. But I agree that
`{*()}` is too-clever-by-half. Moreover, it's the same character count as
`set()`, so it doesn't even save anything.
Using five characters to create an empty `set()` really isn't that many. I
do that all the time. Proposals
On Fri, Apr 9, 2021 at 1:30 PM David Mertz wrote:
> I don't do twitter, so hadn't seen Raymond's comment. But I agree that
> `{*()}` is too-clever-by-half. Moreover, it's the same character count as
> `set()`, so it doesn't even save anything.
>
> Using five characters to create an empty `set()
But if there are two proposals with conflicting semantics for the same
syntax that kills both ideas, doesn’t it? Because apparently it’s not clear
what the syntax should mean.
On Fri, Apr 9, 2021 at 00:28 Serhiy Storchaka wrote:
> 08.04.21 17:59, anthony.flury via Python-ideas пише:
> > I was wo
On 09/04/2021 19:02, Guido van Rossum wrote:
But if there are two proposals with conflicting semantics for the same
syntax that kills both ideas, doesn’t it? Because apparently it’s not
clear what the syntax should mean.
Surely it depends (if we adopt a proposal) how we document it. You could
On 4/9/21 11:33 AM, anthony.flury via Python-ideas wrote:
On 09/04/2021 19:02, Guido van Rossum wrote:
But if there are two proposals with conflicting semantics for the same syntax that kills both ideas, doesn’t it?
Because apparently it’s not clear what the syntax should mean.
Surely it dep
David Mertz wrote:
> The pattern of "Create an empty collection, then add stuff in a loop" is
> quite common, ...
Or you can use comprehensions, in which case there's no need for creating an
empty collection.
s = {f(x) for x in some_list}
vs
s = set()
for x in some_list:
s.add(f(x))
__
On Fri, Apr 9, 2021, 3:23 PM Peter Ludemann
wrote:
> David Mertz wrote:
> > The pattern of "Create an empty collection, then add stuff in a loop" is
> quite common, ...
>
> Or you can use comprehensions, in which case there's no need for creating
> an empty collection.
>
> s = {f(x) for x in some
In August 2020, in the context of PEP 472 I suggested
>>> {-}
for the empty set literal. At present the closest we can do for an empty
set literal is
>>> {0} - {0}
set()
The context for this is whether PEP 472 should make
>>> something[]
a syntax error. If we do then, what about th
On 2021-04-08 11:25, Chris Angelico wrote:
On Fri, Apr 9, 2021 at 2:24 AM Paul Bryan wrote:
Q. Safe to assume this would catch exceptions from both the call to `open` as
well as the call to `open.__enter__`?
No, not safe to assume. It's equally reasonable to define it as
guarding only the
>
> $ def unpack_set():
> > return {*()}
> >
> $ dis.dis(unpack_set)
> 2 0 BUILD_SET0
> 2 LOAD_CONST 1 (())
> 4 SET_UPDATE 1
> 6 RETURN_VALUE
>
Seems like the peephole optimizer could be trained t
26 matches
Mail list logo
