Attack a sacred Python Cow

[Russ P.]

It has, at least, long ago bought him a place in my kill-file. Seeing
your side of the conversation, I can only confirm that decision as
correct.

Now there's a classic reply from another comp.lang.python regular. All
he needs is one side of the conversation to know what's going on!

I'd really like to know where both of you guys find the time to spend
here, because unless you type extremely fast, I figure it's about
10-20 hours per week every week. Sorry, but if you also have "quite a
lot of work," I don't believe that leaves much time for a "happy
social life."

Each and every time I get involved in an extended discussion about
Python here, I end up realizing that I've wasted a lot of time trying
to reason with unreasonable people who are infatuated with Python and
incapable of recognizing any deficiencies.

I will thank you for one thing. By taking your best shot at my
suggestion and coming up with nothing significant or relevant, you
have given me confidence to go ahead with a PEP. I may just do it. If
it is rejected, then so be it. Unlike you, they will have to give me a
valid reason to reject it.

 

[Russ P.]

Preprocessor are not a solution. Sorry.

I never said that a pre-processor is a good permanent solution, but
the simple fact that my proposal can be done with a simple pre-
processor means that it does not change the inner workings of the
Python interpreter.

Oh, you don't stand people disagreing with you, that's it ?

I can stand people disagreeing with me all day long, so long as they
are making sense. You are simply making the issue more complicated
that it is because you are apparently incapable of understanding the
substance of it.

Why so ? Because I answer to your proposition and not agree with your
arguments ??? C'mon, be serious, you have the right to post your
proposition here, I have the right to post my reaction to your
proposition, period. Grow up, boy.

Boy, I don't know who you think you're talking to, but you're obviously
out of luck here. I'm 41, married, our son is now a teenager, I have an
happy social life, quite a lot of work, and no time to waste in the
streets. And FWIW, name-calling won't buy you much here.

There you go again. Do you think you are proving something by
addressing me as "boy"? I'll make a little wager with you. I'll bet
that what I am using Python for dwarfs in importance what you are
using it for. Care to put the cards on the table, big man?

I'll tell you something else while I'm at it. I'm ten years older than
you, but I pump iron and stay in excellent shape. If you addressed me
as "boy" in person, I'd be more than happy to teach you a badly needed
lesson you won't soon forget, big man.

 

[alex23]

As I said, I could write a pre-processor myself to
implement it in less than a day.

So WHY DON'T YOU WRITE IT ALREADY?

If you're meeting so much resistance to your idea, why not scratch
your own damn itch and just do it?

Or doesn't that afford you as many chances to insult others while
feeling smugly superior?

 

[Russ P.]

So WHY DON'T YOU WRITE IT ALREADY?

I'm working on something else right now if you don't mind, but I'll
get to it in good time.

Conceptually, the matter is simple. All I need to do is to grab the
first formal argument of each def, then search for occurrences of any
word in the body of the def that starts with a dot, and insert that
first argument in front of it.

I expect the "hard" part will be breaking up the body of the def into
"words." I could just split each line on white space, except for
situations like

x+=.zzz

So I need to account for the fact that operators do not need to be
surrounded by spaces. That's the hardest part I can think of off the
top of my head.

Maybe I'll encounter an insurmountable problem and realize that the
idea can't work in general. If so, then so be it. Certainly, no one on
this thread has anticipated such a problem. Had someone pointed out an
actual technical problem with the idea, I would have gladly thanked
them. But I got a load of irrelevant crap instead, not to mention
being addressed as "boy."

If you're meeting so much resistance to your idea, why not scratch
your own damn itch and just do it?

Or doesn't that afford you as many chances to insult others while
feeling smugly superior?

This coming from a guy who insulted my reading comprehension ability
-- when he was the one who was wrong!

 

[Nikolaus Rath]

Nikolaus Rath a écrit :

Because it would very seriously break a *lot* of code ?

Well, Python 3 will break lots of code anyway, won't it?


Best,

-Nikolaus

--
»It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that.«
-J.H. Hardy

PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C

 

[Carl Banks]

I gave you a piece of code, actual code from one of my own projects. If
you wouldn't accept that evidence then, why would you accept it now?

I would accept as "evidence" something that satisfies my criteria,
which your example did not: it could have easily (and more robustly)
been written with a simple explicit test. I am looking for one that
can't.

You keep bringing up this notion of "more complex with no benefit",
which I'm simply not interested in talking about that at this time,
and I won't respond to any of your points. I am seeking the answer to
one question: whether "if x" can usefully do something a simple
explicit test can't. Everyone already knows that "if x" requires
fewer keystrokes and parses to fewer nodes.


Carl Banks

 

[Heiko Wundram]

Am Dienstag, 29. Juli 2008 10:37:45 schrieb Carl Banks:

You keep bringing up this notion of "more complex with no benefit",
which I'm simply not interested in talking about that at this time,
and I won't respond to any of your points. I am seeking the answer to
one question: whether "if x" can usefully do something a simple
explicit test can't. Everyone already knows that "if x" requires
fewer keystrokes and parses to fewer nodes.

Yes, there are quite a lot of use cases. Think of a polymorphic function,
where the input can be any object that implements the iterator protocol
(concerning base types, I'm thinking of strings, tuples, lists, dicts and
sets here, which are all iterable and yield a chain of singular values) and
you want to check whether the iterable object is empty or not for
special-casing that.

"if x" uses the special interface method __nonzero__() if that's implemented
(which all of the above types implement as returning True iff the container
yields at least one value when iterated over, i.e., it isn't empty), and
falls back to a test for __len__() != 0, otherwise x is considered to be
true.

Now, explicitly comparing x against the five "empty" values of the container
types I specified above would be broken design in such a function: when I
implement a container class myself, which implements the __iter__() and
__nonzero__() methods, I can directly use it with the polymorphic function I
wrote, and the special case for an empty container will work out of the box.
In the case of explicit comparisons, I have to modify the polymorphic
function to accept my container type in addition to those it already
processes to be able to special-case the empty container for my type.

I can't dig up a simple example from code I wrote quickly, but because of the
fact that explicit comparisons always hamper polymorphism (which might not be
needed initially, but you never know what comes up later, thinking of
reusability of components), I personally always stick to the idiom "if x"
rather than comparing it to an empty value, even when I'm sure that the type
of x is a singular type.

Additionally, IMHO "if x" is so much more readable than "if x != <something>".

Just my 2 (euro)cents.

 

[Iain King]

I'm working on something else right now if you don't mind, but I'll
get to it in good time.

Conceptually, the matter is simple. All I need to do is to grab the
first formal argument of each def, then search for occurrences of any
word in the body of the def that starts with a dot, and insert that
first argument in front of it.

I expect the "hard" part will be breaking up the body of the def into
"words." I could just split each line on white space, except for
situations like

x+=.zzz

So I need to account for the fact that operators do not need to be
surrounded by spaces. That's the hardest part I can think of off the
top of my head.

Maybe I'll encounter an insurmountable problem and realize that the
idea can't work in general. If so, then so be it. Certainly, no one on
this thread has anticipated such a problem. Had someone pointed out an
actual technical problem with the idea, I would have gladly thanked
them. But I got a load of irrelevant crap instead, not to mention
being addressed as "boy."



This coming from a guy who insulted my reading comprehension ability
-- when he was the one who was wrong!

Are you actually this stupid? I mean, you were entertaining while you
were mouthing of and insulting your betters, but now you're gonna
complain the second anyone insults you (and I mean, 'boy' - what an
insult!). Never mind that you're never gonna get off your ass to
write a PEP, which would be rejected on language design grounds anyway
(as demonstrated by alex23's link - the one you aren't
comprehending). The most irritating thing is that I like the idea of
being able to use '.x = 10' type notation (and have been for a long
time), but the person arguing for it is an insufferable buffoon who's
too dense to understand a cogent argument, never mind make one. So
great, thanks, the chances of this (or a VB 'with'-like 'using'
keyword) ever making it into the language get smaller every time you
fire up your keyboard. Nice work.

Iain

p.s. am looking forward to your post whining about the invalid reasons
your PEP got rejected, in the slim hope you actually write one.

 

[Steven D'Aprano]

I would accept as "evidence" something that satisfies my criteria, which
your example did not: it could have easily (and more robustly) been
written with a simple explicit test.

Only at the cost of completely ignoring the functional requirements and
changing the API. In other words: you ignore my code, and invent your own
imaginary code that does something completely different, then say that
this imaginary code is better.

And I question your assertion that a "simple explicit test" is more
robust. Where's your evidence for that?

I am looking for one that can't.

If you are writing code that needs to do the right thing with arbitrary
types, then your so-called "simple explicit tests" simply can't work. If
your code isn't expected to deal with arbitrary types, then you've got an
excellent chance that it will work, because you know what types to expect.

Until somebody passes a type that you didn't expect, and your code fails
because it makes assumptions about the object.

If you know that you only get lists, then "if len(x)!=0" is a perfectly
good test (apart from being longer to type, harder to read, and slower to
execute than "if x"). It will work so long as you only get objects where
a length of zero is equivalent to being false. That's a good assumption
to make, but it is an *unnecessary* assumption. Any reasonable object you
get will know if it is false/nothing or true/something, so why make any
assumptions? Just ask the object. It knows.

You keep bringing up this notion of "more complex with no benefit",
which I'm simply not interested in talking about that at this time, and
I won't respond to any of your points.

Of course not.

I am seeking the answer to one
question: whether "if x" can usefully do something a simple explicit
test can't.

"if x" is completely type agnostic. You can pass an object of any type to
it, and it will work. (Excluding objects with buggy methods, naturally.)

Try doing that with one of your so-called "simple explicit tests".

 

[Anders J. Munch]

I'm sorry Anders, that was a needlessly harsh thing for me to say. I
apologize for the unpleasant tone.

Still, __nonzero__ is a fundamental part of Python's behaviour. You
should learn about it.

Hm, first you apologize, then you repeat the insult? That's no basis for a
conversation. Bye from here.

regards, Anders

 

[Heiko Wundram]

Am Dienstag, 29. Juli 2008 11:15:05 schrieb Heiko Wundram:

I can't dig up a simple example from code I wrote quickly...

Just to get back to that: an example I found where "if x" (the generic
__nonzero__() test) will work to test for emptiness/non-emptiness of a
container, whereas "if len(x) > 0" (the "specific" test for this example)
will not, is my for own integer set type I wrote a while back (which you can
find on ASPN).

The corresponding set type allows you to create infinitely sized sets of
integers (which of course are stored as pairs of <start>,<stop>-values, so
the storage itself for the set is bounded), for which len(x) does not have
a "proper" meaning anymore, and __len__() is limited to returning a (platform
dependent) ssize_t anyway IIRC, so even with a bounded set, the length of the
set might not necessarily be accessible using len(x); that's why the set type
additionally got a member function called .len() to work around this
restriction.

I should think is a non-contrieved example where the generic test whether the
object considers itself True/False (which for containers means
non-empty/empty) is preferrable over the special case test whether the length
is positive. A polymorphic function, which for example only accesses the
first ten members of the container is able to work with an infinite set if it
uses the generic test, but is not in case it uses len(x) > 0.

 

[Colin J. Williams]

Am Dienstag, 29. Juli 2008 11:15:05 schrieb Heiko Wundram:

Just to get back to that: an example I found where "if x" (the generic
__nonzero__() test) will work to test for emptiness/non-emptiness of a
container, whereas "if len(x) > 0" (the "specific" test for this example)
will not, is my for own integer set type I wrote a while back (which you can
find on ASPN).

The corresponding set type allows you to create infinitely sized sets of
integers (which of course are stored as pairs of <start>,<stop>-values, so
the storage itself for the set is bounded), for which len(x) does not have
a "proper" meaning anymore, and __len__() is limited to returning a (platform
dependent) ssize_t anyway IIRC, so even with a bounded set, the length of the
set might not necessarily be accessible using len(x); that's why the set type
additionally got a member function called .len() to work around this
restriction.

I should think is a non-contrieved example where the generic test whether the
object considers itself True/False (which for containers means
non-empty/empty) is preferrable over the special case test whether the length
is positive. A polymorphic function, which for example only accesses the
first ten members of the container is able to work with an infinite set if it
uses the generic test, but is not in case it uses len(x) > 0.

(+1) This an Heiko's previous post sets
things out clearly.

Colin W.

 

[Matthew Fitzgibbons]

I would accept as "evidence" something that satisfies my criteria,
which your example did not: it could have easily (and more robustly)
been written with a simple explicit test. I am looking for one that
can't.

You keep bringing up this notion of "more complex with no benefit",
which I'm simply not interested in talking about that at this time,
and I won't respond to any of your points. I am seeking the answer to
one question: whether "if x" can usefully do something a simple
explicit test can't. Everyone already knows that "if x" requires
fewer keystrokes and parses to fewer nodes.


Carl Banks

My use case involves a DAG of filters that pass data (of a variety of
types--filters just pass on data types they don't understand) between
them. I can also drop out of the filter chain at any point, using
critera determined by the filters. These criteria, you guessed it, are
bound to __nonzero__ in the filter and I determine whether or not to
continue through the graph using "if x". You can't code explicit tests
if you don't know what the tests even are beforehand. Also, I wanted to
support builtins (ints and lists in particular) because they can be
meaningful inputs to filters. Finally, as I add more filters and data
types, I don't want to go back and mess with the code that decides
whether or not to break out of the graph.

-Matt

 

[Carl Banks]

If you are writing code that needs to do the right thing with arbitrary
types, then your so-called "simple explicit tests" simply can't work.

I asked for a code example. You say this is true, but neither you nor
anyone else here has provided useful code that demonstrates it.


Carl Banks

 

[Carl Banks]

I can't dig up a simple example from code I wrote quickly, but because of the
fact that explicit comparisons always hamper polymorphism

I'm not going to take your word for it. Do you have code that
demonstrates how "if x" improves polymorphism relative to simple
explicit tests?


Carl Banks

 

[Carl Banks]

My use case involves a DAG of filters that pass data (of a variety of
types--filters just pass on data types they don't understand) between
them. I can also drop out of the filter chain at any point, using
critera determined by the filters. These criteria, you guessed it, are
bound to __nonzero__ in the filter and I determine whether or not to
continue through the graph using "if x". You can't code explicit tests
if you don't know what the tests even are beforehand. Also, I wanted to
support builtins (ints and lists in particular) because they can be
meaningful inputs to filters. Finally, as I add more filters and data
types, I don't want to go back and mess with the code that decides
whether or not to break out of the graph.

Much like in Steven D'Aprano's example, still the only actual code
snippet I've seen, it seems that this can easily be done with a simple
explicit test by having all no-advance filters return None and testing
with "if x is not None". So it doesn't pass my criterion of being not
replaceable with simple explicit test.

Maybe that's not workable for some reason. Perhaps if you'd post a
code example that shows this, rather than just talking about it, you
might be more persuasive.


Carl Banks

 

[Carl Banks]

I'm not going to take your word for it. Do you have code that
demonstrates how "if x" improves polymorphism relative to simple
explicit tests?

And, in case it wasn't obvious, the way to demonstrate that "if x"
improves polymorphism relative to simple explicit tests would be
posting an example where "if x" works but a simple explicit test
doesn't. So don't accuse me of changing the question on you: it's the
same question.

You see, what you are stating and expecting me to take for granted is
exactly what I'm asking for a concrete example of.


Carl Banks

 

[Carl Banks]

Only at the cost of completely ignoring the functional requirements and
changing the API. In other words: you ignore my code, and invent your own
imaginary code that does something completely different, then say that
this imaginary code is better.

And, BTW, you keep making unsubstantiated assertions and keep
expecting me to take them at face value. I'm really not going to take
your word for it that your "functional requirements" would preclude
the possibility of rewriting it as I said to, unless you provide
details.

Also, your third claim is false since it would have exactly the same
behavior.


Carl Banks

 

[Terry Reedy]

Well, Python 3 will break lots of code anyway, won't it?

Each code breaking change was evaluated as a cost against the long-term
net benefits. Many are removals that were announced years ago and which
will not break code written with an eye to the future. An example is
the removal of 'apply', which was replace with '*iterable' years ago.

Some proposed changes, were rejected only because they would break too
much code, or because automatic fixed would not be easy. For these
reasons, the core Python syntax is pretty much untouched. Attribute
lookup is part of core syntax.

 

[Heiko Wundram]

I'm not going to take your word for it. Do you have code that
demonstrates how "if x" improves polymorphism relative to simple
explicit tests?

As I wrote in the second reply email I sent, check out my integer set
recipe on ASPN (and to save you the search:
http://code.activestate.com/recipes/466286/). To test whether the integer
set is empty or not (in a polymorphic function which accepts any kind of
sequence type), the explicit test would be, as you proposed elsewhere:
len(x) > 0. This simply WILL NOT work with some sets of that respective
type, because, as I documented for the __len__() method there: the return
value of __len__() has to (had to?) be in the range 0 <= len < 2**31
(which I think means, as I tested and implemented it on i386, that the
return value has to fit in an ssize_t platform type, but someone with more
knowledge of the interpreter internals might be able to comment here; I'm
not in the mood for checking this out now).

Another reason why the test for __nonzero__() is beneficial, at least
here: testing whether the set is empty or not is easy, because an empty
set has no ranges, and a set with at least one element has at least one
range (i.e., to test whether the set is non-empty, check whether the
_ranges member, a list, is __nonzero__()); taking the len() of a set
always means adding the size of the ranges together (even though this
could of course be precomputed/cached, as the set type is immutable, but
I'm not doing that in that recipe's code).

So, adding things up: the interpretation of __nonzero__(), i.e. the direct
"conversion" to bool, for container-types, implements THE means to test
whether the container is empty or not. Insisting on not using it, because
a "simple explicit" test is supposedly better, will prove to not work in
those cases where the container type might not have a representable length
(because of the constraints on the return value of __len__()), even though
the container has an empty/non-empty state.

I think this does make a very compelling use case for "if x" instead of
"if len(x) > 0".

--- Heiko.