micro python and Jaltek systems pyboard
Greetings, anyone using micro python or Jaltek System's pyboard designed to run it? http://micropython.org/ Cheers, marcus :) -- https://mail.python.org/mailman/listinfo/python-list
Re: trying idle
On 10/9/14 1:52 AM, Rustom Mody wrote: > Been using emacs for over 20 years and teaching python for 10. > And getting fed up that my audience looks at me like Rip van Winkle > each time I start up emacs... (sigh) > So trying out Idle... Good for you! ... and even better for your students. IDLE is fabulous as a native python interactive development environment these days. It really works well, is clean and does what it advertises; its very nice! > > Some specific and some general questions: > My audience consists of people having linux and windows and macbooks. > Does Idle run on all these? Absolutely. The ONLY problem you might run into on the (macs) apple systems is that tcl/tk tkinter might be at the wrong level. Use ActiveTCL: https://www.python.org/download/mac/tcltk Depending on the apple system the wrong (built-in tcl/tk tkinter) will cause problems. If you ActiveTCL you'll have no problem. Just point your students at the appropriate pages. Cheers -- https://mail.python.org/mailman/listinfo/python-list
Re: trying idle
On 10/9/14 7:21 AM, wxjmfa...@gmail.com wrote: My audience consists of people having linux and windows and macbooks. Does Idle run on all these? --- No. Huh? -- https://mail.python.org/mailman/listinfo/python-list
Re: trying idle
On 10/9/14 7:47 AM, random...@fastmail.us wrote: I believe control-click, but Macs users could say better. Control-click was the canonical way to do it when right click menus were introduced in Mac OS itself. Some programs (notably Netscape) supported them via click-hold before that. And it's been nearly a decade since Apple sold a mouse with no ability to right-click. The apple mouse has only one click in the hardware... but, through the software (settings) the apple hardware 'know' which side of the mouse you are pushing over. You can configure the mouse through the settings to make the left or right side function alternately. The same is true for the magic mouse (wireless, swipe-able); it also only has one clicker but 'senses' which side of the mouse the fingers are over when the push occurs. At any rate, right mousing on the mac has been happening for several years. -- https://mail.python.org/mailman/listinfo/python-list
Re: About python while statement and pop()
On 6/12/14 11:57 AM, Chris Angelico wrote: def poplist(L): done = False while done==False: yield L[::-1][:1:] L = L[::-1][1::][::-1] if len(L)==0: done=True Why not just "while L"? OK, here it is with Chris' excellent advice: >>> def poplist(L): while L: yield L[::-1][:1:] L = L[::-1][1::][::-1] >>> L=[1, 2, 3, 4, 5, 6, 7] >>> m=[] >>> pop = poplist(L) >>> for n in poplist(L): m.append(n[0]) >>> m [7, 6, 5, 4, 3, 2, 1] >>> == ah === -- https://mail.python.org/mailman/listinfo/python-list
Re: About python while statement and pop()
On 6/12/14 11:57 AM, Chris Angelico wrote: On Fri, Jun 13, 2014 at 2:49 AM, Mark H Harris wrote: Consider this generator variation: def poplist(L): done = False while done==False: yield L[::-1][:1:] L = L[::-1][1::][::-1] if len(L)==0: done=True Why not just "while L"? Or are you deliberately trying to ensure that cheating will be detectable? ;-) -- https://mail.python.org/mailman/listinfo/python-list
Re: About python while statement and pop()
On 6/12/14 11:55 AM, Marko Rauhamaa wrote: while not done: Better Python and not bad English, either. ... and taking Marko's good advice, what I think you really wanted: >>> def poplist(L): done = False while not done: yield L[::-1][:1:] L = L[::-1][1::][::-1] if len(L)==0: done=True >>> L=[1, 2, 3, 4, 5, 6, 7] >>> m=[] >>> pop = poplist(L) >>> for n in poplist(L): m.append(n[0]) >>> m [7, 6, 5, 4, 3, 2, 1] >>> -- https://mail.python.org/mailman/listinfo/python-list
Re: About python while statement and pop()
On 6/11/14 10:12 PM, hito koto wrote: def foo(x): y = [] while x !=[]: y.append(x.pop()) return y Consider this generator variation: >>> def poplist(L): done = False while done==False: yield L[::-1][:1:] L = L[::-1][1::][::-1] if len(L)==0: done=True >>> L1=[1, 2, 3, 4, 5, 6, 7] >>> for n in poplist(L1): print(n) [7] [6] [5] [4] [3] [2] [1] >>> -- https://mail.python.org/mailman/listinfo/python-list
Re: About python while statement and pop()
On 6/11/14 10:12 PM, hito koto wrote: i want to change this is code: def foo(x): y = [] while x !=[]: y.append(x.pop()) return y Consider this generator (all kinds of permutations on the idea): >>> L1 [1, 2, 3, 4, 5, 6, 7] >>> def poplist(L): while True: yield L[::-1][:1:] L = L[::-1][1::][::-1] >>> pop = poplist(L1) >>> next(pop) [7] >>> next(pop) [6] >>> next(pop) [5] >>> next(pop) [4] >>> next(pop) [3] >>> next(pop) [2] >>> next(pop) [1] >>> next(pop) [] >>> next(pop) [] -- https://mail.python.org/mailman/listinfo/python-list
Re: Python's re module and genealogy problem
On 6/11/14 8:26 AM, Robert Kern wrote: Anyways, to your new problem, yes it's possible. Search for "regular expression intersection" for possible approaches. I agree, I would not use a decision (decision tree) but would consider a set of filters from most specific to least specific. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: First time I looked at Python was(...)
On 6/10/14 3:41 PM, leo kirotawa wrote: Guys I'm from Brazil too, and I'm ashamed for this troll. Don't feed the troll bot. OTOH, it might be fun to feed it some weird subject|predicate phrases to see what it does with them. Bots eat bananas because bouncing on berries becomes beenie baby bologna! ;-) -- https://mail.python.org/mailman/listinfo/python-list
Re: First time I looked at Python was(...)
On 6/9/14 3:54 PM, Carlos Anselmo Dias wrote: Hi ... I'm finishing my messages with this ... The first time I looked into Python was +- 10 years ago ... and in the last 10 years I did not spent more than 30 minutes looking at ... but I like it ... it's easy to read ... even if I'm not familiar with the syntax of ... When you look at the script I provided you in my first post ... if you're capable of thinking about it ... yoy can see countless terabytes/petabytes of information indexed .. it doesn't matter what you're daling with ...it might be millions of databases or billions of files ... I spent the last two days thinking about what I want to implement(...) ... looking at your posts ... thinking in the wideness and in the particularity of the detail ... I really consider that Python is one good option(probably the best) ... the programmers need less lines of code to achieve what must be achieved ... and this is one great advantage ... If you read what I wrote in my first post ->'Python team(...)' and if somehow you're capable of visualize that integrated with logs ,etc ... advertisement included, manipulation of the search string in the client apis, etc ... you're very probably very capable of ... (...) Best regards, Carlos This is the funniest troll I have see in a while... and a bot to boot! ~cool -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On 6/5/14 12:18 PM, Michael Torrie wrote: No they won't be used in the same niche. Objective C is certainly not used in the same niche as Python, so why would Swift? I don't expect to see any major OS X app written completely in Python, nor would I expect and of the core frameworks to be written in Python. They will be written in Swift however. OS X apps will indeed be written in Swift; esp if they will be distributed from the Apple Store--- Python apps are streng verboten in Apple land. OTOH, much of my Python work is done on the mac for the mac... just not distributed from the Apple Store. OTOH, it only makes sense to code with Apple's tools if the app is going to be Apple Store ready. OTOH, I don't view the mac as an "Apple" thing. My mac is a *nix clone (freeBSD variant) which is a stable platform for Python coding and debug|test. I won't be using Swift; however, I will be using IDLE. JFTR, Apple should have adopted Python3, IMHO. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Unicode and Python - how often do you index strings?
On 6/5/14 10:39 AM, alister wrote: {snipped all the mess} And you have may time been given a link explaining the problems with posting g=from google groups but deliberately choose to not make your replys readable. The problem is that thing look fine in google groups. What helps is getting to see what the mess looks like from Thunderbird or equivalent. -- https://mail.python.org/mailman/listinfo/python-list
Re: Error while installing PIL
On 6/4/14 10:02 PM, Sanjay Madhikarmi wrote: I have already install python 2.7 64bit in my windows 8 machine but while installing PIL 1.1.7 for python 2.7 it says that "Python 2.7 required which was not found in the registry" Please help me sort out this problem ... also this one; -- https://mail.python.org/mailman/listinfo/python-list
Re: Error while installing PIL
On 6/4/14 10:02 PM, Sanjay Madhikarmi wrote: I have already install python 2.7 64bit in my windows 8 machine but while installing PIL 1.1.7 for python 2.7 it says that "Python 2.7 required which was not found in the registry" ... oops, sorry, also this one: http://stackoverflow.com/questions/3652625/installing-setuptools-on-64-bit-windows marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Error while installing PIL
On 6/4/14 10:02 PM, Sanjay Madhikarmi wrote: I have already install python 2.7 64bit in my windows 8 machine but while installing PIL 1.1.7 for python 2.7 it says that "Python 2.7 required which was not found in the registry" Please help me sort out this problem http://stackoverflow.com/questions/14177000/cant-install-pil-1-7 I found the above link with a google search; there are others. I suspect this is the probably answer to your question. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On 6/4/14 5:18 PM, Terry Reedy wrote: On 6/4/2014 10:53 AM, Mark H Harris wrote: The primary paradigm on this topic locally is that indents are bad because malformed or mangled code cannot be reformatted easily (if at all). Begin solution:':' as the end of a line means 'begin block; indent next line'. If one is using tools that mangle, one can add end-of-block comments: '# end, # end if, # if (end implied), or even just ##. In any case, the stylized comment could mean 'dedent' and code could be reconstituted with all indents stripped. There are probably programs on PyPI to do that. End of excuse. Yup. Well, I've only been doing python coding for ~9-10 years, but I've never had this formatting problem. I viewed the entire debate as 'an excuse'. I'm going to do some looking on PyPI-- it would be nice to point folks to something concrete. If its an excuse, then that puts an end to it. As long as I'm addressing an IDLE guy, what would you think of a feature for IDLE that would format python code with block delimiters automatically and visa versa ? Thanks marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: immutable vs mutable
On 6/3/14 8:14 PM, Deb Wyatt wrote: Well, I'm glad you find this concept straight-forward. I guess I'm not as smart as you. Not at all. I think you misunderstood me. I read the article and I reviewed it (although brief, I stand by what I said). To expand a bit, the article is poorly written and adds more confusion to the topic than it straightens out. (that is not a comment on your, or my, intelligence) Most of the article is based on a misunderstanding of the concept of python as variable, and that topic comes up here all the time with these at the top: 1) python does not have variables 2) python has names bound to objects 3) python of *course* has variables marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: immutable vs mutable
On 6/3/14 8:24 PM, Ethan Furman wrote: Deb, do yourself a favor and just trash-can anything from Mark Harris. Ouch, that hurt. Did someone not get their coffee this morning? :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On 6/4/14 9:24 AM, Skip Montanaro wrote: Surely your local colleagues realize that Python has been around for 20-odd years now, that indentation-based block structure has been there since Day One, and that it's not going to change, right? Yup. Its the primary argument on the side for indentation. "... and don't call me Surely":-) {snip} Why are you people even having this discussion? The topic came up because the C/C++ coders were being encouraged to try Python3 as the language of choice for a new project, and someone said they would never consider Python for a project primary language because of indentation block delimiting. The whole debate, as in most flames, was stupid. The primary paradigm on this topic locally is that indents are bad because malformed or mangled code cannot be reformatted easily (if at all). From my own perspective, if you tell me I need to use END, ok. If I need to use {} , well ok, and if the BDFL says we use indents here, well that's cool tool. Getting back to Swift, did they choose {} braces because JS uses them, or did they choose {} braces because 'they' think most people will want that style? marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On 6/3/14 11:54 PM, Steven D'Aprano wrote: I've been passing code snippets by email and Usenet for 15 years or more, and I've never had a problem with indentation. Of course, I've had problems with *other people's code*, because they use broken tools that break the text they send. Me too. The other way round is also true, that is, tools that break the code when read into a formatting tool. The claim (which I cannot substantiate) is that code passed through emails/web, with indents, gets mangled in such a way that a formatting tool cannot restore the indent logic. Well, the problem is what mangles the code, not the indents. Regardless, the misconception that indents are bad prevails here almost universally. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On 6/3/14 3:43 PM, Sturla Molden wrote: Nicholas Cole wrote: > {snip} Unfortunately they retained the curly brackets from JS... The curly braces come from C, and before that B and A/. (I think others used them too before that, but it escapes me now and I'm too lazy to google it) ... but the point is that curly braces don't come from JS ! I have been engaged in a minor flame debate (locally) over block delimiters (or lack thereof) which I'm loosing. Locally, people hate python's indentation block delimiting, and wish python would adopt curly braces. I do not agree, of course; however, I am noticing when new languages come out they either use END (as in Julia) or they propagate the curly braces paradigm as in C. The issue locally is trying to pass code snippets around the net informally is a problem with indentation. My reply is, well, don't do that. For what I see as a freedom issue, folks want to format their white space (style) their way and don't want to be forced into an indentation paradigm that is rigid (or no so much!). We even have a couple of clucks on our side of the world that refuse to even get their feet wet in python because they hate the indentation paradigm. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On 6/3/14 1:26 PM, Skip Montanaro wrote: From Apple's perspective, there's always platform lock-in. That's good for them, so it must be good for you, right? :-) http://www.theregister.co.uk/2014/06/02/apple_aims_to_speed_up_secure_coding_with_swift_programming_language/ The key to this "Swift thing" is the same for the "Julia thing"... LLVM. Swift is getting huge performance boost from LLVM, not to mention that its not bloated, nor is it designed by committee. ehem. This has less to due with lock-in per se, and more to do with quality control and consistency. OTOH, it has A LOT to due with reinventing the wheel. I love it. Every time a product comes out like Julia, or Swift, the committee needs to take notice, and perhaps adapt. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: immutable vs mutable
On 6/3/14 12:29 PM, Deb Wyatt wrote: http://www.spontaneoussymmetry.com/blog/archives/438 Deb in WA, USA The article is bogged down in unnecessary complications with regard to mutability (or not) and pass-by reference|value stuff. The author risks confusing her audience (those who are perhaps already confused about the nature of variables in Python). The examples deal mostly with names and scope. The article in my opinion confuses a Python concept which is otherwise very straight-forward which has been beat to death on this forum. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: How to run script from interpreter?
On 5/28/14 10:22 PM, Steven D'Aprano wrote: If you want to use python as a shell-glue you can try using system. >>> from os import system >>> def ([parms]) >>> blah blah >>> rc = system(" os.system is cool for quick and dirty calls to an external command. But for serious work, the subprocess module is better. ... yup, particularly for non trivial network related stuff. Neither here nor there, but I just learned the ";" character command today for the Julia REPL, and got to thinking that python should have a similar way for the REPL to drop into "shell" mode for system commands. So, I might code a clear screen in python: def cls() rc = system("clear") or in Julia function cls() run(`clear`) end ... but on Julia we can also do this: ; clear On the Julia REPL the ";" character drops the julia prompt into shell. I think the IDLE REPL should have a system shell mode. What say you? marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
On 5/29/14 11:44 AM, Paul Rudin wrote: Terry Reedy writes: I am curious how many of the editors people have been recommending have all of the following Idle features, that I use constantly. 1. Run code in the editor with a single keypress. 2. Display output and traceback in a window that lets you jump from the any line in the traceback to the corresponding file and line, opening the file if necessary. 3. Search unopened files (grep) for a string or re. 4. Display grep output in a window that lets you jump from any 'hit' to the corresponding file and line, opening the file if necessary. Emacs. Emacs is the coolest tech editor out there, by far; however, the very nature of Emacs (which makes it the coolest) is also unfortunately the very thing that sucks about it... highly configurable (&extensible), highly complex, intricately complicated; especially for novices. The OP is looking for an "IDE-like" interactive environment, because he is "uncomfortable" with IDLE. IDLE is THE choice, however ---precisely because IDLE is clean, elegant, and most importantly "simple". It is simple to understand, and it is even simpler to use effectively... even for novice pythonics. IDLE is straight-forward. As Terry pointed out, IDLE is very useful and functional. And in the modern python world is also very stable (IDLE used to get a black eye because it had snags early-on). Today IDLE works, has great features, and actually helps new users get on-board with Python. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: need help with this code please fix it or at least tell me what im doing wrong
On 5/28/14 12:32 PM, funky wrote: import pygame <== a very good place to start import random import time import sys http://www.pygame.org/wiki/tutorials My hourly rate is $295.00 /hour, w/2hour minimum, happy to send you a contract of engagement and a copy of my document of understanding. Sign both and arrange payment through paypal and I'll give you a call --- the first 30 minutes consultation is free. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: How to run script from interpreter?
On 5/28/14 2:44 AM, onlyvin...@gmail.com wrote: On Friday, January 19, 2001 1:22:23 AM UTC+5:30, Rolander, Dan wrote: What is the best way to run a python script from within the interpreter? What command should I use? try using execfile(filename) What type of script? python? bash? tcl? other? If you want to use python as a shell-glue you can try using system. >>> from os import system >>> def ([parms]) >>> blah blah >>> rc = system(">> When you call function_name within the python interpreter your_script_name will be called using system. OTOH, if you are wanting to run a python script within the interpreter then just import the names you want from your_script.py file and then call the name... like main, forinstance. >>> from my_script import main >>> main([parms]) Within your_script.py define a main function: def main([parms]): blah blah return rc - OTOH, just write the script.py file (top down procedural) and then import it: >>> import my_script.py marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
On 5/28/14 5:43 AM, Sameer Rathoud wrote: I am currently using python 3.3 With python I got IDLE, but I am not very comfortable with this. Please suggest, if we have any free ide for python development. I tend to agree with Chris & Steven on this... a good gnu/linux desktop is the best IDE (debian, xfce, terminals galore) Early in my unix career I learned VI (now VIM) and find that for most editing jobs (even from remote) --- can't be beat. OTOH, I would highly recommend getting comfortable with IDLE; especially if you're using 3.3+ / the modern IDLE works, is stable, and has many advantages over just a tabbed editor. It is highly configurable, simple and elegant, not to mention that its written against tkinter with pure python. Today I'm using IDLE for python development almost exclusively. You no doubt are getting comfortable with python's indentation code blocking delimiting anomaly. IDLE helps with that. Yes, you can use tabs, but you shouldn't (for several reasons, I spare you). Typically the indentation is 4 spaces; IDLE handles this for you automatically (mostly) and allows the 4 spaces to be reconfigured. The only really irritating aspect of IDLE which I had to get used to was that the interactive REPL provides no way to clear the screen. Its debugging capabilities (and undo levels) more than make up for that tiny small snag. You will come to appreciate the class path browser, recent files, &c. The default highlight colors are well chosen (they may be changed) and the window size and fonts may be changed. I think IDLE looks good. Its clean, clear, and functional. I guess what I'm encouraging you to do is be patient with IDLE until you get a grip on it. There's more to it than meets the eye, at first. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Advice for choosing correct architecture/tech for a hobby project
On 5/22/14 1:54 PM, Aseem Bansal wrote: I am working on a hobby project - a Bookmarker{snip} hi, no django is not really the correct tool-set. Django is for server-side content management, but who knows, you might come up with a great hack (I don't want to discourage you). But, a straight python trimmed down app would probably be better... what led you to django? It seems from your descriptions, which don't make sense by the way, that you are attempting to create your own 'browser' within your app (web api) and you want to use a standard browser (like firefox or chrome) to 'front-end' the apps bookmarks. So, your app needs to be able to read your browser's bookmarks file. Browsers most certainly can read http:// https:// file:// etc. (and many more). Your api may not be able to read local file:// urls, but I'm skeptical about that (most web api(s) have no trouble with file:// either). Provide some more info, somebody will help. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is horribly slow compared to bash!!
On 5/22/14 5:54 AM, Chris Angelico wrote: Figure some of you folks might enjoy this. Look how horrible Python performance is! http://thedailywtf.com/Articles/Best-of-Email-Brains,-Security,-Robots,-and-a-Risky-Click.aspx > From TDWTF: Most of the interesting physics analysis code here is based on a framework using Python scripts for setup and configuration which then calls native analysis code, that usually is implemented in C++. This goes back to a previous discussion about about Julia (couple weeks back) and IPython. What these guys at CERN need is the dynamic duo of IPython and Julia. (its gonna be fabulous, seriously) Or, Julia by itself. The whole point of the Julia project was to bring the whole dynamic scripting, glue, lightning fast FORTRAN or C++ specialty code, into one screaming fast package that "does it all". Of course that's a pipe dream, but they are getting very close. And, if they pull off the IPython | Julia match-up thing, man, its going to change the way technical computation is handled for decades to come. Back to the TDWTF post, what a hoot. Ok, you heard it there first people, Python is dead everyone learn BASH.:-pheh marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: daemon.DaemonContext and logging
On 5/22/14 10:28 AM, wo...@4amlunch.net wrote: On Saturday, April 10, 2010 11:52:41 PM UTC-4, Ben Finney wrote: pid = daemon.pidlockfile.TimeoutPIDLockFile( "/tmp/dizazzo-daemontest.pid", 10) Has pidlockfile been removed? (1.6) -brian "Have you released the inertial dampener?" :) -- https://mail.python.org/mailman/listinfo/python-list
Re: All-numeric script names and import
On 5/21/14 8:46 AM, Chris Angelico wrote: # from 1 import app as application # Doesn't work with a numeric name application = __import__("1").app Is there a way to tell Python that, syntactically, this thing that looks like a number is really a name? Or am I just being dumb? (Don't hold back on that last question. "Yes" is a perfectly acceptable answer. But please explain which of the several possibilities is the way I'm being dumb. Thanks!) If you have a script that is self-programming (producing sequenced, numbered scripts 1.py 2.py 3.py) then why not just prefix an alpha character a1.py a2.py a3.py ? Otherwise, are you just pulling our chain?:) On the other hand, if you open IDLE and then open the 1.py module (yes, that's a dumb name) and then click run--> run module it will import and run... assuming 1.py contains some valid python code. Why must you have a numbered script? You're just pulling someone's chain, right? marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Bug in Decimal??
On 5/15/14 3:45 PM, pleasedonts...@isp.com wrote: Please take a deeper look at my second post. Try the same but this time set the precision to 4000, 8000 or whatever you need to convince yourself there's no error propagation, yet there's a 4 in the middle that shouldn't be there. See for yourself! I've tested on all platforms I know of and confirmed it. The wrong digit occurs in the middle of the number. Propagation error would have a bad digit near the end, and garbage after that. Here there's a perfect sequence of numbers, but with one single digit changed in the middle of the number. No error propagation in a series expansion can do that. I generated a table of 1000 numbers, one correctly generated and one with mpdecimal. Then I did a diff of both files and it's horrible. The difference is all over the place, sometimes as high as digit 500 (out of 2000). Almost every result has the bad digit somewhere. The bad digit moves around a lot, from about position 500 to 2000. All other digits are correct, and in a 2000 digit sequence is hard to spot the difference (I used the visual diff tool that comes with TortoiseSVN or TortoiseGit). I think there's a bad pointer or something that's rounding the wrong digit. You cannot possibly have 1999 correct digits and only 1 changed on every number if it was propagation error. I'll follow up directly with the author of mpdecimal, as this is somewhat serious on a language that's so widely used as python. But please test it and confirm, am I seeing ghost digits? I don't believe it. I've been running converging series to hudreds of thousands of decimal places (not only on different platforms, but on different BigFloat systmes, Jullia, BC, Decimal with pdeclib) and I'm not seeing the 'middle of the number' error you are talking about. I ran π to over 100,000+ digits and compared between BC and Python Decimal with pilib pdeclib and both compared correct; also compared correct to the on-line standard. S... not sure ... I can work on this some this weekend (comparing between Julia BigFloat and Python Decimal with pdeclib and see. I'm very skeptical at this point. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Everything you did not want to know about Unicode in Python 3
On 5/13/14 1:18 AM, Chris Angelico wrote: instead of yelling "LALALALALA America is everything" and pretending that ASCII, or Latin-1, or something, is all you need. ... it isn't? LALALALALALALALALA :)) -- https://mail.python.org/mailman/listinfo/python-list
Re: Simple Function Decorator Sample Snippet
On 5/13/14 12:54 AM, Steven D'Aprano wrote: I don't think that this idea is original to you :-) I'm pretty sure many people have come up with the idea of a decorator that just announces when it runs and when it is called. I know I have :-) oh, absolutely... every piece of that thing comes from somebody (about six somebodies to be exact) what makes it unique is that its compressed, in the right order (I think), and 'without' extraneous gibberish that confuses the whole dang thing. People keep independently inventing this because it's an obvious, and easy to understand, example. Nicely done. Its obvious until you get to the @charater. In fact its taken so obviously by *everyone* that no one actually gets it explained without eight pages or twelve steps of something until its all confused. I tried to run your code, but every line is quoted with a > which causes a syntax error. Was there a reason you quoted the snippet? Yes, because depending on your interface the code can get mangled (the indentation thing breaks). the quoted paste seems to avoid this mostly with the downside that the quote characters need to be striped from the py file. by the way, any suggestions are welcome regarding that too... there doesn't really seem to be a good way to share code on the group consistently. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran (Was: The "does Python have variables?" debate)
On 5/13/14 12:48 AM, Steven D'Aprano wrote: On Tue, 13 May 2014 00:33:47 -0500, Mark H Harris wrote: there has to be a value add for scientists to move away from R or Matlab, or from FORTRAN. Why go to the trouble? FORTRAN works well (its fast too), and there are zillions of lines of code cranking away on huge linear arrays. Enter Julia... over the next ten years; seriously. Because of the value adds! Why?, glad you asked. Enter self modifying code for one. Self-modifying code is a nightmare inside the head of a Lovecraftian horror. There's a reason why almost the only people still using self- modifying code are virus writers, and the viruses they create are notorious for being buggy. no, no, no... Steven don't think self-modifying (sorry I even used it) think meta-programming. Python accomplishes this kind of thing using Class and function decorations (sort-uv). Take a look at the video presentation of the concept before you turn it into a Friday the Thirteenth virus writing horror flick... its going to be as powerful as lisp was supposed to be with the user friendliness of python-like code-ability but 'without' the forced indentation rule (Julia uses 'ends' and white-space means nothing). marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Everything you did not want to know about Unicode in Python 3
On 5/13/14 12:10 AM, Rustom Mody wrote: I think the most helpful way forward is to accept two things: a. Unicode is a headache b. No-unicode is a non-option QOTW(so far...) -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran (Was: The "does Python have variables?" debate)
On 5/12/14 3:44 AM, Alain Ketterlin wrote: multiple-dispatch (i.e., dynamically testing types, converting to a common type, and selecting the version of sqrt to use). That's probably more than the time it takes to actually perform the computation, a bit like what happens with x+y on integers with Python, where only a fraction of time is spent on adding integers. When you are doing scientific computation, this overhead is unacceptable, because you'll have zillions of computations to perform. I'm still trying to sort that out. I have not tested this yet, but it looks like Julia is fully dynamic (yes it has types too), and it does parallel processing at its core, so the zillions of computations are being handled all at once, depending on how many processors|cores you have. Julia provides a way to make things fast: typing. If you provide explicit types, the dynamic typing part obviously disappears, and the overhead is removed. Julia is dynamic (depending on how far you want to go with that) but what makes it fast is the JIT. It is almost accomplishing C/C++ and FORTRAN speeds (even though dynamic) because it is compiling on-the-fly. But then, you're not too far from Fortran, or C/C++. Right. Again, this is really about the design goals and the JIT. The following code will produce over 100,000 digits of π (pi) in less than 2 seconds on a low-end processor, like my mac mini dual core 2Ghz: {snip} You seem to be discovering the power of the libraries that are behind all this (MPFR in that case)... Yes, and more+ Gnu GMP & MPFR are not new to me, but the wrapper and repl are ! I am just realizing the power behind the libraries in this context, but I am very impressed with the functionality wrapped around the Gnu stuff... the interface is quite nice. But, like lisp, Julia's internal structures are lists, so, it can create and modify its own code on-the-fly. [...] Sorry, I was comparing to Fortran, and it's use in scientific computing. Self modifying code is totally irrelevant there. no, no, no... there has to be a value add for scientists to move away from R or Matlab, or from FORTRAN. Why go to the trouble? FORTRAN works well (its fast too), and there are zillions of lines of code cranking away on huge linear arrays. Enter Julia... over the next ten years; seriously. Because of the value adds! Why?, glad you asked. Enter self modifying code for one. The influence of Lisp|Scheme is potentially huge here. For scientific computing the reason for making the switch is that the array functions being calculated now in FORTRAN can be calculated (as fast) but more elegantly with Julia; because the language has the ease of use of Python, the stats of R, the array capabilities of MatLab (on steroids) and the almost speed of C/C++ (all together in one package). There is enough of a value add in this language to make FORTRAN users (also NumPy SciPy) take notice. Yes, its on a development curve right now (very much beta); but very much out there with some serious capability --- right now. It will take some time to mature, but I really think this language has the potential to be around for a long long time. There needs to be some serious bench marking on the parallel processing model, and there needs to be some uptake on the user base to find out what 'they' really need from it, but I think this dev group is on the ball. (maybe a little too smart for their own good, we'll see) I noticed from the MIT videos http://julialang.org/blog/2013/03/julia-tutorial-MIT/ from a year ago that the project has grown with leaps and bounds... but, there is very much an intellectual edge here vs. a usability edge... um, the computer scientists are still very much in control. It might be time for a larger user group to get involved with the development direction, and code base. I agree with D'Aprano that languages come and go. But I think Julia is different... like Python... for the scientific community; seriously. And, if they really are working together with certain Python group(s) to merge technologies, this could be big for years to come! I'm excited about it. Don't get me wrong anybody, I'm still a Pythonista! :) marcus -- https://mail.python.org/mailman/listinfo/python-list
Simple Function Decorator Sample Snippet
hi folks, I've come up with a simple snippet that intends to explain the concept of decorations without an article (for on app help), while being succinct and concise, while not being overly complicated. Does this work? I have another one coming for args, similar, if this works... comments appreciated. thanks. # BEGIN FUNCTION DECORATOR SIMPLE # # define the function decorator (wrapper function) def enter_exit(f): def new_f(): print("entering", f.__name__) f() print(f.__name__, "exited !", end="\n\n") return new_f # the above "function decoration" takes a 'callable' as an argument #and returns a 'callable' new function that is used to #replace the original function (function is decorated), which #adds functionality to the original function being decorated ... # define the original function def f1(): print("inside f1()") # replace the original function (above) with the new decorated #'wrapped' function using the function decoration 'enter_exit'... f1 = enter_exit(f1) # (OR) accomplish the same thing with decoration lines as below: # functions wrapped with decoration lines syntax (annotations) #as below, accomplish the same 'decoration' as above #by using some 'syntactic sugar' to accomplish same ... @enter_exit def f2(): print("inside f2()") @enter_exit def f3(): print("inside f3()") # demo the new 'decorated' functions f1() f2() f3() # END FUNCTION DECORATOR SIMPLE ## -- https://mail.python.org/mailman/listinfo/python-list
Re: a better way to operate svn with python(better than pysvn)?
On 5/12/14 10:16 AM, xs.nep...@gmail.com wrote: > {nothing} huh? -- https://mail.python.org/mailman/listinfo/python-list
Re: Everything you did not want to know about Unicode in Python 3
On 5/12/14 8:18 PM, Steven D'Aprano wrote: Unicode is hard, not because Unicode is hard, but because of legacy problems. Yes. To put a finer point on that, Unicode (which is only a specification constantly being improved upon) is harder to implement when it hasn't been on the design board from the ground up; Python in this case. Julia has Unicode support from the ground up, and it was easier for those guys to implement (in beta release) than for the Python crew when they undertook the Unicode work that had to be done for Python3.x (just an observation). Anytime there are legacy code issues, regression testing problems, and a host of domain issues that weren't thought through from the get-go there are going to be more problematic hurdles; not to mention bugs. Having said that, I still think Unicode is somewhat harder than you're admitting. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran (Was: The "does Python have variables?" debate)
On 5/11/14 11:10 PM, Mark H Harris wrote: On 5/11/14 10:10 PM, Dave Angel wrote: On 05/11/2014 02:54 PM, Mark H Harris wrote: >julia> sin(BigFloat(π/4)) > 7.0710678118654750275194295621751674626154323953749278952436611913748 > 20215180412e-01 with 256 bits of precision That answer doesn't seem to come anywhere near 256 bits of precision. Using Python 3.2, >>> x=70710678118654750275194295621751674626154323953749278952436611913748 >>> x*x 4999693838300213161705693483516931249926767981110058185818806614907837502621065882204197129973479350206261627418690991407504 Not that this is surprising, but it does make a terrible ad for how great Julia is. Dave, you get the golden egg! I expected D'Aprano to catch it first! Yes, BigFloat does the same dumb thing Python's Decimal does. π/4 is not a BigFloat, and BigFloat simply makes the 16 digit float into a 256 bit float, the sin of which will only be 16 digits accurate (more or less). It has nothing to do with the language (Python vs. Julia) it has to do with the way the BigFloat is formed. So let's fix it by forming the π constant as a BigFloat constant: >julia> n = BigFloat(1) >1e+00 with 256 bits of precision >julia> π = atan(n/5)*16 - atan(n/239)*4 >3.141592653589793238462643383279502884197169399375105820974944592307816406286198e+00 >with 256 bits of precision >julia> S = sin(π/4) >7.07106781186547524400844362104849039284835937688474036588339868995366239231051e-01 >with 256 bits of precision >julia> S * S >4.57e-01 >with 256 bits of precision Having said that, the accuracy was not my point; in the first place. My point is that the sin() function is built-in, takes standard floats (32 bit, 64 bit, 128 bit) and BigFloats of arbitrary precision (and does something meaningful with it). Let's take a look at Python Deciaml: >>> === RESTART === >>> from decimal import * (first I have to import) >>> from math import * (than I have to import again) >>> π Traceback (most recent call last): File "", line 1, in π NameError: name 'π' is not defined (whoops, don't know π ) >>> π=4*atan(1) (let's create it) >>> sin(Decimal(π/4)) 0.7071067811865475 (whoops sin doesn't do Decimals) >>> from pdeclib import sin (let's get a sin that does do Decimals) >>> sin(Decimal(π/4)) Decimal('0.707106781186547502751942956217516746261543') >>> S=sin(Decimal(π/4)) (Whoops has the same problem as BigFloat) >>> S**2 Decimal('0.499969383830021316170569348351') >>> Now let's fix it: >>> >>> from pdeclib import d >>> n=d(1) >>> from pdeclib import * >>> n=d(1) >>> π=atan(n/5)*16 - atan(n/239)*4 >>> S=sin(π/4) >>> S**2 > Decimal('0.50') >>> Also not bad, but slower.;-) marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran (Was: The "does Python have variables?" debate)
On 5/11/14 10:10 PM, Dave Angel wrote: On 05/11/2014 02:54 PM, Mark H Harris wrote: >julia> sin(BigFloat(π/4)) > 7.0710678118654750275194295621751674626154323953749278952436611913748 > 20215180412e-01 with 256 bits of precision That answer doesn't seem to come anywhere near 256 bits of precision. Using Python 3.2, >>> x=70710678118654750275194295621751674626154323953749278952436611913748 >>> x*x 4999693838300213161705693483516931249926767981110058185818806614907837502621065882204197129973479350206261627418690991407504 Not that this is surprising, but it does make a terrible ad for how great Julia is. Dave, you get the golden egg! I expected D'Aprano to catch it first! Yes, BigFloat does the same dumb thing Python's Decimal does. π/4 is not a BigFloat, and BigFloat simply makes the 16 digit float into a 256 bit float, the sin of which will only be 16 digits accurate (more or less). It has nothing to do with the language (Python vs. Julia) it has to do with the way the BigFloat is formed. So let's fix it by forming the π constant as a BigFloat constant: >julia> n = BigFloat(1) >1e+00 with 256 bits of precision >julia> π = atan(n/5)*16 - atan(n/239)*4 >3.141592653589793238462643383279502884197169399375105820974944592307816406286198e+00 >with 256 bits of precision >julia> S = sin(π/4) >7.07106781186547524400844362104849039284835937688474036588339868995366239231051e-01 >with 256 bits of precision >julia> S * S >4.57e-01 >with 256 bits of precision Not too bad... marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran (Was: The "does Python have variables?" debate)
On 5/11/14 1:59 PM, Chris Angelico wrote: julia> prec=524288 524288 julia> with_bigfloat_precision(prec) do println(atan(BigFloat(1)/5)*16 - atan(BigFloat(1)/239)*4) end Would it be quicker (and no less accurate) to represent pi as atan(BigFloat(1))*4 instead? That's how I originally met a pi-calculation (as opposed to "PI = 3.14" extended to however much accuracy someone cared to do). No. Simple experiment will show you. The atan(x<=1) will converge faster. For 524288 bits atan(1) formula converged in 3 seconds, and Machin's formula atan(x<1) converged in 2 seconds. Where it becomes very apparent is 10K and 100K or above. Also, the difference is much more noticeable in Python than in Julia, but it is there no-the-less. But here is the cool part: what if your π function could be broken down into three very fast converging atan(x<1) functions like this one: > pi = 24*atan(1/8) + 8*atan(1/57) + 4*atan(1/239)(Shanks used this) ... and then, you have julia send each piece to a separate processor|core (it does this at its center) and they converge together, then julia pieces them together at the end. Then things get incredibly faster. -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran (Was: The "does Python have variables?" debate)
On 5/11/14 12:05 PM, Alain Ketterlin wrote: Julia is Matlab and R, Python, Lisp, Scheme; all rolled together on steroids. Its amazing as a dynamic language, and its fast, like lightning fast as well as multiprocessing (parallel processing) at its core. Its astounding, really. Hmmm... Its number concept is unified, What exactly is unified? There is no implicit promotion between primitive types and BigInt/Float. The built-in math functions (extensive, by the way) just work, and they work consistently the way you might expect across types. Consider sqrt(): > julia> sqrt(-1+0im) > 0.0 + 1.0im > julia> sqrt(complex(-1)) > 0.0 + 1.0im > julia> sqrt(2) > 1.4142135623730951 >julia> sqrt(2.0) > 1.4142135623730951 > julia> sqrt(BigFloat(2.0)) >1.414213562373095048801688724209698078569671875376948073176679737990732478462102 >e+00 with 256 bits of precision >julia> with_bigfloat_precision(1024) do > sqrt(BigFloat(2.0)) > end >1.414213562373095048801688724209698078569671875376948073176679737990732478462107 >03885038753432764157273501384623091229702492483605585073721264412149709993583141 >32226659275055927557999505011527820605714701095599716059702745345968620147285174 >18640889198609552329230484308714321450839762603627995251407989687253402e+00 >with 1024 bits of precision You'll notice that I did not need to import anything to use sqrt(), and sqrt() takes all types and does something meaningful with them. The following code will produce over 100,000 digits of π (pi) in less than 2 seconds on a low-end processor, like my mac mini dual core 2Ghz: >julia> prec=524288 >524288 >julia> with_bigfloat_precision(prec) do > println(atan(BigFloat(1)/5)*16 - atan(BigFloat(1)/239)*4) > end The scientific and transcendental functions (built-ins) just work. The coder sets the precision in floating point bits, and the functions just work --- at that precision. Nothing needs to be imported, and special functions are not necessary. The maths are unified, and they are fast; yet, the coder has the flexibility and ease of python coding, with a very useful repl. But, like lisp, Julia's internal structures are lists, so, it can create and modify its own code on-the-fly. Unicode characters above code point \u00A0 can be used as symbols, and constants ARE their unicode characters: >julia> sin(π/4) > 0.7071067811865475 >julia> cos(π/4) > 0.7071067811865476 >julia> sin(BigFloat(π/4)) > 7.0710678118654750275194295621751674626154323953749278952436611913748 > 20215180412e-01 with 256 bits of precision marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Free vs proprietary (was Re: NumPy, SciPy, & Python 3X Installation/compatibility issues)
On 5/10/14 6:35 PM, Chris Angelico wrote: Instead, what we have is a world in which Python can be used to write closed-source software, LibreOffice Writer will happily open a Microsoft Word document, Samba communicates with Windows computers, libc can be linked to non-free binaries, etc, etc, etc. Yes, that means the open source community can't wield its weight against closed-source. Its not open source that's the big deal. Its freedom that's the big deal. Many have latched onto open source because its efficient. But that was the wrong reason to latch onto it! Libre software is the ONLY way to fight NSA GCHQ. Libre software is the ONLY way to ensure privacy and interoperability --- its a huge paradox. Libre software and libre Internet are absolutely paramount for the 21st century. I may not live to see it fully, but I have absolutely no doubt that its coming. There is going to be one whopping paradigm shift Chris. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran (Was: The "does Python have variables?" debate)
On 5/10/14 8:42 AM, Roy Smith wrote: Ars Technica article a couple of days ago, about Fortran, and what is likely to replace it: http://tinyurl.com/mr54p96 uhm, yeeah! 'Julia' is going to give everyone a not so small run for competition; justifiably so, not just against FORTRAN. Julia is Matlab and R, Python, Lisp, Scheme; all rolled together on steroids. Its amazing as a dynamic language, and its fast, like lightning fast as well as multiprocessing (parallel processing) at its core. Its astounding, really. Its number concept is unified, BigFloats are by default arbitrary precision with full scientific and transcendental functions built-in, everything complex just works, and did I mention its fast? The bench-marks are within 2x of C across the boards; makes Matlab look like a rock, and is well ahead of python (NumPy SciPy) for technical computing. Julia is still very much beta in my opinion but its maturing fast. Its open free (libre) and cross platform and did I mention it flatout screams? Not only will it replace FORTRAN completely if things keep progressing, but also Matlab, Mathematica, NumPy, & SciPy (and others). Keep your eye on her fellows. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Free vs proprietary (was Re: NumPy, SciPy, & Python 3X Installation/compatibility issues)
On 5/10/14 11:16 PM, Nelson Crosby wrote: I also believe in this more 'BSD-like' view, but from a business point of view. No one is going to invest in a business that can't guarantee against piracy, and such a business is much less likely to receive profit (see Ardour). Don't get me wrong - I love free software. It's seriously awesome to see what a community can do. But at the same time, some people want to earn a living from writing code. That is simply not possible without proprietary software. That's just the point... The twenty-first century is not going to be about making money by moving bits around a network, nor about making money writing code. It is going to be about making money|living (whatever that means) by leveraging free networking (think libre box) and by leveraging free (as in libre) software and libre software engineering. In other words, no longer are coders going to make a living writing proprietary code; rather, coders are going to make a living leveraging their skill writing libre software (in the specialized problem domain needing their resources --- free agents, have skill, will travel, or connect). So, I go to work for some technical scientific research outfit that just got a federal grant for yadda yadda... and I bring in my toolkit|toobox (julia, haskell, python, C++ &c whatever) and I make a living coding within that specialized domain. I don't market the app (& they don't either). The killer app in the 21st century IS the unix distro (gnu/linux), and the toolbox is (mine, or yours). We are going to stop purchasing software across the board, and we are going to share. In the process we are going to make our livings with our skills, services, innovations towards specialized problem domains through leveraged technical specialty, and by working together to better the whole. This is already occurring. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: NumPy, SciPy, & Python 3X Installation/compatibility issues
On 5/10/14 12:07 PM, esaw...@gmail.com wrote: 4. In the long run, would it be better to use UNIX instead of Windows, if I were to use Python for all of my research? I concur with Chris and Stefan. The *nix model is faster, cleaner, and more secure. I prefer gnu/linux, but mac os/x is also quite nice. Simply change... or, if you like, just switch. I moved away from OS/2 and Windows in the late 1990s and have never looked back; no reason to use Windows what-so-ever. You're question (in the long run) is important, to be fair. Because, in the short run there will be some learning curve, and there will be some conceptual porting as well as code porting to handle; not to mention apps. All critical apps from Windows, and most day-to-day apps have free libre counter-parts in the unix world, and most everyday apps have gnu counter parts and others. Just switch. Proprietary code and systems will not survive the 21st century, you can be sure of that. 'We' can never allow another Microsoft to rule again; not google, nor canonical, nor oracle, nor anyone else. 'We' must have net neutrality, and software idea patents must die (world-wide). Go gnu/linux Go Python Go away, Microsoft, go away Oracle. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Values and objects
On 5/9/14 10:05 PM, Rustom Mody wrote: Likewise python's name-spaces go almost all the way to first-classing variables but not quite as Marko discovered when locals() looks like a dict, waddles like a dict but does not quack like a dict. QOTWeekEnd -- https://mail.python.org/mailman/listinfo/python-list
Re: The � debate
On 5/9/14 8:34 PM, Steven D'Aprano wrote: Nobody seems to complain about using the term "assigment" in relation to Python, despite it meaning something a bit different from what it means in some other languages, so I don't see anything wrong with using the term "variable" with the above definition. What differences in assignment are you referring to? In any case, the issue is whether or not the misunderstanding leads to confusion or not. That's really the question --- regarding the issue of 'variable' and assignment. The term 'variable' (assignment) typically means: the LHS (name) of an assignment where the coder is placing some 'type' (RHS) into a chunk of memory statically defined, or dynamically malloc'd. With Python the assignment term 'variable' means: the LHS (name) is now associated with (bound to) an object (RHS), regardless whether the object already exists or whether the object is being constructed, nor what kind or type the object may be. The coder is not concerned with the memory model, nor address, nor reference. So for Python variable names are object handles. I've been reading through the python docs today (the FAQ mostly) and noting that python has variables BIG TIME as far as the docs go. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Abstractions [was Re: Pass variable by reference]
On 5/9/14 7:58 PM, Steven D'Aprano wrote: {snip} at which point we're now talking about a concrete, physical description of the process, not an abstraction. There really is a bottom-most turtle that holds up all the rest.) hi Steven, heh... yup, there really is a bottom-most turtle (and who created him?) Intel (often copied, never exceeded) :)) -- https://mail.python.org/mailman/listinfo/python-list
Re: The “does Python have variables?” debate
On 5/7/14 8:27 PM, Steven D'Aprano wrote: In almost every other language you know A and B each "contain" by reference (and almost always by static type) macTruck. But NOT python. Nor Javascript, Ruby, Perl, PHP, Lua, or (I think) Lisp or Java. To mention only a few. I think it is easy to exaggerate the difference between Python and "almost every other language". Python's name binding model is very common amongst dynamically typed languages, and there are many dynamically typed languages. Then we don't need a discussion. Why are new Python coders 'always' confused by this question of variable (name value) vs. {name: object} model of Python? The reason I suggest is that the person has a preconceived idea of what 'variable' means, and they then attempt to apply their conception of variable on to Python in some way ending in a surprise. We need a way to speak about Pythons name object model to avoid this confusion. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Pass variable by reference
On 5/7/14 8:31 PM, Chris Angelico wrote: On Thu, May 8, 2014 at 4:11 AM, Mark H Harris wrote: And we must never forget that CPython's underpinnings, uhm C, uses variables, C ones... (never mind) Be careful of this one. It's utterly irrelevant to your point, and may be distracting. I could implement Ook in Python; does that mean that Ook has a socket library? Clearly not. Probably. Although, its turtles all the way down. C is a better way to write asm code (more efficient, less lines of code, better abstraction, way more readable). wow, use C to build Python. Python is requires way less lines of code than C, better abstraction, more efficient, and way more readable. Now, down under the stack of turtles, we are still placing values into memory boxes (variables) although we are getting there from a very abstract and indirect way; but its turtles all the way down from a certain point of view. On the other hand, if we are coming at this from the highest level (strictly pure Python coding) all we care about is abstracting the real world by constructing objects which interact with the rest of the world and with themselves. We are no longer interested in modeling memory (although that does happen somewhere) --- what we are interested in is modeling life and the objects of life. The mechanism of {name: object} is so far above the simple name -- value pair mechanism we used to call 'variables' (boxes holding native types) that we really need some new name for the concept... is a Python 'name' a variable. No. Then what is it? If we call it a variable (what ever we mean by that) someone is going to be confused as they try to write Python code. What should it be referred to? Someone said it is silly to say that Python has no variables. I disagree. We need a way to speak about Python variables that highlights the distinctions which create for new coders (and some old ones too) the misunderstandings and surprises which spark a debate like this one. As someone else pointed out its a both|and. I suppose I agree. OTOH: A = 7 Seven is not a C integer native type, and A is not a static int variable. 7 is an object, and the name A is bound to it. What shall we call A ? object nomenclature : A is objname, objhandle, OBH. or just handle. I think we need to stop calling it a variable. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Values and objects [was Re: Pass variable by reference]
On 5/7/14 8:08 PM, Steven D'Aprano wrote: In Python, all values *are* objects. It isn't a matter of choosing one or the other. The value 1 is an object, not a native (low-level, unboxed) 32 or 64 bit int. Unlike C# or Java, there is no direct language facility to box native values into objects or unbox objects to native values. Yes. In the context of the rest of this discussion, this one point is just one of the many reasons why it is not helpful to think of Python's {name: object} relationship as 'variable -- value'. Typically when I think about variables (particularly from the past, say Pascal, Basic, C, Fortran, Cobol &c) I am thinking about modeling memory is some way where the variable (some naming convention) is a value handle or value pointer of some chunk of memory (by type | length) --- where I am creating a 'box' into which I may place something (usually some native type). When I think of Python's 'variables' (and I don't believe Python has variables) I am now thinking of a naming convention (for handling objects) where I am not the least interested in modeling memory for native types. I am instead interested in modeling the real world (or subset) with object abstractions. I am no longer interested in creating a 'box' into which I may place some type. I don't need variables any longer for that purpose. What I want is some very efficient naming convention whereby I can handle the objects I am constructing (for whatever abstract purpose). If a programmer new to Python thinks in terms of 'variables' from C or Pascal, or Fortran or Basic, they will run into surprises when it comes to handling the {name: object} idea in Python. In fact, most of the time this debate comes up it is precisely that the new user is finding Python's 'variables' aren't behaving correctly or finding that they are not able to 'do' what they used to do (say) with C's variables. It really comes down to the definition of 'variable' and whether the language in question is modeling memory, or modeling object abstractions. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: The “does Python have variables?” debate
On 5/7/14 4:15 PM, Marko Rauhamaa wrote: That's why I always try to say “Python doesn't have variables the way you might know from many other languages”, Please elaborate. To me, Python variables are like variables in all programming languages I know. Python currently does not allow me to obtain the "address" of a variable, but that doesn't make me think of Python variables any differently. Here is the difference... in almost every other language you know. A = macTruck B = A In almost every other language you know A and B each "contain" by reference (and almost always by static type) macTruck. But NOT python. A --> {macTruck} <-- B In almost every other language you know there is some kind of binding table (name reference to type/length) and BOTH A and B are bound to data in memory macTruck... and usually its a different place in memory! NOT python. No doubt you may use A and B in python the way other people use their variables in their language... but it MEANS something different. marcus -- https://mail.python.org/mailman/listinfo/python-list
right click cut copy past context menu in IDLE in 3.4
Greetings, thanks to the folks who worked on the right click context menu in IDLE for python 3.4! Nice job. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: idle glitch while building python 3.4 from sources
On 5/7/14 1:19 PM, Ned Deily wrote: If the Python build (the "make sharedmods" build step) can't successfully build the _tkinter extension module (because, for example, it couldn't find the Tk headers or libraries), the build step already reports that it could not build _tkinter. hi Ned, where is the report? Its not obvious; where does one look for this step output? I did not see it on my build attempts last night. I'm assuming its in one of the logs. What would be nice is a final (at the end) report listing of the modules|extention modules that did not get built (for whatever reason). As an aside, the ensure pip is disabled for some reason (I'm reading the pep, and such, which is confusing). There isn't much to go on from the build listing about ensure pip either. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: The “does Python have variables?” debate
On 5/7/14 10:48 AM, Jerry Hill wrote: I think it's rather silly for someone to insist that python doesn't have variables. On the other hand, I think it can be useful to point out that python variable aren't like C variables, and that thinking of python variables as having two parts -- names and values -- really can help people who are struggling to learn the language. I know it certainly helped me. But here is the rub: BASIC also has -- names and values --; although they are in a variable table, and they refer to memory not objects. C is the same, basically. ehem. ... a name bound to an address that references a chunk of memory (by type) of a certain length. ... and we could go on. But, Python's names bound to objects not only doesn't behave like the 'variables' mentioned above, they provide for serious side-effects for the programmer if the coder does not think of them properly as names bound to objects. And that means surprises. So, when anyone points out that Python does not have variables, but rather Python has names bound to objects... they are being most helpful. As I pointed out earlier, I think the better approach would be to find positive language for helping new folks understand Python's beautiful heart, than the relatively negative language of stating Python has no variables. -- https://mail.python.org/mailman/listinfo/python-list
Re: Pass variable by reference
On 5/6/14 6:46 PM, Chris Angelico wrote: Is there really a fundamental difference between languages in which that is equally valid syntax and does exactly the same thing? No. And from that standpoint, python has variables. I know, because I thought about python's 'variables' as variables for quite sometime before I learned about the 'beautiful heart of python'. AND I used them as variables too, ignorantly of course. And we must never forget that CPython's underpinnings, uhm C, uses variables, C ones... (never mind) Here is the rub. What happens when a newbie (me, some some years ago) gets a strange 'surprise' when trying to use python's variables: Given that A is bound to 3.5, and B is also bound to another object 3.5: A == B True A is B False ... and now they want to know why if A == 3.5 and B == 3.5 does (A is B) come up False? This is just one of a dozen 'different' kinds of examples. And the answer is the same, Python does not have variables, Python has names bound to objects. The cleanest clearest explanation of Python's (name-->object) model is 'the beautiful heart of python' in Mark Summerfield's Programming Python 3. I think we should STOP saying that python does not have variables (like that horse hasn't been beaten before, to death) but instead explain Python's beautiful heart. uhm, "What you have been using in ignorance as a simple variable is, uhm, a 'name' bound to an object... and these are its strange properties: ... enumerated... marcus -- https://mail.python.org/mailman/listinfo/python-list
idle glitch while building python 3.4 from sources
hi folks, I got bit again trying to build python3.4 from sources (mea culpa, of course). The symptom is everything (except ensure pip) builds, installs, and runs fine with the small baby problem that IDLE will not run (-tkinter isn't even there) even though tcl/tk 8.5 is loaded and running. This happens to me from time to time when I'm building on a new machine (this one is a T-61 ThinkPad running Mint Maya). The solution is simple, if I could remember it. The dev packages for tcl/tk have to be installed or the python build will not self-configure for tkinter. Make sure these are installed before ./configure; make; sudo make install : tcl8.5-dev tk8.5-dev That is assuming that the dev packages (as well as tcl/tk) are installed to the standard places on my distro (they were). We can point the build at another location in setup.py, or with ./configure options, or with make options (complicated). Why am I posting? Glad you asked. I am wondering if the build scripts could be updated slightly by prompting the user for IDLE preferences; and|or by being more robust about determining where tcl/tk lives, and|or by explicitly telling the user in the logs (or preferably right there on-screen) that the dev header packages for tcl/tk are not installed, and|or by refusing to build until the tcl/tk dev packages are installed, and|or refusing to build unless the user explicitly opts to bypass tkinter and build python anyway. I know its my own fault (because I should just know this) but I got to wondering about others who 'might not know' about the tcl/tk dev packages and would be scratching their heads about why _tkinter is missing and IDLE won't run, although tcl/tk is installed correctly and running? Just a suggestion... marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Pass variable by reference
On 5/6/14 3:31 PM, Ned Batchelder wrote: On 5/6/14 12:42 AM, Gary Herron wrote: This gets confusing, but in fact the most accurate answer is that Python does not have "variables", so there is no such thing as passing "variables" by reference or any other method. Python *does* have names bound to values, but that's a very different thing. If necessary, you may consider that the *values* are passed by reference. This meme bugs me so much. Python has variables. They work differently than variables in C. In fact, they work by having names bound to values. What does the word "variable" mean. Think BASIC variables. You can set them, you can reset them, you can delete them, you can change them. ... because they are variable. Python has names bound to objects... some of which you may not change. Once the name is bound to an object you may bind it to another object, but you may not change it, nor may you change the object it is bound to if the object is immutable. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: (question) How to use python get access to google search without query quota limit
On 5/6/14 2:27 PM, Mark Lawrence wrote: will u please send me the code that you write. actually i'm trying to learn use of google search api but i'm not getting so please mail me the code. Sure but it's USD 1,000 cash or cheque made payable to the Python Software Foundation, backed up by bankers card. QOTW -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
On 5/1/14 10:53 AM, William Ray Wing wrote: I’m surprised no one has jumped in to defend/tout the Dietzgen slide rules (which I always thought were the ultimate). Mine (their Vector Log Log) is one of their Microglide series that had teflon rails inserted in the body and is still totally stick-free after nearly 50 years. http://www.marksmath.com/slide-rules/img/ed-n1725.jpg The above link is nice for the Dietzgen Microglide. It doesn't have the CF/m DF/m scales, but is a very nice Vector type log log. Most of my drafting equipment from the same era was Dietzgen; it looked like the previous video post featured the same/ My dad has one of these; but I can't get him to part with it yet... marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
On 5/1/14 8:47 PM, Dennis Lee Bieber wrote: On Wed, 30 Apr 2014 22:54:21 -0500, Mark H Harris declaimed the following: My high school '74 was the last class to learn the slide-rule using the Sterling (we paid a deposit to use the school's). Since calculators had started to appear, I never did get formal training in slide-rules. The LL scales still require me to glance at a guide book... I regret that I never risked the $35 dollars when my college bookstore was closing out the slide-rule display. They had the top Post bamboo laminate rule at half price. At the time I'd bought an HP-25 calculator [they phased out the HP brand a year or two later -- apparently RPN was too confusing]. Half way through my senior year the HP-65 "gold key" calculator was available for about $800.00 dollars. That sucker was programmable and had magnetic strip recorder for off-loading storage... but I digress. We all had our priorities... one guy bought one; the rest of us bought cars. ---for about the same price too! I used my rule well into college; the first calculator I owned was the Rockwell 63R --- "The Big green numbers, and the little rubber feet!" marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
On 5/1/14 9:06 PM, Dennis Lee Bieber wrote: The N4-ES and the N4-T (mine) are essentially the same rule. The N4-ES on the site is yellow (mine is white) and the site rule indicates Picket & Eckel Inc. (that's where the E comes from) Also the the ES states Chicage Ill USA where the T states Made in USA. ES was for "Eye-Saver" -- the yellow background vs the bright white of the other models. Actually, I think you're right. I never used the a yellow rule, but I will say that my N4-T never caused me any eye-strain (but I was younger then). The N4-T was a flat white also... very easy to read. I really don't know what all the 'yellow' hype was all about. -- https://mail.python.org/mailman/listinfo/python-list
Re: Running scripts from shell / IDLE in windows
On 5/1/14 11:02 AM, Mark H Harris wrote: file hello.py=== def Hello(parms list): whatever whatever From IDLE: import hello hello.Hello([1, 2, 3, 4]) Sorry, almost forgot, if you 'run' the module hello.py (with the IDLE run dropdown) then the 'hello' name will not be in the namespace... just enter: Hello(parms) Here is another example: ===hello.py=== def Hello(myname): out = "hello, " + str(myname) print(out) == import hello hello.Hello("mark") hello, mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Running scripts from shell / IDLE in windows
On 5/1/14 10:34 AM, s71murfy wrote: I am trying to run the simple helloworld script from the IDLE shell. I want to pass it arguments. Please can you give me the syntax to do it? There are several ways to do this, depending on your preferences and goals. Is the helloworld script the tk version? In which case have the script put up input dialog boxes... The python docs pages are very clear about input parameter i/o and may give you some help, if you're building a script that you want to launch from a terminal, or startup... What I do with my IDLE scripts is embed to embed a Main function (or call it Hello(). So, I import hello, then call hello.Main(parms). or, hello.Hello(parms) example file hello.py=== def Hello(parms list): whatever whatever From IDLE: import hello hello.Hello([1, 2, 3, 4]) marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
On 4/30/14 10:56 PM, Paul Rubin wrote: There is a nice Javascript simulation of the N4-ES here: http://www.antiquark.com/sliderule/sim/n4es/virtual-n4es.html Thank you! The N4-ES and the N4-T (mine) are essentially the same rule. The N4-ES on the site is yellow (mine is white) and the site rule indicates Picket & Eckel Inc. (that's where the E comes from) Also the the ES states Chicage Ill USA where the T states Made in USA. The only technical difference is the T scale (which is folded-expanded on both). On the ES the T scale is listed only once in the margin. On the N4-T the T scale is listed 'twice'!-- once for each part of the fold. Well, that gives (2) scales instead of one --for T... increasing the number of scales on the rule from 34 to 35... if I'm counting right. Which makes the N4-T more valuable... supposedly. I don't plan are parting with it... till I croak, then my son (who is studying engineering this fall) will inherit it... heh he won't have a clue what to do with it ! The simulated rule on the site above is fabulous... especially if viewed from a large wide LED. ... simply fabulouso/:) marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
On 4/30/14 7:02 PM, Dennis Lee Bieber wrote: Sterling? Snort. K&E was the way to go. Absolutely, snort. I still have my K&E (Keuffel & Esser Co. N.Y.); made of wood... (when ships were wood, and men were steel, and sheep ran scared) ... to get to the S L T scales I have to pull the slide out (turn it over) and reinsert it. You're right, the CF and DF scales are missing, but the A B scales have the π symbol where it should be (more or less). Mine is the 4058 C model, and you're right... has maths equivalents and conversions printed on the back... I've misplaced the Sterling, but I'm fairly sure it was a deci-trig log-log model. My high school '74 was the last class to learn the slide-rule using the Sterling (we paid a deposit to use the school's). I returned my Sterling to the teacher at year-end and got my deposit back. They are all probably in an old card-board box in the basement. I should ask. In the last 15-20 years I've added NIB versions of Faber-Castell 1/54 Darmstadt, Pickett N-803-ES Dual-Base Log-Log, Pickett Cleveland Institute of Electronics N-515-T, and a pair of Sama&Etani/Concise circular pocket rules (models 200 and 600). I received my Pickett Model N4-T Vector-Type Log Log Dual-Base Speed Rule as a graduation | birthday gift... off to college with a leather cased slip stick hanging from my belt (I was invincable). Mine had the CF/m DF/m scales also -- folded at 2.3, the loge of 10 with π where it should be (more or less). Copyright 1959... that baby was the king of slide rules... I pull it out from time to time, just for warm feelings. Heh... I wonder if the VEs would have noticed the CIE rule had lots of electronics formulas on the back, if I'd taken it to the exam session where I passed both General and Amateur Extra tests. I couldn't take a calculator -- all of mine were programmable. But the slide-rule I took was just about as perplexing to the VEs. I carried my slide rule to my general class exam as well. The VE inspected it to be sure that certain stuff was not written in pencil between the scales! True story. Its not required today, of course, but I can still send/receive at 20 wpm. marcus W0MHH '73 -- https://mail.python.org/mailman/listinfo/python-list
Re: Slightly OT - using PyUIC from Eclipse
On 4/30/14 8:50 PM, Steven D'Aprano wrote: On Thu, 01 May 2014 01:49:25 +0100, Steve Simmons wrote: On 30/04/2014 23:49, Fabio Zadrozny wrote: And that's about where I stopped reading. Post as quote: I'm trying to set up a new dev environment using Windows 7; Eclipse (Kepler); Python 3.3; PyDev and PyQt 5 and I've hit an issue getting PyUIC to generate a python Qt class from within Eclipse. I'm using the following setup process (from Google Groups) modified to match my PyQt5 configuration: 1. Click Run -> External Tools -> External Tools Configurations ... 2. In the resulting dialog, click 'New' icon in the top left 3. Under 'Name' put 'PyUIC' 4. Under 'Location' enter 'C:\Program Files\Python\2.5\Python.exe' or the path to your Python executable (probably C:\Python25\Python.exe) 5. Under 'Arguments' enter '"C:\Program Files\Python\2.5\Lib\site- packages\PyQt4\uic\pyuic.py" "${resource_loc}"' substituting the path to your PyQt4 installation - be sure also to include the double quotes 6. Change to the 'Common' tab and check 'File' under 'Standard Input/ Output' and enter '${resource_loc}.py' 7. Change to the 'Build' tab and uncheck 'Build before launch' 8. Change to the 'Refresh' tab and check 'Refresh resources upon completion' 9. Click 'Apply' then 'Run' and I'm getting the following traceback: Traceback (most recent call last): File "D:\Development\Python33\Lib\site-packages\PyQt5\uic\pyuic.py", line 28, in from .driver import Driver SystemError: Parent module '' not loaded, cannot perform relative import I tried this on Qt4 a week or so ago and it worked OK but Qt5 is giving me an error message, so I guess I've either mis-transcribed or there's a difference in the directory structure betwee PyQt4 & PyQt5. I'm more interested to learn how to read the traceback (insightfully) and track it to the source of the problem, although it would be good to have it working too!! Steve Simmons PS Also posted to PyQT list. Cheers -- https://mail.python.org/mailman/listinfo/python-list
Re: First attempt at a Python prog (Chess)
On 4/30/14 8:28 AM, Chris Hinsley wrote: On 2013-02-15 05:05:27 +, Rick Johnson said: First of all your naming conventions suck. You've used the "interface" style for every function in this game so i can't /easily/ eyeball parse the /real/ interface functions from the helper functions -- and i'm not going to even try, because i don't read ugly code! Try to learn the Python style guide as soon as you can (In particular pay attention to naming conventions): Wow, such vitriol for such a simple bear to cope with ! Maybe Papa bear would like to try some humility ! This was my very first Python prog, and my first chess prog and my attempt to learn somthing about Generators ! Do youtself a favour and leave the Python comunity for the good of the language ! Chris Chris, you might want to try another list: https://mail.python.org/mailman/listinfo/tutor The folks on this list are friendly, but tough. They are not generally arrogant, but many of them are experts (or core python developers) and most of them are worth listening to. The list mentioned above is for folks who are learning python and who have basic questions or want basic clarifications. (they are gentler too):) marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Designing a network in Python
On 4/30/14 9:57 AM, varun...@gmail.com wrote: I don't know how to do that stuff in python. Always a good time to learn. Let the database do the work for you; try not to re-invent the relational database wheel. Access the database via python-sql: https://pypi.python.org/pypi/python-sql/ marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Significant digits in a float?
On 4/29/14 3:16 PM, Adam Funk wrote: "A man pitches his tent, walks 1 km south, walks 1 km east, kills a bear, & walks 1 km north, where he's back at his tent. What color is the bear?" ;-) Who manufactured the tent? marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: how to build and install multiple micro-level major.minor versions of Python
On 4/29/14 1:53 PM, Brent S. Elmer Ph.D. wrote: I would rather have a way to have the build and install process install to the micro level. I agree. On the other hand, is there really a special need to thoroughly test against a micro level. I have the latest 2.6, 2.7, 3.2, 3.3, 3.4 ... there might a critical reason for splitting hairs, but honestly, probably not. -- https://mail.python.org/mailman/listinfo/python-list
Re: how to build and install multiple micro-level major.minor versions of Python
On 4/29/14 1:53 PM, Brent S. Elmer Ph.D. wrote: Yes, I already use --prefix to build to a different path. I guess that is what I need to do but I would rather have a way to have the build and install process install to the micro level. example only, Use --prefix /usr/local/2.7.6/ Use --prefix /usr/local/2.7.2/ &c., Both of the 2.7 installs will be 2.7, but it doesn't matter because they will (each one) be installed under a different micro level. ... works great. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: App segmentation fault (CentOS 6.5)
On 4/23/14 1:08 PM, Reginaldo wrote: I have a GUI app that is written using wx. When I run it on CentOS 6.5, the following error messages are displayed and the app closes: Only fails on CentOS ? I use an idle thread in my application. Is your CentOS launching idle with -n switch ? What is different on this setup ? Have you tried more than one CentOS system? marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Soap list and soap users on this list
On 4/17/14 12:58 PM, Joseph L. Casale wrote: Seems the soap list is a little quiet and the moderator is mia regardless. Are there many soap users on this list familiar with Spyne or does anyone know the most optimal place to post such questions? Read first. You can try : > http://spyne.io/docs/2.10/ > https://pythonhosted.org/Soapbox/ google is our friend. There are lots of links in the above, tutorials, &c. Also, you might do some additional searching on PyPI... lots of SOAP packages (simple object access protocol). Spyne uses SOAP. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: networking question: 2-way messaging w/o wireless modem config?
On 4/17/14 11:20 AM, haiticare2...@gmail.com wrote: I have a Raspberry Pi board with a wireless usb modem on it. I wish to be able to message 2-way with the board from across the internet, without having to open ports on the wireless modem. Is there a way to do this? I have been looking at udp, but imagine that a udp packet is allowed in, but not out? The amount of data transmission I want is very small, maybe lt 30 bytes. The answer depends on how you setup your wireless modem | router. There are many ways to set this up depending on your project goals. If you're trying to setup a sniffer (well, just don't do that, its not nice). If you were trying to setup a micro server on my network (for instance), well, you couln't, because I don't permit the outgoing connection without authorization and port (actually, same is true for incoming connections. I would have to setup auth and port for you to connect your Pi as a micro server on my wireless network. Most public access points are blocked (peer to peer) too (if they're smart). For legitimate non trivial setups (not experiments) you want to control the connection with auth and ports. A word of caution about udp. If the data you are sending is contained in one datagram (one packet), then no problem; however, if you are sending multiple packets over the WAN it can be a big problem because the upd in|out does not guarantee correct packet ordering. Is there a python question in here somewhere? marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 4/15/14 4:02 PM, Terry Reedy wrote: https://python3wos.appspot.com/ That's what I thought. Its really about getting the super-power wall fixed up; everything else will fall in place. I do think that Guido might be positioning himself as an enabler, of sorts. I can see extending through 2015... I think extending support for 2.7 through 2020 is ridiculous. The trouble with the super-power wall is that if Guido extends t much, the super-powers will slack off because the dead-line appears further out than it really is. All I'm saying is a little pressure might be a good thing. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 4/15/14 2:37 PM, Novocastrian_Nomad wrote: On Tuesday, April 15, 2014 12:32:14 PM UTC-6, Mark H. Harris wrote: Can you site the announcement? Thanks http://hg.python.org/peps/rev/76d43e52d978?utm_content=buffer55d59&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer Thanks, guys. I am noticing the call to 2.8 from time to time (blogs). All along I have been seeing the reluctance to migrate to 3.x as either stubborn or lazy; or both. I don't think so any longer. Seems like the reluctance to migrate stems from dependencies. Is there a list of primary dependencies ? As an example: Is 'twisted' a dependency? ie., twisted does not support 3.x consequently 'I' can't port my stuff to 3.x because 'twisted' isn't there yer. There are others, gevent, maybe. Has anyone taken an inventory of dependencies that must support 3.x before other code(s) can be ported? Maybe there could be an on-line questionnaire regarding perceived dependencies? marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
On 4/14/14 2:32 PM, Phil Dobbin wrote: On a related note, Guido announced today that there will be no 2.8 & that the eol for 2.7 will be 2020. Can you site the announcement? Thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: Language summit notes
On 4/11/14 11:02 AM, Chris Angelico wrote: It's almost now debatable whether you were metabaiting Steven into telling you off for trolling the resident troll... QOTW -- https://mail.python.org/mailman/listinfo/python-list
Re: python obfuscate
On 4/10/14 8:29 PM, Wesley wrote: Does python has any good obfuscate? Others have answered this well, but I thought I would give you another opinion, perhaps more direct. Obfuscation (hiding) of your source is *bad*, usually done for one of the following reasons: 1) Boss is paranoid and fears loss of revenues due to intellectual property theft. 2) Boss is ignorant of reverse engineering strategies available to folks who want to get to the heart of the matter. 3) Boss and|or coders are embarrassed for clients (or other coders) to see their art, or lack thereof. Sometimes this is also wanting to hide the fact that the product really isn't "worth" the price being charged for it?!? There really is no good reason to obfuscate your code. Currently our company wanna release one product developed by > python to our customer. But dont's wanna others see the py code. This is the age of open source in computer science. It is far better to develop a strategy and culture of openness. Everyone benefits; especially your customers. I recommend the GPLv3 license. I also advocate for copyleft. How to leverage openness for capital gain, you might ask? Answer: provide a value add. Its not just about your code, or your "product". It should also be about your service, maintenance, support, packing, manuals, news letters, &c. Deliberately obfuscating your code is a negative; please consider an alternative strategy. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Teaching python to non-programmers
On 4/10/14 10:54 AM, Lalitha Prasad K wrote: Dear List Recently I was requested to teach python to a group of students of GIS (Geographic Information Systems). Adults? ... what age ranges? Their knowledge of programming is zero. The objective is to enable them to write plug-ins for GIS software like QGIS and ArcGIS. Its a fabulous idea. Integrating disciplines is the correct approach to computer science education in my opinion. From day one (and yes I was there on day one) computer science knows nothing about the insurance industry, and underwriters know nothing about programming. The way to get these two groups together is to integrate comp sci education with underwriting. It would require them to learn, besides core python, PyQt, QtDesigner. So my plan is to teach them core python, PyQt, Qt Designer, in that order. A kind of "bottom up approach". Beautiful. But the students seem to feel that I should use "top down approach". That is, show them how to write a plug-in, then PyQt and Qt Designer and then enough of python so they can handle the above. The phrase "just enough python" is almost possible. I am working on a project I call SimplyPy that has this same goal in mind; but I'm not finished yet. But the idea is to boil the galaxy of python down to a small solar system with a couple of planets. If these cats are in their early twenties, no problem. If they really are "non programmers" it will be easier because they come to the table teachable. I would rather have twenty students "tabula rosa" than having one student who thinks they already know everything. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Teaching python to non-programmers
On 4/10/14 3:52 PM, pete.bee@gmail.com wrote: Do you get paid to be a jerk, or is it just for yuks? If the latter, you're not funny. Mark is the c.l.python resident margin police. Think of him as a welcome committee with an attitude. :) -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
On 4/9/14 12:52 PM, Chris Angelico wrote: People with a fear of threaded programming almost certainly never grew up on OS/2. :) I learned about GUI programming thus: Write your synchronous message handler to guarantee that it will return in an absolute maximum of 0.1s, preferably a lot less. If you have any sort of heavy processing to do, spin off a thread. heh very true. Any non trivial OS/2 GUI app required threads. We had a template at our shop that we gave to noobs for copy-n-tweak. It had not only the basics for getting the canvas on the screen with a tool bar and a button, but also the minimal code required to setup the thread to handle the button event (it was a database lookup in our case). -- https://mail.python.org/mailman/listinfo/python-list
Re: "Latching" variables in function
On 4/8/14 3:09 PM, Grawburg wrote: I have a N/O pushbutton that I want to "latch" a value to a variable when it's been pressed. I need button_value to become '1' when the button is pressed and to remain '1' until ... What do I use to 'latch' button_value? Philosophically speaking buttons don't latch. You push the button, an event is generated, and the call-back handles the event to do something in your project. You might try setting a global variable on the button-push event. Or, if I understand you, you might want to use a configurable, like a radio button or a check box, either of which are designed to be "latched". marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: [OFF-TOPIC] How do I find a mentor when no one I work with knows what they are doing?
On 4/8/14 2:07 AM, James Brewer wrote: I don't think that I have anything to learn from my co-workers, which saddens me because I really like to learn and I know that I have a lot of learning to do. Give it time. The first thing that must happen is relationship building. Initially its about being: faithful available interested teachable I've been employed as a software engineer for about eight months now and I feel like I haven't learned nearly as much as I should. compared to what Things I'm interested include contributing to both Python and Django, database design and data modeling, API design, code quality, algorithms and data structures, and software architecture, among other things. Find a project. Find something you are interested in, download the source, and study. Volunteer, and do a lot of observing. Basically, I want to be a better engineer. Where can I find someone willing to point me in the right direction and what can I offer in return? This list is a great resource. The folks here are tough, but friendly; the list is active, and those participating will teach you plenty. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 4/6/14 12:31 PM, Rustom Mody wrote: I think python wins because it (usually) lets people do their thing (includes but not limited to CS-research) and gets out of the way. To say therefore that it is irrelevant to the research is a strange inversion of its advantages. I think so too. I find python useful for modeling (prototyping) constructs that it [python interpreter] was not 'designed' to do. [Or simply just switch to C++ for 3 months and report back with the increment in your white-hair-count] Back in the day I used Rexx to prototype a new language idea, or a new computational technique. Today I use python for prototyping. From a CS standpoint I can use python for research in morphology because of the flexibility and extensibility of the namespace, and the easy ability to create new nouns and verbs through 'def' (as either function or generator) and the iterative process over data types like 'list' and 'dict'. I am playing with neural nets again, using python, and liking the fact that I can put my ideas into practice easily and python gets out of the way. I find it a great research language. I am surprised that others only see it as a problem solving tool. I have another question for y'all, is a function (particularly a generator) a noun or a verb? Does a function (or generator) 'do' something (based on name and parms) or does it 'return' something based on name and parms? Based on name and parms should a function (or generator) function as a noun, or function as a verb, or *both*? --or, are Classes nouns only, and all functions *are* verbs only? marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 4/4/14 4:53 AM, Steven D'Aprano wrote: > Python is not a computer-science-ey language. Really ? > It is of little or no > interest to computer scientists involved in the mathematics of > computation, ... you mean no one except me, then ? > or compiler-theory, or type-theory, or any of the other > academic disciplines under comp-sci. So, I understand as you say, that there are no academics using C python interpreter within the rubric of their particular comp sci discipline? none? anyplace? I am surprised. They might be surprised as well. You probably think the same is true of common lisp? then? Under the covers there are some striking similarities between the way lisp does things, and the way python does things. You know this, right? The python interpreter is actually an excellent computer science language (not only for education) because of its structure, data types, flexibility, and extensibility. It is an excellent research language. There seems to be a considerable difference of opinion as to 'what' comprises computer science; very interesting. Not only is C python interpreter an excellent research language, but the study of the Python language itself is of major interest for anyone who studies languages in general; ie., Lambda the Ultimate λ marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 4/4/14 4:53 AM, Steven D'Aprano wrote: Python is not a computer-science-ey language. Really ? It is of little or no interest to computer scientists involved in the mathematics of computation, ... you mean no one except me, then ? or compiler-theory, or type-theory, or any of the other academic disciplines under comp-sci. So, I understand as you say, that there are no academics using C python interpreter within the rubric of their particular comp sci discipline? none? anyplace? I am surprised. They might be surprised as well. You probably think the same is true of common lisp? then? Under the covers there are some striking similarities between the way lisp does things, and the way python does things. You know this, right? The python interpreter is actually an excellent computer science language (not only for education) because of its structure, data types, flexibility, and extensibility. It is an excellent research language. There seems to be a considerable difference of opinion as to 'what' comprises computer science; very interesting. Not only is C python interpreter an excellent research language, but the study of the Python language itself is of major interest for anyone who studies languages in general; ie., Lambda the Ultimate λ marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 4/4/14 4:53 AM, Steven D'Aprano wrote: Python is not a computer-science-ey language. Every programming language is interesting from a comp sci standpoint. Some are more useful for research; python is one of those. For what reasons do you disagree? marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 4/5/14 1:01 AM, Ben Finney wrote: Mark H Harris writes: On 4/5/14 12:02 AM, Ian Kelly wrote: A fork is undesirable because it fragments the community. I don't think "fear" or "panic" are the right words for it. Yes. I get that. So, you get that “fear” and “panic” are not the right words to characterise the undesirability Ian describes. Not so much. I 'get' his point about community fragmentation. I disagree that 'fear' is not the correct word. Its semantics, really, but the root is 'fear' of community fragmentation. This is something less than 'fear' as in terror, or fear as in irrational, or fear as in childish (or something like that). Did you use those words anyway, despite knowing they're not the right words to use? Often decisions are made within tension (fear) that the price of consequences will not warrant the effort, nor heroism. I believe that decisions should be made because "its the right thing to do," and not because, "if we force this too soon there will be a fork," kinda thing. Decision out of fear is not good. Conservative posturing within tension might be good, as long as its not carried out too far. Or did you think they were the right words to use, and now you've changed your position? I don't see where that happened, so I'm confused. You might be confused because you expect me to have a position. My opinions are often also floating on a continuum (just like everything else). I try to keep an open mind, consider all views, allow for the fact that I'm constantly learning and don't know everything, humble enough to know that others can teach me, and above all else willing to hold "truth" gently and humbly. Or do you still think they are the correct words to use, but now wish to distance yourself from that position? In Ian's case he may, in point of fact, be concerned for the fragmentation of the community and he might not be fearful; in which case fear would not be the right word for his concern. On the other hand, in point of fact, if Ian (or anyone else) fears the fragmentation of the community that he sees as the consequence of forking C python, then 'fear' would be the right word to use. Just say'n. I don't really have a position (as it were) to distance myself from, but I do have a concern about the perceived awkward conservative snail pace with regard to C python 3.x migration. I mean, its not about being slothful (nor anything like that) but it appears to be 'concern' for constituents (of one kind and another). That 'appearance' is in my view the 'fear' of consequence with a too-quick migration plan (its been way drawn out so far). I personally want python 3.3+ on my android devices. Well, QPython is stuck on 2.7.2 because why? Twisted does not fully work on 3.x yet. What's the solution? Get Twisted up to speed. (gevent is similar). Now, I don't think QPython will want to maintain a fork. I also don't think they will want to stay on 2.7.2 forever, because they will want security patches. They will eventually get up to speed when Twisted is ready. What I wish the C python community would do is to apply just a little pressure here so that the Twisted community is motivated to move a little faster. This is taking too long, and yes, I think the core devs are afraid of offending (or fragmenting) constituents. I might be wrong. This may seem trivial, but I'm trying to get a handle on what it is you mean to communicate, when your stated position in one message conflicts with your stated position only a few messages earlier. Very seldom is anything black & white. Always we entertain shades of grey and a panacea of color and multiple hues. Sometimes when we are thinking out loud (which is itself more than vulnerable) we may be interpreted as being contradictory. Often the contradiction is more or less a nuance as we're wrestling with our mental heuristics. Often my categories overlap, and sometimes those categories have weights that shift (or morph) as the discussion continues. Never are we thinking in a vacuum, and always we are being influenced and challenged by others viewpoints and nuanced opinions. *What position?* Its a little like quantum mechanics and the Heisenberg uncertainty principle--- the more you know about my position, the less you know about how I arrived at it; and the more you know about how I arrived at my position the less you will know about the locus of the position itself. Of course, being able to parse intention with nothing to go on except typed English words and without non verbals (oh the pain of it all) is at best a quandary fraught with foil and frustration; but none the less we persist. {shrug} marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 4/5/14 12:02 AM, Ian Kelly wrote: A fork is undesirable because it fragments the community. I don't think "fear" or "panic" are the right words for it. Yes. I get that. I think what is desired (just thinking out loud from my own vantage point) is a unified community, but also a foundation of perceived permanence. The PSF establishes this to a certain extend, as well the PEP process, and to some extent the communities willingness to support two interpreters. It looks like C python is here to stay; I can count on it for my projects years into the future. -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 4/4/14 11:49 PM, Chris Angelico wrote: On Sat, Apr 5, 2014 at 3:31 PM, Mark H Harris wrote: Its has always seemed to me that Java or C++ would be better suited to creating python. I wonder will C always be the standard canonical PSF python interpreter base language? Has the C python community considered making the standard base language Java or C++ ? what's the advantage of C++ over C? A Python interpreter needs to do broadly this: 1) Parse a text file into an abstract syntax tree 2) Compile the AST into bytecode 3) Execute the bytecode: 3a) Manage object lifetimes and garbage collection 3b) Perform lower-level calls 3c) Efficiently handle namespaces etc The only advantage of C++ over C is polymorphism, really. There are in my view only three reasons to even use C++: 1) the iostream library, and 2) polymorphism, and 3) operator overloading. If you need to do all three, then C++ is a really good candidate. I am still thinking about the concept of unifying Number; Number as a C++ abstract base class, and an entire Class hierarchy which carries through making *any* Number just work. The ability of the C++ compiler to construct and maintain the virtual function tables would be an advantage. Operator overloading (and maybe templates) would make C++ advantageous also. Guido told me that the modern C python is object oriented. Operator overloading is a big part of this. It seems to me that a modern object oriented language would best be implemented with a true object oriented base language, C++ rather than C. I have always questioned this, just curious why the decision for C was made--- historically, methodologically, and maybe scientifically. It would be tons of work, but maybe not as much as one might think, initially. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 4/4/14 11:40 PM, Chris Angelico wrote: If it's too much work to make the changes to move something from Python 2.7 to Python 3.3, it's *definitely* too much work to rewrite it in a different language. Totally, no doubt. There would have to be some strong other reason for shifting, especially since there's a 2to3 but not a PytoRuby. And forking is a pretty huge job; someone's gotta maintain it. I agree there, too. That's why I don't think anyone should worry about a new program, nor about a fork. Nobody really wants to fork a programming language, esp one like python. It takes an entire team of dedicated people to support it--- jut not worth trying to do that. What's more likely is that, once python.org stops maintaining Python 2.x at all, people will just stay on 2.7.9 or {snip} > After that, it'll be like running old versions of anything else: you weigh the cost of migrating to the new version against the risk of exploits if you don't move. It's that simple. Yup, totally agree. So, just do it. Probably after 3.4 will be the right time. Beats me. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 4/4/14 10:42 PM, Rustom Mody wrote: Computer-hobbyists and computer-professionals are quite different sets of people. I know its just a gut feel, and I know there are a lot of lurkers here too, but it seems that there are *way* more folks from the professional camp on comp.lang.python than otherwise. Do you have a gut feel for the % of hobbyists vs. professionals participating here? Are you aware That [people?] FORTRAN, COBOL, mainframes are still in use? Well, the S390 is still in use (running gnu/linux these days) and the z series machines from IBM. FORTRAN and COBOL have government (military) niche. I remember during the Y2K problem COBOL coders were working their butts off. There is a 2014 standard doc replacing the 2002 standard, believe. The last time I used FORTRAN IV was in about 1977, on the System360-44, but GNU still supports it, and as far as I know it still has a wide user group (mostly academic). I have it on my system here, but I don't use it. 1. Python is a fun language; its also a serious language A very serious language; yes, its fun too. 2. Python is not as old as FORTRAN and COBOL but at 20 years its not exactly young either It won't have its day until it becomes ubiquitous... and its coming! As the gnu/linux numbers continue to climb, more everyday is C python becoming ubiquitous. I'm hoping the ubiquitous version is C python 3.4+ 3. Its reached far because core-devs behave responsibly towards different constituencies I think its because the language is flexible, extensible, &powerful (batteries included), and is supported by a world-wide community of software engineers (both amateur and professional) who are committed to its development and adoption world-wide. The PEP process has had a lot to due with this (and not to ape the BDFL) it has had a lot to due with some Dutch genius.;-) However, knowing your user-base is certainly important. Its always a problem (any venue, any environment) to try to please everyone. Tough choices have to be made. The C python community does a pretty good job of this. Python-ideas and the PEP process are a unique and unparalleled strategy for enhancement. Very nice. Having said that, I do believe that the migration to C python3 has been too conservative. Nobody wants to maintain a fork, not really. I don't think its something anyone should be afraid of. Somebody should put a date on C python 3.4+ migration and cut off support for 2.7.x/ Its just an opinion. If 'Twisted' isn't ready for 3.x, well, they need to get ready. That's also just an opinion. marcus -- https://mail.python.org/mailman/listinfo/python-list