[Python-ideas] Re: built in to clear terminal
On Sat, Dec 19, 2020 at 7:43 PM Steven D'Aprano wrote: > Thread is here: > > > https://mail.python.org/archives/list/python-ideas@python.org/message/EWQ2BOL3WVZAU2V2MT3HLXN3AEBHANNZ/ > > > I don't think this needs to be a literal built-in, part of the > interpreter. I think it could be a library function which is added to > builtins on startup, like `help` and `quit`. > That sounds like a very special status. Why not os.clear()? I do agree with the motivation for doing this. (I've started doing more exploratory programming and I've felt this need clearly a few times.) I can't comment on the exact semantics or implementation (though I'd prefer it if it didn't have to run a subprocess). IDLE should probably monkey-patch this so it does something reasonable in its shell window. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/7GSOBZSOK57GMT43UQ5TBTAANIKROCLF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add aggregations and joins code-generating library along with itertools
Dear Nikita, I'm sorry to squash your idea, but I don't think your library is mature enough to be considered for inclusion in the standard library. May 2021 be an improvement upon 2020, --Guido On Sun, Dec 27, 2020 at 7:04 AM Nikita Almakov wrote: > Hello everyone! > > The idea: it would be cool to have the functionality of "convtools" > library available along with "itertools". > Python should provide decent functionality of aggregations and joins > out-of-the-box. > > Given that named tuples generate some could, this one could too: > https://pypi.org/project/convtools/ > https://convtools.readthedocs.io/en/latest/cheatsheet.html > https://github.com/iTechArt/convtools > > Please, let me know your view on this or any ideas (I would appreciate it). > > Thank you and happy holidays! > Nikita Almakov > ___ > 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/PP6HREMDLPMACAPIYQR3HD73UTHKGCLL/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/QHF5CKCZLKJ7SXARJ7INKFMDOSQXLLBR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: asyncio.Pipe()
The asyncio module already has a subprocess support: Subprocesses — Python 3.9.1 documentation <https://docs.python.org/3/library/asyncio-subprocess.html> Was that not sufficient to solve your problem? On Mon, Dec 28, 2020 at 5:23 AM Roger Iyengar wrote: > I believe that asyncio should have a way to wait for input from a > different process without blocking the event loop. > > The Asyncio module currently contains a Queue class that allows > communication between multiple coroutines running on the same event loop. > However, this module is not threadsafe or process-safe. > > The multiprocessing module contains Queue and Pipe classes that allow > inter-process communication, but there's no way to directly read from these > objects without blocking the event loop. > > I propose adding a Pipe class to asyncio, that is process-safe and can be > read from without blocking the event loop. This was discussed a bit here: > https://github.com/python/cpython/pull/20882#issuecomment-683463367 > > This could be implemented using the multiprocessing.Pipe > class. multiprocessing.connection.Connection.fileno() returns the file > descriptor used by a pipe. We could then use loop.add_reader() to set > an asyncio.Event when something has been written to the pipe by the other > process. I did this all manually in a project I was working on. However, > this required me to learn a considerable amount about asyncio. It would > have saved me a lot of time if there was an easy documented way to wait for > input from another process in a non-blocking way. > > One compelling use case for this is a server that uses asyncio, which > receives inputs from clients, then sends these to another process that runs > a neural network. The server then sends the client a result after the > neural network finishes. ProcessPoolExecutor does not seem like a good fit > for this use case, because the process needs to stay alive and be re-used > for subsequent requests. Starting a new process for each request is > impractical, because loading the neural network into GPU memory is an > expensive operation. See here for an example of such a server (however this > one is mostly written in C++ and does not asyncio): > https://www.tensorflow.org/tfx/guide/serving > ___ > 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/2YTRR3QUFJ66MOJKVUQXAVPBY4AKB4PX/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/2HH6R3T5ME5QW3LHELC5F4YSUSPWSBVF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: asyncio.Pipe()
Okay, fair. I am guessing that the first step would be to create a quality implementation and publish it on PyPI. And of course this begs the question, *who* is going to do the work? [ducks] On Mon, Dec 28, 2020 at 10:27 AM Roger Iyengar wrote: > It was not sufficient. The only way to communicate with a Subprocesses is > using stdout, stdin and stderr. However, packages like Tensroflow will > print messages to stdout, and this can be hard to turn off. > > It seems useful to have a class like multiprocessing.Pipe to communicate > with another process, separately from stdout/stdin. > > On Mon, Dec 28, 2020 at 12:50 PM Guido van Rossum > wrote: > >> The asyncio module already has a subprocess support: Subprocesses — >> Python 3.9.1 documentation >> <https://docs.python.org/3/library/asyncio-subprocess.html> >> >> Was that not sufficient to solve your problem? >> >> >> On Mon, Dec 28, 2020 at 5:23 AM Roger Iyengar >> wrote: >> >>> I believe that asyncio should have a way to wait for input from a >>> different process without blocking the event loop. >>> >>> The Asyncio module currently contains a Queue class that allows >>> communication between multiple coroutines running on the same event loop. >>> However, this module is not threadsafe or process-safe. >>> >>> The multiprocessing module contains Queue and Pipe classes that allow >>> inter-process communication, but there's no way to directly read from these >>> objects without blocking the event loop. >>> >>> I propose adding a Pipe class to asyncio, that is process-safe and can >>> be read from without blocking the event loop. This was discussed a bit >>> here: >>> https://github.com/python/cpython/pull/20882#issuecomment-683463367 >>> >>> This could be implemented using the multiprocessing.Pipe >>> class. multiprocessing.connection.Connection.fileno() returns the file >>> descriptor used by a pipe. We could then use loop.add_reader() to set >>> an asyncio.Event when something has been written to the pipe by the other >>> process. I did this all manually in a project I was working on. However, >>> this required me to learn a considerable amount about asyncio. It would >>> have saved me a lot of time if there was an easy documented way to wait for >>> input from another process in a non-blocking way. >>> >>> One compelling use case for this is a server that uses asyncio, which >>> receives inputs from clients, then sends these to another process that runs >>> a neural network. The server then sends the client a result after the >>> neural network finishes. ProcessPoolExecutor does not seem like a good fit >>> for this use case, because the process needs to stay alive and be re-used >>> for subsequent requests. Starting a new process for each request is >>> impractical, because loading the neural network into GPU memory is an >>> expensive operation. See here for an example of such a server (however this >>> one is mostly written in C++ and does not asyncio): >>> https://www.tensorflow.org/tfx/guide/serving >>> ___________ >>> 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/2YTRR3QUFJ66MOJKVUQXAVPBY4AKB4PX/ >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> >> >> -- >> --Guido van Rossum (python.org/~guido) >> *Pronouns: he/him **(why is my pronoun here?)* >> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> >> > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/VXIP4DLEWKJKRT257FIESE4L3QRJK34T/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Unpack operator "**" and Mapping
On Mon, Dec 28, 2020 at 12:15 PM Christopher Barker wrote: > > I don't know about the OP, but all I wanted was a clear definition of the > part of the API needed to support **, and apparently it's a keys() method > that returns an iterator of the keys, and a __getitem__ that then returns > the values associated with those keys. Which is fine. > > Though frankly, I would rather have had it use .items() -- seems more > efficient to me, and you do need both the keys and the values, and items() > is just as much part of the Mapping API as keys. > There may be a (small) performance issue with that -- items() requires creating a tuple object for each key/value pair. Anyway, of course it's too late to change. And there are probably other "protocols" that check for the presence of keys and __getitem__(). Also, in a sense keys() is more fundamental -- deriving keys() from items() would be backwards (throwing away the values -- imagine a data type that stores the values on disk). > But there is an argument that the ** operator should be able to be > supported only with dunder methods -- which could be done if it used the > iterator protocol to get the keys, rather than the keys() method, which > does not appear to work now. though to be fair, all you need to do to get > that is add a __len__ and derive from Mapping. > If we had to do it all over from scratch we would probably design mappings and sequences to be differentiably using dunders only. But it's about 31 years too late for that. And looking at the mess JavaScript made of this (sequences are mappings with string keys "0", "1" and so on), I'm pretty happy with how Python did this. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/3DLPC2DLDTT4Y3NBQHLBIWCMS76CRC56/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Unpack operator "**" and Mapping
On Tue, Dec 29, 2020 at 8:11 AM Steven D'Aprano wrote: > On Mon, Dec 28, 2020 at 11:36:55PM -0800, Christopher Barker wrote: > > > Side Question: when should one use __dict__ vs vars() vs getattr() ??? > all > > three work in this case, but I'm never quite sure which is prefered, and > > why. > > `vars(obj)` is defined as returning `obj.__dict__` so technically it > probably doesn't matter, but I feel that as a matter of aesthetics and > future-proofing, we should avoid direct use of dunders whenever > practical. > To the contrary, vars() is something I added to the language for the benefit of REPL users (like dir()), and other usages look suspect to me. I find that using `__dict__` is more direct about the purpose, and also it is the prevailing style. > Do you prefer to write `mylist.__len__()` over `len(mylist)`? Then you > will probably prefer `obj.__dict__` over `vars(obj)` too :-) > Not a valid analogy. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/YBACDV7JURIR7YUS3JCC6QQYJLBJXQYX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Unpack operator "**" and Mapping
On Mon, Dec 28, 2020 at 11:36 PM Christopher Barker
wrote:
> On Mon, Dec 28, 2020 at 12:33 PM Guido van Rossum
> wrote:
>
>> On Mon, Dec 28, 2020 at 12:15 PM Christopher Barker
>> wrote:
>>
>>> Though frankly, I would rather have had it use .items() -- seems more
>>> efficient to me, and you do need both the keys and the values, and items()
>>> is just as much part of the Mapping API as keys.
>>>
>>
>> There may be a (small) performance issue with that -- items() requires
>> creating a tuple object for each key/value pair.
>>
>
> it does look like items() is a tad faster (dict with 1000 items), but not
> enough to matter:
>
> In [61]: %timeit {k: d[k] for k in d.keys()}
> 112 µs ± 1.02 µs per loop (mean ± std. dev. of 7 runs, 1 loops each)
>
> In [62]: %timeit {k: v for k, v in d.items()}
> 92.6 µs ± 1.9 µs per loop (mean ± std. dev. of 7 runs, 1 loops each)
>
Interesting -- thanks for taking up the challenge. I still suspect that if
we ran the corresponding benchmark at the C level, the first form would
win, but it's a matter of hashing twice vs. creating a tuple -- both of
which have the wazoo optimized out of them so it could go either way. There
are many surprises possible here (e.g. long ago someone found that
`s.startswith('x')` is slower than `s[:1] == 'x'` and the reason is the
name lookup for `startswith`!).
> Anyway, of course it's too late to change. And there are probably other
>> "protocols" that check for the presence of keys and __getitem__(). Also, in
>> a sense keys() is more fundamental -- deriving keys() from items() would be
>> backwards (throwing away the values -- imagine a data type that stores the
>> values on disk).
>>
>
> Does there need to be a single defined "protocol" for a mapping (other
> than the ABC)? -- that is, would **unpacking be able to use .items() and
> keys() be used in other contexts?
>
> And why does ** unpacking need to check at all (LBYL) couldn't it simply
> do something like:
>
> {k: d[k] for k in d}
>
> sure, there could occasionally be a Sequence for which that would happen
> to work (like a range object for instance), but then it would be
> unlikely to result in the expected result anyway -- just like many other
> uses of Duck typing. Or not, and it could still be correct.
>
I don't understand why LBYL is considered such an anti-pattern. It helps
produce much clearer error messages in this case for users who are
exploring this feature, and distinguishing *early* between sequences and
mappings is important for that. Long ago we decided that the distinctive
feature is that mappings have a `keys()` method whereas sequences don't
(and users who add a `keys()` method to a sequence are just asking for
trouble). So that's what we use.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/OQOGANKVMEBWTSPMNMOT7ZKCMLAMRBBU/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: On the history and usage of vars [was Re: Re: Unpack operator "**" and Mapping]
On Wed, Dec 30, 2020 at 5:01 PM Steven D'Aprano wrote:
> On Tue, Dec 29, 2020 at 09:02:10AM -0800, Guido van Rossum wrote:
> > On Tue, Dec 29, 2020 at 8:11 AM Steven D'Aprano
> wrote:
>
> > To the contrary, vars() is something I added to the language for the
> > benefit of REPL users (like dir()), and other usages look suspect to me.
> I
> > find that using `__dict__` is more direct about the purpose, and also it
> is
> > the prevailing style.
>
> I cannot argue with your historical perspective on this, and I agree
> that `vars()` is not as well known as I believe it should be.
>
> So you are right on the bare facts. I still think you are wrong on the
> aesthetics :-)
>
> Your comment also shines some light on why `vars()` with no argument
> returns `locals()`, which otherwise seems strange to me.
>
This is the first hint that vars() is not what it seems.
Nevertheless, I have to ask what could possibly be "suspect" about using
> vars() programmatically? It isn't like dir().
>
But it is dir()'s cousin, and the fact that its meaning hasn't changed
doesn't mean they couldn't: Christopher Barker is already asking for such a
change. This is the second hint.
> dir() is certainly a convenience function for interactive use, and is
> documented as returning "the most relevant, rather than complete,
> information".
>
> This note is repeated again later in the docs: "Because dir() is
> supplied primarily as a convenience for use at an interactive prompt, it
> tries to supply an interesting set of names more than it tries to supply
> a rigorously or consistently defined set of names, and its detailed
> behavior may change across releases."
>
> On the other hand, `vars()` has no such warnings. There's no wiggle-
> room: it either returns the instance `__dict__` or it raises TypeError.
> So aside from the difference in exceptions (AttributeError versus
> TypeError) I don't think that there is any possible difference between
> direct attribute access and the output of vars(). Am I wrong?
>
That's just because vars() didn't turn out to be so useful, or perhaps
because people didn't think of improving it when dir() was improved. I
suspect that if you look at the original docs, dir() and vars() had pretty
similar documentation. (And according to PEP 361, `__dir__` was originally
added in 3.0 -- though it seems to have been backported to 2.x at some
point.)
> Speaking of slots, I've often been annoyed that there is no abstraction
> that hides the difference between instances that use a dict as symbol
> table, and those that use slots. (And those that use both.) If you need
> an object's symbol table, for introspection or otherwise, you're out of
> luck if it uses slots.
>
> There doesn't seem to be any way to handle these two implementations in
> the same way, and objects with both slots and a dict can give surprising
> results if naive code expects `__dict__` to be the symbol table:
>
>
> >>> class A:
> ... __slots__ = ('spam', '__dict__')
> ...
> >>> obj = A()
> >>> obj.spam = True
> >>> 'spam' in obj.__dict__
> False
> >>> obj.__dict__.update(spam=False)
> >>> obj.spam
> True
>
>
> So there's no way to get an object's symbol table in an implementation-
> independent way. Whether you use `obj.__dict__` or `vars(obj)` it only
> gives you the symbol table for objects that use a dict. There's nothing
> that works for objects that use slots.
>
> So far I've worked around this in an ad-hoc fashion by testing for
> `__slots__` and treating that case as special, but it would be nice to
> ignore the implementation details and just have a "symbol table" object
> to work with. What do you think?
>
That you're providing an excellent argument to evolve vars() independently
from `__dict__`. :-)
> > > Do you prefer to write `mylist.__len__()` over `len(mylist)`? Then you
> > > will probably prefer `obj.__dict__` over `vars(obj)` too :-)
> >
> > Not a valid analogy.
>
> I think it is. Apart from a matter of taste, what part of the analogy
> do you feel is invalid?
>
len() is an important abstraction for containers, and its usage deserves a
short name (just like unary minus and abs() for numbers). This is crucial
even though you have to use its "true name" (https://xkcd.com/2381/) to
define the implementation for a particular class.
OTOH, `__dict__` is the opposite of an abstraction -- whether you spell it
vars(x) or `x.__dict__`, the matter remains that you're looking inside the
implementation of the object, and
[Python-ideas] Re: A PEP to encourage people to mind docstrings in stub files
How do we avoid having the docstrings in two places? Large communities (e.g. Jupyter notebook and IPython users) rely on docstrings available at runtime. There should be a tool to update the docstrings in stubs before I could recommend duplicating them there. Even for stubs corresponding to extension modules we would need such a tool, since those also typically expose docstrings (defined in the C code) at runtime. On Fri, Jan 1, 2021 at 7:11 AM wrote: > Alexey Volobuev wrote: > > Sometimes you have to put docstrings in stub files e.g. when using code > > generation. In that case, stubs are the only place you can locate > "objects" > > to add docstrings to. > > Thus it is frustrating to find that docstring-related software generally > > tends to ignore the presence of docstrings in stubs or to work > incorrectly > > with those. > > I think we need a PEP to clarify the interaction between stubs and > > docstrings. This PEP might also encourage developers of docstring-related > > software to mind docstrings provided with stub files. > > Not having docstrings in type stubs is one of the small frustrations I > have when working with Python. When working with combined Python/Typescript > projects in PyCharm, I often find myself hitting Ctrl-B to jump to the > definition of third-party JavaScript functions. This takes me to the > appropriate *.d.ts file, which is JavaScript's equivalent of Python stubs > files. But they also include JSDoc comments. I often wish I could do the > same in Python. > > In my ideal world, every Python package (as well as the stdlib) would ship > with stubs files that describe the package's public API, both for machine > and human consumption. This could be automatically generated on build time > from the sources, or it could be hand-crafted. This means, including types > and docstrings. I also thing that providing the actual default, like Eric > Traut suggested, would be a good 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/PPXVKIH7PZCSBB73PMVSMDWGFXPBUPBA/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/IUJC2BT3LSEY3XKZFKBG7U3JUAET5M5Z/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Making TYPE_CHECKING builtin.
That's a mypy-specific hack, not something that's guaranteed by a PEP -- but it works great with mypy! On Mon, Jan 18, 2021 at 4:40 PM Brandt Bucher wrote: > Doesn't explicitly setting it yourself still work? > > ``` > TYPE_CHECKING = False > > if TYPE_CHECKING: > import xxx # modules used only in type hints. > ``` > > This seems to work for mypy, at least. Even just doing `if False:` works > correctly (and is arguably the most efficient at runtime). > ___ > 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/P5W5ETPGVXN47OW27RICUQQRJZCBVFKQ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/COTZHISICAU52HMMV7HOVA37OYGGK6GJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding `open_text()` builtin function. (relating to PEP 597)
I have definitely seen BOMs written by Notepad on Windows 10. Why can’t the future be that open() in text mode guesses the encoding? -- --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/FCIMN3PSTAZT4ST3FH3QALGBH5H5IA6P/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding `open_text()` builtin function. (relating to PEP 597)
On Mon, Jan 25, 2021 at 4:42 PM Steven D'Aprano wrote: > On Sat, Jan 23, 2021 at 09:11:27PM +1100, Chris Angelico wrote: > > > > On the other hand, if we add `open_text()`: > > > > > > * Replacing open with open_text is easier than adding `, > encoding="utf-8"`. > > > * Teachers can teach to use `open_text` to open text files. Students > > > can use "utf-8" by default without knowing about what encoding is. > > > > > > So `open_text()` can provide better developer experience, without > > > waiting 10 years. > > > > But this has a far worse end goal - two open functions with subtly > > incompatible defaults, and a big question of "why should I choose this > > over that". > > It has an easy answer: > > - Are you opening a text file and you don't know about or want to deal > with encodings? Use `open_text`. > > - Otherwise, use `open`. > > I think that if we moved to an open_text() builtin, it should have the > simplest possible signature: > > open_text(filename, mode='r') > > If you care about anything beyond that, use `open`. > > > > And if you start using open_text, suddenly your code won't > > work on older Pythons. > > "Using older Pythons" is mostly a concern for library maintainers, not > beginners. A few years from now, Python 3.10 will be the oldest version > the great majority of beginners will care about, and 3.9 will be as > irrelevant to them as 3.4 is to us today. > > Library maintainers always have to deal with the issue of not being able > to use the newest functionality, it doesn't prevent us from adding new > functionality. > Older Pythons may be easy to drop, but I'm not so sure about older unofficial docs. The open() function is very popular and there must be millions of blog posts with examples using it, most of them reading text files (written by bloggers naive in Python but good at SEO). I would be very sad if the official recommendation had to become "[for the most common case] avoid open(filename), use open_text(filename)". BTW remind me what open_text() would do? How would it differ from open() with the same arguments? That's too many messages back. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/QPKA3SOCHMFMGZXW7YBCTSDMVQ6B6BHW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding `open_text()` builtin function. (relating to PEP 597)
On Mon, Jan 25, 2021 at 5:49 PM Inada Naoki wrote: > On Tue, Jan 26, 2021 at 10:22 AM Guido van Rossum > wrote: > > > > > > Older Pythons may be easy to drop, but I'm not so sure about older > unofficial docs. The open() function is very popular and there must be > millions of blog posts with examples using it, most of them reading text > files (written by bloggers naive in Python but good at SEO). > > > > I would be very sad if the official recommendation had to become "[for > the most common case] avoid open(filename), use open_text(filename)". > > > > I agree that. But until we switch to the default encoding of open(), > we must recommend to avoid `open(filename)` anyway. > The default encoding of VS Code, Atom, Notepad is already UTF-8. > > Maybe, we need to update the tutorial (*) to use `encoding="utf-8"`. > Telling people to always add `encoding='utf8'` makes much more sense to me than introducing a new function and telling them to do that. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/ZT66Q2UMDYJBOKM7GAMTLTPIXFVXZMBG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Provide UTF-8 version of Python for Windows.
Aren't there too many different Windows installers already? I worry that it's too hard to choose which one to use (I know I had to ask another expert :-). On Mon, Jan 25, 2021 at 7:05 PM Inada Naoki wrote: > Sorry for posting multiple threads so quickly. > > Microsoft provides UTF-8 code page for process. It can be enabled by > manifest file. > > https://docs.microsoft.com/ja-jp/windows/uwp/design/globalizing/use-utf8-code-page > > How about providing Python binaris both of "UTF-8 version" and "ANSI > version"? > This idea can provide a more smooth transition of the default encoding. > > 1. Provide UTF-8 version since Python 3.10 > 2. (Some years later) Recommend UTF-8 version > 3. (Some years later) Provide only UTF-8 version > 4. (Some years later, maybe) Change the default encoding > > The upsides of this idea are: > > * We don't need to emit a warning for `open(filename)`. > * We can see the download stats. > > Especially, the last point is a huge advantage compared to current > UTF-8 mode (e.g. PYTHONUTF8=1). > We can know how many users need legacy behavior in new Python > versions. That is a very important information for us. > > Of course, there are some downsides: > > * Windows team needs to maintain more versions. > * More divisions for "Python on Windows" environment. > > Regards, > -- > Inada Naoki > ___ > 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/KMYPF7RKDUHHXLPELA2RZC7TSPUWSHNU/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/MNVQWQEYUYKLIQOXVOFLFOPWY63QRLXN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Questions about using PEP 637 syntax in PEP 646
On Fri, Jan 29, 2021 at 2:28 AM Stefano Borini wrote: > On Tue, 19 Jan 2021 at 13:51, wrote: > > > > Hello, > > > > This is a great PEP. It turns out to be applicable in a variety of > scenarios. > > > > Case in point: Matthew Rahtz and I are working on PEP 646: Variadic > Generics (https://www.python.org/dev/peps/pep-0646/; discussion on > typing-sig). It is a type system feature that allows specifying an > arbitrary tuple of type variables instead of a single type variable. > > > > We plan to use your proposed syntax to represent unpacking a tuple type. > This would be analogous to `*` for unpacking a tuple value: > > > > + `Tensor[int, *Ts, str]` and `Tensor[*Ts1, *Ts2]` > > + such variadic classes would be declared as `class Tensor(Generic[T, > *Ts, T2]):` > > > > Questions: > > > > 1. Does PEP 637 support unpacking multiple `*` arguments? > >- e.g., Tensor[int, *Ts, str, *Ts2] > > > Yes, technically yes, and it does in our experimental branch. > > _but_ > > Brandt and I are unsure about the semantics of it, specifically the > corner case of star unpacking a tuple with one element. The current > PEP says that the following two are equivalent: > > a[1] and a[*(1,)]. (calls __getitem__ with index = 1) > > However, the way it's implemented now, these two are equivalent > > a[1,] and a[*(1,)] (calls __getitem__ with index = (1,)) > > I think we would both love a discussion over it. > I think for PEP 646 it doesn't matter. That PEP is mostly concerned with static checks and the static checker can assign this any meaning it wants as long as it is syntactically allowed. Honestly I think it's fine the way you have implemented it -- since there is a difference between a[1] and a[1,], a[*t] where len(t) == 1 has to make a choice, and it's fine if this always passes a tuple. > > 2. Does PEP 637 allow a positional argument after a `*`? > >- e.g., Generic[T, *Ts, T2] > > Yes. > Excellent. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/TU6DAW7SI4SWCZCWH663VBACZX3HAY4D/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make UTF-8 mode more accessible for Windows users.
Although a file adds I/O slowdown to startup (which is already slow) while an envvar doesn’t. On Thu, Feb 4, 2021 at 13:19 Barry Scott wrote: > > > > On 3 Feb 2021, at 02:49, Christopher Barker wrote: > > > > > Rather than reply point by point I will summarise my input. > > I think that utf-8 mode is a great idea. > > I think that an .INI file in the style that py.exe uses is better then env > var. > > Env var on WIndows could be used but there can be surprises with the way > windows merges user and system env vars. Maybe that only with PATH that > is very odd. > > I'm hoping that the solution implemented allows new users to get a great > experience and also that advanced users can get control of the mode. > > Personally I'd prefer to have files that I edit to configure python then > registry > keys. I can put files into git, not exmple. I have to work hard to manage > registry > keys via git. > > Barry > ___ > 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/N4HV3CM3QAUNZA4XRP2PQTNNR2BV7H2V/ > 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/YTBMBACSVME3QJ5IQUQVJA75V2WEZQJE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Top Level Await in Python like in Deno
The proposal is to add a default event loop that is always active. On Sat, Feb 6, 2021 at 06:41 wrote: > I mean to be able to do something like this: > ```python > import asyncio > > await asyncio.sleep(1); > ``` > -- --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/ATXEJR7GYY2E3B6WGC7Y2G7NL6WWZ33L/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [Python-Dev] What's up with assignment expression and tuples?
Hi Paul,
I suggest that you just go straight to the PEP phase.
--Guido
On Thu, Feb 4, 2021 at 11:54 PM Paul Sokolovsky wrote:
> Hello,
>
> Everyone knows how hard to find a compelling usecase for the assignment
> expression operator (":=", colloquially "walrus operator").
> https://www.python.org/dev/peps/pep-0572/ examples never felt
> compelling and we all remember the split it caused.
>
> I finally found a usecase where *not* using assignment expression is
> *much* worse than using it. I'm working on SSA (Static Single
> Assignment,
> https://en.wikipedia.org/wiki/Static_single_assignment_form) conversion
> of Python programs, where there's a need to "join" dataflow of values
> from different control flow paths using a special function (Phi
> function). This "joining" itself creates a new variable, and of course,
> the original variable was used in an expression. We've got
> assignment in expression, assignment expression operator to the rescue!
>
> With it, a simple loop like:
>
>
> a = 0
> while a < 5:
> a += 1
>
>
> becomes:
>
>
> a0 = 0
> while (a1 := phi(a0, a2)) < 5:
> a2 = a1 + 1
>
>
> So far, so good. But semantics of Phi function is parallel assignment.
> No problem with Python either, "a, b = b, c" is exactly parallel
> assignment. So, let's try example with 2 variables:
>
>
> a = 0
> b = 10
> while a < 5:
> a += 1
> b += 1
>
>
> becomes:
>
>
> a0 = 0
> b0 = 10
> while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5:
> a2 = a1 + 1
> b2 = b1 + 1
>
>
> But oops:
>
> > SyntaxError: cannot use assignment expressions with tuple
>
> To reproduce in the REPL:
>
>
> >>> ((a, b) := (1, 2))
> File "", line 1
> SyntaxError: cannot use assignment expressions with tuple
>
>
> Why this accidental syntactic gap? Why assignment statement can do
> parallel assignment with a tuple on LHS, and assignment operator
> suddenly can't?
>
> Why the adhoc naming and conceptual shift on the AST level, when PEP572
> explicitly talks about *assignment operator*, but corresponding node on
> the AST level is called NamedExpr? Why look at assignment expression as
> "name of expression" instead of assignment expression per se?
>
> It's of course not a problem to recast:
>
> NamedExpr(expr target, expr value)
>
> to
>
> NamedExpr(expr* target, expr value)
>
> in the ASDL (and it works out of the box), the point is that it should
> have been ExprAssign from the start (folloing the AugAssign and
> AnnAssign tradition).
>
>
> --
> Best regards,
> Paul mailto:pmis...@gmail.com
> ___________
> Python-Dev mailing list -- python-...@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-...@python.org/message/6IFDG7PAFPHVPGULANOQDAHP2X743HCE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/CATW4D6SP6ZYHBQYBIXGT7UWJCQ6F2GQ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Type hinting **kwargs
This discussion should probably be held on typing-...@python.org. (Hope you're aware of that list.) I will have to admit that in PEP 484 we screwed up with `*args` and `**kwds` -- we thought that these would always be homogeneous and we thought we'd save the user some time by letting them write `*args: int` instead of `*args: Tuple[int, ...]` (and similar for `**kwds`), but this use case and a few others have shown that we would have been better off with the more verbose syntax. It's too late to change, alas. PEP 646 is one example where we had to twist ourselves into knots to make something work for `*args`. On Sun, Feb 7, 2021 at 9:58 AM Paul Bryan wrote: > I'm encountering a situation where it would be far cleaner to use **kwargs > (multiple functions taking the same set of parameters); I'd like to have > type hints, and avoid repeating multiple function definitions, explicitly > enumerating all parameters for each function definition. > > Therefore, I'd like to have some meaningful type hint for **kwargs. > First, I thought TypedDict would be a great fit, until I found this passage > in PEP 589: > > These features were left out from this PEP, but they are potential > extensions to be added in the future: > ... > TypedDict can't be used for specifying the type of a **kwargs argument. > This would allow restricting the allowed keyword arguments and their types. > According to PEP 484, using a TypedDict type as the type of **kwargs means > that the TypedDict is valid as the value of arbitrary keyword arguments, > but it doesn't restrict which keyword arguments should be allowed. The > syntax **kwargs: Expand[T] has been proposed for this [11]. > ... > [11] https://github.com/python/mypy/issues/4441 > > > In the mypy issue discussion, there seems to be two issues: > > 1. Ambiguity of whether the type hint applies to the **kwargs dict vs. > each value in the dict. I think this could be a red herring; kwargs > presents as a dict and I think TypedDict can unambiguously represent the > structure of that dict. I don't see how it should be different than any > other dict parameter being defined as a function parameter. > > 2. A question of whether one needs to assume that for a TypedDict, the > type validator should assume total=False. I think what keys are required > should be explicitly determined by the TypedDict (required keys inferred > from total). I suspect the issue could be that mypy may not be able to > determine this during static type analysis? > > In summary, **kwargs is a dict; TypedDict can specify its structure; > static type checker limitations should not necessarily restrict its use in > this way. > > Therefore, I propose a short PEP be drafted to codify the validity of > using TypedDict to specify the type of a **kwargs argument. > > Paul > > ___ > 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/F64KJNO7FB4ONPNV5H2EVSJQ5IPU2ECW/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/YIIKR3JWRF6FCPYKBYPVPNC64YD46UFA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [Python-Dev] What's up with assignment expression and tuples?
This was intentional in PEP 572 so it is not a grammar bug fix.
Put your money where your mouth is, or become another armchair language
designer. Your choice.
On Sun, Feb 7, 2021 at 23:58 Paul Sokolovsky wrote:
> Hello,
>
> On Sun, 7 Feb 2021 13:10:55 -0800
> Guido van Rossum wrote:
>
> > Hi Paul,
> >
> > I suggest that you just go straight to the PEP phase.
>
> Thanks. In all fairness, I don't expect immediate resolution to this
> issue. But I'm aware of out for at least a year, and keep returning to
> it (yes, in context of my SSA experiments). So, I proceeded to the next
> stage - bring it up on its own, then created a bug ticket:
> https://bugs.python.org/issue43143
>
> And my idea is to try to argue that it would be just a "grammar
> bugfix", similarly to already existing grammar elaborations for walrus:
>
> https://bugs.python.org/issue42316
> https://bugs.python.org/issue42374
> https://bugs.python.org/issue42381
>
> Granted, allowing "foo((a, b) := (b, a))" is a bit bigger change than
> allowing "foo[a := b]" instead of "foo[(a := b)]". But if people
> find assigning within index expression useful, up to reporting it, and
> then other people ack it and fix it, then why not fix parallel
> assignment case? Implementation-wise they *seem* to be of the
> similar effort/complexity - just a one-term grammar change. (I still
> need to run the testsuite, yeah).
>
>
> >
> > --Guido
> >
> > On Thu, Feb 4, 2021 at 11:54 PM Paul Sokolovsky
> > wrote:
> >
> > > Hello,
> > >
> > > Everyone knows how hard to find a compelling usecase for the
> > > assignment expression operator (":=", colloquially "walrus
> > > operator"). https://www.python.org/dev/peps/pep-0572/ examples
> > > never felt compelling and we all remember the split it caused.
> > >
> > > I finally found a usecase where *not* using assignment expression is
> > > *much* worse than using it. I'm working on SSA (Static Single
> > > Assignment,
> > > https://en.wikipedia.org/wiki/Static_single_assignment_form)
> > > conversion of Python programs, where there's a need to "join"
> > > dataflow of values from different control flow paths using a
> > > special function (Phi function). This "joining" itself creates a
> > > new variable, and of course, the original variable was used in an
> > > expression. We've got assignment in expression, assignment
> > > expression operator to the rescue!
> > >
> > > With it, a simple loop like:
> > >
> > >
> > > a = 0
> > > while a < 5:
> > > a += 1
> > >
> > >
> > > becomes:
> > >
> > >
> > > a0 = 0
> > > while (a1 := phi(a0, a2)) < 5:
> > > a2 = a1 + 1
> > >
> > >
> > > So far, so good. But semantics of Phi function is parallel
> > > assignment. No problem with Python either, "a, b = b, c" is exactly
> > > parallel assignment. So, let's try example with 2 variables:
> > >
> > >
> > > a = 0
> > > b = 10
> > > while a < 5:
> > > a += 1
> > > b += 1
> > >
> > >
> > > becomes:
> > >
> > >
> > > a0 = 0
> > > b0 = 10
> > > while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5:
> > > a2 = a1 + 1
> > > b2 = b1 + 1
> > >
> > >
> > > But oops:
> > >
> > > > SyntaxError: cannot use assignment expressions with tuple
> > >
> > > To reproduce in the REPL:
> > >
> > >
> > > >>> ((a, b) := (1, 2))
> > > File "", line 1
> > > SyntaxError: cannot use assignment expressions with tuple
> > >
> > >
> > > Why this accidental syntactic gap? Why assignment statement can do
> > > parallel assignment with a tuple on LHS, and assignment operator
> > > suddenly can't?
> > >
> > > Why the adhoc naming and conceptual shift on the AST level, when
> > > PEP572 explicitly talks about *assignment operator*, but
> > > corresponding node on the AST level is called NamedExpr? Why look
> > > at assignment expression as "name of expression" instead of
> > > assignment expression per se?
> > >
> > > It's of course not a problem to recast:
> > >
> >
[Python-ideas] Re: Generic NamedTuples
Did you bring this up on the original issue?
On Mon, Feb 8, 2021 at 10:21 AM Ben Avrahami wrote:
> In both python 3.7 and 3.8, typing.NamedTuple had some strange behaviour
> regarding multiple inheritance. This behaviour was solved in 3.9
> (bpo-36517), but this fix also barred me from a feature very close to my
> heart: the generic named tuple
>
> ```
> T = TypeVar('T')
> class LLNode(NamedTuple, Generic[T]):
> value: T
> next: Optional[LLNode[T]]
> ```
>
> bpo-36517 was committed because any additional features of other classes
> would be missing from the NamedTuple class at runtime. But Generic has no
> features at runtime, and thus this snippet actually works as expected in
> python 3.7/8. But in 3.9, it raises a TypeError, as bpo-36517 completely
> barred any other bases in a typing.NameTuple subclass.
>
> I propose that instead of wholesale barring multiple inheritance in
> NamedTuple, NamedTuple will allow some pre-defined bases alongside it. It
> will only allow do-nothing mixins with no runtime features (I can only
> think of `Generic` Aliases atm, but perhaps others exist). As before, these
> bases will be actually omitted from the class's bases at runtime.
>
> Any thoughts?
> ___
> 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/XZVZT3U237UCEI4FT6MZVU5MBZICV6ST/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/EHHVQ2J5EILIM74BKVQIXE3U4QDLHRBE/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Alternate lambda syntax
On Thu, Feb 11, 2021 at 8:58 PM Random832 wrote:
> On Thu, Feb 11, 2021, at 06:48, Paul Sokolovsky wrote:
> > Hello,
> >
> > On Thu, 11 Feb 2021 12:24:55 +0100
> > "J. Pic" wrote:
> >
> > > Hi all,
> > >
> > > Lambdas can be defined as such:
> > >
> > > w = lambda: [12]
> > > x = lambda y: len(y)
> > >
> > > I'd like to propose the following:
> > >
> > > w = (): [12]
> >
> > What will be the meaning of {(): [12]} ? Hint: it will be a dictionary
> > of empty tuple mapping to a list, where do you see lambda here?
>
> This could be solved with parentheses, but I think it'd probably be better
> to use similar syntax to C#, Java, and Javascript instead, and use () ->
> [12] or () => 12...
>
Agreed. I'd prefer the JavaScript solution, since -> already has a
different meaning in Python return *type*. We could use -> to simplify
typing.Callable, and => to simplify lambda.
> It's worth noting that all three of these are later additions to their
> respective languages, and they all have earlier, more difficult, ways of
> writing nested functions within expressions. Their designers saw the
> benefit of an easy lambda syntax, why don't we?
>
Probably we were blinded by the endless search for for multi-line lambdas.
It's not too late.
> It also may be worth looking at what it would take to allow asynchronous
> lambdas. Syntactically, while "any lambda containing await" is tempting,
> the lack of static typing means that we need a way to specify async lambdas
> that do not contain await. Javascript prefixes the argument list with async
> [i.e. "async () => ..." or "async onearg => ..."], as does C# even though
> it could in principle get away without doing so because of static typing.
>
Makes sense.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/AR5B36GAMB32DXUY2RMG36ADJ5YJRMWD/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Pattern Matching -- Removing Name Binding from Partial Matching
The solution here is not to use the same name for two different concepts in
the first place. Python doesn't have scopes associated with blocks, only
with functions, and occasionally this means you have to pick your names
carefully -- the same happens e.g. if you reuse a variable as a for-loop
control variable.
You can say that you don't want failed cases to bind any variables -- but
what if the pattern succeeds and now a guard (the 'if' clause) needs to
check the variable? We went down the route of how to make this work and in
the end decided it would be too complicated.
Or what if a case succeeds, and then after the match statement is over and
done with (not in `case _:`) you still wanted access to the global 'name'?
The long and short of it is that match statements are liable to any or all
names bound in any of the patterns used, and your code is incorrect if you
aren't prepared for that.
A variant of the syntax to allow alternate semantics sounds worse.
On Fri, Feb 12, 2021 at 10:30 PM Abdulla Al Kathiri <
alkathiri.abdu...@gmail.com> wrote:
> I will explain it in the following few lines of code..
>
> name = "George"
> year = 2021
>
> d = {"name": "Mike", "year": 1919}
>
> match d:
>
> case {"name": name, "year": 1917}:
> print("match 1 found”)
> # I want to remove binding "name" here from partial
> matching
>
> case {"year": year, "name": "Michael”}:
> print("match 2 found”)
> # I want to remove binding "year" here from partial
> matching.
> # Basically removing all name bindings after every
> partial/failed matching
>
> case _:
> print("match not found!”)
> print(f"{name = }, {year = }”)
>
> ### Output ###:
> match not found!
> name = 'Mike', year = 1919
>
> But I want :var: 'name' to stay being the global name “George" and :var:
> 'year' being the global year 2021 if an exact matching is not found.
>
> Maybe it is done the way it is for speed optimization (overhead reduction
> or something), but what if I don't care about speed and I care about having
> no un-intentional side-effects?
>
> Can we do something like the following to solve this issue?
> match d, partial_binding=False:
> case … : ...
> case … : ...
> with partial_binding=True by default.
>
> Any other idea in how to prevent name binding due to partial matching from
> happening? Any previous discussions on this?
>
> Thanks,
>
> Abdulla
> ___
> 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/HOFNVZ6KJA6SHCE4NCLPSK27XLDMK7VR/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/ROVCZOFH7OXVI32VPS2K5SAF2FXUA3UN/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Pattern Matching -- Removing Name Binding from Partial Matching
I should add that I accidentally left out a word. It should be “... liable to *overwrite* any or all names ...” On Sun, Feb 14, 2021 at 12:10 Abdulla Al Kathiri < alkathiri.abdu...@gmail.com> wrote: > That makes sense. As Guido mentioned, this is similar to reusing a > variable in a for-loop. You do it at your own risk. Ok consider me > convinced. I will use the following sentence to explain name binding in > partial matching: > *“Match statements are liable to any or all names bound in any of the > patterns used, and your code is incorrect if you aren't prepared for that."* > > > On 14 Feb 2021, at 7:20 PM, Chris Angelico wrote: > > On Sun, Feb 14, 2021 at 11:26 PM Abdulla Al Kathiri > wrote: > > > My idea was that in the case of partial matching or full matching without > passing the guard, the binding names has some sort of self destruction and > return to the previous state. Using different variable names would resolve > the issue and if I want to modify the global variables, I could choose to > do so in the case block after the case succeeded. At least, this way, it > would be more explicit, conveying the person intention (or forgetting if > the original global value was later needed). I saw many people online > talking about this the last couple of days so I thought I would bring it up > here. Any other syntax variant could be used to achieve the same thing. > > > It's not about syntax. Python doesn't have an idea of "self > destruction and return to the previous state". The nearest equivalent > is a very special case at the end of an exception handler, where after > "except Exception as e:" you'll get an implicit "e = None; del e" to > prevent a refloop. That's not a return to the previous state, that's a > conscious clearing of one reference. > > If this "unwinding" were desired, the best way would be to simply make > it a permanent part of the match semantics - no syntax for selecting > which behaviour you want. There's no backward compatibility to be > maintained (yet). But that would be inconsistent with the rest of > Python, where things happen step by step, and if something breaks, > everything prior to it has happened. > > 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/5K65WY7B6O7EO5ZKWZZCS3OYV2HCIBQJ/ > 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/LQWGSE7DYQHXQQCVJDDRXROZ7WHYDHQQ/ > 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/CXLTVIRD3BWQIQTQMKQXR7NWJ7Y6I6SI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Arrow functions polyfill
Okay, here’s my dilemma. It looks like this thread wants to devise a new
syntax for lambda, using e.g. (x, y) -> x+y, or the same with =>. That’s
great, but doesn’t open new vistas.
OTOH, for people using type annotations, a much more pressing issue is an
alternative for typing.Callable that is more readable, and supports extra
features that Callable doesn’t, like keyword args, varargs, and pos-only.
If you can do both with the same arrow, great, but if the arrows must
differ (for some technical reason, e.g. types in cast()), I want -> for
Callable, and you can have => for lambda.
—Guido
On Mon, Feb 15, 2021 at 02:51 Steven D'Aprano wrote:
> On Mon, Feb 15, 2021 at 02:12:03AM +1100, Chris Angelico wrote:
> > On Sun, Feb 14, 2021 at 8:42 PM Steven D'Aprano
> wrote:
> > > We should not choose the more confusing, error-prone solution out of
> > > fear of being different. Python is already different from Javascript in
> > > every regard:
> > >
> >
> > Is it really?
>
> Well, they're both Turing Complete, so I guess not different in *every*
> regard :-)
>
> By the way, I'm not judging the differences.
>
>
> > > - the basic execution model is different;
> > Don't know what you mean here, but I thought they were the same.
>
> Python has a purely dynamic execution model; Javascript has a hybrid
> two-pass model that combines elements of static and dynamic execution,
> and which allows code like this to run:
>
> print(f(3));
>
> function f(a) {
> return a*2;
> }
>
>
> (not in an interactive REPL of course).
>
> Although both Python and Javascript have dynamic typing, Python's
> type model is stronger (i.e. stricter) than Javascript's.
>
> 1 + '2' # an error in Python, 12 in Javascript.
>
> In Python, every thing is an object; in Javascript, some things are
> objects, and some things are primitive values.
>
>
> > > - the object model is different;
> > Same object model.
>
> Absolutely not. Javascript is based on the prototype object model, and
> Python is based on the class object model.
>
>
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain
>
>
> > > - the numeric model is different;
> > Python has more data types, but that's not as fundamental a difference
> > as you might think
>
> Python has a numeric tower; Javascript has a single floating point type.
> It's hard to build a tower with a single brick :-)
>
>
> > > -the truthy/falsey model is different;
> > There are different rules about WHAT is truthy/falsy, but, again, the
> > differences aren't fundamental
>
> The differences are precisely my point.
>
>
> > > - the syntax is different;
> > > - the list of keywords is different;
> > > - the standard library is different;
> > > - the list of operators is different;
> > Well, of course. If these four were the same, they'd be the same
> > language. These four differ between Py2 and Py3 too.
>
> Yes, the fact that they are different languages is my point.
>
>
> > > - even basic equality is different;
> > Yes, although that's more historic than anything else - most people
> > use "===" which has mostly the same semantics as Python's equality
>
> "Mostly the same", apart from being completely different :-(
>
> Javascript's === tests for "same type and equal" for primitive values,
> and is equivalent to Python's `is` for objects. It cannot be overloaded.
>
>
> > > - the culture of the community is different.
> > TBH neither community has a single culture.
>
> Of course neither group of people is a monoculture of identical
> clones. That would be the Haskell community *wink*
>
> But in general, the JS/Node.js community embraces practices which are
> rejected by the Python community, such as the use of micro-packages.
> Remember left-pad?
>
> This four-line package got nearly fifty million downloads last week:
>
> https://www.npmjs.com/package/isarray
>
> That's about 78 times per second.
>
> If I published that on PyPI, I would be amazed if I got 78 downloads in
> a year.
>
>
> --
> 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/7RDIPZDPOZUU7AD5JFE2BNQH75OAAGS7/
> 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/UJ32U33U4FL4GAOERD77CMB5QFJNHF63/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Arrow functions polyfill
On Mon, Feb 15, 2021 at 9:02 AM Ricky Teachey wrote:
> [...]
> But if we could expand the proposal to allow both anonymous and named
> functions, that would seem like a fantastic idea to me.
>
> Anonymous function syntax:
>
> (x,y)->x+y
>
> Named function syntax:
>
> f(x,y)->x+y
>
Proposals like this always baffle me. Python already has both anonymous and
named functions. They are spelled with 'lambda' and 'def', respectively.
What good would it do us to create an alternate spelling for 'def'?
I know that in JavaScript there are different ways to define functions
('function' and '=>'), and they have subtly different semantics. (For
example, regarding 'this'. Such an incredible mess!) We don't need
different semantics in Python.
I can sympathize with trying to get a replacement for lambda, because many
other languages have jumped on the arrow bandwagon, and few Python
first-time programmers have enough of a CS background to recognize the
significance of the word lambda. But named functions? Why??
> But since Guido wants to save the right shaft operator for type hinting,
> and named functions do need a way to write type hints, maybe the best thing
> to do is use an equal sign shaft for the function definition and the right
> shaft for the type hint:
>
> f(x,y)=>x,y->str
>
> >>> f('a','b')
> 'ab'
> >>> f(1,2) # type hint error
>
Another thing. Type hints are not interpreted at runtime, and I don't
expect this to change in the near to middle future.
Plus, that syntax really has nothing to recommend it.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/ATG3LCZRNRM3T33NNRALXXLAA7YR6XSU/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Deprecate/change the behaviour of ~bool
Also, code that is expecting an int should not behave differently when it receives a bool. On Mon, Feb 22, 2021 at 17:47 Chris Angelico wrote: > On Tue, Feb 23, 2021 at 12:14 PM Soni L. wrote: > > > > Currently ~False is -1 and ~True is -2. Would be nicer if ~bool was the > > same as not bool. Hopefully nobody actually relies on this but > > nevertheless, it would be a backwards-incompatible change so the whole > > deprecation warnings and whatnot would be required. > > There are quite a few ways in which bitwise operators are not the same > as boolean operators. What would be the advantage of having them be > the same in just this one case? > > > In particular, this is nice for xnor operator: a ^~ b. This currently > > works on ints, but not on bools, while most other operators, including > > xor, do successfully work on bools. > > You could write it as a ^ (not b), as long as you don't mind it giving > back an integer rather than a bool. Fundamentally, you're doing > bitwise operations on integers, and expecting them to behave as if > they have only a single bit each, so another way to resolve this might > be to mask it off at the end with "& 1". > > If this makes your code horrendously ugly, perhaps it would be better > to create your own "one-bit integer" class, which responds to all > bitwise operators by automatically masking down to one bit? > > 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/6HLSLQMMKYNLSEQCIIDVKXIGV2TZFREE/ > 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/CHWNS222IJQQHXBTXXMSSD2GQZ4QAE7A/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Barrier Object in asyncio lib
On Fri, Feb 26, 2021 at 10:09 AM Yves Duprat wrote: > I was expecting an explanation about the initial request. > Is there an oversight (??) or an another reason to not have a Barrier > primitive in asyncio ? > Probably because nobody working on asyncio at the time had any experience using threading.Barrier. I know that I have used all the other primitives, but I don't recall ever having used Barrier. I don't think there's anything deeper than that. You should probably just open a bpo issue (mention this thread) and submit a PR linked there. I can't promise to review it though. :-) -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/GNUCKA2MCVROCVLWRQUTMUG7CGOVQQV6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Dataclasses, keyword args, and inheritance
I've seen comments from Eric V Smith in this thread and in the PR. If he's in favor and it can be done in a backwards compatible way then he can guide you to acceptance and merging of your PR. But like all of us he has limited time. On Wed, Mar 10, 2021 at 6:15 AM Laurie O wrote: > I've had tens of people show interest in my proposal, asking what the > blocker is in acceptance. As far as I know, no Python developer has shown > any interest in it. > > My proposal is to automatically make any non-default fields become > keyword-only `__init__` parameters, with no need to have any arguments > passed to the `dataclass` decorator. > > My PR: https://github.com/python/cpython/pull/17322 > > My previous mailing-list message: > https://mail.python.org/archives/list/python-ideas@python.org/message/2V2SCUFMK7PK3DVA7D77AVXWIXNTSQDK/ > ___ > 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/KPVB2G64BHFGGOTXZQXT3AU7SIO5ABJE/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/IN3D7UQQI4HSKSCUPMU3C3RTUG6NWUKG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Implicit line continuation for method chaining
Can we skip ahead to considering how to implement this? I can think of two
approaches: either hack the lexer to special-case a newline followed by a
period (which currently can never start a line), or redesign the syntax to
allow NEWLINE INDENT ‘.’ . NEWLINE ‘.’ DEDENT at the
end of an expression. Both have pros and cons.
Discuss how this allows for certain typos to pass as valid syntax.
On Fri, Mar 12, 2021 at 07:42 Matt Williams wrote:
> Hi,
>
> It's becoming more popular in Python to have interfaces which are built
> around method chaining as a way of applying operations to data. For example
> in pandas is moving more towards a default model where methods do not
> change the object in-place but instead return an altered version (or at
> least an altered view) of it.
>
> The major downside to method chaining is that it ends up creating long
> lines of code which can become hard to read. The two main solutions to this
> are 1) break down the chain and give the steps their own variable names and
> 2) split it over multiple lines using `\` as a line continuation.
>
> e.g.:
>
> y = x.rstrip("\n").split(":")[0].lower()
>
> would become
>
> y = x.rstrip("\n") \
>.split(":")[0] \
>.lower()
>
> I find the continuation character visually distracting, easy to forget and
> does not allow for line-by-line commenting (causing `SyntaxError:
> unexpected character after line continuation character`):
>
> y = x.rstrip("\n") \
>.split(":")[0] \ # grab the key name
>.lower()
>
> My idea is to alter the syntax of Python to allow doing:
>
> y = x.rstrip("\n")
>.split(":")[0]
>.lower()
>
> i.e., not requiring an explicit line continuation character in the case
> where the next line starts with a period.
>
> I've had a search through the archives and I couldn't see this discussion
> before. Feel free to point me to it if I've missed anything.
>
> Cheers,
> Matt
> ___
> 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/LWB3U5BTGC4CT26U4AB676SKGED3ZOEX/
> 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/3BNMTY74DDQMTD6PVH3ZGCVMBCSW3SQ5/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Implicit line continuation for method chaining
This argument pretty much kills the proposal.
On Fri, Mar 12, 2021 at 9:01 AM Rob Cliffe via Python-ideas <
python-ideas@python.org> wrote:
> To my mind there are too many differences between running code as a
> script and running it in the REPL. This would, presumably, add another
> one: the initial line would be executed without waiting to see if there
> is a dot continuation line. And it just feels wrong to have a complete
> syntactically valid line of code ... not be a complete line of code.
> You can always add outer brackets, as in other situations where lines of
> code become over-long:
>
> y = (x.rstrip("\n")
> .split(":")[0]
> .lower())
>
> -1
> Rob Cliffe
>
> On 12/03/2021 15:32, Matt Williams wrote:
> > Hi,
> >
> > It's becoming more popular in Python to have interfaces which are built
> around method chaining as a way of applying operations to data. For example
> in pandas is moving more towards a default model where methods do not
> change the object in-place but instead return an altered version (or at
> least an altered view) of it.
> >
> > The major downside to method chaining is that it ends up creating long
> lines of code which can become hard to read. The two main solutions to this
> are 1) break down the chain and give the steps their own variable names and
> 2) split it over multiple lines using `\` as a line continuation.
> >
> > e.g.:
> >
> >y = x.rstrip("\n").split(":")[0].lower()
> >
> > would become
> >
> >y = x.rstrip("\n") \
> > .split(":")[0] \
> > .lower()
> >
> > I find the continuation character visually distracting, easy to forget
> and does not allow for line-by-line commenting (causing `SyntaxError:
> unexpected character after line continuation character`):
> >
> >y = x.rstrip("\n") \
> > .split(":")[0] \ # grab the key name
> > .lower()
> >
> > My idea is to alter the syntax of Python to allow doing:
> >
> >y = x.rstrip("\n")
> > .split(":")[0]
> > .lower()
> >
> > i.e., not requiring an explicit line continuation character in the case
> where the next line starts with a period.
> >
> > I've had a search through the archives and I couldn't see this
> discussion before. Feel free to point me to it if I've missed anything.
> >
> > Cheers,
> > Matt
> > ___
> > 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/LWB3U5BTGC4CT26U4AB676SKGED3ZOEX/
> > 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/GVVLTS2EYLB7WKQ625RUOXSQHR3SOQ6E/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/JZZHPUSTBSWPKIZJ7AERBKLQYGJBU2QO/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Enum: determining if a value is valid
On Fri, Mar 12, 2021 at 1:52 PM Ethan Furman wrote: > A question that comes up quite a bit on Stackoverflow is how to test to > see if a value will result in an Enum member, preferably without having to > go through the whole try/except machinery. > > A couple versions ago one could use a containment check: > >if 1 in Color: > > but than was removed as Enums are considered containers of members, not > containers of the member values. Maybe you were a bit too quick in deleting it. Was there a serious bug that led to the removal? Could it be restored? > It was also possible to define one's own `_missing_` method and have it > return None or the value passed in, but that has also been locked down to > either return a member or raise an exception. > > At this point I see three options: > > 1) add a `get(value, default=None)` to EnumMeta (similar to `dict.get()` > But the way to convert a raw value to an enum value is Color(1), not Color[1], so Color.get(1) seems inconsistent. Maybe you can just change the constructor so you can spell this as Color(1, default=None) (and then check whether that's None)? > 2) add a recipe to the docs > But what would the recipe say? Apparently you're looking for a one-liner, since you reject the try/except solution. > 3) do nothing > Always a good option. :-) Where's that StackOverflow item? How many upvotes does it have? -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/QRDMKZBL54GU7A7OSDB5GG2HIAGCDTLE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add an export keyword to better manage __all__
t (Zen) -- it's easy to accidentally "import sys" instead > of > "import sys as _sys" -- it makes doing the wrong thing the default state. > > > Proposal: > > > > Add a contextual keyword "export" that has meaning in three places: > > 1. Preceding an "import" statement, which directs all names imported by > that >statement to be added to __all__: > > import sys > export import .foo > export import ( > A, > B, > C, > D > ) from .bar > > # __all__ == ["foo", "A", "B", "C", "D"] > > 2. Preceding a "def", "async def", or "class" keyword, directing that > function >or class's name to be added to __all__: > > def private(): pass > export def foo(): pass > export async def async_foo(): pass > export class Foo: pass > > # __all__ == ["foo", "async_foo", "Foo"] > > 3. Preceding a bare name at top-level, directing that name to be added to >__all__: > > x = 1 > y = 2 > export y > > # __all__ == ["y"] > > > # Big Caveat > > For this scheme to work, __all__ needs to not be auto-populated with names. > While the behavior is possibly suprising, I think the best way to handle > this is > to have __all__ not auto-populate if an "export" keyword appears in the > file. > While this is somewhat-implicit behavior, it seems reasonable to me to > expect that > if a user uses "export", they are opting in to the new way of managing > __all__. > Likewise, I think manually assigning __all__ when using "export" should > raise > an error, as it would overwrite all previous exports and be very confusing. > ___ > 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/HL3P7CXZX3U5SMNIJODL45BE6E72MWTI/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/LQL4VRXWWDYRYCOHQYWV4GMZO542HV6E/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Implicit line continuation for method chaining
On Fri, Mar 12, 2021 at 6:23 PM Peter Ludemann wrote: > [I wonder why C didn't adopt BCPL's convention for eliding semi-colons? > ...] > [Presumably because it caused too many surprising behaviors...] -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/4FN7WKW4BJP6XWJPQGFF63RYN2PU5JCC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add an export keyword to better manage __all__
On Sun, Mar 14, 2021 at 7:11 AM Theia Vogel wrote: > > import the_module > > > the_module.sys > > > would work, but > > > from the_module import sys > > > would not work? > > > That might be odd and confusing. > > Good point. I'm not familiar with CPython internals so I'm not sure how > this would work on the implementation side, but I definitely think it would > be important to not have an inconsistency here. > You probably should design this in partnership with someone who's more familiar with those internals. I believe that familiarity with Python internals is pretty important if you want to be able to design a new feature. Without thinking about the implementation you might design something that's awkward to implement; but you might also not think of something that's easy to do in the implementation but not obvious from superficial usage. (There are two lines in the Zen of Python devoted to this. :-) It is already possible to completely customize what happens when you write "import X". The returned object doesn't even strictly need to have a `__dict__` attribute. For `from X import Y` it first does `import X` (but doesn't bind X in your namespace) and then gives you `X.Y`, except if `Y` is `*`, in which case it looks in `X.__all__`, or if that's not found it looks in `X.__dict__` and imports all keys not starting with `_`. So to support `from X import *` you need either `__all__` or `__dict__`, else you get an import error (but neither of those is needed to support `from X import Y` or `import X; X.Y`). So I think there is no technical reason why we couldn't make it so that a module that uses `export` returns a proxy that only lets you use attributes that are explicitly exported. If users disagree with this, they can negotiate directly with the module authors. It's not a principle of Python that users *must* be given access to implementation details, after all -- it was just more convenient to do it this way when the language was young. (For example, it's not possible to root around like this in C extensions -- these only export what the author intends to export.) I do think that this means that existing libraries need to be careful when adding `export` statements, because it effectively becomes a backwards incompatibility. We could also implement a flag to weaken the strictness in this area (the flag would have to be set by the module, not by the importing code). Such a proxy could also be used to implement lazy imports, to some extent. (I'm not sure how to do `from X import Y` lazily -- it would have to wrap `Y` in another proxy, and then it becomes awkward, e.g. if `Y` is supposed to represent a simple number or string -- we don't want any other part of the language or stdlib to need to become aware of such proxies.) Long answer short, yes, we can make it so that `the_module.sys` in your example above is forbidden -- if we want to. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/2GCHG5TMEYNPYKXQBCM2CK5LG7SRRRD6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add an export keyword to better manage __all__
If you feel so strongly about it maybe we need to see some credentials. What's your background? (This may sound like an odd request, but reputation matters, and right now I have no idea who you are or why I should take your opinion seriously, no matter how eloquently it is stated.) Note that C extensions allow none of the introspection mechanisms you're proposing here (they have a `__dict__` but it is fully controlled by the author of the C code) and they thrive just fine. I am happy with giving module authors a way to tell the system "it's okay, users can reach in to access other attributes as well". But I think module authors should *also* be given a way to tell the system "please prevent users from accessing the private parts of this API no matter how hard they try". And using 'export' seems a reasonable way to enable the latter. (To be clear I am fine if there's a flag to override this default even when 'export' is used.) I know there are package authors out there who have this desire to restrict access (presumably because they've been burned when trying to evolve their API) and feel so strongly about it that they implement their own restrictive access controls (without resorting to writing C code). On Sun, Mar 14, 2021 at 12:42 PM Stestagg wrote: > On Sun, 14 Mar 2021 at 18:58, Guido van Rossum wrote: > >> On Sun, Mar 14, 2021 at 7:11 AM Theia Vogel wrote: >> >>> > import the_module >>> >>> > the_module.sys >>> >>> > would work, but >>> >>> > from the_module import sys >>> >>> > would not work? >>> >>> > That might be odd and confusing. >>> >>> Good point. I'm not familiar with CPython internals so I'm not sure how >>> this would work on the implementation side, but I definitely think it would >>> be important to not have an inconsistency here. >>> >> >> So I think there is no technical reason why we couldn't make it so that a >> module that uses `export` returns a proxy that only lets you use attributes >> that are explicitly exported. If users disagree with this, they can >> negotiate directly with the module authors. It's not a principle of Python >> that users *must* be given access to implementation details, after all -- >> it was just more convenient to do it this way when the language was young. >> (For example, it's not possible to root around like this in C extensions -- >> these only export what the author intends to export.) >> >> > > If this is implemented, then please ensure that some mechanism is included > (either keeping __dict__, or functions in inspect, or some other mechanism) > to both get and set all attributes of a module irrespective of any > export/__all__ controls. > > I understand that perspective that says library authors should be able to > control their API, for various reasons, but this has to be balanced against > the fact that library authors are not perfect, and can either include bugs, > or fail to consider all reasonable use-cases when designing their code. > Historically, this has been done, by convention, through use of the "_" > private specifier for module-level objects. > > The value of being able to (in specific cases) reach into third-party > code, and customize it to work for your specific situation should not be > disregarded. > > I think every large codebase that I've worked with has had to monkey-patch > a method deep within at least one third-party library at runtime, in > production (this is also commonly used for testing purposes), at some point > to work-around either a limitation of the library, incompatibility with > other library, or to patch a bug. This also applies to module-globals that > are themselves imported modules, being able to rebind a name to reference a > different module (within careful constraints) in a library module has saved > me several times. > > If external visibility of code units within libraries starts to be > restricted so that this sort of patching isn't possible, then the cost of > fixing some problems may start to become significantly greater. > > I strongly believe that the access to members of modules should be kept as > similar to the access of members of class instances as possible. Not only > will this keep the model simpler, the same arguments and/or concerns apply > when talking about classes as when talking about modules. Maybe this means > that non-exported members of modules get name-mangled as protected class > attributes do, or maybe the '__dict__' member is always exported. > > I think the idea of resolving the issues mention
[Python-ideas] Re: Add an export keyword to better manage __all__
Hi Steve, I don't think I can explain adequately why I challenged you, so I'll just apologize. Your feedback (about the 'export' proposal, and about my challenge of your credentials) is duly noted. Sorry! --Guido On Sun, Mar 14, 2021 at 4:11 PM Stestagg wrote: > On Sun, Mar 14, 2021 at 8:22 PM Guido van Rossum wrote: > >> If you feel so strongly about it maybe we need to see some credentials. >> What's your background? (This may sound like an odd request, but reputation >> matters, and right now I have no idea who you are or why I should take your >> opinion seriously, no matter how eloquently it is stated.) >> >> > Hi Guido, I have enormous respect for you, but have no interest in > attempting to prove I'm a 'good-enough egg' to warrant your serious > attention. > > The entire question makes me somewhat uncomfortable, and to illustrate > why, I'm going to willfully misinterpret it to make my point: > > My background is: White, Middle-class British male, mid-30s, my family is > descended from the illigitimate son of the governor of the Isle of Wight. > I've dined with the Queen, and my last two schools were both over 400 years > old. Does this qualify me for attention? What if I were a BAME teen woman > living in Bangladesh? > > Of course, sarcastic responses aside, I assume you meant technical > background/credentials. Similar concerns still apply there, this > python-ideas list is full of people with ideas, many of which are held > strongly, that don't get their background questioned openly (although, as > in most communities, there's evidence of this happening subtextually in > places). > > In fact, when I previously pointed out a critical flaw in one of your > proposals in another thread on this list, I wasn't questioned about my > credentials then (I assume because you realised your mistake at that > time). If you're still interested in my CV, it's easily findable online, > along with other technical context about me that may be relevant to > assessing my worthiness. > > Regardless of the above, I'm not going to argue further about the proposal > or my plea to keep some control/override. That's why I made my case as > robustly as I could initially. It's a single data-point, other people may > reinforce it, or counter it, in the disucssion. By broaching the subject, > I was hoping to ensure that this aspect of the proposed change would be > considered, if you decide I'm not worth it, then that's your call. > > Regards > > Steve > > Note that C extensions allow none of the introspection mechanisms you're >> proposing here (they have a `__dict__` but it is fully controlled by the >> author of the C code) and they thrive just fine. >> >> I am happy with giving module authors a way to tell the system "it's >> okay, users can reach in to access other attributes as well". But I think >> module authors should *also* be given a way to tell the system "please >> prevent users from accessing the private parts of this API no matter how >> hard they try". And using 'export' seems a reasonable way to enable the >> latter. (To be clear I am fine if there's a flag to override this default >> even when 'export' is used.) >> >> I know there are package authors out there who have this desire to >> restrict access (presumably because they've been burned when trying to >> evolve their API) and feel so strongly about it that they implement their >> own restrictive access controls (without resorting to writing C code). >> >> On Sun, Mar 14, 2021 at 12:42 PM Stestagg wrote: >> >>> On Sun, 14 Mar 2021 at 18:58, Guido van Rossum wrote: >>> >>>> On Sun, Mar 14, 2021 at 7:11 AM Theia Vogel wrote: >>>> >>>>> > import the_module >>>>> >>>>> > the_module.sys >>>>> >>>>> > would work, but >>>>> >>>>> > from the_module import sys >>>>> >>>>> > would not work? >>>>> >>>>> > That might be odd and confusing. >>>>> >>>>> Good point. I'm not familiar with CPython internals so I'm not sure >>>>> how this would work on the implementation side, but I definitely think it >>>>> would be important to not have an inconsistency here. >>>>> >>>> >>>> So I think there is no technical reason why we couldn't make it so that >>>> a module that uses `export` returns
[Python-ideas] Re: Enum: determining if a value is valid
On Mon, Mar 15, 2021 at 10:53 AM Ethan Furman wrote: > On 3/12/21 5:28 PM, Guido van Rossum wrote: > > On Fri, Mar 12, 2021 at 1:52 PM Ethan Furman wrote: > > >> A question that comes up quite a bit on Stackoverflow is how to test > >> to see if a value will result in an Enum member, preferably without > >> having to go through the whole try/except machinery. > >> > >> A couple versions ago one could use a containment check: > >> > >> if 1 in Color: > >> > >> but than was removed as Enums are considered containers of members, > >> not containers of the member values. > > > > Maybe you were a bit too quick in deleting it. Was there a serious > > bug that led to the removal? Could it be restored? > > Part of the reason is that there are really two ways to identify an > enum -- by name, and by value -- which should `__contains__` work with? > The two sets don't overlap, so we could allow both. (Funny interpretations of `__contains__` are not unusual, e.g. substring checks are spelled 'abc' in 'fooabcbar'.) > >> At this point I see three options: > >> > >> 1) add a `get(value, default=None)` to EnumMeta (similar to > `dict.get()` > > > > But the way to convert a raw value to an enum value is Color(1), not > > Color[1], so Color.get(1) seems inconsistent. > > Very good point. > > > Maybe you can just change the constructor so you can spell this as > > Color(1, default=None) (and then check whether that's None)? > > An interesting idea. > > >> 2) add a recipe to the docs > > > > But what would the recipe say? Apparently you're looking for a one-liner, > > since you reject the try/except solution. > > The recipe would be for a method that could be added to an Enum, such as: > > @classmethod > def get_by_value(cls, value, default=None): > for member in cls: > if member.value == value: > return member > return default > But that's a non-solution -- people can figure out how to write such a helper just fine (although probably using try/except) but they don't want to -- they have *one* line where they want to do this check and so they're going for a local solution -- probably the try/except. > >> 3) do nothing > > > > Always a good option. :-) > > Yes, but not always a satisfying one. :) > > > Where's that StackOverflow item? How many upvotes does it have? > > > 93 - How do I test if int value exists in Python Enum without using > try/catch? > https://stackoverflow.com/q/43634618/208880 > > 25 - How to test if an Enum member with a certain name exists? > https://stackoverflow.com/q/29795488/208880 > > 3 - Validate value is in Python Enum values > https://stackoverflow.com/q/54126570/208880 > > 2 - How to check if string exists in Enum of strings? > https://stackoverflow.com/q/63335753/208880 > > I think I like your constructor change idea, with a small twist: > > Color(value=, name=, default=) > > This would make it possible to search for an enum by value or by name, and > also specify a default return value (raising an exception if the default is > not set and a member cannot be found). > So specifically this would allow (hope my shorthand is clear): ``` Color['RED'] --> Color.RED or raises Color(1) -> Color.RED or raises Color(1, default=None) -> Color.RED or None Color(name='RED', default=None) -> Color.RED or None ``` This seems superficially reasonable. I'm not sure what Color(value=1, name='RED') would do -- insist that both value and name match? Would that have a use case? My remaining concern is that it's fairly verbose -- assuming we don't really need the name argument, it would be attractive if we could write Color(1, None) instead of Color(1, default=None). Note that instead of Color(name='RED') we can already write this: ``` getattr(Color, 'RED') -> Color.RED or raises getattr(Color, 'RED', None) -> Color.RED or None ``` -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/CIXFX5SL5DX4ISZOWXJFFYVQK53FGQ27/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Enum: determining if a value is valid
+1 On Mon, Mar 15, 2021 at 12:48 PM Ethan Furman wrote: > On 3/15/21 11:27 AM, Guido van Rossum wrote: > > On Mon, Mar 15, 2021 at 10:53 AM Ethan Furman wrote: > > >> Part of the reason is that there are really two ways to identify an > >> enum -- by name, and by value -- which should `__contains__` work with? > > > > The two sets don't overlap, so we could allow both. (Funny > > interpretations of `__contains__` are not unusual, e.g. > > substring checks are spelled 'abc' in 'fooabcbar'.) > > They could overlap if the Enum is a `str`-subclass -- although having the > name of one member match the value of a different member seems odd. > > >> I think I like your constructor change idea, with a small twist: > >> > >> Color(value=, name=, default=) > >> > >> This would make it possible to search for an enum by value or by name, > >> and also specify a default return value (raising an exception if the > >> default is not set and a member cannot be found). > > > > > > So specifically this would allow (hope my shorthand is clear): > > ``` > > Color['RED'] --> Color.RED or raises > > Color(1) -> Color.RED or raises > > Color(1, default=None) -> Color.RED or None > > Color(name='RED', default=None) -> Color.RED or None > > ``` > > This seems superficially reasonable. I'm not sure what > > Color(value=1, name='RED') would do -- insist that both value and > > name match? Would that have a use case? > > I would enforce that both match, or raise. Also not sure what the > use-case would be. > > > My remaining concern is that it's fairly verbose -- assuming we don't > > really need the name argument, it would be attractive if we could > > write Color(1, None) instead of Color(1, default=None). > > > > Note that instead of Color(name='RED') we can already write this: > > ``` > > getattr(Color, 'RED') -> Color.RED or raises > > getattr(Color, 'RED', None) -> Color.RED or None > > Very good points. > > Everything considered, I think I like allowing `__contains__` to verify > both names and values, adding `default=` to the constructor for > the value-based "gimme an Enum or None" case, and recommending `getattr` > for the name-based "gimme an Enum or None" case. > > -- > ~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/UQBSDZQJWBKMOVSUES7HEDJTYR76Y5N2/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/ZK7KKABFNSFC4UY763262O2VIPZ5YDPQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dataclasses keyword-only fields, take 2
uld be ignored, except for assigning the kw_only > flag to fields declared after these singletons are used. So you'd get: > > @dataclasses.dataclass > class B: > a: Any > _: dataclasses.KW_ONLY > b: Any > > This would generate: > > def __init__(self, a, *, b): > > This example is equivalent to: > > @dataclasses.dataclass > class B: > a: Any > b: Any = field(kw_only=True) > > The name of the KW_ONLY field doesn't matter, since it's discarded. I > think _ is a fine name, and '_: dataclasses.KW_ONLY' would be the > pythonic way of saying "the following fields are keyword-only". > > My example above would become: > > @dataclasses.dataclass > class LotsOfFields: > a: Any > _: dataclasses.KW_ONLY > b: Any = 0 > c: Any = 'foo' > d: Any > e: Any = 0.0 > f: Any > g: Any = () > h: Any = 'bar' > i: Any = 3+4j > j: Any = 10 > k: Any > > Which I think is a lot clearer. > > The generated __init__ would look like: > > def __init__(self, a, *, b=0, c='foo', d, e=0.0, f, g=(), h='bar', > i=3+4j, j=10, k): > > The idea is that all normal argument fields would appear first in the > class definition, then all keyword argument fields. This is the same > requirement as in a function definition. There would be no switching > back and forth between the two types of fields: once you use KW_ONLY, > all subsequent fields are keyword-only. A field of type KW_ONLY can > appear only once in a particular dataclass (but see the discussion below > about inheritance). > > > Re-ordering args in __init__ > > > If, using field(kw_only=True), you specify keyword-only fields before > non-keyword-only fields, all of the keyword-only fields will be moved to > the end of the __init__ argument list. Within the list of > non-keyword-only arguments, all arguments will keep the same relative > order as in the class definition. Ditto for within keyword-only arguments. > > So: > > @dataclasses.dataclass > class C: > a: Any > b: Any = field(kw_only=True) > c: Any > d: Any = field(kw_only=True) > > Then the generated __init__ will look like: > > def __init__(self, a, c, *, b, d): > > __init__ is the only place where this rearranging will take place. > Everywhere else, and importantly in __repr__ and any dunder comparison > methods, the order will be the same as it is now: in field declaration > order. > Can you be specific and show what the repr() would be? E.g. if I create C(1, 2, b=3, d=4) the repr() be C(a=1, b=3, c=2, d=4), right? > This is the same behavior that attrs uses. > Nevertheless I made several typos trying to make the examples in my sentence above correct. Perhaps we could instead disallow mixing kw-only and regular args? Do you know why attrs does it this way? > Inheritance > --- > > There are a few additional quirks involving inheritance, but the > behavior would follow naturally from how dataclasses already handles > fields via inheritance and the __init__ argument re-ordering discussed > above. Basically, all fields in a derived class are computed like they > are today. Then any __init__ argument re-ordering will take place, as > discussed above. > > Consider: > > @dataclasses.dataclass(kw_only=True) > class D: > a: Any > > @dataclasses.dataclass > class E(D): > b: Any > > @dataclasses.dataclass(kw_only=True) > class F(E): > c: Any > > This will result in the __init__ signature of: > > def __init__(self, b, *, a, c): > > However, the repr() will still produce the fields in order a, b, c. > Comparisons will also use the same order. > This can be simulated by flattening the inheritance tree and adding explicit field(kw_only=True) to all fields of classes using kw_only=True in the class decorator as well as all fields affected by _: KW_ONLY, right? So the above would behave like this: @dataclasses.dataclass class F: a: Any = field(kw_only=True) b: Any c: Any = field(kw_only=True) which IIUC indeed gives the same __init__ signature and repr(). > Conclusion > -- > > Remember, the only point of all of these hoops is to add a flag to each > field saying what type of __init__ argument it becomes: normal or > keyword-only. Any of the 3 methods discussed above (kw_only flag to > @dataclass(), kw_only flag to field(), or the KW_ONLY marker) all have > the same result: setting the kw_only flag on one or more fields. > > The value of that flag, on a per-field basis, is used to re-order > __init__ arguments, and is us
[Python-ideas] Re: Enum: determining if a value is valid
You have a good point (and as static typing proponent I should have thought
of that).
Maybe there is not actually a use case for passing an arbitrary default?
Then maybe overloading __contains__ (‘in’) might be better? The ergonomics
of that seem better for the dominant use case (“is this a valid value for
that enum?”).
On Mon, Mar 15, 2021 at 21:37 Matt Wozniski wrote:
> I find the idea of having the constructor potentially return something
> other than an instance of the class to be very... off-putting. Maybe it's
> the best option, but my first impression of it isn't favorable, and I can't
> think of any similar case that exists in the stdlib today off the top of my
> head. It seems like we should be able to do better.
>
> If I might propose an alternative before this gets set in stone: what if
> `Enum` provided classmethods `from_value` and `from_name`, each with a
> `default=`, so that you could do:
>
> Color.from_value(1) # returns Color.RED
> Color.from_value(-1) # raises ValueError
> Color.from_value(-1, None) # returns None
>
> Color.from_name("RED") # returns Color.RED
> Color.from_name("BLURPLE") # raises ValueError
> Color.from_name("BLURPLE", None) # returns None
>
> That still allows each concept to be expressed in a single line, and
> remains explicit about whether the lookup is happening by name or by value.
> It allows spelling `default=None` as just `None`, as we desire. And instead
> of being a `__contains__` with unusual semantics coupled with a constructor
> with unusual semantics, it's a pair of class methods that each have fairly
> unsurprising semantics.
>
> ~Matt
>
> On Mon, Mar 15, 2021 at 3:55 PM Guido van Rossum wrote:
>
>> +1
>>
>> On Mon, Mar 15, 2021 at 12:48 PM Ethan Furman wrote:
>>
>>> On 3/15/21 11:27 AM, Guido van Rossum wrote:
>>> > On Mon, Mar 15, 2021 at 10:53 AM Ethan Furman wrote:
>>>
>>> >> Part of the reason is that there are really two ways to identify an
>>> >> enum -- by name, and by value -- which should `__contains__` work
>>> with?
>>> >
>>> > The two sets don't overlap, so we could allow both. (Funny
>>> > interpretations of `__contains__` are not unusual, e.g.
>>> > substring checks are spelled 'abc' in 'fooabcbar'.)
>>>
>>> They could overlap if the Enum is a `str`-subclass -- although having
>>> the name of one member match the value of a different member seems odd.
>>>
>>> >> I think I like your constructor change idea, with a small twist:
>>> >>
>>> >> Color(value=, name=, default=)
>>> >>
>>> >> This would make it possible to search for an enum by value or by name,
>>> >> and also specify a default return value (raising an exception if the
>>> >> default is not set and a member cannot be found).
>>> >
>>> >
>>> > So specifically this would allow (hope my shorthand is clear):
>>> > ```
>>> > Color['RED'] --> Color.RED or raises
>>> > Color(1) -> Color.RED or raises
>>> > Color(1, default=None) -> Color.RED or None
>>> > Color(name='RED', default=None) -> Color.RED or None
>>> > ```
>>> > This seems superficially reasonable. I'm not sure what
>>> > Color(value=1, name='RED') would do -- insist that both value and
>>> > name match? Would that have a use case?
>>>
>>> I would enforce that both match, or raise. Also not sure what the
>>> use-case would be.
>>>
>>> > My remaining concern is that it's fairly verbose -- assuming we don't
>>> > really need the name argument, it would be attractive if we could
>>> > write Color(1, None) instead of Color(1, default=None).
>>> >
>>> > Note that instead of Color(name='RED') we can already write this:
>>> > ```
>>> > getattr(Color, 'RED') -> Color.RED or raises
>>> > getattr(Color, 'RED', None) -> Color.RED or None
>>>
>>> Very good points.
>>>
>>> Everything considered, I think I like allowing `__contains__` to verify
>>> both names and values, adding `default=` to the constructor for
>>> the value-based "gimme an Enum or None" case, and recommending `getattr`
>>> for the name-based "gimme an Enum or None" case.
>>>
>>> --
>>> ~Ethan~
>>> ___
[Python-ideas] Re: allow initial comma
is is my preferred formatting. > > I don't think that [PEP](https://www.python.org/dev/peps/pep-0008) > is wrong. I just don't want to be restricted by unnecessary rules. > Rules need to have a reason beyond someone dictating them. If that is > the case, I follow them, because I see the reason, but not because > someone dictates them. > > I'll go to > [Python Ide as]( > https://mail.python.org/mailman3/lists/python-ideas.python.org/), > then. Thanks. > ___ > 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/E3HYA7AWLHTD3MCWVBRH7AT3GLGXFUOG/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/ES4FWNZW7F54BVFO3YDPHPOXXI5GPH5K/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dataclasses keyword-only fields, take 2
That's a really good question. I think that `__match_args__` should *only*
contain the non-kw-only args, so that you would have to write `case C(a, c,
b=b, d=d)` to match on all four attributes (but typically you'd probably
just write `case C(a, c)` -- that's about the same as `case C(a, c, b=_,
d=_)` except it doesn't even care whether b and d are set at all.
On Tue, Mar 16, 2021 at 1:36 PM Eric V. Smith wrote:
> And now I have a question for you, Guido.
>
> I'm looking at the code and I see the additions for __match_args__. Is
> there any bad interaction between this proposal and the match statement? I
> assume __match_args__ be the re-ordered arguments to __init__, but I want
> to make sure.
>
> So this:
> @dataclasses.dataclass
> class C:
> a: Any
> b: Any = field(kw_only=True)
> c: Any
> d: Any = field(kw_only=True)
>
> Which generates:
>
> def __init__(self, a, c, *, b, d):
> Would have __match_args__ equal to ('a', 'c', 'b', 'd'), right? Even
> though the repr would have fields in order a, b, c, d.
>
> Eric
> On 3/15/2021 7:45 PM, Guido van Rossum wrote:
>
> Good proposal! I have a few questions.
>
> On Mon, Mar 15, 2021 at 2:22 PM Eric V. Smith wrote:
>
>> [I'm sort of loose with the terms field, parameter, and argument here.
>> Forgive me: I think it's still understandable. Also I'm not specifying
>> types here, I'm using Any everywhere. Use your imagination and
>> substitute real types if it helps you.]
>>
>> Here's version 2 of my proposal:
>>
>> There have been many requests to add keyword-only fields to dataclasses.
>> These fields would result in __init__ parameters that are keyword-only.
>>
>> In a previous proposal, I suggested also including positional arguments
>> for dataclasses. That proposal is at
>>
>> https://mail.python.org/archives/list/python-ideas@python.org/message/I3RKK4VINZUBCGF2TBJN6HTDV3PVUEUQ/
>> . After some discussion, I think it's clear that positional arguments
>> aren't going to work well with dataclasses. The deal breaker for me is
>> that the generated repr would either not work with eval(), or it would
>> contain fields without names (since they're positional). There are
>> additional concerns mentioned in that thread. Accordingly, I'm going to
>> drop positional arguments from this proposal.
>>
>> Basically, I want to add a flag to each field, stating whether the field
>> results in a normal parameter or a keyword-only parameter to __init__.
>> Then when I'm generating __init__, I'll examine those flags and put the
>> normal arguments first, followed by the keyword-only ones.
>>
>> The trick becomes: how do you specify what type of parameter each field
>> represents?
>>
>>
>> What attrs does
>> ---
>>
>> First, here's what attrs does. There's a parameter to their attr.ib()
>> function (the moral equivalent of dataclasses.field()) named kw_only,
>> which if set, marks the field as being keyword-only. From
>> https://www.attrs.org/en/stable/examples.html#keyword-only-attributes :
>>
>> >>> @attr.s
>> ... class A:
>> ... a = attr.ib(kw_only=True)
>> >>> A()
>> Traceback (most recent call last):
>>...
>> TypeError: A() missing 1 required keyword-only argument: 'a'
>> >>> A(a=1)
>> A(a=1)
>>
>> There's also a parameter to attr.s (the equivalent of
>> dataclasses.dataclass), also named kw_only, which if true marks every
>> field as being keyword-only:
>>
>> >>> @attr.s(kw_only=True)
>> ... class A:
>> ... a = attr.ib()
>> ... b = attr.ib()
>> >>> A(1, 2)
>> Traceback (most recent call last):
>>...
>> TypeError: __init__() takes 1 positional argument but 3 were given
>> >>> A(a=1, b=2)
>> A(a=1, b=2)
>>
>>
>> dataclasses proposal
>>
>>
>> I propose to adopt both of these methods (dataclass(kw_ony=True) and
>> field(kw_only=True) in dataclasses. The above example would become:
>>
>> >>> @dataclasses.dataclass
>> ... class A:
>> ... a: Any = field(kw_only=True)
>>
>> >>> @dataclasses.dataclass(kw_only=True)
>> ... class A:
>> ... a: Any
>> ... b: Any
>>
>> But, I'd also like to make this a little easier to use, especially in
>> the case where you're defining a dataclass that has some normal fiel
[Python-ideas] Re: Installer/target architecture mismatch
Can you file a bug for this on bpo and add Steve Dower to the nosy list? On Fri, Mar 19, 2021 at 17:04 Dany Lisiansky wrote: > An odd suggestion/request here, hope it's the right place to discuss it. > > So I was trying to install python on the Xbox series S (yup..), so far I > got the embedded x86_64 version for windows to work, however, I was unable > to get packages to install properly. > I'm not familiar enough with Windows to know how the installation is > supposed to be laid out, but I figured it might be just a side affect from > using the embedded version. > Now I need to mention that the Xbox is an odd NT based system, it can run > win32/UWP apps, but it comes with a strict requirement of x86_64 and > therefore has no SysWoW64 to support i386. > Naturally, I tried to use the distributed installer, and that's when I > found out that the x86_64 installer itself was in fact compiled for i386. > I can compile a one-off build for myself and go on with my life, but I > also realized it's an oversight because the installer should never assume > the target system has backwards compatibility for older architectures and > stick to the target architecture throughout the installation phase. > > I know It's an extreme edge case, but I guess it's valid and make sense. > Let me know what you think, and how (or if) I should proceed from here. > > DanyL. > ___ > 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/C7UQTGKJCSHBMIXGRMRDSZJOL3LLQF2Q/ > 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/BZADOG37KZ3N2KFZNSQXLMECMEWQFAKT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Looking for people interested in a Python register virtual machine project
On Sun, Mar 21, 2021 at 3:35 PM Chris Angelico wrote:
> On Mon, Mar 22, 2021 at 7:49 AM Ben Rudiak-Gould
> wrote:
> >
> > In the "Object Lifetime" section you say "registers should be cleared
> upon last reference". That isn't safe, since there can be hidden
> dependencies on side effects of __del__, e.g.:
> >
> > process_objects = create_pipeline()
> > output_process = process_objects[-1]
> > return output_process.wait()
> >
> > If the process class terminates the process in __del__ (PyQt5's QProcess
> does), then implicitly deleting process_objects after the second line will
> break the code.
> >
>
> Hang on hang on hang on. After the second line, there are two
> references to the last object, and one to everything else. (If
> create_pipeline returns two objects, one for each end of the pipe,
> then there are two references to the second one, and one to the
> first.) Even if you dispose of process_objects itself on the basis
> that it's not used any more (which I would disagree with, since it's
> very difficult to manage that well), it shouldn't terminate the
> process, because one of the objects is definitely still alive.
>
In the hypothetical scenario, presumably create_pipeline() returns a list
of process objects, where the process class somehow kills the process when
it is finalized. In that case dropping the last reference to
process_objects[0] would kill the first process in the pipeline. I don't
know if that's good API design, but Ben states that PyQt5 does this, and it
could stand in for any number of other APIs that legitimately destroy an
external resource when the last reference is dropped. (E.g., stdlib
temporary files.)
Curiously, this is about the opposite problem that we would have if we were
to replace the current reference counting scheme with some kind of
traditional garbage collection system.
> This is nothing to do with a register-based VM and everything to do
> with standard Python semantics, so this can't change.
>
Exactly. The link with a register-based VM is that if we replaced the value
stack with temporary local variables (as the "register-based" VM scheme
does), we'd have to decide on the lifetimes of those temporary variables.
Finalizing them when the function returns might extend the lifetimes of
some objects compared to the stack-based scheme. But finalizing all local
variables (temporary or not) as soon as they are no longer needed by
subsequent code could *shorten* the lifetimes, as in the above example.
A reasonable solution would be to leave the lifetimes of explicitly named
locals alone, but use the proposed ("as soon as possible") scheme for
temporary variables. This would appear to match how values on the value
stack are treated. Honestly that's how I read the quoted section of Skip's
proto-PEP (since it explicitly mentions registers). A version of the
example that exhibits the same questionable behavior would be this:
return create_pipeline()[-1].wait()
Presumably this would not work correctly with the PyQt5 process class.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/VRHX3JRVL6ZDXHBLWVNNYTMPGW5ERYBH/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Looking for people interested in a Python register virtual machine project
As I wrote, Skip’s Porto+PEP is not proposing to delete locals that are not used in the rest of the function, only registers. So the voiced concerns don’t apply. On Sun, Mar 21, 2021 at 23:59 Chris Angelico wrote: > On Mon, Mar 22, 2021 at 5:37 PM Ben Rudiak-Gould > wrote: > > > > On Sun, Mar 21, 2021 at 11:10 PM Chris Angelico > wrote: > >> > >> At what point does the process_objects list cease to be referenced? > >> After the last visible use of it, or at the end of the function? > > > > > > In Python as it stands, at the end of the function, as you say. > > > > Skip Montanaro's PEP suggested that in his register machine, locals > would be dereferenced after their last visible use. I don't think that's > intrinsically a bad idea, but it's not backward compatible. The thing with > the process objects was just an example of currently working code that > would break. > > > > The example has nothing to do with PyQt5 really. I just happen to know > that QProcess objects kill the controlled process when they're collected. I > think it's a bad design, but that's the way it is. > > > > Another example would be something like > > > > td = tempfile.TemporaryDirectory() > > p = subprocess.Popen([..., td.name, ...], ...) > > p.wait() > > > > where the temporary directory will hang around until the process exits > with current semantics, but not if td is deleted after the second line. Of > course you should use a with statement in this kind of situation, but > there's probably a lot of code that doesn't. > > > > Thanks for the clarification. I think the tempfile example will be a > lot easier to explain this with, especially since it requires only the > stdlib and isn't implying that there's broken code in a third-party > library. > > I don't like this. In a bracey language (eg C++), you can declare that > a variable should expire prior to the end of the function by including > it in a set of braces; in Python, you can't do that, and the normal > idiom is to reassign the variable or 'del' it. Changing the semantics > of when variables cease to be referenced could potentially break a LOT > of code. Maybe, if Python were a brand new language today, you could > define the semantics that way (and require "with" blocks for anything > that has user-visible impact, reserving __del__ for resource disposal > ONLY), but as it is, that's a very very sneaky change that will break > code in subtle and hard-to-debug ways. > > (Not sure why this change needs to go alongside the register-based VM, > as it seems to my inexpert mind to be quite orthogonal to it; but > whatever, I guess there's a good reason.) > > 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/C3CUQYW3TQGJHC7SP5B4QJXFDV2XTEXB/ > 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/5TBFVUF6OTDFWQHEAC6ZJ4LQ64D5DZWA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Looking for people interested in a Python register virtual machine project
On Tue, Mar 23, 2021 at 12:40 PM Skip Montanaro wrote: > I've not attempted to make any changes to calling conventions. It > occurred to me that the LOAD_METHOD/CALL_METHOD pair could perhaps be > merged into a single opcode, but I haven't really thought about that. > Perhaps there's a good reason the method is looked up before the > arguments are pushed onto the stack (call_function()?). In a > register-based VM there's no need to do things in that order. > IIRC the reason is that Python's language reference promises left-to-right evaluation here. So o.m(f()) needs to evaluate o.m (which may have a side effect if o overrides __getattr__) before it calls f(). -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/BKYWRGTA3J3ZEJXLZPPTUCZWKJGA7OSR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python Idea - extension of 'with'
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
Please. Use. set().
On Sat, Apr 10, 2021 at 02:03 Serhiy Storchaka wrote:
> 09.04.21 19:08, 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.
>
> Do you think that {,} does not need to be taught? It is a new special
> syntax which needs paragraphs in tutorial and language reference. In
> contrary, {*()} is a simple combination of already described syntax
> elements.
>
> > It also doesn't give quite the
> > optimization as {,}.
>
> It is a trivial optimization. It was not implemented yet only because
> such code is never used in tight loops, empty set creation is very rare
> operation at all. We prefer to keep the compiler simpler and focus on
> optimizing common operations which has significant effect.
>
> ___
> 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/ASBHWYDCPR3D2FCVLGPHELPRJUJOWHLL/
> 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/MWBML4BCZ5I3OR2L64JW7WZLZSUTU6GJ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add an export keyword to better manage __all__
On Sun, Mar 14, 2021 at 10:55 PM Ethan Furman wrote: > I completely agree with this. One of the hallmarks of Python is the > ability to query, introspect, and modify Python code. It helps with > debugging, with experimenting, with fixing. Indeed, one of the few > frustrating bits about Python is the inability to work with the C portions > as easily as the Python portions (note: I am /not/ suggesting we do away > with the C portions). > > What would be the benefits of locking down modules in this way? I owe you an answer here. For large projects with long lifetimes that expect their API to evolve, experience has taught that any part of the API that *can* be used *will* be used, even if it was clearly not intended to be used. And once enough users have code that depends on reaching into some private part of a package and using a method or attribute that was available even though it was undocumented or even clearly marked as "internal" or "private", if an evolution of the package wants to remove that method or attribute (or rename it or change its type, signature or semantics/meaning), those users will complain that the package "broke their code" by making a "backwards incompatible change." For a casually maintained package that may not be a big deal, but for a package with serious maintainers this can prevent ordered evolution of the API, especially since a package's developers may not always be aware of how their internal attributes/methods are being used or perceived by users. So experienced package developers who are planning for the long term are always looking for ways to prevent such situations (because it is frustrating for both users and maintainers). Being able to lock down the exported symbols is just one avenue to prevent disappointment in the future. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/XDLAAQKWDSPOJ6HKVTBEZEK6KYM5PQGP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add an export keyword to better manage __all__
Wow, super helpful response. On Mon, Apr 12, 2021 at 1:26 PM Brendan Barnwell wrote: > On 2021-04-12 03:13, Stéfane Fermigier wrote: > > The public API of a library is the one which is documented as > > such. > > > > > > Right, except that in practice: > > > > 1) Many useful libraries are not documented or properly documented. > > Then they're buggy. I'm not convinced by the argument that "in > practice" people do things they shouldn't do and that therefore we > should encourage them to do more of that. > > > 2) People don't read the docs (at least not always, and/or not in > details). > > Insofar as someone relies on behavior other than that given in the > docs, they are being foolish. Again, I'm not convinced by the argument > that "in practice" people do foolish things and that therefore we should > encourage them to do more of that. > > -- > Brendan Barnwell > "Do not follow where the path may lead. Go, instead, where there is no > path, and leave a trail." > --author unknown > ___ > 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/DWI2MI3FRPRNOC7AS6CC3YBWLOOVZYZA/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/F57J672KTTK6FRA7ITRUVTRYBF2A3P57/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`
On Sun, May 9, 2021 at 5:08 PM Chris Angelico wrote: > On Mon, May 10, 2021 at 9:57 AM Steven D'Aprano > wrote: > > > > On Sun, May 09, 2021 at 04:45:55PM -, Thomas Grainger wrote: > > > > > now that python2.7 is EOL, it might be worth resurrecting this syntax > > [...] > > > except E1, E2, E3 as e: > > > > What advantages will this new syntax bring us? > > > > Will it allow us to do things that we can't currently do? > > > > When would you use it in preference to the existing syntax? By this I > > mean both under what circumstances, and at what time (tomorrow? in a > > year? in ten years?). > > > > Is there an aim beyond saving two characters? > > > > It would remove a level of frustration. I've watched a lot of novice > programmers, and some intermediate programmers, run into a source of > (now completely unnecessary) pain that changing this: > > except ValueError: > > into this: > > except ValueError, TypeError: > > doesn't work. Yes, it's a quick SyntaxError, but the editor won't show > it up (since most editors are Python 2 compatible, and wouldn't be > checking this level of syntax anyway), so there's X amount of time > spent coding, then go to run the thing, and it won't work the way they > expect it to. > We've had arguments like this before, and we've usually taken the position that we shouldn't compromise the language to cater to imperfect tools. Editors that are Python-aware should just catch up with Python 3 syntax. Editors that don't check this level of syntax definitely shouldn't be used as motivation at all. (I just tried this in the latest VS Code Insiders edition, and the Python support does catch this.) Also, I wonder what made those users think to try that? Maybe they read a tutorial or StackOverflow issue suggesting the Python 2 syntax? > If it weren't for the Python 2 issues, would there be any good reason > for demanding parentheses? We don't need them in a for loop: > > for i, thing in enumerate(stuff): > Someone else (Steven?) already pointed out in this thread that there are other places where 'as ' or 'as ' as used, the relative precedence of commas and 'as' is different than the proposal here: import foo.bar as foobar, bar.foo as barfoo is parsed as import (foo.bar as foobar), (bar.foo as barfoo) Similarly, with something as foo, something_else as bar: ... is parsed as with (something as foo), (something_else as bar): ... And similar in pattern matching. It's true that adding "as e" makes it read oddly, but that's the only > real point against it - other than a question of "when". > I think never is a perfectly fine answer. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/7XREC6PDF2YG55WVDXHJHWZQJNYJIC7X/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: division of integers should result in fractions not floats
I should probably explain (again) why I am not a fan of such a change. I blogged about this before -- this is mostly a treatise about / vs. //, but it explains my reservations about this proposal as well: http://python-history.blogspot.com/2009/03/problem-with-integer-division.html In particular: """ For example, in ABC, when you divided two integers, the result was an exact rational number representing the result. [...] In my experience, rational numbers didn't pan out as ABC's designers had hoped. A typical experience would be to write a simple program for some business application (say, doing one’s taxes), and find that it was running much slower than expected. After some debugging, the cause would be that internally the program was using rational numbers with thousands of digits of precision to represent values that would be truncated to two or three digits of precision upon printing. This could be easily fixed by starting an addition with an inexact zero, but this was often non-intuitive and hard to debug for beginners. """ -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/3J5DRJLHZYL33ZBTN4SOR7PNYEZ3IKYC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Fractions vs. floats - let's have the cake and eat it
On Tue, May 18, 2021 at 12:39 AM Martin Teichmann < martin.teichm...@gmail.com> wrote: > [...] > To give an example (this is not fake, but from the prototype): > > >>> 2/5 > 0.4 > >>> (2/5).denominator > 5 > >>> isinstance(2/5, float) > True > >>> type(2/5) > > > Note that this is only done at compile time, no such behavior is done at > run time, everything just behaves like normal floats: > > >>> two=2 > >>> five=5 > >>> (two/five) > 0.4 > >>> (two/five).numerator > Traceback (most recent call last): > File "", line 1, in > AttributeError: 'float' object has no attribute 'numerator' > This violates a basic property of Python. If 1/2 has a certain property, then `x = 1; y = 2; x/2` should have the same property. Please don't go down this road. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/R3B7CA4KSOVECDRHCSYSXPNEHGOYZP5C/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: symbolic math in Python
Oh no, not the vertical bar hack. :-( ___ 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/B4XH4Q5PJNE65DHHIIMIZ76XSXBE4Y2T/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Bring back PEP 501
64 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >> >Registered at Amtsgericht Duesseldorf: HRB 46611 >> >https://www.egenix.com/company/contact/ >> > https://www.malemburg.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/FXSHIJ5TV6ZRN2D74FEFEGSHTB4LKGQJ/ >> > Code of Conduct: http://python.org/psf/codeofconduct/ >> > >> >> -- >> Marc-Andre Lemburg >> eGenix.com >> >> Professional Python Services directly from the Experts (#1, May 08 2021) >> >>> Python Projects, Coaching and Support ...https://www.egenix.com/ >> >>> Python Product Development ...https://consulting.egenix.com/ >> >> >> ::: We implement business ideas - efficiently in both time and costs ::: >> >>eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >>Registered at Amtsgericht Duesseldorf: HRB 46611 >>https://www.egenix.com/company/contact/ >> https://www.malemburg.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/MYKV5BUW4IBSWRDNIUARKAHXM4R5HZO3/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/36ZVYYCEOZLOJJWXGSMK2L6FZ7ZLS24B/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
Andre, did you have an experience where something related to Ellipsis/... confused you? It is not clear to me what exactly prompted you to single out Ellipsis (or it’s repr()?) On Mon, May 31, 2021 at 08:37 André Roberge wrote: > > > On Mon, May 31, 2021 at 12:20 PM MRAB wrote: > >> On 2021-05-31 15:55, Paul Bryan wrote: >> > If you're proposing prevention of monkey patching Ellipsis, I think >> > you'll have to go all-in on all builtins. >> > >> > For example: >> > >> str = int >> > >> str >> > >> > >> > >> str == int >> > >> > True >> > >> > >> If you rebind str to int, the repr of str will say , so you >> can tell that something's happened, but the repr of ... is always >> 'Ellipsis', even though you've rebound Ellipsis. >> > > Exactly. > > Thinking some more about it, perhaps the confusion would be sufficiently > reduced if the repr of '...' would be 'Ellipsis (...)', and use this repr > to appear in error messages rather than simply the name Ellipsis. > > > >> >> > >> > On Mon, 2021-05-31 at 11:37 -0300, André Roberge wrote: >> >> In Python `...` is referred to as `Ellipsis` and cannot be assigned to. >> >> Yet, one can assign any value to the name `Ellipsis`. >> >> >> >> Consider the following: >> >> >> >> ``` >> >> >>> ... >> >> Ellipsis >> >> >>> ... == Ellipsis >> >> True >> >> >>> Ellipsis >> >> Ellipsis >> >> >>> Ellipsis = 3 >> >> >>> Ellipsis >> >> 3 >> >> >>> ... = 4 >> >> File "", line 1 >> >> ... = 4 >> >> ^ >> >> SyntaxError: cannot assign to Ellipsis >> >> >>> # But I just did assign a new value to the name Ellipsis above. >> >> >>> Ellipsis >> >> 3 >> >> >>> ... >> >> Ellipsis >> >> >>> ... == Ellipsis >> >> False >> >> ``` >> >> >> >> For consistency, `Ellipsis` (the name) should **always** refer to the >> >> same object that `...` refers to, so that both could not be assigned a >> >> new value. >> >> >> ___ >> 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/NE2FAW3XDFYUIMILV4BC2XT6VKLC4P6V/ >> 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/DIRDIQFK72LFHYJNAD5BWL3L5SPAUMVM/ > 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/DWOVJOTJZQGTLVDEQ76XAI5ZD4M3KSCI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Custom-Strings: Combine f-strings and condtional_escape()
PEP 501 is unlikely to be accepted *as is*. But it’s still a good starting point. Personally I would look for inspiration towards JavaScript template literals ( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals), combined with f-string-like interpolation. On Fri, Jun 4, 2021 at 07:24 Matt del Valle wrote: > Interpolation templates were recently brought up here ( > https://mail.python.org/archives/list/python-ideas@python.org/thread/5AW73ICBD4CVCRUNISRNAERPPF2KSOGZ/), > and Guido mentioned that in his opinion the SC would be unlikely to > reconsider PEP 501 in its current state. I trust that he has a much better > insight into this sort of thing than the rest of us, so he's likely right, > but if I'm honest I wasn't able to find any of the actual reasons why PEP > 501 was deferred in the Rationale or Discussion sections of the PEP. > > If anyone has any insight into the actual reasons why PEP 501 might be > considered unworkable in its current state, I'd be really curious to find > out what they are. It's hard to argue in favor of a feature if you don't > know what the actual arguments against it are. > > The rationale for it at least seems quite solid to me, as it provides > powerful templating and injection-safety functionality. It's not a purely > hypothetical feature either, as it has been quite successful in other > languages like C#. > > If the success of f-strings over the last five years is anything to go by, > people also seem to overwhelmingly prefer this style of string formatting > compared to `str.format` or `%` formatting. I literally can't think of a > single modern Python codebase I've seen lately where f-strings weren't the > main method of string-formatting employed. > > Is it something in the implementation then? Or something else? > > On Fri, Jun 4, 2021 at 1:37 PM Chris Angelico wrote: > >> On Fri, Jun 4, 2021 at 10:02 PM Thomas Güttler >> wrote: >> > >> > Hi, >> > >> > I have a crazy idea how to extend Python for web development. >> > >> > What do you think? What are the next steps? >> > >> > [chomp details] >> >> Something like this - but more generic - has been proposed already: >> >> https://www.python.org/dev/peps/pep-0501/ >> >> There've been a few variants on the idea, but I think PEP 501 is the >> best summary. >> >> If you want to press forward with this, I think that would be the best >> starting point. >> >> 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/WZHFKMUKSSS6LLJGQUX7DVGP5EOL7M46/ >> 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/PWZALQJKKECGNAWT4SA63AVT6HUPIAF3/ > 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/KI6U4RWFWZQUBAJTUI44TYZEBXJEIZJG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Custom-Strings: Combine f-strings and condtional_escape()
On Fri, Jun 4, 2021 at 3:08 PM Thomas Güttler wrote: > > > Am Fr., 4. Juni 2021 um 19:20 Uhr schrieb Guido van Rossum < > gu...@python.org>: > >> PEP 501 is unlikely to be accepted *as is*. But it’s still a good >> starting point. >> >> > OK, before starting a new project, it maybe makes sense to finish the > first. > > Why not reject PEP-501 officially? Maybe with a reason. Then we know > what's wrong with it. > You'd have to ask its author. Most likely he'll just withdraw the PEP completely without telling you anything more. In short, I don't think you're going to get much out of trying to get anyone to say anything "official" about PEP 501. If you really want to know more, you could probably dig up the discussions around that PEP and learn from that. > After that is done, we can think about a new start. > There's no need to wait for that. > What do you think? > > > > > >> Personally I would look for inspiration towards JavaScript template >> literals ( >> >> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals), >> combined with f-string-like interpolation. >> >> > I personally really would like to avoid the dollar sign which gets used in > JS template literals. > Well of course. The Python equivalent would use the exact same interpolation syntax as f-strings (and before it, str.format()). -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/7O5NKN3XUJQJLC3S6JGPT7QBVPD3GUUF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Define functions without parentheses (if no parameters given)
On Fri, Jun 11, 2021 at 7:47 AM Jelle Zijlstra wrote: > > El jue, 10 jun 2021 a las 19:30, Cameron Simpson () > escribió: > >> On 11Jun2021 10:01, Cameron Simpson wrote: >> >> It also struck me: functions with _no_ parameters are pretty rare. >> >> [...] >> > I got curious so I checked a large codebase I have access to. Out of 85540 > functions, 8244 take no arguments. Many of them are test functions. > I'm sure the idea is dead now, but it reminds me of an amusing anecdote I heard in college. You may not have heard of a language named Algol-68, but it was a big thing when I learned programming in Amsterdam in the late '70s. Like its predecessor, Algol-60, it had a feature where parameter-less functions could both be *defined* and *called* without parentheses. Now, in Algol-60, this was easy, because there were no function pointers, so whenever the compiler saw the name of a parameter-less function, it would generate the code to call it. (Example: "x := random*2".) But Algol-68 *did* have function pointers, so the language design committee had to introduce a complicated wrinkle into the type system so that you could write things like "f := random" (interpreting it as a function pointer) but also "x := 2*random" (calling it). The distinguishing property was the type of the receiving end (i.e., f had to be declared as a parameterless function pointer, and x had to be a number). So one of the classes I took near the end of my studies was taught by the lead author of Algol-68 (Adriaan van Wijngaarden). He was well respected and near retirement age, so he could do what he wanted in class, and sometimes he just told anecdotes from the past (I'd love such a job :-). One day the issue with parameter-less functions came up, and by then a new language named C had gained some notoriety. C, of course, has function pointers and parameter-less functions, but both the declaration and the call must use an empty pair of parentheses (i.e, "x = 2*random()", like Python). Van Wijngaarden told us, somewhat ruefully, that, had the design committee known that programmers would be happy to write that empty pair of parentheses, they would have been able to simplify a significant corner of Algol-68's type system. This was one of the seminal ideas that went into Python's design. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/DQGLY3ZLFMGVOC4JE7E2TLMWDROK2PAE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Deprecate sum of lists
Just trolling along, flattening a list could be written as functools.reduce(list.__iadd__, xs, []) Right? On Wed, Jun 16, 2021 at 22:53 David Mertz wrote: > On Thu, Jun 17, 2021, 1:38 AM Chris Angelico > >> >>> list(chain.from_iterable(list_of_lists)) >> >> > More-itertools has flatten(): >> https://more-itertools.readthedocs.io/en/stable/api.html#more_itertools.flatten. >> That seems better than a method specific to lists. >> >> ... which is built on top of chain.from_iterable. :) >> > > Oh, of course. And anyone can put it in their personal utility library > too. I just meant it in the sense that the name might be more intuitive to > beginners. > >> ___ > 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/2T53ADB3TVQJF2UENEXKB5G5ZWTQOQVW/ > 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/QTXUMBUHFWBG572NPD6YUNT3FEUCIDEC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Deprecate sum of lists
Wow, strong language. Not really helping people see it your way. On Thu, Jun 17, 2021 at 14:26 Ben Rudiak-Gould wrote: > On Thu, Jun 17, 2021 at 12:37 AM Serhiy Storchaka > wrote: > >> And it is equivalent to pure Python code >> >> [x for chunk in list_of_lists for x in chunk] >> > > Okay, slightly off-topic, but can we *please* allow > > [*chunk for chunk in list_of_lists] > > some day. I think it was left out because some discussion concluded it > would be too confusing, which is ridiculous. I assumed it would work and > was confused to find that it didn't. It's blatantly inconsistent. > > It's not even the performance I care about, it's the unreadability of > having an extra "for i_have_to_think_of_yet_another_variable_name in > whatever" at the end of the list comprehension (at maximum distance from > where the variable is used). I've wished for this feature ridiculously many > times. > > >> It would be >> possible to make the compiler recognizing such pattern and generating >> more efficient bytecode (LIST_EXTEND instead of an internal loop with >> LIST_APPEND), but I am not sure that this case is common enough to >> complicate the compiler. >> > > In my personal experience it's very common. > > ___ > 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/YH7COSZIV5BWQ3EOEA5MQMBHMB3OQNND/ > 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/7C6VIG52AEBKTEE4KD5MIGTHINEFWZEG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Deprecate sum of lists
On Fri, Jun 18, 2021 at 00:43 Serhiy Storchaka wrote: > 18.06.21 00:22, Ben Rudiak-Gould пише: > > Okay, slightly off-topic, but can we *please* allow > > > > [*chunk for chunk in list_of_lists] > > > > some day. I think it was left out because some discussion concluded it > > would be too confusing, which is ridiculous. I assumed it would work and > > was confused to find that it didn't. It's blatantly inconsistent. > > It was originally proposed in PEP 448 (Additional Unpacking > Generalizations) but was excluded after discussing. > > If we allow > > [*chunk for chunk in list_of_lists] > > we should allow also > > [x, y for x in a] > > which would be equivalent to > > [a[0], y, a[1], y, a[2], y, ...] Note the ambiguity around whether the user might have meant [x,(y for y in a)] or [(x, y) for y in a] That’s a good enough reason for me to also disallow *chunks. -- --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/6I63FWKEDQ4RJPUL4CQK22KFCKIIPU5X/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Deprecate sum of lists
On Fri, Jun 18, 2021 at 8:40 PM Steven D'Aprano wrote:
> On Fri, Jun 18, 2021 at 07:38:49AM -0700, Guido van Rossum wrote:
>
> > Note the ambiguity around whether the user might have meant
> >
> > [x,(y for y in a)]
> >
> > or
> >
> > [(x, y) for y in a]
>
> We already have a rule to disambiguate generator comprehensions: they
> must always be parenthesized unless they are already parenthised:
>
> g = (y for y in a) # parens required
> t = 999, (y for y in a) # parens required
>
> func((y for y in a)) # inner parens optional
>
Yes, that's exactly what I was referring to.
> That’s a good enough reason for me to also disallow *chunks.
>
> That's an odd way to look at it. We must disallow an unambiguous syntax
> because a completely different syntax would have been ambiguous if we
> didn't already have a rule in place that disambiguates it.
>
Maybe, but the two are not unrelated. In other contexts, when we accept
"*chunk", and 'chunk' equals "1, 2", we also accept "1, 2" in the original
position, and it means the same thing. This is useful as an explanation of
the semantics of the unary '*' operator[1]. For example
# Given:
chunk = 1, 2
# Equivalent:
f(*chunk)
f(1, 2)
# Equivalent:
[*chunk]
[1, 2]
So then if we were to allow this:
[*chunk for chunk in ...]
we ought to consider this equivalent:
[1, 2 for chunk in ...]
(Note there's nothing that says the expressions to the left of 'for' need
to involve the for-control variable 'chunk'. :-)
Now, this shouldn't be considered an airtight argument against [*chunk for
...], but it does show that there's no straightforward explanation of its
meaning through equivalence (like the OP seemed to think), and I think this
is what Serhiy was also getting at in his post.
__
[1] Does the unary star operator have a name when used like this in Python?
In JavaScript the equivalent syntax ("...chunk", where the "..." are a
literal ellipsis) is called "spread". We could borrow this term.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/M5U7L54BRZU6KSI42RGZBOPIS4R4HGNJ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Deprecate sum of lists
On Fri, Jun 18, 2021 at 10:15 PM Steven D'Aprano
wrote:
> On Fri, Jun 18, 2021 at 09:33:49PM -0700, Guido van Rossum wrote:
>
> > Now, this shouldn't be considered an airtight argument against [*chunk
> for
> > ...], but it does show that there's no straightforward explanation of its
> > meaning through equivalence (like the OP seemed to think), and I think
> this
> > is what Serhiy was also getting at in his post.
>
> Indeed. I was initially confused by what Ben thought was a simple and
> obvious connection between star unpacking in some other contexts and his
> suggestion for comprehensions. The analogy with `[*a]` never crossed my
> mind, and I don't think that we should look at this as literally the
> application of sequence unpacking in a comprehension, for reasons I gave
> in my earlier post.
>
> But having it explained to me, I think that treating this as an analogy
> rather than literal unpacking works. We already give unary star and
> double star a number of meanings, not all of which are related:
>
>
> - import wildcard;
>
> - capture positional and keyword parameters `def func(*args, **kw)`
>
> - sequence and keyword unpacking in function calls;
>
> - sequence capture in assignment targets `head, *a, tail = items`
>
> - sequence unpacking in list etc displays;
>
>
> Have I missed any?
>
What you seem to be (intentionally) missing is that all but the import
wildcard *are* closely related, even though they are specified separately
in the syntax. (Saying that they are unrelated would be like saying that
the name occurring after a 'def' keyword and the function name occurring in
a function call are unrelated. :-)
> We could define *star comprehensions* as syntactic sugar for nested
> comprehensions, to aid in flattening nested sequences and mappings.
>
> [*expression for name in sequence if condition]
>
> results in this:
>
> result = []
> for name in sequence:
> if condition:
> for tmp in expression:
> result.append(tmp)
> return result
>
> I haven't thought deeply into this, but I think that if the starred
> expression is anything but a simple name, it may require parentheses?
>
> *name # okay
> *(name.attr or []) # everything else needs parens
>
The grammar for the last three forms you give allows pretty much any
expression, for example
https://github.com/python/cpython/blob/291848195f85e23c01adb76d5a0ff9c6eb7f2614/Grammar/python.gram#L504-L506
> Alternatively, we could just do something that people have been asking
> about since Python 1.5 and provide a flatten builtin or list method :-)
>
Probably a builtin, since in my mind I want to write flatten(a), never
a.flatten(), and it would be useful for any kind of sequence of sequences
(or even iterable of iterables).
I think I would find flatten(a) more readable than [*chunk for chunk in a],
and more discoverable: this operation is called "flatten" in other
languages, so users are going to search the docs or help for that.
But there could be endless debate about whether flatten( ("x", "y") )
should return a list or a tuple...
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/KTZLOA6DIRIJ4QHCZBVQGD36AX6JZQ5V/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes
Would a static type checker have found this? On Fri, Jun 25, 2021 at 02:07 Thomas Grainger wrote: > I was debugging some code that was using TLSv1.2 when I expected it to > only support TLSv1.3, I tracked it down to a call to: > > context.miunimum_version = ssl.TLSVersion.TLSv1_3 > > it should have been: > > context.minimum_version = ssl.TLSVersion.TLSv1_3 > > I'd like invalid attribute assignment to be prevented at runtime > ___ > 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/RPD5OICSY3KLVXKIYWFTABNIA7F7YWG3/ > 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/BHZNLW2647Z6KYRP672J63RJ7CDGUUVV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes
On Fri, Jun 25, 2021 at 8:22 AM Bluenix wrote: > I am not fully aware of how ssl.SSLContext is used, but adding __slots__ > would prevent this. You would see an error similar to: AttributeError: > 'MyClass' object has no attribute 'my_attribute' > That's a reasonable solution, except that it's not backwards compatible. It's possible that there is code out there that for some reason adds private attributes to an SSLContext instance, and using __slots__ would break such usage. (They could perhaps fix their code by using a dummy subclass, but that could well become a non-trivial change to their code, depending on where they get their SSLContext instances.) So unless there's evidence that nobody does that, we're stuck with the status quo. I'm adding Christian Heimes to the thread in case he has a hunch either way. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/U7N5K542MGEAC3VXDPJEVUV4OPB6QJ2P/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes
On Fri, Jun 25, 2021 at 11:42 AM Chris Angelico wrote: > On Sat, Jun 26, 2021 at 4:20 AM Guido van Rossum wrote: > > > > On Fri, Jun 25, 2021 at 8:22 AM Bluenix wrote: > >> > >> I am not fully aware of how ssl.SSLContext is used, but adding > __slots__ would prevent this. You would see an error similar to: > AttributeError: 'MyClass' object has no attribute 'my_attribute' > > > > > > That's a reasonable solution, except that it's not backwards compatible. > It's possible that there is code out there that for some reason adds > private attributes to an SSLContext instance, and using __slots__ would > break such usage. (They could perhaps fix their code by using a dummy > subclass, but that could well become a non-trivial change to their code, > depending on where they get their SSLContext instances.) > > > > So unless there's evidence that nobody does that, we're stuck with the > status quo. I'm adding Christian Heimes to the thread in case he has a > hunch either way. > > > > Another possible solution - although I'm not sure how practical this > would be - would be to have __init__ accept only specific keyword > arguments. You could do something like: > > ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT, > minimum_version=ssl.PROTOCOL_TLSv1_1) > > and it would work, but if you misspell "minimum_version", it would > error out. That's actually what I expected it to do, based on the > signature; but it doesn't, it simply ignores the argument. Not > actually sure what it does with kwargs. > But that's not what the OP wrote -- his code used an attribute assignment. It looks like SSLContext just throws the *args and **kwds away. You *must* set the attribute. I don't know why it has *args and **kwds at all -- maybe so that you can subclass it and define an __init__ that takes those? It all seems a mystery to me. I've never used this directly -- I've always just used urllib's default for https URLs. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/HVOEIESRKDOZMZ7RVQEQFK23HJ6TTTC7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes
On Fri, Jun 25, 2021 at 12:17 PM Christian Heimes wrote: > On 25/06/2021 20.17, Guido van Rossum wrote: > > On Fri, Jun 25, 2021 at 8:22 AM Bluenix > <mailto:bluenix...@gmail.com>> wrote: > > > > I am not fully aware of how ssl.SSLContext is used, but adding > > __slots__ would prevent this. You would see an error similar to: > > AttributeError: 'MyClass' object has no attribute 'my_attribute' > > > > > > That's a reasonable solution, except that it's not backwards compatible. > > It's possible that there is code out there that for some reason adds > > private attributes to an SSLContext instance, and using __slots__ would > > break such usage. (They could perhaps fix their code by using a dummy > > subclass, but that could well become a non-trivial change to their code, > > depending on where they get their SSLContext instances.) > > > > So unless there's evidence that nobody does that, we're stuck with the > > status quo. I'm adding Christian Heimes to the thread in case he has a > > hunch either way. > > I agree, it is a backwards incompatible change. Also __slots__ won't > work. The class has class attributes that can be modified in instances. > Oh, I see. There are two class attributes, sslsocket_class and sslobject_class, and their docs say they can be overridden per instance. Could we perhaps create a custom descriptor that allows both per-instance and per-class assignment and lookup? > You cannot have attributes that are both class and instance attributes > with __slots__. We'd have to overwrite __setattr__() and block unknown > attributes of exact instances of ssl.SSLContext. > Well, if we don't think it's supported behavior to subclass SSLContext, perhaps we could do that. The bug in the OP's code (misspelling minimum_version in assignment) is pretty hard to find. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/VGSFW6UXY7NRHZ6OUWJMXABFVVFMHIQN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)
FWIW, we could make f-strings properly nest too, like you are proposing for backticks. It's just that we'd have to change the lexer. But it would not be any harder than would be for backticks (since it would be the same algorithm), nor would it be backward incompatible. So this is not an argument for backticks. Separately, should there be a way to *delay* evaluation of the templated expressions (like we explored in our private little prototype last year)? -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/E5JBLCI3J357CCEKNC7ME5ZX6KORPYBD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)
On Mon, Jul 5, 2021 at 5:05 PM Chris Angelico wrote:
> On Tue, Jul 6, 2021 at 9:39 AM Greg Ewing
> wrote:
> >
> > On 6/07/21 9:56 am, Jim Baker wrote:
> > >
> > > d = deferred_tag"Some expr: {:(x*2)}"
> > >
> > > All that is happening here is that this being wrapped in a lambda,
> which
> > > captures any scope lexically as usual.
> >
> > Is there reason to think this will be a common enough requirement
> > to justify having an abbreviated syntax for a parameterless lambda
> > that's only available in template expressions?
> >
>
> If it's just being wrapped in a lambda function, probably nothing, but
> I think that that would be *very* surprising behaviour. People will
> expect that the expressions' values will be collected at the point you
> hit the interpolated string, not later when it gets used.
>
It would be surprising indeed if this was the *default* behavior, that's
why you have to specially mark it using {:...} in Jim's proposal.
IIUC the idea is that the entire template becomes effectively a lambda.
It's useful if the evaluation is relatively expensive and may never be
needed, e.g. for logging at a level that is off in production. We can
debate whether it's better to mark individual substitutions with something
like {:...} or whether we should mark the template as a whole (obviously
the marking must be understandable by the parser).
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/TUAFAIOH2WEHZOKQZ4RF2M6H6KVI7CMY/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: writelines2?
Let's leave poor writelines alone. It's an old API, if you want something different, there are a zillion other ways (e.g. print(*x, sep="\n") ). I wonder how much research the OP did before they claimed "writelines is a very big misnomer to many python developers". On Tue, Jul 13, 2021 at 8:46 AM MRAB wrote: > On 2021-07-13 15:11, sandhoners...@gmail.com wrote: > > Maybe (to be consistent with other functions like print), end= since > that would allow even custom line endings > > > I'm not sure about the name 'end'. The 'print' function has 'end', but > it's printed only at the end(!); .writelines would write it after every > line. > ___ > 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/2SYIBL275IIHMSPAT6J4K3TIA7HXEKV5/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/RBWD6GIK5JTAM4PDWU6X6O4JWTOXZWUD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Notation for subscripts.
Have you seen PEP 637? IIRC it has discussions on a[] and a[*x]. Note that
it was rejected, but the idea of a[*x] is being resurrected for PEP 646.
On Fri, Aug 13, 2021 at 5:43 AM Matsuoka Takuo
wrote:
> Dear Developers,
>
> Given a subscriptable object s, the intended rule for the notation for
> getting an item of s seems that, for any expression {e}, such as
> "x, ",
> s[{e}]
> (i.e., s[x, ] if {e} is "x, ") means the same as
> s[({e})]
> (i.e., s[(x, )] in the considered case), namely, should be evaluated
> as s.__getitem__(({e})) (or s.__class_getitem__(({e})) when that
> applies). If this is the rule, then it looks simple and hence
> friendly to the user. However, there are at least two exceptions:
>
> (1) The case where {e} is the empty expression "":
> The expression
> s[]
> raises SyntaxError instead of being evaluated in the same way as
> s[()] is.
>
> (2) The case where {e} contains "*" for unpacking:
> An expression containing the unpacking notation, such as
> s[*iterable, ]
> raises SyntaxError instead of being evaluated in the same way as
> s[(*iterable, )] in this example, is.
>
> Are these (and other if any) exceptions justified? If not, I propose
> having the described rule to have full effect if that would simplify
> the syntax. This would affect currently working codes which rely on
> SyntaxError raised in either of the described ways (through eval, exec
> or import??). I wonder if reliance on SyntaxError in these cases
> should be supported in all future versions of Python.
>
> Best regards,
> Takuo Matsuoka
> ___
> 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/V2WFMNVJLUBXVQFPNHH4TJNRYNPK2BKJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/L6CXI6OWIXS7ADXWHE4K2FJUMQSAOAYI/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP idea
That's proposed in PEP 645 (https://www.python.org/dev/peps/pep-0645/). Personally I think it's not necessary, we should just write MyType | None. (Yes, this is directly from TypeScript.) On Sun, Aug 15, 2021 at 6:10 AM Will Bradley wrote: > Hi all, > > As of 3.10 (PEP 604) we've gotten syntactical support for a common type > operation— namely, typing.Union[Type1, Type2] can now be written as Type1 | > Type2 . This is achieved via overriding the __or__ method. > > I propose the ? symbol as sugar for typing.Optional, so that > typing.Optional[MyType] can be written as MyType? . (Yes, this is lifted > directly from C#.) > > Thoughts? Is it unnecessary now that we can write MyType | None as of 3.10? > > Thanks, > Will > ___ > 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/VYZOMTCNSSAJNAYHRE5A5BJUMACY57SF/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/VOEC3A6GMSLMIXU2WBUKKXCWVH673BCT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Stack-scoped variables
Perhaps we need a library for creating/managing threads that inherits all current context values? On Thu, Aug 19, 2021 at 7:48 AM Paul Prescod wrote: > There are certain values that are managed independent of any specific > code-accessible object. The decimal precision is a good example: > > https://docs.python.org/3/library/decimal.html > > We can call these context variables. As your code shows, the true "home" > of the "prec" value is not some object you manage in your code, but rather > some background object called the Context. > > The Context is not inherited by sub-threads. > > Your code is fine, because you did not use threads. Replace the map with > concurrent.futures code (as in my example). > > Your code will not work properly anymore. This is the issue. > ___ > 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/6YU3RZ6WDWVJI7QEJKICJZN72B5FYOEV/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/ZSOM5DJ3JFCXJDANRWTRVF3LHYNJ2EDJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Stack-scoped variables
Oh, I like that. It does feel like a property of the variable. (But can you efficiently enumerate all context vars when creating a thread?) I imagine that thread pools add some complication, because you don’t want to inherit these accidentally between tasks run by the same worker. On Thu, Aug 19, 2021 at 14:28 Paul Prescod wrote: > On Thu, Aug 19, 2021 at 8:43 AM Guido van Rossum wrote: > >> Perhaps we need a library for creating/managing threads that inherits all >> current context values? >> > > Or is it a "kind of context variable that is shared among threads?" That > was more the direction my mind was going. > > Context variables that hold explicitly or implicitly immutable values > are safe to share. Context variables that hold values intended to be > mutated: seldom. > > What if it were some kind of ContextVar subclass or flag where you would > say you did or didn't want something shared? > > And for legacy modules like decimal, you could turn on the flag somehow to > get the sharing behaviour. > > Sometimes threads are made by third-party libraries and those libraries > don't know anything about the context. > > In my case, the pattern was: > > 1. my code set context variable > 2. my code configured a third party library with a callback > 3. the third party library used threading for perf reasons > 4. it called my callback, which failed due to the context variable failing > to be inherited > > I believe (after only thinking about it for a day or so) that one can > generally determine the right "sharing rule" at the point of definition of > a ContextVar, based on the semantics and type of the Var. > > On Thu, Aug 19, 2021 at 8:43 AM Guido van Rossum wrote: > >> Perhaps we need a library for creating/managing threads that inherits all >> current context values? >> >> On Thu, Aug 19, 2021 at 7:48 AM Paul Prescod wrote: >> >>> There are certain values that are managed independent of any specific >>> code-accessible object. The decimal precision is a good example: >>> >>> https://docs.python.org/3/library/decimal.html >>> >>> We can call these context variables. As your code shows, the true "home" >>> of the "prec" value is not some object you manage in your code, but rather >>> some background object called the Context. >>> >>> The Context is not inherited by sub-threads. >>> >>> Your code is fine, because you did not use threads. Replace the map with >>> concurrent.futures code (as in my example). >>> >>> Your code will not work properly anymore. This is the issue. >>> ___ >>> 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/6YU3RZ6WDWVJI7QEJKICJZN72B5FYOEV/ >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> >> >> -- >> --Guido van Rossum (python.org/~guido) >> *Pronouns: he/him **(why is my pronoun here?)* >> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> >> > -- --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/KWDN3T7QUEBLGL3YBHDIARHDEAQJMW43/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: NAN handling in statistics functions
Urgh. That's a nasty dilemma. I propose that the default should be return
NAN, since that's what you'd expect if you did the super-naive arithmetic
version (e.g. mean(x, y, z) = (x+y+z)/3).
On Mon, Aug 23, 2021 at 8:55 PM Steven D'Aprano wrote:
> At the moment, the handling of NANs in the statistics module is
> implementation dependent. In practice, that *usually* means that if your
> data has a NAN in it, the result you get will probably be a NAN.
>
> >>> statistics.mean([1, 2, float('nan'), 4])
> nan
>
> But there are unfortunate exceptions to this:
>
> >>> statistics.median([1, 2, float('nan'), 4])
> nan
> >>> statistics.median([float('nan'), 1, 2, 4])
> 1.5
>
> I've spoken to users of other statistics packages and languages, such as
> R, and I cannot find any consensus on what the "right" behaviour should
> be for NANs except "not that!".
>
> So I propose that statistics functions gain a keyword only parameter to
> specify the desired behaviour when a NAN is found:
>
> - raise an exception
>
> - return NAN
>
> - ignore it (filter out NANs)
>
> which seem to be the three most common preference. (It seems to be
> split roughly equally between the three.)
>
> Thoughts? Objections?
>
> Does anyone have any strong feelings about what should be the default?
>
>
> --
> 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/EDRF2NR4UOYMSKE64KDI2SWUMKPAJ3YM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/PXLFIB4Y2EJ757E5Y7FGJG26CVDMO4S2/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: We should have an explicit concept of emptiness for collections
Hi Tim, I'm sorry if this has been brought up before, but *aside from PEP 8* is there anything wrong with using "if len(a)" for nonempty, or "if not len(a)" for empty? It would seem to work for numpy and pandas arrays, and it works for builtin sequences. Also, it has the advantage of being 100% backwards compatible. :-) Surely conforming to PEP 8 shouldn't need an addition to the language or stdlib? Or does it not work? On Tue, Aug 24, 2021 at 3:42 PM Tim Hoffmann via Python-ideas < python-ideas@python.org> wrote: > Ethan Furman wrote: > > On 8/24/21 3:03 PM, Tim Hoffmann via Python-ideas wrote: > > > **How do you check if a container is empty?** > > > IMHO the answer should not depend on the container. > > I think this is the fly in the ointment -- just about everything, from > len() to bool(), to add, to iter() /all/ depend > > on the container -- even equality depends on the container. `and`, > `or`, and `not` partially depend on the container > > (via bool()). Only `is` is truly independent. > > Sorry, I think you got me wrong: The meaning and thus implementation > depends on the type (e.g. each container defines its own __len__()). > However the syntax for querying length that is still uniformly > `len(container)`. Likewise I'd like to have a uniform syntax for emptiness, > and not different syntax for different types (`if not container` / `if > len(array) == 0` / `if dataframe.empty`). > ___ > 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/LRK6HHQKBH2Y4USB7DAJNOUF5NE62ZYD/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/5KTHNWMKZBRDQSRO7C4WCX4KG22QWCG2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: We should have an explicit concept of emptiness for collections
On Tue, Aug 24, 2021 at 7:23 PM MRAB wrote: > On 2021-08-25 00:48, Guido van Rossum wrote: > > Hi Tim, > > > > I'm sorry if this has been brought up before, but *aside from PEP 8* is > > there anything wrong with using "if len(a)" for nonempty, or "if not > > len(a)" for empty? > > > What is the cost of 'len'? If it's always O(1), then it's not a problem, > but if it's not O(1) (counting the items in a tree, for example) and > you're not interested in how many items there are but only whether > there's at least one, then... > It's a pretty universal assumption that len() is O(1) -- something that doesn't do that probably shouldn't implement __len__(). (And yeah, there's probably some tree package around that does implement an O(N) __len__(). People do a lot of silly things though, we can't handle *everything*.) > It would seem to work for numpy and pandas arrays, and it works for > > builtin sequences. Also, it has the advantage of being 100% backwards > > compatible. :-) > > > > Surely conforming to PEP 8 shouldn't need an addition to the language or > > stdlib? Or does it not work? > It was pointed out to me that numpy allows arrays that have no elements but a nonzero first dimension. People could disagree about whether that should be considered empty. I'm not sure about Pandas, but IIRC a Dataframe is always a table of rows, with all rows having the same number of columns. Here I'd say that if there's at least one row in the table, I'd call it non-empty, even if the rows have no columns. This conforms to the emptiness of [()]. It's possible that there's a common use case in the data science world where this should be counted as empty, but to me, that would be inconsistent -- a row with zero columns is still a row. (For numpy arrays my intuition is less clear, since there's more symmetry between the dimensions.) So then the next question is, what's the use case? What code are people writing that may receive either a stdlib container or a numpy array, and which needs to do something special if there are no elements? Maybe computing the average? AFAICT Tim Hoffman (the OP) never said. PS. Why is anyone thinking that an array containing all zeros (and at least one zero) might be considered empty? That seems a totally different kind of test. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/3FKVLFJLVZIARGNIA7VQBJS3V3BAD3O5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: We should have an explicit concept of emptiness for collections
“Container” is a kind of pun, it’s something with a __contains__ method.
The thing you’re looking for is “Collection”, which is the base for
sequences, mappings and sets.
I also note that the discussion seems quite stuck.
—Guido
On Tue, Aug 24, 2021 at 21:55 Christopher Barker
wrote:
> It seems the conversation has confused two related concepts:
>
> 1) The default bool() implementation (Truthiness) -- this is what the OP
> said was recommended by PEP 8: "For sequences, (strings, lists, tuples),
> use the fact that empty sequences are false:" -- there is some debate about
> that whether this is a good recommendation or not, but i don't think that's
> the OPs point. Rather:
>
> 2) That there is no standard way to explicitly test containers for
> "emptiness" - - there is only length, with the assumption that
> len(something) == 0 or not len(something) is a good way to test for
> emptiness.
>
> I still don't see why length is not perfectly adequate, but i wonder if
> there are any "containers" i.e.things that could be empty, in the std lib
> that don't support length.
>
> Looking in the ABCs, a Container is something that supports `in`, and a
> Sized is something that supports len()-- so in theory, there could be a
> Container that does not have a length. Are there any in the std lib?
>
> Perhaps the ABCs are instructive in another way here -- if we were to add
> a __empty__ or some such dunder, what ABC would require it? Container? or
> yet another one-method ABC?
>
> -CHB
>
>
> On Tue, Aug 24, 2021 at 8:39 PM David Mertz, Ph.D.
> wrote:
>
>> I wanted to do a survey of various "aggregates" in Python to see if any
>> stand out as making the usual `if stuff: ...` troublesome. I wrote a
>> little script at
>> https://github.com/DavidMertz/LanguagePractice/blob/main/python/aggregates.py
>> .
>>
>> I'm being deliberately vague about an "aggregate." It might not be a
>> collection strictly speaking, but it is something that might seems to
>> "contain" values in some sense. Basically, I think that standard library
>> and built-in stuff behaves per PEP8. Some other libraries go their own
>> way. I throw in a linked-list implementation I found on PyPI. I've never
>> used it beyond this script; but per what it is, it cannot implement `len()`
>> on O(1) (well, it *could* if it does extra bookkeeping; but then it's kinda
>> a different thing).
>>
>> In NumPy land, the np.empty vs. np.zeros case is another oddball. On my
>> system, my memory happened to have some prior value that wasn't zero; that
>> could vary between runs, in principle.
>>
>> These are the results:
>>
>> Expr: '' | Value: ''
>> Truth: False | Length: 0
>> Expr: list() | Value: []
>> Truth: False | Length: 0
>> Expr: tuple() | Value: ()
>> Truth: False | Length: 0
>> Expr: dict() | Value: {}
>> Truth: False | Length: 0
>> Expr: set() | Value: set()
>> Truth: False | Length: 0
>> Expr: bytearray() | Value: bytearray(b'')
>> Truth: False | Length: 0
>> Expr: bytearray(1) | Value: bytearray(b'\x00')
>> Truth: True | Length: 1
>> Expr: bytearray([0]) | Value: bytearray(b'\x00')
>> Truth: True | Length: 1
>> Expr: array.array('i') | Value: array('i')
>> Truth: False | Length: 0
>> Expr: array.array('i', []) | Value: array('i')
>> Truth: False | Length: 0
>> Expr: Nothing() | Value: EmptyNamedTuple()
>> Truth: False | Length: 0
>> Expr: deque() | Value: deque([])
>> Truth: False | Length: 0
>> Expr: deque([]) | Value: deque([])
>> Truth: False | Length: 0
>> Expr: ChainMap() | Value: ChainMap({})
>> Truth: False | Length: 0
>> Expr: queue.Queue() | Value:
>> Truth: True | Length: No length
>> Expr: asyncio.Queue() | Value:
>> Truth: True | Length: No length
>> Expr: multiprocessing.Queue() | Value: > object at 0x7f0940dd2190>
>> Truth: True | Length: No length
>> Expr: np.ndarray(1,) | Value: array([5.e-324])
>> Truth: True | Length: 1
>> Expr: np.ndarray((1,0)) | Value: array([], shape=(1, 0), dtype=float64)
>> Truth: False | Length: 1
>> Expr: np.empty((1,)) | Value: array([5.e-324])
>> Truth: True | Length: 1
>> Expr: np.zeros((1,)) | Value: array([0.])
>> Truth: False | Length: 1
>> Expr: np.zeros((2,)) | Value: array([0., 0.])
>> Truth: No Truthiness | Length: 2
>> Expr: np.ones((1,)) | Value: array([1.])
>> Truth: True | Length: 1
>> Expr: np.ones((2,)) | Value: array([1., 1.])
>> Truth: No Truthiness | Length: 2
>> Expr: pd.Series() | Value: Series([], dtype: float64)
>> Truth: No Truthiness | Length: 0
>> Expr: pd.DataFrame() | Value: Empty DataFrame
>> Truth: No Truthiness | Length: 0
>> Expr: xr.DataArray() | Value:
>> Truth: True | Length: No length
>> Expr: linkedadt.LinkedList() | Value: > 0x7f08d8d77f40>
>> Truth: False | Length: 0
>>
>>
>>
>> --
>> Keeping medicines from the bloodstreams of the sick; food
>> from the bellies of the hungry; books from the hands of the
>> uneducated; technology from the underdeveloped; and putting
>> advocates of freedom in prisons. Intellec
[Python-ideas] Re: We should have an explicit concept of emptiness for collections
What sort of code would be able to do anything useful with either a sequence or a queue? Queues aren’t iterable. This seems a case of hyper-generalization. On Tue, Aug 24, 2021 at 22:19 Christopher Barker wrote: > Bringing this back on list: > > On Tue, Aug 24, 2021 at 9:58 PM David Mertz, Ph.D. > wrote: > >> Sorry, I should have been more explicit. The several kinda of queues can >> all "contain" items, but do not respond to len(). >> > > yeah, I should have looked more closely at your list > > Though i would consider that an oversight, len(a_queue) could be handy. > > There is qsize() -- I wonder if there's a reason not to have __len__ do > the same thing -- O(n) maybe? See Guido's point that there's an assumption > tha len() will be O(1). > > This is an argument for the OP's point -- there is no standard way to > check emptiness. > > -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/EEK7QHRGT2P5WLEOOJCPJQSR6VEDAJVC/ > 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/DCHSJADNALHHBLXW45EVXSEFCFCIHJD4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: We should have an explicit concept of emptiness for collections
My conclusion is that you should ignore PEP 8 for your use case and write “if len(a) == 0”. On Wed, Aug 25, 2021 at 06:13 Tim Hoffmann via Python-ideas < python-ideas@python.org> wrote: > Guido van Rossum wrote: > > So then the next question is, what's the use case? What code are people > > writing that may receive either a stdlib container or a numpy array, and > > which needs to do something special if there are no elements? Maybe > > computing the average? AFAICT Tim Hoffman (the OP) never said. > > There's two parts to the answer: > > 1) There functions e.g. in scipy and matplotlib that accept both numpy > arrays and lists of flows. Speaking from matplotlib experience: While > eventually we coerce that data to a uniform internal format, there are > cases in which we need to keep the original data and only convert on a > lower internal level. We often can return early in a function if there is > no data, which is where the emptiness check comes in. We have to take extra > care to not do the PEP-8 recommended emptiness check using `if not data`. > > 2) Even for cases that cannot have different types in the same code, it is > unsatisfactory that I have to write `if not seq` but `if len(array) == 0` > depending on the expected data. IMHO whatever the recommended syntax for > emptiness checking is, it should be the same for lists and arrays and > dataframes. > ___ > 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/Q6KZEXFLJ6TEFSDQM3SXXIVGNFNURPYT/ > 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/JVNSGTXFPCODPGEPX2N4SWB7LIMPGTVS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a special TypeError subclass for implementation errors
The question is, would anyone ever want to make a distinction between the two in *real* code? I find it unlikely that someone would write try: sum(x, y, z) except TypeError: ... If you bury the sum() call deep inside other code, I'd say your try/except net is too wide. On Fri, Sep 3, 2021 at 4:24 AM Oscar Benjamin wrote: > On Fri, 3 Sept 2021 at 08:10, Serhiy Storchaka > wrote: > > > > There are two different kinds of TypeError: if the end user passes an > > instance of wrong type and if the author of the library makes an error > > in implementation of some protocols. > > > > For example, len(obj) raises TypeError in two cases: if obj does not > > have __len__ (user error) and if obj.returns non-integer (implementation > > error). for x in obj raises TypeError if obj does not have __iter__ > > (user error) and if iter(obj) does not have __next__ (implementation > error). > > > > User errors can be fixed on user side, implementation errors can only be > > fixed by the author of the class. Even if the user and the author is the > > same person, these errors point to different places of code. > > > > Would it be worth to add a special TypeError subclass for implementation > > errors to distinguish them from user errors? How to name it > > (ImplementationError, ProtocolError, etc)? > > I think that it would be good to make TypeError more fine-grained. > Another example is: > > >>> sum(1, 2, 3) > Traceback (most recent call last): > File "", line 1, in > TypeError: sum() takes at most 2 arguments (3 given) > > There can be reasons in library code to catch TypeError that might > arise from bad user input but in those situations you would usually > not want to catch this TypeError. The error from calling a function > with the wrong number of arguments would usually mean a bug in the > library code which should not be caught. Conversely if the user input > is a callable and you do want to catch the error resulting from it > being called with the wrong number of arguments then catching > TypeError is too broad again. Something like BadArgumentsError would > be better. > > -- > Oscar > ___ > 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/3CLXFC52JIBCFXMXRFA5I6F4RDU5ZYP3/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/MXVBSNUTLVJVKWIVUK7MSCKM4YDPEL4Y/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a special TypeError subclass for implementation errors
But the text of the error message will explain all you need for debugging and testing. On Fri, Sep 3, 2021 at 10:08 AM Christopher Barker wrote: > > > On Fri, Sep 3, 2021 at 9:35 AM Guido van Rossum wrote: > >> The question is, would anyone ever want to make a distinction between the >> two in *real* code? >> > > I expect not. > > However, finer grained exception may help with debugging and testing. > > -CHB > > > > > find it unlikely that someone would write >> >> try: >> sum(x, y, z) >> except TypeError: >> ... >> >> If you bury the sum() call deep inside other code, I'd say your >> try/except net is too wide. >> >> On Fri, Sep 3, 2021 at 4:24 AM Oscar Benjamin >> wrote: >> >>> On Fri, 3 Sept 2021 at 08:10, Serhiy Storchaka >>> wrote: >>> > >>> > There are two different kinds of TypeError: if the end user passes an >>> > instance of wrong type and if the author of the library makes an error >>> > in implementation of some protocols. >>> > >>> > For example, len(obj) raises TypeError in two cases: if obj does not >>> > have __len__ (user error) and if obj.returns non-integer >>> (implementation >>> > error). for x in obj raises TypeError if obj does not have __iter__ >>> > (user error) and if iter(obj) does not have __next__ (implementation >>> error). >>> > >>> > User errors can be fixed on user side, implementation errors can only >>> be >>> > fixed by the author of the class. Even if the user and the author is >>> the >>> > same person, these errors point to different places of code. >>> > >>> > Would it be worth to add a special TypeError subclass for >>> implementation >>> > errors to distinguish them from user errors? How to name it >>> > (ImplementationError, ProtocolError, etc)? >>> >>> I think that it would be good to make TypeError more fine-grained. >>> Another example is: >>> >>> >>> sum(1, 2, 3) >>> Traceback (most recent call last): >>> File "", line 1, in >>> TypeError: sum() takes at most 2 arguments (3 given) >>> >>> There can be reasons in library code to catch TypeError that might >>> arise from bad user input but in those situations you would usually >>> not want to catch this TypeError. The error from calling a function >>> with the wrong number of arguments would usually mean a bug in the >>> library code which should not be caught. Conversely if the user input >>> is a callable and you do want to catch the error resulting from it >>> being called with the wrong number of arguments then catching >>> TypeError is too broad again. Something like BadArgumentsError would >>> be better. >> >> >>> >>> -- >>> Oscar >>> ___ >>> 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/3CLXFC52JIBCFXMXRFA5I6F4RDU5ZYP3/ >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> >> >> -- >> --Guido van Rossum (python.org/~guido) >> *Pronouns: he/him **(why is my pronoun here?)* >> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> >> ___ >> 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/MXVBSNUTLVJVKWIVUK7MSCKM4YDPEL4Y/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > -- > Christopher Barker, PhD (Chris) > > Python Language Consulting > - Teaching > - Scientific Software Development > - Desktop GUI and Web Development > - wxPython, numpy, scipy, Cython > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/PODUQXNURYYPUJBBYS6T4O4X2XT3WOA2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a special TypeError subclass for implementation errors
On Fri, Sep 3, 2021 at 5:04 PM Oscar Benjamin wrote: > On Fri, 3 Sept 2021 at 17:32, Guido van Rossum wrote: > > > > On Fri, Sep 3, 2021 at 4:24 AM Oscar Benjamin < > oscar.j.benja...@gmail.com> wrote: > >> > >> On Fri, 3 Sept 2021 at 08:10, Serhiy Storchaka > wrote: > >> > > >> > There are two different kinds of TypeError: if the end user passes an > >> > instance of wrong type and if the author of the library makes an error > >> > in implementation of some protocols. > >> > > >> > For example, len(obj) raises TypeError in two cases: if obj does not > >> > have __len__ (user error) and if obj.returns non-integer > (implementation > >> > error). for x in obj raises TypeError if obj does not have __iter__ > >> > (user error) and if iter(obj) does not have __next__ (implementation > error). > >> > > >> > User errors can be fixed on user side, implementation errors can only > be > >> > fixed by the author of the class. Even if the user and the author is > the > >> > same person, these errors point to different places of code. > >> > > >> > Would it be worth to add a special TypeError subclass for > implementation > >> > errors to distinguish them from user errors? How to name it > >> > (ImplementationError, ProtocolError, etc)? > >> > >> I think that it would be good to make TypeError more fine-grained. > >> Another example is: > >> > >> >>> sum(1, 2, 3) > >> Traceback (most recent call last): > >> File "", line 1, in > >> TypeError: sum() takes at most 2 arguments (3 given) > >> > >> There can be reasons in library code to catch TypeError that might > >> arise from bad user input but in those situations you would usually > >> not want to catch this TypeError. The error from calling a function > >> with the wrong number of arguments would usually mean a bug in the > >> library code which should not be caught. Conversely if the user input > >> is a callable and you do want to catch the error resulting from it > >> being called with the wrong number of arguments then catching > >> TypeError is too broad again. Something like BadArgumentsError would > >> be better. > > > > The question is, would anyone ever want to make a distinction between > the two in *real* code? I find it unlikely that someone would write > > > > try: > > sum(x, y, z) > > except TypeError: > > ... > > > > If you bury the sum() call deep inside other code, I'd say your > try/except net is too wide. > > You've misunderstood. I do *not* want to catch the exception from sum(x, > y, z). > I know you don't. My point with that example was to show how unlikely it is that someone would write that in the first place (since the code would always fail rather than in specific cases). > Sometimes a situation arises that there is a problem involving an > exception being raised that is best fixed by catching the exception. > Python does not provide much of a programmatic API for inspecting > exceptions beyond simply choosing which class of exceptions to catch. > That makes it important to limit the class of exceptions caught as > carefully as possible. > I find it unlikely that TypeError (in particular) is of much use for repairing a situation, precisely because it is raised for situations where a value has an incorrect type. That sounds to me like either a bug in the code (and you don't fix bugs by catching exceptions, you fix them by changing the source code), or something that should be checked explicitly before making the call (e.g. if you can only sum ints and floats, and your data is from an unknown source, you should check the data before calling sum). > If the exception that needs to be caught is literally TypeError then > it is not possible to be more precise than simply "except TypeError". > I have seen code that parses the error messages but that seems flakey > to me. The problem with "except TypeError" is that it also catches > exceptions from situations where the exception should very rarely be > caught e.g. sum(1, 2, 3). > This argument would be more convincing if you could quote real code where this has been a problem. In the case of sum(), it's no hardship to ensure that you pass a list of values, avoiding the sum(x, y, z) mistake, so if you wish to catch the TypeError from sum(a), that should not need this language change. > If the different cases that currently result in TypeError were broken > down into more f
[Python-ideas] Re: Add a special TypeError subclass for implementation errors
On Fri, Sep 3, 2021 at 5:37 PM Christopher Barker wrote: > On Fri, Sep 3, 2021 at 1:13 PM Guido van Rossum wrote: > >> But the text of the error message will explain all you need for debugging >> and testing. >> > > debugging, probably yes. > > But it's a lot easier to check that a particular Exception is raised than > to have to check for the Exception and also parse the error message. > > Honestly, I haven't figured out a use case for this particular example, > but I do appreciate finer grained Exceptions in general. > Hm. More is not always better. (Today's entry for the 20th "Zen of Python" line. :-) -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/JXXR2LUZKYM4JZ6ID4FLHGCEPHRUAMIW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add @parametrize decorator to unittest library
On Mon, Sep 6, 2021 at 21:45 Christopher Barker wrote: > Just use pytest. > For third party code I agree, it’s the way to go. —Guido -- --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/75MAGYGI3NKUTVFWQ4P3QHO5OX6JQORF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: open functions in dbm submodule need to support path-like object
If someone posted a Pull Request that added this, it would be looked upon favorably I'm sure. On Tue, Sep 7, 2021 at 8:31 AM Christopher Barker wrote: > it looks like this as had a BPO for over a year: > > https://bugs.python.org/issue40563 > > I suggest pinging that (and maybe python-dev) to see what's up. > > NOTE: first check 3.10 :-) > > -CHB > > > On Tue, Sep 7, 2021 at 5:05 AM Evan Greenup via Python-ideas < > python-ideas@python.org> wrote: > >> Currently, in Python 3.9, `dbm.open()`, `dbm.gnu.open()` and >> `dbm.ndbm.open()` doesn't support path-like object, class defined in >> `pathlib`. >> >> It would be nice to add support with it. >> >> Sent with ProtonMail Secure Email. >> ___ >> 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/22OBR3A3GZLHR56P7GMWAFHSNN4CAZ7T/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > -- > 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/RSIU7TT6R2Y2FZQAWS24BQN2VIYDDLPU/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/O7LJFFWWH6G3XYO2KAK6JM3V6W2GA34W/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Different exceptions for assert
Ooh, that’s a nice idea. If the message is an exception instance, raise it instead of AssertionError. Unfortunately it’s not 100% backwards compatible. We could address that with the syntax assert cond, raise=ExcType(args) Maybe we could deprecate the case assert cond, ExcType(args) So that eventually the raise= keyword can become optional. —Guido On Thu, Sep 9, 2021 at 09:04 Juancarlo Añez wrote: > Steven, > > The purpose is to make it easier to make software more resilient. > > The inspiration was this article that reminded me that software *_will > always fail_*, and also reminded me about all the discussions around DBC > and Eiffel: > > https://www.youtube.com/watch?v=AaZ_RSt0KP8 > > > IOW, my premise is that we should be using *_lots_* of assertions, > *_always_*, and that for that we need to make them easier to write, and > easier to handle in the event of the unavoidable failures. Seeking > unit-test coverage is not enough because unit tests don't run in production. > > I will concede that code written under the *"Python culture"* tends to be > resilient because the semantics of defaults and border conditions are > explicit in the documentation, and implemented thus. > > Perhaps it's enough to allow for: > > *assert **cond**, *ExType(args) > > > > On Tue, Sep 7, 2021 at 9:28 PM Steven D'Aprano > wrote: > >> On Tue, Sep 07, 2021 at 11:12:37AM -0400, Juancarlo Añez wrote: >> > I won't propose a syntax, but I think it would be useful if *assert* >> could >> > raise an exception different from *AssertionError*. >> > >> > This is in the context of "Design by contrast" (DBC) as a useful >> companion >> > to "Test-driven development" and other forms of external tests. >> >> I don't see why that would be useful. DBC assertions are assertions. You >> are *asserting* that a condition is always true. Since it is always >> true, it should be safe to disable those DBC assertion checks once your >> software is in production. >> >> I could *maybe* see that having fine distinction between pre-condition, >> post-condition and invariant failures would be useful, but without a >> system in place to allow those to be globally enabled/disabled >> separately, what's the point? >> >> In any case, in the event of a contract failure, there's really nothing >> you can do except log the error and exit. Raising errors like TypeError >> etc will encourage people to abuse assertions and contracts by catching >> those exceptions, for checking caller-supplied parameters and user data, >> or for flow control. >> >> >> -- >> 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/B4GZYQZEYBHCEZMB4GA2IK5GSNFOOE4P/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > -- > Juancarlo *Añez* > ___ > 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/3HUS3M74VI2ECMOSGAN4QLLI3PZWXA3H/ > 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/ADQCK6Z4QLMXDDVRILAZROFOJD3T6YSJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Power Assertions: Is it PEP-able?
This is cool.
AFAIK pytest does something like this. How does your implementation differ?
What is your argument for making this part of the language? Why not a 3rd
party library?
What about asserts that are not used for testing, but as classic “unless
there’s a bug, this should hold”? Those may not want to incur the extra
cost.
—Guido
On Sun, Sep 12, 2021 at 07:09 wrote:
> Hi all,
>
> I’d like your comments and feedback on an enhancement that introduces
> power assertions to the Python language.
>
> Proposal
>
> This feature is inspired by a similar feature of the Groovy language[1],
> and is effectively a variant of the `assert` keyword.
> When an assertion expression evaluates to `False`, the output shows not
> only the failure, but also a breakdown of the evaluated expression from the
> inner part to the outer part.
>
> For example, a procedure like:
> ```python
> class SomeClass:
> def __init__(self):
> self.val = {'d': 'e'}
>
> def __str__(self):
> return str(self.val)
>
> sc = SomeClass()
>
> assert sc.val['d'] == 'f'
> ```
>
> Will result in the output:
>
> ```python
> Assertion failed:
>
> sc.val['d'] == f
> | ||
> | eFalse
> |
> {'d': 'e'}
> ```
> See link [2] if the formatting above is screwed up.
>
> In the output above we can see the value of every part of the expression
> from left to right, mapped to their expression fragment with the pipe (`|`).
> The number of rows that are printed depend on the value of each fragment
> of the expression.
> If the value of a fragment is longer than the actual fragment (`{'d':
> 'e'}` is longer than `sc`), then the next value (`e`) will be printed on a
> new line which will appear above.
> Values are appended to the same line until it overflows in length to
> horizontal position of the next fragment.
>
> The information that’s displayed is dictated by the type.
> If the type is a constant value, it will be displayed as is.
> If the type implements `__str__`, then the return value of that will be
> displayed.
>
> It is important to note that expressions with side effects are affected by
> this feature. This is because in order to display this information, we must
> store references to the instances and not just the values.
>
> Rational
>
> Every test boils down to the binary statement "Is this true or false?",
> whether you use the built-in assert keyword or a more advanced assertion
> method provided by a testing framework.
> When an assertion fails, the output is binary too — "Expected x, but got
> y".
>
> There are helpful libraries like Hamcrest which give you a more verbose
> breakdown of the difference and answer the question "What exactly is the
> difference between x and y?".
> This is extremely helpful, but it still focuses on the difference between
> the values.
>
> We need to keep in mind that a given state is normally an outcome of a
> series of states, that is, one outcome is a result of multiple conditions
> and causes.
> This is where power assertion comes in. It allows us to better understand
> what led to the failure.
>
> Implementation
>
> I’ve already built a fully functional implementation[2] of this feature as
> part of my Python testing framework - Nimoy[3].
> The current implementation uses AST manipulation to remap the expression
> to a data structure[4] at compile time, so that it can then be evaluated
> and printed[5] at runtime.
>
>
> [1]
> http://docs.groovy-lang.org/next/html/documentation/core-testing-guide.html#_power_assertions
> [2]
> https://browncoat-ninjas.github.io/nimoy/examples/#power-assertions-beta
> [3] https://github.com/browncoat-ninjas/nimoy/
> [4]
> https://github.com/browncoat-ninjas/nimoy/blob/develop/nimoy/ast_tools/expression_transformer.py#L77
> [5]
> https://github.com/browncoat-ninjas/nimoy/blob/develop/nimoy/assertions/power.py
> ___
> 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/T26DR4BMPG5EOB3A2ELVEWQPYRENRXHM/
> 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/EEVHXKWUMVSEPAR73WOBQM3BO7NESPBZ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Power Assertions: Is it PEP-able?
Maybe you all could collaborate on a PEP? This sounds a worthy topic. On Sun, Sep 12, 2021 at 08:37 Serhiy Storchaka wrote: > 12.09.21 17:28, Guido van Rossum пише: > > This is cool. > > > > AFAIK pytest does something like this. How does your implementation > differ? > > What pytest does is awesome. I though about implementing it in the > standard compiler since seen it the first time. > > > What is your argument for making this part of the language? Why not a > > 3rd party library? > > It needs a support in the compiler. The condition expression should be > compiled to keep all immediate results of subexpressions on the stack. > If the final result is true, immediate results are dropped. If it is > false, the second argument of assert is evaluated and its value together > with all immediate results of the first expression, together with > references to corresponding subexpressions (as strings, ranges or AST > nodes) are passed to the special handler. That handler can be > implemented in a third-party library, because formatting and outputting > a report is a complex task. The default handler can just raise an > AttributeError. > > > What about asserts that are not used for testing, but as classic “unless > > there’s a bug, this should hold”? Those may not want to incur the extra > > cost. > > The only extra cost is that immediate results are temporary save on > stack instead of just be dropped. It increases the size of bytecode and > stack, but I don't think it will be significant. > > ___ > 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/S673FXNSAWR3UWKNLIYTBVDAWONDPWWJ/ > 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/E67KVRNCGWB5CULMKOSQSOBS36RLYLFA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: os.workdir() context manager
Here I think we need to drop our perfectionist attitude. When I saw
Marc-Andre's proposal my first response was also "but what about threads."
But really, os.chdir() is the culprit here, and since it's a syscall we
can't fix it. If we can live with that, we can live with the proposed
os.workdir(). The docs just need a warning about threads.
Yes, you could create a thread-safe version of this by overriding open() --
and several hundred other functions that refer to pathnames natively. Such
a project will inevitably have serious backwards compatibility concerns
(any use of pathnames from C extensions will not work right) so it's just
not going to be done.
If we don't offer this in the stdlib, users will just implement this
themselves, poorly (for example, by not restoring the original when done).
On Tue, Sep 14, 2021 at 2:43 PM Cameron Simpson wrote:
> On 14Sep2021 21:43, M.-A. Lemburg wrote:
> >- The context manager is not thread safe. There's no thread safe model
> > for the current work dir. OTOH, scripts usually don't use threads,
> > so not a big deal.
>
> This is the source of my concerns. Though of course it applies to any
> process global state. It would need this stated up front in big letters
> (as of course does chdir itself). My real concern is that this can leak
> into other functions whose use then makes whatever uses them to become
> inherently and unrepairably not thread safe.
>
> I know I'm atypical, but I have quite a lot of multithreaded stuff,
> including command line code. So while it'd be ok to avoid this context
> manager for my own code, I fear library modules, either stdlib or pypi,
> quietly using this in their code, making them unuseable in the general
> case. Unrepairably unuseable, for the user.
>
> I think what would be more useful is a context manager which worked on a
> threading.local which pushed/popped a reference directory path, and had
> an open() method which used that (and friends for other pathname based
> functions).
>
> In my own code I'd write this like (sketch, untested):
>
> from cs.threads import State as ThreadState
>
> class RefDir(ThreadState)
>
> def __init__(self, refpath=None):
> if refpath is None:
> refpath = os.getcwd()
> self.refpath = abspath(refpath)
>
> def open(self, path, *a, **kw):
> if not isabs(path):
> path = os.path.join(self.refpath, path)
> return open(path, *a, **kw) # calls the builtin open()
>
> ... listdir, mkdir, etc etc ...
>
> # on reflection, __enter__ and __exit__ would make the below even
> # more convenient
> @contextmanager
> def dirpath(newrefpath):
> ''' Push `newrefpath` for the duration of the context manager.
> '''
> with self(refpath=newrefpath):
> yield self.refpath
>
> and then use it like this:
>
> R = RefDir()
>
> with R.dirpath('/some/new/place') as newpath:
> ...
> with R.open("something.txt") as f:
> ... work on /some/new/place/something.txt ...
>
> In the above, cs.threads.State is a threading.lcoal subclass which is
> also a context manager whose operation pushes arbitrary attribute
> values. Great for thread safe execution scoped state. Like this
> example.
>
> All that said, I wrote pretty much exactly what you describe just the
> other week for umask().
>
> Cheers,
> Cameron Simpson
> ___
> 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/EJETKXD7PAW3XKD5AW4OM45XKDSNX2QJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
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/KS3KYQA65NS47CMY5LAEMPNINUNRZRY3/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: os.workdir() context manager
On Tue, Sep 14, 2021 at 4:36 PM Cameron Simpson wrote: > On 15Sep2021 07:50, Chris Angelico wrote: > >On Wed, Sep 15, 2021 at 7:43 AM Cameron Simpson wrote: > >> I know I'm atypical, but I have quite a lot of multithreaded stuff, > >> including command line code. So while it'd be ok to avoid this context > >> manager for my own code, I fear library modules, either stdlib or pypi, > >> quietly using this in their code, making them unuseable in the general > >> case. Unrepairably unuseable, for the user. > > > >Library code shouldn't be changing the working directory, context > >manager or not. That belongs to the application. > > Entirely agree. > > I'm concerned that convenient stackable chdir is a bug magnet, and would > creep into library code. Maybe not in the stdlib, but there's no point > writing such a context manager if it isn't goingg to be used, and > therefore it could get used in library code. Imagine when a popular pypi > module starts using it internally and breaks a multithreaded app > previously relying on it? > I know where I'd file a bug. :-) "Bug magnet" is an extremely subjective pejorative term. When the *better* way to do things (os.workdir()) is harder than the *easy* way to do (os.chdir()), which is the real bug magnet? -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/66ZPA74HWFPYB7G7ZLHLONX32KSWIW4E/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: os.workdir() context manager
For the stdlib context managers that I know of, all-lowercase seems the convention. Would it even be a class? The simplest implementation would use contextlib.contextmanager (unless that’s a undesirable dependency for os.py). —Guido On Tue, Sep 14, 2021 at 17:53 Finn Mason wrote: > BTW, should it be `WorkDir` instead of `workdir` because it's a class, or > would that be too inconsistent? > > > On Tue, Sep 14, 2021, 6:47 PM Finn Mason wrote: > >> >> On Tue, Sep 14, 2021, 5:36 PM Cameron Simpson wrote: >> >>> On 15Sep2021 07:50, Chris Angelico wrote: >>> >On Wed, Sep 15, 2021 at 7:43 AM Cameron Simpson wrote: >>> >> I know I'm atypical, but I have quite a lot of multithreaded stuff, >>> >> including command line code. So while it'd be ok to avoid this context >>> >> manager for my own code, I fear library modules, either stdlib or >>> pypi, >>> >> quietly using this in their code, making them unuseable in the general >>> >> case. Unrepairably unuseable, for the user. >>> > >>> >Library code shouldn't be changing the working directory, context >>> >manager or not. That belongs to the application. >>> >>> Entirely agree. >>> >>> I'm concerned that convenient stackable chdir is a bug magnet, and would >>> creep into library code. Maybe not in the stdlib, but there's no point >>> writing such a context manager if it isn't going to be used, and >>> therefore it could get used in library code. Imagine when a popular pypi >>> module starts using it internally and breaks a multithreaded app >>> previously relying on it? >>> >> >> I don't think we should worry about it "creeping into library code." The >> thread-unsafety is not a cause of this context manager. It comes from the >> preexisting `os.chdir()`. If the library is changing the CWD, it's already >> thread-unsafe. It's not because of the new context manager. All >> `os.workdir()` does is make things easier. >> However, if it's implemented (which I personally support), there should >> still of course be a warning in the documentation. But I'd like to >> emphasize that *it is not because of `workdir()` itself, but the >> underlying `chdir()`!* >> >> On 14Sep2021 15:16, Guido van Rossum wrote: >> >Here I think we need to drop our perfectionist attitude. >> >> I completely agree. >> >>> ___ > 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/J4L3I3QWV65GPKHJ5RZ4NASGX7ZIS774/ > 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/X6IGI33OS7534GF7CCFUKJXTG5OMJAXA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: os.workdir() context manager
To make chdir() return a context manager *and* keep it working without calling `__enter__`, it would have to call `getcwd()`, which I've heard is expensive. So I don't think that would work, alas. On Wed, Sep 15, 2021 at 11:55 AM Eric V. Smith wrote: > On 9/15/2021 2:48 PM, Eric Fahlgren wrote: > > On Wed, Sep 15, 2021 at 12:21 AM Eric V. Smith wrote: > >> And I'm not crazy about the name "workdir". To me, it sounds like it >> returns something, not sets and resets something. But I don't have a >> particularly great alternative in mind: in my own code I've used >> "change_dir", which isn't awesome either. >> > > Our version is named "pushdir", modeled after shell's pushd (even though > pushdir is a context manager and does auto-pop). Everyone figures out what > it does at a glance. > > That's a great name! > > Although I think having os.chdir() return a context manager is a better > design (assuming it can work, but at first blush it would seem so). > > Eric > > > ___ > 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/U5UQFDAJ4KWG2OQ3YMP2THMSJ72JRV6Y/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/LZL4YXXRW4TBBSFZVW46PTTUOT36LX62/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Typing Callable Ellipsis -- support for type hints a la Callable[[int, float, ...], None]
This is a question for typing-sig. Over on typing-sig we are looking at alternatives to Callable, so it's unlikely that any changes to Callable itself will be accepted. Instead of `...`, we will probably use `*args`, similar to what is used in the `def` syntax. Feel free to peruse the typing-sig archives to learn more about the current status: https://mail.python.org/archives/list/typing-...@python.org/ --Guido On Wed, Sep 22, 2021 at 1:04 AM Randolf Scholz wrote: > @Valentin Berlier > > That would probably be possible, but the question here is, given that > `Callable` is a built-in, is it sensible to expect `Callable` to support > this behaviour. > > I would say yes, because it is extremely intuitive, especially with > regards to the fact that the widely used numpy library already uses > Ellipsis in a fashion semantically consistent with this proposal. > ___ > 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/L6BTMIIMNSXX37YQA7J5VCOI7TOKOX5O/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ 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/WE6MSPQNAKZIBNBJ3IN5MIKO6E7NIIV5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP Draft: Power Assertion
On Fri, Sep 24, 2021 at 19:49 Christopher Barker wrote: > Alternatively, take the approach taken with distutils and setuptools— > officially accept that a full featured test framework will be left to third > parties. > I think this is by far the best option. Pytest can evolve much faster than the stdlib. —Guido > -- --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/5X7ESOCGBP25YNEF3F3XWVDQHOV37N6R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP Draft: Power Assertion
On Fri, Sep 24, 2021 at 22:07 Stephen J. Turnbull < stephenjturnb...@gmail.com> wrote: > Guido van Rossum writes: > > > I think this is by far the best option. Pytest can evolve much faster > than > > the stdlib. > > Is there no room for making it easier to do this with less invasive > changes to the stdlib, or are Steven d'A's "heroic measures in an > import hook" the right way to go? > > Other Steve There’s room for that, but that’s not what’s being proposed (yet :-). —Guido > -- --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/K33XPSZVDHFTBXURX5I64OV4ZK65BTX6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP Draft: Power Assertion
On Sat, Sep 25, 2021 at 00:56 Steven D'Aprano wrote: > On Fri, Sep 24, 2021 at 11:23:00PM -0700, Guido van Rossum wrote: > > > > Is there no room for making it easier to do this with less invasive > > > changes to the stdlib, or are Steven d'A's "heroic measures in an > > > import hook" the right way to go? > > > > > > Other Steve > > > > > > There’s room for that, but that’s not what’s being proposed (yet :-). > > I'm confused. My reading of the pre-PEP is that that is precisely what > it is proposing: changing the way assert works so that the value of each > sub-expression is available to be displayed to the user. Presumably any > framework or library would be able to access that information. > > Have I missed something? I don't see anything in the proposal about > creating new stdlib frameworks or changing unittest. But others were. Anyway, I admit that I didn’t read the PRP carefully enough and was confused about what it proposes. My next responses: - The name “Power Assertions” is terrible. It sounds like a Microsoft product. :-) - I was envisioning something that provides an API that would allow a test framework to do what pytest does; not a behavior chance to the assert statement by default. - Please, please collaborate with the pytest developers on the design. —Guido -- --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/6OSPVMGPPOKRNIQ7ITSM57MWHQCBQSA6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP Draft: Power Assertion
First you need to fond a core dev to sponsor you (Steven D’A?). That person
will guide you through the process.
On Sat, Sep 25, 2021 at 08:30 Noam Tenne wrote:
> So should I just scratch this and rewrite a PEP for an extensible
> assertion mechanism?
>
> On Fri, Sep 24, 2021, at 14:04, Noam Tenne wrote:
>
> Hi All,
>
> Following the discussions on "Power Assertions: Is it PEP-able?", I've
> drafted this PEP.
> Your comments are most welcome.
>
> PEP:
> Title: Power Assertion
> Author: Noam Tenne
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 24-Sep-2021
>
>
> Abstract
>
>
> This PEP introduces a language enhancement named "Power Assertion".
>
> The Power Assertion is inspired by a similar feature found in the
> `Groovy language`_ and is an extension to the core lib's ``assert``
> keyword.
>
> When an assertion expression evaluates to ``False``, the output shows
> not only the failure, but also a breakdown of the evaluated expression
> from the inner part to the outer part.
>
> .. _Groovy language:
> http://docs.groovy-lang.org/next/html/documentation/core-testing-guide.html#_power_assertions
>
>
> Motivation
> =
>
> Every test boils down to the binary statement "Is this true or false?",
> whether you use the built-in assert keyword or a more advanced
> assertion method provided by a testing framework.
> When an assertion fails, the output is binary too —
> "Expected x, but got y".
>
> There are helpful libraries like Hamcrest which give you a more
> verbose breakdown of the difference and answer the question
> "What exactly is the difference between x and y?".
> This is extremely helpful, but it still focuses on the difference
> between the values.
>
> Keep in mind that a given state is normally an outcome of a series of
> states, that is, one outcome is a result of multiple conditions and causes.
> This is where Power Assertion comes in. It allows us to better
> understand what led to the failure.
>
>
> The Community Wants This
>
>
> As mentioned in the abstract, this feature was borrowed from Groovy.
> It is a very popular feature within the Groovy community, also used by
> projects such as `Spock`_.
>
> On top of that, it is very much needed in the Python community as well:
>
> * `Power Assertion was explicitly requested`_ as a feature in the
> `Nimoy`_ testing framework
> * There's a `similar feature in pytest`_
>
> And when `discussed in the python-ideas`_ mailing list, the responses
> were overall positive:
>
> * "This is cool." - Guido van Rossum
> * "I was actually thinking exactly the opposite: this would more
> useful in production than in testing."
> - 2QdxY4RzWzUUiLuE＠potatochowder.com
> * "What pytest does is awesome. I though about implementing it in the
> standard compiler since seen it the first time." - Serhiy Storchaka
>
> .. _Spock: https://spockframework.org/
> .. _Power Assertion was explicitly requested:
> https://stackoverflow.com/a/58536986/198825
> .. _similar feature in pytest:
> https://docs.pytest.org/en/latest/how-to/assert.html
> .. _discussed in the python-ideas:
> https://mail.python.org/archives/list/python-ideas@python.org/thread/T26DR4BMPG5EOB3A2ELVEWQPYRENRXHM/
>
>
> Rational
>
>
> Code Example
>
>
> ::
>
> class SomeClass:
> def __init__(self):
> self.val = {'d': 'e'}
>
> def __str__(self):
> return str(self.val)
>
> sc = SomeClass()
>
> assert sc.val['d'] == 'f'
>
> This routine will result in the output:
>
> ::
>
> Assertion failed:
>
> sc.val['d'] == f
> | ||
> | eFalse
> |
> {'d': 'e'}
>
>
> Display
> ---
>
> In the output above we can see the value of every part of the
> expression from left to right, mapped to their expression fragment
> with the pipe (``|``).
> The number of rows that are printed depend on the value of each
> fragment of the expression.
> If the value of a fragment is longer than the actual fragment
> (``{'d': 'e'}`` is longer than ``sc``), then the next value (``e``)
> will be printed on a new line which will appear above.
> Values are appended to the same line until it overflows in length to
> horizontal position of the next fragment.
>
> This way of presentation is clearer and more human friendly than the
> output offered by pytest's solution
