please help shrink this each_with_index() implementation

[Phlip]

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?

 

[akean]

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?

y = [[seq,i] for i in range(len(seq))] gives the same result.
The index is accessible without assigning it to another variable.

 

[Marco Nawijn]

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?

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?

 

[Phlip]

My Pythonic sequencing skills are obviously feeble. Can anything think
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]

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]

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:
153

then yes it does. But if you mean something like this:

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.

 

[Phlip]

Does it say how to convert a string containing either an integer

If you mean something like this:


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]

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 ;-)

Someone wrote about a port of a Perl script to Python. The script would
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]

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!


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.

 

[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]

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]

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".

Writing robust software from the outset puts you at a competitive
disadvantage to those who understand how the system works.

 

[Phlip]

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.

 

[Antoine Pitrou]

Le Wed, 06 Jan 2010 12:12:08 -0800, Phlip a écrit :

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.