🌐 Mailman 3 September 2010 - Python-list - python.org

Re: scheduler or infinite loop
by harryos Sept. 30, 2010

Sept. 30, 2010

thanks Frank > > Here is a technique that allows the loop to run in the background, in its > own thread, leaving the main program to do other processing - > > import threading > > class DataGetter(threading.Thread): >

2 1

Re: Clarification of notation
by alex23 Sept. 30, 2010

Sept. 30, 2010

Bruce Whealton <br...(a)futurewavedesigns.com> wrote: > For lists, when would > you use what appears to be nested lists, like: > [[], [], []] > a list of lists? Well, you'd use it when you'd want a list of lists ;) There's nothing magical about a list of lists, it's just a list with objects inside like any other, in this case they just happen to be lists. Possibly the canonical example is for a simple multidimensional array: >>> array5x5 = [[0]*5 for i in range(5)] >>> array5x5[2][3] = 7 >>> array5x5[4][1] = 2 >>> array5x5 [[0, 0, 0, 0, 0], [0, 0, 0, 0, 0], [0, 0, 0, 7, 0], [0, 0, 0, 0, 0], [0, 2, 0, 0, 0]] > Would you, and could you combine a dictionary with a list in this fashion? Lists can contain dictionaries that contain dictionaries containing lists :) So yes, they can easily be combined. Here's a list with dictionaries: elements = [ {'tag': 'strong', 'style': 'bold'}, {'tag': 'header', 'style': 'bolder', 'color': 'red}, ] And a dictionary of lists: classes_2010 = { 'economics': ['John Crowley', 'Jack Savage', 'Jane Austen'], 'voodoo economics': ['Ronald Reagan', 'Ferris Beuller'], } (Note that the formatting style is a personal taste and not essential). Generally, you tend to use a list when you want to work on items in sequence, and a dictionary when you want to work on an item on demand. > Next, from the documentation I see and this is just an example (this > kind of notation is seen elsewhere in the documentation: > > str.count(sub[, start[, end]]) > This particular example is from the string methods. > Is this a nesting of two lists inside a a third list? I know that it > would suggest that some of the arguments are optional, so perhaps if > there are 2 items the first is the sub, and the second is start? Or did In documentation (as opposed to code), [] represents optional arguments, and have nothing at all to do with Python lists. The above example is showing that the method can be called in the following ways: 'foobarbazbam'.count('ba') 'foobarbazbam'.count('ba', 6) 'foobarbazbam'.count('ba', 6, 9) Hope this helps.

1 0

Re: Clarification of notation
by Seebs Sept. 30, 2010

Sept. 30, 2010

On 2010-09-30, Bruce Whealton <bruce(a)futurewavedesigns.com> wrote: > Next, from the documentation I see and this is just an example (this > kind of notation is seen elsewhere in the documentation: > str.count(sub[, start[, end]]) > This particular example is from the string methods. > Is this a nesting of two lists inside a a third list? No, it's not -- it's a different use of [] to indicate that things are optional, a convention which dates back to long before Python existed. >I know that it > would suggest that some of the arguments are optional, so perhaps if > there are 2 items the first is the sub, and the second is start? Or did > I read that backwards? That is exactly correct. The key is the implication that you can omit end, or both start and end. (But you can't omit start and provide end.) -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.

1 0

Re: (and scheme lisp) x Python and modern langs [was Re: gossip, Guy Steel, Lojban, Racket]
by Xah Lee Sept. 30, 2010

Sept. 30, 2010

2010-09-28 On Sep 28, 12:07 pm, namekuseijin <namekusei...(a)gmail.com> wrote: > On 28 set, 14:56, Xah Lee <xah...(a)gmail.com> wrote: > > > ultimately, all lang gets transformed at the compiler level to become > > machine instructions, which is imperative programing in the ultimate > > sense. > > > You say that “do” is merely macro and ultimately function application. > > But to what level should we go down this chain on how the language > > actually works when evaluating a function in source code? > > > any functional lang, quickly becomes imperative when compiled to some > > intermediate code or interpreted. In a sense, it can't be any other > > way. Functions are abstract mathematical ideas, while “do” loop or any > > instruction are actual steps of algorithms. > > That is true as of Mathematica too. Difference being that do in > scheme is pretty-much user-level syntax. If you look in most (good) > implementations sources, do and let are defined in scheme itself, not > C or lower-level: C code only deals with transforming lambda > application and tail calls into proper gotos. > > So, as far as we're talking about scheme, haskell or Mathematica code, > it's all functional in its abstraction context. > > do syntax does allow for imperative commands to be issued in scheme, > just like let. It does not mean it was used in said examples nor that > do is automatically inherently imperative just because of choice of > name. imperative do -> (do (steppers ...) (final-condition? result) > malign-imperative-code-here ...) > > so, now that we got it clear why do in scheme is not (inherently) > imperative why were you bashing useful (at times) functional syntax in > the form of list comprehensions again? le's get precise. The argument i want to make, is this: • “list comprehension” is a very bad jargon; thus harmful to functional programing or programing in general. Being a bad jargon, it encourage mis-communication, mis-understanding. • “list comprehension” is a redundant concept in programing. The concept is of historical interest. e.g. when people talk about the history of computer languages. The LC can simply be filter(map(func, list), predicate). • The special syntax of “list comprehension” as it exists in many langs, are not necessary. It can simply be a plain function, e.g LC(function, list, filter). I gave a stand-alone explanation of these points at: http://groups.google.com/group/comp.lang.lisp/msg/329b3b68ff034453 Do you disagree or agree with the above? This is the point _I_ want to argue about, but you don't seem to admit any part of it, but you seems to want to discuss about “do” in Scheme lisp being functional. So, perhaps we can now focus on this subject: The “do” in Scheme lisp is not imperative, or, it can be considered as functional. Alright. To be honest, i haven't had enough experience to comment on, but in general, i understand the example you've given, and i disagree. Full report on your argument on this is given at: http://groups.google.com/group/comp.lang.lisp/msg/87a987070e80231f Now, in your message (quoted above), you made further argument on this. I think the main point is this, quote: «do syntax does allow for imperative commands to be issued in scheme, just like let. It does not mean it was used in said examples nor that do is automatically inherently imperative just because of choice of name. imperative do -> (do (steppers ...) (final-condition? result) malign-imperative-code-here ...)» i don't think your argument is forceful enough. It appears that by this argument you even say that “let” is not functional. Here, the issue verges on what is functional? What is a function? If a function in lisp is defined as macro, does it ceases to be considered as a function? Likewise, if a lisp's has “for” loop that is defined as a macro, is that “for” now considered a function? this is getting quite iffy. What level or aspect are we considering? In each lang, usually they define certain terms specifically to the lang, and to various degree of precision. For eample, the term “object” means very different things in a technical way in different langs. Same for the word “function”, “keyword”, “command”, “module”, “package” ... So, overall, i consider your argument for “do” in Scheme lisp being functional is weak, or trivial. It seems to be a pet peeve. You got annoyed because i seem to have ignored it entirely. But i got annoyed by you because you don't get the point about what i consider more significant opinion on “list comprehension”, which you totally ignored and kept at hacking the “do” in Scheme lisp. Xah ∑ xahlee.org ☄

4 5

Re: Certificate validation with HTTPSConnection
by John Nagle Sept. 30, 2010

Sept. 30, 2010

On 9/29/2010 3:51 PM, Antoine Pitrou wrote: > On Wed, 29 Sep 2010 13:41:15 -0700 > John Nagle<nagle(a)animats.com> wrote: >> >> The really stupid thing about the current SSL module is that it >> accepts a file of root certificates as a parameter, but ignores it. > > That's not true. You have to pass CERT_OPTIONAL or CERT_REQUIRED as a > parameter (CERT_NONE is though). If you pass CERT_REQUIRED and a root certificate authority file, there has to be some certificate, but the signature chain is not validated against the CA file, so the cert doesn't certify anything. Phony web sites look valid to Python's SSL library. John Nagle

1 0

Strange os.stat behavior
by Philip Bloom Sept. 30, 2010

Sept. 30, 2010

I'm on python 2.6.1: Ran into some os.stat behavior that knocked me for a loop. I was using os.stat to retrieve file st_ctime and st_mtime from a remote server through a unc path, and doing this I encountered that os.stat was returning me st_ctime and st_mtime values that were months off, reporting values that not only were months in the past, but also relatively wrong (Reporting a greater difference between Modified and Created than there should be). Below, run through localtime and formatted a little for easier reading.). C++ stat, Win32API, and Windows own directory report all match with the same seen time (and are correct). Has anyone seen something like this before? It's quite scary to me that os.stat is returning a different value that it's getting from somewhere and doesn't match with either the Windows API or the C++ stat library. I read over the release notes for 2.6.x and didn't see any mention of os.stat relevant bugs or fixes. I'm curious what it could possibly be doing differently than the others (I thought it used the windows api under the hood for Windows nt derived systems). Ex: \\mpkarc01\Build_stats\tras\MayaExportKernel_p.config\mabahazy~RWCWRK_70 01470.stats\9-27-2010_log.txt 1279755701.87 1285810489.65 Created: time.struct_time(tm_year=2010, tm_mon=7, tm_mday=21, tm_hour=16, tm_min=41, tm_sec=41, tm_wday=2, tm_yday=202, tm_isdst=1) Modified: time.struct_time(tm_year=2010, tm_mon=7, tm_mday=25, tm_hour=0, tm_min=59, tm_sec=45, tm_wday=6, tm_yday=206, tm_isdst=1), raw: 1280044785 Accessed: time.struct_time(tm_year=2010, tm_mon=9, tm_mday=29, tm_hour=17, tm_min=25, tm_sec=31, tm_wday=2, tm_yday=272, tm_isdst=1) Raw Time.Time(): time.struct_time(tm_year=2010, tm_mon=9, tm_mday=29, tm_hour=18, tm_min=34, tm_sec=49, tm_wday=2, tm_yday=272, tm_isdst=1), raw: 1285810489.65 Win32API Ctime: 09/27/10 20:18:11 Win32API MTime: 09/28/10 01:18:37 Win32API ATime: 09/29/10 00:24:46 Relevant code segment: import win32api import win32con import win32file import time import os ... statinfo = os.stat(os.path.join(root, name)) print os.path.join(root, name) + " " + str(statinfo.st_ctime) + " " + str(time.time()) print "Modified: ", time.localtime(int(statinfo.st_mtime)),int(statinfo.st_mtime) print "Created: ", time.localtime(int(statinfo.st_ctime)) print "Accessed: ", time.localtime(int(statinfo.st_atime)) print time.localtime(),time.time() fh = win32file.CreateFile(os.path.join(root, name), win32file.GENERIC_READ | win32file.GENERIC_WRITE, 0, None, win32file.OPEN_EXISTING,0, 0) sts, creationTime, accessTime, writeTime = win32file.GetFileTime(fh) print creationTime, accessTime, writeTime win32file.CloseHandle(fh) Platform of executing code: Windows XP, 64 bit. ______________________________________________________________________ This email has been scanned by the MessageLabs ______________________________________________________________________

1 0

Supplementing the std lib (Was: partial sums problem)
by kj Sept. 30, 2010

Sept. 30, 2010

In <mailman.1142.1285722789.29448.python-list(a)python.org> Terry Reedy <tjreedy(a)udel.edu> writes: >Do not try to do a reduction with a comprehension. Just write clear, >straightforward code that obviously works. >s=[1,2,3,4,5,6] >def cusum(s): > t = 0 > for i in s: > t += i > yield t >print(list(cusum(s))) > >>> >[1, 3, 6, 10, 15, 21] Actually, this is just fine. Thank you! But it brings up a new question, of an entirely different nature. It's a recurrent conundrum, actually, and I have not found a good solution. Your cusum function is one that I would like to see somewhere in the standard library (in itertools maybe?). Maybe some future version of the standard library will have it, or something like it (I'm thinking of a generalized form which, like reduce, takes a function and an initial value as arguments). But in the immediate term, cusum is not part of the standard library. Where would you put it if you wanted to reuse it? Do you create a module just for it? Or do you create a general stdlib2 module with all those workhorse functions that have not made it to the standard library? Or something else entirely? (I'm not expecting to get *the* solution from anyone reply; rather, I'm interested in reading people's take on the question and their way of dealing with those functions they consider worthy of the standard library.) kj

4 3

Re: About __class__ of an int literal
by Steven D'Aprano Sept. 30, 2010

Sept. 30, 2010

On Wed, 29 Sep 2010 02:20:55 +0100, MRAB wrote: > On 29/09/2010 01:19, Terry Reedy wrote: >> A person using instances of a class should seldom use special names >> directly. They are, in a sense, implementation details, even if >> documented. The idiom "if __name__ == '__main__':" is an exception. >> > __file__ is another exception. As are __iter__, __next__, __add__, __dict__, and, yes, __class__, to say nothing of all the other special methods. I'm afraid that I have to disagree with Terry here. Double-underscore special variables don't start with double underscores because they're implementation details, or to indicate that they're private. They are reserved names for attributes or methods that have special meaning to Python. An implementation that didn't use __dict__ for the namespace of an ordinary class, or didn't call __add__ for the + operator, would be considered to be buggy. Naturally one has to be careful about the assumptions you make with such special methods. You shouldn't assume, for example, that all classes will have a __dict__ attribute. If the class has __slots__ defined, it may not. But I think that it is safe to assume any object will have a __class__ attribute. At least, I'd report it as a bug if I found one that didn't. (This may change in the future. Given type(), and isinstance(), I'm not sure what value __class__ adds.) -- Steven

4 3

ANNOUNCING Tahoe, the Least-Authority File System, v1.8.0
by Zooko O'Whielacronx Sept. 30, 2010

Sept. 30, 2010

Hello, people of python-list. This storage project uses Python for almost everything, except we use C/C++ for the CPU-intensive computations (cryptography and erasure coding) and we use JavaScript for some user interface bits. We're even looking at the possibility of replacing the C/C++ crypto code with pure-Python code, relying on JIT compilers such as PyPy to make it efficient enough. :-) http://twitter.com/#!/fijall/status/25314330015 Regards, Zooko ANNOUNCING Tahoe, the Least-Authority File System, v1.8.0 The Tahoe-LAFS team is pleased to announce the immediate availability of version 1.8.0 of Tahoe-LAFS, an extremely reliable distributed storage system. Get it here: http://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.html Tahoe-LAFS is the first distributed storage system to offer "provider-independent security" — meaning that not even the operators of your storage servers can read or alter your data without your consent. Here is the one-page explanation of its unique security and fault-tolerance properties: http://tahoe-lafs.org/source/tahoe/trunk/docs/about.html The previous stable release of Tahoe-LAFS was v1.7.1, which was released July 18, 2010 [1]. v1.8.0 offers greatly improved performance and fault-tolerance of downloads and improved Windows support. See the NEWS file [2] for details. WHAT IS IT GOOD FOR? With Tahoe-LAFS, you distribute your filesystem across multiple servers, and even if some of the servers fail or are taken over by an attacker, the entire filesystem continues to work correctly, and continues to preserve your privacy and security. You can easily share specific files and directories with other people. In addition to the core storage system itself, volunteers have built other projects on top of Tahoe-LAFS and have integrated Tahoe-LAFS with existing systems, including Windows, JavaScript, iPhone, Android, Hadoop, Flume, Django, Puppet, bzr, mercurial, perforce, duplicity, TiddlyWiki, and more. See the Related Projects page on the wiki [3]. We believe that strong cryptography, Free and Open Source Software, erasure coding, and principled engineering practices make Tahoe-LAFS safer than RAID, removable drive, tape, on-line backup or cloud storage. This software is developed under test-driven development, and there are no known bugs or security flaws which would compromise confidentiality or data integrity under recommended use. (For all important issues that we are currently aware of please see the known_issues.txt file [4].) COMPATIBILITY This release is compatible with the version 1 series of Tahoe-LAFS. Clients from this release can write files and directories in the format used by clients of all versions back to v1.0 (which was released March 25, 2008). Clients from this release can read files and directories produced by clients of all versions since v1.0. Servers from this release can serve clients of all versions back to v1.0 and clients from this release can use servers of all versions back to v1.0. This is the eleventh release in the version 1 series. This series of Tahoe-LAFS will be actively supported and maintained for the forseeable future, and future versions of Tahoe-LAFS will retain the ability to read and write files compatible with this series. LICENCE You may use this package under the GNU General Public License, version 2 or, at your option, any later version. See the file "COPYING.GPL" [5] for the terms of the GNU General Public License, version 2. You may use this package under the Transitive Grace Period Public Licence, version 1 or, at your option, any later version. (The Transitive Grace Period Public Licence has requirements similar to the GPL except that it allows you to delay for up to twelve months after you redistribute a derived work before releasing the source code of your derived work.) See the file "COPYING.TGPPL.html" [6] for the terms of the Transitive Grace Period Public Licence, version 1. (You may choose to use this package under the terms of either licence, at your option.) INSTALLATION Tahoe-LAFS works on Linux, Mac OS X, Windows, Cygwin, Solaris, *BSD, and probably most other systems. Start with "docs/quickstart.html" [7]. HACKING AND COMMUNITY Please join us on the mailing list [8]. Patches are gratefully accepted -- the RoadMap page [9] shows the next improvements that we plan to make and CREDITS [10] lists the names of people who've contributed to the project. The Dev page [11] contains resources for hackers. SPONSORSHIP Tahoe-LAFS was originally developed by Allmydata, Inc., a provider of commercial backup services. After discontinuing funding of Tahoe-LAFS R&D in early 2009, they continued to provide servers, bandwidth, small personal gifts as tokens of appreciation, and bug reports. Google, Inc. sponsored Tahoe-LAFS development as part of the Google Summer of Code 2010. They awarded four sponsorships to students from around the world to hack on Tahoe-LAFS that summer. Thank you to Allmydata and Google for their generous and public-spirited support. HACK TAHOE-LAFS! If you can find a security flaw in Tahoe-LAFS which is serious enough that feel compelled to warn our users and issue a fix, then we will award you with a customized t-shirts with your exploit printed on it and add you to the "Hack Tahoe-LAFS Hall Of Fame" [12]. ACKNOWLEDGEMENTS This is the fifth release of Tahoe-LAFS to be created solely as a labor of love by volunteers. Thank you very much to the team of "hackers in the public interest" who make Tahoe-LAFS possible. David-Sarah Hopwood and Zooko Wilcox-O'Hearn on behalf of the Tahoe-LAFS team September 23, 2010 Rainhill, Merseyside, UK and Boulder, Colorado, USA [1] http://tahoe-lafs.org/trac/tahoe/browser/relnotes.txt?rev=4579 [2] http://tahoe-lafs.org/trac/tahoe/browser/NEWS?rev=4732 [3] http://tahoe-lafs.org/trac/tahoe/wiki/RelatedProjects [4] http://tahoe-lafs.org/trac/tahoe/browser/docs/known_issues.txt [5] http://tahoe-lafs.org/trac/tahoe/browser/COPYING.GPL [6] http://tahoe-lafs.org/source/tahoe/trunk/COPYING.TGPPL.html [7] http://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.html [8] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev [9] http://tahoe-lafs.org/trac/tahoe/roadmap [10] http://tahoe-lafs.org/trac/tahoe/browser/CREDITS?rev=4591 [11] http://tahoe-lafs.org/trac/tahoe/wiki/Dev [12] http://tahoe-lafs.org/hacktahoelafs/

1 0

Re: About __class__ of an int literal
by Steven D'Aprano Sept. 30, 2010

Sept. 30, 2010

On Wed, 29 Sep 2010 14:46:18 -0400, Terry Reedy wrote: >> In that sense the user >> should be calling iter(foo) instead of foo.__iter__(), next(foo) >> instead of foo.__next__(), and foo+bar instead of foo.__add__(bar). > > Yes. Guido added iter() and next() to the list of built-in functions, > even though they seem reduncant.. I believe it is his intention that the > use of special names outside of class statements should be fairly rare. Fairly rare but not non-existent. For example, there's nothing wrong with using a callback function of (say) instance.__sub__ instead of lambda b, a=instance: a - b. Not only is the direct call to the method slightly faster, but more importantly it's easier to read and more clear to intent. Admittedly beginners may find instance.__sub__ to be a tad mysterious, but then beginners are likely to find the lambda form with its two arguments and default value mysterious too. > If I remember right, in the old, pre-2.2 system that separated built-in > types and user-written classes, the builtins did not have accessible > special method attributes. Yes, that's correct. But we're talking about Python *now*, not back in the mists of time before new-style classes. Would you argue that users shouldn't use decorators, iterators or closures because Python 2.1 didn't have them? I don't think so. > They are only for customizing user classes. Say "were" rather than "are" and I will agree with you. Say "primarily for" rather than "only" and I will also agree with you. > So one could not have generically written foo.__add__(bar). > Special-method attribute were added to builtins so that they could be > inherited (or replaced) by user-written subclasses, not so that one > could replace normal syntax. Of course one shouldn't prefer seq.__len__() over len(seq). But that's a readability issue, and not because Python implementations are free to change __len__ to something else. If I gave the opposite impression, that was not my intention and I'm sorry for the failure to be more clear. >> Direct >> calls to special-name methods, such as __len__, often indicate that the >> programmer hasn't grasped how those methods are intended to be used in >> Python. > > Right. That fact that *Python* interpreters implement syntax with > special methods is an implementation detail of the *language*. The > importance is that it allow *writers* of new classes to rather easily > imitate built-in classes so that their classes seamlessly plug into the > syntax. If I've understood this paragraph correctly, you're trying to say that since *other languages* that aren't Python are free to implement syntax features using some other mechanism, *Python* developers shouldn't use special methods because they are implementation details. If we're prohibited from using anything which is an implementation detail of "the *language*" (your emphasis), then we can't use *anything*. Yes, special methods are an implementation detail of Python, but only in the same sense that it is an implementation detail of Python that we write this: def f(a, b): x = a + b return math.sqrt(x) rather than this: function f(a, b: integer):float: var x: integer; begin x := a + b; f := sqrt(x) end; -- Steven

1 0