no doubt tho after playing with this is that enumerate value ends up in the
output which is a dictionary. The enumerate has no key which makes it invalid
json if dumped.
Not massive issue but getting the effect of enumerate without polluting output
would be the winner.
>runner_lists = {}
On 04Nov2017 17:43, Sayth Renshaw wrote:
figured it. Needed to use n to iterate when creating.
Yeah, my mistake.
runner_lists = {}
for n, item in enumerate(result):
# if this one is interested / not -filtered:
print(n, item)
runner_lists[n] = result[n]["RacingFormGuid
Sorry
figured it. Needed to use n to iterate when creating.
runner_lists = {}
for n, item in enumerate(result):
# if this one is interested / not -filtered:
print(n, item)
runner_lists[n] = result[n]["RacingFormGuide"]["Event"]["Runners"]
Sayth
--
https://mail.python
> I'd just keep the interesting runners, along with their race numbers, in a
> dict. The enumerate function is handy here. Something like (untested):
>
> runner_lists = {}
> for n, item in enumerate(result):
> if this one is interested/not-filtered:
> runner_lists[n] = result["Raci
On Sunday, 5 November 2017 09:53:37 UTC+11, Cameron Simpson wrote:
> >I want to get a result from a largish json api. One section of the json
> >structure returns lists of data. I am wanting to get each resulting list
> >returned.
> >
> >This is my code.
> >import json
> >from pprint import ppr
On 04Nov2017 14:01, Sayth Renshaw wrote:
I want to get a result from a largish json api. One section of the json
structure returns lists of data. I am wanting to get each resulting list
returned.
This is my code.
import json
from pprint import pprint
with open(r'/home/sayth/Projects/results/
Hi
I want to get a result from a largish json api. One section of the json
structure returns lists of data. I am wanting to get each resulting list
returned.
This is my code.
import json
from pprint import pprint
with open(r'/home/sayth/Projects/results/Canterbury_2017-01-20.json', 'rb') as
f
C, there
was a GOSUB intermediate between a GOTO and a procedure call.
Surely Meyer doesn't mean to say we should never call functions or use
`while`, `for` or `if`. So he has to distinguish between kinds of jumps:
Good jumps (I presume):
* function calls
* if...else
* loopi
On Mon, Sep 24, 2017 09:41 PM, Daiyue Weng wrote:
>
Hi, I tried to make a menu using print statements in Python 3. The code is
>as follows,
>
>print('insert data into: ')
>data_insert_method = ['new collection', 'existing collection']
>for index, elem in enumerate(data_insert_method):
>print(ind
On 24Sep2017 21:41, Daiyue Weng wrote:
Hi, I tried to make a menu using print statements in Python 3. The code is
as follows,
One thing, please try to preserve the code indenting in messages. What you
pasted is all hard against the left side of the screen. I've tried to repair
it.
print('
Sry for the unclear formatting, this is the original code with correct
format (copy from pycharm),
print('insert data into: ')
data_insert_method = ['new collection', 'existing collection']
for index, elem in enumerate(data_insert_method):
print(index, '-', elem)
while 1:
how_to_insert =
well, in my case, there is no GUI, and we do not intend to use it since
this script is only for internal testing purposes. So I am just wondering
how to loop menu in this context.
On 24 September 2017 at 22:03, Stefan Ram wrote:
> Daiyue Weng writes:
> >I am wondering how to loop back to the 1s
Hi, I tried to make a menu using print statements in Python 3. The code is
as follows,
print('insert data into: ')
data_insert_method = ['new collection', 'existing collection']
for index, elem in enumerate(data_insert_method):
print(index, '-', elem)
while 1:
how_to_insert = input('Choose a meth
Chris Angelico writes:
> while True:
> c = sys.stdin.read(1)
> if not c: break
> if c.isprintable(): text += c
> elif c == "\x08": text = text[:-1]
> # etc
> Can you write _that_ as a do-while?
I prefer to write that sort of thing with iterators:
for c in iter(lambda: sys.st
Op 16-04-17 om 19:07 schreef Terry Reedy:
> On 4/16/2017 11:35 AM, Michael Torrie wrote:
>> On 04/16/2017 07:57 AM, bartc wrote:
>>> But people just don't want it.
>>>
>>> /That/ is what surprises me, when people reject things that to me are
>>> no-brainers.
>
> Whereas to me, it is a no-brainer th
Ben Bacarisse wrote:
I fond the proportion on while True: loops surprising. Is there
something about Python that encourages that kind of loop?
Maybe because for-loops take care of most of the ordinary
cases in Python, leaving while-loops to cover the weird
ones, many of which need one or more
Christian Gollwitzer writes:
> Am 18.04.17 um 08:21 schrieb Chris Angelico:
>> On Tue, Apr 18, 2017 at 4:06 PM, Christian Gollwitzer
>> wrote:
>>> Am 18.04.17 um 02:18 schrieb Ben Bacarisse:
>>>
Thanks (and to Grant). IO seems to be the canonical example. Where
some languages would f
Am 18.04.17 um 08:21 schrieb Chris Angelico:
On Tue, Apr 18, 2017 at 4:06 PM, Christian Gollwitzer wrote:
Am 18.04.17 um 02:18 schrieb Ben Bacarisse:
Thanks (and to Grant). IO seems to be the canonical example. Where
some languages would force one to write
c = sys.stdin.read(1)
while c
Christian Gollwitzer :
> Am 18.04.17 um 02:18 schrieb Ben Bacarisse:
>> Python opts for
>>
>> while True:
>> c = sys.stdin.read(1)
>> if c != ' ': break
>
> This loop would be the archetypical do..while or repeat...until to me.
>
> do
> c = sys.stdin.read(1)
> while c== ' '
No,
On Tue, Apr 18, 2017 at 4:06 PM, Christian Gollwitzer wrote:
> Am 18.04.17 um 02:18 schrieb Ben Bacarisse:
>
>> Thanks (and to Grant). IO seems to be the canonical example. Where
>> some languages would force one to write
>>
>> c = sys.stdin.read(1)
>> while c == ' ':
>> c = sys.stdin.
Am 18.04.17 um 02:18 schrieb Ben Bacarisse:
Thanks (and to Grant). IO seems to be the canonical example. Where
some languages would force one to write
c = sys.stdin.read(1)
while c == ' ':
c = sys.stdin.read(1)
Python opts for
while True:
c = sys.stdin.read(1)
if c !=
On Tuesday, April 18, 2017 at 2:09:19 AM UTC+1, Paul Rubin wrote:
> Ben Bacarisse writes:
> > ? I get "AttributeError: 'itertools.dropwhile' object has no attribute
> > 'next'" from your example.
>
> Hmm, .next() worked ok for me in Python 2.7.5. Not sure what happened.
> Maybe something went wr
Ben Bacarisse :
> Python opts for
>
> while True:
> c = sys.stdin.read(1)
> if c != ' ': break
I opt for that in C and bash as well.
In fact, when I start writing a loop, I first type:
while True:
Once it is done, I might notice that the loop begins:
while True:
Gregory Ewing :
> Marko Rauhamaa wrote:
>> What I notice in my numbers is that about one half of my while loops
>> are "while True", and about a third of my loops are while loops.
>
> Out of curiosity, what proportion of your 'while True' loops are
> infinite? (I.e. no break, return or raise in th
On Tue, Apr 18, 2017 at 1:37 AM, MRAB wrote:
> In Python 3 it's:
>
> c = next(itertools.dropwhile(
> lambda c: c==' ',
> iter(lambda: sys.stdin.read(1),None)
> ))
iter's sentinel should be an empty string.
--
https://mail.python.org/mailman/listinfo/python-list
On 2017-04-18 02:09, Paul Rubin wrote:
Ben Bacarisse writes:
? I get "AttributeError: 'itertools.dropwhile' object has no attribute
'next'" from your example.
Hmm, .next() worked ok for me in Python 2.7.5. Not sure what happened.
Maybe something went wrong with my paste. Oh well.
Coming
Ben Bacarisse writes:
> ? I get "AttributeError: 'itertools.dropwhile' object has no attribute
> 'next'" from your example.
Hmm, .next() worked ok for me in Python 2.7.5. Not sure what happened.
Maybe something went wrong with my paste. Oh well.
> Coming from the lazy language Haskell, I find
Paul Rubin writes:
> Ben Bacarisse writes:
>> c = sys.stdin.read(1)
>> while c == ' ':
>> c = sys.stdin.read(1)
(for the record: I was not suggesting this was how you'd do it but how
you'd be forced to do it in some languages)
> c = itertools.dropwhile(
> lambda c: c==' ',
>
On 18/04/2017 01:23, Paul Rubin wrote:
Ben Bacarisse writes:
c = sys.stdin.read(1)
while c == ' ':
c = sys.stdin.read(1)
c = itertools.dropwhile(
lambda c: c==' ',
iter(lambda: sys.stdin.read(1),None)
).next()
I tried this but it doesn't like the .next.
I wanted t
Marko Rauhamaa writes:
> Ben Bacarisse :
>
>> Marko Rauhamaa writes:
>>> What I notice in my numbers is that about one half of my while loops
>>> are "while True", and about a third of my loops are while loops.
>>
>> I fo[u]nd the proportion on while True: loops surprising. Is there
>> something
Ben Bacarisse writes:
> c = sys.stdin.read(1)
> while c == ' ':
> c = sys.stdin.read(1)
c = itertools.dropwhile(
lambda c: c==' ',
iter(lambda: sys.stdin.read(1),None)
).next()
--
https://mail.python.org/mailman/listinfo/python-list
Marko Rauhamaa wrote:
What I notice in my numbers is that about one half of my while loops are
"while True", and about a third of my loops are while loops.
Out of curiosity, what proportion of your 'while True' loops
are infinite? (I.e. no break, return or raise in the loop.)
--
Greg
--
https:
On 2017-04-17, Ben Bacarisse wrote:
> Marko Rauhamaa writes:
>
>> Terry Reedy :
>>
>>> On 4/17/2017 3:11 AM, Marko Rauhamaa wrote:
Here's statistics from a medium-sized project of mine:
while True:34
while : 39
for ... in ...: 158
>>>
>>> As
uch more problems, and better code editors
should adress those, not current syntax.
As for loops, well, if we speak of some 'my' language,
it could be interesting whether there are common patterns.
But is it on-topic here to speak of, say PyBasic2020 fantasy
language?
For
Ben Bacarisse :
> Marko Rauhamaa writes:
>> What I notice in my numbers is that about one half of my while loops
>> are "while True", and about a third of my loops are while loops.
>
> I fo[u]nd the proportion on while True: loops surprising. Is there
> something about Python that encourages that
On 17/04/2017 19:02, Ben Bacarisse wrote:
Marko Rauhamaa writes:
Terry Reedy :
On 4/17/2017 3:11 AM, Marko Rauhamaa wrote:
Here's statistics from a medium-sized project of mine:
while True:34
while : 39
for ... in ...: 158
As I posted previously, the ratio
Marko Rauhamaa writes:
> Terry Reedy :
>
>> On 4/17/2017 3:11 AM, Marko Rauhamaa wrote:
>>> Here's statistics from a medium-sized project of mine:
>>>
>>>while True:34
>>>while : 39
>>>for ... in ...: 158
>>
>> As I posted previously, the ratio of for-loops in th
Terry Reedy :
> On 4/17/2017 3:11 AM, Marko Rauhamaa wrote:
>> Here's statistics from a medium-sized project of mine:
>>
>>while True:34
>>while : 39
>>for ... in ...: 158
>
> As I posted previously, the ratio of for-loops in the stdlib is about 7
> to 1.
What I
On 4/17/2017 3:11 AM, Marko Rauhamaa wrote:
Gregory Ewing :
bartc wrote:
Most of my loops start off as endless loops, until I can determine
the actual terminating condition, and where it best goes.
Interesting. My experience is quite different. Most of the loops I
write start off with me thi
Gregory Ewing :
> bartc wrote:
>> Most of my loops start off as endless loops, until I can determine
>> the actual terminating condition, and where it best goes.
>
> Interesting. My experience is quite different. Most of the loops I
> write start off with me thinking "Now I want to do this for eac
On Mon, 17 Apr 2017 05:49 am, Dennis Lee Bieber wrote:
> On Mon, 17 Apr 2017 02:48:08 +1000, Steve D'Aprano
> declaimed the following:
>
>>On Sun, 16 Apr 2017 11:57 pm, bartc wrote:
>>
>>> But people just don't want it.
>>
>>Damn straight. Now you get it. It's not about how easy it is to impleme
es, and have characteristics
that can't easily be replicated using the fundamental types,
if at all.
Alternative looping constructs, in contrast, have *no*
functional difference, their only advantage being that they
provide a slightly more succint way of expressing certain
things.
While a;
On 16/04/2017 19:42, Chris Angelico wrote:
On Mon, Apr 17, 2017 at 4:21 AM, bartc wrote:
Here is a function from some old CPython source that appears to be something
to do with While statements:
static int
validate_while(node *tree)
{
...
Look, no comments! Are you going to castigate the dev
On Mon, Apr 17, 2017 at 4:21 AM, bartc wrote:
> Here is a function from some old CPython source that appears to be something
> to do with While statements:
>
> static int
> validate_while(node *tree)
> {
> int nch = NCH(tree);
> int res = (validate_ntype(tree, while_stmt)
>
On 16/04/2017 17:30, Steve D'Aprano wrote:
On Sun, 16 Apr 2017 10:06 pm, bartc wrote:
(The 30 Loc figure is with support for loops /in
general/ already in place, and is for /adding/ a new loop statement, in
this case 'while')
What part of *testing* and *documenting* do you not understand?
On Mon, 17 Apr 2017 03:00 am, Rustom Mody wrote:
> BTW I regard Steven's long list of things that youve missed such as
> regression tests, docs etc to be somewhat off the mark
> To see that try this experiment:
> Just add a feature to python that matters to you along with all these
> requirements
ests and a few packages in
site-packages. These got 1389 and 9842 hits respectively. I am opposed
to adding syntax to subdivide the 12% of looping using 'while'. (As a
note, '^ *while True' had 363 hits, about 1/4 of while loops.)
> I have yet to find a loop that I
On Sunday, April 16, 2017 at 7:27:49 PM UTC+5:30, bartc wrote:
> Technically, adding this one feature to Python /is/ trivial,
^
You are not paying attention bart and I am not likely to pursue this beyond this
post. I tried to say as are others that the substantive reasons to reject a
On Sun, 16 Apr 2017 11:57 pm, bartc wrote:
> Yet countless other, far more elaborate features /are/ added all the time.
Indeed. Because they are needed. Because they add functionality that Python
doesn't already have, or seriously improves the interface to that
functionality.
> Technically, add
ses of Python's for loop, were, for example, there are
> multiple loop variables.
>
> I wonder how much testing that took to get it right?
Probably a lot. And it would be worth it even if it took fifty times more
testing.
[...]
>>> But very common requirements are endle
On 16/04/2017 15:22, Chris Angelico wrote:
On Sun, Apr 16, 2017 at 11:57 PM, bartc wrote:
Technically, adding this one feature to Python /is/ trivial, for example,
allowing while: as a synonym for while True:, but preferably using a new
keyword such as loop. Nothing else needs to be touched. An
ly works well for many people.
I have yet to find a loop that I couldn't construct with Python's
apparently-limited constructs. I guess I don't see what having those
extra looping constructs will give me in terms of productivity or even
ease of use.
--
https://mail.python.org/mailman/listinfo/python-list
On Sun, Apr 16, 2017 at 11:57 PM, bartc wrote:
> Technically, adding this one feature to Python /is/ trivial, for example,
> allowing while: as a synonym for while True:, but preferably using a new
> keyword such as loop. Nothing else needs to be touched. And it could have
> been done right at the
On 16/04/2017 13:22, Rustom Mody wrote:
On Sunday, April 16, 2017 at 5:36:28 PM UTC+5:30, bartc wrote:
On 16/04/2017 03:51, Steve D'Aprano wrote:
On Sat, 15 Apr 2017 10:17 pm, bartc wrote:
Yes, I'm constantly surprised at this, as such syntax has a very low
cost (in my last compiler, support
On Sunday, April 16, 2017 at 5:36:28 PM UTC+5:30, bartc wrote:
> On 16/04/2017 03:51, Steve D'Aprano wrote:
> > On Sat, 15 Apr 2017 10:17 pm, bartc wrote:
>
> >> Yes, I'm constantly surprised at this, as such syntax has a very low
> >> cost (in my last compiler, supporting 'while' for example only
ter the test
thus combining both the
repeat while condition:
...
and
do:
...
until condition
styles of looping in one handy syntax.
Perhaps you misremembered as that looks too unwieldy to be practical. If
implemented orthogonally, then a loop like this:
While A
executed once only
> REPEAT
> loop body # before the test
> WHILE condition # test
> loop body # after the test
>
> thus combining both the
>
> repeat while condition:
> ...
>
> and
>
> do:
> ...
> until condition
&
n # test
loop body # after the test
thus combining both the
repeat while condition:
...
and
do:
...
until condition
styles of looping in one handy syntax.
> Of course, it's possible to overdo it; if you look at Lisp, you'll lose
> yourself in th
For completeness I was close this is the working code.
def get_list_of_names(generator_arg):
name_set = set()
for name in generator_arg:
base = os.path.basename(name.name)
filename = os.path.splitext(base)[0]
name_set.add(filename)
return name_set
def data_att
On Wed, 4 Jan 2017 01:09 pm, Sayth Renshaw wrote:
> Untested as i wrote this in notepad at work but, if i first use the
> generator to create a set of filenames and then iterate it then call the
> generator anew to process file may work?
It "may" work. Or it "may not" work. It is hard to tell bec
On 04/01/17 02:10, Deborah Swanson wrote:
> Sayth Renshaw wrote, on January 03, 2017 5:36 PM
>>
>> So can I call the generator twice and receive the same file
>> twice in 2 for loops?
>>
>> Once to get the files name and the second to process?
>>
>> for file in rootobs:
>> base = os.path.b
ery handles for you under the covers. Each 'for' statement
> effectively has a 'try' block around it that catches
> 'StopIteration' and
> just terminates that particular 'for' loop and continues on with the
> remainder of your script.
>
> Ra
Sayth Renshaw wrote, on January 03, 2017 5:36 PM
>
> So can I call the generator twice and receive the same file
> twice in 2 for loops?
>
> Once to get the files name and the second to process?
>
> for file in rootobs:
> base = os.path.basename(file.name)
> write_to = os.path.join
Sayth Renshaw wrote, on January 03, 2017 5:55 PM
>
> On Wednesday, 4 January 2017 12:36:10 UTC+11, Sayth Renshaw wrote:
> > So can I call the generator twice and receive the same file
> twice in 2
> > for loops?
> >
> > Once to get the files name and the second to process?
> >
> > for file in roo
Untested as i wrote this in notepad at work but, if i first use the generator
to create a set of filenames and then iterate it then call the generator anew
to process file may work?
Good idea or better available?
def get_list_of_names(generator_arg):
name_set = set()
for name in generat
Chris Angelico wrote, on January 03, 2017 3:35 PM
>
> On Wed, Jan 4, 2017 at 10:05 AM, Deborah Swanson
> wrote:
> > Ok, I learned how to use generators in Python 2.7.8, which may be
> > different from Python 3 for generators. But I learned from MIT's
> > online introduction to python course, and t
So can I call the generator twice and receive the same file twice in 2 for
loops?
Once to get the files name and the second to process?
for file in rootobs:
base = os.path.basename(file.name)
write_to = os.path.join("output", os.path.splitext(base)[0] + ".csv")
with open
Erik wrote, on January 03, 2017 3:53 PM
>
> On 03/01/17 23:05, Deborah Swanson wrote:
> > And yes, we usually used for loops for generators, unless you don't
> > know when the generator will be exhausted. As in this case,
> where the
> > number of files the generator can provide is unknown. Then
>
On Wednesday, 4 January 2017 12:36:10 UTC+11, Sayth Renshaw wrote:
> So can I call the generator twice and receive the same file twice in 2 for
loops?
>
> Once to get the files name and the second to process?
>
> for file in rootobs:
> base = os.path.basename(file.name)
> write_to
y' block around it
that catches 'StopIteration' and just terminates that particular 'for' loop and
continues on with the remainder of your script.
Raising a 'StopIteration' is an internal mechanism used to determine when an
iterator (i.e., the thing a 'for
Erik wrote, on January 03, 2017 3:45 PM
>
> Hi,
>
> On 03/01/17 22:14, Deborah Swanson wrote:
> > ...you have to create the generator object first and use it to call
> > the next function. And I really don't think you can use a
> generator as
> > your range in a for loop. So I'd use a 'while True',
On 03/01/17 23:05, Deborah Swanson wrote:
> And yes, we usually used for loops for generators, unless you don't know
> when the generator will be exhausted. As in this case, where the number
> of files the generator can provide is unknown. Then we used the while
> True, break on StopIteration metho
Hi,
On 03/01/17 22:14, Deborah Swanson wrote:
> ...you have to create the generator object first and use it to call the
> next function. And I really don't think you can use a generator as your
> range in a for loop. So I'd use a 'while True', and break out of the
> loop when you hit the StopItera
-Original Message-
From: Matt Wheeler [mailto:m...@funkyhat.org]
Sent: Tuesday, January 03, 2017 1:47 PM To: pyt...@deborahswanson.net; Sayth
Renshaw; python-list@python.org
Subject: Re: Screwing Up looping in Generator
On Tue, 3 Jan 2017 at 20:17 Deborah Swanson wrote:
> What&#x
Chris Angelico wrote, on January 03, 2017 2:31 PM
>
> On Wed, Jan 4, 2017 at 8:19 AM, Deborah Swanson
> wrote:
> > while True:
> > try:
> > file = files.next()
> > except StopIteration:
> > break
>
> Small side point: Try to avoid calling a generator object's
> .next() method directly.
Terry Reedy
>
> On 1/3/2017 3:53 PM, Deborah Swanson wrote:
>
> >> I think you're expecting
> >>
> >>for file in rootobs
> >>
> >> to get the next yield for you from rootobs, but unless someone
> >> corrects me, I don't think you can expect a 'for' statement to do
> >> that. You need to have a
On Wed, Jan 4, 2017 at 10:05 AM, Deborah Swanson
wrote:
> Ok, I learned how to use generators in Python 2.7.8, which may be
> different from Python 3 for generators. But I learned from MIT's online
> introduction to python course, and they certainly seem to know python
> well. So what is the corre
On Wed, Jan 4, 2017 at 8:19 AM, Deborah Swanson
wrote:
> while True:
> try:
> file = files.next()
> except StopIteration:
> break
Small side point: Try to avoid calling a generator object's .next() method
directly. Normally, when you _do_ want to do this, you should be calling
next(
On 1/3/2017 3:53 PM, Deborah Swanson wrote:
>> I think you're expecting
>>
>> for file in rootobs
>>
>> to get the next yield for you from rootobs, but unless
>> someone corrects me, I don't think you can expect a 'for'
>> statement to do that. You need to have a 'next' statement
>> inside yo
On Tue, 3 Jan 2017 at 21:46 Matt Wheeler wrote:
> range() is not part of the for syntax at all, it's completely separate, it
> simply returns an iterator which the for loop can use, like any other.
>
*iterable
--
--
Matt Wheeler
http://funkyh.at
--
https://mail.python.org/mailman/listinfo/pyt
On Tue, 3 Jan 2017 at 20:17 Deborah Swanson wrote:
> > What's the code for your generator? And I don't see where you
> > call 'next'.
>
> I think you're expecting
>
> for file in rootobs
>
> to get the next yield for you from rootobs, but unless someone corrects
> me, I don't think you ca
t; > > > cannot get len(generator) to use a while loop on. it exhausts
> > > >
> > > > should I use the same for again after the with open?
> > > >
> > > > rootobs in this code is my generator and I am already looping it
> > > > however
> > > should I use the same for again after the with open?
> > >
> > > rootobs in this code is my generator and I am already looping it
> > > however def data_attr(roots):
> > > """Get the root object and iter items."""
be a written file for each
> input file. I saw a roundrobin example however it failed for
> me as you cannot get len(generator) to use a while loop on.
> it exhausts
>
> should I use the same for again after the with open?
>
> rootobs in this code is my generator and I am al
> >
> > I want to alter the behaviour to be a written file for each
> > input file. I saw a roundrobin example however it failed for
> > me as you cannot get len(generator) to use a while loop on.
> > it exhausts
> >
> > should I use the same for again after the
For completeness I was close this is the working code.
def get_list_of_names(generator_arg):
name_set = set()
for name in generator_arg:
base = os.path.basename(name.name)
filename = os.path.splitext(base)[0]
name_set.add(filename)
return name_set
def data_att
On 04/01/17 02:10, Deborah Swanson wrote:
Sayth Renshaw wrote, on January 03, 2017 5:36 PM
So can I call the generator twice and receive the same file
twice in 2 for loops?
Once to get the files name and the second to process?
for file in rootobs:
base = os.path.basename(file.name)
On Wed, 4 Jan 2017 01:09 pm, Sayth Renshaw wrote:
> Untested as i wrote this in notepad at work but, if i first use the
> generator to create a set of filenames and then iterate it then call the
> generator anew to process file may work?
It "may" work. Or it "may not" work. It is hard to tell bec
pt.
>
> Raising a 'StopIteration' is an internal mechanism used to determine
> when an iterator (i.e., the thing a 'for' loop is looping over) has
> exhausted itself. It's not something a regular user is ever
> expected to
> know about let alone catch.
&g
Sayth Renshaw wrote, on January 03, 2017 5:55 PM
>
> On Wednesday, 4 January 2017 12:36:10 UTC+11, Sayth Renshaw wrote:
> > So can I call the generator twice and receive the same file
> twice in 2
> > for loops?
> >
> > Once to get the files name and the second to process?
> >
> > for file i
Untested as i wrote this in notepad at work but, if i first use the generator
to create a set of filenames and then iterate it then call the generator anew
to process file may work?
Good idea or better available?
def get_list_of_names(generator_arg):
name_set = set()
for name in generat
Sayth Renshaw wrote, on January 03, 2017 5:36 PM
>
> So can I call the generator twice and receive the same file
> twice in 2 for loops?
>
> Once to get the files name and the second to process?
>
> for file in rootobs:
> base = os.path.basename(file.name)
> write_to = os.pat
Chris Angelico wrote, on January 03, 2017 3:35 PM
>
> On Wed, Jan 4, 2017 at 10:05 AM, Deborah Swanson
> wrote:
> > Ok, I learned how to use generators in Python 2.7.8, which may be
> > different from Python 3 for generators. But I learned from MIT's
> > online introduction to python course, a
On Wednesday, 4 January 2017 12:36:10 UTC+11, Sayth Renshaw wrote:
> So can I call the generator twice and receive the same file twice in 2 for
> loops?
>
> Once to get the files name and the second to process?
>
> for file in rootobs:
> base = os.path.basename(file.name)
> w
So can I call the generator twice and receive the same file twice in 2 for
loops?
Once to get the files name and the second to process?
for file in rootobs:
base = os.path.basename(file.name)
write_to = os.path.join("output", os.path.splitext(base)[0] + ".csv")
with o
k around it that catches 'StopIteration' and
just terminates that particular 'for' loop and continues on with the
remainder of your script.
Raising a 'StopIteration' is an internal mechanism used to determine
when an iterator (i.e., the thing a 'for' loop is
Erik wrote, on January 03, 2017 3:53 PM
>
> On 03/01/17 23:05, Deborah Swanson wrote:
> > And yes, we usually used for loops for generators, unless you don't
> > know when the generator will be exhausted. As in this case,
> where the
> > number of files the generator can provide is unknown. The
Erik wrote, on January 03, 2017 3:45 PM
>
> Hi,
>
> On 03/01/17 22:14, Deborah Swanson wrote:
> > ...you have to create the generator object first and use it to call
> > the next function. And I really don't think you can use a
> generator as
> > your range in a for loop. So I'd use a 'while T
On 03/01/17 23:05, Deborah Swanson wrote:
And yes, we usually used for loops for generators, unless you don't know
when the generator will be exhausted. As in this case, where the number
of files the generator can provide is unknown. Then we used the while
True, break on StopIteration method.
O
Hi,
On 03/01/17 22:14, Deborah Swanson wrote:
...you have to create the generator object first and use it to call the
next function. And I really don't think you can use a generator as your
range in a for loop. So I'd use a 'while True', and break out of the
loop when you hit the StopIteration e
1 - 100 of 454 matches
Mail list logo
