Re: pop method question
Hi Jordan, That is true what you say about pop() behavior with stack-like objects. But the definition of pop() for a stack-like structure is stronger than that. A stack is a LIFO data structure. Therefore the pop() operation is defined to not only mutate the receiver and return the item popped but also ensure that the LAST item in the stack is removed. This makes perfect sense for a list type in python since lists are mutable sequences that have a specified order. But for dictionaries this does not hold since they are unordered sequences by definition. So for dictionaries it would not make sense for a programmer to simulate a stack-like type. While we're on the subject I'm also curious as to why the author of the built-in list class called the method append to add an element to the end of a list and not something like push. But this is not really much of a problem if the programmer could create an alias for it. Is it possible to do this in python? I know you can do it in ruby and even override methods and attributes in an existing built-in class like String for instance. --Nick On Mar 3, 2007, at 10:40 PM, MonkeeSage wrote: Nick, In regards to stack-like objects, pop() implies mutation of the reciever and returning the item 'popped' off the stack. The same _semantic_ meaning can be used for pop() regarding dictionaries, even though the _implementation_ would be different: dict.pop(key) mutates the reciever and returns the value associated with the key. Regards, Jordan -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: pop method question
On Mar 4, 2007, at 4:38 AM, Marc 'BlackJack' Rintsch wrote: In [EMAIL PROTECTED], Nicholas Parsons wrote: Just from my computer science background when I see pop(), I think of a stack data structure. Then question your presumptions. There are also many people thinking `list` must be something with nodes and pointers when they see the interface and usage of Python lists. Good point :). But then again, there are other examples of ambiguity in the python language such as allowing operators like '+' to be overloaded. Why not just have a add() method like Java? Why does this remove ambiguity? I even would expect different behaviour from both. I expect the ``+`` operator to return either an immutable or entirely new object, while `add()` can be something on containers that mutates the object. This is true. As long as the language (be it Java, Python, X) itself remains consistent over time, then this should be fine. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Project organization and import
1a) Module/class collision. I like to use the primary class in a file as the name of the file. However this can lead to namespace collisions between the module name and the class name. Also it means that I'm going to be stuck with the odious and wasteful syntax foo.foo everywhere, or forced to use from foo import *. The normal convention is to use a initial uppercase letter when defining a class and using all lowercase letters for naming a file/ module. For example you might have a file called foo.py with the following: class Foo: pass Now no namespace collision will result when you import the foo file/ module. 1b) The Pythonic way seems to be to put more stuff in one file, but I believe this is categorically the wrong thing to do in large projects. The moment you have more than one developer along with a revision control system, you're going to want files to contain the smallest practical functional blocks. I feel pretty confident saying that put more stuff in one file is the wrong answer, even if it is the Pythonic answer. Each file is considered a module in python. You usually don't want to throw everything into one module, especially for big projects. Breaking your code down into meaningful modules that can be reused in other modules. There is no general rule to follow here as far as length of a file/module is concerned. Use your judgment here.-- http://mail.python.org/mailman/listinfo/python-list
pop method question
Howdy Folks,
I was just playing around in IDLE at the interactive prompt and typed
in dir({}) for the fun of it. I was quite surprised to see a pop
method defined there. I mean is that a misnomer or what? From the
literature, pop is supposed to be an operation defined for a stack
data structure. A stack is defined to be an ordered list data
structure. Dictionaries in Python have no order but are sequences.
Now, does anyone know why the python core has this pop method
implemented for a dictionary type?
I realize that in this context it is used for removing a specific key
from the current dictionary object. But why call it pop and not
something more intuitive like remove or delete?
Thanks for the clarification in advance :).
--Nick
--
http://mail.python.org/mailman/listinfo/python-list
Re: pop method question
On Mar 3, 2007, at 3:49 PM, Paul Rubin wrote:
Nicholas Parsons [EMAIL PROTECTED] writes:
I was just playing around in IDLE at the interactive prompt and typed
in dir({}) for the fun of it. I was quite surprised to see a pop
method defined there. I mean is that a misnomer or what? From the
literature, pop is supposed to be an operation defined for a stack
data structure. A stack is defined to be an ordered list data
structure. Dictionaries in Python have no order but are sequences.
Now, does anyone know why the python core has this pop method
implemented for a dictionary type?
Try typing:
help({}.pop)
--
http://mail.python.org/mailman/listinfo/python-list
Thanks, that gives a more details explanation of what the behavior is
but doesn't answer my question above :(
--
http://mail.python.org/mailman/listinfo/python-list
Re: pop method question
Hi Raymond, Thank you for your clarification below. I was just using remove and delete as possible alternatives to the name pop without much contemplation. Like you say below, it begs the question as to why not have two separate operations for dictionaries (retrieval of value from key followed by deletion of key) instead of one method. I'm not sure I agree with you said about the pedantic usage of pop. I would rather have a term mean one thing instead of several causing ambiguity. Just from my computer science background when I see pop (), I think of a stack data structure. Why muddle the waters by introducing another meaning for the term? There are plenty of other words to use that could describe the behavior exhibited by the dictionary operation of removing a key and returning its value. The notion of a stack and pop() and push() methods for it are very important from a historical perspective and is not just some fad. But then again, there are other examples of ambiguity in the python language such as allowing operators like '+' to be overloaded. Why not just have a add() method like Java? Of course Java does cheat a little by overloading the '+' operator for string objects but that is a built-in feature of language. Also some people find '+' more appealing to the eye than a method call like add() in their code. Even in the case of C, we have some ambiguity with the dangling if statement. So I guess you can't win for trying :). Just call me a purist and think of me as someone who likes consistency. Python is here to stay and no language is perfect... --Nick On Mar 3, 2007, at 7:32 PM, Raymond Hettinger wrote: [Nicholas Parsons] Dictionaries in Python have no order but are sequences. Now, does anyone know why the python core has this pop method implemented for a dictionary type? I realize that in this context it is used for removing a specific key from the current dictionary object. But why call it pop and not something more intuitive like remove or delete? The naming for pop() method followed from the naming of the previously existing popitem() method. Neither remove nor delete would have been a good name for a method that looked-up and returned a value as well as mutating the dictionary. The word pop on the other hand strongly suggests both retrieval and mutation. The notion that pop is only defined for stack operations is somewhat pedantic. We have also successfully used the name for sets, dicts, and deques (success meaning that most people just get it and are able to learn, use, read the name without difficultly). The rationale for the pop() method was that the pattern v=d[k]; del d[k] could be collapsed to a single call, eliminating a two successive look-ups of the same key. Looking back, this rationale is questionable because 1) the second lookup is not expensive because the first lookup put the relevant hash entries in the cache, and 2) the lookup/delete pattern for dictionaries does not seem to arise often in practice (it does come-up every now and then in the context of set operations). There was also a notion that threaded programming would benefit by having lookup-then-delete as an atomic transaction. It is unknown to me whether that purported benefit has ever been realized. Raymond Hettinger -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: classes and functions
Hi Claire, That is the beauty of using Python. You have a choice of using classes and traditional OOP techniques or sticking to top level functions. For short, small scripts it would probably be overkill to use classes. Yet the programmer still has classes in his tool chest if he/she is writing code that is going to be reused in larger projects. In contrast, languages like Java force you into doing everything with classes. Another good resource to read is Learning Python by Mark Lutz and David Ascher if you want to learn more about python. Hope this helps... --Nick On Mar 2, 2007, at 5:26 PM, Silver Rock wrote: Friends, I don´t see why using classes.. functions does everything already. I read the Rossum tutotial and two other already. Maybe this is because I am only writing small scripts, or some more serious misunderstandings of the language. Please give me a light. thanks guys, Claire -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Newbie Test
Greetings, This is just a test to see if I can post to this mailing list. Can someone from the list please respond to this email so I know it worked? Thanks in advance! --Nick -- http://mail.python.org/mailman/listinfo/python-list
