[Python-ideas] Re: Towards better type annotations enabled by PEP-0563, was: Re: Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
IMHO, if `->` becomes an operator with semantics, then `[t1, ..., tn] -> tr` should mean `typing.Callable[[t1, ..., tn], tr]`. ___ 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/ACRRCSNMMQ54IUHRYC3NH4XUL54VDUAQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Towards better type annotations enabled by PEP-0563, was: Re: Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
On 24/05/20 10:26 am, Paul Sokolovsky wrote: On Mon, 18 May 2020 13:25:50 +1200 Greg Ewing wrote: Or maybe we could leverage the new walrus operator and write str := (int) With the idea that someone may confuse ":=" for "<-", so we can swap result and argument types comparing to their natural/intuitive order? No, with the idea of making use of an already-legal expression and not introducing any new syntax into the grammar. But we indeed can treat ":=" as a function operator in annotations, and write: (int) := str But that would be backwards with respect to the flow of data when := is used for assignment. Also, it is not currently legal syntax when there is more than one argument, because := doesn't support unpacking. -- Greg ___ 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/IQP4PFE5SPS4F3TIJBAER3S3JEX5JPOF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
Wouldn't it be better implemented on an editor as a display option instead of changing python? Because, as I understand, it's an issue of appearing nice on screen, rather than storing (and parsing) `'\u2192'` as an alias to `'->'` on type hints. It *would* look nice, though ___ 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/HEWJOAZIXZY2ESGPC2OCGSD25KKFVLSU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python GIL Thoughts
On 5/23/2020 6:24 PM, redrad...@gmail.com wrote:
> Hi all,
>
> I am very exciting about the sub-interpreters ... but I do not like some
> parts ...
> Consider the following code:
> ```python
> import _xxsubinterpreters as interpreters
> import threading
> import textwrap as tw
> import marshal
>
> if __name__ == '__main__':
> # Create a sub-interpreter
> interpid = interpreters.create()
>
> # If you had a function that generated some data
> arry = list(range(0,100))
>
> # Create a channel
> channel_id = interpreters.channel_create()
>
> # Pre-populate the interpreter with a module
> interpreters.run_string(interpid, "import marshal; import
> _xxsubinterpreters as interpreters")
>
> # Define a
> def run(interpid, channel_id):
> # Still is run in thread which
> is use GIL
> interpreters.run_string(interpid,
> tw.dedent("""
> arry_raw = interpreters.channel_recv(channel_id)
> arry = marshal.loads(arry_raw)
> result = [1,2,3,4,5] # where you would do some calculating
> result_raw = marshal.dumps(result)
> interpreters.channel_send(channel_id, result_raw)
> """),
>shared=dict(
>channel_id=channel_id
>),
>)
>
> inp = marshal.dumps(arry)
> interpreters.channel_send(channel_id, inp)
>
> # Run inside a thread
> t = threading.Thread(target=run, args=(interpid, channel_id))
> t.start()
>
> # Sub interpreter will process. Feel free to do anything else now.
> output = interpreters.channel_recv(channel_id)
> interpreters.channel_release(channel_id)
> output_arry = marshal.loads(output)
>
> print(output_arry)
> ```
>
> Add some `async` execution of `interpreters.run_string_async` and other async
> functions !!
>
> Also regarding the threads ... I think it is better to make
> `threading.Thread` as green `Thread` !!
>
> I know, I know, `Thread` is not possible due to `sync io` ... But we can to
> change underling `api` from `sync io` to `async io` !!
> User will notice nothing, but performance will be increased mush more !!
Only if your workload is CPU bound. Python optimizes IO bound workload
performance by releasing the GIL while doing IO. Green threads generally do
not offer this option.
--Edwin
___
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/VBO6PIWHVKWMYRNND3P7LMLE6JQKD3RJ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Python GIL Thoughts
Hi all,
I am very exciting about the sub-interpreters ... but I do not like some parts
...
Consider the following code:
```python
import _xxsubinterpreters as interpreters
import threading
import textwrap as tw
import marshal
if __name__ == '__main__':
# Create a sub-interpreter
interpid = interpreters.create()
# If you had a function that generated some data
arry = list(range(0,100))
# Create a channel
channel_id = interpreters.channel_create()
# Pre-populate the interpreter with a module
interpreters.run_string(interpid, "import marshal; import
_xxsubinterpreters as interpreters")
# Define a
def run(interpid, channel_id):
# Still is run in thread which is
use GIL
interpreters.run_string(interpid,
tw.dedent("""
arry_raw = interpreters.channel_recv(channel_id)
arry = marshal.loads(arry_raw)
result = [1,2,3,4,5] # where you would do some calculating
result_raw = marshal.dumps(result)
interpreters.channel_send(channel_id, result_raw)
"""),
shared=dict(
channel_id=channel_id
),
)
inp = marshal.dumps(arry)
interpreters.channel_send(channel_id, inp)
# Run inside a thread
t = threading.Thread(target=run, args=(interpid, channel_id))
t.start()
# Sub interpreter will process. Feel free to do anything else now.
output = interpreters.channel_recv(channel_id)
interpreters.channel_release(channel_id)
output_arry = marshal.loads(output)
print(output_arry)
```
Add some `async` execution of `interpreters.run_string_async` and other async
functions !!
Also regarding the threads ... I think it is better to make `threading.Thread`
as green `Thread` !!
I know, I know, `Thread` is not possible due to `sync io` ... But we can to
change underling `api` from `sync io` to `async io` !!
User will notice nothing, but performance will be increased mush more !!
Consider the following execution of `threading.Thread` in Python:
```
gil_lock.acquire()
for green_thread in green_threads:
thread.execute()
gil_lock.release()
```
If we implement in such way we will be able to reduce resource used in system,
but performance would be the same !!
Sub-Interpreter would be the something like Workers in JavaScript, but much
more flexible !!
What we will have at the end:
1) `threading.Thread` is a green thread that do not consume a lot of resources
but still useful !!
2) Real parallelizm is done within sub-interpreters like workers in JavaScript,
but much more flexible
Say what do you think ?
___
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/NYKC4UCRQXT6K7BXACBTIU57MIAK2MPF/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Towards better type annotations enabled by PEP-0563, was: Re: Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
Hello, On Mon, 18 May 2020 02:39:27 +0100 MRAB wrote: [] > > Or maybe we could leverage the new walrus operator and write > > > > str := (int) > > > It would be closer to the existing annotation if we could write: > > [int] -> str To make it clear, the talk is about "better", not "existing" annotation syntax, which is a square (literally) peg in a round hole. With PEP 0563, there's totally no need to wrap everything in square brackets, and atrocities like __class_getitem__ can be treated like an implementation detail of a particular Python implementation (CPython, that is). With PEP 0563, while evaluating annotations, one can just pass to eval() a suitably constructed "globals" dict, to enable any operators on any symbols (which would be represented by objects, not classes), or just operate on AST with even finer level of control. -- Best regards, Paul mailto:pmis...@gmail.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/DOUR5EK2WYSNE7TUNFJ6DQTPWQMASDUL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Towards better type annotations enabled by PEP-0563, was: Re: Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
Hello,
On Mon, 18 May 2020 13:25:50 +1200
Greg Ewing wrote:
> On 18/05/20 1:59 am, Paul Sokolovsky wrote:
> > But even
> > {(int): str} is a better type annotation for a function than
> > Callable[[int], str].
>
> I don't agree -- it looks more like some kind of dict type, and
> would be better reserved for that purpose.
Well, I don't say "ideal", I say "better". The point is that the world
learned long ago that any type of information can be represented with
just recursive parens: (foo (bar 1 (2) 3)), but some variety in
punctuation helps mere humans among us.
>
> > And if we e.g. talk about making "->" a special operator which would
> > allow it to appear in other contexts
>
> Or maybe we could leverage the new walrus operator and write
>
> str := (int)
With the idea that someone may confuse ":=" for "<-", so we can swap
result and argument types comparing to their natural/intuitive order?
Well, I guess that's not what I'm talking about. But we indeed can treat
":=" as a function operator in annotations, and write:
(int) := str
Actually, we don't have to use funky novelties, and mere "-" looks
better as a lookalike for "->" than ":=". The following works as
expected:
=
from __future__ import annotations
def foo(f: (str, int) - int = map, seq: list = None):
pass
print(foo.__annotations__)
import ast
print(ast.dump(ast.parse(foo.__annotations__["f"]).body[0]))
=
I'd still consider it a better idea to just make "->" an operator on
the AST level. Can stop there, because realistically (or sanely)
PEP-0563 annotations would be parsed via an AST (example above).
But if there's desire to assign some semantics to it, it can be that of
making a tuple, with precedence just above "," operator, so
"foo -> bar, 1 -> 2" would evaluate to ((foo, bar), (1, 2)).
Worst-case, can add a __rarrow__ dunder.
>
> --
> Greg
--
Best regards,
Paul mailto:pmis...@gmail.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/56BAIT46CLGQWYEOL7VU54VENG72QCNO/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python tagged unions based on dataclasses
Hello, On Sat, 23 May 2020 21:52:47 +0900 "Stephen J. Turnbull" wrote: > Paul Sokolovsky writes: > > Andrey Cizov wrote: > > > > Sorry I forgot to add the URL: > > > https://pypi.org/project/tagged-dataclasses/ > > > As a quick comment, looks verbose comparing to ML ;-). > > Do you mean ML, the language? > Yes, ML, the programming language: https://en.wikipedia.org/wiki/ML_(programming_language) , which is arguably the language which popularized (ahem, but in 40+ years, the effects are definitely visible) algebraic data types and pattern matching on them. -- Best regards, Paul mailto:pmis...@gmail.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/TTBWASQORJFER4UU6XZ3IDNU7BX6QDBG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Optional keyword arguments
A programmer making the least effort wouldn't update themselves on the grammar: the patch would be useless. ___ 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/IACJB4BZFVFQR36O5WLE6CA2XM3IJTZM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Enhance list.index with a comparison function
Christopher Barker writes:
> Interesting -- in other recent threads, Ive felt that those of us that
> thought "iterators and `next" were relatively advanced concepts that
> newbies didn't need to learn were dismissed ...
I for one don't *dismiss* that idea iterators and next are advanced,
but I wonder if there aren't halfway explanations for *many* of the
issues that come up that
> doesn't really require the full concept of iterators and iterables
I also believe that *some* of the halfway explanations are useful to
new Pythonistas, and don't (necesssarily) leave them with
misconceptions, such David's implementation of "first_one_like_this"
and Andrew's explanation of files as streams ("they know where they're
going to read next").
(Note: AFAICS the only definition of iterable you need until you've
introduced ABCs and/or protocols is "you can usefully put iterables,
and nothing that isn't iterable, in the 'in' clause of a 'for'
statement". This is much simpler than explaining reasonably
completely what an iterator is and why you might care. It's obvious
why you care about iterables, of course.)
> Interestingly, this seems to contradict API design-wise, what's been pushed
> on recent threads:
>
> * Rather than adding a keyword argument that changes behavior, we should
> add another function to itertools (or the like)
This is a matter of taste. I subscribe to it; I thought Guido did
too, but he says that in this case at least he likes the flag.
> and
>
> * rather than add functionality to a built-in (or ABC), we should add
> utility functions that can act on many related types
This is a principle some subscribe to, yes, but it doesn't apply in
the zip case, since zip already acts on an tuple of arbitrary iterables.
It does apply to ABCs, but it's most persuasive when a highly abstract
ABC already has all the prerequisites for the function to work. For
example, iter() has an obvious implementation for any sequence, it's
basically just
def iterseq(seq):
def wrapper():
for i in range(len(seq)):
yield seq[i]
return wrapper()
and it works because all sequences already have __len__ and
__getitem__. Then for *unordered* containers like sets and dicts, you
can add a protocol (__iter__).
___
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/PTPCXCJT6EBJ46HQMUD3AWK7GL4ZX5ZH/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: How to propose a change with tests where the failing test case (current behaviour) is bad or dangerous
On Fri, May 22, 2020 at 4:23 AM Steven D'Aprano wrote: > In pseudo-code: > > - create a temporary file of 2048 bytes; > - write a NTFS file system in that file; > - mount that file system somewhere so it is visible; > > So have the test create a new file system on the fly, cd into that file > system, run the test proper, and if it fills up, no harm done. > If that IS doable on all platforms we care about, it could be pretty handy for all kinds of tests that require writing files. yes, in most cases, temp files work fine, but this feels cleaner and easier to make make sure you don't leave any files laying around after your tests. It would be a handy utility to have available in unit tests in general. -CHB -- Christopher Barker, PhD 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/ZWJT7VO3OCLAQ6RZWIL5IZMA7ZM2YUQD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Enhance list.index with a comparison function
> > for obj in somelist: > > > if comparison(obj, needle): > > > do_something(obj) > > > break > People who think in functional programming terms will probably love the > `next(filter(...))` idiom, but not everyone thinks or likes functional > programming idioms, and there are many people who would reject a patch > containing that idiom. > I wouldn't reject it, but I don't love the functional idioms (well, I don't love the functional functions (map, filter, vs comprehensions) -- I'd be inclined to go the comprehension way -- which woukld only require understanding next() if you only wanted the first one, but I suspect most of the time you don't only want the first anyway. 1. It requires teaching people about iterators and `next` first. > Interesting -- in other recent threads, Ive felt that those of us that thought "iterators and `next" were relatively advanced concepts that newbies didn't need to learn were dismissed ... But in this case: next(i for i in a_list if pred(i)) doesn't really require the full concept of iterators and iterables -- it requires comprehension syntax, and a quick "next() gives you the next item in an 'iterator' and an 'iterator' is something you can put in a for loop." -- yes, that leaves out all kinds of important details, but gets the job done for now. In fact, in my intro class, I've used "how to get the first item from a thing" as my first introduction to next() :-) 2. If you want to operate on a sublist, you have to teach them about > slicing, so you can introduce itertools.islice, rather than just say > "give the start and end positions as arguments". > hmm -- a great reason to provide an easily accessible "lazy" slice -- like the sequence view proposal recently discussed (and waiting for me to flesh out ...) > 3. If you need the index instead of the value, using filter becomes > downwrite obfuscated: > > next(filter(lambda t: pred(t[1]), enumerate(iterable)))[0] > indeed. but how often DO people need the index? I suspect many uses of .index() are used to then get the object anyway. And I'm not sure it's THAT obfuscated -- we teach folks to use enumerate() pretty early as a way to avoid explicitly looping through indexes. We have a simple answer to a simple question: > > "How do I search a list?" > "Use list.index" > > With this proposal, we get: > > "How do I search a list by some key?" > "Use list.index with a key function" > Interestingly, this seems to contradict API design-wise, what's been pushed on recent threads: * Rather than adding a keyword argument that changes behavior, we should add another function to itertools (or the like) and * rather than add functionality to a built-in (or ABC), we should add utility functions that can act on many related types Granted, this is not a flag (neither boolean, ternary or mode-switching), and it's not a new method, but the API principles may still apply. In particular, a function in itertools would have a lot more utility for various iterables, rather than just lists (or the /sequence ABC?) -CHB -- Christopher Barker, PhD 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/KU27MEEYBIBWIJOOLTCSIFJWH5RW6YOP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Enhance list.index with a comparison function
On Saturday, May 23, 2020, at 11:02 -0400, David Mertz wrote: > Still, generator comprehension are great. And next() is an excellent > function. Agreed, on both counts. I often end up needing an arbitrary element of a set (or the only element of a single-element set), and next(iter(set)) scratches that itch well. ___ 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/FQ3H5OEJZOEPVRJ7APTT4EJF2FQZQLBH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Enhance list.index with a comparison function
On Sat, May 23, 2020, 10:54 AM Rob Cliffe via Python-ideas > index_of(needle, haystack, key=func) > > Sounds like a list comprehension: [ needle for needle in haystack if > func(needle) ] > The times it doesn't sound like a list comprehension is when you have a million items in the list, 100k of which match the predicate, but you only care about the first one... Or even just the first ten. Still, generator comprehension are great. And next() is an excellent function. ___ 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/2ZQR3HMRLIPSOAAK7GJQBJX6MQLUEIKD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Enhance list.index with a comparison function
On 23/05/2020 05:48, David Mertz wrote: On Sat, May 23, 2020, 12:26 AM Steven D'Aprano Obviously not all such key functions are that simple and you may need to write a helper function, but the same applies to filter. I like the key function much better than the predicate. In large part that's because as soon as you say predicate, I think filter. Particularly if I care about laziness in not looking through extra items. If you wanted everything matching a predicate, using a comprehension just seems more obvious. It could be lazy with a generator comprehension, not them you need next() to get the first. Key= has the obvious parallel with sorted() and friends. Even then, a function similar to sorted() feels more general than a method on lists only. I.e. index_of(needle, haystack, key=func) I'm not sure where that would live exactly, maybe itertools. I think you were on my side in believing an import from standard library is not a huge burden. I think if such a function existed, I'd want another argument to match n != 1 results. But then it gets ugly because one index is an integer, and multiple indices are some sort of collection. Sounds like a list comprehension: [ needle for needle in haystack if func(needle) ] So maybe one is best... ___ 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/W24RTDL4VHKNDMLVMRO6CB3V2AT544XP/ 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/JJIE4L722CUGQF5ACIHT65L6YCJLZYWI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
On 5/23/2020 8:52 AM, Stephen J. Turnbull wrote: > Executive summary: > > I'd like to make three points. > > 1. Accessibility matters, and I think this change would be > inaccessible to users of screen readers. > 2. Yes, a variety of tools imposes a burden, but also confers > benefits. > 3. There's no such thing as "pretty source code." There are only > tools that display source code beautifully. > > Down and dirty details: > > The first is new to this discussion: > > Let's not make life more annoying for the accessibility developers and > the people who *need* accessibility accommodations. Not all visual > puns are audible puns. "→" looks like "->", but "Unicode U+2192 > RIGHTWARDS ARROW" sounds nothing like "HYPHEN GREATER-THAN". (I'm > guessing at the pronunciation, I don't use a screen reader myself. > OK, probably the reader just says "RIGHTWARDS ARROW" or even > "RIGHTARROW", but it's still not close to the same.) Microsoft Narrator totally skips → when I got it to read the subject line on this email (Result: "I'd like to suggest allowing unicode as an alternative to 'dash'"). There might be other screen readers that work better, but I agree that this would increase inaccessibility. --Edwin ___ 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/2SZG2GVHGTMVPDZXFWWC6D2VVSZZ7XBP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Optional keyword arguments
On Sat, May 23, 2020 at 2:52 PM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Alex Hall writes: > > > In all cases it's not immediately clear what the actual default value > is, > > or even what kind of object is meant to be passed to that parameter. > > I agree with the basic principle, but I'm not sure this is a very > strong argument. First, if you want to indicate what the type of the > actual argument should be, we have annotations for that exact purpose. Yes, but many people can't be bothered to write annotations. This change would mean that I get extra type information even when using a function written by a programmer making as little effort as they can. Besides that, type annotations are often not easy to read - see the StreamHandler screenshot. An example of an acceptable value is additionally helpful. ___ 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/EGNNAUJGHWM2P6UGJMHQFLPKMWWOWF5N/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Optional keyword arguments
Alex Hall writes:
> In all cases it's not immediately clear what the actual default value is,
> or even what kind of object is meant to be passed to that parameter.
I agree with the basic principle, but I'm not sure this is a very
strong argument. First, if you want to indicate what the type of the
actual argument should be, we have annotations for that exact purpose.
(Granted, these don't deal with situations like "should be nonempty,"
see below.) Second, in many cases the default value corresponding to
None is the obvious mutable falsey: an empty dict or list or whatever.
Viz:
> ```
> ChainMap.new_child(m={})
> StreamHandler(stream=sys.stderr)
> json.dump(..., cls=JSONEncoder, ...)
> ```
>
> In the case of json.dump, I don't know why that isn't already the
> signature, does anyone know?
Assuming that in many other cases we could fix the signature in this
way, are the leftovers like StreamHandler important enough to justify
a syntax change? I have no opinion on that, it's a real question.
> The point is that the signature now conveys the default as well as
> the type of the parameter,
Except that it doesn't convey the type in a Pythonic way. How much of
the API of dict must 'm' provide to be acceptable to ChainMap? Are
there any optional APIs (i.e., APIs that dict doesn't have but
ChainMap would use if available) that must have correct semantics or
ChainMap goes "BOOM!"? Are non-empty mappings acceptable?!
This doesn't change my lack of opinion. :-) Clearly, it's useful to
know that dicts (probably including non-empty ones ;-) are acceptable
to new_child, that sys.std* output streams are (probably ;-) acceptable
to StreamHandler, and that cls should (probably ;-) encode Python data
to JSON. Those are all good enough bets that I would take them. But
it isn't as big a help as it looks on first sight, in particular to
somebody who has a partially duck-type-compatible object they would
like to use.
___
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/FFGCR4CQX3I3L77FSIP67ZE5AVE4ZKNT/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python tagged unions based on dataclasses
Paul Sokolovsky writes: > Andrey Cizov wrote: > > Sorry I forgot to add the URL: > > https://pypi.org/project/tagged-dataclasses/ > As a quick comment, looks verbose comparing to ML ;-). Do you mean ML, the language? ___ 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/2XMTW57SEB4O4EXDLGITZK4YV64CFJ7Z/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
Executive summary: I'd like to make three points. 1. Accessibility matters, and I think this change would be inaccessible to users of screen readers. 2. Yes, a variety of tools imposes a burden, but also confers benefits. 3. There's no such thing as "pretty source code." There are only tools that display source code beautifully. Down and dirty details: The first is new to this discussion: Let's not make life more annoying for the accessibility developers and the people who *need* accessibility accommodations. Not all visual puns are audible puns. "→" looks like "->", but "Unicode U+2192 RIGHTWARDS ARROW" sounds nothing like "HYPHEN GREATER-THAN". (I'm guessing at the pronunciation, I don't use a screen reader myself. OK, probably the reader just says "RIGHTWARDS ARROW" or even "RIGHTARROW", but it's still not close to the same.) At the very least, we should do a case-by-case check when we want to pun this way, and also ask an accessibility expert (better three) about whether screen readers make this connection, and if not, whether their users would be able to. Second, about Tower-of-Babelonian tool proliferation: Thierry Parmentelat writes: > people need to mess with solutions on the outside sphere - editors, > IDE’s, documentation post-processing - that essentially have no > chance to be sustainable, and/as it causes extra burden for > everybody This situation that has no chance to be sustainable obviously *is* sustainable. It's been this way for as long as I've been using computers (daily use for work or study since 1979). I very much doubt it is going to change, ever, because tools are personal. Yes, it causes a certain amount of burden for everybody, but it also provides great benefits for everybody, or network externalities would impel us to accept a common set of tools. > We should allow code to be natively pretty, and not rely on other > tools to do the prettifying job - or not There's no such thing as code being "natively pretty". Code (source code) is a sequence of bits grouped into bytes grouped into characters grouped into statements grouped into a file. I can't see the pits on a BD or the microwaves in a wireless connection, and I doubt you can. There are software tools doing a prettifying job every time source code is displayed, printed, or read out loud, and a mass audience language like Python needs to adapt to the tools of the mass audience. Yes, we humans can help relatively "dumb" tools do a better job of displaying pretty code (for example, "significant whitespace"), but it's the quality of tool that matters most. Fred Brooks had a good essay on "sharp tools", slightly off-point, in *The Mythical Man-Month*. (I'm pretty sure of the citation but unfortunately my copies of MMM are all at school for access by my students. :-) He advocated having a tool-building specialist on his "surgical team" of (proprietary) developers, but in the open source world, we all publish our tools, which is both the glory and the disaster of something like Emacs. There are also habits that won't change -- even if *you* habitually use one of the many right arrows in Unicode instead of "->", most of us will continue to touch-type "->", and you're going to have to read it. And code is eternal: 20 years from now, somebody's going to be upset about some misfeature in the stdlib, and they're going to have to read it. (Well, maybe not "->", depends on whether they need to look at the stub files, which is a "probably not", stub files are more useful to the Python compiler than to humans most of the time.) If you want all your Python code to use non-ASCII characters in the syntax whether you wrote it or not, *your tools will have to do it for you*. Steve ___ 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/RQORZK7MMUCXJAJEDMFIF2CQRMT5LFTW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python tagged unions based on dataclasses
Most of the prior art to this tries to take too much from other languages
(e.g. using match as you show here).
For example they create their own DSL for matching that either introduces
the magic function for matching, which doesn’t completely support Python
classes (e.g what if I want my tagged union to also have methods?).
I am not completely against the compactness of ML - however ML approaches
usually imply either heavy customisation or support from the language
itself.
So I view my implementation as a pragmatic approach to implementing
fully-featured tagged unions today:
- support introspection in PyCharm
- typecheckable with mypy
- you can subclass from them
- clear semantics
It’s also super-lightweight!
On Fri, 22 May 2020 at 23:03, Paul Sokolovsky wrote:
> Hello,
>
> On Fri, 22 May 2020 21:01:03 +0100
> Andrey Cizov wrote:
>
> > Sorry I forgot to add the URL:
> > https://pypi.org/project/tagged-dataclasses/
>
> How does this compare with many other implementations spread over the
> interwebs?
>
> As a quick comment, looks verbose comparing to ML ;-).
>
> For comparison, I found an algebraic2.py in ~/my-python-hacks/, no
> dataclasses or particular IDEs involved:
>
> --
> from collections import namedtuple
>
> # Ideal syntax:
> #
> #Type = (
> #Int(i: int) |
> #Str(s: str) |
> #Plus(l: Type, r: Type)
> #)
>
> def V(name, **args):
> return namedtuple(name, args.keys())
>
>
> class Union:
>
> def __init__(self, *variants):
> self.variants = list(variants)
>
> def add(self, *variants):
> self.variants.extend(variants)
>
> def __instancecheck__(self, inst):
> return isinstance(inst, tuple(self.variants))
>
>
> def match(val, typ):
> if isinstance(val, typ):
> # Have to return scalar instead of a tuple due to CPython
> # deficiency with := operator
> return val[0]
> --
>
>
> Can be used as:
>
> --
> UnaryExpr = Union(
> Int := V("Int", i=int),
> Str := V("Str", s=str),
> )
>
> # Recursive variants should be added after initial definition
> UnaryExpr.add(
> Inc := V("Inc", e=UnaryExpr),
> Dec := V("Dec", e=UnaryExpr),
> )
>
>
> def eval(var: UnaryExpr):
> if i := match(var, Int):
> return i
> elif s := match(var, Str):
> return s
> elif e := match(var, Inc):
> return eval(e) + 1
> elif e := match(var, Dec):
> return eval(e) - 1
>
>
> expr = Dec(Int(123))
> print(isinstance(expr, UnaryExpr))
> print(eval(expr))
> --
>
> It's sad "UnaryExpr" (instead of e.g. BinaryExpr) because of a known
> deficiency of CPython:
>
> ---
> $ python3.8 -c "( (a, b) := (1, 2) )"
> File "", line 1
> SyntaxError: cannot use assignment expressions with tuple
> ---
>
> Btw, does anybody know a Python implementation which has this bug
> fixed?
>
>
> >
> > On Fri, 22 May 2020 at 20:25, Andrey Cizov wrote:
> >
> > > I have developed a library to introduce tagged unions to python
> > > that uses dataclasses to define disjoint members of the tagged
> > > union (by defining them as Optional fields). With some additional
> > > validation I make sure that only one of the fields is not None.
> > >
> > > I find that it also fits well with the existing analysis tools and
> > > IDEs (e.g. PyCharm) and doesn’t require any additional work in
> > > order to be supported.
> > >
> > > I would like to see some criticism and whether that could
> > > potentially be a good candidate for python standard library in the
> > > future.
>
> []
>
> --
> Best regards,
> Paul mailto:pmis...@gmail.com
>
--
Andrey Cizov
___
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/VDU54VW3HZ2OVMS72FJODBHP2XNAZ4UW/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
On 22/05/2020 20:40, Steven D'Aprano wrote: Imagine the confusion if somebody had variables spam, Spam, sPAM, SPam, sPAm. Or worse, SPΑM, SPАM and SPAM. Randall is way ahead of you. https://xkcd.com/2309/ :-) -- Rhodri James *-* Kynesim Ltd ___ 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/RD26H7FMPTKUAYZWG6DJRLVG2SIMNJEU/ Code of Conduct: http://python.org/psf/codeofconduct/
