🌐 Mailman 3 November 2013 - Python-list - python.org

Re: ctypes for AIX
by Anssi Saari July 29, 2015

July 29, 2015

"Waddle, Jim" <jim.waddle(a)boeing.com> writes: > I do not have sufficient knowledge to know how to fix this. I would think that this error somehow is related to compiling on aix. If you have any suggestions on how to correct this problem , I would appreciate it I'd have to guess your main problem is not using gcc to compile. From a quick look, that's what the guys at the pware site did.

2 1

Re: Language design
by Steven D'Aprano June 2, 2015

June 2, 2015

On Thu, 12 Sep 2013 20:23:21 -0700, Mark Janssen wrote: >>> Really? Are you saying you (and the community at-large) always derive >>> from Object as your base class? >> >> Not directly, that would be silly. > > Silly? "Explicit is better than implicit"... right? If I'm inheriting from str, I inherit from str explicitly: class MyStr(str): ... and then str in turn inherits from object explicitly. I certainly do not inherit from object and then re-implement all the string methods from scratch: class MyStr(object): def __new__(cls, value): ... def upper(self): ... def lower(self): ... # and so on... That would be ridiculous, and goes against the very idea of inheritance. But nor do I feel the need to explicitly list the entire superclass hierarchy: class MyStr(str, object): ... which would be silly. Only somebody who doesn't understand how inheritance works in Python would do that. There's simply no need for it, and in fact it would be actively harmful for larger hierarchies. >>> But wait is it the "base" (at the bottom of the hierarchy) or is it >>> the "parent" at the top? You see, you, like everyone else has been >>> using these terms loosely, confusing yourself. >> >> Depends on whether I'm standing on my head or not. >> >> Or more importantly, it depends on whether I visualise my hierarchy >> going top->down or bottom->up. Both are relevant, and both end up with >> the *exact same hierarchy* with only the direction reversed. > > Ha, "only the direction reversed". That little directionality that > you're passing by so blithely is the difference between whether you're > talking about galaxies or atoms. It makes no difference whether I write: atoms -> stars -> galaxies or galaxies <- stars <- atoms nor does it make any difference if I write the chain starting at the top and pointing down, or at the bottom and pointing up. Your objection implies that writing family trees with the most distant ancestor (the root of the tree) at the top of the page somehow confuses people into thinking that perhaps they are the progenitor of people who lived generations earlier. That's absurd -- people simply are not as stupid as you think. > The simplicity of Python has seduced you into making an "equivocation" > of sorts. It's subtle and no one in the field has noticed it. It crept > in slowly and imperceptively. Ah, and now we come to the heart of the matter -- people have been drawing tree-structures with the root at the top of the page for centuries, and Mark Janssen is the first person to have realised that they've got it all backwards. >>> By inheriting from sets you get a lot of useful functionality for >>> free. That you don't know how you could use that functionality is a >>> failure of your imagination, not of the general idea. >> >> No you don't. You get a bunch of ill-defined methods that don't make >> sense on dicts. > > They are not necessarily ill-defined. Keep in mind Python already chose > (way back in 1.x) to arbitrary overwrite the values in a key collision. > So this problem isn't new. You've simply adapted to this limitation > without knowing what you were missing. No, Python didn't "arbitrarily" choose this behaviour. It is standard, normal behaviour for a key-value mapping, and it is the standard behaviour because it is the only behaviour that makes sense for a general purpose mapping. Python did not invent dicts (although it may have invented the choice of name "dict"). If you think of inheritance in the Liskov Substitution sense, then you might *consider* building dicts on top of sets. But it doesn't really work, because there is no way to sensibly keep set-behaviour for dicts. For example, take intersection of two sets s and t. It is a basic principle of set intersection that s&t == t&s. But now, take two dicts with the same keys but different values, d and e. What values should be used when calculating d&e compared to e&d? Since they are different values, we can either: * prefer the values from the left argument over that from the right; * prefer the values from the right argument over that from the left; * refuse to choose and raise an exception; * consider the intersection empty The first three choices will break the Liskov Substitution Principle, since now dicts *cannot* be substituted for sets. The fourth also breaks Liskov, but for a different reason: # sets (key in s) and (key in t) implies (key in s&t); but # dicts (key in d) and (key in e) *does not* imply (key in d&e) So whatever you do, you are screwed Liskov-wise. You cannot derive dicts from sets and still keep the Liskov Substitution Principle. Of course, LSP is not the only way to design your inheritance hierarchies. An alternative is to design them in terms of delegating implementation to the superclass. As Raymond Hettinger puts it, your classes tells it's parent to do some of the work. But in this case, you're still screwed: you can derive sets from dicts, and in fact the first implementation of sets in Python did exactly that, but you cannot derive dicts from sets. So either way, whether you are an OOP purist who designs your classes with type-theoretic purity and the Liskov Substitution Principle in mind, or a pragmatist who designs your classes with delegation of implementation in mind, you can't sensibly derive dicts from sets. >>>>> 3) It used the set literal for dict, so that there's no obvious way >>>>> to do it. This didn't get changed in Py3k. >>>> >>>> No, it uses the dict literal for dicts. >>> >>> Right. The dict literal should be {:} -- the one obvious way to do >>> it. >> >> I don't agree it is obvious. It is as obvious as (,) being the empty >> tuple or [,] being the empty list. > > You're just being argumentative. If there are sets as built-ins, then > {:} is the obvious dict literal, because {} is the obvious one for set. > You don't need [,] to be the list literal because there is no simpler > list-type. The point is that the obvious way to write an empty collection is using a pair of delimiters, not to shove an arbitrary separator separating nothing at all in there: [] is an empty list, not [,] () is an empty tuple, not (,) {} is an empty (dict|set), not {,} or {:} We can't have {} be both an empty set and an empty dict, so one of the two has to miss out. Neither is more obvious than the other. dicts are more important data structures, and they have historical precedence, so they win. If Python was being re-invented from scratch now, or if sets had been around just as long as dicts, people might have chosen to given sets higher priority than dicts, but frankly I doubt it. It's much more common to want an empty dict than an empty set, at least in my experience. >>>> And the obvious way to form an empty set is by calling set(), the >>>> same as str(), int(), list(), float(), tuple(), dict(), ... >>> >>> Blah, blah. Let me know when you got everyone migrated over to >>> Python.v3. >> >> What does this have to do with Python 3? It works fine in Python 2. > > I mean, you're suggestions are coming from a "believer", not someone > wanting to understand the limitations of python or whether v3 has > succeeded at achieving its potential. "not someone wanting to understand the limitations of python..." -- are you aware that I started this thread? -- Steven

5 6

Re: Language design
by Steven D'Aprano June 2, 2015

June 2, 2015

On Wed, 11 Sep 2013 14:30:54 -0700, Mark Janssen wrote: > 1) It tried to make Object the parent of every class. Tried, and succeeded. > No one's close enough to God to make that work. Non-sequitor. One doesn't need to be close to a deity to have a single root of the object hierarchy. > 2) It didn't make dicts inherit from sets when they were added to > Python. Why would you want dicts to inherit from sets? > 3) It used the set literal for dict, so that there's no obvious > way to do it. This didn't get changed in Py3k. No, it uses the dict literal for dicts. And the obvious way to form an empty set is by calling set(), the same as str(), int(), list(), float(), tuple(), dict(), ... > 4?) It allowed > [reference] variables to be used as dict keys. This creates a parsing > difficulty for me, mentally. Keys should be direct, hashable values, > not hidden in a variable name. I don't even understand what you are talking about here. "[reference] variables"? What does that mean? Dict keys are direct, hashable values, and I have no idea what you mean by "hidden in a variable name". -- Steven

5 5

Re: Message passing syntax for objects | OOPv2
by Steven D'Aprano June 2, 2015

June 2, 2015

On Wed, 08 May 2013 19:35:58 -0700, Mark Janssen wrote: > Long story short: the lambda > calculus folks have to split from the Turing machine folks. > These models of computation should not use the same language. Their > computation models are too radically different. Their computation models are exactly equivalent. This is like saying that Cartesian coordinates and polar coordinates are so radically different that they cannot possibly both describe the same space. -- Steven

4 3

My attempts in playing with tail-recursion in python
by Thomas Baruchel May 18, 2015

May 18, 2015

Hi, I would like to share some of my recent attempts concerning recursivity in python, more precisely recursivity with lambda functions. I know that the title of my thread with the "tail-recursion" words may wake up some long and old war; please don't take it as such. I am not claiming anything about what programming languages should be or not; I enjoy using python for many purposes and I perfectly know how to handle loops for achieving some tasks, but sometimes I like rather think with recursivity because I have been using various dialects of Lisp for a long time. I had a very great time studying the Y-combinator; then I wrote various pieces of code for remapping recursive calls to loop iterations. The following functions are fully usable; I hope someone will enjoy using them. If you are not interested by the explanations, just jump to the end of the message and take my functions for using them. Here is a recursive function: fac = lambda f: lambda n: 1 if n==0 else n*f(n-1) The Y-combinator is well known: Y = lambda f: (lambda x: x(x))(lambda y: f(lambda *args: y(y)(*args))) Now, you can use the recursive function: rf = Y(fac) rf(5) Now we write fac as a tail-recursive function: fac = lambda f: lambda a,b: b if a==0 else f(a-1,a*b) rf = Y(fac) rf(5,1) but of course, the recursivity is handled like previously. In fact, it is very easy to build some effcient wrapper; for instance: (lambda f: f(lambda *args: ("callback",args))) will act in the following way: (lambda f: f(lambda *args: ("callback",args)))(fac)(5,1) --> ('callback', (4, 5)) (lambda f: f(lambda *args: ("callback",args)))(fac)(4,5) --> ('callback', (3, 20)) (lambda f: f(lambda *args: ("callback",args)))(fac)(3,20)) --> ('callback', (2, 60)) (lambda f: f(lambda *args: ("callback",args)))(fac)(2,60) --> ('callback', (1, 120)) (lambda f: f(lambda *args: ("callback",args)))(fac)(1,120) --> ('callback', (0, 120)) (lambda f: f(lambda *args: ("callback",args)))(fac)(0,120) --> 120 Here, the "callback" string is arbitrary chosen in order to make the loop know that a next call is needed. Now, the recursivity is handled as successive calls, which is what I was looking for. A first proposal could be: def with_tail_recursion(func): x = (lambda f: f(lambda *args: ("callback",args)))(func) def wrapper(*args): out = ("callback",args) while type(out)==tuple and out[0]=="callback": out = x(*out[1]) return out return wrapper Now, the very same function can be used as recursive or inside a loop: fac = lambda f: lambda a,b: b if a==0 else f(a-1,a*b) rf = Y(fac) tr = with_tail_recursion(fac) rf(5,1) --> 120 tr(5,1) --> 120 Of course, if most of your job relies on writing functions returning tuples with the string "callback" being the first argument, you should use another keyword in the previous code ;-) You can inspect the stack by raising an exception: f2 = lambda f: lambda n: 1/n if n==0 else f(n-1) and see the differences between Y(f2)(5) and with_tail_recursion(f2)(5) But I was not fully happy with the use of a tuple, efficient but a little too tricky to my eyes. For that reason, I took the Y combinator again and slightly modified it: lambda f: (lambda x: x(x))(lambda y: f(lambda *args: lambda: y(y)(*args))) Now, the function doesn't call itself, but returns a function calling itself with the relevant arguments. I like this new function better than the previous one, but it is now more difficult for the wrapper to detect when it is time to leave the loop. Right now, I use the following test: checking for the __call__ string in the dir() list. This means ONE IMPORTANT THING: this second wrapper can't handle tail-recursive functions returning functions, (which is actually more likely to happen than tail-recursive functions returning tuples with the string "callback" being the first argument ;-) ). But I like it that way: def B(func): x = (lambda f: (lambda x: x(x))(lambda y: f(lambda *args: lambda: y(y)(*args))))(func) def wrapper(*args): out = x(*args) while '__call__' in dir(out): out = out() return out return wrapper tr2 = B(fac) tr2(5,1) --> 120 Now, you can write functions with a huge depth of recusivity with no problem : B(lambda f: lambda n: "ok" if n==0 else f(n-1))(5000) (don't try with the Y combinator instead...) Best regards, -- Thomas Baruchel

2 2

Confessions of a Python fanboy
by r May 11, 2015

May 11, 2015

Hello fellow Pythonista's it's nice to be back after such a long hiatus. I have recently realized my blind love affair with Python was just that. I must admit there are better ways to program. Like your first lay, your first programing language can leave an indelible mark on you, but like all young chaps, the passion for programming has sweep me away into vast new orgies of programming bliss. (ig ,little head guides the big one.) My adventures in Ruby. an autobyography by rt8396 After breaking free from the wild love affair i had with Python, a new day had dawned. I dried my eyes and soon discovered the Ruby language (not by choice however) --now don't worry fellow Pythonistas, i am still on your side (mostly) -- but i now realize Ruby has some good things going for it. For instance... 1.) No need to use "()" to call a function with no arguments. Python --> "obj.m2().m3()" --ugly Ruby --> "obj.m1.m2.m3" -- sweeet! Man, i must admit i really like this, and your code will look so much cleaner. 2.) the .each method container.each{|localVar| block} This method can really cleanup some ugly for loops, although i really like the readability of for loops. 3.) true OOP Now before you go and get all "huffy" over this statement, hear me out. Python is the best language in the world. But it damn sure has some warts! "len(this)" instead of "obj.length" max(that) instead of [1,2,3,4,5].max(). You know what i am talking about here people. We all get complacent and It seems easier to just cope with these problems instead of fighting for change. But look at the French, WHAT THE HELL HAS THAT DONE FOR THEM, *NOTHING*!!!! As for the rest of Ruby, i am not impressed. The redundant usage of "end" over indention perplexes me. The Perlish feel of "require" and the horrifically cryptic idioms of Ruby regular expressions. The "puts" and "gets" seem childish and the math class does not even have a degrees or radians function! Anyway, i thought i would get this off my chest and catch up with old friends in the meantime. We can all make Python the perfect language it needs to be, but it ain't gonna be easy! Thank you all PS stay tuned for more from this series....

20 34

Custom alphabetical sort
by Pander Musubi May 3, 2015

May 3, 2015

Hi all, I would like to sort according to this order: (' ', '.', '\'', '-', '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'a', 'A', 'ä', 'Ä', 'á', 'Á', 'â', 'Â', 'à', 'À', 'å', 'Å', 'b', 'B', 'c', 'C', 'ç', 'Ç', 'd', 'D', 'e', 'E', 'ë', 'Ë', 'é', 'É', 'ê', 'Ê', 'è', 'È', 'f', 'F', 'g', 'G', 'h', 'H', 'i', 'I', 'ï', 'Ï', 'í', 'Í', 'î', 'Î', 'ì', 'Ì', 'j', 'J', 'k', 'K', 'l', 'L', 'm', 'M', 'n', 'ñ', 'N', 'Ñ', 'o', 'O', 'ö', 'Ö', 'ó', 'Ó', 'ô', 'Ô', 'ò', 'Ò', 'ø', 'Ø', 'p', 'P', 'q', 'Q', 'r', 'R', 's', 'S', 't', 'T', 'u', 'U', 'ü', 'Ü', 'ú', 'Ú', 'û', 'Û', 'ù', 'Ù', 'v', 'V', 'w', 'W', 'x', 'X', 'y', 'Y', 'z', 'Z') How can I do this? The default sorted() does not give the desired result. Thanks, Pander

7 7

How to receive a data file of unknown length using a python socket?
by twgray April 22, 2015

April 22, 2015

I am attempting to send a jpeg image file created on an embedded device over a wifi socket to a Python client running on a Linux pc (Ubuntu). All works well, except I don't know, on the pc client side, what the file size is? The following is a snippet: [code] f = open("frame.jpg",mode = 'wb') while True: data = self.s.recv(MAXPACKETLEN) if len(data) == 0: break recvd += len(data) f.write(data) f.close() [end] It appears to be locking up in 'data=self.s.recv(MAXPACKETLEN)' on the final packet, which will always be less than MAXPACKETLEN. I guess my question is, how do I detect end of data on the client side?

11 14

Python newbie here! No module named settings
by Neeraj Agarwal April 13, 2015

April 13, 2015

Hello all, I'm a newbie to Python and its my 2nd day exploring it. I was trying to use Python wrapper for Google Charts API and was tweaking the examples. https://github.com/gak/pygooglechart/raw/master/examples/pie.py This is the script which I was trying. And the python interpreter gives the following error: import settings ImportError: No module named settings I installed Django as well before this (if its causing the problem, dunno) Please help me. Thanks, Neeraj

5 5

Python to C++ in a pickle
by Larry Whitley April 2, 2015

April 2, 2015

I'd like to pickle an object in python and unpickle it in C++. The object in question is a python dictionary so it will have to go into a C++ map. Has someone done this and is willing to share? Or, is the cPickle source available on the web somewhere? Larry

4 3