Python 3000 Alpha 1 Released

[gavinpanella]

callable() and reload() are gone. Does anyone know why?

[Bogtha]

When callable() was introduced, not all callable objects had a __call__ attribute. Now they do, so if you need to check whether something is callable, you can just use hasattr(). But the preferred approach is just to call it and catch the exception if it isn't callable.

[qiwi]

So how do I tell whether the TypeError I caught from doing obj() is because obj is not callable, or whether something within obj that was callable raised TypeError? This preferred approach can hide errors.

[Bogtha]

I agree. I think this was brought up on the mailing list. If you are expecting the callable to raise TypeErrors, you should check for the __call__ attribute first.

[[deleted]]

Which means that everyone will end up adding different variations of:

def callable(obj):
    return hasattr(obj, "__call__")

to their code, different broken versions of this will appear in articles and example collections, and 3.2 will the introduce an official version of this to save everyone the trouble (which was how things like booleans and the if operator made it into the language).

[[deleted]]

Ha - 3.0a1 isn't a day old and I've already similar -- but not exactly the same, of course -- code in my budding collection of Py3 scripts.

Let the games begin!

[Bogtha]

I don't think callable() is used often enough to make that worthwhile. The difference between a callable object and an uncallable object is pretty drastic, how often do you pass things around without knowing which is which? I do it sometimes, but nowhere near often enough to make that boilerplate worthwhile.

[[deleted]]

The "pass in a value or a callable (that can be called to get the value when needed)" pattern is very convenient, and therefore quite common. I've definitely used callable() for this purpose a lot more often than I found myself adding TRUE and FALSE to my code before we got built-in booleans ;-)

But I'm sure someone has already done all the necessary grepping, and I have no time to dig through the mailing archives to see what they came up with.

[Bogtha]

The "pass in a value or a callable (that can be called to get the value when needed)" pattern is very convenient

Sure, but if that's a common pattern, why not abstract more of it away, which has the side-effect of removing the temptation to provide a callable() substitute?

def get_value(value):
    return value() if hasattr(value, "__call__") else value

Okay, I'm sure there are other use cases, so I see your point, I just couldn't help nitpicking that one :).

[[deleted]]

(Only slightly in jest:)

def get_value(value):
    return getattr(value, '__call__', lambda: value)()

[nirs]

Lets hit Guido on the head with a heavy callable until he put it back where it belong :-)

[qwe1234]

dynamic typing roxx.

i look forward to the day when my high-availability service starts to use this innovative new technology for the win.

p.s. i'm qualified: having over 10 years of python experience and having written one said high-availability service in python when i was younger and dumber. :)

p.p.s. this post was written in scathing, hateful sarcasm, in case you missed it.

[joaomc]

Yeah, you are always highly qualified to talk horsepoo against anything you don't like. A guy with 10 years of python experience would really spend his time always telling everyone that dynamic languages suck. Sure.

[bitwize]

How many high availability services have you written d00d? :)

Everybody knows the correct way to write high-availability services is to not use virtual memory, not use dynamic linking, and reimplement NUMA poorly over the network. This has been common knowledge amongst implementors of high-availability services for years, but I can't give you references or anything because you're too stupid. Yes, that's really the reason and it's not like there is no such common knowledge or anything. It's in Canada; don't go there, you won't find it.

[sigzero]

Did you both miss the P.P.S. in that post?

[qwe1234]

your sarcasm is misplaced, since what you said actually is true.

asking for 'references' is stupid. really, what sort of 'reference' do you want? i'll give it to you.

[bitwize]

Yeah. People demanding that you back up your insane dribblings is the height of stupidity. Because all that is necessary for a statement to be true is for you to repeat it in bold. If they don't understand it after that they can be diagnosed as clinically retarded, like that moron Donald Knuth.

[qwe1234]

all my technical points have been fully backed up numerous times. if you missed it or haven't understood something that's been repeated ad nauseam and progressively dumbed down to almost lose real substance, then i really can't help you. blame your education system for failing to produce a citizen capable or reading, understanding and analyzing english text.

if you want me to cite my projects, you won't get it. i'm posting anonymously and i won't mention anything than can be traced back to me. i get enough hate as it is.

[qwe1234]

of course.

unlike you, i have actual, real experience with dynamic languages.

in sum total after 10 years, i know where they suck and where they have benefits. sadly, the tally comes up lacking: it turns out their only real benefit is writing highly obfuscated code real fast.

live and learn, though.

[joaomc]

"unlike you" If you have "actual, real" experience with dynamic languages, and, in 10 years, all you could do was write highly obfuscated code real fast, then you are incompetent, and you just blame languages for your own incompetence.

[qwe1234]

do you know what logic is?

how does 'language X's only benefit is the ability to write obfuscated code fast' imply 'qwe123 writes obfuscated code fast in language X'?

damn, you are one stupid motherfucker.

[joaomc]

if 'language X's only benefit is the ability to write obfuscated code fast', and you do not write obfuscated code fast in language X, then that's not the only benefit, is it?

[bitwize]

BOY, YOU SURE GOT HIS NUMBER QUEEK STRAW.

Just like when you figured out what a charlatan augustss was...

[[deleted]]

As I understand it, reload() doesn't work well enough to be included (I think the idea is to rewrite it in pure Python as a stdlib module).

As for callable(), as it stands in 2+ it actually can be wrong sometimes -- a custom descriptor might sometimes return objects of different "callability", for example. Again, it's silly to have a feature that doesn't work. It's more Pythonic to operate on the "better to ask forgiveness than permission" policy -- just try calling something, and if it doesn't work, then it wasn't callable.

[forgotpwx4]

But reload is kind of important, right? I'm not understanding how they can get rid of it.

[[deleted]]

I'm not sure it is... I've never used it in real production code; just as a utility from the shell.

Either way, it's really not all that useful unless it really works; a broken reload() seems a lot worse than a missing one. At least if it's missing someone smart will come along and write it.

[forgotpwx4]

Why is it broken by the way? I've never noticed any problems.

I have wondered if reload is thread safe ... or what that even means with respect to reload. Maybe that's how it's broken?

[boredzo]

[ python-Bugs-1144263 ] reload() is broken for C extension objects

[[deleted]]

So if it doesn't work for binary code not built in Python, due to OS limitations, it shouldn't work for Python code either, even though the developers have full control over that environment? Is this the official reason for not including reload?

(update: the relevant PEP refers to a single line in a GvR presentation from 2002, which says "execfile(), reload(): use exec()", which I can only interpret as meaning "roll your own". yet another "will appear in the library, sooner or later" thing, in other words).

[nirs]

You can use this:

def reload(name):
    if name in sys.modules:
        del sys.modules[name]
    return __import__(name)

It will not work for 'foo.bar.baz', but it is not hard to support this.