Re: How to replace a cell value with each of its contour cells and yield the corresponding datasets seperately in a list according to a Pandas-way?

ells) >      datasets = create_possible_datasets(zipf_dataset, > target_cells_with_contour) >      print(datasets) > > > main() > > Le dim. 21 janv. 2024 à 16:33, Thomas Passin via Python-list > mailto:python-list@python.org>

Re: How to replace a cell value with each of its contour cells and yield the corresponding datasets seperately in a list according to a Pandas-way?

tasets_final > > > > > > def main(): > > zipf_dataset = create_zipf_distribution() > > > > target_cells = select_target_values(zipf_dataset, 5) > > print(target_cells) > > contour_cells = select_contours(target_cells) > >

Re: How to replace a cell value with each of its contour cells and yield the corresponding datasets seperately in a list according to a Pandas-way?

ython-list mailto:python-list@python.org>> a écrit : On 1/21/2024 7:37 AM, marc nicole via Python-list wrote: > Hello, > > I have an initial dataframe with a random list of target cells (each cell > being identified with a couple (x,y)). >

Re: How to replace a cell value with each of its contour cells and yield the corresponding datasets seperately in a list according to a Pandas-way?

1/2024 7:37 AM, marc nicole via Python-list wrote: > > Hello, > > > > I have an initial dataframe with a random list of target cells (each cell > > being identified with a couple (x,y)). > > I want to yield four different dataframes each containing the value of > one

Re: How to replace a cell value with each of its contour cells and yield the corresponding datasets seperately in a list according to a Pandas-way?

On 1/21/2024 7:37 AM, marc nicole via Python-list wrote: Hello, I have an initial dataframe with a random list of target cells (each cell being identified with a couple (x,y)). I want to yield four different dataframes each containing the value of one of the contour (surrounding) cells of each

How to replace a cell value with each of its contour cells and yield the corresponding datasets seperately in a list according to a Pandas-way?

Hello, I have an initial dataframe with a random list of target cells (each cell being identified with a couple (x,y)). I want to yield four different dataframes each containing the value of one of the contour (surrounding) cells of each specified target cell. the surrounding cells to consider

Re: [Python-ideas] yield functionality to match that of await

gt; you happen to refactor out the last "yield" from a generator, suddenly > > it's not a generator any more, and you'll have a weird time trying to > > figure out what happened; but an async function is an async function > > even if it doesn't (curr

potential feature "Yield in "

This is about a feature suggestion regarding having the ability to have parallel generators. Currently you can have generators and iterators that can yield a single value. or a collection of values (still a single value). But what if you could yield to multiple objects. In a sense build

Re: Reducing "yield from" overhead in recursive generators

On 23/03/22 11:44 am, Rathmann wrote: So that sounds like the original CPython implementation had an O(depth) component, but with a lower constant factor than the current version? Yes, but so much lower that I would expect it to be unmeasurable. -- Greg -- https://mail.python.org/mailman/list

Re: Reducing "yield from" overhead in recursive generators

> On 19 Mar 2022, at 03:07, Greg Ewing wrote: > > On 19/03/22 9:40 am, Rathmann wrote: >> The other challenge/question would be to see if there is a way to implement >> this basic approach with lower overhead. > > My original implementation of yield-from didn't

Re: Reducing "yield from" overhead in recursive generators

> On 19 Mar 2022, at 03:07, Greg Ewing wrote: > > On 19/03/22 9:40 am, Rathmann wrote: >> The other challenge/question would be to see if there is a way to implement >> this basic approach with lower overhead. > > My original implementation of yield-from didn

Re: Reducing "yield from" overhead in recursive generators

On Sat, 19 Mar 2022 at 14:06, Greg Ewing wrote: > > On 19/03/22 9:40 am, Rathmann wrote: > > The other challenge/question would be to see if there is a way to implement > > this basic approach with lower overhead. > > My original implementation of yield-from didn't ha

Re: Reducing "yield from" overhead in recursive generators

On 19/03/22 9:40 am, Rathmann wrote: The other challenge/question would be to see if there is a way to implement this basic approach with lower overhead. My original implementation of yield-from didn't have this problem, because it didn't enter any of the intermediate frames -- i

Re: Reducing "yield from" overhead in recursive generators

toon. I was not aware of macropy. It certainly seems like a macro could automate the process of switching the "yield from" to yield forms. That is already pretty easy to do by hand, though. The driver itself could be packaged as a decorator using just the facilities available in regular Pyt

Re: Reducing "yield from" overhead in recursive generators

if isinstance(val, types.GeneratorType): # Yielded value represented a recursive call, so push stack.append(val) else: # Regular value for iterator, give to caller yield val except StopIte

Reducing "yield from" overhead in recursive generators

the "yield from" syntax which provides a technique for generators to delegate to other generators, including recursively. The trouble is that recursion and generators don't necessarily play all that well together from a performance point of view. As Greg Ewing noted in PEP 380:

Re: PYT - The expressions described in the Python language reference yield only boolean values

On 2022-02-19 23:28:28 +0100, vanyp wrote: > *I am trying to learn Python from the grammar given in the Python language > reference and I am surprised.* > > *Lets start here:* > > *"* > *6.3.4. Calls* > > A call calls a callable object (e.g., a function >

Re: PYT - The expressions described in the Python language reference yield only boolean values

On Sun, 20 Feb 2022 at 12:00, vanyp wrote: > > *I am trying to learn Python from the grammar given in the Python > language reference and I am surprised.* > The grammar is not the best way to learn the language. It'll show you a lot of unnecessary details. For technical reasons, Python's grammar

PYT - The expressions described in the Python language reference yield only boolean values

-python-grammar-not_test>| *"* *and the ony way out is comparison, which by the semantics should return a boolean.* *Looking at comparison gives:* *"* **6.10. Comparisons** *comparison *::= |or_expr <https://docs.python.org/3/reference/expressions.html#grammar-token-python-gramm

Re: Yield after the return in Python function.

ity or equality"), but other times, you can't actually pin down the exact semantics in Python code. Or maybe it's possible, but really hard; the precise meaning of "yield from iterable" is quite the read - check out PEP 380, and notice that even just calling a method isn't as simple as it looks :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list

Re: Yield after the return in Python function.

On Wed, Apr 7, 2021 at 12:31 PM Chris Angelico wrote: > > I just realised that the whole eval/exec/namespace stuff is massive > overkill. All you need is an object that is inconsistent in its > boolification... > > Somewhat related: https://bugs.python.org/issue42899 Steve -- https://mail.pytho

Re: Yield after the return in Python function.

On Tue, Apr 6, 2021 at 12:40 PM Terry Reedy wrote: > > On 4/5/2021 3:32 PM, Chris Angelico wrote: > > > On Tue, Apr 6, 2021 at 5:14 AM Terry Reedy wrote: > >> Python *could* do the same for expresssions: load 'a' (in this case) > >> once into a register or stack slot and use that value consistent

Re: Yield after the return in Python function.

On 4/5/2021 3:32 PM, Chris Angelico wrote: On Tue, Apr 6, 2021 at 5:14 AM Terry Reedy wrote: Python *could* do the same for expresssions: load 'a' (in this case) once into a register or stack slot and use that value consistently throughout the expression. Replacing the eval with the following

Re: Yield after the return in Python function.

On Mon, Apr 5, 2021 at 10:46 AM Terry Reedy wrote: > If there were a 'dead > (unreachable) code' exception, a reader or compiler would have to > analyze each use of 'yield' and decide whether it is reachable or not. > It's also subject to how hard the co

Re: Yield after the return in Python function.

On 6/04/21 4:02 am, Terry Reedy wrote: *Any* use of 'yield' in a function makes the function a generator function.  ...  If there were a 'dead (unreachable) code' exception, a reader or compiler would have to analyze each use of 'yield' and decide whether it is

RE: Yield after the return in Python function.

--Original Message- From: Python-list On Behalf Of Terry Reedy Sent: Monday, April 5, 2021 3:01 PM To: python-list@python.org Subject: Re: Yield after the return in Python function. On 4/5/2021 1:53 PM, Chris Angelico wrote: > On Tue, Apr 6, 2021 at 3:46 AM Terry Reedy wrote: >> *While &#x

Re: Yield after the return in Python function.

still mean that it is never True, making > >> 'yield 0' still unreachable. > > When I wrote that, I knew I might be missing something else. > > > And even just the lookup can have side effects, if your code is > > pathologically stupid. > > Or

Re: Yield after the return in Python function.

On 4/5/2021 1:53 PM, Chris Angelico wrote: On Tue, Apr 6, 2021 at 3:46 AM Terry Reedy wrote: *While 'a and not a' == False in logic, in Python it might raise NameError. But that would still mean that it is never True, making 'yield 0' still unreachable. When I wrote tha

Re: Yield after the return in Python function.

On Tue, Apr 6, 2021 at 3:46 AM Terry Reedy wrote: > *While 'a and not a' == False in logic, in Python it might raise > NameError. But that would still mean that it is never True, making > 'yield 0' still unreachable. > And even just the lookup can ha

Re: Yield after the return in Python function.

On 4/5/2021 8:25 AM, Bischoop wrote: The return suspends the function execution so how is it that in below example I got output: def doit(): return 0 yield 0 print(doit()) *Any* use of 'yield' in a function makes the function a generator function. This is a simple

Re: Yield after the return in Python function.

On 2021-04-05 2:25 PM, Bischoop wrote: The return suspends the function execution so how is it that in below example I got output: def doit(): return 0 yield 0 print(doit()) The 'yield' in the function makes the function a 'generator' function. &

Yield after the return in Python function.

The return suspends the function execution so how is it that in below example I got output: def doit(): return 0 yield 0 print(doit()) -- https://mail.python.org/mailman/listinfo/python-list

Re: XML RPC changes between 3.7 and 3.9 yield 401 http error

lucas wrote at 2021-3-27 18:53 +0100: >Following our previous discussion: > https://www.talkend.net/post/287193.html > >I finally took time (thanks to Florian R.) to get a reproducible example >of my problem, as asked previously by ChrisA. I compared `xmlrpc.client.ServerProxy.__init__` for Py

Re: XML RPC changes between 3.7 and 3.9 yield 401 http error

On 3/27/2021 6:10 PM, lucas wrote: I hope it will solve it too. Do i need to do anything ? Review the patch by trying it out on your system. If necessary because you do not have a local cpython clone, backup installed 3.9 Lib/xmlrpc.py and hand-edit. Then report OS, python used, and result.

Re: XML RPC changes between 3.7 and 3.9 yield 401 http error

On Sun, Mar 28, 2021 at 9:12 AM lucas wrote: > > Thank you ChrisA ! > > I hope it will solve it too. Do i need to do anything ? > > Thank you for your time and help. > There are a couple of things you can do actually! First off, here's the pull request, which will be where further comments happen

Re: XML RPC changes between 3.7 and 3.9 yield 401 http error

On 3/27/2021 5:49 PM, Chris Angelico wrote: https://bugs.python.org/issue38038 It seems to have been intended as a pure refactor, so I'd call this a regression. Fortunately, it's not difficult to fix; but I'm not sure if there are any other subtle changes. The regression's already been reporte

Re: XML RPC changes between 3.7 and 3.9 yield 401 http error

Thank you ChrisA ! I hope it will solve it too. Do i need to do anything ? Thank you for your time and help. Best wishes, --lucas On 27/03/2021 22:49, Chris Angelico wrote: On Sun, Mar 28, 2021 at 5:00 AM lucas wrote: I finally took time (thanks to Florian R.) to get a reproducible exampl

Re: XML RPC changes between 3.7 and 3.9 yield 401 http error

On Sun, Mar 28, 2021 at 5:00 AM lucas wrote: > I finally took time (thanks to Florian R.) to get a reproducible example > of my problem, as asked previously by ChrisA. Thanks! With this in hand, I can play around with it. > On debian, Python 3.7, i got: > > 127.0.0.1 - - [27/Mar/2021 18:31:

Re: XML RPC changes between 3.7 and 3.9 yield 401 http error

And, in my outputs, a key part is missing: the received arguments as parsed by Flask: Python 3.7: REQUEST: ImmutableMultiDict([('u', 'user'), ('p', 'password')]) Python 3.9: REQUEST: ImmutableMultiDict([]) Have a good day everyone, --lucas On 27/03/2021 18:53, lucas wrote: Followin

Re: XML RPC changes between 3.7 and 3.9 yield 401 http error

Following our previous discussion: https://www.talkend.net/post/287193.html I finally took time (thanks to Florian R.) to get a reproducible example of my problem, as asked previously by ChrisA. The following code is implementing a webserver with Flask, and a client with the XMLRPC client

Re: yield from () Was: Re: weirdness with list()

lazy - they don't run at all until you ask for a value. By contrast, this is unlike Go's goroutines, which are busy - they commence operation as soon as invoked and run until the first yield (channel put, I forget how it is spelled now). This can cause excessive CPU utilisation, but it

Re: yield from () Was: Re: weirdness with list()

over > >>> the subboxes. For MDAT that is implemented like this: > >>> > >>> def __iter__(self): > >>> yield from () > >> > >> Sorry, a bit OT but I'm curious. I haven't seen > >> this before: > >>

Re: yield from () Was: Re: weirdness with list()

t;>> >>> def __iter__(self): >>> yield from () >> >> Sorry, a bit OT but I'm curious. I haven't seen >> this before: >> >> yield from () >> >> What is it doing? >> What do the () represent in this context? > >

Re: yield from () Was: Re: weirdness with list()

until you ask for a value. By contrast, this is unlike Go's goroutines, which are busy - they commence operation as soon as invoked and run until the first yield (channel put, I forget how it is spelled now). This can cause excessive CPU utilisation, but it handle for _fast_ production of

Re: yield from () Was: Re: weirdness with list()

> > > the subboxes. For MDAT that is implemented like this: > > > > > > def __iter__(self): > > > yield from () > > > > Sorry, a bit OT but I'm curious. I haven't seen > > this before: > > > > yield from () >

Re: yield from () Was: Re: weirdness with list()

On Mon, 1 Mar 2021 at 19:51, Alan Gauld via Python-list wrote: > Sorry, a bit OT but I'm curious. I haven't seen > this before: > > yield from () > > What is it doing? > What do the () represent in this context? It's the empty tuple. -- https://mail.python.org/mailman/listinfo/python-list

Re: yield from () Was: Re: weirdness with list()

On Tue, Mar 2, 2021 at 5:51 AM Alan Gauld via Python-list wrote: > > On 28/02/2021 00:17, Cameron Simpson wrote: > > > BUT... It also has a __iter__ value, which like any Box iterates over > > the subboxes. For MDAT that is implemented like this: > > > > def

Re: yield from () Was: Re: weirdness with list()

On 28/02/2021 23:47, Alan Gauld via Python-list wrote: > On 28/02/2021 00:17, Cameron Simpson wrote: > >> BUT... It also has a __iter__ value, which like any Box iterates over >> the subboxes. For MDAT that is implemented like this: >> >> def __iter_

Re: yield from () Was: Re: weirdness with list()

On Wed, Mar 3, 2021 at 8:21 AM Dieter Maurer wrote: > > Alan Gauld wrote at 2021-2-28 23:47 +0000: > >yield from () > > "yield from iterator" is similar to "for i in iterator: yield i" (with > special handling when data/exceptions are injected into the g

yield from () Was: Re: weirdness with list()

Alan Gauld wrote at 2021-2-28 23:47 +: >yield from () "yield from iterator" is similar to "for i in iterator: yield i" (with special handling when data/exceptions are injected into the generator). Thus, "yield from ()" does essentially nothing with th

Re: yield from () Was: Re: weirdness with list()

On 01/03/2021 00:47, Alan Gauld via Python-list wrote: On 28/02/2021 00:17, Cameron Simpson wrote: BUT... It also has a __iter__ value, which like any Box iterates over the subboxes. For MDAT that is implemented like this: def __iter__(self): yield from () Sorry, a bit OT but

Re: yield from () Was: Re: weirdness with list()

On 28Feb2021 23:47, Alan Gauld wrote: >On 28/02/2021 00:17, Cameron Simpson wrote: >> BUT... It also has a __iter__ value, which like any Box iterates over >> the subboxes. For MDAT that is implemented like this: >> >> def __iter__(self): >> yield f

yield from () Was: Re: weirdness with list()

On 28/02/2021 00:17, Cameron Simpson wrote: > BUT... It also has a __iter__ value, which like any Box iterates over > the subboxes. For MDAT that is implemented like this: > > def __iter__(self): > yield from () Sorry, a bit OT but I'm curious. I haven't

Re: XML RPC changes between 3.7 and 3.9 yield 401 http error

On 24/02/2021 20:21, Chris Angelico wrote: On Thu, Feb 25, 2021 at 6:14 AM lucas wrote: I tested from the windows computer (Python 3.8, it appears, not 3.7 as i thought), and got the following nginx log: [LAPTOP IP] - - [24/Feb/2021:20:06:42 +0100] "POST /lib/exe/xmlrpc.php?u=[user]&p=[passwor

Re: XML RPC changes between 3.7 and 3.9 yield 401 http error

On Thu, Feb 25, 2021 at 6:14 AM lucas wrote: > I tested from the windows computer (Python 3.8, it appears, not 3.7 as i > thought), and got the following nginx log: > > [LAPTOP IP] - - [24/Feb/2021:20:06:42 +0100] "POST > /lib/exe/xmlrpc.php?u=[user]&p=[password] HTTP/1.1" 200 209 "-" > "DokuWikiX

Re: XML RPC changes between 3.7 and 3.9 yield 401 http error

On 24/02/2021 19:22, Chris Angelico wrote: On Thu, Feb 25, 2021 at 5:12 AM lucas wrote: On 24/02/2021 18:48, Chris Angelico wrote: I added socket.gethostbyname("wiki.example.net") (i removed the https:// since it, obviously now i think about it, led to a socket error) in the program, so i coul

Re: XML RPC changes between 3.7 and 3.9 yield 401 http error

On Thu, Feb 25, 2021 at 5:12 AM lucas wrote: > > On 24/02/2021 18:48, Chris Angelico wrote: > I added socket.gethostbyname("wiki.example.net") (i removed the https:// > since it, obviously now i think about it, led to a socket error) > in the program, so i could verify both the URL and IP are equi

Re: XML RPC changes between 3.7 and 3.9 yield 401 http error

On 24/02/2021 18:48, Chris Angelico wrote: On Thu, Feb 25, 2021 at 4:36 AM lucas wrote: A properly-formed URL will start with a protocol. I don't know specifically what changed, but it's looking like something started rejecting malformed URLs. Try adding "http://"; or "https://"; to your URL (w

Re: XML RPC changes between 3.7 and 3.9 yield 401 http error

On Thu, Feb 25, 2021 at 4:36 AM lucas wrote: > > A properly-formed URL will start with a protocol. I don't know > > specifically what changed, but it's looking like something started > > rejecting malformed URLs. Try adding "http://"; or "https://"; to your > > URL (whichever is appropriate) and s

Re: XML RPC changes between 3.7 and 3.9 yield 401 http error

On 24/02/2021 18:00, Chris Angelico wrote: On Thu, Feb 25, 2021 at 2:02 AM lucas wrote: Hi everyone, (Sorry for the double-send if any, i'm not sure the first send was performed, maybe because of bounce errors according to mailman.) I'm currently trying to understand an error when using the

Re: XML RPC changes between 3.7 and 3.9 yield 401 http error

On Thu, Feb 25, 2021 at 2:02 AM lucas wrote: > > Hi everyone, > > (Sorry for the double-send if any, i'm not sure the first send was > performed, maybe because of bounce errors according to mailman.) > > > I'm currently trying to understand an error when using the > dokuwikixmlrpc python module, a

Re: XML RPC changes between 3.7 and 3.9 yield 401 http error

Hi, thanks for your answer ! I updated everything, including certificates, while upgrading to python 3.9, and retried today (no new certificates to install). I am the administrator of the wiki i try to access, and didn't do black magic in the configuration.. The error really seems to came fr

Re: XML RPC changes between 3.7 and 3.9 yield 401 http error

On 2021-02-24 at 15:29:58 +0100, lucas wrote: > I'm currently trying to understand an error when using the dokuwikixmlrpc > python module, allowing to easily work with DokuWiki RPC interface. > > Another description of the problem : > https://github.com/kynan/dokuwikixmlrpc/issues/8 > > H

XML RPC changes between 3.7 and 3.9 yield 401 http error

Hi everyone, (Sorry for the double-send if any, i'm not sure the first send was performed, maybe because of bounce errors according to mailman.) I'm currently trying to understand an error when using the dokuwikixmlrpc python module, allowing to easily work with DokuWiki RPC interface. An

Re: yield from

On Wed, Mar 25, 2020 at 10:08 AM Dan Stromberg wrote: > > Some time ago, when I first heard about yield from, it wasn't faster than a > for loop yielding. > > Has that improved? It's not about speed. It's about correctness, and the way it delegates everything, no

yield from

Some time ago, when I first heard about yield from, it wasn't faster than a for loop yielding. Has that improved? -- https://mail.python.org/mailman/listinfo/python-list

Re: Passing yield as a function argument...

Christopher Reimer wrote: > Greetings, > > I have two functions that I generalized to be nearly identical except > for one line. One function has a yield statement, the other function > appends to a queue. > > If I rewrite the one line to be a function passed in as an arg

Passing yield as a function argument...

Greetings, I have two functions that I generalized to be nearly identical except for one line. One function has a yield statement, the other function appends to a queue. If I rewrite the one line to be a function passed in as an argument -- i.e., func(data) -- queue.append works fine. If I

Re: how to send a json of yield list

when not to use queue, it is faster now while True: for ii in getcombinations(): item = ii print(item) sock.send(json.dumps(ii)) On Friday, October 14, 2016 at 5:11:35 PM UTC+8, meInvent bbird wrote: > succeed to run, > > is it the yield return

Re: how to send a json of yield list

succeed to run, is it the yield return the whole list 2000 * 2000 * 2000 items? as i know that yield is return [1,1,1] etc one by one once it get if it return 2000*2000*2000 items, why? i have to add a queue get this yield in order to succeed but i do not understand the situation when using

Re: how to send a json of yield list

meInvent bbird writes: > after google a several solutions, > First method i searched has memory error > sock.send(json.dumps(StreamArray())) > Traceback (most recent call last): > File "pusher.py", line 43, in > sock.send(json.dumps(StreamArray())) > ... > MemoryError "MemoryError" means

how to send a json of yield list

bject'])) return dct context = zmq.Context() sock = context.socket(zmq.PUSH) sock.bind(sys.argv[1]) def getcombinations(): for ii in range(1,2000): for jj in range(1,2000): for kk in range(1,2000): yield [ii,jj,kk] class StreamArray(list): def __iter__(s

Re: PEP proposal: sequence expansion support for yield statement: yield *

be used (in the context of "the ways this can NOW be used in Python 3.5"). So the proposed "yield *sequence" does make good sense; however, "yield from" has, as Steven pointed out, *far* more detailed semantics, as it basically allows generators to be refactored, wi

Re: PEP proposal: sequence expansion support for yield statement: yield *

I agree with the others that the new syntax is not needed. I would also like to point out that I believe any new added syntax or functionality should avoid the use of '*' and '**' as both of these characters are already used for many things such as optional arguments and mathematical operators. Ad

Re: PEP proposal: sequence expansion support for yield statement: yield *

On Thu, 21 Apr 2016 05:34 am, Ken Seehart wrote: > Currently the common pattern for yielding the elements in a sequence is as > follows: > > for x in sequence: yield x > > I propose the following replacement (the result would be identical): > > yield *sequence Oth

Re: PEP proposal: sequence expansion support for yield statement: yield *

On Thu, Apr 21, 2016 at 8:26 AM, wrote: > Anyway, thanks for the link. And I suppose checking Python 3 for > implementation would be a good prior step as well! Sadly, "yield from" is not > in python 2.7, but it's presence in python 3.3 renders my proposal dead as a

Re: PEP proposal: sequence expansion support for yield statement: yield *

ows: > > > >for x in sequence: yield x > > > > I propose the following replacement (the result would be identical): > > > >yield *sequence > > > > The semantics are somewhat different from argument expansion (from > > which the syntax

Re: PEP proposal: sequence expansion support for yield statement: yield *

Currently the common pattern for yielding the elements in a sequence is as follows: for x in sequence: yield x I propose the following replacement (the result would be identical): yield *sequence imho the current syntax is much more intuitive, it is obvious to infer what it does by

Re: PEP proposal: sequence expansion support for yield statement: yield *

On 04/20/2016 12:34 PM, Ken Seehart wrote: New ideas for Python are typically vetted on Python Ideas. [1] Currently the common pattern for yielding the elements in a sequence > is as follows: for x in sequence: yield x I propose the following replacement (the result would be identi

Re: PEP proposal: sequence expansion support for yield statement: yield *

On Wed, Apr 20, 2016, at 15:34, Ken Seehart wrote: > Currently the common pattern for yielding the elements in a sequence is > as follows: > > for x in sequence: yield x > > I propose the following replacement (the result would be identical): > > yield *seque

PEP proposal: sequence expansion support for yield statement: yield *

Currently the common pattern for yielding the elements in a sequence is as follows: for x in sequence: yield x I propose the following replacement (the result would be identical): yield *sequence The semantics are somewhat different from argument expansion (from which the syntax is

Re: yield in try/finally case

lambda: myclose(f) > files.append(f) > return f > > def upperfile(filename): > with open(filename) as f: > for line in f: > yield line.upper() > > for uf in map(upperfile, sys.argv[1:]): > for line in uf: > print(line, end=&q

Re: yield in try/finally case

esource(): with acquire_resource() as r: yield r for r in gen_resource(): use(r) break # use(r) triggering an exception would have the same effect assert r was released # may fail you are at the mercy of the Python interpreter's garbage collection strategy. Of course yo

Re: yield in try/finally case

On Fri, 4 Mar 2016 02:00 am, Random832 wrote: > On Thu, Mar 3, 2016, at 06:52, 刘琦帆 wrote: >> I have just saw PEP 255, and it says that >> >> "A yield statement is not allowed in the try clause of a try/finally >> construct. The difficulty is that there's no

Re: yield in try/finally case

def myclose(self): print("--- closed " + self.name) self._close() def open(*args, **kw): f = _open(*args, **kw) f._close = f.close f.close = lambda: myclose(f) files.append(f) return f def upperfile(filename): with open(filename) as f: for line in f:

Re: yield in try/finally case

On Thu, Mar 3, 2016, at 06:52, 刘琦帆 wrote: > I have just saw PEP 255, and it says that > > "A yield statement is not allowed in the try clause of a try/finally > construct. The difficulty is that there's no guarantee the generator > will ever be resumed, hence no guarant

Re: yield in try/finally case

刘琦帆 wrote: > 在 2016年3月3日星期四 UTC+8下午8:14:29，Oscar Benjamin写道： >> On 3 March 2016 at 11:52, 刘琦帆 wrote: >> > >> > "A yield statement is not allowed in the try clause of a try/finally >> > construct. The difficulty is that there's no guarantee the

Re: yield in try/finally case

在 2016年3月3日星期四 UTC+8下午8:14:29，Oscar Benjamin写道： > On 3 March 2016 at 11:52, 刘琦帆 wrote: > > > > "A yield statement is not allowed in the try clause of a try/finally > > construct. The difficulty is that there's no guarantee the generator will > > ever be

Re: yield in try/finally case

On 3 March 2016 at 11:52, 刘琦帆 wrote: > > "A yield statement is not allowed in the try clause of a try/finally > construct. The difficulty is that there's no guarantee the generator will > ever be resumed, hence no guarantee that the finally block will ever get > ex

yield in try/finally case

I have just saw PEP 255, and it says that "A yield statement is not allowed in the try clause of a try/finally construct. The difficulty is that there's no guarantee the generator will ever be resumed, hence no guarantee that the finally block will ever get executed; that&#x

Re: coroutine, throw, yield, call-stack and exception handling

Ian Kelly wrote: > On Mon, Feb 8, 2016 at 2:17 AM, Veek. M wrote: >> >> Exceptions can be raised inside a coroutine using the throw( >> >> Exceptions raised in this manner will originate at the currently >> executing yield state-ment

Re: coroutine, throw, yield, call-stack and exception handling

On Mon, Feb 8, 2016 at 2:17 AM, Veek. M wrote: > > Exceptions can be raised inside a coroutine using the throw( > > Exceptions raised in this manner will originate at the currently > executing yield state-ment in the coroutine.A coroutine can e

Re: coroutine, throw, yield, call-stack and exception handling

Veek. M wrote: > > Exceptions can be raised inside a coroutine using the throw( > > Exceptions raised in this manner will originate at the currently > executing yield state-ment in the coroutine.A coroutine can elect to > catch exceptions

coroutine, throw, yield, call-stack and exception handling

Exceptions can be raised inside a coroutine using the throw( Exceptions raised in this manner will originate at the currently executing yield state-ment in the coroutine.A coroutine can elect to catch exceptions and handle them as appropriate. It is not safe to use

Re: Question about yield

On Sun, 15 Nov 2015 01:37 pm, fl wrote: > Hi, > I have read a couple of tutorial on yield. The following code snippet > still gives me a shock. I am told yield is a little like return. I only > see one yield in the tutorial examples. Here it has two yields. And there > are

Re: Question about yield

On Sun, Nov 15, 2015 at 1:37 PM, fl wrote: > Or are there some high relevant tutorial on this? > Start here: https://docs.python.org/3/tutorial/index.html ChrisA -- https://mail.python.org/mailman/listinfo/python-list

Question about yield

Hi, I have read a couple of tutorial on yield. The following code snippet still gives me a shock. I am told yield is a little like return. I only see one yield in the tutorial examples. Here it has two yields. And there are three variables following keyword yield. I have not tried debug function

Re: Oddity with lambda and yield

On Fri, Jan 9, 2015 at 1:30 AM, Ian Kelly wrote: > > Seems like a bug to me. http://bugs.python.org/issue23192 created with a bit more info, including disassembly. ChrisA -- https://mail.python.org/mailman/listinfo/python-list

Re: Oddity with lambda and yield

On Thu, Jan 8, 2015 at 5:11 AM, Chris Angelico wrote: > As yield is an expression, it's legal in a lambda function, which then > means you have a generator function. But it's not quite the same as > the equivalent function made with def: > > $ python3 > Python 3.5.0a0

Oddity with lambda and yield

As yield is an expression, it's legal in a lambda function, which then means you have a generator function. But it's not quite the same as the equivalent function made with def: $ python3 Python 3.5.0a0 (default:1c51f1650c42+, Dec 29 2014, 02:29:06) [GCC 4.7.2] on linux Type "he

  1   2   3   >