Re: Python IDE/text-editor
On Sat, 2011-04-16, Chris Angelico wrote: > Based on the comments here, it seems that emacs would have to be the > editor-in-chief for programmers. I currently use SciTE at work; is it > reasonable to, effectively, bill my employer for the time it'll take > me to learn emacs? I'm using a lot of the same features that the OP > was requesting (multiple files open at once, etc), plus I like syntax > highlighting (multiple languages necessary - I'm often developing > simultaneously in C++, Pike, PHP, and gnu make, as well as Python). Your editor seems popular, free, cross-platform and capable ... if you already know it well, I can't see why you should switch. Unless you're truly not productive in SciTE, but I'd have to watch you use it for hours to tell. (That should really be a new job title. Just as there are aerobics instructors or whatever at the gyms to help you use the equipment there safely and efficiently, there should be text editor instructors!) /Jorgen -- // Jorgen GrahnO o . -- http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/text-editor
On Sun, Apr 17, 2011 at 5:17 PM, Jorgen Grahn wrote: > (That should really be a new job title. Just as there are aerobics > instructors or whatever at the gyms to help you use the equipment > there safely and efficiently, there should be text editor instructors!) You nearly had me crack up laughing in the middle of a church meeting... Yes! We need text editor instructors. "Don't forget that you can press F7 to make." "You could do that more easily with C-x M-c M-butterfly." Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/text-editor
Am Sat, 16 Apr 2011 22:22:19 -0500 schrieb John Bokma : > Yeah, if you bring it down to open a file, save a file, and move the > cursor around, sure you can do that in a day or two (two since you > have to get used to the "weird" key bindings). Sorry but learning the basic stuff doesnt take any longer than 10 to 30 minutes and if one doesnt want to learn the shortcuts one can use GNU/Emacs GUI and click around. Configuring it to do Python optimal could took some hours / days some time ago, but now it just takes setting up Emacs for Python and you have syntax highlighting, code templates, refactoring and auto-completion support. Chao Balle signature.asc Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Equivalent code to the bool() built-in function
Le 17/04/2011 04:39, Ben Finney a écrit : Why do you need to know? (I should have asked that question earlier.) First because I was doubting the true interest of the bool() type. In fact, it appears that it's _semantically_ a shortcut for True if x else False. I could't imagine a builtin function having a so trivial implementation. Compare with float() or int(). I also try to consider how essential the bool() type is. Again compare with int() or str() types. In the orther hand, I'm builting a sort of documentation for learning Python. In order to spell out the purposes of the bool() type, I guessed that giving an equivalence code could help. -- http://mail.python.org/mailman/listinfo/python-list
Re: PYTHONPATH
On Sun, 17 Apr 2011 01:14:54 -0500, harrismh777 wrote: > Its just technically difficult to > setup easily configured concurrent environments on the Windows platform, > primarily due to the way the platform was designed--- closed and > proprietary--- with little to no community input. I believe that is incorrect. In my opinion, a better explanation for the difficulty faced by Windows users is that this is a side-effect of Windows starting life as a single-user operating system. Various proprietary Unixes -- and all Unixes started off life as closed and proprietary -- and other proprietary but multi-user OSes, such as VMS, are more easily configured. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Equivalent code to the bool() built-in function
On Sun, Apr 17, 2011 at 6:38 PM, candide wrote: > I also try to consider how essential the bool() type is. > Again compare with int() or str() types. Well, of course you can always implement bool as an int; C has done this for decades, and it hasn't killed it. You can also implement integers as strings - REXX manages quite well, and gets some advantages therefrom. But having an explicit bool type has its benefits too. Essential? No. Useful? Certainly. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature suggestion -- return if true
On Sun, 17 Apr 2011 16:21:53 +1200, Gregory Ewing wrote: > Chris Angelico wrote: > >> def fac(n): >> # attempt to get from a cache >> return? cache[n] >> # not in cache, calculate the value >> ret=1 if n<=1 else fac(n-1)*n >> # and cache and return it >> cache[n]=ret; return ret > > My idiom for fetching from a cache looks like this: > >def get_from_cache(x): > y = cache.get(x) > if not y: >y = compute_from(x) >cache[x] = y > return y > > which doesn't require any conditional returns. I'm sure you realise that that snippet needlessly recalculates any cached result that happens to be false, but others reading might not. If the compute_from function is expensive (and it better be, otherwise why are you bothering with a cache?), that could be expensive: compute_from = is_prime_number get_from_cache(253590421923456781012937340348512751108342137327 * 195789732345627381015532937340363481051277321451) :) A better way is to explicitly test for the sentinel: y = cache.get(x) if y is not None: ... -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature suggestion -- return if true
On Sun, Apr 17, 2011 at 6:45 PM, Steven D'Aprano wrote: > On Sun, 17 Apr 2011 16:21:53 +1200, Gregory Ewing wrote: > >> Chris Angelico wrote: >> >>> def fac(n): >>> # attempt to get from a cache >>> return? cache[n] >>> # not in cache, calculate the value >>> ret=1 if n<=1 else fac(n-1)*n >>> # and cache and return it >>> cache[n]=ret; return ret >> >> My idiom for fetching from a cache looks like this: >> >> def get_from_cache(x): >> y = cache.get(x) >> if not y: >> y = compute_from(x) >> cache[x] = y >> return y >> >> which doesn't require any conditional returns. > > > I'm sure you realise that that snippet needlessly recalculates any cached > result that happens to be false, but others reading might not. Sure. In my (somewhat contrived) example of factorials, that's going to be true (apart from 0! = 0); and if the function returns a string or other object rather than an integer, same thing. If there's the possibility of _ANY_ value coming back from the computation, then it would need to be done as: if x in cache: return cache[x] or as: try: return cache[x] except KeyError: # calculate etc Obviously, as with everything, you need to know your own code and your own data. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Make Python "portable" by default! (Re: Python IDE/text-editor)
> You can't run Python programs without a Python interpreter installed.
Wrong.
See e.g. http://www.portablepython.com/
BTW: Imho, the Python interpreter should be made
"portable" ("zero-install") _by default_. "Installing" it should be
purely optional.
Sincerely,
Wolfgang Keller
--
http://mail.python.org/mailman/listinfo/python-list
Re: Make Python "portable" by default! (Re: Python IDE/text-editor)
On Sun, Apr 17, 2011 at 7:13 PM, Wolfgang Keller wrote: >> You can't run Python programs without a Python interpreter installed. > > Wrong. > > See e.g. http://www.portablepython.com/ Uhm... how does that disprove? Whatever language you distributed code is in, you need something on the computer that can read it. Only pure machine code needs no interpreter (and even that's arguable, but the interpreter is in hardware instead of software). With code that's distributed in source form (all interpreted / shell languages, plus most open source C/C++ code today), you need to have a language-specific interpreter or compiler before you can run it. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: Equivalent code to the bool() built-in function
candide writes: > First because I was doubting the true interest of the bool() type. In > fact, it appears that it's _semantically_ a shortcut for > True if x else False. That bends my brain. Both ‘True’ and ‘False’ are instances of the ‘bool’ type. So of course the ‘bool’ constructor will return them. What is the “shortcut” you refer to? Remember, the point of a type is to encapsulate both behaviour and an exclusive domain of possible values. The Boolean type is particularly simple, so I don't see why you would be surprised that the behaviour of the ‘bool’ constructor is simple – that's a feature of that type. > In the orther hand, I'm builting a sort of documentation for learning > Python. Something different from http://docs.python.org/tutorial/>. > In order to spell out the purposes of the bool() type, I guessed that > giving an equivalence code could help. The purpose of the ‘bool’ type is to have a data type which captures the behaviour of only Boolean values, and no other values. -- \ Eccles: “I just saw the Earth through the clouds!” Lew: “Did | `\ it look round?” Eccles: “Yes, but I don't think it saw me.” | _o__)—The Goon Show, _Wings Over Dagenham_ | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/text-editor
Thanks for all the replies (I love the python mailing-list!) I've tried all the IDEs/text-editors mentioned. PyScripter is great, however is unmaintained thus doesn't support 64-bit :[ (and is a little buggy) Also, it requires network connectivity, which could prove troublesome on my locked-down Uni network (requires localhost for python shell) DreamPIE isn't what I'm looking for. Editra has a python plugin? - Excellent! — Got the plugin working... is there a shortcut (e.g.: F9) for running the opened python script? UliPad is quite good, however badly coded (a new console window opens then closes each time I run a script)... I might fix that bug if I ever get the time. MonoDevelop doesn't seem to support Python (I pressed: "New Solution") GEdit probably won't work from a USB, and the embedded console isn't user friendly (you'd need to type: "import x.py" or whatever) Emacs and vim are good, however I often find myself on a workstation without direct console access. GVim leaves a lot aesthetically desired. Also there's a learning-curve to both of them, whereas nano, and all the text-editors/IDEs above are user-friendly. None I've found to have a big learning curve (more about finding the right preference to change in settings than anything else!) Kate I haven't tried yet... it's currently downloading. On Sun, Apr 17, 2011 at 3:05 AM, Terry Reedy wrote: > On 4/16/2011 3:03 AM, Alec Taylor wrote: >> >> IDLE loses syntax highlighting annoyingly often > > Could you exlain? > When does it do that with a file labelled .py? > > Terry Jan Reedy Just randomly, sometimes on first save to a .py, other-times on files that I've opened with a .py extension. It loses all syntax highlighting! -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature suggestion -- return if true
>> be expanded to >> >>_temp = expr >>if _temp: return _temp > > This could be simplified to just: > > return expr or None > """ No, it can't be simplified in this way. If there is code after that snippet, then it will get executed in the original version if _temp is false, but won't get executed in your simplification. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Equivalent code to the bool() built-in function
On Sun, Apr 17, 2011 at 7:38 PM, candide wrote:
> I could't imagine a builtin function having a so trivial implementation.
As it was pointed out, its not function, its type,
SETBUILTIN("bool", &PyBool_Type);
While its __new__ is indeed trivial (in essence, it just calls
PyObject_IsTrue), it also provides needed comparison ops, repr and
other magic methods for the type.
You can check Objects/boolobject.c in python repository if its
implementation is interesting for you.
--
With best regards,
Daniel Kluev
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/text-editor
Alec Taylor writes: > I've tried all the IDEs/text-editors mentioned. Great! Experimenting with them is valuable if you have the time. > Emacs and vim are good, however I often find myself on a workstation > without direct console access. I don't understand this; both of those (unlike most of the less powerful alternatives mentioned in this thread) allow operation via direct windowed application, by remote windowed application, or by remote text-mode application. What is is you think Emacs or Vim are lacking in this regard, and what makes you expect it? > GVim leaves a lot aesthetically desired. Also there's a learning-curve > to both of them They carry a lot of baggage from being decades old. But that speaks more about the mercurial changes in user interfaces of other programs, and the high value programmers who've already mastered a flexible tool place on applying what they've already learned in as many future situations as can be feasible. Both Vim and Emacs are actively and passionately developed, their interfaces are being refined all the time without dramatic overhauls every few years, and that's a huge advantage of these two and is part of what makes them the default choice of so many programmers. > whereas nano, and all the text-editors/IDEs above are user-friendly. As many others in this thread have said, the learning curve pays off in access to a powerful general-purpose tool that you can apply to an enormous range of programming tasks. A reason Vim and Emacs survive while so many thousands of other options rise and fall and are forgotten is in part because Vim and Emacs have gained the maturity and critical mass of community support that ensures you can do just about anything in them. Even if you don't end up liking either of them, you should gain working familiarity with at least one of Vim or Emacs. They are the closest things the programming world has to a standard coding environment and are the most likely to be available and acceptable to your peers where no other familiar option exists. -- \“I got fired from my job the other day. They said my | `\ personality was weird. … That's okay, I have four more.” | _o__) —Bug-Eyed Earl, _Red Meat_ | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: TextWrangler "run" command not working properly
In article , Ernest Obusek wrote: > I'm not a python expert, but you might trying running 'print sys.path' inside > your script and run that from TextWrangler to see where it's looking for > modules. > > - Ernest Hi Ernst, Hi Brian, Thank you for your answers! With the "#!/usr/bin/env python" shebang line now it works! I also had more insights running "print sys.path". I still have to understand how comes, even with this "env trick" TextWrangler isn't able to "find the libraries" if I run a script "in TextWrangler". It only works fine if I use the "Run in Terminal" method. Do you have more details about how TextWrangler manages these commands? Which are its defalut locations? Cheers, Fabio > > > On Apr 14, 2011, at 5:01 PM, Jon Clements wrote: > > > On Apr 14, 9:52 pm, Fabio wrote: > >> Hi to all, > >> I have troubles with TextWrangler "run" command in the "shebang" (#!) > >> menu. > >> I am on MacOSX 10.6.7. > >> I have the "built-in" Python2.5 which comes installed by "mother Apple". > >> Then I installed Python2.6, and left 2.5 untouched (I was suggested to > >> leave it on the system, since "something might need it"). > >> > >> I ran the "Update Shell Profile.command", and now if I launch "python" > >> in the terminal it happily launches the 2.6 version. > >> Then I installed some libraries (scipy and matplotlib) on this newer 2.6 > >> version. > >> They work, and everything is fine. > >> > >> Then, I started to use TexWrangler, and I wanted to use the "shebang" > >> menu, and "run" command. > >> I have the "#! first line" pointing to the 2.6 version. > >> It works fine, as long as I don't import the libraries, in which case it > >> casts an error saying: > >> > >> ImportError: No module named scipy > >> > >> Maybe for some reason it points to the old 2.5 version. > >> But I might be wrong and the problem is another... > >> > >> I copy here the first lines in the terminal window if i give the "run in > >> terminal" command > >> > >> Last login: Thu Apr 14 22:38:26 on ttys000 > >> Fabio-Mac:~ fabio$ > >> /var/folders/BS/BSS71XvjFKiJPH3Wqtx90k+++TM/-Tmp-/Cleanup\ At\ > >> Startup/untitled\ text-324506443.860.command ; exit; > >> Traceback (most recent call last): > >> File "/Users/fabio/Desktop/test.py", line 3, in > >> import scipy as sp > >> ImportError: No module named scipy > >> logout > >> > >> [Process completed] > >> > >> where the source (test.py) contains just: > >> > >> #!/usr/bin/python2.6 > >> > >> import scipy as sp > >> > >> print "hello world" > >> > >> Any clue? > >> > >> Thanks > >> > >> Fabio > > > > http://www.velocityreviews.com/forums/t570137-textwrangler-and-new-python-ve > > rsion-mac.html > > ? > > -- > > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: ipython: Multiple commands on the same line and newlines
Phil Winder writes: > Yes, that does not produce an error, but it does not "work". Please > refer to my first post. Try the first code, you will get a syntax > error. Placing things on one line makes for easy history scrollback. > In your version you will have 2 lines of history for the x = 0 term > and the while ... term. I don't want to have to press up twice, > especially when the code was in the distant past! Also cpaste might be > ok for scripting, but it looks too clumsy to use at the command line. > > Cheers, > Phil Well I guess that's the way it is with the interpreter.. But I don't see the sense in doing everything from there, just write the code to a file and use %edit from ipython to change and run it, it's quite nice and easy too. -- http://mail.python.org/mailman/listinfo/python-list
An unusual question...
Hi coders...
Before I start I don`t expect an easy answer
except "No it can`t be done!".
I have not tried it yet, I`m only asking for opinions ATM.
(Except on the classic AMIGA and it DOES work for that!)
I only want it to work in Linux/?IX. Windblows does
not interest me at all.
OK here we go...
I can easily place a machine code, PURE binary,
routine into Python.
I can also find out where it is EXACTLY just as
easily so this is not my problem.
The problem is calling it!
If I wrote an Assembly(/Assembler) routine to call
this binary code using say the JMP instruction or
using PUSH absolute value and RET, and, call these
"Jump" using:-
os.system("/full//path/to/Jump ")
can I expect a "segmentation error" OR because the
"Jump" command is already inside the Python terminal
would this be considered inside Python`s working memory
from the MMUs point of view?
TIA...
--
73...
Bazza, G0LCU...
Team AMIGA...
http://homepages.tesco.net/wisecracker/
http://main.aminet.net/search?readme=wisecracker
http://mikeos.berlios.de/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/text-editor
Ben Finney writes: > As many others in this thread have said, the learning curve pays off in > access to a powerful general-purpose tool that you can apply to an > enormous range of programming tasks. > > A reason Vim and Emacs survive while so many thousands of other options > rise and fall and are forgotten is in part because Vim and Emacs have > gained the maturity and critical mass of community support that ensures > you can do just about anything in them. > > Even if you don't end up liking either of them, you should gain working > familiarity with at least one of Vim or Emacs. They are the closest > things the programming world has to a standard coding environment and > are the most likely to be available and acceptable to your peers where > no other familiar option exists. > +1 For me simple too often translates to "very dumb" and "limited". The only exception in editors I've found was textmate, simple and well thought while very powerful and customizable. Too bad it was only for OSX and virtually dead (another bad example of great commercial software abandoned). But at the same time I think that everyone has to find its way. When he'll find himself always doing the same stupid and annoying actions because the editor is using is too dumb to have macros/snippets (for example) it should be automatic to look for something else. Some people are happy using a crappy and easy program though, I think you can't really force or convince anyone... -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature suggestion -- return if true
On Sun, 17 Apr 2011 16:21:53 +1200 Gregory Ewing wrote: > My idiom for fetching from a cache looks like this: > >def get_from_cache(x): > y = cache.get(x) > if not y: >y = compute_from(x) >cache[x] = y > return y I prefer not to create and destroy objects needlessly. def get_from_cache(x): if not x in cache: cache[x] = compute_from(x) return cache[x] -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- http://mail.python.org/mailman/listinfo/python-list
Re: An unusual question...
>
> If I wrote an Assembly(/Assembler) routine to call
> this binary code using say the JMP instruction or
> using PUSH absolute value and RET, and, call these
> "Jump" using:-
>
> os.system("/full//path/to/Jump ")
This is calling a different *program* outside of the current Python process. I
don't think it'll do what you want (different memory segments).
I'd start with either using ctypes/libffi or writing my own C extension wrapper
around your good.
HTH
--
Miki Tebeka
http://pythonwise.blogspot.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: Questions about GIL and web services from a n00b
On Apr 15, 6:33 pm, Chris H wrote: > 1. Are you sure you want to use python because threading is not good due > to the Global Lock (GIL)? Is this really an issue for multi-threaded > web services as seems to be indicated by the articles from a Google > search? If not, how do you avoid this issue in a multi-threaded process > to take advantage of all the CPU cores available? First, if you are stupid enough to to compute-bound work in Python, without using a library, you have worse problems than the GIL. How incompetent would you need to be to write multi-threaded matrix multiplication or FFTs in pure Python, and blame the GIL for lack for performance? Second, if you think "advantage of all the CPU cores available" will make difference for an I/O bound webservice, you're living in cloud cookoo land. How on earth will multiple CPU cores give you or your clients a faster network connection? The network connection is likely to saturate long before you're burning the CPU. Sturla -- http://mail.python.org/mailman/listinfo/python-list
Re: Questions about GIL and web services from a n00b
On Apr 16, 4:59 am, David Cournapeau wrote: > My experience is that if you are CPU bound, asynchronous programming > in python can be more a curse than a blessing, mostly because the > need to insert "scheduling points" at the right points to avoid > blocking and because profiling becomes that much harder in something > like twisted. I think Raymond's argument was that multi-threaded server design does not scale well in any language. There is a reason that Windows I/O completion ports use a pool of worker threads, and not one thread per asynchronous I/O request. A multi-threaded design for a webservice will hit the wall from inscalability long before CPU saturation becomes an issue. -- http://mail.python.org/mailman/listinfo/python-list
Re: Questions about GIL and web services from a n00b
On Apr 17, 12:10 am, Michael Torrie wrote: > Many GUI toolkits are single-threaded. And in fact with GTK and MFC you > can't (or shouldn't) call GUI calls from a thread other than the main > GUI thread. Most of them (if not all?) have a single GUI thread, and a mechanism by which to synchronize with the GUI thread. -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature suggestion -- return if true
On Sun, 17 Apr 2011 08:33:47 -0400, D'Arcy J.M. Cain wrote: > On Sun, 17 Apr 2011 16:21:53 +1200 > Gregory Ewing wrote: >> My idiom for fetching from a cache looks like this: >> >>def get_from_cache(x): >> y = cache.get(x) >> if not y: >>y = compute_from(x) >>cache[x] = y >> return y > > I prefer not to create and destroy objects needlessly. > > def get_from_cache(x): >if not x in cache: > cache[x] = compute_from(x) >return cache[x] What object(s) do you think are being created and destroyed needlessly? (This is not a rhetorical question.) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Questions about GIL and web services from a n00b
On 15/04/2011 20:17, Dan Stromberg wrote: On Fri, Apr 15, 2011 at 9:33 AM, Chris H wrote: 1. Are you sure you want to use python because threading is not good due to the Global Lock (GIL)? Is this really an issue for multi-threaded web services as seems to be indicated by the articles from a Google search? If not, how do you avoid this issue in a multi-threaded process to take advantage of all the CPU cores available? Concurrency in Python is a largish topic. It's true that CPython's multithreading is poor. In fact, running a multithreaded CPython application on n vs 2n cores can actually take more time on the 2n cores. However: 1) In Jython, and likely IronPython, threading is good. The load times of Iron Python are ssslllow! (My tests showed startup times 4 to 6 times that of cpython on the same kit). 3) There's something called "stackless" and (similar to stackless) "greenlets". While stackless allows you to use thousands of threads comfortably, it's still pretty single-core. It's essentially a fork of CPython, and is being made a part of PyPy. I believe greenlets are an attempt to bring what's good about stackless to CPython, in the form of a C extension module. Greenlets are green threads - cooperative switching all in one system thread and therefore one core. Very lightweight. 4) I've heard that in CPython 3.2, the GIL is less troublesome, though I've not yet heard in what way. Multiple threads still cannot run at the same time, however, if one thread runs too long without a context switch, it relinquishes control and forces another thread to run. This stops a low priority thread on one core, locking out a high-priority thread on another. That this was happening is why 2 cores can be slower than one. (The overhead of starting the second thread, finding it can't get the GIL and closing down again). 5) Even in CPython, I/O-bound processes are not slowed significantly by the GIL. It's really CPU-bound processes that are. Its ONLY when you have two or more CPU bound threads that you may have issues. Regards Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: An unusual question...
On Sun, 17 Apr 2011 13:15:01 +0100, wisecracker wrote:
> OK here we go...
>
> I can easily place a machine code, PURE binary, routine into Python.
What do you mean by "into Python"? Do you mean patching the Python
compiler? Injecting code into the runtime interpreter? Storing a bunch of
bytes in memory?
What machine code, for which CPU?
> I can also find out where it is EXACTLY just as easily so this is not my
> problem.
And how would you do that?
> The problem is calling it!
>
> If I wrote an Assembly(/Assembler) routine to call this binary code
> using say the JMP instruction or using PUSH absolute value and RET, and,
> call these "Jump" using:-
>
> os.system("/full//path/to/Jump ")
>
> can I expect a "segmentation error"
Almost certainly.
Sorry to be cynical, but if you have to ask these questions, you almost
certainly don't have the skill to successfully pull it off.
Reading your questions is a bit like hearing somebody saying "I have a
Swiss Army Knife. If I poke around here in somebody's chest, can I do a
heart transplant, or do you think they might die?"
> OR because the "Jump" command is
> already inside the Python terminal would this be considered inside
> Python`s working memory from the MMUs point of view?
I don't know. That depends on what you mean by "into Python".
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Feature suggestion -- return if true
On Sun, 17 Apr 2011 19:07:03 +1000, Chris Angelico wrote: > If there's the > possibility of _ANY_ value coming back from the computation, then it > would need to be done as: > > if x in cache: return cache[x] Or you can create a sentinel value that is guaranteed to never appear anywhere else: SENTINEL = object() obj = cache.get(x, SENTINEL) if obj is SENTINEL: obj = calculate(x) cache[x] = obj return obj You can create the sentinel once, at the start of your program, rather than each time. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: An unusual question...
Hi Miki...
>> os.system("/full//path/to/Jump ")
> This is calling a different *program* outside of the current Python process.
> I don't think
> it'll do what you want (different memory segments).
That is what I assumed, that an os.system() call would run in a subshell.
> I'd start with either using ctypes/libffi or writing my own C extension
> wrapper around your good.
Hmm, I was hoping to stay inside a standard Python install.
Thanks a lot...
--
73...
Bazza, G0LCU...
Team AMIGA...
http://homepages.tesco.net/wisecracker/
http://main.aminet.net/search?readme=wisecracker
http://mikeos.berlios.de/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Questions about GIL and web services from a n00b
On Apr 15, 6:33 pm, Chris H wrote: > 1. Are you sure you want to use python because threading is not good due > to the Global Lock (GIL)? Is this really an issue for multi-threaded > web services as seems to be indicated by the articles from a Google > search? If not, how do you avoid this issue in a multi-threaded process > to take advantage of all the CPU cores available? By the way: The main issue with the GIL is all the FUD written by people who don't properly understand the issue. It's not easy to discern the real information from the unqualified FUD. I whish people who think in Java would just shut up about things they don't understand. The problem is they think they understand more than they do. Also, people that write multi-threaded programs which fails to scale from false-sharing issues, really should not pollute the web with FUD about Python's GIL. Java's "free threading" model is not better when all you use it for is to create dirty cache lines that must be reloaded everywhere. Sturla -- http://mail.python.org/mailman/listinfo/python-list
Re: Questions about GIL and web services from a n00b
On Apr 17, 5:15 pm, Ian wrote: > > 5) Even in CPython, I/O-bound processes are not slowed significantly > > by the GIL. It's really CPU-bound processes that are. > > Its ONLY when you have two or more CPU bound threads that you may have > issues. And when you have a CPU bound thread, it's time to find the offending bottleneck and analyse the issue. Often it will be a bad choise of algorithm, for example one that is O(N**2) instead of O(N log N). If that is the case, it is time to recode. If algoritmic complexity is not the problem, it is time to remember that Python gives us a 200x speed penalty over C. Moving the offending code to a C library might give a sufficent speed boost. If even that does not help, we could pick a library that uses multi-threading internally, or we could release the GIL and use multiple threads from Python. And if the library is not thread-safe, it is time to use multiprocessing. Sturla -- http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/text-editor
On Apr 17, 7:09 am, Ben Finney wrote: > Alec Taylor writes: [..] > > whereas nano, and all the text-editors/IDEs above are user-friendly. No they're not 'user-friendly'. They are a user's worst enemy. What's the point of a computer if all you can come up with is a typewriter in disguise? Back to the dark ages. I have not tried all of the above, but a quick peek at nano & imagining I would having to use it for anything beyond _entering_ text and crossing fingers I ever need to change a single comma or fix a single typo sends shivers down my spine. > As many others in this thread have said, the learning curve pays off [..] Ben, I agree wholeheartedly with the rest of your post, but in the case of Vi/Vim... what learning curve..? It takes an hour at most to do the Vim tutorial. Do it, say 3 times and read Bram Moolenaar's 'Seven habits of effective editing' twice and within one week you are already editing (much) more efficiently and with a lot less frustration than with those supposedly 'user-friendly' editors. And contrary to Notepad and its descendants your editing experience will keep improving. Now that is the difference between a _real_ friend a passing acquaintance. Sal. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/text-editor
rusi writes:
[ Notepad -> Emacs ]
> If all one seeks is 'notepad-equivalence' why use any key-binding?
> All this basic ('normal') stuff that other editors do, emacs can also
> do from menus alone.
OK, true. Anyway, I highly doubt anyone using Notepad as an editor is
going to switch to Emacs to begin with :-D.
--
John Bokma j3b
Blog: http://johnbokma.com/Facebook: http://www.facebook.com/j.j.j.bokma
Freelance Perl & Python Development: http://castleamber.com/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/text-editor
Bastian Ballmann writes: > Am Sat, 16 Apr 2011 22:22:19 -0500 > schrieb John Bokma : > >> Yeah, if you bring it down to open a file, save a file, and move the >> cursor around, sure you can do that in a day or two (two since you >> have to get used to the "weird" key bindings). > > Sorry but learning the basic stuff doesnt take any longer than 10 to 30 > minutes and if one doesnt want to learn the shortcuts one can use > GNU/Emacs GUI and click around. My experience is different, but I am sure that we define basic stuff different. Things like how copy paste works, deleting, and undo (and redo!) will take certainly more than 10-30 minutes. Unless you don't want to use those features, that is. Even if you do everything via the menus (and who reads here is going to do that) there are still surprises (where is redo?). > Configuring it to do Python optimal could took some hours / days some > time ago, but now it just takes setting up Emacs for Python and you > have syntax highlighting, code templates, refactoring and > auto-completion support. Yeah, sure. And learning Python takes also just 5 days... Like I wrote, I am still learning Emacs (and Python). And I don't think I am more dense than you. Just more honest about learning ;-). -- John Bokma j3b Blog: http://johnbokma.com/Facebook: http://www.facebook.com/j.j.j.bokma Freelance Perl & Python Development: http://castleamber.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/text-editor
Alec Taylor writes: > Emacs and vim are good, however I often find myself on a workstation > without direct console access. Emacs and vim can also work in a GUI enviroment. > GVim leaves a lot aesthetically desired. Ditto for Emacs. It misses the bling bling. But are you really looking at all those shiny GUI elements when editing? I've turned off the icon bar in Emacs (pointless) and rarely use the menu if ever. -- John Bokma j3b Blog: http://johnbokma.com/Facebook: http://www.facebook.com/j.j.j.bokma Freelance Perl & Python Development: http://castleamber.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: An unusual question...
On Apr 17, 2:15 pm, wrote: > I can also find out where it is EXACTLY just as > easily so this is not my problem. > > The problem is calling it! You'll need to mmap or valloc a page-alligned memory buffer (for which the size must be a multiple of the system page size), and call mprotect to make it executable. Copy your binary code into this buffer. Then you will need to do some magic with ctypes, Cython or C to call it; i.e. cast or memcpy the address of the excutable buffer into a function pointer, and dereference/call the function pointer. If that sounds gibberish, see Steven's comment about heart transplants. Sturla -- http://mail.python.org/mailman/listinfo/python-list
Re: An unusual question...
Hello Steven... I read the whole of your post first and you come across one abrasive character. >> I can easily place a machine code, PURE binary, routine into Python. > What do you mean by "into Python"? Do you mean patching the Python > compiler? Injecting code into the runtime interpreter? No and no. > Storing a bunch of bytes in memory? Not quite but close enough at this point... > What machine code, for which CPU? Is that important when I mentioned MMU at the end of my question? If it is so important then how about 68060 for a starter. >> I can also find out where it is EXACTLY just as easily so this is not my >> problem. > And how would you do that? Why should I reveal that secret at this point, if you want to know, buy an AMIGA without an MMU and run Python to find out where it is - I already know. I`ll give you a clue... id(some_object) is close enough but NOT that close. I'll give you a second clue... the NOP assembly instruction IS important, 0x4e75, two bytes for 68K and 0x90? one byte for x86, again byte, word or long isn't important. >> The problem is calling it! >> can I expect a "segmentation error" > Almost certainly. Thank you! That was all I wanted not the supercilious attitude you have shown with the remainder of your post below, that was unnecessary. > Sorry to be cynical, but if you have to ask these questions, you almost > certainly don't have the skill to successfully pull it off. Quote my RSM:- "Never underestimate you opponent!" > Reading your questions is a bit like hearing somebody saying "I have a > Swiss Army Knife. If I poke around here in somebody's chest, can I do a > heart transplant, or do you think they might die?" Did I ask for that?!? >> OR because the "Jump" command is >> already inside the Python terminal would this be considered inside >> Python`s working memory from the MMUs point of view? > I don't know. That depends on what you mean by "into Python". Someone else understood immediately but maybe for pedanticheads like you I should have written "Python script". Anyhow "no it can't be done" would have been quite sufficient. I am silent on this now as the previous poster already answered.my question. -- 73... Bazza, G0LCU... Team AMIGA... http://homepages.tesco.net/wisecracker/ http://main.aminet.net/search?readme=wisecracker http://mikeos.berlios.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: An unusual question...
Hi Sturla... > You'll need to mmap or valloc a page-alligned memory > buffer (for which the size must be a multiple of the system > page size), and call mprotect to make it executable. > Copy your binary code into this buffer. Then you will > need to do some magic with ctypes, Cython or C to call > it; i.e. cast or memcpy the address of the excutable buffer > into a function pointer, and dereference/call the function > pointer. Many thanks for the sensible reply, Miki has already given me a starter... > If that sounds gibberish, see Steven's comment about heart transplants. He he, I've already said my piece to Steven and will remain silent after this reply to you... Cheers... Off air now... -- 73... Bazza, G0LCU... Team AMIGA... http://homepages.tesco.net/wisecracker/ http://main.aminet.net/search?readme=wisecracker http://mikeos.berlios.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: An unusual question...
It sounds to me like you're trying to pull off a classic buffer overrun and remote code execution exploit, in someone else's Python program. And all I have to say is Good luck to you. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: An unusual question...
On Apr 17, 9:37 pm, wrote: > Hi Sturla... > > > You'll need to mmap or valloc a page-alligned memory > > buffer (for which the size must be a multiple of the system > > page size), and call mprotect to make it executable. > > Copy your binary code into this buffer. Then you will > > need to do some magic with ctypes, Cython or C to call > > it; i.e. cast or memcpy the address of the excutable buffer > > into a function pointer, and dereference/call the function > > pointer. Thats a dense info-filled para! If you make it work (and prove Steve wrong :-) ) please post your how/ what/where here -- We (at least I) would be interested in seeing this work. -- http://mail.python.org/mailman/listinfo/python-list
Re: An unusual question...
On Apr 17, 7:25 pm, Chris Angelico wrote: > It sounds to me like you're trying to pull off a classic buffer > overrun and remote code execution exploit, in someone else's Python > program. And all I have to say is Good luck to you. He might. But this also has reputable use, such as implementing a JIT compiler. E.g. this is what Psyco and PyPy does. Sturla -- http://mail.python.org/mailman/listinfo/python-list
Re: An unusual question...
On Sun, 17 Apr 2011 10:30:01 -0700, rusi wrote: [...] > If you make it work (and prove Steve wrong :-) ) please post your how/ > what/where here -- I'm always happy to be proven wrong. If I was right all the time, that would mean I'd run out of things to learn, and where's the fun in that? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: An unusual question...
Hi Chris... > It sounds to me like you're trying to pull off a classic buffer > overrun and remote code execution exploit, in someone else's Python > program. And all I have to say is Good luck to you. No, not even remotely close... ;o) Note that the idea works on an AMIGA without an MMU. The stumbling block will probably be the MMU on any platform but I haven't tried it yet so I don't knoe for sure. Miki came to the same conclusion as me, that my "Jump" command is running is another subshell so there would be a segmentation fault. Keep guessing... ;oD -- 73... Bazza, G0LCU... Team AMIGA... http://homepages.tesco.net/wisecracker/ http://main.aminet.net/search?readme=wisecracker http://mikeos.berlios.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: An unusual question...
Hi Sturla... > He might. But this also has reputable use, such as implementing > a JIT compiler. E.g. this is what Psyco and PyPy does. I`ll contact you privately... Gimme a bit of time to type a monologue... ;o) -- 73... Bazza, G0LCU... Team AMIGA... http://homepages.tesco.net/wisecracker/ http://main.aminet.net/search?readme=wisecracker http://mikeos.berlios.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: ipython: Multiple commands on the same line and newlines
On Apr 17, 1:11 pm, Andrea Crotti wrote: > Phil Winder writes: > > Yes, that does not produce an error, but it does not "work". Please > > refer to my first post. Try the first code, you will get a syntax > > error. Placing things on one line makes for easy history scrollback. > > In your version you will have 2 lines of history for the x = 0 term > > and the while ... term. I don't want to have to press up twice, > > especially when the code was in the distant past! Also cpaste might be > > ok for scripting, but it looks too clumsy to use at the command line. > > > Cheers, > > Phil > > Well I guess that's the way it is with the interpreter.. > But I don't see the sense in doing everything from there, just write the > code to a file and use %edit from ipython to change and run it, it's > quite nice and easy too. Ok, thanks all. It's a little disappointing, but I guess that you always have to work in a different way when you move to a new language. Andrea's %edit method is probably the best compromise, but this now means that I will have to learn all the (obscure) shortcuts for vi! Cheers, Phil -- http://mail.python.org/mailman/listinfo/python-list
Namespaces in functions vs classes
I apologize if this has been answered before or if it is easy to find in the docs. (I couldn't find it but might have missed it) I'm trying to understand the differences between namespaces in class definitions vs. function definitions. Consider this function: >>> def a(): ... foo = 'foo' ... def g(x): ... return foo ... print g(1) ... >>> a() foo >>> Now, I replace the first "def" with "class": >>> class a(): ... foo = 'foo' ... def g(x): ... return foo ... print g(1) ... Traceback (most recent call last): File "", line 1, in File "", line 5, in a File "", line 4, in g NameError: global name 'foo' is not defined So, the variable "foo" is not available inside the function inside class as it is inside the (inner) function. I figured this was just because the class was still being defined, so I tried this: >>> class a(): ... foo = 'foo' ... def g(x): ... return foo ... >>> x = a() >>> x.g() Traceback (most recent call last): File "", line 1, in File "", line 4, in g NameError: global name 'foo' is not defined >>> which still fails. I had expected that "foo" would be available within the namespace of the object instance. I was wrong. For my final attempt, I add the prefix "a." to my use of "foo" >>> class a(): ... foo = 'foo' ... def g(x): ... return a.foo ... >>> x = a() >>> x.g() 'foo' So, this works and I can use it. However, I would like a deeper understanding of why I cannot use "foo" as an unqualified variable inside the method in the class. If Python allowed such a thing, what problems would that cause? -- Gerald Britton -- http://mail.python.org/mailman/listinfo/python-list
Re: ipython: Multiple commands on the same line and newlines
On 17.04.2011 20:40, Phil Winder wrote: Ok, thanks all. It's a little disappointing, but I guess that you always have to work in a different way when you move to a new language. Andrea's %edit method is probably the best compromise, but this now means that I will have to learn all the (obscure) shortcuts for vi! As you can read in "Python IDE/text-editor" thread. Learning either Vim or Emacs will pay off in the long run, Anyway, IPython honors the $EDITOR environment variable. Just set it to whatever editor you prefer. -- http://mail.python.org/mailman/listinfo/python-list
Re: Namespaces in functions vs classes
On Sun, Apr 17, 2011 at 12:30 PM, Gerald Britton wrote: > I apologize if this has been answered before or if it is easy to find > in the docs. (I couldn't find it but might have missed it) > > I'm trying to understand the differences between namespaces in class > definitions vs. function definitions. Consider this function: > def a(): > ... foo = 'foo' > ... def g(x): > ... return foo > ... print g(1) > ... a() > foo > > Now, I replace the first "def" with "class": > class a(): > ... foo = 'foo' > ... def g(x): > ... return foo > ... print g(1) > ... > Traceback (most recent call last): > File "", line 1, in > File "", line 5, in a > File "", line 4, in g > NameError: global name 'foo' is not defined > > So, the variable "foo" is not available inside the function inside > class as it is inside the (inner) function. I figured this was just > because the class was still being defined, so I tried this: > class a(): > ... foo = 'foo' > ... def g(x): > ... return foo > ... x = a() x.g() > Traceback (most recent call last): > File "", line 1, in > File "", line 4, in g > NameError: global name 'foo' is not defined > > which still fails. I had expected that "foo" would be available > within the namespace of the object instance. I was wrong. For my > final attempt, I add the prefix "a." to my use of "foo" > class a(): > ... foo = 'foo' > ... def g(x): > ... return a.foo > ... x = a() x.g() > 'foo' > > So, this works and I can use it. However, I would like a deeper > understanding of why I cannot use "foo" as an unqualified variable > inside the method in the class. If Python allowed such a thing, what > problems would that cause? Class-level scope is simply never consulted when looking up unqualified names in methods. When looking up such name from within a method, the following scopes are consulted, in order (ignoring some subtleties): 1. Local variables 2. Variables in nested functions 3. Global variables 4. Built-ins For "workarounds" for this, see: http://mail.python.org/pipermail/python-list/2009-December/1228354.html As to why Python works this way, I'm not sure. However, one could cogently argue that this requires you to be more explicit about what the scope is of the name you're referring to; which set of semantics you desire in the face of inheritance, monkey-patching, and instance variable shadowing makes this trickier than you might otherwise think. Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/text-editor
On Sat, 2011-04-16 at 23:12 +, Krzysztof Bieniasz wrote: > > It takes a day or two to learn emacs. > > > > It takes forever to set it up. > > Remember, Emacs is THE way. It's the light in the darkness, it'll save > your soul and bring you happiness. Isn't it worth the trouble? :) > > Seriously though, when I was setting my Emacs to work with Python I > stumbled upon this: > http://pedrokroger.net/2010/07/configuring-emacs-as-a-python-ide-2/ > Read it and you'll know everything you need to know -- at least to start > with. > > KTB No, it's not. Vim is THE way. -- http://mail.python.org/mailman/listinfo/python-list
Re: ipython: Multiple commands on the same line and newlines
Phil,
there is one more way you can run all commands as in linux shell..
>>> import commands
>>> s, o = commands.getstatusoutput('x=10;for i in $(seq $x); do echo $i ;
done')
>>> print o
1
2
3
4
5
6
7
8
9
10
>>>
On Sun, Apr 17, 2011 at 11:40 AM, Phil Winder wrote:
> On Apr 17, 1:11 pm, Andrea Crotti wrote:
> > Phil Winder writes:
> > > Yes, that does not produce an error, but it does not "work". Please
> > > refer to my first post. Try the first code, you will get a syntax
> > > error. Placing things on one line makes for easy history scrollback.
> > > In your version you will have 2 lines of history for the x = 0 term
> > > and the while ... term. I don't want to have to press up twice,
> > > especially when the code was in the distant past! Also cpaste might be
> > > ok for scripting, but it looks too clumsy to use at the command line.
> >
> > > Cheers,
> > > Phil
> >
> > Well I guess that's the way it is with the interpreter..
> > But I don't see the sense in doing everything from there, just write the
> > code to a file and use %edit from ipython to change and run it, it's
> > quite nice and easy too.
>
> Ok, thanks all. It's a little disappointing, but I guess that you
> always have to work in a different way when you move to a new
> language. Andrea's %edit method is probably the best compromise, but
> this now means that I will have to learn all the (obscure) shortcuts
> for vi!
>
> Cheers,
> Phil
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/text-editor
On Sun, 2011-04-17 at 09:08 +1000, Chris Angelico wrote: > On Sun, Apr 17, 2011 at 8:31 AM, Westley Martínez wrote: > > > > Either way doesn't it require python be installed on the system? > > Most Python development is going to require that... > > I'm rather puzzled by this question; I think I've misunderstood it. > You can't run Python programs without a Python interpreter installed. > > Chris Angelico Didn't the OP ask for a portable system, i.e. you can carry everything around on a flash drive and pop it into any computer? Or is he just asking that the editor be portable? -- http://mail.python.org/mailman/listinfo/python-list
Re: Namespaces in functions vs classes
Gerald Britton wrote:
However, I would like a deeper
understanding of why I cannot use "foo" as an unqualified variable
inside the method in the class. If Python allowed such a thing, what
problems would that cause?
8<
"script with possible name clashes"
eggs = 'scrambled eggs'
meat = 'steak'
class Breakfast():
meat = 'spam'
def serve(self):
print("Here's your %s and %s!" %
(eggs, meat))
Breakfast().serve()
8<
What will serve print?
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/text-editor
On 16Apr2011 10:59, Jorgen Grahn wrote: | On Sat, 2011-04-16, Alec Taylor wrote: | > Thanks, but non of the IDEs so far suggested have an embedded python | > interpreter AND tabs... | > emacs having the opposite problem, missing tabs (also, | > selecting text with my mouse is something I do often). | | Does it *have* to be tabs? Why? Both Emacs and Vim can have multiple | files open, and have various powerful ways to navigate between them. If I'm using tabs I tend to use a tabbed terminal emulator (Terminal or iTerm on MacOSX of late), and run vi and shells and python interpreters in various tabs. My normal programming workspace has two terminals side by side - an editing terminal and a "running stuff" terminal. I'm a vi/vim user, though that's just what my fingers are happy with. I'm not an IDE person - I just make my work environment from my preferred editor and some terminals (and, under X11, a good window manager - I like FVWM). That way one can pick the pieces one likes and use them together. Cheers, -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ The more I ride the more I notice and the more fearful I become - somebody on rec.moto -- http://mail.python.org/mailman/listinfo/python-list
Re: Namespaces in functions vs classes
Gerald Britton wrote: For my final attempt, I add the prefix "a." to my use of "foo" class a(): ... foo = 'foo' ... def g(x): ... return a.foo ... The first parameter to any method in a class* is going to be the instance of that class, and is usually named 'self'. So your above code (to stick with your 'x') should be: def g(x): return x.foo or to follow normal naming conventions: def g(self): return self.foo ~Ethan~ *It is also possible to write special methods that take the class as the first argument (classmethod) or don't take either (staticmethod). -- http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/text-editor
In http://docs.python.org/using/unix.html#editors you can read: Geany is an excellent IDE with support for a lot of languages. For more information, read: http://geany.uvena.de/ I followed that suggestion, and am very happy with Geany. But I confess that I am not a sophisticated user. Why does nobody mention Geany ? e -- Egbert Bouwman - Keizersgracht 197 II - 1016 DS Amsterdam - 020 6257991 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/text-editor
Westley Martínez writes: > On Sat, 2011-04-16 at 23:12 +, Krzysztof Bieniasz wrote: > > Remember, Emacs is THE way. It's the light in the darkness, it'll save > > your soul and bring you happiness. Isn't it worth the trouble? :) […] > > No, it's not. Vim is THE way. Clearly there is only one standard text editor, and that's ‘ed’ http://www.gnu.org/fun/jokes/ed.msg>. -- \ “Of all classes the rich are the most noticed and the least | `\ studied.” —John Kenneth Galbraith, _The Age of Uncertainty_, | _o__) 1977 | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
[ANN] Python 2.5.6 Release Candidate 1
On behalf of the Python development team and the Python community, I'm happy to announce the release candidate 1 of Python 2.5.6. This is a source-only release that only includes security fixes. The last full bug-fix release of Python 2.5 was Python 2.5.4. Users are encouraged to upgrade to the latest release of Python 2.7 (which is 2.7.1 at this point). This releases fixes issues with the urllib, urllib2, SimpleHTTPServer, and audiop modules. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of bugs fixed. For more information on Python 2.5.6, including download links for various platforms, release notes, and known issues, please see: http://www.python.org/2.5.6 Highlights of the previous major Python releases are available from the Python 2.5 page, at http://www.python.org/2.5/highlights.html Enjoy this release, Martin Martin v. Loewis mar...@v.loewis.de Python Release Manager (on behalf of the entire python-dev team) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/text-editor
On 04/17/2011 04:19 PM, Ben Finney wrote: No, it's not. Vim is THE way. Clearly there is only one standard text editor, and that's ‘ed’ While it's funny, I'm curious how many folks on c.l.p have done any/much python coding in ed. I've had to do a bit on a router running an embedded Linux that had Python and ed, but no vi/vim. I'm also glad I don't have to maintain that router any more, but I feel I earned my "ed" merit badge at that job :) -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature suggestion -- return if true
D'Arcy J.M. Cain wrote: On Sun, 17 Apr 2011 16:21:53 +1200 Gregory Ewing wrote: def get_from_cache(x): y = cache.get(x) if not y: y = compute_from(x) cache[x] = y return y I prefer not to create and destroy objects needlessly. How does that create objects needlessly? def get_from_cache(x): if not x in cache: cache[x] = compute_from(x) return cache[x] That looks up the cache *twice* for every access. Mine only does one lookup when the item is already in the cache. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Equivalent code to the bool() built-in function
Le 17/04/2011 11:46, Ben Finney a écrit : > candide writes: > >> First because I was doubting the true interest of the bool() type. In >> fact, it appears that it's _semantically_ a shortcut for >> True if x else False. > > That bends my brain. Both ‘True’ and ‘False’ are instances of the ‘bool’ > type. So of course the ‘bool’ constructor will return them. A user of the Python programming language can sensibly handle boolean values and write a lot of good code and at the same time completely ignore all the object oriented stuff behind the True and False instances. > What is the > “shortcut” you refer to? bool(x) is nothing more than a shortcut for the following expression : True if x else False. Compare for instance with the str() type whose implementation is far more complicated. When learning Python, you early and communly use str() type but use sparingly the bool() type. On the other hand, the learner cannot replace himself the service str() provide (hard to write an equivalent code). It's not the case for the bool() type : True if foo else False. > > Remember, the point of a type is to encapsulate both behaviour and an > exclusive domain of possible values. The Boolean type is particularly > simple, so I don't see why you would be surprised that the behaviour of > the ‘bool’ constructor is simple – that's a feature of that type. > In fact, bool() is so simple that at first glance I didn't see any use for it. >> In the orther hand, I'm builting a sort of documentation for learning >> Python. > > Something different fromhttp://docs.python.org/tutorial/>. > More : something _opposite_ to the official Python tutorial ;) I found this tutorial very unfriendly and very unsmooth, poorly structured, providing overloaded examples, unable to distinguish essential from incidental, full of bad explanations, etc. OOP presentation is terribly verbose and speculative, chapter on error handling is very hard to follow if you are not aware of the exception mechanism, etc This is not a surprise, as the abstract explains : "This tutorial does not attempt to be comprehensive and cover every single feature, or even every commonly used feature." The nice graphical aspect of the tutorial (thanks to Sphinx) doesn't compensate the many weaknesses of the content. -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature suggestion -- return if true
On Sun, Apr 17, 2011 at 8:03 PM, Martin v. Loewis wrote: > No, it can't be simplified in this way. > If there is code after that snippet, then > it will get executed in the original version if _temp is > false, but won't get executed in your simplification. Martin, we've been over this! :) And you're a bit late... You said it yourself "If there is code after that snippet" cheers James -- -- James Mills -- -- "Problems are solved by method" -- http://mail.python.org/mailman/listinfo/python-list
Re: Equivalent code to the bool() built-in function
On Sun, Apr 17, 2011 at 8:38 AM, Ben Finney wrote:
> It won't look up the *name* ‘bool’, but it will use that object. Any
> boolean expression is going to be calling the built-in ‘bool’ type
> constructor.
>
> So the answer to the OP's question is no: the function isn't equivalent
> to the type, because the OP's ‘bool_equivalent’ function necessarily
> uses the built-in ‘bool’ type, while the reverse is not true.
Actually, as I was curious myself, I've checked sources and found that
`True if x else False` will _not_ call bool(), it calls
PyObject_IsTrue() pretty much directly.
>>> import dis
>>> def bool2(x):
... return True if x else False
...
>>> dis.dis(bool2)
2 0 LOAD_FAST0 (x)
3 POP_JUMP_IF_FALSE 10
6 LOAD_GLOBAL 0 (True)
9 RETURN_VALUE
>> 10 LOAD_GLOBAL 1 (False)
13 RETURN_VALUE
case POP_JUMP_IF_FALSE:
w = POP();
if (w == Py_True) {
Py_DECREF(w);
goto fast_next_opcode;
}
if (w == Py_False) {
Py_DECREF(w);
JUMPTO(oparg);
goto fast_next_opcode;
}
err = PyObject_IsTrue(w);
Py_DECREF(w);
if (err > 0)
err = 0;
else if (err == 0)
JUMPTO(oparg);
else
break;
continue;
So technically these implementations are equivalent besides the fact
that bool() is type rather than function.
--
With best regards,
Daniel Kluev
--
http://mail.python.org/mailman/listinfo/python-list
Re: Equivalent code to the bool() built-in function
candide writes: > Le 17/04/2011 11:46, Ben Finney a écrit : > > What is the “shortcut” you refer to? > > bool(x) is nothing more than a shortcut for the following expression : > True if x else False. We're going around in circles. I've already pointed out that ‘bool(x)’ is what the expression you're talking about will do behind the scenes for the ‘if x’ clause *anyway*. It's bizarre to call that a shortcut. You seem to expect the documentation to be explicit about everything the implementation does. Either that, or you're not making much sense. -- \ “Pray, v. To ask that the laws of the universe be annulled in | `\ behalf of a single petitioner confessedly unworthy.” —Ambrose | _o__) Bierce, _The Devil's Dictionary_, 1906 | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Equivalent code to the bool() built-in function
candide wrote: bool(x) is nothing more than a shortcut for the following expression : True if x else False. It's a much shorter and easier-to-read shortcut. Also keep in mind that if-else expressions are quite a recent addition to the language. Before that, we had 'not not x' as another equivalent -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Equivalent code to the bool() built-in function
Chris Angelico wrote: Well, of course you can always implement bool as an int; Which Python used to do once upon a time -- and still does in a way, because bool is a subclass of int. The bool type was added mainly to provide a type that prints out as 'True' or 'False' rather than 1 or 0. This can be a considerable help for debugging and keeping the conceptual meaning of one's data clear. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Equivalent code to the bool() built-in function
On Mon, 18 Apr 2011 01:22:59 +0200, candide wrote:
> > What is the
> > “shortcut” you refer to?
>
> bool(x) is nothing more than a shortcut for the following expression :
> True if x else False.
"Nothing more"? That's completely incorrect. bool is a type object, not
an expression, so you can do things like these:
>>> isinstance("Hello world", (float, bool))
False
>>> issubclass(bool, list)
False
>>> types = [str, complex, float, bool]
>>> [f(x) for f, x in zip(types, (1, 2, 3, 4))]
['1', (2+0j), 3.0, True]
For that reason alone, bool is useful.
> Compare for instance with the str() type whose implementation is far
> more complicated.
So what? What's your point? Types and functions don't exist because
they're *complicated*, but because they're *useful*. bool is useful:
in order for True and False to print as True and False, they need to
belong to a type that has that behaviour. bool is that type.
Consequently, calling bool(x) returns a canonical True/False from any
arbitrary object, but that's not the primary purpose for bool existing.
> When learning Python, you early and communly use str()
> type but use sparingly the bool() type.
So what? What's your point?
A little bit of history may make things more clear to you.
Up to version 2.1, Python had no built-in True and False values. This
*almost always* worked fine, since you can always say (e.g.):
if x:
do_something()
elif y or z:
do_something_else()
for any objects x, y and z. But it wasn't quite ideal, because:
* if flags are written 0 and 1, that frequently fools people into
thinking they are meant to be understood as *integer* values rather
than boolean values, and they will do arithmetic on those flags;
* people coming from other languages were confused and worried by
the lack of bools and found it difficult to get used to the
Python truth-testing idiom;
* people would define a standard pair of True/False values at the
top of each module, so they could refer to flags by name rather
than value;
* there was never any consistency, people would write any of:
true = 1; false = 0
FALSE = 0; TRUE = not FALSE
True = -1; False = not True
or whatever other idiom they preferred, or they'd write custom
classes that printed as true/TRUE/True etc.
So in Python 2.2, Python introduced two new built-in names, True and
False, with values 1 and 0 respectively:
[steve@sylar ~]$ python2.2
Python 2.2.3 (#1, Aug 12 2010, 01:08:27)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-27)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> True, False
(1, 0)
>>> type(True)
Then in Python 2.3, Python introduced the bool type, which gave True and
False an independent type ("bool") with a prettier display. For backwards
compatibility reasons, bool is actually a subclass of int, so that code
that does arithmetic on flags continues to work.
The ternary if operator `true-value if flag else false-value` wasn't
introduced until version 2.5.
So as you can see, while you are correct *today* that the function call
"bool(x)" is equivalent to "True if x else False", for at least seven
versions of Python (1.4, 1.5, 1.6, 2.0 through 2.4) that was not correct.
Furthermore, why would you write "True if x else False" (twenty
characters) instead of "bool(x)" (seven characters)? bool is the
canonical way to get an explicit boolean value. It's even shorter than
"not not x" (nine characters), and far more obvious than either of the
alternatives.
You're also correct that there very rarely is a need to explicitly
convert arbitrary objects to booleans. That's okay. That's not why bool
exists, that's just an occasionally useful side-effect.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Feature suggestion -- return if true
Steven D'Aprano wrote: I'm sure you realise that that snippet needlessly recalculates any cached result that happens to be false, but others reading might not. I only use it as written when I'm dealing with types that don't have false values. If I did need to cache such a type, I would use a different test, such as 'if y is None'. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: An unusual question...
On Sun, 17 Apr 2011 17:17:02 +0100, wrote: I`ll give you a clue... id(some_object) is close enough but NOT that close. You do realise that what id() returns is implementation-dependent, don't you? In particular, what IronPython returns isn't an address. -- Rhodri James *-* Wildebeest Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: Equivalent code to the bool() built-in function
Daniel Kluev writes: > Actually, as I was curious myself, I've checked sources and found that > `True if x else False` will _not_ call bool(), it calls > PyObject_IsTrue() pretty much directly. Sure. By ‘bool(x)’ I'm referring only to the implementation inside that constructor. > So technically these implementations are equivalent besides the fact > that bool() is type rather than function. What is confusing me is why on Earth this matters to the OP. -- \“Most people don't realize that large pieces of coral, which | `\ have been painted brown and attached to the skull by common | _o__)wood screws, can make a child look like a deer.” —Jack Handey | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Equivalent code to the bool() built-in function
On Mon, Apr 18, 2011 at 10:22 AM, Steven D'Aprano
wrote:
types = [str, complex, float, bool]
[f(x) for f, x in zip(types, (1, 2, 3, 4))]
> ['1', (2+0j), 3.0, True]
I believe this one would work fine with a function defined as per OP -
zip takes callables, which could be types or functions.
> * if flags are written 0 and 1, that frequently fools people into
> thinking they are meant to be understood as *integer* values rather
> than boolean values, and they will do arithmetic on those flags;
Depending on what you mean by arithmetic, that can be a good thing.
I've frequently, in various languages, used booleans as though they
were integers - for instance, indexing a list with an integer plus a
condition. Contrived example:
mode = 2
...
print ("default", "default-root",
"modeA","modeA-root",
"modeB","modeB-root",
) [mode+mode+(uid==0)]
For debugging output, where I want to keep it as self-contained as
possible, constructs like these are very handy - especially as they
can be embedded inside other expressions.
Every language I've used except BASIC has used True == 1, False == 0,
but I'm sure there are some which use other values. If True == -1,
then you simply subtract the bool from the int instead of adding them.
If it's something else, you arrange the array accordingly.
> * there was never any consistency, people would write any of:
>
> true = 1; false = 0
> FALSE = 0; TRUE = not FALSE
> True = -1; False = not True
Just as long as someone doesn't use:
true = 1; false = -1
which results in the annoying situation that:
if x == false:
is different from:
if x:
But on the plus side, TheDailyWTF.com is never short of publishable material...
Chris Angelico
--
http://mail.python.org/mailman/listinfo/python-list
Re: Namespaces in functions vs classes
On Apr 17, 8:56 pm, Chris Rebert wrote: > On Sun, Apr 17, 2011 at 12:30 PM, Gerald Britton > > > > > > > > > > wrote: > > I apologize if this has been answered before or if it is easy to find > > in the docs. (I couldn't find it but might have missed it) > > > I'm trying to understand the differences between namespaces in class > > definitions vs. function definitions. Consider this function: > > def a(): > > ... foo = 'foo' > > ... def g(x): > > ... return foo > > ... print g(1) > > ... > a() > > foo > > > Now, I replace the first "def" with "class": > > class a(): > > ... foo = 'foo' > > ... def g(x): > > ... return foo > > ... print g(1) > > ... > > Traceback (most recent call last): > > File "", line 1, in > > File "", line 5, in a > > File "", line 4, in g > > NameError: global name 'foo' is not defined > > > So, the variable "foo" is not available inside the function inside > > class as it is inside the (inner) function. I figured this was just > > because the class was still being defined, so I tried this: > > class a(): > > ... foo = 'foo' > > ... def g(x): > > ... return foo > > ... > x = a() > x.g() > > Traceback (most recent call last): > > File "", line 1, in > > File "", line 4, in g > > NameError: global name 'foo' is not defined > > > which still fails. I had expected that "foo" would be available > > within the namespace of the object instance. I was wrong. For my > > final attempt, I add the prefix "a." to my use of "foo" > > class a(): > > ... foo = 'foo' > > ... def g(x): > > ... return a.foo > > ... > x = a() > x.g() > > 'foo' > > > So, this works and I can use it. However, I would like a deeper > > understanding of why I cannot use "foo" as an unqualified variable > > inside the method in the class. If Python allowed such a thing, what > > problems would that cause? > > Class-level scope is simply never consulted when looking up > unqualified names in methods. When looking up such name from within a > method, the following scopes are consulted, in order (ignoring some > subtleties): > 1. Local variables > 2. Variables in nested functions > 3. Global variables > 4. Built-ins > > For "workarounds" for this, > see:http://mail.python.org/pipermail/python-list/2009-December/1228354.html > > As to why Python works this way, I'm not sure. However, one could > cogently argue that this requires you to be more explicit about what > the scope is of the name you're referring to; which set of semantics > you desire in the face of inheritance, monkey-patching, and instance > variable shadowing makes this trickier than you might otherwise think. I don't know but I suspect that the reason is one of optimisation. Functions know what the locally defined names are so when it is compiled it uses the opcode that loads from the local variable namespace. Functions also know what their closure is (that is, the locally defined names of enclosing functions) and can do an appropriate thing in that case. If a name does not fall into either of those two categories it is loaded with the LOAD_GLOBAL opcode. The result of all this is that functions find the correct namespace very quickly. If variables in class scope were to be accessible unqualified from within a method either loading of global names (a VERY common operation) would be made notably slower, or the class namespace would have to be immutable (which I think we can agree would be undesirable), or possibly other, more complicated tradeoffs I haven't considered. This is all just guesswork. As a suitable proxy for the class (i.e. an instance thereof) is available within the local scope of all methods, getting those class variables is quite straightforward really. Personally I find qualifying the scope of variables that aren't globals or builtins to be a restriction that leads to better, clearer code. :-) > Cheers, > Chris > --http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Equivalent code to the bool() built-in function
On 01/-10/-28163 02:59 PM, Daniel Kluev wrote:
On Sun, Apr 17, 2011 at 8:38 AM, Ben Finney wrote:
It won't look up the *name* ‘bool’, but it will use that object. Any
boolean expression is going to be calling the built-in ‘bool’ type
constructor.
So the answer to the OP's question is no: the function isn't equivalent
to the type, because the OP's ‘bool_equivalent’ function necessarily
uses the built-in ‘bool’ type, while the reverse is not true.
Actually, as I was curious myself, I've checked sources and found that
`True if x else False` will _not_ call bool(), it calls
PyObject_IsTrue() pretty much directly.
You miss Ben's point, and got it backwards.
He didn't say that the function will call the bool() type (constructor),
but that it will use the bool type; in other words, it will return True
or False. The one that may not is the function bool().
>>> print bool("143")
True
>>> bool = int
>>> print bool("143")
143
Once bool has been reassigned, calling it may not return True or False
any more.
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Re: Equivalent code to the bool() built-in function
On Mon, Apr 18, 2011 at 11:46 AM, Dave Angel wrote: bool = int > Any language that allows you to do this is either awesome or terrifying. Come to think of it, there's not a lot of difference. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature suggestion -- return if true
On 01/-10/-28163 02:59 PM, Chris Angelico wrote: Sure. In my (somewhat contrived) example of factorials, that's going to be true (apart from 0! = 0); and if the function returns a string or other object rather than an integer, same thing. If there's the Just to be pedantic, by any reasonable definition, 0! == one, not zero. One reference: http://en.wikipedia.org/wiki/Factorial 3rd sentence. More interestingly, There is a gamma function defined for lots of real and complex numbers, which for all non-negative integers matches the factorial: gamma(n) = (n-1)! The gamma function has the same value (1) for one and two, so to be consistent, factorial should have that value for both zero and one. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature suggestion -- return if true
On Mon, Apr 18, 2011 at 12:04 PM, Dave Angel wrote: > On 01/-10/-28163 02:59 PM, Chris Angelico wrote: >> >> >> >> Sure. In my (somewhat contrived) example of factorials, that's going >> to be true (apart from 0! = 0); and if the function returns a string >> or other object rather than an integer, same thing. If there's the > > Just to be pedantic, by any reasonable definition, 0! == one, not zero. > > One reference: http://en.wikipedia.org/wiki/Factorial > 3rd sentence. Hm! I never thought to check the definition... I just coded it up quickly, and didn't even consider the possibility of a zero return until the cache's loophole was challenged. Guess with a more correct definition of factorial, it's even safer in the cache. Question: How many factorial functions are implemented because a program needs to know what n! is, and how many are implemented to demonstrate recursion (or to demonstrate the difference between iteration and recursion)? :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Equivalent code to the bool() built-in function
On Mon, Apr 18, 2011 at 12:46 PM, Dave Angel wrote: > He didn't say that the function will call the bool() type (constructor), but > that it will use the bool type; Actually, he did say exactly that > Any boolean expression is going to be _calling the built-in ‘bool’ type > constructor_ (underscores are mine) >The one that may not is the function bool(). Its not function, its type. There is no wrapper, bool(x) is direct constructor call. > Once bool has been reassigned, calling it may not return True or False any > more. Not sure what did you want to show with this example. You just assigned name in locals() namespace. Boolean type itself didn't change because of that and would still call PyObject_IsTrue() and return according constant. Sure, python allows to change namespaces in very flexible way, but we are talking about specific objects (PyBool_Type) rather than pointers to them. > in other words, it will return True or False. Well, his code explicitly returns True or False, so this was not doubted. Although I agree with Ben that this doesn't have any practical meaning. bool() is more readable and implementation-independent way to do explicit casting to boolean than the hack in OP. -- With best regards, Daniel Kluev -- http://mail.python.org/mailman/listinfo/python-list
Re: PYTHONPATH
Steven D'Aprano wrote: In my opinion, a better explanation for the difficulty faced by Windows users is that this is a side-effect of Windows starting life as a single-user operating system. Yes, that is my opinion as well. Windows for better or worse is plagued by "cruft" that dates back to the CP/M 80 and DOS days. Not just single user systems, but also single-threaded (or single process) systems. When I speak of Windows design, its really a tongue in cheek thing... its really a matter of non-design in my view. Over the years it [windows] has crofted into the technical mess it is today. In retrospect, in many ways this is why I am relatively patient with the Python3 development direction. While I think its non-compatibility may hurt in the short term, the long term goal of stream-lining the language will make for a much better Python future. Essentially, the python team said, "Look, python2 sucks... ," and then they went about figuring out what Python would look like had it been "designed" right in the first place. Whalla, Python3. So after years and years of practical experience with the language Python is getting the face lift it deserves, and is going to be one gorgeous lady when finished. Windows, on the other hand, never had the humility of the Python team in the respect of willingness to change in the face of bloat, or cruft. Windows stuck it out with ultimate backward compatibility issues and a plethora of CP/M DOS carry-overs that are just not helpful... not to mention not realizing that a desk machine can *also* be a server--! In their insane attack on third party browsers their ultimate and quintessential design error was integrating the browser/desktop while designing networking as an application (needing protection from third parties). They should have taken the *nix approach of integrating the network (no third party access to the kernel) and making the desktop an application. In this, gnulinux is the correct design choice (OSX does this as well... based on FreeBSD). Windows may come around in the future; if they survive. There are many reasons for how and why Windows has usability and extensibility issues. At some point I expect to see Microsoft realizing these errors and correcting by completely redesigning their OS. This time around making it open and configurable. They might even get some of the love back... who knows. kind regards, m harris -- http://mail.python.org/mailman/listinfo/python-list
Re: Equivalent code to the bool() built-in function
Chris Angelico: > Dave Angel: > bool = int > Any language that allows you to do this is either awesome or > terrifying. Come to think of it, there's not a lot of difference. Even better: $ python2.7 -c 'False = True; print False' True Alas: $ python3 -c 'False = True; print(False)' File "", line 1 SyntaxError: assignment to keyword -- Ned Deily, n...@acm.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Equivalent code to the bool() built-in function
On Mon, Apr 18, 2011 at 2:40 PM, Ned Deily wrote: > Chris Angelico: >> Dave Angel: >> bool = int >> Any language that allows you to do this is either awesome or >> terrifying. Come to think of it, there's not a lot of difference. > > Even better: > $ python2.7 -c 'False = True; print False' > True http://bofh.ch/bofh/bofh13.html > Alas: > $ python3 -c 'False = True; print(False)' > File "", line 1 > SyntaxError: assignment to keyword Someone in Python3 dev thinks it's a bad idea to shoot yourself in the foot. Remind me some day to finish work on my "ultimate programming language", which starts out with a clean slate and lets the programmer define his own operators and everything. Pro: The expression evaluator can be taught to interpret Dungeons & Dragons notation - 2d6 means "random(1,6)+random(1,6)". Con: The same expression might mean something completely different in another program. Pro: You can do anything. Con: You can do anything. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Equivalent code to the bool() built-in function
On Sun, Apr 17, 2011 at 9:53 PM, Chris Angelico wrote: > On Mon, Apr 18, 2011 at 2:40 PM, Ned Deily wrote: >> Even better: >> $ python2.7 -c 'False = True; print False' >> True > > http://bofh.ch/bofh/bofh13.html > >> Alas: >> $ python3 -c 'False = True; print(False)' >> File "", line 1 >> SyntaxError: assignment to keyword > > Someone in Python3 dev thinks it's a bad idea to shoot yourself in the foot. > > Remind me some day to finish work on my "ultimate programming > language", which starts out with a clean slate and lets the programmer > define his own operators and everything. > > Pro: The expression evaluator can be taught to interpret Dungeons & > Dragons notation - 2d6 means "random(1,6)+random(1,6)". > Con: The same expression might mean something completely different in > another program. > > Pro: You can do anything. > Con: You can do anything. I think someone already beat you to it. They call their invention "Lisp". :-P Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Equivalent code to the bool() built-in function
On Mon, Apr 18, 2011 at 3:49 PM, Chris Rebert wrote: >> Pro: You can do anything. >> Con: You can do anything. > > I think someone already beat you to it. They call their invention "Lisp". :-P Bah! Lisp comes, out of the box, with far too many features! No no no. If you want the + operator to add two numbers, you have to say so! (Obviously there'll be extensive use of #include or equivalent.) It started out as a serious idea - a really clean language that would, like Lua or Python, be nicely embeddable in larger programs - and specifically, I wanted an expression evaluator that could have d-notation added to it. But the realisation that such a language consisted of a foot, a machine gun, and a belt of ammunition kinda led to it being dropped. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: [Q] ipython: Multiple commands on the same line and newlines
Terry Reedy wrote: You can write multiple *simple* statements using ';'. All compound statements, like while, must start on own line. E.g. I want: "x = 0; This is one statement while x< 10: x = x + 1; Lutz has a very nice write-up entitled "Why Indentation Syntax?" Lutz, Mark, "Learning Python: Powerful Object Oriented Programming," 4th ed, (Sebastopol: O'Reilly, 2009), 266 -271. He makes the point clear that only simple statements may be chained together on a single line with ; and that compound statements (like while) "must still appear on lines of their own" (Lutz, 269). It might be nice (as an option) to be able to disengage the forced indentation syntax rules of Python. In other words, provide indentation syntax by default and allow an option via environment variable to engage an alternate (more C-like) blocking syntax. The forced indentation syntax is great for readability (and frankly, I like the appearance /low clutter) but it is inconvenient in some situations, like the one at the top of the thread. Just an idea (probably already been beaten to death long before my time) :) kind regards, m harris -- http://mail.python.org/mailman/listinfo/python-list
Re: [Q] ipython: Multiple commands on the same line and newlines
On Mon, Apr 18, 2011 at 4:01 PM, harrismh777 wrote: > It might be nice (as an option) to be able to disengage the forced > indentation syntax rules of Python. In other words, provide indentation > syntax by default and allow an option via environment variable to engage an > alternate (more C-like) blocking syntax. > You can do that with a future directive. from __future__ import braces That's two underscores before and after the word "future". http://docs.python.org/reference/simple_stmts.html#future-statements Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: Equivalent code to the bool() built-in function
On Sun, 17 Apr 2011 22:49:41 -0700, Chris Rebert wrote: >> Pro: You can do anything. >> Con: You can do anything. > > I think someone already beat you to it. They call their invention > "Lisp". :-P Also Forth. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: An unusual question...
Hi Rhodri... > You do realise that what id() returns is implementation-dependent, don't > you? In particular, what IronPython returns isn't an address. I'm pretty sure I wrote "standard Python" install in one of my replies. Yeah here it is in a reply to Miki... "Hmm, I was hoping to stay inside a standard Python install." -- 73... Bazza, G0LCU... Team AMIGA... http://homepages.tesco.net/wisecracker/ http://main.aminet.net/search?readme=wisecracker http://mikeos.berlios.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Free software versus software idea patents
Steven D'Aprano wrote: software*is* mathematics No it isn't. Yes, it is. (If the machine is particularly simple -- you might be able to exactly simulate a lever in pure mathematics, but simulating, say, a nuclear bomb or a dialysis machine in mathematics is more of a challenge...) I do not disagree with your frustration over what may or may not be simulated by mathematics, within a computer, but that is to misunderstand the thrust of the argument. Essentially what you are saying is that because it is difficult to simulate in software what is evident in pure mathematics that software is somehow not mathematics... if I have understood what you are saying here, then you are absolutely incorrect. If I have misunderstood you, please clarify. We are not talking about what can or can not be simulated--- much less how difficult those simulations might be. The argument is much much simpler than that... please do not over complicate this. What it is that software does is to extend human thought and process over symbol across a machine ALU (the von Neumann funnel). The machine ALU is the medium *only* for the natural and obvious expression of mathematics (relationship over symbol) carried about in the human mind yet extended and expressed across the registers and switches of the machine, rather than markers and white-boards (or black-boards and chalk, if you're as old as I am). Software is comprised of nothing more nor less than mathematics; the human tools of thought and process, relationship over symbol, expressed across the domain of switches and registers in the processor's ALU. This is the part of the argument that Geremy will loath and despise perhaps even more than you do... that what software is comprised of resides at the very heart of the CPU itself... that which we call the von Neumann funnel--- the ALU. It does not matter in the least what is being simulated (H bomb, or word-processor, or spread-sheet, or life automata) no software ever ever ever ever does anything other than logically manipulate registers of bits (ones and zeros) on and off at very high speeds (that's it, nothing more and nothing less). All of this is mathematics, and nothing more nor less. Even addition in the ALU is not computation... it is logical manipulation of 1s and 0s with a bitwise exclusive (xor) function across the register with carry. Whalla, ADD. All logic operations in the ALU of all CPUs are comprised of logical manipulations (algorithms) designed to simulate higher and higher types of functions; regardless of what is simulated, at the core and heart of the CPU is nothing more nor less than logical algorithm(s) expressing relationship over symbol by "software". In fact, the software itself is some of the logical manipulation --- in other words, the software itself is processed in precisely the same ways. Again: Mathematics *is not* software. Software *is* mathematics. kind regards, m harris -- http://mail.python.org/mailman/listinfo/python-list
Re: An unusual question...
On Mon, Apr 18, 2011 at 4:21 PM, wrote: > Hi Rhodri... > >> You do realise that what id() returns is implementation-dependent, don't >> you? In particular, what IronPython returns isn't an address. > > I'm pretty sure I wrote "standard Python" install in one of my replies. > > Yeah here it is in a reply to Miki... > > "Hmm, I was hoping to stay inside a standard Python install." But "standard Python" doesn't necessarily mean any particular implementation thereof. Or did you mean "standard CPython version N.N.N"? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: An unusual question...
On Mon, 18 Apr 2011 07:21:18 +0100, wisecracker wrote: > Hi Rhodri... > >> You do realise that what id() returns is implementation-dependent, >> don't you? In particular, what IronPython returns isn't an address. > > I'm pretty sure I wrote "standard Python" install in one of my replies. IronPython *is* standard Python. As are Jython, PyPy and CPython. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
