please help shrink this each_with_index() implementation
Phlip
def each_with_index(seq):
index = 0
result = []
for item in seq:
result.append([item, index])
index += 1
return result
My Pythonic sequencing skills are obviously feeble. Can anything think
of a way to write that in fewer lines?
akean
y = [[seq[i],i] for i in range(len(seq))] gives the same result.
The index is accessible without assigning it to another variable.
--
Anita
Marco Nawijn
You could use the build-in function enumerate inside a list
comprehension.
>>> seq = range(5)
>>> [ (i,s) for i,s in enumerate(seq) ]
[(0, 0), (1, 1), (2, 2), (3, 3), (4, 4)]
This will reduce the function to a one-liner.
Regards,
Marco
Carsten Haese
> Hypo Nt:
>
> def each_with_index(seq):
> index = 0
> result = []
>
> for item in seq:
> result.append([item, index])
> index += 1
>
> return result
>
> My Pythonic sequencing skills are obviously feeble. Can anything think
> of a way to write that in fewer lines?
Couldn't you just use the built-in enumerate() to replace the whole thing?
--
Carsten Haese
http://informixdb.sourceforge.net
Phlip
> > of a way to write that in fewer lines?
Thanks, all!
> Couldn't you just use the built-in enumerate() to replace the whole thing?
Because that would involve, like, reading an entire Python book just
to locate that method?
GMAB I'm too busy writing high-end Django via TDD & BDD! C-:
Antoine Pitrou
>> Couldn't you just use the built-in enumerate() to replace the whole
>> thing?
>
> Because that would involve, like, reading an entire Python book just to
> locate that method?
Actually, no. It just involves reading one of the most important pages in
the documentation, the page which describes the built-in functions:
http://docs.python.org/library/functions.html
Don't forget that the Python documentation is rich and structured.
And good luck.
Phlip
> http://docs.python.org/library/functions.html
>
> Don't forget that the Python documentation is rich and structured.
> And good luck.
Does it say how to convert a string containing either an integer
representation, or something alphabetic, into an integer, or a zero,
in like 1 method call? (No except: ?)
Nothing personal, but I'm finding the super-hard stuff very facile &
tractable, and the easy stuff absurdly hard around here...
Steven D'Aprano
> On Jan 5, 1:10 pm, Antoine Pitrou <solip...@pitrou.net> wrote:
>
>> http://docs.python.org/library/functions.html
>>
>> Don't forget that the Python documentation is rich and structured. And
>> good luck.
>
> Does it say how to convert a string containing either an integer
> representation, or something alphabetic, into an integer, or a zero, in
> like 1 method call? (No except: ?)
If you mean something like this:
>>> int('153')
153
then yes it does. But if you mean something like this:
>>> some_mysterious_function('one hundred and fifty-three')
153
then no, it doesn't.
> Nothing personal, but I'm finding the super-hard stuff very facile &
> tractable, and the easy stuff absurdly hard around here...
Then perhaps you should work through the tutorial to learn the basics.
--
Steven
Phlip
> > representation, or something alphabetic, into an integer, or a zero, in
> > like 1 method call? (No except: ?)
>
> If you mean something like this:
>
> >>> int('153')
>
> 153
The point: int('') or int('something') both throw an error. In
general, this is hand-holding, but in specific I don't think the "rich
and structured" documentation will cover how to beat a 0 out of it in
less than 3 lines. So I will persist in my idiotic questions here!
> Then perhaps you should work through the tutorial to learn the basics.
They will tell me how to use except: (which is a good example why a
program should not use exceptions for its normal control flow if at
all possible).
Please, please, please save your newbie admonitions for those who
qualify!
Antoine Pitrou
> The point: int('') or int('something') both throw an error. In general,
> this is hand-holding, but in specific I don't think the "rich and
> structured" documentation will cover how to beat a 0 out of it in less
> than 3 lines.
Because it's a bad idea to do so and Python doesn't encourage such sloppy
behaviour. If you like it, though, you might prefer PHP.
By the way: error reporting is definitely *not* hand-holding. It is
simply not good to let errors pass silently by default. Again, if you
think the contrary, PHP is your friend ;-)
MRAB
>> The point: int('') or int('something') both throw an error. In general,
>> this is hand-holding, but in specific I don't think the "rich and
>> structured" documentation will cover how to beat a 0 out of it in less
>> than 3 lines.
>
> behaviour. If you like it, though, you might prefer PHP.
>
> By the way: error reporting is definitely *not* hand-holding. It is
> simply not good to let errors pass silently by default. Again, if you
> think the contrary, PHP is your friend ;-)
>
parse the output from a program it would call, but the Python script
sometimes raised a ValueError when it tried to convert a certain field
to a number. It turned out that sometimes the field would contain
"ERROR" instead of a number. The Perl script had been silently
'converting' any such "ERROR" to 0!
alex23
> They will tell me how to use except: (which is a good example why a
> program should not use exceptions for its normal control flow if at
> all possible).
Really? Magic functions that coerce and eat errors are a better coding
technique than exceptions and explicit handling?
What kool-aid have you been drinking?
Steven D'Aprano
>> > Does it say how to convert a string containing either an integer
>> > representation, or something alphabetic, into an integer, or a zero,
>> > in like 1 method call? (No except: ?)
>>
>> If you mean something like this:
>>
>> >>> int('153')
>>
>> 153
>
> The point: int('') or int('something') both throw an error.
Well, that's a bug. Obviously they should return 42.
Or is that 23? I forget.
But seriously... of course they do. What did you expect them to do?
Any Python function will raise an exception if you pass invalid data to
it. So the solutions are, don't pass invalid data, or wrap the function
in a try block. If you don't want to use try, then make sure that your
data is good.
> In general,
> this is hand-holding, but in specific I don't think the "rich and
> structured" documentation will cover how to beat a 0 out of it in less
> than 3 lines. So I will persist in my idiotic questions here!
>
>> Then perhaps you should work through the tutorial to learn the basics.
>
> They will tell me how to use except: (which is a good example why a
> program should not use exceptions for its normal control flow if at all
> possible).
Huh? So because YOU don't know how to use except, programs shouldn't use
exceptions for flow control? I reject that, and I will continue using
exceptions for flow control when I think it is appropriate.
> Please, please, please save your newbie admonitions for those who
> qualify!
Oh please, get off your high horse. You're asking newbie questions, no
matter how many years of using Python you may or may not have, your
experience is obviously low. Stick around and you might learn something,
but if you bite every time somebody tries to teach you, you'll soon run
out of people willing to help you.
--
Steven
alex23
> Stick around and you might learn something,
> but if you bite every time somebody tries to teach you, you'll soon run
> out of people willing to help you.
The ongoing crowdsourced development by this group of "Victor
Subervi's" project would seem to indicate that this isn't the case. Or
that if it is, that it will be a good handful of months at the very
soonest before it becomes true.
Nobody
> You could use the build-in function enumerate inside a list
> comprehension.
>
>>>> seq = range(5)
>>>> [ (i,s) for i,s in enumerate(seq) ]
> [(0, 0), (1, 1), (2, 2), (3, 3), (4, 4)]
Just use list(), i.e. "list(enumerate(seq))".
Carl Banks
> On Jan 5, 1:10 pm, Antoine Pitrou <solip...@pitrou.net> wrote:
>
> >http://docs.python.org/library/functions.html
>
> > Don't forget that the Python documentation is rich and structured.
> > And good luck.
>
> Does it say how to convert a string containing either an integer
> representation, or something alphabetic, into an integer, or a zero,
> in like 1 method call?
No, as he said, it only describes the most important functions.
Carl Banks
Nobody
Maybe he's doing it for a living?
Contract programming seems to work on the basis that the ultimate
requirement is for the client to hand over the money. If, at that point,
the program is still full of bugs, you get to charge extra for "upgrades".
Writing robust software from the outset puts you at a competitive
disadvantage to those who understand how the system works.
Phlip
> On Tue, 05 Jan 2010 19:46:01 -0800, alex23 wrote:
>
>>> They will tell me how to use except: (which is a good example why a
>>> program should not use exceptions for its normal control flow if at
>>> all possible).
>> Really? Magic functions that coerce and eat errors are a better coding
>> technique than exceptions and explicit handling?
>>
>> What kool-aid have you been drinking?
>
> Maybe he's doing it for a living?
>
> Contract programming seems to work on the basis that the ultimate
> requirement is for the client to hand over the money. If, at that point,
> the program is still full of bugs, you get to charge extra for "upgrades".
Uh, no, right now I'm working with the long-term goal of creating useful modules
that sustain us equitably.
> Writing robust software from the outset puts you at a competitive
> disadvantage to those who understand how the system works.
And I, not my language, should pick and chose how to be rigorous. The language
should not make the decision for me.
Steven D'Aprano
> And I, not my language, should pick and chose how to be rigorous. The
> language should not make the decision for me.
All languages make that decision for you by making some thing possible
and other things not. The language designer, not the programmer, decides
what syntactic features to allow and disallow, what programming styles to
include, and what functionality to provide as primitives.
--
Steven
Antoine Pitrou
>
> And I, not my language, should pick and chose how to be rigorous. The
> language should not make the decision for me.
And that's why there is the "try: ... except: ..." construct.
Your rant is getting tiring.
alex23
> And I, not my language, should pick and chose how to be rigorous. The language
> should not make the decision for me.
Since you seem unwilling to put the minimal effort into producing the
support code you'd need to work with Python the way you want, perhaps
Perl might be more to your liking?
Carl Banks
> Nobody wrote:
> > Writing robust software from the outset puts you at a competitive
> > disadvantage to those who understand how the system works.
>
> And I, not my language, should pick and chose how to be rigorous. The language
> should not make the decision for me.
Oh well, your language does. Deal with it, or pick another language.
Carl Banks
P.S. Actually, Python has ways to request no expection when it's
actually useful, e.g. the get method of dicts, but not when it's
ridiculous and stupid like int() returning zero on error.
Roel Schroeven
> Nobody wrote:
>> Writing robust software from the outset puts you at a competitive
>> disadvantage to those who understand how the system works.
>
> And I, not my language, should pick and chose how to be rigorous. The language
> should not make the decision for me.
You can always easily make your program less rigorous than the language,
but the reverse is generally very difficult. So a rigorous language
gives you the choice, why a non-rigorous language does not.
--
The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
-- Isaac Asimov
Roel Schroeven