pubsub.Topic.create() returns None?

[jgeewax]

I'd really like to write

topic = pubsub.Topic('topic').create()

Looks like from the code we have today, that we don't return anything, so this won't work (topic will be None right here).

[dhermes]

We've spoken a bit about this. That is un-Pythonic.

For example, see from the standard library.

>>> a = [1, -1, 10, 6]
>>> b = a.sort()
>>> b is None
True
>>> a
[-1, 1, 6, 10]

[jgeewax]

Being able to chain things nicely is un-Pythonic? Do we have more references to why this is a bad idea? Can you point me to that discussion?

It looks like Boto does this... See:

• http://boto.readthedocs.org/en/latest/ref/sqs.html#boto.sqs.connection.SQSConnection.create_queue
• https://github.com/boto/boto/blob/develop/boto/sqs/connection.py#L68

[dhermes]

Having been inside, boto is not a very Pythonic library. Method chaining is a JavaScript idiom, not Python.

[jgeewax]

That doesn't really answer things for me ... :(

I think the bigger issue is that I don't see a use for a Topic object that isn't 'created'. that is, what can I do with topic = pubsub.Topic('name') besides create it?

Would this method be better as a factory?

topic = pubsub.Topic.create('topic-name')

or

topic = pubsub.create_topic('topic-name')

?

[dhermes]

1. Yeah I was going to point out pubsub.create_topic('topic-name')
2. I'll let @tseaver speak on the design, but for us, the point of a method like topic.create() is to make it clear to the user when they are making an HTTP request and when they are just updating a local property of a Topic object.

So they have the option of "functional" approach pubsub.create_topic('topic-name') or OO approach topic.create()

[jgeewax]

Yeah I was going to point out pubsub.create_topic('topic-name')

Does that exist? I don't see it...

the point of a method like topic.create() is to make it clear to the user when they are making an HTTP request and when they are just updating a local property of a Topic object.

Totally agree - I don't want to hide that a request is being made.

Wouldn't the two options go against the whole "one way to do things" idea?

[dhermes]

Indeed they would violate the Zen of Python "There should be one-- and preferably only one --obvious way to do it.". @tseaver has mentioned abolishing functions of the form

top_level_package.verb_thing(args)

in favor of

thing = top_level_package.Thing(...)
thing.verb(args)

[jgeewax]

What's the reason for that ?

If we're going to go that way, I'd like to re-open the topic of enforcing all our methods to be chainable. I'd rather go the package.verb_thing(args) though....

[dhermes]

Closing this as #911 due to lost steam