Re: Python 3 is killing Python
On 5/29/2014 12:03 AM, Steven D'Aprano wrote: On Wed, 28 May 2014 20:41:53 -0400, Terry Reedy wrote: Claim: Another great strength of Python 2 was that programs written in it would almost always run on the next version of Python without much alteration. True. True, but only because of the weasel-words "almost always", and "without much alteration". And for the record, for many (although not all) programs written in Python 2.7, it is still true that they will often run in Python 3 with little or no modification. Changes and removals of deprecated features (like old style classes) were put off until 3.0 (at the request of some of the noiser users). I am specifically thinking of int / int -> float, which Guido initially proposed for 2.5 after warnings in 2.3, 2.4. The idea of 3.0 with more breakage and 2to3 emerged during that discussion. That's a little unfair. Noisy users or not, Python Dev has always taken backwards compatibility seriously. Nevertheless, there have been some big changes to Python 2.x that *didn't* wait for 3.x to break backwards compatibility. A few examples that come to mind: - removing string exceptions for good in 2.6; - changes to the treatment in hex() of negative numbers; - the repr() of floats; - changes to the sequence of random numbers generated by the random number module (e.g. while random.random() is guaranteed to return the same sequence of values, random.choice is not); - removal of obsolete modules like bastion and rotor. Any and all of these things can break code that relies on them. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Forking PyPI package
On Thu, May 29, 2014 at 10:31 AM, Wiktor wrote: > I see few scenarios: > > 1) I'm trying to contact with original script's author, and send him my > propositions of changes in code. (Oh, one more thing: my code isn't > backward compatible, and I don't know Py2 that much to include all those > try/except, so it could be Py2+Py3 compatible). He decides, if he wants to > release it as Py3 only version, or combine it with his script and release > Py2+Py3 common version. > > 2) I'm not contacting with him, and I'm forking his project on GitHub >a) under the same name? - probably bad idea >b) under new name (e.g. py3pwdhash)? > Of course all credits about original author stay in code / setup.py. > > 2.1) After forking on GitHub, I'm creating new package on PyPI >a) under old name, but different version number, and new description? >b) under new name, to not confuse users? Unfortunately, you're not legally allowed to just fork it and make your own derivative work, because the original author hasn't put license terms on the project. As it's been posted on github, we can guess that the intention was probably for it to be open source, but your first action has to be to contact the author and ask about license. If you absolutely can't get in touch with him, the only option is to go back to the original protocol and manually reimplement it, completely ignoring this code. It's sad but true; some code dies because of a trivial thing like "Oops, I forgot to actually say that this is MIT-licensed". (At least, I can't see a license anywhere on github there. If you can find another copy of the same code somewhere else, posted by its author, and including a license, then your job is easier.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Forking PyPI package
Chris Angelico wrote: > If you absolutely can't get in touch with him, the only option is to > go back to the original protocol and manually reimplement it, > completely ignoring this code. It's sad but true; some code dies > because of a trivial thing like "Oops, I forgot to actually say that > this is MIT-licensed". > > (At least, I can't see a license anywhere on github there. If you can > find another copy of the same code somewhere else, posted by its > author, and including a license, then your job is easier.) Deep in the code (pwdhash / pwdhash.py.egg-info / PKG-INFO): Author: Lev Shamardin Author-email: shamar...@gmail.com License: BSD Still better to get in touch with the author, but he has actually stated the license albeit in the most minimal way possible. -- Duncan Booth http://kupuguy.blogspot.com -- https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
On Thu, May 29, 2014 at 9:12 AM, Rhodri James wrote: > On Wed, 28 May 2014 14:04:55 +0100, Steven D'Aprano > wrote: > >> My IDE is to have three GUI windows open: >> >> * A web browser for searching the Internet. Any browser will do, but I >> prefer Firefox. >> >> * A tabbed editor. I prefer kate (KDE 3 version, not KDE 4), but geany is >> also good. At a pinch gedit will do. kwrite is another good editor, but >> not tabbed, and it lacks some of the features of kate. >> >> * An xterm or console app, again with tabs. I like KDE 3's konsole, but >> any modern, configurable, tabbed console will do. > > > Interesting. I'm entirely the other way; while I'm perfectly happy to use a > tabbed browser, I find tabbed editors and tabbed consoles awful to use. I > want to have three different sections of code side by side on the screen for > comparison. I want to have half a dozen consoles all running different > things, all positioned so I can take in the state of those things at a > glance. I do not want to be wasting time flicking between this and that, > and relying on my relatively poor memory to cache all that information :-) > > Then again, I'm not as bad as one former colleague of mine. He reckons that > the main advantage of higher resolution screens is that he can tile more > 80x40 console windows on them. I'm half way in between. Tabbed web browser, tabbed editor, but all my terminals/consoles are untabbed. I don't use screen/tmux to have multiple consoles in one window, I use them to share a console between two systems (eg ssh to someone else's computer and let him/her watch what I'm doing). When I switch from terminal to terminal, I use their position and size to identify them (most of my terminal windows are 80x24; some are full screen; and if I'm working with avconv, I widen the window to about 110 or 120). Oh, and I use a tabbed MUD client, which (along with my editor) is pinned to all Xfce workspaces. But the web browser is Workspace 3 only. Not sure why I do that. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Forking PyPI package
On Thu, May 29, 2014 at 5:56 PM, Duncan Booth wrote: > Chris Angelico wrote: > >> If you absolutely can't get in touch with him, the only option is to >> go back to the original protocol and manually reimplement it, >> completely ignoring this code. It's sad but true; some code dies >> because of a trivial thing like "Oops, I forgot to actually say that >> this is MIT-licensed". >> >> (At least, I can't see a license anywhere on github there. If you can >> find another copy of the same code somewhere else, posted by its >> author, and including a license, then your job is easier.) > > Deep in the code (pwdhash / pwdhash.py.egg-info / PKG-INFO): > > Author: Lev Shamardin > Author-email: shamar...@gmail.com > License: BSD > > Still better to get in touch with the author, but he has actually stated > the license albeit in the most minimal way possible. Ah! There you go then. Excellent. In that case, the options I see are (in priority order): 1) Contact the author with your proposed changes, possibly with the actual code or possibly leaving that for later, for inclusion in the original project. 2) Ask the author if he's okay with you maintaining the Python 3 equivalent version as a separate project, under the same name. 3) If you can't get in touch with the author, just maintain that Py3 version, but maybe under a different name to avoid accidental confusion. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
Sameer Rathoud wrote: > On Wednesday, May 28, 2014 5:16:41 PM UTC+5:30, Greg Schroeder wrote: >> > > Please suggest, if we have any free ide for python development. >> >> >> >> Anything that writes text is fine. >> >> I recommend the standard text editor for your OS (Notepad if you use >> >> Windows, Textedit on Mac, whatever is on your GNU/Linux distro by >> >> default) unless you know exactly what you don't like about it. >> >> >> >> Greg > > Right now I am looking for ide on windows 7 platform. > > Actually, I shouldn't say this, But I am bit use to intellisense and > on go warnings and error and my text editor (Notepad) doesn't provide > me that feature . If you are used to Visual Studio then you could try PTVS. I have no experience of it, but http://pytools.codeplex.com/ > PTVS is a free, open source plugin that turns Visual Studio into a > Python IDE. > > PTVS supports CPython, IronPython, editing, browsing, Intellisense, > mixed Python/C++ debugging, remote linux/MacOS debugging, profiling, > IPython, Django, and cloud computing with client libraries for > Windows, Linux and MacOS. > > Designed, developed, and supported by Microsoft and the community. -- Duncan Booth -- https://mail.python.org/mailman/listinfo/python-list
Re: daemon thread cleanup approach
On Thu, May 29, 2014 at 11:20 AM, Carl Banks wrote: > Most threads have cleanup work to do (such as deleting temporary directories > and killing spawned processes). > > For better or worse, one of the requirements is that the library can't cause > the program to hang no matter what... This ma y be a fundamental problem. I don't know how Windows goes with killing processes (can that ever hang?), but certainly you can get unexpected delays deleting a temp dir, although it would probably require some deliberate intervention, like putting your %temp% on a remote drive and then bringing that server down. But believe you me, if there is a stupid way to do something, someone WILL have done it. (Have you ever thought what it'd be like to have your swapfile/pagefile on a network drive? I mean, there's acres of room on the server, why waste some of your precious local space?) So you may want to organize this as a separate spin-off process that does the cleaning up. That way, the main process has completely ended, but the cleanup daemon is still busy. And if you're going to do that, then the easiest way, IMO, would be to have your worker threads be themselves in a separate process; your library passes work across to this other process via a pipe or socket (this being Windows, that would have to be a TCP socket, not a Unix domain socket, but a named pipe would also work), and when the pipe/socket connection is broken, the other end knows that it should clean up. That way, you get to clean up perfectly even if the process terminates abruptly (segfault, system kill, whatever), although possibly delayed until the system notices that the other end is gone. ChrisA (sometimes I feel I suggest TCP/IP sockets the way Grant Imahara suggests building a robot... enthusiastically and maybe too often) -- https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
Duncan Booth wrote: > Sameer Rathoud wrote: > >> On Wednesday, May 28, 2014 5:16:41 PM UTC+5:30, Greg Schroeder wrote: >>> > > Please suggest, if we have any free ide for python development. >>> >>> >>> >>> Anything that writes text is fine. >>> >>> I recommend the standard text editor for your OS (Notepad if you use >>> >>> Windows, Textedit on Mac, whatever is on your GNU/Linux distro by >>> >>> default) unless you know exactly what you don't like about it. >>> >>> >>> >>> Greg >> >> Right now I am looking for ide on windows 7 platform. >> >> Actually, I shouldn't say this, But I am bit use to intellisense and >> on go warnings and error and my text editor (Notepad) doesn't provide >> me that feature . > > If you are used to Visual Studio then you could try PTVS. I have no > experience of it, but http://pytools.codeplex.com/ > >> PTVS is a free, open source plugin that turns Visual Studio into a >> Python IDE. >> >> PTVS supports CPython, IronPython, editing, browsing, Intellisense, >> mixed Python/C++ debugging, remote linux/MacOS debugging, profiling, >> IPython, Django, and cloud computing with client libraries for >> Windows, Linux and MacOS. >> >> Designed, developed, and supported by Microsoft and the community. > > I'm just watching the video from that page. It is impressive just how much of intellisense they have working with PTVS: for example inside a function doing 'find all references' on a local variable that happens to be a method passed in to the function shows you all def lines for methods that are passed as parameters. There's a heck of a lot of type inferencing going on. -- Duncan Booth -- https://mail.python.org/mailman/listinfo/python-list
Re: Forking PyPI package
On Thu, 29 May 2014 02:31:56 +0200, Wiktor wrote:
> So, what should I do?
Thanks guys, you're right. I'll contact the Lion. ;-)
Yes, I forgot to mention that pwdhash.py was published under BSD licence.
Without knowing that I wouldn't even consider forking it.
--
Best regards, Wiktor Matuszewski
'py{}@wu{}em.pl'.format('wkm', 'ka')
--
https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
On 28.05.2014 12:43, Sameer Rathoud wrote: Hello everyone, I am new to python. 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. Seems like not too many other people on this list share my opinion, but let me just say that IDLE is a nice and sufficient (for my purposes) IDE. If you're used to eclipse, then stick with it, but I prefer IDLE over any text editor although admittedly some of its keyboard shortcuts are unusual choices. Cheers, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Python alternative to Google Groups
On 29/05/2014 06:06, Tim Golden wrote: On 28/05/2014 22:54, Steven Clift wrote: If you are looking for an open source alternative between Google Groups and Mailman, I wanted to share: http://groupserver.org It has recent release and new design. Aargh. I hate it when someone does that: posts something so interesting that I want to dive in and start investigating, when I *know* I'm already overcommitted to everything else I'm already doing! QOTW On a more serious note, it does look interesting and it would be great to have a credible alternative to promote for people who tend towards GG. Needs to someone to do the setup / config / management though. (Hence my frustrated comment above). It would certainly save me, and I'm sure others, a great deal of frustration. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Wed, May 28, 2014 at 10:49 PM, Steven D'Aprano wrote: > On Wed, 28 May 2014 14:58:05 -0500, Larry Martell wrote: > > > On Wed, May 28, 2014 at 2:49 PM, Paul Rubin > > wrote: > > > >> Larry Martell writes: > >> > Somthing I came across in my travels through the ether: > >> > [1]https://medium.com/@deliciousrobots/5d2ad703365d/ > >> > >> "Python 3 can revive Python" https://medium.com/p/2a7af4788b10 > >> long HN comment thread: https://news.ycombinator.com/item?id=7801834 > >> > >> "Python 3 is fine" http://sealedabstract.com/rants/python-3-is-fine/ > >> > >> OT: wow that medium site is obnoxious. > >> > >> > > No company that I work for is using python 3 - they just have too much > > of an investment in a python 2 code base to switch. I'm just saying. > > Is that Python 2 code base aimed at Python 2.7 or 2.6? Or 2.5? Or 2.4? Or > even 2.3? Or all of the above? > One company is using 2.5. Another has been using 2.6 but they are moving to 2.7 because it's required by a package they need. I think that will be the driving force for companies to upgrade. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python alternative to Google Groups
On 29/05/2014 11:57, Mark Lawrence wrote: > On 29/05/2014 06:06, Tim Golden wrote: >> On a more serious note, it does look interesting and it would be great >> to have a credible alternative to promote for people who tend towards >> GG. Needs to someone to do the setup / config / management though. >> (Hence my frustrated comment above). >> > > It would certainly save me, and I'm sure others, a great deal of > frustration. After a quick skim of the feature list etc. it's not actually clear to me that it can operate as a proxy for, eg, a Mailman list. As a standalone group list manager it's clearly worth looking at. But as a means of allowing current GG users a similary way of accessing the existing mail.python.org lists... I'm not so clear. TJG -- https://mail.python.org/mailman/listinfo/python-list
Re: Command prompt not shown when running Python script with subprocess on Windows
On 28/05/2014 21:46, ps16thypresenceisfullnessof...@gmail.com wrote: > > Thank you for your replies. I tried what you suggested in your second > post and it worked. > > That was actually a mistake in the app_list.xml file. As you said: > > %ProgramFiles%\LibreOffice > 4\program\swriter.exe "C:\Users\Timothy\Documents\myfile.odt" > > should instead be: > > "%ProgramFiles%\LibreOffice > 4\program\swriter.exe" "C:\Users\Timothy\Documents\myfile.odt" > > I just made that file as a sample, and didn't actually test it. > > My "shlex dance" has nothing to do with that, though. A few examples > from the interactive interpreter should explain why I am doing it (I > used raw strings in these examples so that I wouldn't need to escape > the backslashes): > import shlex shlex.split(r'C:\Users\Timothy\Documents\Python\myscript.py') > ['C:UsersTimothyDocumentsPythonmyscript.py'] shlex.split(r'C:\\Users\\Timothy\\Documents\\Python\\myscript.py') > ['C:\\Users\\Timothy\\Documents\\Python\\myscript.py'] shlex.split(r'C:\Users\Timothy\Documents\Python\myscript.py', posix=False) > ['C:\\Users\\Timothy\\Documents\\Python\\myscript.py'] > > The first example shows that single backslashes get removed. The > second example shows that double backslashes are preserved intact. > The third example shows that if posix=False, single backslashes are > converted to double backslashes. None of these three behaviors are > acceptable to correctly parse a Windows path, which is why I am doing > what I am to work around the issue. Well I certainly learnt something there! An additional test, which you don't show is this: >>> import shlex >>> shlex.split(r'"c:\users\timothy\documents"') ['c:\\users\\timothy\\documents'] >>> In other words, given the double-quoted data in your XML file, I think it will do the right thing by Windows backslashes. YMMV, I suppose. TJG -- https://mail.python.org/mailman/listinfo/python-list
Re: Python alternative to Google Groups
Ah, I wasn't referring to Google Groups newsgroup/usenet connection, but if one wanted to host open source based online groups themselves that are similar to the web experience with Google Groups overall. While folks who just want a mailing list are well served by Mailman, Sympa, and others ... for our organization we need to compete with user expectations from Facebook Groups more and more. We'll we can't compete on features, but we can make our web experience simple and more visually pleasing so the web-centric users stick with us. This is an example neighborhood forum we host - http://e-democracy.org/se - our reality is that if someone creates a Facebook Group in the same local community, we see sharing types migrate there due to the visual experience and baked in mobile sharing options. So our investments in this open source tool could benefit those who see the need to host online communities on their own site where they can innovate further. Thanks! Steve ᐧ On Thu, May 29, 2014 at 6:38 AM, Tim Golden wrote: > On 29/05/2014 11:57, Mark Lawrence wrote: >> On 29/05/2014 06:06, Tim Golden wrote: >>> On a more serious note, it does look interesting and it would be great >>> to have a credible alternative to promote for people who tend towards >>> GG. Needs to someone to do the setup / config / management though. >>> (Hence my frustrated comment above). >>> >> >> It would certainly save me, and I'm sure others, a great deal of >> frustration. > > After a quick skim of the feature list etc. it's not actually clear to > me that it can operate as a proxy for, eg, a Mailman list. As a > standalone group list manager it's clearly worth looking at. But as a > means of allowing current GG users a similary way of accessing the > existing mail.python.org lists... I'm not so clear. > > TJG > > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran (Was: The "does Python have variables?" debate)
In article , Mark H Harris wrote: >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. I know now how to interpret your posts. Using "incredible" for a mere factor of at most 3. Balanced views are more convincing. Groetjes Albert > -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran
In article <8761l9pi3n@elektro.pacujo.net>, Marko Rauhamaa wrote: > >Producing an effective JIT for Python seems like a formidable challenge >but not impossible in principle. After all, the developer *could* >provide that static typing information in, like, 99.9% of the code. That >would be feat worthy of a Millennium Technology Prize. It would be like >having the cake and eating it, too. I'm totally flabbergasted by comments like this. I always thought that the real point of JIT was that it can take advantage of type information that is not available until runtime. If it can infer that something is an integer, just before entering a loop to be executed millions of times, that should be a big win, not? > > >Marko -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran
alb...@spenarnc.xs4all.nl (Albert van der Horst):
> I always thought that the real point of JIT was that it can take
> advantage of type information that is not available until runtime. If
> it can infer that something is an integer, just before entering a loop
> to be executed millions of times, that should be a big win, not?
JIT most generally refers to on-the-fly optimization of the code. In the
case of Java, the code to be executed is bytecode that is independent of
the CPU instruction set and thus needs to be interpreted. You could
perform the optimization before the execution and save the executable
binary, but the Java gods are reluctant to do that for ideological
reasons ("compile once, run everywhere").
Python code, too, is compiled into interpreted bytecode. Again, you
could compile it into machine code ahead of execution or perform the
compilation on the fly with JIT techniques. However, Python is so
ridiculously dynamic that such compilers have an extremely difficult
time making effective optimizations.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: Fortran
On Fri, May 30, 2014 at 12:50 AM, Marko Rauhamaa wrote: > Python code, too, is compiled into interpreted bytecode. Again, you > could compile it into machine code ahead of execution or perform the > compilation on the fly with JIT techniques. However, Python is so > ridiculously dynamic that such compilers have an extremely difficult > time making effective optimizations. I'd avoid the word "ridiculously" there. Python's dynamism is a feature, not a flaw. It's a feature with consequences (but then, what isn't), and if you don't want it, use a different language, but it's not ridiculous. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran
Chris Angelico : > On Fri, May 30, 2014 at 12:50 AM, Marko Rauhamaa wrote: >> Python code, too, is compiled into interpreted bytecode. Again, you >> could compile it into machine code ahead of execution or perform the >> compilation on the fly with JIT techniques. However, Python is so >> ridiculously dynamic that such compilers have an extremely difficult >> time making effective optimizations. > > I'd avoid the word "ridiculously" there. Python's dynamism is a > feature, not a flaw. It's a feature with consequences (but then, what > isn't), and if you don't want it, use a different language, but it's > not ridiculous. The ridiculous dynamism is the main selling point of high-level programming languages. I wouldn't have it any other way. But from the point of view of the JIT developer, it must feel like Alice in Wonderland. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
On 5/29/2014 5:41 AM, Wolfgang Maier wrote: On 28.05.2014 12:43, Sameer Rathoud wrote: Hello everyone, I am new to python. I am currently using python 3.3 With python I got IDLE, but I am not very comfortable with this. What bothers you the most. Seems like not too many other people on this list share my opinion, but let me just say that IDLE is a nice and sufficient (for my purposes) IDE. If you're used to eclipse, then stick with it, but I prefer IDLE over any text editor although admittedly some of its keyboard shortcuts are unusual choices. 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. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
Terry Reedy writes: > On 5/29/2014 5:41 AM, Wolfgang Maier wrote: >> On 28.05.2014 12:43, Sameer Rathoud wrote: >>> Hello everyone, >>> >>> I am new to python. >>> >>> I am currently using python 3.3 >>> >>> With python I got IDLE, but I am not very comfortable with this. > > What bothers you the most. > >> Seems like not too many other people on this list share my opinion, but >> let me just say that IDLE is a nice and sufficient (for my purposes) IDE. >> If you're used to eclipse, then stick with it, but I prefer IDLE over >> any text editor although admittedly some of its keyboard shortcuts are >> unusual choices. > > 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. -- https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
On Fri, May 30, 2014 at 2:39 AM, Terry Reedy wrote: > I am curious how many of the editors people have been recommending have all > of the following Idle features, that I use constantly. Regarding SciTE: > 1. Run code in the editor with a single keypress. Yes, although for most of what I like to do, it's not appropriate. But if you're developing a script that runs and then terminates, yes, you certainly can. > 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. Yes; it recognizes the most common formats used by C compilers, as well as Python's traceback. Pressing F4 repeatedly will cycle you through the output pane, effectively taking you from one step to another in the traceback. (Obviously if you have more than one traceback, it'll go straight from one to another, which won't always be useful.) You can also double-click a line to go straight there. > 3. Search unopened files (grep) for a string or re. Yes, either using grep itself (fourth point) or using an internal search that's more akin to an old DOS or OS/2 style of search. Either way, the results come up in the output pane, and F4 will cycle through them. > 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. As above. These three are all one feature, really. You can type commands in the output pane and they'll be executed; any program output that matches one of its parseable "this file, this line" formats (which is true of 'grep -n') will be picked up. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran (Was: The "does Python have variables?" debate)
On 29 May 2014 14:06:47 GMT, Albert van der Horst wrote: > In article , > Mark H Harris wrote: >>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. > > I know now how to interpret your posts. Using "incredible" for a mere > factor of at most 3. Balanced views are more convincing. Won't there be an additional speedup resulting from the computation of atan(x) converging faster for x=1/8 than for x=1? -- To email me, substitute nowhere->spamcop, invalid->net. -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran
On Thu, 29 May 2014 17:50:00 +0300, Marko Rauhamaa wrote:
> alb...@spenarnc.xs4all.nl (Albert van der Horst):
>
>> I always thought that the real point of JIT was that it can take
>> advantage of type information that is not available until runtime. If
>> it can infer that something is an integer, just before entering a loop
>> to be executed millions of times, that should be a big win, not?
>
> JIT most generally refers to on-the-fly optimization of the code.
Using information available at run-time, which was Albert's point. Why
would you delay compilation to run-time if you're only going to use
information available at edit-time? You pay all the cost of delayed
compilation and get none of the benefits.
> In the
> case of Java, the code to be executed is bytecode that is independent of
> the CPU instruction set and thus needs to be interpreted.
Not so. There are Java compilers which compile to machine code.
http://www.excelsiorjet.com/
http://gcc.gnu.org/java/
Both are AOT (Ahead Of Time) compilers, but that's not important for this
discussion. If an AOT compiler can emit machine code, so can a JIT
compiler, and that's exactly what PyPy does:
http://morepypy.blogspot.com.au/2011/08/visualization-of-jitted-code.html
> You could
> perform the optimization before the execution and save the executable
> binary, but the Java gods are reluctant to do that for ideological
> reasons ("compile once, run everywhere").
Who are these Java gods of which you speak?
> Python code, too, is compiled into interpreted bytecode.
An unjustified assertion. The Python infrastructure is incredibly rich,
and compilers include many different strategies:
- compile to byte-code for some virtual machine
(e.g. JVM, .Net, Parrot)
- static compilation to machine-code;
- JIT compilation to machine-code;
- translation to some other language (e.g. Haskell, Javascript)
followed by compilation of that code to machine code.
I've already mentioned that PyPy compiles to machine code. So did its
predecessor, Psyco. Both are JIT compilers, as are Numba and Parakeet and
Pyston and Unladen Swallow[1].
Then there's at least one AOT compiler, Nuitka, which produces machine
code. It's not optimized yet, but there's only one guy working on this
project, and it's still young.
http://nuitka.net/posts/static-compilation-that-is-the-point.html
> Again, you
> could compile it into machine code ahead of execution or perform the
> compilation on the fly with JIT techniques.
You're talking as if this were only theoretical. It is not. The state of
the art in compiler techniques has advanced a lot since the old days of
the Pascal P-Machine. Parakeet, for example[2], compiles numeric
functions to optimized machine code on the fly using decorators, using
Static Single Assignment, which some wag described as being "covered in
Fisher Price's My First Compiler"[3].
> However, Python is so
> ridiculously dynamic that such compilers have an extremely difficult
> time making effective optimizations.
Anyone who used Psyco ten years ago would laugh at that statement, and
Psyco isn't even close to cutting edge.
[1] Unladen Swallow was not a failure. It's just that expectations were
so high ("OMG OMG Google is making a Python compiler this will be more
powerful than the Death Star and faster than time travel!!!1!") that it
couldn't help but be a disappointment.
[2] http://www.phi-node.com/2013/01/a-transformative-journey-from-python-to.html
[3] http://blog.cdleary.com/2011/06/mapping-the-monkeysphere/
--
Steven D'Aprano
http://import-that.dreamwidth.org/
--
https://mail.python.org/mailman/listinfo/python-list
Re: Fortran
Steven D'Aprano :
> You're talking as if this were only theoretical. It is not. The state
> of the art in compiler techniques has advanced a lot since the old
> days of the Pascal P-Machine. Parakeet, for example[2], compiles
> numeric functions to optimized machine code on the fly using
> decorators, using Static Single Assignment, which some wag described
> as being "covered in Fisher Price's My First Compiler"[3].
>From your Parakeet link:
An eager reader may be thinking:
I can just stick that decorator atop any Python function and it
will magically run faster? Great! I'll paste @jit all over my
code and my Python performance problems will be solved!
Easy with those decorators! Parakeet is not a general-purpose
compiler for all of Python. Parakeet only supports a handful of
Python's data types: numbers, tuples, slices, and NumPy arrays.
Thus, by its own admission, it is not the Holy Grail I've been talking
about: a Python optimizer that makes Java redundant. For example, I have
never really had to deal with numeric computations; I have implemented
numerous communication protocols in C, C++, Java and Python. I would
love to stick to Python, but I haven't seen the performance numbers
posted that would support that decision.
Also, I know people who are using Java in large-scale online game
servers. Could they be using Python instead?
> [1] Unladen Swallow was not a failure. It's just that expectations
> were so high ("OMG OMG Google is making a Python compiler this will be
> more powerful than the Death Star and faster than time travel!!!1!")
> that it couldn't help but be a disappointment.
That would be *my* expectation. Until then, I'm quite happy with CPython
performance in the numerous niches where it is enough.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: Command prompt not shown when running Python script with subprocess on Windows
That's interesting, now I learned something else too. As I said before, though, I want users to be able to enter paths in the XML file exactly the way they would be entered in a Windows shortcut. (Actually, my program currently only has one Windows user, for whom I develop it [I don't even use it myself :-0].) Since in a Windows shortcut you don't need to put quotes around a path that doesn't contain spaces, I want to follow that behavior in my program as well. So actually, I see that the line: "%ProgramFiles%\LibreOffice 4\program\swriter.exe" "C:\Users\Timothy\Documents\myfile.odt" should instead be: "%ProgramFiles%\LibreOffice 4\program\swriter.exe" C:\Users\Timothy\Documents\myfile.odt because there are no spaces in the second path, but there is a space in the first one. So I guess I'll still have to do my "shlex dance" (which for some reason I keep on mistyping as "shlex dane" :-)) unless I can learn a better way to do it. Also, is my calling os.path.expandvars only on the first argument a good idea? I want to accept environment variables in my program, but I don't want to call os.path.expandvars on all the arguments, because I want to let other programs take care of parsing their own arguments. I'm just wondering if I should relook at the whole way that I am doing things here. Maybe it would be better to just use shlex.split and subprocess.Popen and not try to follow the behavior of Windows shortcuts so closely? (But then it might be hard for some Windows users to understand how to use the program if I didn't.) What do you think? -- https://mail.python.org/mailman/listinfo/python-list
Re: daemon thread cleanup approach
On Thursday, May 29, 2014 1:15:35 AM UTC-7, Chris Angelico wrote: > On Thu, May 29, 2014 at 11:20 AM, Carl Banks wrote: > > > Most threads have cleanup work to do (such as deleting temporary > > directories and killing spawned processes). > > > > > > For better or worse, one of the requirements is that the library can't > > cause the program to hang no matter what... > > > > This ma y be a fundamental problem. I don't know how Windows goes with > > killing processes (can that ever hang?), but certainly you can get > > unexpected delays deleting a temp dir, although it would probably > > require some deliberate intervention, like putting your %temp% on a > > remote drive and then bringing that server down. But believe you me, > > if there is a stupid way to do something, someone WILL have done it. > > (Have you ever thought what it'd be like to have your > > swapfile/pagefile on a network drive? I mean, there's acres of room on > > the server, why waste some of your precious local space?) > > > > So you may want to organize this as a separate spin-off process that > > does the cleaning up. [snip rest] Thanks, that's good information. Even if the temp directories do fail to be removed before the join times out (which probably won't happen much) the situation is still no worse than the situation where the daemon thread is just killed without any chance to clean up. And subprocesses would be a more reliable way to ensure cleanup and might be the direction I take it in the future. Carl Banks -- 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: 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 29/05/2014 21:11, Mark H Harris wrote: 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 I'll point out (again?) that IDLE is improving all the time thanks to Terry & Co. This explains why http://legacy.python.org/dev/peps/pep-0434/ Strangely I've been using Eclipse and Pydev since porting Java to Python some time ago, it really simplified the process. However I'd been thinking of changing and picked IDLE because it's there. Perfectly adequate for my current needs. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
On 5/29/2014 12:51 PM, Chris Angelico wrote: On Fri, May 30, 2014 at 2:39 AM, Terry Reedy wrote: I am curious how many of the editors people have been recommending have all of the following Idle features, that I use constantly. Regarding SciTE: 1. Run code in the editor with a single keypress. Yes, although for most of what I like to do, it's not appropriate. But if you're developing a script that runs and then terminates, yes, you certainly can. 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. Yes; it recognizes the most common formats used by C compilers, as well as Python's traceback. Pressing F4 repeatedly will cycle you through the output pane, effectively taking you from one step to another in the traceback. (Obviously if you have more than one traceback, it'll go straight from one to another, which won't always be useful.) You can also double-click a line to go straight there. 3. Search unopened files (grep) for a string or re. Yes, either using grep itself (fourth point) or using an internal search that's more akin to an old DOS or OS/2 style of search. Either way, the results come up in the output pane, and F4 will cycle through them. 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. As above. These three are all one feature, really. Thank you. This makes your recommendation understandable. > You can type commands in the output pane and they'll be executed; any program output that matches one of its parseable "this file, this line" formats (which is true of 'grep -n') will be picked up. Find in Files (grep) is implemented within Idle, in Python, using re. One of the subprojects of this summer's Idle GSOC student, Saimadhav Heblikar, is to add to Idle something similar to what you describe above. Run an external code analyzer (PyLint/Flake/Checker, whatever...), capture output, and jump to indicated locations. For Idle, the prime intended use would, of course, be for analyzing Python files. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
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. You can satisfy such wonderings with a search for the answers to such questions, which is how I got these answers. > 1. Run [Python] code in the editor with a single keypress. That's not very clear. If you mean, run the entire file being edited: yes, Vim and Emacs can do that. I don't use such a feature, because I almost never want to run the *entire* module; I want to test the one function I'm working on at that moment. For that purpose, a unit test is more appropriate. Vim and Emacs also have the feature to run a Python unit test suite with a single key and navigate the output. > 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. Yes, any decent programmer's editor will have this, once it is taught how to parse the error output from the language interpreter. For Vim and Emacs, yes, they already know how to capture error output and interactively jump to the referenced locations in the code. They also both have interactive debugger modes, including for Python. > 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. This is an essential feature of any decent programming editor, and Vim and Emacs certainly have the feature to grep a file tree and navigate the results interactively. -- \ “[Entrenched media corporations will] maintain the status quo, | `\ or die trying. Either is better than actually WORKING for a | _o__) living.” —ringsnake.livejournal.com, 2007-11-12 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Forking PyPI package
On Thu, May 29, 2014 at 1:40 AM, Chris Angelico wrote: > If you absolutely can't get in touch with him, the only option is to > go back to the original protocol and manually reimplement it, > completely ignoring this code. It's sad but true; some code dies > because of a trivial thing like "Oops, I forgot to actually say that > this is MIT-licensed". The second part of that is that the code should actually *include* the license text. Just writing "BSD license" somewhere on the website or in package metadata is annoyingly common but somewhat questionable in how a judge might interpret it. For instance, there at least four different versions of the BSD license; which one did you mean? -- https://mail.python.org/mailman/listinfo/python-list
Binary data exchange
friends
I have a pair of simple python programs as follows:
#!/usr/bin/python
# broadcast.py
import socket
from ctypes import *
import random
class PurgeData(Structure):
_fields_ = [("press",c_int), ("ticks",c_int), ("volume",c_float)]
myPort = 10756
sock=socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
addr = ('localhost',myPort)
#sock.sendto(data,addr)
presdata = PurgeData()
presdata.press = 0
presdata.ticks = 100
for msg in range(1,20):
presdata.press = presdata.press+1
presdata.ticks = presdata.ticks+1
presdata.volume = random.random()
sock.sendto(presdata,addr)
#
#!/usr/bin/python
# Receiver
import socket
from ctypes import *
class PurgeData(Structure):
_fields_ = [("press",c_int), ("ticks",c_int), ("volume",c_float)]
myPort = 10756
sock=socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
addr = ('localhost',myPort)
sock.bind(addr)
presdata=PurgeData()
while True:
data,addr = sock.recvfrom(1024)
memmove(addressof(presdata),data.strip(),len(data.strip()))
print presdata.press, presdata.ticks, presdata.volume
-
When I tried to run this I get some bizarre results:
1 101 0.343009024858
2 102 0.36397305131
3 103 0.495895296335
4 104 0.372055351734
5 105 0.933839201927
6 106 0.931187808514
7 107 0.876732826233
8 108 0.298638045788
1828716544 -754974720 0.183644190431
1845493760 1660944384 0.186560109258
1862270976 1056964608 0.18631502986
1879048192 1728053248 0.186902835965
1895825408 2097152000 0.18658298254
14 114 0.407857120037
15 115 0.833854913712
16 116 0.00646247947589
17 117 0.297783941031
18 118 0.58082228899
19 119 0.61717569828
the received data for the messages 9 thru 13 are not as expected.
I wonder if anyone can see what I am doing wrong?
Appreciate any hints. thanks, srini
--
https://mail.python.org/mailman/listinfo/python-list
Re: Binary data exchange
BTW - My environment is: H:\>python Enthought Canopy Python 2.7.6 | 64-bit | (default, Apr 11 2014, 20:31:44) [MSC v .1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> -- https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
> On May 28, 2014, at 3:43, Sameer Rathoud wrote: > > Hello everyone, > > I am new to python. > > 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. > -- > https://mail.python.org/mailman/listinfo/python-list I use either vim or textwrangler for simple one file scripts. For larger things with multiple files and/or classes, I like pycharm best ( free community edition ). I tried both pydev and wing before that. -- https://mail.python.org/mailman/listinfo/python-list
Re: Binary data exchange
On 2014-05-29 23:08, rasikasriniva...@gmail.com wrote:
friends
I have a pair of simple python programs as follows:
#!/usr/bin/python
# broadcast.py
import socket
from ctypes import *
import random
class PurgeData(Structure):
_fields_ = [("press",c_int), ("ticks",c_int), ("volume",c_float)]
myPort = 10756
sock=socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
addr = ('localhost',myPort)
#sock.sendto(data,addr)
presdata = PurgeData()
presdata.press = 0
presdata.ticks = 100
for msg in range(1,20):
presdata.press = presdata.press+1
presdata.ticks = presdata.ticks+1
presdata.volume = random.random()
sock.sendto(presdata,addr)
#
#!/usr/bin/python
# Receiver
import socket
from ctypes import *
class PurgeData(Structure):
_fields_ = [("press",c_int), ("ticks",c_int), ("volume",c_float)]
myPort = 10756
sock=socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
addr = ('localhost',myPort)
sock.bind(addr)
presdata=PurgeData()
while True:
data,addr = sock.recvfrom(1024)
memmove(addressof(presdata),data.strip(),len(data.strip()))
print presdata.press, presdata.ticks, presdata.volume
-
When I tried to run this I get some bizarre results:
1 101 0.343009024858
2 102 0.36397305131
3 103 0.495895296335
4 104 0.372055351734
5 105 0.933839201927
6 106 0.931187808514
7 107 0.876732826233
8 108 0.298638045788
1828716544 -754974720 0.183644190431
1845493760 1660944384 0.186560109258
1862270976 1056964608 0.18631502986
1879048192 1728053248 0.186902835965
1895825408 2097152000 0.18658298254
14 114 0.407857120037
15 115 0.833854913712
16 116 0.00646247947589
17 117 0.297783941031
18 118 0.58082228899
19 119 0.61717569828
the received data for the messages 9 thru 13 are not as expected.
I wonder if anyone can see what I am doing wrong?
Appreciate any hints. thanks, srini
I don't understand why you're using the .strip method. That's for
stripping whitespace from text, but you're not sending and receiving
text, you're sending and receiving binary data.
Personally, I'd use the struct module.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Binary data exchange
On Thu, May 29, 2014 at 5:09 PM, MRAB wrote: > On 2014-05-29 23:08, rasikasriniva...@gmail.com wrote: >> the received data for the messages 9 thru 13 are not as expected. >> >> I wonder if anyone can see what I am doing wrong? >> >> Appreciate any hints. thanks, srini >> > I don't understand why you're using the .strip method. That's for > stripping whitespace from text, but you're not sending and receiving > text, you're sending and receiving binary data. And indeed, ASCII characters 9-13 are all whitespace. The receiver appears to be stripping off the first byte of the (presumably little-endian) data and thus shifting the whole struct by a byte for those entries. -- https://mail.python.org/mailman/listinfo/python-list
Re: Binary data exchange
Of course Cut and paste issue. Anyhow, i will look at the struct module.
cheers, srini
On Thursday, May 29, 2014 7:09:21 PM UTC-4, MRAB wrote:
> On 2014-05-29 23:08, rasikasriniva...@gmail.com wrote:
>
> > friends
>
> >
>
> > I have a pair of simple python programs as follows:
>
> >
>
> > #!/usr/bin/python
>
> > # broadcast.py
>
> > import socket
>
> > from ctypes import *
>
> > import random
>
> >
>
> > class PurgeData(Structure):
>
> > _fields_ = [("press",c_int), ("ticks",c_int), ("volume",c_float)]
>
> >
>
> > myPort = 10756
>
> >
>
> > sock=socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
>
> > addr = ('localhost',myPort)
>
> > #sock.sendto(data,addr)
>
> >
>
> > presdata = PurgeData()
>
> > presdata.press = 0
>
> > presdata.ticks = 100
>
> >
>
> > for msg in range(1,20):
>
> > presdata.press = presdata.press+1
>
> > presdata.ticks = presdata.ticks+1
>
> > presdata.volume = random.random()
>
> > sock.sendto(presdata,addr)
>
> >
>
> > #
>
> >
>
> > #!/usr/bin/python
>
> > # Receiver
>
> > import socket
>
> >
>
> > from ctypes import *
>
> >
>
> > class PurgeData(Structure):
>
> > _fields_ = [("press",c_int), ("ticks",c_int), ("volume",c_float)]
>
> >
>
> > myPort = 10756
>
> >
>
> > sock=socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
>
> > addr = ('localhost',myPort)
>
> > sock.bind(addr)
>
> > presdata=PurgeData()
>
> >
>
> > while True:
>
> > data,addr = sock.recvfrom(1024)
>
> > memmove(addressof(presdata),data.strip(),len(data.strip()))
>
> > print presdata.press, presdata.ticks, presdata.volume
>
> >
>
> > -
>
> >
>
> > When I tried to run this I get some bizarre results:
>
> >
>
> >
>
> > 1 101 0.343009024858
>
> > 2 102 0.36397305131
>
> > 3 103 0.495895296335
>
> > 4 104 0.372055351734
>
> > 5 105 0.933839201927
>
> > 6 106 0.931187808514
>
> > 7 107 0.876732826233
>
> > 8 108 0.298638045788
>
> > 1828716544 -754974720 0.183644190431
>
> > 1845493760 1660944384 0.186560109258
>
> > 1862270976 1056964608 0.18631502986
>
> > 1879048192 1728053248 0.186902835965
>
> > 1895825408 2097152000 0.18658298254
>
> > 14 114 0.407857120037
>
> > 15 115 0.833854913712
>
> > 16 116 0.00646247947589
>
> > 17 117 0.297783941031
>
> > 18 118 0.58082228899
>
> > 19 119 0.61717569828
>
> >
>
> > the received data for the messages 9 thru 13 are not as expected.
>
> >
>
> > I wonder if anyone can see what I am doing wrong?
>
> >
>
> > Appreciate any hints. thanks, srini
>
> >
>
> I don't understand why you're using the .strip method. That's for
>
> stripping whitespace from text, but you're not sending and receiving
>
> text, you're sending and receiving binary data.
>
>
>
> Personally, I'd use the struct module.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Binary data exchange
On 30/05/2014 00:25, rasikasriniva...@gmail.com wrote: Of course Cut and paste issue. Anyhow, i will look at the struct module. cheers, srini Please let us know how you get on, please don't top post, and please either use the mailing list https://mail.python.org/mailman/listinfo/python-list or read and action this https://wiki.python.org/moin/GoogleGroupsPython to prevent us seeing double line spacing and single line paragraphs, thanks. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
pyflakes best practices?
We've recently started using pyflakes. The results seem to be similar to most tools of this genre. It found a few real problems. It generated a lot of noise about things which weren't really wrong, but were easy to fix (mostly, unused imports), and a few plain old false positives which have no easy "fix" (in the sense of, things I can change which will make pyflakes STFU). So, what's the best practice here? How do people deal with the false positives? Is there some way to annotate the source code to tell pyflakes to ignore something? -- https://mail.python.org/mailman/listinfo/python-list
Re: Forking PyPI package
On Fri, May 30, 2014 at 7:54 AM, Ian Kelly wrote: > On Thu, May 29, 2014 at 1:40 AM, Chris Angelico wrote: >> If you absolutely can't get in touch with him, the only option is to >> go back to the original protocol and manually reimplement it, >> completely ignoring this code. It's sad but true; some code dies >> because of a trivial thing like "Oops, I forgot to actually say that >> this is MIT-licensed". > > The second part of that is that the code should actually *include* the > license text. Just writing "BSD license" somewhere on the website or > in package metadata is annoyingly common but somewhat questionable in > how a judge might interpret it. For instance, there at least four > different versions of the BSD license; which one did you mean? Agreed. I tend to have a file called README or LICENSE in the main source code directory that has license terms (in the case of a README, the license will follow whatever else there is to say); that's generally clear enough, without having to put a header on every single source file. I like to put both a short name and the full license text in there (see eg https://github.com/Rosuav/Yosemite for which I use the MIT license), so it's independent of random web sites - having nothing but a link to the license text makes it that bit more vulnerable. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How to run script from interpreter?
On Thu, 29 May 2014 15:26:37 -0500, Mark H Harris wrote: > I think the IDLE REPL should have a system shell mode. What say you? I don't use IDLE, so I don't really care what you do to it. But speaking generally, -1 on that. IDLE is primarily aimed at beginners, and beginners have enough trouble distinguishing the system shell separate in their heads from the Python shell, the last thing they need is something that blurs the difference. There is a power-user shell that does exactly what you want, turned up to eleven: IPython. IPython allows you to run system commands by prefixing them with ! and has an entire subsystem of user-configurable "magic" commands using % prefix. (By the way, ; won't work for a Python shell, because ;spam already is valid Python syntax: it's an empty statement followed by the statement spam, separated by a semicolon.) -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: How to run script from interpreter?
On Fri, May 30, 2014 at 10:33 AM, Steven D'Aprano wrote: > (By the way, ; won't work for a Python shell, because ;spam already is > valid Python syntax: it's an empty statement followed by the statement > spam, separated by a semicolon.) That's not really a problem, though. It's not going to stop you from doing something actually *useful*, and the fact that the semicolon could be syntactically valid isn't going to come into it, because the REPL would swallow it anyway. But I agree that IDLE does not need a "drop to shell" mode. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: pyflakes best practices?
On 30/05/2014 01:13, Roy Smith wrote: We've recently started using pyflakes. The results seem to be similar to most tools of this genre. It found a few real problems. It generated a lot of noise about things which weren't really wrong, but were easy to fix (mostly, unused imports), and a few plain old false positives which have no easy "fix" (in the sense of, things I can change which will make pyflakes STFU). So, what's the best practice here? How do people deal with the false positives? Is there some way to annotate the source code to tell pyflakes to ignore something? I was under the impression that pyflakes was configurable. It it isn't I'd simply find another tool. Having said that if you don't get better answers here try gmane.comp.python.code-quality. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Multi-line commands with 'python -c'
Since lines are so critical to Python syntax, I'm a little surprised
there's no majorly obvious solution to this... or maybe I'm just
blind.
Problem: Translate this into a shell one-liner:
import os
for root, dirs, files in os.walk("."):
if len(dirs + files) == 1: print(root)
Solution 1: SyntaxError
python -c 'import os; for root, dirs, files in os.walk("."): if
len(dirs + files) == 1: print(root)'
You can't put a 'for' statement after an 'import' with just a semicolon.
Solution 2: SyntaxError
python -c 'import os\nfor root, dirs, files in os.walk("."): if
len(dirs + files) == 1: print(root)'
You can't put a backslash escape into your code like that! Makes no sense.
Solution 3: Silence
python -c 'import os' -c 'for root, dirs, files in os.walk("."): if
len(dirs + files) == 1: print(root)'
Haven't dug into exactly what this does, but the docs say that -c
terminates the option list, so I would guess that the second -c and
its arg get passed to the script.
Solution 4: Rely on the shell's ability to pass newlines inside arguments
$ python -c 'import os
> for root, dirs, files in os.walk("."):
> if len(dirs + files) == 1: print(root)
> '
That works, but at that point, you aren't writing a one-liner any
more. It's also fiddly to edit.
Is there a better way to put multiple virtual lines into a 'python -c' command?
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: pyflakes best practices?
In article , Mark Lawrence wrote: > On 30/05/2014 01:13, Roy Smith wrote: > > We've recently started using pyflakes. The results seem to be similar > > to most tools of this genre. It found a few real problems. It > > generated a lot of noise about things which weren't really wrong, but > > were easy to fix (mostly, unused imports), and a few plain old false > > positives which have no easy "fix" (in the sense of, things I can change > > which will make pyflakes STFU). > > > > So, what's the best practice here? How do people deal with the false > > positives? Is there some way to annotate the source code to tell > > pyflakes to ignore something? > > > > I was under the impression that pyflakes was configurable. It it isn't > I'd simply find another tool. Having said that if you don't get better > answers here try gmane.comp.python.code-quality. I didn't know that list existed, it looks very interesting. Thanks for the pointer! -- https://mail.python.org/mailman/listinfo/python-list
Re: How to run script from interpreter?
On Fri, 30 May 2014 10:46:34 +1000, Chris Angelico wrote:
> On Fri, May 30, 2014 at 10:33 AM, Steven D'Aprano
> wrote:
>> (By the way, ; won't work for a Python shell, because ;spam already is
>> valid Python syntax: it's an empty statement followed by the statement
>> spam, separated by a semicolon.)
>
> That's not really a problem, though. It's not going to stop you from
> doing something actually *useful*, and the fact that the semicolon could
> be syntactically valid isn't going to come into it, because the REPL
> would swallow it anyway.
The point is that *syntactically valid* Python statements should not
behave differently when running inside the shell or not. I thought
that ;statement was syntactically valid -- but I was wrong. The vanilla
CPython interactive interpreter gives a syntax error, as do IronPython
and Jython. I misinterpreted what I saw in IPython -- it's already doing
magic at the command line:
In [4]: len []
--> len([])
Out[4]: 0
In [5]: ;len []
--> len("[]")
Out[5]: 2
--
Steven D'Aprano
http://import-that.dreamwidth.org/
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to run script from interpreter?
On Fri, May 30, 2014 at 11:49 AM, Steven D'Aprano wrote: > On Fri, 30 May 2014 10:46:34 +1000, Chris Angelico wrote: > >> On Fri, May 30, 2014 at 10:33 AM, Steven D'Aprano >> wrote: >>> (By the way, ; won't work for a Python shell, because ;spam already is >>> valid Python syntax: it's an empty statement followed by the statement >>> spam, separated by a semicolon.) >> >> That's not really a problem, though. It's not going to stop you from >> doing something actually *useful*, and the fact that the semicolon could >> be syntactically valid isn't going to come into it, because the REPL >> would swallow it anyway. > > The point is that *syntactically valid* Python statements should not > behave differently when running inside the shell or not. I thought > that ;statement was syntactically valid -- but I was wrong. The vanilla > CPython interactive interpreter gives a syntax error, as do IronPython > and Jython. Huh. I responded to your post on the unchecked assumption that ";spam" was syntactically valid. I'm still of the opinion that technically valid (but not useful) constructs are allowed to be swallowed by an interactive interpreter; for instance, it's perfectly valid to write this: >>> x = (1 . imag) But quite a few interpreters (though not Python) take a dot on its own line to mean "flush the buffer, cancel my current command". I couldn't find a way to do this in Python, but if someone proposed adding it, the fact that the above is syntactically legal shouldn't be a proposal blocker. It's on par with creating a file with a name beginning with a hyphen, and then fiddling around with various commands as you try to manipulate it (tip: "rm ./-r" works); programs will happily interpret "-r" as an option rather than a file name, without being concerned that it's technically legal. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Proposal of an API to deal with fingerprints on Python
Today I wrote the following API. It was not implemented on C yet. Do you have any comment? Could you help me to implement it? http://www.izecksohn.com/pedro/python/fingerprint/fingerprint.001.py -- https://mail.python.org/mailman/listinfo/python-list
Multi-line commands with 'python -c'
On Thursday, May 29, 2014, Chris Angelico > wrote:
> Since lines are so critical to Python syntax, I'm a little surprised
> there's no majorly obvious solution to this... or maybe I'm just
> blind.
>
> Problem: Translate this into a shell one-liner:
>
> import os
> for root, dirs, files in os.walk("."):
> if len(dirs + files) == 1: print(root)
>
> Is there a better way to put multiple virtual lines into a 'python -c'
> command?
>
You can always cheat:
$ python -c 'exec("import os\nfor root, dirs, files in os.walk(\".\"):\n if
len(dirs + files) == 1: print(root)")'
Doesn't do much for being long and fiddly, though.
--
Zach
Sent from an iPad, please bear with any brevity, uncaught
auto-uncorrections, HTML, or other annoyances. Suggestions for a great (not
just 'good') email app are welcome.
--
Sent from Gmail Mobile
--
https://mail.python.org/mailman/listinfo/python-list
Re: Proposal of an API to deal with fingerprints on Python
On Fri, May 30, 2014 at 7:21 AM, Pedro Izecksohn wrote: > Today I wrote the following API. It was not implemented on C yet. Do you > have any comment? Could you help me to implement it? > > http://www.izecksohn.com/pedro/python/fingerprint/fingerprint.001.py If that's a proof-of-concept for just the function names and things, then what I'd say is: Follow PEP 8, especially if (as your license comment suggests) you're hoping for it to be included in the Python standard library. Notably, use underscore_separated_names rather than mixedCase for function names. If that's meant to be actual usable (if stubby) code, then PEP 8 is even more important; for instance, "if (None == fpdev):" should be "if fpdev is None:". Also, your bare excepts are nasty code smell. My recommendation: Look into Cython. You're basically wrapping a C library, so you should be able to let Cython do the heavy lifting, and then maybe just add a few convenience functions in pure Python. There won't be much work, that way! Regarding licensing, by the way, I would advise decoupling yourself from the CPython standard library, which has a bit of a mess of licensing and ownership due to its long history. Pick one of the well-known open source licenses, like MIT, GPL2/GPL3, or MPL, and use that. Post your code on some place like github or bitbucket, link to it from PyPI, and let your project stand alone as a third-party installable package - if it's good, people will use it, and they can find it using pip or equivalent. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Multi-line commands with 'python -c'
On Fri, May 30, 2014 at 12:34 PM, Zachary Ware
wrote:
> You can always cheat:
>
> $ python -c 'exec("import os\nfor root, dirs, files in os.walk(\".\"):\n if
> len(dirs + files) == 1: print(root)")'
>
> Doesn't do much for being long and fiddly, though.
Not really, no! Heh. I wrote that in competition against a theoretical
solution involving shell commands and pipes and so on, with the
intention being that the Python version could be a simple shell
one-liner, just as the pipe version could. (The task: Find all
directories with exactly one subdirectory or file in them, not
counting dot and dot-dot. Python's os.walk() is pretty much perfect
for that.) I tried fiddling with __import__() rather than the import
statement, but it didn't really aid clarity much.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: PythonCE successfully inst'ed, but scripts don't work. Please help.
Hi, I know you posted this 15 years ago but I recently stumbled across your post here : https://mail.python.org/pipermail/python-list/1999-May/018340.html And I am in the same situation (kind of). I can’t get Python to install on my MobilePro 770 running Windows CE 3.0. Are you still available? Is this e-mail even valid? I know I’m just some random person on the internet but I need your help in installing Python to my MobilePro 770. Any help would be appreciated. Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Script suddenly stops
Dear All, I'm trying to read ten 200 MB textfiles into a MySQL MyISAM database (Linux, ext4). The script output is suddenly stopping, while the Python process is still running (or should I say sleeping?). It's not in top, but in ps visible. Why is it stopping? Is there a way to make it continue, without calling "kill -9", deleting the processed lines and starting it again? Thank you in advance. [1] http://pastebin.com/CxHCA9eB -- Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: Multi-line commands with 'python -c'
On Friday, May 30, 2014 6:22:24 AM UTC+5:30, Chris Angelico wrote:
> Since lines are so critical to Python syntax, I'm a little surprised
> there's no majorly obvious solution to this... or maybe I'm just
> blind.
> Problem: Translate this into a shell one-liner:
> import os
> for root, dirs, files in os.walk("."):
> if len(dirs + files) == 1: print(root)
I would have thought this would work:
python -m os -c 'for root, dirs, files in os.walk("."): if len(dirs + files) ==
1: print(root)'
Unfortunately doesn't
But did show up a small doc-bug:
This fact is not documented in
$ man python
but is documented in
$ python -h
Anyways...
I thought when one signs up for python one has to sign an affidavit
saying:
"I shall not write one-liners\n" * 100
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to run script from interpreter?
On Fri, 30 May 2014 12:04:27 +1000, Chris Angelico wrote: > On Fri, May 30, 2014 at 11:49 AM, Steven D'Aprano > wrote: >> On Fri, 30 May 2014 10:46:34 +1000, Chris Angelico wrote: >> >>> On Fri, May 30, 2014 at 10:33 AM, Steven D'Aprano >>> wrote: (By the way, ; won't work for a Python shell, because ;spam already is valid Python syntax: it's an empty statement followed by the statement spam, separated by a semicolon.) >>> >>> That's not really a problem, though. It's not going to stop you from >>> doing something actually *useful*, and the fact that the semicolon >>> could be syntactically valid isn't going to come into it, because the >>> REPL would swallow it anyway. >> >> The point is that *syntactically valid* Python statements should not >> behave differently when running inside the shell or not. I thought that >> ;statement was syntactically valid -- but I was wrong. The vanilla >> CPython interactive interpreter gives a syntax error, as do IronPython >> and Jython. > > Huh. I responded to your post on the unchecked assumption that ";spam" > was syntactically valid. I'm still of the opinion that technically valid > (but not useful) constructs are allowed to be swallowed by an > interactive interpreter; Heavens no. If it's legal in a script when running non-interactively, it should be legal when running interactively. I give a grudging exception to things like the REPL ending a function definition at the first empty line, even though it breaks copy-and-paste of working code: py> def example(): ... do_this() ... py> do_that() File "", line 1 do_that() ^ IndentationError: unexpected indent That's a *serious* PITA when copying (say) classes into the interactive interpreter, because you have to delete all the blank lines (or stick comments # in them) before pasting. But I can't see any practical alternative. > for instance, it's perfectly valid to write > this: > x = (1 > . > imag) Absolutely it is valid Python code, so your REPL better accept it as valid Python code. > But quite a few interpreters (though not Python) take a dot on its own > line to mean "flush the buffer, cancel my current command". I've never come across that. I'm very glad I haven't. Who came up with that broken interface? > I couldn't > find a way to do this in Python, but if someone proposed adding it, the > fact that the above is syntactically legal shouldn't be a proposal > blocker. Damn straight it ought to. If I proposed making: x = (1 + y) do something other than set x to 1+y, I would completely deserve to be dragged out into the street and beaten with halibuts. Replace the + with a dot, and there is no difference at all. If you want to kill the current buffer, just hit Ctrl-C like you're meant to. > It's on par with creating a file with a name beginning with a > hyphen, and then fiddling around with various commands as you try to > manipulate it (tip: "rm ./-r" works); programs will happily interpret > "-r" as an option rather than a file name, without being concerned that > it's technically legal. I don't see any connection between the two. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Multi-line commands with 'python -c'
On Friday, May 30, 2014 11:34:36 AM UTC+5:30, Rustom Mody wrote:
> On Friday, May 30, 2014 6:22:24 AM UTC+5:30, Chris Angelico wrote:
> > Since lines are so critical to Python syntax, I'm a little surprised
> > there's no majorly obvious solution to this... or maybe I'm just
> > blind.
> > Problem: Translate this into a shell one-liner:
> > import os
> > for root, dirs, files in os.walk("."):
> > if len(dirs + files) == 1: print(root)
Heres a (pr) approx
$ python -c 'import os, pprint; pprint.pprint ([ r for r, d, f in os.walk(".")
if len(d+f) != 1])'
Mysterious that print after a ; is fine whereas for is not
> Anyways...
> I thought when one signs up for python one has to sign an affidavit
> saying:
> "I shall not write one-liners\n" * 100
I hope youve signed it by now
--
https://mail.python.org/mailman/listinfo/python-list
Re: Multi-line commands with 'python -c'
On Friday, May 30, 2014 12:15:46 PM UTC+5:30, Rustom Mody wrote:
> Heres a (pr) approx
>
> $ python -c 'import os, pprint; pprint.pprint ([ r for r, d, f in
> os.walk(".") if len(d+f) != 1])'
Without pprint: (pooor)
python -c 'import os; print "\n".join([ r for r, d, f in os.walk(".") if
len(d+f) != 1])'
Or (poor)
python -c 'from os import walk; print "\n".join([ r for r, d, f in walk(".") if
len(d+f) != 1])'
--
https://mail.python.org/mailman/listinfo/python-list
