Skip to content
This repository was archived by the owner on Apr 28, 2023. It is now read-only.

Conversation

@lichray
Copy link
Contributor

@lichray lichray commented Apr 11, 2013

No description provided.

@painterjd
Copy link
Owner

I am generally not a fan of moving so many classes into one python file (resources.py). What's the advantage to doing it this way? Sure, all of those things are 'resources' (if you want to look at it like that) but why should they be grouped into a single file?

@lichray
Copy link
Contributor Author

lichray commented Apr 12, 2013

  1. queue.Queue, message.Message, claim.Claim... Eye bleeding.
  2. Module should group things belonging to the same concept.

@painterjd
Copy link
Owner

Why namespace those objects then? Are we to confuse marconiclient.Queue with some other Queue class?

@lichray
Copy link
Contributor Author

lichray commented Apr 16, 2013

On Tue, Apr 16, 2013 at 6:10 PM, Jamie Painter notifications@github.comwrote:

Why namespace those objects then? Are we to confuse marconiclient.Queue
with some other Queue class?

I'm not talking about removing the namespace. The namespace is used to
group
similar things. For example, in the standard library, we have Queue.Queue,
Queue.LifoQueue,
similarly, for the client, we can have resource.Queue, resource.Message.
When talking
about avoiding name clashes, giving multiple classes one namespace is
equivalent functional
to giving each class a namespace. Neither approach brings confusion.

Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.


4BSD -- http://4bsd.biz/

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants