[Python-ideas] Re: Adding syntax for the empty set

[Skip Montanaro]

>
> $ 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 to easily recognize that
the LOAD_CONST/SET_UPDATE pair will be a no-op.

Skip
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OVFLVPSKHJWZ5FYDELRCXP66JCQUL33G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python Idea - extension of 'with'

[Mike Miller]

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 body of the statement, or as guarding the header as
well. The semantics have to be locked in one way or the other, and
half the time that's going to be incorrect.



Hmm, I don't see the problem.

I'd assume/want it to catch everything not already caught by the context 
manager.  The scope would be everything inside the "try-with..." and not be 
mandatory of course.  That's why the original example "try ..." comes first and 
is on the outside.


If you wanted it to guard only *inside* the with statement, then you'd not be 
putting the try on the outside in the first place.  You'd put it inside.


I've used try-with many, many times, and can't currently remember any instances 
of with-try.


-Mike
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LKJRNFRYV2SILVPWNL2YP7ZXI7OPPVGZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding syntax for the empty set

[Jonathan Fine]

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 the workarounds
>>> something[*argv]
>>> something[**kwargs]
which so to speak convert the syntax error to a run-time error.

Because
>>> something[]
was ugly and easily misunderstood I suggested
>>> something[-]
and hence
>>> {-}
as new syntax.

The thread from August 2020 can be found (with >>> prompts as quotes) at
https://mail.python.org/archives/list/python-ideas@python.org/thread/2QANGFBMGUSCYOLU3GJ6AOGV6Q2ATC72/#QOBONXUPUMC3ULCGJU6FVHOCIZQDT45W

-- 
Jonathan
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TEZUX6EMOLZBMN6GYJC5J5J5KR2QGTOT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding syntax for the empty set

[David Mertz]

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_list}
>

Only for the very simplest cases of that pattern. Of course I use
comprehensions in such cases.

In many other cases, the loop that adds stuff to collections also has
conditional branches to add this vs that, calls to other functions to get
more data or make decisions, nested loops, temporary variables,
side-effects, and so on.

... Yes, of course with enough contortions, some of that can be worked into
comprehensions. But usually it is better not to, and sometimes it is
impossible.
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CDGXTBGZPKHB4YV2IOMOYMHSSCM6FPUF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding syntax for the empty set

[Peter Ludemann]

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))
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3ZEFFBQMMEG3BHE45SOHB2P4G73C7DC3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python Idea - extension of 'with'

[Ethan Furman]

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 depends (if we adopt a proposal) how we document it. You could argue that very few syntax elements are 
entirely clear unless we explain it - which is what the point of the documentation.


For example for someone who doesn't know what 'with' does, it isn't necessarily clear (just from the syntax) that 'with' 
ensures finalizing of resources when an exception occurs - the documentation has to explain that.


Especially if one is coming from, say, Foxpro, where `with` is a shortcut for 
omitting the class name for attribute lookups.

--
~Ethan~
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BROGBEJET7ZOFQXTSPHY2HGEHGWIHSUA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python Idea - extension of 'with'

[anthony.flury via Python-ideas]

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 
argue that very few syntax elements are entirely clear unless we explain 
it - which is what the point of the documentation.


For example for someone who doesn't know what 'with' does, it isn't 
necessarily clear (just from the syntax) that 'with' ensures finalizing 
of resources when an exception occurs - the documentation has to explain 
that.


IF we reject a syntax because it isn't self-explanatory that sounds like 
a bad precedence.


--
Anthony Flury
*Moble*: +44 07743 282707
*Home*: +44 (0)1206 391294
*email*: anthony.fl...@btinternet.com 
<>___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6Q6BEU6URZUSWJPZWJ4EKTICY2Q7ZQBZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python Idea - extension of 'with'

[Guido van Rossum]

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 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 look like:
> >
> >
> > with open('config.cfg', 'r') as cfg:
> > # Process the open  file
> > config = load_config(cfg)
> > except FileNotFound:
> > logging.info('Config file not found - using default
> configuration')
> > except PermissionError:
> > logging.warning('Cannot open config .cfg - using default
> > configuration')
> > config = default_config()
> > else:
> > logging.info('Using config from config.cfg')
>
> A year or two ago I proposed the same syntax with different semantic: to
> catch only exceptions in the context manager, not in the with block.
> Exceptions in the with block you can catch by adding try/except around
> the with block, exceptions in the with block and the context manager you
> can catch by adding try/except around the with statement, but there is
> no currently way to catch only exceptions in the context manager.
>
> It is quite a common problem, I encounter it several times per year
> since then. I still have a hope to add this feature, and it will
> conflict with your idea.
>
> ___
> 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/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/OMAEC4EPAWBXBIHHLY75M6GTN6OL4MP4/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YSNU23SVDJSRI5IR4UYDJDORCZFLL7PG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding syntax for the empty set

[Ricky Teachey]

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()` really isn't that many. I
> do that all the time.  Proposals to get that down to three characters don't
> feel like any big win.  Actually, I've largely gotten in the habit of
> writing `list()` and `dict()` as well when I want to start with empty
> ones.  I suppose the fact I do that is influenced by having to do it with
> `set()`; but even beyond that, I find it jumps out in intent more than the
> display forms.
>
> The pattern of "Create an empty collection, then add stuff in a loop" is
> quite common, and emphasizing which type of collection is being used is
> useful.  Moreover, the type might be `Queue()`, or `deque()` or `Counter()`
> as well, and I don't expect or want literals for every possible collection.
>

Devil's advocate: it might be nice to not have to import all of those
highly useful collection classes from collections all the time.

What about creating syntax that looks something like:

Counter() <  > c{}
Queue() <  > q{}
deque() <  > dq{}
ChainMap() <  > cm{}
OrderedDict() <  > od{}
defaultdict(list) <  > dd{list}  # this one is admittedly a little weird

And similarly, while you're at it you could do something like:

set() <  > s{}

To be clear: I am not proposing a new "alt call" syntax... these are to be
new LITERALS. I see this as sort of analogous to f-string syntax:

f""

One benefit is this could greatly shorten the reprs for ALL of these types.
Consider:

defaultdict(, {})

rather than:

dd{list}

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VKUD4M7S3AEU4TRVPW7FMZXVRXNLY7P7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding syntax for the empty set

[David Mertz]

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 to get that down to three characters don't
feel like any big win.  Actually, I've largely gotten in the habit of
writing `list()` and `dict()` as well when I want to start with empty
ones.  I suppose the fact I do that is influenced by having to do it with
`set()`; but even beyond that, I find it jumps out in intent more than the
display forms.

The pattern of "Create an empty collection, then add stuff in a loop" is
quite common, and emphasizing which type of collection is being used is
useful.  Moreover, the type might be `Queue()`, or `deque()` or `Counter()`
as well, and I don't expect or want literals for every possible collection.

On Fri, Apr 9, 2021 at 5:43 PM Ricky Teachey  wrote:

> On Fri, Apr 9, 2021 at 3:20 AM Serhiy Storchaka 
> wrote:
>
>> 08.04.21 19:58, ucod...@gmail.com пише:
>> > 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 syntax for empty set.
>>
>
> Interestingly, Raymond Hettinger recently had a post on twitter
> specifically deriding this usage as obfuscatory, and expressing his
> preference that people not do it (and use set() instead).
>
> https://twitter.com/raymondh/status/1372376414184296448
>
> I tend to agree with him on that... I have no opinion on whether set
> should be given its own "empty repr literal", but I don't think {*()} is a
> useful suggestion to give people who want one.
>
> ---
> Ricky.
>
> "I've never met a Kentucky man who wasn't either thinking about going home
> or actually going home." - Happy Chandler
> ___
> 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/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/5MVX7DYTMYRGZNTAFAW4DQXQH4YLZHTO/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EVX6ZFBNFQJ4NCW4X5QEA52WN3QJDLIF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding syntax for the empty set

[Chris Angelico]

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, ucod...@gmail.com пише:
>> > 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 syntax for empty set.
>
>
> Interestingly, Raymond Hettinger recently had a post on twitter specifically 
> deriding this usage as obfuscatory, and expressing his preference that people 
> not do it (and use set() instead).
>
> https://twitter.com/raymondh/status/1372376414184296448
>
> I tend to agree with him on that... I have no opinion on whether set should 
> be given its own "empty repr literal", but I don't think {*()} is a useful 
> suggestion to give people who want one.
>

Like "1e1000" as a representation of float("inf"), it's a good trick
for contexts where you absolutely have to use syntax with no names.

ChrisA
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NEUZCQBKK3NHBVALMYBTAHR4I3I2F3NK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding syntax for the empty set

[Christopher Barker]

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 themselves, except for set.
>

To emphasize that point, sets DO have a literal (or display, or whatever we
want to call it) for non-empty sets, so there is a real asymmetry there.

I like {,} alright, and then maybe allowing [,] and (,) for lists and
tuple, but where does dict fit in? maybe: {:,} ? kinda ugluy, but provides
more symmetry

The fact that () creates a tuple, but (2) does not is problematic -- way
too late to change anything there, but adding (,) as an optional empty
tuple might help a tiny bit in the future.

-CHB

-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2ZIOKBWW242COU5ZMLU46YOR2GQI3V6N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding syntax for the empty set

[Ricky Teachey]

On Fri, Apr 9, 2021 at 3:20 AM Serhiy Storchaka  wrote:

> 08.04.21 19:58, ucod...@gmail.com пише:
> > 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 syntax for empty set.
>

Interestingly, Raymond Hettinger recently had a post on twitter
specifically deriding this usage as obfuscatory, and expressing his
preference that people not do it (and use set() instead).

https://twitter.com/raymondh/status/1372376414184296448

I tend to agree with him on that... I have no opinion on whether set should
be given its own "empty repr literal", but I don't think {*()} is a useful
suggestion to give people who want one.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5MVX7DYTMYRGZNTAFAW4DQXQH4YLZHTO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding syntax for the empty set

[micro codery]

>
>
> 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 empty tuple unpacking to get the empty set, where
I do think that either set() or {,} would be natural, at least after some
trial and exceptions. It also doesn't give quite the optimization as {,}.
$ def comma_set():
> return {,}
>
$ dis.dis(comma_set)
  2   0 BUILD_SET0
  2 RETURN_VALUE
$ def unpack_set():
> return {*()}
>
$ dis.dis(unpack_set)
  2   0 BUILD_SET0
  2 LOAD_CONST   1 (())
  4 SET_UPDATE   1
  6 RETURN_VALUE
although it is better than recommendations I have seen for 2.7 code
$ def and_set():
> return {1} & {2}
>
$ dis.dis(and_set)
  2   0 LOAD_CONST   1 (1)
  2 BUILD_SET1
  4 LOAD_CONST   2 (2)
  6 BUILD_SET1
  8 BINARY_AND
 10 RETURN_VALUE

Part of the problem here might be the teaching; if {*()} had been talked
about since 3.0 and pointed out in documentation and tutorials I likely
would never have thought to raise this proposal. But I don't think it is
well known, and not often used. I gave examples of where in cpython set()
is used, however {*()} is only used once, as a string in ast.py; not even
set repr uses this fancy syntax but instead returns "set()" for the empty
set, even though braces are used to repr sets of any non-zero length.
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/T4P5QV5TLLLPCBYLAZ57AYRDJM3JWHXI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Greek alphabet in built-in`string` module

[Paul Bryan]

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 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 GREEK CAPITAL THETA SYMBOL
> > 
> > Phonetic Extensions Supplement:
> > U+1DBF MODIFIER LETTER SMALL THETA
> > 
> > Mathematical Alphanumeric Symbols:
> > U+1D6AF MATHEMATICAL BOLD CAPITAL THETA
> > U+1D6B9 MATHEMATICAL BOLD CAPITAL THETA SYMBOL
> > U+1D6C9 MATHEMATICAL BOLD SMALL THETA
> > (... 17 more Thetas in this group! ...)
> > 
> > If you were to pick a definitive set of Greek characters for your
> > use case, would it be in the Mathematical Alphanumeric Symbols
> > category? Would others' expected use of Greek characters match
> > yours, or would it need to be inclusive of all Greek characters
> > across groupings?
> > 
> > I'm beginning to sense a metal container containing wriggly
> > things...
> > 
> 
> But I think you've also nailed the correct solution. Python comes
> with
> [1] a unicodedata module, which would be the best way to define these
> sorts of sets. It's a tad messy to try to gather the correct elements
> though, so maybe the best way to do this would be a
> unicodedata.search() function that returns a string of all characters
> with a particular string in their names, or something like that.
> 
> ChrisA
> 
> [1] technically, CPython and many other implementations come with,
> but
> there are some (eg uPy) that don't
> ___
> 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/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/5MRAFMNZQ27DDAA7ZRD2E55OAFKWD734/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RJBE2WZV4BM2INB2HR7FLHOR45XM73MB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Greek alphabet in built-in`string` module

[Chris Angelico]

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
> U+03B8 GREEK SMALL LETTER THETA
> U+03D1 GREEK THETA SYMBOL
> U+03F4 GREEK CAPITAL THETA SYMBOL
>
> Phonetic Extensions Supplement:
> U+1DBF MODIFIER LETTER SMALL THETA
>
> Mathematical Alphanumeric Symbols:
> U+1D6AF MATHEMATICAL BOLD CAPITAL THETA
> U+1D6B9 MATHEMATICAL BOLD CAPITAL THETA SYMBOL
> U+1D6C9 MATHEMATICAL BOLD SMALL THETA
> (... 17 more Thetas in this group! ...)
>
> If you were to pick a definitive set of Greek characters for your use case, 
> would it be in the Mathematical Alphanumeric Symbols category? Would others' 
> expected use of Greek characters match yours, or would it need to be 
> inclusive of all Greek characters across groupings?
>
> I'm beginning to sense a metal container containing wriggly things...
>

But I think you've also nailed the correct solution. Python comes with
[1] a unicodedata module, which would be the best way to define these
sorts of sets. It's a tad messy to try to gather the correct elements
though, so maybe the best way to do this would be a
unicodedata.search() function that returns a string of all characters
with a particular string in their names, or something like that.

ChrisA

[1] technically, CPython and many other implementations come with, but
there are some (eg uPy) that don't
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5MRAFMNZQ27DDAA7ZRD2E55OAFKWD734/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Greek alphabet in built-in`string` module

[Paul Bryan]

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 GREEK CAPITAL THETA SYMBOL

Phonetic Extensions Supplement:
U+1DBF MODIFIER LETTER SMALL THETA

Mathematical Alphanumeric Symbols:
U+1D6AF MATHEMATICAL BOLD CAPITAL THETA
U+1D6B9 MATHEMATICAL BOLD CAPITAL THETA SYMBOL
U+1D6C9 MATHEMATICAL BOLD SMALL THETA
(... 17 more Thetas in this group! ...)

If you were to pick a definitive set of Greek characters for your use
case, would it be in the Mathematical Alphanumeric Symbols category?
Would others' expected use of Greek characters match yours, or would it
need to be inclusive of all Greek characters across groupings?

I'm beginning to sense a metal container containing wriggly things...

Paul

On Fri, 2021-04-09 at 12:59 +, mitchell.negus...@gmail.com wrote:
> 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`.
> 
> Judging by how these constants are defined in the module, this seems
> like it might be an almost trivially easy addition (with minimal
> future maintenance required), and could provide a neat little
> functionality. Where Python 3 already uses unicode strings, I don't
> believe this would cause any backward compatibility issues. 
> 
> The only one drawback I can see might be polluting the namespace if
> it is not a commonly used feature. That said, the Greek alphabet is
> used so commonly in math/science that I'd hazard a guess it might be
> valuable for some, especially as unicode becomes increasingly
> prevalent. Obviously developers could build their own similar
> constant just by creating a string with those characters, but this
> would save a step, whether that's adding a dependency or
> copying/pasting a handful of characters. I also anticipate that the
> argument may come up that this opens a can of worms, and then why not
> include even more symbols. I think that is a valid concern, though I
> think the Greek alphabet is somewhat unique in it's prevalence (due
> to it's use in math/science), on top of the fact that it is both
> limited and permanent (in a way that things like logograms and emojis
> may not be).
> 
> I'm certainly not an expert on the Python source code though, so
> please correct me if there's an obvious reason not to add this or if
> this has been debated before :)
> ___
> 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/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/STABL2VLT2XQV3XO6S7OBVAABJR6QVEN/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6PBD5CGGX6RT6WAP5W5RIZQ7TBZ2RVOQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Greek alphabet in built-in`string` module

[David Mertz]

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 "characters used in such-and-such domain."





On Fri, Apr 9, 2021, 9:34 AM  wrote:

> 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`.
>
> Judging by how these constants are defined in the module, this seems like
> it might be an almost trivially easy addition (with minimal future
> maintenance required), and could provide a neat little functionality. Where
> Python 3 already uses unicode strings, I don't believe this would cause any
> backward compatibility issues.
>
> The only one drawback I can see might be polluting the namespace if it is
> not a commonly used feature. That said, the Greek alphabet is used so
> commonly in math/science that I'd hazard a guess it might be valuable for
> some, especially as unicode becomes increasingly prevalent. Obviously
> developers could build their own similar constant just by creating a string
> with those characters, but this would save a step, whether that's adding a
> dependency or copying/pasting a handful of characters. I also anticipate
> that the argument may come up that this opens a can of worms, and then why
> not include even more symbols. I think that is a valid concern, though I
> think the Greek alphabet is somewhat unique in it's prevalence (due to it's
> use in math/science), on top of the fact that it is both limited and
> permanent (in a way that things like logograms and emojis may not be).
>
> I'm certainly not an expert on the Python source code though, so please
> correct me if there's an obvious reason not to add this or if this has been
> debated before :)
> ___
> 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/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/STABL2VLT2XQV3XO6S7OBVAABJR6QVEN/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RKMKK3IEYEQFURGPTFCO2JX7UQETD6NH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Greek alphabet in built-in`string` module

[mitchell . negus . 57]

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`.

Judging by how these constants are defined in the module, this seems like it 
might be an almost trivially easy addition (with minimal future maintenance 
required), and could provide a neat little functionality. Where Python 3 
already uses unicode strings, I don't believe this would cause any backward 
compatibility issues. 

The only one drawback I can see might be polluting the namespace if it is not a 
commonly used feature. That said, the Greek alphabet is used so commonly in 
math/science that I'd hazard a guess it might be valuable for some, especially 
as unicode becomes increasingly prevalent. Obviously developers could build 
their own similar constant just by creating a string with those characters, but 
this would save a step, whether that's adding a dependency or copying/pasting a 
handful of characters. I also anticipate that the argument may come up that 
this opens a can of worms, and then why not include even more symbols. I think 
that is a valid concern, though I think the Greek alphabet is somewhat unique 
in it's prevalence (due to it's use in math/science), on top of the fact that 
it is both limited and permanent (in a way that things like logograms and 
emojis may not be).

I'm certainly not an expert on the Python source code though, so please correct 
me if there's an obvious reason not to add this or if this has been debated 
before :)
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/STABL2VLT2XQV3XO6S7OBVAABJR6QVEN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding syntax for the empty set

[Matt del Valle]

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 represents
an empty version of themselves, except for set. It's not really much of an
argument, but I figured I'd mention it.

On Fri, Apr 9, 2021 at 1:23 PM Serhiy Storchaka  wrote:

> 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, descriptors (staticmethod, classmethod,
> property), exceptions, iterators (filter, map, zip, enumerate, reversed
> and numerous collection iterators). All these types are defined in the
> builtins module.
>
> ___
> 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/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/LS43IAFFLNCCVVLF6WXMXOYZFOSNOHRL/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/Y6UJDJYIL374UQHOGCTTIHGOI4SJRZMO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding syntax for the empty set

[Serhiy Storchaka]

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, descriptors (staticmethod, classmethod,
property), exceptions, iterators (filter, map, zip, enumerate, reversed
and numerous collection iterators). All these types are defined in the
builtins module.

___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LS43IAFFLNCCVVLF6WXMXOYZFOSNOHRL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding syntax for the empty set

[Matt del Valle]

 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 the only type in the builtins module without a
dedicated literal syntax? So it would provide, let's say, *pleasing
symmetry* in that regard. I think literals also have some (minor)
performance benefits compared to their equivalent type constructors.

As long as no one can think of any objections (or perhaps an alternate
syntax), it seems like a reasonable enough backwards-compatible change.

On Fri, Apr 9, 2021 at 9:54 AM Chris Angelico  wrote:

> 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: invalid character '∅' (U+2205)
> >
> > It works with the similarly looking "ϕ" or 'GREEK PHI SYMBOL' (U+03D5)
> >
> > >>> ϕ = set()
> > >>> ϕ.union({1,2})
> > {1, 2}
> >
> > But it's less than ideal.
> >
> > I think it's an error from the Unicode standard to list the empty set as
> a "Mathematical Operator" (
> https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode#Mathematical_Operators_block)
> and not as a
> > "Letterlike Symbol" like ℝ or ℕ (
> https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode#Letterlike_Symbols_block
> ).
> >
> > Ex:
> >
> > >>> ℕ = [0, ...]  # Whatever that means...
> > >>> ℕ
> > [0, Ellipsis]
> >
> > So yes, the language would need to be changed to allow the proper empty
> set unicode symbol to be used.
> >
>
> Not to mention everyone's keyboards. Python != APL. Err, I mean, Python ≠
> APL.
>
> ChrisA
> ___
> 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/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/TXKHZY6L3CE22XVK3MJTSW2LVGBOIBG5/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/D2K643R5LFIG35ZPACFQNCPMZP5LZSWR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding syntax for the empty set

[Chris Angelico]

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: invalid character '∅' (U+2205)
>
> It works with the similarly looking "ϕ" or 'GREEK PHI SYMBOL' (U+03D5)
>
> >>> ϕ = set()
> >>> ϕ.union({1,2})
> {1, 2}
>
> But it's less than ideal.
>
> I think it's an error from the Unicode standard to list the empty set as a 
> "Mathematical Operator" 
> (https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode#Mathematical_Operators_block)
>  and not as a
> "Letterlike Symbol" like ℝ or ℕ 
> (https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode#Letterlike_Symbols_block).
>
> Ex:
>
> >>> ℕ = [0, ...]  # Whatever that means...
> >>> ℕ
> [0, Ellipsis]
>
> So yes, the language would need to be changed to allow the proper empty set 
> unicode symbol to be used.
>

Not to mention everyone's keyboards. Python != APL. Err, I mean, Python ≠ APL.

ChrisA
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TXKHZY6L3CE22XVK3MJTSW2LVGBOIBG5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding syntax for the empty set

[Stéfane Fermigier]

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 PHI SYMBOL' (U+03D5)

>>> ϕ = set()
>>> ϕ.union({1,2})
{1, 2}

But it's less than ideal.

I think it's an error from the Unicode standard to list the empty set as a
"Mathematical Operator" (
https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode#Mathematical_Operators_block)
and not as a
"Letterlike Symbol" like ℝ or ℕ (
https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode#Letterlike_Symbols_block
).

Ex:

>>> ℕ = [0, ...]  # Whatever that means...
>>> ℕ
[0, Ellipsis]

So yes, the language would need to be changed to allow the proper empty set
unicode symbol to be used.

  S.



On Thu, Apr 8, 2021 at 11:27 PM  wrote:

> Hello,
>
> 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 `{,}`.
>
> I know this idea has surfaced a few times before, but I cannot find any
> serious consideration since the 3K ideas chain with the closest to a
> pronouncement here
> https://mail.python.org/pipermail/python-3000/2006-May/001599.html. In
> that thread the idea of a new syntax for the empty set did not seem to be
> rejected outright, but more that the idea of set literals at all was still
> in question and as empty sets were not implemented for 2.7 they were
> ultimately still left out of 3k, intentionally or unintentionally.
>
> Within cpython itself `set()` is used just over 200 times to assign a
> variable the value of an empty set. As a comparison `dict()` is used only
> 15 times, and all but one of those are within the test module, mostly for
> testing dict. On the other hand, `{}` is used for assignment a little over
> 1300 times; I think there is a clear preference for using literal over type
> construction when possible.
>
> I have a working implementation of this new syntax at
> https://github.com/ucodery/cpython/tree/empty-set which includes a few
> changes. Python from this branch allows `{,} == set()` but also `[,] ==
> list()` and `(,) == tuple`.  Partly this was because the grammar changes
> were easier to do all three but also because I personally liked keeping
> some symmetry between these collection literals. The main point of starting
> this thread is to gather opinions on adding `{,}` to the language, but I
> would like to discuss the other two as well.
>
> As a secondary point, I do think that this new tuple syntax would make
> teaching python easier. Those new to python often believe that parentheses
> are what make a tuple and only later, if ever, realize that it is only
> value(s) followed by a comma that construct a tuple and that parentheses
> are places around it mainly for readability. This misunderstanding often
> leads to a bug like  `iter((4))`, assuming the programmer meant
> `iter((4,))`. I believe this confusion about whether it is the parentheses
> or the commas that construct a tuple is deepened because two parentheses
> surrounding nothing _does_ specifically create the empty tuple but `empty =
> ,` is a SyntaxError. With this literal tuple change, those new to the
> language can be told that parentheses containing at least one comma always
> creates a tuple (at least anywhere is is grammatically valid to have a
> tuple).
>
> Jeremy
> ___
> 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/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/TUCSR7C5K7A4Z62564CTYRR2C6VNGEQ4/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ &
http://pydata.fr/
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/X4TX2HDNKDJ7PVZL3DVI5QD2MIMRHKO4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python Idea - extension of 'with'

[Serhiy Storchaka]

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 look like:
> 
> 
> with open('config.cfg', 'r') as cfg:
>     # Process the open  file
>     config = load_config(cfg)
> except FileNotFound:
>     logging.info('Config file not found - using default configuration')
> except PermissionError:
>     logging.warning('Cannot open config .cfg - using default
> configuration')
>     config = default_config()
> else:
>     logging.info('Using config from config.cfg')

A year or two ago I proposed the same syntax with different semantic: to
catch only exceptions in the context manager, not in the with block.
Exceptions in the with block you can catch by adding try/except around
the with block, exceptions in the with block and the context manager you
can catch by adding try/except around the with statement, but there is
no currently way to catch only exceptions in the context manager.

It is quite a common problem, I encounter it several times per year
since then. I still have a hope to add this feature, and it will
conflict with your idea.

___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OMAEC4EPAWBXBIHHLY75M6GTN6OL4MP4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding syntax for the empty set

[Serhiy Storchaka]

08.04.21 19:58, ucod...@gmail.com пише:
> 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 syntax for empty set.

___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DOW63RAL3275PWUIAYGMWC5FE66L7HVD/
Code of Conduct: http://python.org/psf/codeofconduct/