I have function which takes an argument. My code needs that argument
to be an iterable (something i can loop over)...so I dont care if its a
list, tuple, etc. So I need a way to make sure that the argument is an
iterable before using it. I know I could do...
def foo(inputVal):
if isinstance
I have function which takes an argument. My code needs that argument
to be an iterable (something i can loop over)...so I dont care if its a
list, tuple, etc. So I need a way to make sure that the argument is an
iterable before using it. I know I could do...
def foo(inputVal):
if isinstance
On 15 Nov 2005 11:01:48 -0800,
"py" <[EMAIL PROTECTED]> wrote:
> I have function which takes an argument. My code needs that argument
> to be an iterable (something i can loop over)...so I dont care if its a
> list, tuple, etc. So I need a way to make sure that the argument is an
> iterable befo
On Tue, 2005-11-15 at 11:01 -0800, py wrote:
> I have function which takes an argument. My code needs that argument
> to be an iterable (something i can loop over)...so I dont care if its a
> list, tuple, etc. So I need a way to make sure that the argument is an
> iterable before using it. I kno
Dan Sommers wrote:
> Just do it. If one of foo's callers passes in a non-iterable, foo will
> raise an exception, and you'll catch it during testing
That's exactly what I don't want. I don't want an exception, instead I
want to check to see if it's an iterableif it is continue, if not
return
On 15 Nov 2005 11:26:23 -0800, py <[EMAIL PROTECTED]> wrote:
>Dan Sommers wrote:
>> Just do it. If one of foo's callers passes in a non-iterable, foo will
>> raise an exception, and you'll catch it during testing
>
>That's exactly what I don't want. I don't want an exception, instead I
>want to c
marduk wrote:
> On Tue, 2005-11-15 at 11:01 -0800, py wrote:
>
>>I have function which takes an argument. My code needs that argument
>>to be an iterable (something i can loop over)...so I dont care if its a
>>list, tuple, etc. So I need a way to make sure that the argument is an
>>iterable befo
py wrote:
> Dan Sommers wrote:
>
>>Just do it. If one of foo's callers passes in a non-iterable, foo will
>>raise an exception, and you'll catch it during testing
>
> That's exactly what I don't want. I don't want an exception, instead I
> want to check to see if it's an iterableif it is co
Hi!
py wrote:
> Dan Sommers wrote:
>
>>Just do it. If one of foo's callers passes in a non-iterable, foo will
>>raise an exception, and you'll catch it during testing
>
>
> That's exactly what I don't want. I don't want an exception, instead I
> want to check to see if it's an iterableif
Thanks for the replies. I agree with Jean-Paul Calderone's
suggestion...let the exception be raised.
Thanks.
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
py <[EMAIL PROTECTED]> wrote:
>I have function which takes an argument. My code needs that argument
>to be an iterable (something i can loop over)...so I dont care if its a
>list, tuple, etc.
My first thought was to just write your loop inside a try block and
catch
On 2005-11-15, py <[EMAIL PROTECTED]> wrote:
> Dan Sommers wrote:
>> Just do it. If one of foo's callers passes in a non-iterable, foo will
>> raise an exception, and you'll catch it during testing
>
> That's exactly what I don't want. I don't want an exception, instead I
> want to check to see i
On 15 Nov 2005 11:26:23 -0800 in comp.lang.python, "py"
<[EMAIL PROTECTED]> wrote:
>Dan Sommers wrote:
>> Just do it. If one of foo's callers passes in a non-iterable, foo will
>> raise an exception, and you'll catch it during testing
>
>That's exactly what I don't want. I don't want an exceptio
Maybe this helps:
>>> import types
>>> def foo(inputVal):
inValType = type(inputVal)
if inValType==types.ListType or inValType==types.TupleType:
for val in inputVal:
print val
else:
print 'Wrong input Type'
>>> list = [1,2,3,4]
>>> foo(list)
1
2
3
4
>>
On Tue, 15 Nov 2005 14:06:45 -0500, Dan Sommers wrote:
> On 15 Nov 2005 11:01:48 -0800,
> "py" <[EMAIL PROTECTED]> wrote:
>
>> I have function which takes an argument. My code needs that argument
>> to be an iterable (something i can loop over)...so I dont care if its a
>> list, tuple, etc. So
How about hasattr("__iter__")?
Regards,
Karsten.
--
http://mail.python.org/mailman/listinfo/python-list
[EMAIL PROTECTED] wrote:
> Maybe this helps:
>
> >>> import types
> >>> def foo(inputVal):
> inValType = type(inputVal)
> if inValType==types.ListType or inValType==types.TupleType:
And what of user-created types that are iterable?
What of user-created iterable types that don't inher
On Tue, 15 Nov 2005 11:26:23 -0800, py wrote:
> Dan Sommers wrote:
>> Just do it. If one of foo's callers passes in a non-iterable, foo will
>> raise an exception, and you'll catch it during testing
>
> That's exactly what I don't want. I don't want an exception, instead I
> want to check to se
Roy Smith <[EMAIL PROTECTED]> wrote:
...
> TypeError: iteration over non-sequence
>
> I was kind of hoping for a more specific exception than TypeError.
> You can't tell the difference between:
>
> try:
> for i in 5:
> print i + 1
> except TypeError:
> print "non-iterable"
>
> and
>
Roy Smith wrote:
> You can't tell the difference between:
>
> try:
> for i in 5:
> print i + 1
> except TypeError:
> print "non-iterable"
>
> and
>
> try:
> for i in ["one", "two", "three"]:
> print i + 1
> except TypeError:
> print "can't add string and integer"
try:
for
[EMAIL PROTECTED] wrote:
> Maybe this helps:
Unfortunately, it doesn't. If you read the sample code
the original poster first gave, you will see that Py's
example is virtually the same as yours:
[original code]
def foo(inputVal):
if isinstance(inputVal, (list, tuple)):
for val in
On Wed, 16 Nov 2005 13:12:38 +1100,
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> try:
> for item in obj:
> do_stuff(item)
> except TypeError, msg:
> if msg == "iteration over non-sequence":
> handle_non_iterator()
> else:
> # re-raise the exception
>
In article <[EMAIL PROTECTED]>,
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> try:
> for item in obj:
> do_stuff(item)
> except TypeError, msg:
> if msg == "iteration over non-sequence":
> handle_non_iterator()
> else:
> # re-raise the exception
>
On Tue, 15 Nov 2005 21:54:07 -0500, Dan Sommers wrote:
> On Wed, 16 Nov 2005 13:12:38 +1100,
> Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>
>> try:
>> for item in obj:
>> do_stuff(item)
>> except TypeError, msg:
>> if msg == "iteration over non-sequence":
>> handle_non
On Tue, 15 Nov 2005 21:59:44 -0500, Roy Smith wrote:
> In article <[EMAIL PROTECTED]>,
> Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>
>> try:
>> for item in obj:
>> do_stuff(item)
>> except TypeError, msg:
>> if msg == "iteration over non-sequence":
>> handle_non_iter
Steven D'Aprano <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> def foo(inputVal):
> try:
> for val in inputVal:
> # do stuff
> except TypeError, msg:
> if msg == "iteration over non-sequence":
> # handle non-iterable case
> else:
>
In article <[EMAIL PROTECTED]>,
Rick Wotnaz <[EMAIL PROTECTED]> wrote:
> Steven D'Aprano <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
>
> > def foo(inputVal):
> > try:
> > for val in inputVal:
> > # do stuff
> > except TypeError, msg:
> > if msg ==
Rick Wotnaz wrote.
> ... which leads me to belive that 'msg' is not type(str). It can be
> coerced (str(msg).find works as expected). But what exactly is msg?
> It appears to be of , and does not test equal to a
> string.
it's an instance of the exception type, of course.
:::
if you do
rai
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> Rick Wotnaz wrote.
>
>> ... which leads me to belive that 'msg' is not type(str). It
>> can be coerced (str(msg).find works as expected). But what
>> exactly is msg? It appears to be of , and does
>> not test equal to a strin
On Wed, 16 Nov 2005 09:06:01 -0500, Rick Wotnaz wrote:
[cutting to the important bit]
>> except TypeError, msg:
>> if msg == "iteration over non-sequence":
>> # handle non-iterable case
> Does this in fact work on your system? On mine (2.4.1 (#65, Mar 30
> 2005, 09:13:57)
Steven D'Aprano wrote:
> This means we're no longer assuming what the error message will be,
> which makes our code a lot more future-proof and implementation-proof: if
> some version of Python changes the error string from "iteration over
> non-sequence" to something else, the code should continu
> Alex has already posted the right way to do this. can you please stop
posting crappy non-solutions to a problem that has a very simple solution (split
things up), that should be obvious to anyone who didn't sleep through exceptions
101.
--
http://mail.python.org/mailman/listinfo/python-l
On Wed, 16 Nov 2005 17:39:57 +0100, "Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
>Rick Wotnaz wrote.
>
>> ... which leads me to belive that 'msg' is not type(str). It can be
>> coerced (str(msg).find works as expected). But what exactly is msg?
>> It appears to be of , and does not test equal to a
>
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
># Create an instance of the exception you expect:
>try:
>for i in 0:
>pass
>except TypeError, ITER_OVER_NON_SEQ:
>pass
># Now run your code...
>try:
>...blah blah blah...
>except TypeError, msg
>if str(msg) == str(ITER_OVER_NON_SE
Fredrik Lundh wrote:
> Steven D'Aprano wrote:
>
>
>>This means we're no longer assuming what the error message will be,
>>which makes our code a lot more future-proof and implementation-proof: if
>>some version of Python changes the error string from "iteration over
>>non-sequence" to something
Ah, found the right solution! Thanks to Fredrik Lundh
for so gently pointing me at this post. Just one
question, if I may:-
Alex Martelli wrote:
> It's not hard...:
>
> try:
> _it = iter(whatever)
> except TypeError:
> print 'non-iterable'
> else:
> for i in _it: # etc, etc
Alas
Roy Smith wrote:
> Now you're assuming that the message is a constant for all TypeErrors
> caused by attempting to iterate over a non-iterable object.
Yes I am, and of course you are correct that that could
change and so shouldn't be relied on.
Seems that my crappy solution is not quite as
fut
Steven D'Aprano wrote:
> What should I do when I can't rely on functions that
> don't exist in older versions of Python?
>
Ideally:
if 'iter' not in dir(__builtins__):
import sys
sys.exit('Archaic Python not supported, please upgrade')
Alternatively fill in the blanks with app
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> Alas and alack, I have to write code which is backwards
> compatible with older versions of Python:
> [...]
> NameError: name 'iter' is not defined
>
> What should I do when I can't rely on functions that
> don't exist in older versions of Python?
I
On Nov 17, Duncan Booth wrote:
> Steven D'Aprano wrote:
> > What should I do when I can't rely on functions that
> > don't exist in older versions of Python?
> sys.exit('Archaic Python not supported, please upgrade')
+1 QOTW.
I recently gave up on trying to support (backport to) pre-2.2 i
Micah Elliott <[EMAIL PROTECTED]> wrote:
> I recently gave up on trying to support (backport to) pre-2.2 in my
> projects. It's been ~3 years since 2.2 released and that seem like a
> pretty reasonable support window.
It depends on what you're doing. If you're developing for in-house
use, you h
Micah Elliott wrote:
> On Nov 17, Duncan Booth wrote:
>
>>Steven D'Aprano wrote:
>>
>>>What should I do when I can't rely on functions that
>>>don't exist in older versions of Python?
>
>
>> sys.exit('Archaic Python not supported, please upgrade')
>
>
> +1 QOTW.
>
> I recently gave up o
Steven D'Aprano wrote:
> Alas and alack, I have to write code which is backwards
> compatible with older versions of Python:
>
> Python 2.1.1 (#1, Aug 25 2001, 04:19:08)
> [GCC 3.0.1] on sunos5
> Type "copyright", "credits" or "license" for more
> information.
> >>> iter
> Traceback (most recent
Fredrik Lundh wrote:
> Steven D'Aprano wrote:
>
>
>>Alas and alack, I have to write code which is backwards
>>compatible with older versions of Python:
[snip]
>>What should I do when I can't rely on functions that
>>don't exist in older versions of Python?
>
>
> python 2.1 doesn't support it
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
...
> In the specific case of iter(), are there good
> alternative ways of detecting an iterable without
> consuming it?
Not a problem I've had often, but when I did, if I recall correctly, I
did something like:
try:
iter
except NameError:
def i
Alex Martelli wrote:
> "Consuming" didn't really come into consideration for the
> backwards compatibility part because only objects indexable with
> integers, 0 and up (and raising IndexError at some point) were usable in
> for statements in old Pythons, there was no "consuming".
Ah yes, of cour
Alex Martelli wrote:
> > In the specific case of iter(), are there good
> > alternative ways of detecting an iterable without
> > consuming it?
>
> Not a problem I've had often, but when I did, if I recall correctly, I
> did something like:
>
> try:
> iter
> except NameError:
> def isiterable(
On Tue, 22 Nov 2005, Steven D'Aprano wrote:
> Are there practical idioms for solving the metaproblem "solve problem X
> using the latest features where available, otherwise fall back on older,
> less powerful features"?
>
> For instance, perhaps I might do this:
>
> try:
>built_in_feature
>
Tom Anderson wrote:
> How about detecting which environment you're in, then running one of two
> entirely different sets of code? Rather than trying to construct modern
> features in the antique environment, write code for each, using the local
> idioms. The trouble with this is that you end up wi
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
> I've said it many times, and I'll say it again: the only fundamentally
> new concept that has been added since Python 1.5.2 is generators.
> [...]
> All the rest is just coloured frosting
In my mind, the biggest thing since 1.5.2 is string methods. T
50 matches
Mail list logo
