[Python-Dev] List copy and clear (was Re: Inconsistent API for sets.Set and build-in set)
>* and because Guido believes beginners tend to copy too much > (that is one reason why copy.copy is not a builtin) and that > the language should encourage correct behavior. OTOH, beginners tend to copy not enough - when for example iterating over a list being acting upon. Though my real argument for list.copy() as an aid to beginners is otherwise - a bit more obtuse/non-linear than that - so much so that it doesn't get much sympahty. It isn't realistic to expect beginners to pick up idioms near the outset of the learning process. Now, copying lists is not something the beginner will often want to do, and the argument that once they want to do so, they will also be comfortable with slicing and with more idiomatic Python is not an unreasonable argument. But I believe it misses something more fundamental. It is a belief that is extracted from my own experience in tackling Python as a first language - as an adult, being able - I think - to introspect a bit better as to the process than I could if I were doing so at a younger age, and more in the normal course. The downside of Guido hiding "copy" to the extent it is - by not having a list.copy(), by not having copy.copy as a built-in, by even rejecting the notion of a short blurb of the copy module in the tutorial - is that the confrontation with the distinction between copying and "=" assignment gets delayed and confusion on the point becomes frustrating - fundamentally so. It doens't seem to me that this is an outlandish notion by any means. It can't be - as I seemed to have experienced it. Guido called this "one of my favorite subjects" in my last go around here on this issue. Well, it is indeed an opinion I hold. Not of earthshaking importance. But I hold it firmly enough, nonetheless. My flexiblity is more on the issue as to the extent that Python should design itself around the needs of beginners. If the conclusion is that list.copy() is a distraction to the experienced programmer, and that the motivated beginner will get to where they need to get, in any case, with or without it - I'm on board. If the thought is that hiding "copy", or relying on idioms for a construct as fundamental as the list - is a favor to the beginner, I very much am not. Art ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] IDLE development
Moam writes - >Hello, >More than a year and a half ago, I posted a big patch to IDLE which >adds support for completion and much better calltips, along with some >other improvements. I had also tried to have a little input to the IDLE development process. Suggesting on the idle-dev list it seemed to me that a trivial patch to the existing code would provide functionality to allow customization via user- defined domain-specific syntax highlighting files in a user's home directory. So that if one wished one could add appropriate syntax highlighting for say, Numeric. I left open the possibility that I was mistaken in my opinion that it was trivial or necessary or desirable. I was unable to assess whether the lack of my ability to get a yes, no or sideways was a result of the fact my suggestion and analysis was absurd, or something else. One of the "something else" possibilities was a broken process. Still can't assess it. Art ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)
On 8 April 2016 at 16:18, Jon Ribbens
wrote:
> I've made another attempt at Python sandboxing, which does something
> which I've not seen tried before - using the 'ast' module to do static
> analysis of the untrusted code before it's executed, to prevent most
> of the sneaky tricks that have been used to break out of past attempts
> at sandboxes.
>
> In short, I'm turning Python's usual "gentleman's agreement" that you
> should not access names and attributes that are indicated as private
> by starting with an underscore into a rigidly enforced rule: try and
> access anything starting with an underscore and your code will not be
> run.
>
> Anyway the code is at https://github.com/jribbens/unsafe
> It requires Python 3.4 or later (it could probably be made to work on
> Python 2.7 as well, but it would need some changes).
>
> I would be very interested to see if anyone can manage to break it.
> Bugs which are trivially fixable are of course welcomed, but the real
> question is: is this approach basically sound, or is it fundamentally
> unworkable?
>
If i'm not mistaken, this breaks out:
> exec('open("out", "w").write("a")', {})
because if the second argument of exec does not contain a __builtins__ key,
then a copy of the original builtins module is inserted:
https://docs.python.org/3/library/functions.html#exec
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] file system path protocol PEP
On 11 May 2016 at 22:51, Ethan Furman wrote: > On 05/11/2016 01:44 PM, Serhiy Storchaka wrote: > > os.path >>> ''' >>> >>> The various path-manipulation functions of ``os.path`` [#os-path]_ >>> will be updated to accept path objects. For polymorphic functions that >>> accept both bytes and strings, they will be updated to simply use >>> code very much similar to >>> ``path.__fspath__() if hasattr(path, '__fspath__') else path``. This >>> will allow for their pre-existing type-checking code to continue to >>> function. >>> >> >> I afraid that this will hit a performance. Some os.path functions are >> used in tight loops, they are hard optimized, and adding support of path >> protocol can have visible negative effect. >> > > Do you have an example of os.path functions being used in a tight loop? > os.path.getmtime could be used in a tight loop, to sync directories with a lot of files for instance. % python3 -m timeit -s "import os.path; p = 'out'" "hasattr(p, '__fspath__'), os.path.getmtime(p)" 10 loops, best of 3: 2.67 usec per loop % python3 -m timeit -s "import os.path; p = 'out'" "isinstance(p, (str, bytes)), os.path.getmtime(p)" 10 loops, best of 3: 2.45 usec per loop % python3 -m timeit -s "import os.path; p = 'out'" "os.path.getmtime(p)" 10 loops, best of 3: 2.02 usec per loop a 25% markup is a lot imo. a isinstance check prior to the hasattr might be a way to mitigate this a bit (but it doesn't help much) Granted, this example could be optimised by calling os.stat directly, which is not in os.path, but still, worth considering ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: PEP 622: Structural Pattern Matching
On Fri, 26 Jun 2020 at 09:07, Greg Ewing wrote: > On 26/06/20 2:10 pm, Gregory P. Smith wrote: > > match get_shape() as shape: > >case start, end := Line@(shape): > > This looks just as inscrutable to me in its own way. > Absolutely, but that's kind of the point I think: no possible way to understand it for something else that what it means. Arthur ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/5AN52CT5BYARJHO3BL3OMXI4A27DHJCH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Implementing an awaitable
I'm trying to figure out if our documentation on the new awaitable concept in Python 3.6+ is correct. It seems to imply that if an object's __await__ method returns an iterator, the object is awaitable. However, just returning an iterator doesn't seem to work with await in a coroutine or with the asyncio selector loop's run_until_complete method. If the awaitable is not a coroutine or future, it looks like we wrap it in a coroutine using sub-generator delegation, and therefore have to have an iterator that fits a very specific shape for the coroutine step process that isn't documented anywhere I could find. Am I missing something? If the definition of an awaitable is more than just an __await__ iterator, we may need to expand the documentation as well as the abstract base class. Here's what I tried in making a synchronous awaitable that resolves to the int 42: class MyAwaitable(Awaitable): def __await__(self): return iter((42,)) # RuntimeError: Task got bad yield: 42 class MyAwaitable(Awaitable): def __await__(self): yield 42 # RuntimeError: Task got bad yield: 42 class MyAwaitable(Awaitable): def __await__(self): return (i for i in (42,)) # RuntimeError: Task got bad yield: 42 class MyAwaitable(Awaitable): def __await__(self): return self def __next__(self): return 42 # RuntimeError: Task got bad yield: 42''' class MyAwaitable(Awaitable): def __await__(self): return iter(asyncio.coroutine(lambda: 42)()) # TypeError: __await__() returned a coroutine class MyAwaitable(Awaitable): def __await__(self): yield from asyncio.coroutine(lambda: 42)() # None class MyAwaitable(Awaitable): def __await__(self): return (yield from asyncio.coroutine(lambda: 42)()) # 42 async def await_things(): print(await MyAwaitable()) asyncio.get_event_loop().run_until_complete(await_things()) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Implementing an awaitable
Thanks for the thorough rundown, Nathaniel. I started to get an idea of the required shape only by looking at CPython code like you suggest. I wanted to create an awaitable compatible with asyncio and trio that could be awaited more than once unlike a coroutine, and not runner-specific like a Future or Deferred. Are coroutines the only common awaitable the various async libraries are going to have for now? I'll take Python documentation suggestions up with other channels. - Justin On Wed, Nov 7, 2018 at 11:27 PM Nathaniel Smith wrote: > "Awaitable" is a language-level concept. To actually use awaitables, > you also need a coroutine runner library, and each library defines > additional restrictions on the awaitables it works with. So e.g. when > using asyncio as your coroutine runner, asyncio expects your > awaitables to follow particular rules about what values they yield, > what kinds of values they can handle being sent/thrown back in, etc. > Different async libraries use different rules here. > > Asyncio's rules aren't documented, I guess because it's such a > low-level thing that anyone who really needs to know is expected to > read the source :-). (In particular asyncio/futures.py and > asyncio/tasks.py.) But it's basically: the object returned by > __await__ has to implement the generator interface (which is a > superset of the iterator interface), the objects yielded by your > iterator have to implement the Future interface, and then you're > resumed either by sending back None when the Future completes, or else > by having an exception thrown in. > > -n > > On Wed, Nov 7, 2018 at 8:24 PM, Justin Turner Arthur > wrote: > > I'm trying to figure out if our documentation on the new awaitable > concept > > in Python 3.6+ is correct. It seems to imply that if an object's > __await__ > > method returns an iterator, the object is awaitable. However, just > returning > > an iterator doesn't seem to work with await in a coroutine or with the > > asyncio selector loop's run_until_complete method. > > > > If the awaitable is not a coroutine or future, it looks like we wrap it > in a > > coroutine using sub-generator delegation, and therefore have to have an > > iterator that fits a very specific shape for the coroutine step process > that > > isn't documented anywhere I could find. Am I missing something? > > > > If the definition of an awaitable is more than just an __await__ > iterator, > > we may need to expand the documentation as well as the abstract base > class. > > > > Here's what I tried in making a synchronous awaitable that resolves to > the > > int 42: > > class MyAwaitable(Awaitable): > > def __await__(self): > > return iter((42,)) > > # RuntimeError: Task got bad yield: 42 > > > > class MyAwaitable(Awaitable): > > def __await__(self): > > yield 42 > > # RuntimeError: Task got bad yield: 42 > > > > class MyAwaitable(Awaitable): > > def __await__(self): > > return (i for i in (42,)) > > # RuntimeError: Task got bad yield: 42 > > > > class MyAwaitable(Awaitable): > > def __await__(self): > > return self > > def __next__(self): > > return 42 > > # RuntimeError: Task got bad yield: 42''' > > > > class MyAwaitable(Awaitable): > > def __await__(self): > > return iter(asyncio.coroutine(lambda: 42)()) > > # TypeError: __await__() returned a coroutine > > > > class MyAwaitable(Awaitable): > > def __await__(self): > > yield from asyncio.coroutine(lambda: 42)() > > # None > > > > class MyAwaitable(Awaitable): > > def __await__(self): > > return (yield from asyncio.coroutine(lambda: 42)()) > > # 42 > > > > async def await_things(): > > print(await MyAwaitable()) > > > > asyncio.get_event_loop().run_until_complete(await_things()) > > > > > > ___ > > Python-Dev mailing list > > [email protected] > > https://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > > https://mail.python.org/mailman/options/python-dev/njs%40pobox.com > > > > > > -- > Nathaniel J. Smith -- https://vorpus.org > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
