Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #70694
| From | Andrew Konstantaras <akonsta@icloud.com> |
|---|---|
| Subject | Re: Help with changes in traceback stack from Python 2.7 to Python 3.x |
| Date | 2014-04-28 19:50 +0000 |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.9559.1398718221.18130.python-list@python.org> (permalink) |
[Multipart message — attachments visible in raw view] - view raw
On Apr 28, 2014, at 12:36 PM, Ned Batchelder <ned@nedbatchelder.com> wrote: > On 4/27/14 5:51 PM, Andrew Konstantaras wrote: > > I guess I am missing something big as I am looking for a shorthand way > > of doing the following: > > > > dctA = dict(x=x, y=y, ... n=n) > > > > Yes, your makeDict(x, y) is a shorthand for dict(x=x, y=y), but there > are many things you can do with dict that you can't do with makeDict. > What is the makeDict equivalent of: > > dict(x=12, y=self.y, z=a+b) > > The code you have allows you more compact expression, but it brings > fragility and surprise. > > > This is, as I understand it a very natural way of using a dictionary. > > It seems that this syntax is unnecessarily redundant and hence my goal > > of writing something more compact. Perhaps the way I am doing it is a > > little unorthodox, but the ultimate use of a dictionary is, as I > > understand it, completely in line with how dictionaries were designed to > > be used. In my other code, I often use these dictionaries to pass > > arguments to functions and return results. It allows me great > > flexibility without breaking existing code. I pack a dictionary before > > passing and unpack when retrieving. > > Perhaps you want to create a class instead? If you find yourself > passing more than a handful of arguments to a function, and especially > more than a handful of values returned from a function, then a class > with methods might be a better way to combine state and behavior. > > Also, keep in mind that you can return a tuple from a function if you > want to return two or three values and assign them to names: > > x, y, z = compute_xyz() > > You mention unpacking your dictionary after the function call. How do > you do that? Isn't that a cumbersome and repetitive operation? One of the reasons I like using the dictionary over the tuple is that if I have a function that grows in functionality (i.e., I decide to return more data for new scenarios), I can just add the new object to the dictionary and I don't have to worry about changing the code every where else that used to call the function. Actually, that is one of the nice features of using a dictionary, I can check if the key is there and if it is pull it out. As I was dusting off this old code, I considered trying to implement this functionality through by creating a class. I never liked going through the stack, it seemed hacky, but I came to love using dictionaries as they have some great built in features. Again, thanks for the advice and I will focus on the class implementation. > > > > > I will give the locals approach a try, it seems a little more clumsy > > than simply passing the variables to the function. > > > > Thanks again for your input. > > > > ---Andrew > > BTW, it's a little easier to follow the threads of conversation if you > put your responses after the text you are responding to. This is known > as bottom-posting, and is preferred to top-posting as you did here. > > > -- > Ned Batchelder, http://nedbatchelder.com > > -- > https://mail.python.org/mailman/listinfo/python-list
Back to comp.lang.python | Previous | Next | Find similar | Unroll thread
Re: Help with changes in traceback stack from Python 2.7 to Python 3.x Andrew Konstantaras <akonsta@icloud.com> - 2014-04-28 19:50 +0000
csiph-web