Mailman 3 April 2013 - Python-ideas

Biggest Fake Conference in Computer Science
by eliswilson＠hushmail.com April 30, 2013

April 30, 2013

Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP http://sites.google.com/site/worlddump1 organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia richer. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. This fake paper is different from the two fake papers already published (see https://sites.google.com/site/worlddump4 for details) in WORLDCOMP. We MUST say that you should look at the above website if you have any thoughts of participating in WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and threatens the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Prof. Hamid Arabnia makes a lot of tricks. For example, he appeared in a newspaper to fool the public, claiming him a victim of cyber-attack (see Item 8 in Section 5 of above website). Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! We ask Prof. Hamid Arabnia to publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also ask him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 and respond if he has any professional values. Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities at http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links.

1 0

Re: [Python-ideas] CPython's cyclic garbage collector (was Automatic context managers)
by MRAB April 29, 2013

April 29, 2013

On 27/04/2013 02:56, Chris Angelico wrote: > On Sat, Apr 27, 2013 at 9:45 AM, Dave Angel <davea(a)davea.name> wrote: >> I didn't know there was a callback that a user could hook into. That's very >> interesting. >> > > On Sat, Apr 27, 2013 at 10:22 AM, Skip Montanaro <skip(a)pobox.com> wrote: >>> Whenever the GC finds a cycle that is unreferenced but uncollectable, >>> it stores those objects in the list gc.garbage. At that point, if the >>> user wishes to clean up those cycles, it is up to them to delve into >>> gc.garbage, untangle the objects contained within, break the cycles, >>> and remove them from the list so that they can be freed by the ref >>> counter. >> >> I wonder if it would be useful to provide a gc.garbagehook analogous >> to sys.excepthook? >> Users could assign a function of their choice to much the cyclic >> garbage periodically. >> >> Just a thought, flying out of my fingers before my brain could stop it... > > As far as I know, Dave, there isn't currently one; Skip, that's close > to what I'm talking about - it saves on the periodic check. But > burying it in gc.garbagehook implies having a separate piece of code > that knows how to break the reference cycles, whereas the __del__ > method puts the code right there in the code that has the problem. > Actually, *ANY* solution to this problem implies having __del__ able > to cope with the cycle being broken. Here's an example, perhaps a > silly one, but not far different in nature from some things I've done > in C++. (Granted, all the Python implementations of those same > algorithms have involved built-in types rather than linked lists, but > still.) > > class DLCircList: > def __init__(self,payload): > self.payload=payload > self.next=self.prev=self > print("Creating node: %s"%self.payload) > def __del__(self): > print("Deleting node %s from cycle %s"%(self.payload,self.enum())) > self.prev.next=self.next > self.next.prev=self.prev > def attach(self,other): > assert(self.next==self) # Don't attach twice > self.prev=other > self.next=other.next > other.next=self > self.next.prev=self > print("Adding node %s to cycle %s"%(self.payload,self.enum())) > def enum(self): > """Return a list of all node payloads in this cycle.""" > ptr=self.next > nodes=[self.payload] > while ptr!=self: > nodes.append(ptr.payload) > ptr=ptr.next > return nodes > > lst=DLCircList("foo") > DLCircList("bar").attach(lst) > DLCircList("quux").attach(lst) > DLCircList("asdf").attach(lst) > DLCircList("qwer").attach(lst) > DLCircList("zxcv").attach(lst) > print("Enumerating list: %s"%lst.enum()) > > del lst > import gc > gbg=gc.collect() > print("And we have garbage: %s"%gbg) > print(gc.garbage) > > > > Supposing you did this many many times, and you wanted decent garbage > collection. How would you write a __del__ method, how would you write > something to clean up gc.garbage? One way or another, something will > have to deal with the possibility that the invariants have been > broken, so my theory is that that possibility should be entirely > within __del__. (Since __del__ calls enum(), it's possible for enum() > to throw DestructedObject or whatever, but standard exception handling > will deal with that.) > How about this: If an object has a __collect__ method, then that method will be called whenever the object is collected, either because its reference count has reached 0 (or maybe this should be done explicitly), or because it has been detected by the GC as being part of a cycle. If the method is called (and doesn't raise an exception?), then the object is not added to the garbage list. The principal purpose of method is to give the object the chance to break any cycles. It should be noted that the method could be called more than once. Here is a modified version of the code: class DLCircList: def __init__(self,payload): self._collected = False self.payload = payload self.next = self.prev = self print("Creating node: %s" % self.payload) def __del__(self): self.__collect__() # Implicit or explicit? print("Deleting node %s" % self.payload) def attach(self,other): assert self.next == self # Don't attach twice self.prev = other self.next = other.next other.next = self self.next.prev = self print("Adding node %s to cycle %s" % (self.payload, self.enum())) def enum(self): """Return a list of all node payloads in this cycle.""" ptr = self.next nodes = [self.payload] while ptr != self: nodes.append(ptr.payload) ptr = ptr.next return nodes def __collect__(self): print("Collecting node % s" % self.payload) if self.prev is None: # Already broken the cycle. print("Already collected %s" % self.payload) return self.prev.next = self.next self.next.prev = self.prev # Break the cycle. self.prev = self.next = None def callback(phase, info): if phase == "stop": new_garbage = [] for obj in gc.garbage: if hasattr(obj, "__collect__"): obj.__collect__() else: new_garbage.append(obj) gc.garbage[:] = new_garbage import gc gc.callbacks.append(callback) lst = DLCircList("foo") DLCircList("bar").attach(lst) DLCircList("quux").attach(lst) DLCircList("asdf").attach(lst) DLCircList("qwer").attach(lst) DLCircList("zxcv").attach(lst) print("Enumerating list: % s" % lst.enum()) del lst print("And we have garbage #1: % s" % gc.collect()) print("And we have garbage #2: % s" % gc.collect())

2 2

hexdump
by anatoly techtonik April 29, 2013

April 29, 2013

Just an idea of usability fix for Python 3. hexdump module (function or bytes method is better) as simple, easy and intuitive way for dumping binary data when writing programs in Python. hexdump(bytes) - produce human readable dump of binary data, byte-by-byte representation, separated by space, 16-byte rows Rationale: 1. Debug. Generic binary data can't be output to console. A separate helper is needed to print, log or store its value in human readable format in database. This takes time. 2. Usability. binascii is ugly: name is not intuitive any more, there are a lot of functions, and it is not clear how it relates to unicode. 3. Serialization. It is convenient to have format that can be displayed in a text editor. Simple tools encourage people to use them. Practical example: >>> print(b) � � � �� >>> b '\xe6\xb0\x08\x04\xe7\x9e\x08\x04\xe7\xbc\x08\x04\xe7\xd5\x08\x04\xe7\xe4\x08\x04\xe6\xb0\x08\x04\xe7\xf0\x08\x04\xe7\xff\x08\x04\xe8\x0b\x08\x04\xe8\x1a\x08\x04\xe6\xb0\x08\x04\xe6\xb0\x08\x04' >>> print(binascii.hexlify(data)) e6b00804e79e0804e7bc0804e7d50804e7e40804e6b00804e7f00804e7ff0804e80b0804e81a0804e6b00804e6b00804 >>> >>> data = hexdump(b) >>> print(data) E6 B0 08 04 E7 9E 08 04 E7 BC 08 04 E7 D5 08 04 E7 E4 08 04 E6 B0 08 04 E7 F0 08 04 E7 FF 08 04 E8 0B 08 04 E8 1A 08 04 E6 B0 08 04 E6 B0 08 04 >>> >>> # achieving the same output with binascii is overcomplicated >>> data_lines = [binascii.hexlify(b)[i:min(i+32, len(binascii.hexlify(b)))] for i in xrange(0, len(binascii.hexlify(b)), 32)] >>> data_lines = [' '.join(l[i:min(i+2, len(l))] for i in xrange(0, len(l), 2)).upper() for l in data_lines] >>> print('\n'.join(data_lines)) E6 B0 08 04 E7 9E 08 04 E7 BC 08 04 E7 D5 08 04 E7 E4 08 04 E6 B0 08 04 E7 F0 08 04 E7 FF 08 04 E8 0B 08 04 E8 1A 08 04 E6 B0 08 04 E6 B0 08 04 On the other side, getting rather useless binascii output from hexdump() is quite trivial: >>> data.replace(' ','').replace('\n','').lower() 'e6b00804e79e0804e7bc0804e7d50804e7e40804e6b00804e7f00804e7ff0804e80b0804e81a0804e6b00804e6b00804' But more practical, for example, would be counting offset from hexdump: >>> print( ''.join( '%05x: %s\n' % (i*16,l) for i,l in enumerate(hexdump(b).split('\n')))) Etc. Conclusion: By providing better building blocks on basic level Python will become a better tool for more useful tasks. References: [1] http://stackoverflow.com/questions/2340319/python-3-1-1-string-to-hex [2] http://en.wikipedia.org/wiki/Hex_dump -- anatoly t.

8 10

itertools.chunks()
by Giampaolo Rodolà April 28, 2013

April 28, 2013

def chunks(total, step): assert total >= step while total > step: yield step; total -= step; if total: yield total >>> chunks(12, 4) [4, 4, 4] >>> chunks(13, 4) [4, 4, 4, 1] I'm not sure how appropriate "chunks" is as a name for such a function. Anyway, I wrote that because in a unit test I had to create a file of a precise size, like this: FILESIZE = (10 * 1024 * 1024) + 423 # 10MB and 423 bytes with open(TESTFN, 'wb') as f: for csize in chunks(FILESIZE, 262144): f.write(b'x' * csize) Now I wonder, would it make sense to have something like this into itertools module? --- Giampaolo https://code.google.com/p/pyftpdlib/ https://code.google.com/p/psutil/ https://code.google.com/p/pysendfile/

12 13

Specificity in AttributeError
by Devin Jeanpierre April 28, 2013

April 28, 2013

Code: class A: @property def text(self): return self.foo Behavior: >>> hasattr(A(), 'text') False Actually, this is absolutely correct. "A().y" does not give a result -- in fact, it raises AttributeError. Behavior wise, this is exactly what it means for an attribute to not exist. The problem is that this may disguise other issues in one's code. Suppose one tries to do "duck-type checking", where a function might get either an object of type A, or an object of type B. It checks if the object has a certain attribute that objects of type A have, and treats it as one or the other as a result. This is ugly, but works, and even works if someone writes a new type that emulates the API of A or B. Real Problem: class B(object): def __init__(self, x): if hasattr(x, 'text'): x = x.text self.x = x Because of an error inside the text property, B has classified x as the wrong type, and this will cause errors later in the execution of the program that might be hard to diagnose. That is what happens when mistakes are made. Worse is that the error is silenced, in a manner similar to how hasattr used to silence things like ValueError. I would not ask that the semantics of hasattr() be changed. hasattr() has a specific meaning, and I don't know what happens if it is changed again. What I would ask is that enough information be added to AttributeError that I can figure out things for myself. Specifically an attribute that stores the object for which attribute access failed, and the attribute (string) for which attribute access failed. This information is known when AttributeError is instantiated, but it's used to generate a string description and then thrown out. I would like to be able to write this function: def hasattr_lite(obj, attr): try: getattr(obj, attr) except AttributeError as e: if e.object is obj and e.attribute is attr: return False raise return True This would let me do this "duck type checking", but also would reduce the number of errors hidden in the process. So I would like it if AttributeError gained those attributes, or some equivalent functionality. Does that sound reasonable? -- Devin

9 10

Cross Platform Python Sound Module/Library
by Clay Sweetser April 27, 2013

April 27, 2013

I've noticed that the python standard library lacks a cross-platform sound/audio module, instead having seperate modules for linux and windows. Is there any reason a standard cross platform library has not been created yet? Clay Sweetser

7 10

Automatic context managers
by anatoly techtonik April 27, 2013

April 27, 2013

Long time no see, all. :P PySide Qt binding have an interesting property - when you create widgets, you need to assign them to variables. When such variable is lost, object is immediately destroyed. I often use this one-shot code in setup.py: ... long_description = open('README.txt').read(), .... Which probably leaves the README.txt file open until the setup.py exits. So, the idea is to close the file as soon as the variable is lost. I don't know why it was not implemented in the first place. Any ideas? Depending on the answer to the above, the solution can be different. I assume that this was done for a reason (probably immediate garbage collection is too expensive), but confirmation is welcome. Meanwhile the solution can be implemented with auto context manager, which __exit__ method is automatically called when all links to created object are lost. Difference from usual "with something" is that it is transparent to the user (leaves less details to worry about) and makes code more beautiful -- in the example above the assignment is made inside setup(...) parameter assignment. An example with ordinary "with" statement would look like: with open('README.txt') as readme: setup( .... long_description=readme.read(), .... ) The nesting level increases with every new file you need to read. Another variation is intermediate variables, which is also less nice. with open('README.txt') as readme: content = readme.read() setup( .... long_description=content, .... ) -- anatoly t.

15 36

Re: [Python-ideas] Automatic context managers
by MRAB April 27, 2013

April 27, 2013

On 26/04/2013 17:52, Chris Angelico wrote: > On Sat, Apr 27, 2013 at 1:54 AM, MRAB <python(a)mrabarnett.plus.com> wrote: >> On 26/04/2013 14:02, anatoly techtonik wrote: >>> This circular reference problem is interesting. In object space it >>> probably looks like a stellar detached from the visible (attached) >>> universe. Is the main problem in detecting it? >>> >> The problem is in knowing in which order the objects should be >> collected. >> >> For example, if A refers to B and B refers to A, should you collect A >> then B, or B then A? If you collect A first, then, for a time, B will >> be referring to a non-existent object. That's not good if the objects >> have destructors which need to be run. > > Spin-off thread from python-ideas to discuss a more general question > of garbage collection of cyclic structures. > > Once it's been proven that there's an unreferenced cycle, why not > simply dispose of one of the objects, and replace all references to it > (probably only one - preferably pick an object with the fewest > references) with a special temporary object? In fact, that could > probably be done in CPython by wiping out the object in memory and > replacing it with a special marker of some sort, which would then > automatically "take over" all references to the old object. Any > attempt to manipulate this object could simply pop back with a > DestructedObject exception or something. > I wonder whether it would be best to call the __del__ method of the newest object (if it's possible to determine which is the newest) in such a case, then replace _that_ object with the DestructedObject (the "special marker" would be just a special "destructed" object). > Is this a plausible (never mind viable yet, just conceptually > plausible) alternative to sticking them into gc.garbage and ignoring > them? It'd allow a double-linked list/tree to function cleanly - > imagine, for instance, something like the DOM facilities available to > web browser scripts: > > class DOMObject: > def __init__(self,parent): > self.parent=parent > self.firstchild=self.sibling=None > if not parent: return > if not parent.firstchild: > parent.firstchild=self > else: > child=parent.firstchild > while child.sibling: > child=child.sibling > child.sibling=self > def __del__(self): > print("Disposing of id #%d"%id(self)) > > document=DOMObject(None) > body=DOMObject(document) > p=DOMObject(body) > p=DOMObject(body) > p=DOMObject(body) > del document,body,p > gc.collect() > > The __del__ method would need to clean up the external resources used > by this object, but wouldn't have to walk the tree. Yet, just because > there is a reference loop and there are __del__ methods, the garbage > collector gives up and leaves it to the program author to deal with. > > I can understand if this is considered too complicated and too unusual > a circumstance to be worth bothering to support, but I'm curious as to > whether it's at least conceptually reasonable to do something like > this. > It does sound like an interesting idea.

3 2

Re: [Python-ideas] CPython's cyclic garbage collector (was Automatic context managers)
by MRAB April 26, 2013

April 26, 2013

On 26/04/2013 20:31, Dave Angel wrote: > On 04/26/2013 01:57 PM, Chris Angelico wrote: >> On Sat, Apr 27, 2013 at 3:42 AM, Dave Angel <davea(a)davea.name> wrote: >>> I don't see what your "special" temporary object actually accomplishes. >>> Seems to me you need to declare that your __del__() methods promise not to >>> reference each other, and the gc would then check all objects in the cycle, >>> and do its present behavior if any of the destructors is not specially >>> declared. >> >> It wouldn't be declared; it'd simply throw an exception if anything >> different happened. >> >>> I'm not sure how often you'd have a non-trivial destructor that wouldn't >>> reference any objects. And doing a static analysis of what will happen >>> during the destructor would be pretty messy. So the best I and come up with >>> is to keep the declaration, but require a try/catch to cleanly terminate >>> each destructor if it ever references anything in the tree. >> >> And yeah. If you catch the exception inside __del__, you can cope with >> the destructed object yourself (or LBLY, if you wish). Alternatively, >> you just proceed as normal, and when your __del__ throws an exception, >> the gc then copes (not sure *how* it should cope - log it to stderr >> and carry on?). Same as normal exception handling. >> >> The advantage of this style is that the code to deal with the cycle is >> kept right in the cyclic object's destructor - right where the problem >> is. Doing it through gc.garbage requires that some other operation >> periodically check for garbage - after the GC has done its own >> periodic check. Seems simpler/cleaner to do it as part of the gc run >> itself. >> > > You must think me dense by now. But I don't understand what the two > different garbage collection operations are that you're positing. > > As far as I know, there's ref counting, which is quick, and frees > something as soon as the count goes to zero. Then there's gc, which has > to scan through all the objects from a known starting set, and identify > those things which aren't accessible, and free any that don't have a > __del__() method. > > And it's only in the gc step that cycles and such are identifiable. > Currently, if the GC finds a cycle and the objects in that cycle have __del__ methods, the objects are not collected. The suggestion is that in such a case the GC could call the __del__ method and then replace the object with a special "deleted" object, removing any references to other objects and thus breaking the cycle. If a __del__ method in one of the other objects subsequently tries to use the deleted object, an exception would be raised (a kind of AttributeError perhaps).

1 0

"else" expression ":"
by Peter Norvig April 18, 2013

April 18, 2013

Beginners will often write code like this: if val > 0: return +1 elif val < 0: return -1 elif val == 0: return 0 Now if you did this in Java, the compiler would produce an error saying that there is an execution path that does not return a value. Python does not give an error message, but it would be considered more idiomatic (and slightly more efficient) to have just "else:" in the third clause. Here's an idea to address this. What do you think of the syntax "else" expression ":" for example: if val > 0: return +1 elif val < 0: return -1 else val == 0: return 0 with the interpretation: if val > 0: return +1 elif val < 0: return -1 else: assert val == 0 return 0 I have to say, I'm uncertain. I'm not sure this is even a good idea at all, and I'm not sure if it should translate into "assert expression" or whether it should be "if not expression: raise ValueError". What do you think? -Peter Norvig

12 14