extend methods of decimal module
Would it be possible to extend the methods of the decimal module just a bit to include atan(), sin(), cos(), and exp() ? The module has methods for ln() and sqrt(); and that's great! I have done some rudimentary searching of the pep history and I'm not finding any pep related to extending the decimal module with other scientific functions. It is easy to write them in pure python, of course, but I am interested in having the same performance boost with atan(), sin(), cos(), and exp() as I see with the rest of the decimal module on 3.3/ Is it possible anytime sooner than later? By-the-by, my hat is off to the person(s) who did the 3.3 work on the decimal module --- the performance boost is astounding. My agm routine for pi100k (which runs on 3.2.3 2Ghz in 10.5 minutes) runs on the same processor in 42 seconds on 3.3.4/ very nice. -- https://mail.python.org/mailman/listinfo/python-list
Re: IDLE won't run after installing Python 3.3 in Windows
> > Any suggestions? Thanks in advance! > > Switch to Gnu/Linux. Which version of tcl/tk is installed. I would guess that tkinter is honked up somehow... did you clear up the old tkinter stuff? -- https://mail.python.org/mailman/listinfo/python-list
Re: IDLE won't run after installing Python 3.3 in Windows
> > The version of tcl/tk is completely irrelevant as it comes bundled in > > the Python msi installer. > Does the previous version put stuff into the registry that keeps the new version from running correctly? -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
> > The decimal module implements IEEE 854 > Thanks Terry... ... long time. I would like to find out if there is some iron-clad policy about extending the implementation of an IEEE standard... decimal module in this case; I'm just thinking that this particular extension really fits the python "batteries included" philosophy. I guess what I'm really asking for are the same routines found in "bc -l" math library. I've finally moved my number crunching stuff to python (from bc) because the performance of "decimal" is finally way better than bc for the moment, and wrapping python are the math routines for control and processing is so much better. Anyway, sure would be nice to have a very speedy atan() function built-in for decimal. Thanks for the answer... I hope you enjoy the day! -- https://mail.python.org/mailman/listinfo/python-list
Re: IDLE won't run after installing Python 3.3 in Windows
On Tuesday, February 18, 2014 8:56:51 AM UTC-6, eglows...@gmail.com wrote: > Any suggestions? Thanks in advance! > Is there any possibility that you are bumping up against open IDLE Issue 14576? http://bugs.python.org/issue14576 -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
> > Have you looked at the gmpy2 ( https://code.google.com/p/gmpy/ ) module? > > casevh No... was not aware of gmpy2... looks like a great project! I am wondering why it would be sooo much faster? I was hoping that Stefan Krah's C accelerator was using FFT fast fourier transforms for multiplication at least... but, as Oscar pointed out a native python series algorithm runs right along with the built-in (at least for exp() and ln() ) I have not looked at Krah's code, so not sure what he did to speed things up... (something more than just writing it in C I would suppose). Thanks for the heads up on gmpy -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Wednesday, February 19, 2014 4:29:27 PM UTC-6, Oscar Benjamin wrote: > Actually the performance difference isn't as big as you might think. > > Oscar You're right. At least my own benchmark on my native exp() vs the built-in was about ~same ~same. I was hoping that Stefan had used FFT... but I need to talk with him... Thanks for the reply. -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Wednesday, February 19, 2014 4:10:22 PM UTC-6, Terry Reedy wrote: > Or just dmath. I think this is a better idea than suggesting additions > to decimal itself. For one thing, anything put in decimal would be > subject to change if the function were to be added to the standard. It > is worth noting in such a posting that Krah's speedup make such > functions really feasible. The algorithms could be similar, at least > initially, to the one used for floats > > Terry Jan Reedy I have created a project here: https://code.google.com/p/pythondecimallibrary/ I wrote a dmath.py library module for use with the C accelerated decimal module, that I would like to see merged into the C Python distribution so that folks have it by default... without having to pull it down with GIT, or whatever. Anyway, thanks for responding (everyone) and for your consideration. Oh, and one more thing... whoever is doing the work on IDLE these days, nice job! It is stable, reliable, and just works/ appreciate it! Kind regards, Mark H Harris -- https://mail.python.org/mailman/listinfo/python-list
posting code snippets
hi folks, Its been too long... can't remember... are there rules here about posting code snippets, or length considerations, and so forth? Seems like there was a place to share code snips outside of the message area? A related question, is there a python repository for uploading py files, patches, suggestions, etc? What is the correct venue protocol for contributing code source? tnx... happy Thursday! -- https://mail.python.org/mailman/listinfo/python-list
Re: Can global variable be passed into Python function?
On Friday, February 21, 2014 12:37:59 AM UTC-6, Sam wrote: > I need to pass a global variable into a python function. However, the global > variable does not seem to be assigned after the function ends. Is it because > parameters are not passed by reference? How can I get function parameters to > be passed by reference in Python? def func(x): global ref_name ref_name = '3.14159' # rest of the code # rest of the code When you call this function the ref_name reference will be set to '3.14159' as a string and your main code will be able to 'see' it, and other funcs will be able to 'see' it too... play with it a bit... if other funcs need to write to it they will also have to use the global ref_name line. As long as other funcs only read the reference, then the global line is not needed to 'see' the reference. As others have noted, python does not have a 'variable' concept (references to objects instead) and so your question is a little ambiguous. Also, using global references within functions is not a good idea... generally speaking. Cheers -- https://mail.python.org/mailman/listinfo/python-list
Re: posting code snippets
On Thursday, February 27, 2014 9:01:50 AM UTC-6, Jerry Hill wrote: > -- > > Jerry Thanks guys, perfect. 'preciate it! -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Thursday, February 27, 2014 8:42:55 AM UTC-6, Oscar Benjamin wrote: > > Some points: Thanks so much... you have clarified some things I was struggling with... > 1) Why have you committed the code as a .tar.gz file? um, to save space... well, I know its tiny, but its just a habit I have... 5kb instead of 25kb... > 2) This function is not such a good idea: > > def D(numform): > return Decimal(str(numform)) The reason for this is not for strings, but for float literals. All of my functions may take a float literal and things still work, because the D(float) function converts the float literal to a string, which is then passed to the Decimal constructor.so... this works sqrt(0.1) or, sqrt(2.01) Without the D() function float literals may not be passed to the Decimal because it really cannot handle them... 0.1 and others cause it a fit...is there another way to do what I'm looking for here..? > 3) In many places you've written code like this: > > prec=dscale(getcontext().prec +7) > sqr = (D(x).sqrt()).__round__(prec) > retscale=dscale(prec) > The preferred way is: > with localcontext() as ctx: > ctx.prec += 7 > sqr = round(D(x).sqrt(), prec) Thanks... > i.e. use a context manager to restore the context even if an error > occurs and use the round builtin rather than the dunder method. This has confused me, because when I look into the module help text I don't see roun() all I see is __round__(...) how do I know when the round() method exists vs. __round__(...) ?? > 4) You shouldn't be using round/__round__ for precision rounding: it > uses decimal places rather than significant figures. If you want to > round to context precision just use unary +. i.e.: > return +sqr whoohoo! thank you. > 5) The Decimal.sqrt method already rounds to context precision. > There's no need to compute in higher precision and then round it > yourself (in fact you're invalidating the correctness of the rounding > by double-rounding like this). So really it's just: > def sqrt(x): > return Decimal(x).sqrt() ok... > > 6) You should organise it in such a way that you're not progressively > increasing the precision each time one function calls another. right... well, and if you look at the calls to my __atan__ funcs I am assuming that they are still in the context of the calling func atan() right...? so no need to even have the bump up in prec there. > > Oscar thanks Oscar, I really appreciate your comments marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Thursday, February 27, 2014 10:24:23 AM UTC-6, Oscar Benjamin wrote:
from decimal import Decimal as D
> >>> D(0.1)
> Decimal('0.155511151231257827021181583404541015625')
>
hi Oscar, well, that's not what I'm doing with my D()... I'm not just
making D() mimic Decimal... look inside it... there's a str() call
consider the following experiment and you'll see what I'm talking about...
Decimal does not keep 0.1 as a floating point format (regardless of size)
which is why banking can use Decimal without having to worry about the floating
formatting issue... in other words, 0.0 is not stored in Decimal as any kind
of floating value... its not rounded it really is Decimal('0.1').
Ok, so for the experiment: consider this exchange from IDLE:
>>> RESTART ==
>>> from dmath import *
>>> pi = D(piagm(32))
>>> pi
Decimal('3.14159265358979323846264338327950')
>>> pi * Decimal(.1)
Decimal('0.31415926535897934128560682837111')
>>>
>>> pi * D(.1)
Decimal('0.31415926535897932384626433832795')
>>>
>>>
You will notice that Decimal(.1) and my D(.1) work against PI
differently... in fact, Decimal(.1) decimates PI
The reason is that Decimal(.1) stores the erroneous float in the Decimal object
including the float error for .1and D(.1) works correctly because the
D(.1) function in my dmath.py first converts the .1 to a string value before
handing it to Decimal's constructor(s)
Now, try this experiment:again from IDLE and dmath.py
>>> = RESTART =
>>> from dmath import *
>>> pi = D(piagm(32))
>>> pi
Decimal('3.14159265358979323846264338327950')
>>>
>>> pi * Decimal(str(.1))
Decimal('0.31415926535897932384626433832795')
>>>
>>> pi * D(.1)
Decimal('0.31415926535897932384626433832795')
>>>
You see? All of my functions make certain that when the Decimal objects are
created that the string constructor gets called so that, in this case,
.1 really is 0.1 precisely, not floating format.
and take a look at this:
>>> RESTART ==
>>> from dmath import *
>>> D(.1)
Decimal('0.1')
>>>
With my dmath D() function the object holds 0.1 precisely... its not the
float 0.1 rounded ...
shifting gears a bit
The real reason I pushed a commit of a gzip tarball to code.google is because
I've never used code.google before (thought I'd give it a try) and I didn't
realize that its only pull / download is a ZIP... so I am going to take your
advice and remove the tarballs and just put the code up there... if I can get
my GIT to work ... its GIVing me fits (probably because I don't have it
configured right on this system.
Thanks for the discussion... its helping me get this stuff into my brain, and
its giving me a chance to discuss what's at issue between floats and Decimal.
kind regards,
marcus
--
https://mail.python.org/mailman/listinfo/python-list
Re: posting code snippets
On Thursday, February 27, 2014 4:15:16 PM UTC-6, Ben Finney wrote: > > Post your code in-line with your message. This is for the sake of the > people whose time you're requesting, and of later readers who will find > the thread when searching the archives -- URLs to snippets are likely to > be invalid later. > Thanks everyone for the great responses will do. I read this group frequently, but have not posted for quite some time for time and focus reasons. To tell you just how long, well, my isp withdrew the post service (nntp) from their server at end of 2011... and I didn't notice till now! ha! So, I'm not using seamonkey any longer... using google groups/ and that has been a fit to get used to, but I'm making progress. :-} Thanks again -- https://mail.python.org/mailman/listinfo/python-list
Re: Can global variable be passed into Python function?
On Thursday, February 27, 2014 11:54:44 AM UTC-6, Ned Batchelder wrote: > Mark, thanks for helping to answer the OP's question. We've covered (in > depth) in the rest of this thread, that Python *does* have the concept > of a variable, it just behaves differently than some other popular > programming languages (but exactly the same as some other popular > programming languages!) > I do not disagree. I've had the same discussion over the years since using python, and often its a rope soaking contest... some folks get so enamored with the 'way' it works under the covers that they forget how people think about it as they are trying (as normal people) to use the language (instead of BASIC). So, yeah, thinking about variables is just not going away. I finally decided (in my own head) that I would completely give up on the 'variable' concept (intellectually) and help folks try to understand references and reference counting. Knowing that A points to an int, and that B=A, now B points to the VERY SAME int... they are references pointing to the same piece of memory. And of course we want new folks to understand the issue of: A==B True A is B False . and WHY that is or isn't :) it just helps to get the 'variable' idea out of here... it really is something completely different in python. Thanks for the note, kind regards, marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Thursday, February 27, 2014 5:50:55 PM UTC-6, Oscar Benjamin wrote:
> . . . Calling Decimal on a float performs an exact binary to
> decimal conversion. Your reasoning essentially assumes that every
> float should be interpreted as an approximate representation for a
> nearby decimal value.
That is the whole point exactly. Yes, the exact binary to decimal conversion
for float is the problem precisely. But my solution does not assume any such
thing... because the decimal module is "advertised" to support what I'm doing.
In other words, decimal correctly builds from a string literal in any case;
even intermediary values. Well, the digits past 16 (for a double) aren't valid
anyway... and the ones before that (when passed to decimal as a string) get
correctly created as a decimal object.
But here is the other point... I am not planning on passing *any* of these
functions a float... my system that uses dmath uses strings only, or decimals.
str(Decimal) works, as does Decimal(str()). So, I'm not really
interested in floats at all... but, and here's the big BUT, I'm expecting
folks to use dmath.py from the console (as I plan to) and they are going to
punch in *floats*. why? because its natural.
Its just easier to type D(2.78) than Deciaml('2.78').
Neither here nor there but the frustration is the fact that floats are
so 1982. Know what I mean? This is the 21st century, and you know what, we
have got to get past this:
>>>
>>> Decimal(.1)
Decimal('0.155511151231257827021181583404541015625')
>>>
In other words, we need to move to a numeric system of computation (decimal is
a good start) that does not keep track of real values as IEEE floats. Back in
the day, that was ok... today, its unacceptable.
So, Krah has a really nice (and fast) module that will help at least the python
community (and users) to move into the 21st century. My hat is off to Stefan,
that's for sure.
I am going to keep playing with this, and making the changes you have
suggested... I'll put the code back up there on code.google and see if I can
make the repository work like its supposed to..
Thanks again for your assistance, I really appreciate it, Oscar.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Can global variable be passed into Python function?
On Thursday, February 27, 2014 8:07:20 PM UTC-6, Steven D'Aprano wrote: > If they point to the same piece of memory -- which, by the way, can be > moved around if the garbage collector supports it -- then A is B cannot > possibly return False. > hi Steve, long time, yes, my whole point exactly. And we all know what python is doing under the covers for small ints like 0 - 256 ... in which case consider the following: a=128 b=a b=128 a is b True But.. consider this a=1024 b=a b=1024 a is b False For small ints below a certain value (257) A is B will always be True but now for ints above that value, as I've shown, A=257 B=A B=257 A is B False But for the variable discussion (like in BASIC, or even C) A=128, B=A, A and B are two pieces of memory that both happen to be variables containing different pieces of memory. For python, the references to small ints (as above) will almost always point to the same int object for each reference; hence the need for reference counts. Folks that think of assignment in python with a BASIC, or even C, mentality will have trouble understanding the difference between "==" and "is" and why... and they won't get reference counting. Cheers -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Thursday, February 27, 2014 9:15:36 PM UTC-6, Steven D'Aprano wrote:
> Decimal uses base 10, so it is a better fit for numbers we
> write out in base 10 like "0.12345", but otherwise it suffers from the
> same sort of floating point rounding issues as floats do.
>
>
> py> Decimal('1.2345').as_tuple()
> DecimalTuple(sign=0, digits=(1, 2, 3, 4, 5), exponent=-4)
>
> py> Decimal('1234.5').as_tuple()
> DecimalTuple(sign=0, digits=(1, 2, 3, 4, 5), exponent=-1)
>
Steven, thank you, your explanation here is splendid, and has cleared up some
of my confusion about Decimal, and given me a tool besides ('preciate it !) I
did not investigate .as_tuple() nice.
Take a look at this: From IDLE
>>> from decimal import *
>>> s=Decimal(.1)
>>> s.as_tuple()
DecimalTuple(sign=0, digits=(1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
5, 5, 5, 1, 1, 1, 5, 1, 2, 3, 1, 2, 5, 7, 8, 2, 7, 0, 2, 1, 1, 8, 1, 5, 8, 3,
4, 0, 4, 5, 4, 1, 0, 1, 5, 6, 2, 5), exponent=-55)
>>>
>>> s=Decimal('.1')<= .1 as string
>>> s.as_tuple()
DecimalTuple(sign=0, digits=(1,), exponent=-1)
>>>
Big difference, yes?You have hit the nail on the head, because as you say,
it is very unfortunate that the function does not know whether it has been
typed in by hand (a big problem) or whether it comes from an intermediate
calculated result (maybe an even bigger problem. rats().
So, I am thinking I need to mods... maybe an idmath.py for interactive
sessions, and then dmath.py for for running within my scientific scripts... ??
Thanks for your input.
kind regards,
--
https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Thursday, February 27, 2014 10:26:59 PM UTC-6, Chris Angelico wrote: > Create Decimal values from strings, not from the str() of a float, > which first rounds in binary and then rounds in decimal. > Thanks Chris... another excellent point... ok, you guys have about convinced me (which is spooky) but, hey, I'm teachable... what is the best strategy then? Many of the functions of my dmath.py are algorithms which calculate infinite series to convergence out there at some number of precision ... do I make the assumption that all functions will take a string as argument and then let interactive users bare the responsibility to enter a string or decimal... avoiding floats... or use try and toss and error if the rules are not followed, or what?I do see that I'm trying to solve a problem the wrong way,... just not sure what is the better approach. If you get a chance, take a look at the dmath.py code on: https://code.google.com/p/pythondecimallibrary/ I got the repository working correctly for me, and the files can be viewed on-line ... its a long script, but not that hard to look through because all the functions pretty much work the same... when you've seen one converging series function in python you've seen them all! Thanks again, Chris. -- https://mail.python.org/mailman/listinfo/python-list
Re: Can global variable be passed into Python function?
On Thursday, February 27, 2014 10:43:23 PM UTC-6, Chris Angelico wrote: > Simple rule of thumb: Never use 'is' with strings or ints. They're > immutable, their identities should be their values. Playing with 'is' > will only confuse you, unless you're specifically going for > introspection and such. Right. The only time I use "is" is when I'm trying to explain to someone new to python assignment what is happening inside... what Mark Summerfield calls "python's beautiful heart," in his his recent book, "Programming in Python 3" ... a great resource, by the way. -- https://mail.python.org/mailman/listinfo/python-list
Re: Can global variable be passed into Python function?
On Friday, February 28, 2014 9:50:09 AM UTC-6, Steven D'Aprano wrote: > > PS On the topic of enums, when are we getting support for a switch > > statement? > http://legacy.python.org/dev/peps/pep-3103/ > http://legacy.python.org/dev/peps/pep-0275/ > I have reviewed these peps, and I heard Guido's 2007 keynote, as well I have heard him speak on YouTube several times about the inadvisability of a pythonized switch statement (similar to C). I think the real issue is about the syntax... because of python's unique indent strategy going back to ABC, a pythonized switch statement would play havoc with the many text parsers out there used for development (TestWrangler, and many others). Personally I would still like to see a pythonized switch statement at some point. I prefer the syntactical form of PEP 275, but unlike the notion of dropping optimization and converting to if elif else under the proverbial covers, I would prefer to see a conversion to the dict dispatch table under the covers. At any rate... and I don't think even Guido can really argue against this,... a switch statement is just more readable to human beings that a dict dispatch table, or a long if elif chain... and one of the main points of python (going all the way back to ABC) was to make very highly readable code. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Friday, February 28, 2014 8:41:49 AM UTC-6, Wolfgang Maier wrote: > Hi Mark, > > here is an enhancement for your epx function. > > Wolfgang hi Wolfgang, thanks much! As a matter of point in fact, I ran into this little snag and didn't understand it, because I was thinking that outside of memory there should not be any overflow for decimal in python / which means, I suppose, that the C accelerated decimal does have some built-in limitations. So, yes, I got some overflows too... Also, thanks for your comment about my D(str()) function... from Oscar to you, and everyone else... well that has to go. Well, now I gotta get busy and clean this thing up... Thanks again. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Friday, February 28, 2014 2:54:12 AM UTC-6, Wolfgang Maier wrote: > Since by now, I guess, we all agree that using the string representation is > the wrong approach, you can simply use Decimal instead of D() throughout > your code. > Best, > Wolfgang hi Wolfgang, ...right... I'm going to clean it up. Thanks, 'preciate it. -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Friday, February 28, 2014 9:11:49 AM UTC-6, Steven D'Aprano wrote: > >> Now that Python has a fast C implementation of Decimal, I would be > >> happy for Python 4000 to default to decimal floats, and require special > >> syntax for binary floats. Say, 0.1b if you want a binary float, and 0.1 > >> for a decimal. > Steven Yes. ... and for clarification back to one of my previous comments, when I refer to 'float' I am speaking of the IEEE binary floating point representation built-in everywhere... including the processor!... not the concept of tracking a floating point, say in decimal for instance. Isn't it amazing... the IEEE binary float or double is so entrenched (including the processor) that even though it has inherent problems... we are kinda stuck with it for a while. I have been thinking that we need extended instructions in the processor (similar to MMX) to handle accelerating decimal float floating point arithmetic, as in the decimal module. Back in the day when memory was expensive binary floats made sense... but today there is no reason to continue to stick with that limitation. And on the other hand, think of all the amazing things folks have done with floats and doubles... all these years. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Friday, February 28, 2014 12:37:37 PM UTC-6, Chris Angelico wrote: > > Are you aware that IEEE 754 includes specs for decimal floats? :) > Yes. I am from back in the day... way back... so 754 1985 is what I have been referring to. IEEE 854 1987 and the generalized IEEE 754 2008 have the specs for decimal floating point included. Everyone is thinking in the same general direction... its kinda like the Y2K problem based on a stupid limit that because of entrenchment takes forever to resolve moving forward with technological advance. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Friday, February 28, 2014 1:34:27 AM UTC-6, Steven D'Aprano wrote: > Now that Python has a fast C implementation of Decimal, I would be happy > for Python 4000 to default to decimal floats, and require special syntax > for binary floats. Say, 0.1b if you want a binary float, and 0.1 for a > decimal. > > Steven Just a side note on how fast... Stefan Krah's performance specs state 120x improvement on many multiplication computations (like PI for instance)... well, its not hype. On my P7350 dual core 2Ghz Intel box (2009 mac mini) running Gnu/Linux, I used the piagm(n) AGM routine from my dmath.py library to benchmark against my own C routines, BC, and a couple of other math packages. The results were phenomenal... my processor is a low-end gem as compared to modern SOTA processors out there, and even yet: 1 million digits of PI --- 13 minutes 10 million digits of PI --- 3 hours 55 minutes Those were new digit/time PRs for me, by-the-by... and the other methods I've used don't even come close... so, Stefan is doing some kind of transform in "decimal" over and above just compiling the extension in C that is really speeding things up quite a bit. (that was just a random side note, sorry) -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Friday, February 28, 2014 1:39:11 PM UTC-6, Mark H. Harris wrote: > On Friday, February 28, 2014 1:34:27 AM UTC-6, Steven D'Aprano wrote: > > > > > Now that Python has a fast C implementation of Decimal, I would be happy > > > for Python 4000 to default to decimal floats, and require special syntax > > > for binary floats. Say, 0.1b if you want a binary float, and 0.1 for a > > > decimal. > > > > > > Steven > > > > Just a side note on how fast... Stefan Krah's performance specs state 120x > improvement on many multiplication computations (like PI for instance)... > well, its not hype. > > > > On my P7350 dual core 2Ghz Intel box (2009 mac mini) running Gnu/Linux, I > used the piagm(n) AGM routine from my dmath.py library to benchmark against > my own C routines, BC, and a couple of other math packages. The results were > phenomenal... my processor is a low-end gem as compared to modern SOTA > processors out there, and even yet: > > > > 1 million digits of PI --- 13 minutes > > 10 million digits of PI --- 3 hours 55 minutes > Oh, rats(), I forgot the comparison Py3.2 [ 1 million digits : 21 hours 21 minutes ] --> Py3.3.4 [ 1 million digits : 13 minutes ] ... that is astounding. All I did was install 3.3.4, no change in the AGM routine. Cheers -- https://mail.python.org/mailman/listinfo/python-list
Re: Can global variable be passed into Python function?
On Friday, February 28, 2014 1:20:52 PM UTC-6, Marko Rauhamaa wrote: > > Which do *you* find more readable? > Yep, my point exactly. nice illustration. -- https://mail.python.org/mailman/listinfo/python-list
Re: Can global variable be passed into Python function?
On Friday, February 28, 2014 3:03:25 PM UTC-6, Marko Rauhamaa wrote: > > Marko ... and between me and you, here is a snip from dmath.py from the atan(x) function: if (n**2 < D(1)): a = __atan__(n) elif (n == D(1)): a = gpi/4 elif (n == D(-1)): a = -(gpi/4) elif (n < D(-1)): a = __atan__Lt_neg1__(n) else: a = __atan__Gt_1__(n) This if--elif--else is not only ugly, its just not readable either, and besides that, its not elegant, nor is it humanly helpful... its does work though, and its absolutely necessary. ugh. First, its not immediately clear what it does. Well, there isn't just one atan(x) routine, there are at least four of them, depending on whether you're a purist, and they must be selected. Second, because of the strict intent ideology of python in the first place, I can't indent this code to make it more readable without breaking python's syntax. Third, this is a VERY simple if elif block. More complex ones are much worse... for human reading that is... I know its a pain in the neck, but python does need a switch statement. Is it a stubborn question? I don't really think that almost every modern computer language has a switch block because of some C paradigm. I think its because most coders find them useful, at least readable, and therefore essential. On the other hand, I have coded many scripts and lots of commercial software that used no switch blocks at all... particularly my C++ and Java stuff. Sooo... -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
On Thursday, February 27, 2014 10:01:39 AM UTC-6, Eric Jacoboni wrote:
>
> ('spam', [10, 30, 20], 'eggs')
>
> I get a TypeError for an illegal operation, but this operation is still
>
> completed?
hi Eric, others have answered your question specifically, but the issue (which
is recurring) begs a couple of questions, which will also be recurring... ehem.
This little snag (if it can be called that) is a side effect from two python
inherent design considerations:
1) not to be a nudge, but dynamic typing is the first...
2) and the concept of immutability is the second.
I'll address the second first by asking a question... should an immutable type
(object) be able to hold (contain) mutable objects ... should tuples be allowed
to hold lists?
lists within a tuple should be converted to tuples.If you want a tuple to
hold a list, make it a list in the first place. Tuples should not be
changed... and as you point out... half changing a tuple is not a good
condition if there is an exception...
Which brings me to my second point... dynamic binding... (and everything
associated with that) is at play here too please, don't get me wrong,
this is not flame bait and I'm not advocating static binding, nor do I want
static binding, nor do I want to open that can of worms again... just saying.
I really think this is a bug; honestly. IMHO it should be an error to use +=
with an immutable type and that means not at all. In other words, the list
should not even be considered, because we're talking about changing a tuple...
which should not be changed (nor should its members be changed).
S the type does not support item assignment, yet the item got
assigned. This is at least inconsistent... and to my small mind means... bug
report.
:)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Can global variable be passed into Python function?
On Friday, February 28, 2014 6:40:06 PM UTC-6, Ned Batchelder wrote: > > I don't understand: you show an if/elif chain that cannot be expressed > as a switch statement (because it uses < ), and then conclude that > Python needs a switch statement? That doesn't make any sense. > Forgive me. I would rewrite the structure, switch x: case GT_1: __atan__Gt_1__(x) case LT_1: __atan__Lt_1__(x) case IS_1: a = gpi/4 case IS_n1: a = -gpi/4 default: __atan__(x) or somesuch... way better... yes, there are some issues, but all workable with some effort marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Can global variable be passed into Python function?
On Friday, February 28, 2014 7:10:49 PM UTC-6, Mark Lawrence wrote: > I think you're talking nonsense. I've been happily using dict dispatch > tables for years and, like Steven and presumably many others, find them > dead easy to read. Perhaps you should invest in a better optician > and/or glasses? > That's the rub right there... yes, they are easy to read for someone who uses them for many years... but not to the average coder, or scientist who just happens to be using python (like she may have used BASIC in the past, or someone else who has no idea at this stage of their python career what a dict is, let alone what a dict dispatch table is (I like to think of virtual function table myself, which its not) ... that is really the point. Readability is important when the reader needs eye glasses... that is the whole point in a nutshell. -- https://mail.python.org/mailman/listinfo/python-list
Re: Can global variable be passed into Python function?
On Friday, February 28, 2014 8:15:38 PM UTC-6, Ned Batchelder wrote: > Mark, if you are going to advocate for a feature, find a good use case, > this one is absurd. Where did the constants GT_1 etc, come from? Not at all. Think of the C switch block... if you read about it in the K & R you'll think its useless... because it can only switch on a SINGLE character. So, to make it work what do you do??? You create some constants that are actually really and totally just a number... one character... that represents GT_1 or anything else. The switch block "switches" on a character in C. In python it could switch on absolutely anything we like... the point is not how it switches... but how it "looks" to human beings, and "maybe" how it performs. For me its more important that code be readable first and foremost... then optimized. Yes, I can use if elif else blocks and I can and do use dict dispatch tables but I "wish" there were a switch case default block in python so that some things could be coded to be clearer to a human reader. just sayin... not arguing though... just a comment. -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
On Friday, February 28, 2014 7:27:17 PM UTC-6, Eric Jacoboni wrote: > I agree with that too... My error was to first consider the list, then > the tuple... I should have considered the tuple first... > Anyway, the TypeError should rollback, not commit the mistake. I believe so too, but I'm not one of the core devs. And they do not agree. Ever since day one with me and python I have questioned whether a tuple even makes sense. Well, certainly it does, because it has so much less overhead and yet it acts like a list (which for so many situations thats really what we want anyway... a list, that never changes). Tuples are great, for what they are designed to do. But now consider, why would I purposely want to place a mutable object within an immutable list? A valid question of high importance. Why indeed? I really believe IMHO that the error should have come when you made the list an item of a tuple. An immutable object should have NO REASON to contain a mutable object like list... I mean the whole point is to eliminate the overhead of a list ... why would the python interpreter allow you to place a mutable object within an immutable list in the first place. This is just philosophical, and yes, the core dev's are not going to agree with me on this either. I think the situation is interesting for sure... and it will surface again, you can count on that. Cheers -- https://mail.python.org/mailman/listinfo/python-list
Re: Can global variable be passed into Python function?
On Friday, February 28, 2014 8:01:45 PM UTC-6, Chris Angelico wrote: > > Does your switch construct have to handle the magic of GT_1 meaning "> > 1", or do you first figure out where it falls with an if/elif tree? > ChrisA hi Chris, yeah... well think again of the switch block in C... the switch block selects a branch based on an integral number (int character) that is generally a return code from a function. The function hides all of that logic. The function runs and returns a "number" which is passed to the switch block. That number generally corresponds to a DEFINE constant at the top or in the header... so we get something really readable: x = somefunc() switch (x): case: CONSTANT1 call blah blah case: CONSTANT2 call blah blah blah default blah This very same concept can work in python code too... if everyone would just agree to try. Again, how it switches is less important than does the "switch" appear readable to humans... whether its optimized or not. Its up to the devs whether it switches on an int, a "switch object" whatever I mean by that, or on something else I have not thought about... the point is , ... can we make something more readable to average people than large if elif else chains, or dict dispatch tables... ?? Its just a question. I know Guido thinks not... and a lot of other people too... but what if there is a third option? If we think about this hard enough there is probably a win win out there that would work/ just sayin marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
On Friday, February 28, 2014 11:34:56 PM UTC-6, Ian wrote: > One very common example of tuples containing lists is when lists are > passed to any function that accepts *args, because the extra arguments > are passed in a tuple. A similarly common example is when returning > multiple objects from a function, and one of them happens to be a > list, because again they are returned in a tuple. > def f(*args): > print(args) > return (args[1:] > > >>> result = f(1, 2, 3, [4, 5]) > (1, 2, 3, [4, 5]) > >>> print(result) > (2, 3, [4, 5]) I agree Ian... good points all. ... again, I'm not arguing with anyone... just saying that an error (whatever we mean by that) should not half-way-fail we are only pointing out the problem... we have not idea what the solution is yet. Intuitively everyone can see that there is a problem here... the debate cannot be answered either because of the inherent design of python (almost all of which we love). So, as they say, what is a mother to do? ... I mean, some people's kids... I don't know how I propose to handle the problem... I think the first step is getting everyone to agree that there IS a problem... then debate how to tackle the solution proposals. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
On Friday, February 28, 2014 11:16:18 PM UTC-6, Ian wrote: > How would you propose doing that? Bear in mind that while Python > knows that tuples specifically are immutable, it doesn't generally > know whether a type is immutable. hi Ian, consider the problem... its a "cake" and "eat it too" scenario... you can't have your cake and eat it too This is what I mean... the error message is telling the user that it cannot do what he has requested, and yet IT DID. You have one of two scenarios: 1) the message is arbitrarily lying and it really can assign an immutable's item... (and it did!) or 2) It really should NOT assign an immutables item (the message is truth) but the action was "allowed" anyway despite the protocol and accepted policy... in which case the two scenarios add up to a giant logical inconsistency... QED a bug. There really is no way to get around this from the average user's perspective. And therefore, this is going to come up again and again and again... because coders don't like unexpected logical inconsistencies. It is not helpful either to explain it away by knowing how the policy works under the covers... the average user of the python language should not have to understand the policy of the underlying substructure... 1) either they can't assign the list item of an immutable tuple type (and the action is a flaw, say bug of 2) they really CAN set the immutable's list item type (which it did!) and the message is bogus. Its one way or the other we can't have our cake and eat it too... this is (one way or the other) a bug. IMHO -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
On Friday, February 28, 2014 11:16:18 PM UTC-6, Ian wrote: > How would you propose doing that? Bear in mind that while Python > knows that tuples specifically are immutable, it doesn't generally > know whether a type is immutable. I was going to bed, and then thought of the solution. Allow the action. Hold the error pending until the action either succeeds or fails for the "item," in this case a list, and then post the error for the tuple depending... this would make the whole mess consistent, and even compatible with the idea of dynamic name and type binding... So, in other words, the action should be permitted, and actually was allowed, and the message is incorrectly reporting something that for this particular "item" is NOT true. The error message (and timing of same) is the bug (philosophically). Under the covers it may be (and probably is) more complicated. Good night everyone. Cheers -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
On Saturday, March 1, 2014 8:54:43 AM UTC-6, Mark Lawrence wrote: > you're also using google groups... it doesn't wrap paragraphs > > correctly... please read and action this > > https://wiki.python.org/moin/GoogleGroupsPython... it does wrap > > paragraphs correctly... it also prevents us seeing double line spacing... > > > > do you get my drift??? > hi Mark, yes, I understand. I am using google groups (for the moment) and it does not wrap correctly, at least not on my end. It also adds additional carrots > that make replying difficult. The elipses thing is a bad habit which I 'picked up' in academia lately. We use elipses frequently in papers (also this---which also annoys people) and there is no problem. In a writing context the elipses seem to function for some people (intentionally) as 'um'. When humans speak they use the word 'um' to pause between though context and its usually unintentional at the surface. Often when I write the elipses (...) show up for the same reason. I really don't know that I'm doing it... it just happens. So, I am working on it. No, you're not the first to mention it. Its one of my many flaws. Thanks for keeping me accountable. Enjoy the day! marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
On Friday, February 28, 2014 11:16:18 PM UTC-6, Ian wrote: > How would you propose doing that? Bear in mind that while Python > knows that tuples specifically are immutable, it doesn't generally > know whether a type is immutable. hi Ian, I thought of something else after I slept on it, so to speak. Consider this: >>> s=(2,3,[42,43,44],7) >>> s[2] [42, 43, 44] >>> s[2] is a list. We should be able to change s[2] even though its within a tuple, like the: [42, 43, 44] >>> s[2].append(45) >>> s[2] [42, 43, 44, 45] <= no error >>> or like this: >>> s[2] [42, 43, 44, 45] >>> s[2]=s[2]+[46] Traceback (most recent call last): File "", line 1, in s[2]=s[2]+[46]<==error, but look below== TypeError: 'tuple' object does not support item assignment >>> >>> s[2] [42, 43, 44, 45]<=also no change to list !! >>> The point I'm trying to make with this post is that s[2]+=[46] and s[2]=s[2]+[46] are handled inconsistently. In each case (whether the list is part of a tuple or not) s[2] is a valid list and should be mutable. In every case, in fact, it is. In each case, in fact, the change might occur. But, the change occurs in the first case (append) without an error. The change occurs in the next case too (+=) but with an error not related to the tuple. The change does not occur in the third case (s=s+ with an error) but the list is not changed ! We all know this is not good. We also all know that its because of implementation details the user/coder should not need to know. QED: a bug. Having slept on it, I am remembering my Zen of Python: Errors should never pass silently, unless explicitly silenced. It looks to me like (+=) in this case is not being handled correctly under the covers. At any rate the three scenarios of trying to change a mutable list as an immutable tuple item should be handled consistently. Either we can change the tuple item (if its a list) or we can't. Also, if we cannot then the expected error should be consistent. Wow. I think I got that whole thing out without one elipses. Cheers -- https://mail.python.org/mailman/listinfo/python-list
Re: Can global variable be passed into Python function?
On Saturday, March 1, 2014 12:24:15 AM UTC-6, Chris Angelico wrote: > much code. If you want to change anything, you potentially have to > > edit three places: the list of constants at the top, the condition > > function, and the switch. > > > > This can't be your idea of readability. Show me where I'm wrong. > > > > ChrisA hi Chris, I don't think you're wrong. There are two issues for me (and one of them is not how the switch is implemented). 1) Is it easier for average users of python as a language to read switch case default, or if elif else ? 2) Would most average users concur that 'readable' means something like, "readily understandable at quick glance, or rapid preview" (or quiv). I readily admit that 'subjective' is the operative work here. As Guido found at his 2007 keynote most experienced devs are not clamoring for a switch block. Just so. But I'm not thinking of experienced devs. I'm thinking of the average coder who is used to looking at switch blocks. I personally can see and understand a switch block 2x to 3x faster than looking at an elif chain. Because I am primarily a C programmer and I personally use and read switch blocks. An experienced python dev can readily 'see' an elif chain, well, because that's all they have and that's all they look at day to day. So, naturally a python dev is going to think an elif chain is readable. Thank you sir, you have good insights. A quote from the high seas is classy. (another post with no elipses) Cheers -- https://mail.python.org/mailman/listinfo/python-list
Re: Can global variable be passed into Python function?
On Saturday, March 1, 2014 4:01:12 PM UTC-6, Mark Lawrence wrote: > > No elipses, just the paragraphs not wrapped and the double line spacing. > > Good old gg, I just love it. How do I fix it? Is there a setting someplace? I tried pulling up the page you linked, but blank. Thanks in advance. -- https://mail.python.org/mailman/listinfo/python-list
Re: Mac vs. Linux for Python Development
On Sunday, February 23, 2014 2:43:14 AM UTC-6, twiz wrote: > I'm sure this is a common question but I can't seem to find a previous thread > that addresses it. If one one exists, please point me to it. My personal preference for writing and testing python code is Gnu/Linux as a platform (free libre open easier to build from C sources etc). As an editor, VI of course. Although, I can honestly say I've been using the latest GNU Emacs lately. It has a very nice python mode. I also use TextWrangler from time to time (can be extended with scripts and it has the same 'feel' as the IDLE editor (kind-of). The main problem you will see with OSX (if you're not careful) is that IDLE will be unstable. To be fair about it, its not IDLE's problem, per se. Its about tcl/tk tkinter. DO NOT use the built-in tcl that comes from Apple, nor the one that comes through the Apple store! Actually go to the Active TCL site and download the version related to your system (yes there is a different one depending on 10.5 10.6 etc). Py3.3.4 and the latest Active TCL are stable on OSX 10.6 or higher. I have been very pleased with IDLE on both Gnu/Linux and OSX ( I refuse to use Windows ever again, ever) and my latest experience has been fabulous, really. My hat is off to the folks that have made IDLE the simple stable and powerful IDE that it is. I am being genuine about this. Another reason for using Gnu/Linux (and/or OSX) is that generally they are faster. Faster loading, and faster running. Serious. I have been hearing of (4) second import times for decimal, for instance. Its almost instantaneous on Gnu/Linux, or OSX. Also, run times are considerably faster. That has less to do with the Windows version of python, and more to do with the Windows version. YMMV If you want to extend your python code with C (as many of us do) well OSX and/or Gnu/Linux are your best bets there too, and frankly Gnu/Linux is the better of the two (from personal experience). OSX 10.6 uses the GNU gcc compiler by default, but the Apple idiosyncratic approach to builds can be annoying. Although, its minimal really (hardly worth mentioning). If you want to build python from sources (as many of us do) my personal opinion is also that Gnu/Linux is the way to go there too. I agree with most of the rest of the posts here that personal preference is at play primarily. Your editor run environment is going to be more important to you than your platform. There is one main difference to that, and it has to do with what you're used to. In IDLE on Gnu/Linux the menu options are on the top of the IDE. In OSX they are on the OSX tool bar at top left (where they are for every other OSX app). OSX guys don't mind this, but Gnu/Linux guys hate it (sometimes). Also, the menu items on Gnu/Linux can be 'torn' off (its a tcl/tk tkinter thing) and on OSX that does not work. Also the 'Options' menu item on OSX has nothing in it. The Options menu is in Preferences in the IDLE drop down on the OSX tool bar. Other than those things, I have spent many cheerful hours in the OSX IDLE editor and have been happy as a clam. Same goes for the Gnu/Linux IDLE editor. If you want to use terminals on OSX you'll want to install Quartz and run the terminal on the emulated X environment. It works better for python IMHO. The built-in terminal for OSX need serious configuring (which is possible) because its color is bad, and its tiny by default, with a crummy font. All of that can be changed, but it just works better to use XQuartz. Enjoy Cheers -- https://mail.python.org/mailman/listinfo/python-list
Re: Can global variable be passed into Python function?
On Saturday, March 1, 2014 4:36:07 PM UTC-6, Ben Finney wrote: > Since when is the absence of action an "attempt" to do anything? > > You're assuming the not-doing of something must have a purpose. That > assumption doesn't seem justified. Correct. Argument from silence is logical fallacy; lack of motion is not the "doing" of being motionless. :) -- https://mail.python.org/mailman/listinfo/python-list
Re: Can global variable be passed into Python function?
On Saturday, March 1, 2014 5:21:57 PM UTC-6, Mark Lawrence wrote: > https://wiki.python.org/moin/GoogleGroupsPython Thanks, Mark. Whoohoo! Looks like gg has some work to do. rats(). Ok, so I'm typing away here and when I get to the boarder I should press the enter key so that the text is forced to wrap to the next line so that you don't see the text as a run-off the page nuisance and complete annoyance leading to homicidal rage and/or other illicit behaviors like nail-biting. How does this look on your news client. I just need to setup an nntp server and use a real client. Thanks for your input Mark. Peace. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: extend methods of decimal module
On Saturday, March 1, 2014 12:55:07 AM UTC-6, Anssi Saari wrote: > I recently watched a presentation by Jessica McKellar of PSF about what > Python needs to stay popular. Other than the obvious bits (difficulties > of limited support of Python on major platforms like Windows and mobile) > the slight lack of perfection in IDLE was mentioned. Specifically the > old blog post titled "The Things I Hate About IDLE That I Wish Someone > Would Fix" at > http://inventwithpython.com/blog/2011/11/29/the-things-i-hate-about-idle-that-i-wish-someone-would-fix/ hi Anssi, this discussion really doesn't belong in this thread, but I'll give you my two cents on it anyway, just because I put the random comment in here to begin with. The blog link which you posted is quite old, and yes, as I remember back to the 2009-2011 time frame IDLE had some problems with stability and some other issues related to tkinter. My experience with IDLE today is one of stability usefulness; clean and simple. Like that FORD commercial here in the States, " Have you driven and IDLE lately?" Some of the bloggers 'hates' are actually features of IDLE and we really don't want to change them. Some of them have been fixed. Some of them are annoyances not with IDLE per se, but with tcl/tk and are a tkinter thing. For instance, the blogger 'hates' the menu tear-off feature. I love it. All of my tcl/tk apps have tear-off menus; its totally a tkinter thing and if you're not used to apps written with the tk library then this 'feature' may annoy you. The IDLE concept was to have an IDE written in pure python that would use the tk library. If you've not written any code using the tk library then try it. GUI apps can be built with the tk library (with either tcl, or with python, and others) that are reduced to a few lines of code vs. many pages of code. In two pages of tk coding I can create a GUI app that would use 16 pages of code written in C, and 8-16 pages of code written in C++ or Java. The down-side to the tk library is that the GUI work they do for you under the covers (which is extensive by the way) makes some assumptions and simplifies the options. So, you trade off the speed and efficiency of writing the app and getting it to market quickly, with not having the explicit control over the GUI that you might have if you had written the code to Q, or GTK, or some such. Producing IDLE using tk was genius on the part of Guido initially. The tradition has been kept up, but has not received the priority that other python issues have received. By the way, there are other python IDEs out there (I don't use them, just pointing out that they are available). IDLE is free, its efficient, and for the moment its also very stable and highly useful. If you have not driven an IDLE lately, give it a try. Also, my experience with the devs on IDLE (and particularly Terry Reedy) is that they have been very responsive, helpful, even courteous and professional. So, I think the blogger was a little too harsh. Cheers -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
On Saturday, March 1, 2014 3:21:44 PM UTC-6, Mark H. Harris wrote: > On Friday, February 28, 2014 11:16:18 PM UTC-6, Ian wrote: hi Ian, I thought of something else after I slept on it, so to speak. Consider this: >>> s=(2,3,[42,43,44],7) >>> s[2] [42, 43, 44] >>> s[2] is a list. We should be able to change s[2] even though its within a tuple, like this: [42, 43, 44] >>> s[2].append(45) >>> s[2] [42, 43, 44, 45] <= no error >>> or like this: >>> s[2] [42, 43, 44, 45] >>> s[2]=s[2]+[46] Traceback (most recent call last): File "", line 1, in s[2]=s[2]+[46]<==error, but look below== TypeError: 'tuple' object does not support item assignment >>> >>> s[2] [42, 43, 44, 45]<=also no change to list !! >>> The point I'm trying to make with this post is that s[2]+=[46] and s[2]=s[2]+[46] are handled inconsistently. In each case (whether the list is part of a tuple or not) s[2] is a valid list and should be mutable. In every case, in fact, it is. In each case, in fact, the change might occur. But, the change occurs in the first case (append) without an error. The change occurs in the next case too (+=) but with an error not related to the tuple. The change does not occur in the third case (s=s+ with an error) but the list is not changed ! We all know this is not good. We also all know that its because of implementation details the user/coder should not need to know. QED: a bug. Having slept on it, I am remembering my Zen of Python: Errors should never pass silently, unless explicitly silenced. It looks to me like (+=) in this case is not being handled correctly under the covers. At any rate the three scenarios of trying to change a mutable list as an immutable tuple item should be handled consistently. Either we can change the tuple item (if its a list) or we can't. Also, if we cannot then the expected error should be consistent. Cheers Hi , I'm experimenting a bit with TextWrangler and gg to see if I can at least solve my double spacing and wrap problems with cut a paste for the moment. Looks ok? Thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
On Saturday, March 1, 2014 8:04:32 PM UTC-6, Eric Jacoboni wrote: > > > In fact, i think i'm gonna forget += on lists :) hi Eric, well, that might be extreme, but you certainly want to avoid trying to change an immutable. Something you might want to consider is trying something like creating a new immutable. In the example we've been looking at I think I would change the tuple list item with an append(); however, you might try building a new tuple instead of trying to change an existing tuple item. I must admit that I would never have found this bug myself, because I don't try to change tuples (at all). Anyway, I'm glad you found it -- we all learn and that's the good news. Cheers -- https://mail.python.org/mailman/listinfo/python-list
python decimal library dmath.py v0.3 released
hi folks, Python Decimal Library dmath.py v0.3 Released https://code.google.com/p/pythondecimallibrary/ This code provides the C accelerated decimal module with scientific/transcendental functions for arbitrary precision. I have also included pilib.py which is a PI library of historic algorithms for generating PI, which uses dmath.py. I wish to thank Oscar, Wolfgang, Steven, Chris (and others) for the help you gave me understanding decimal, particularly format, rounding, and context managers. Everything is documented well (including issues) on the code site, and things are working better, and are certainly cleaner. No doubt there are still bugs, but its getting closer. Thanks again. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: python decimal library dmath.py v0.3 released
On Monday, March 3, 2014 5:34:30 AM UTC-6, Mark H. Harris wrote: > hi folks, Terry, I posted this mod as an idea on python-ideas, as you suggested. Also, I made the additional suggestion that decimal floating point be considered as the primary floating point type for python4.x, with an optional binary floating type (2.345b) if the user might like that. As Steven pointed out last week, we have a fast module now for decimal floating point; it seems this is a good time to consider this as a serious idea for future python(s). marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Reference
On Monday, March 3, 2014 3:42:30 AM UTC-6, ast wrote: > Consider following code: > > >>> A=7 > >>> B=7 > >>> A is B > True The names A and B are both bound to the same object (7). You will discover that this is True for all small ints less than 257; on CPython3.3.4. I just checked it. :) Its just more efficient to do this for small ints because they are immutable (1) and because they are used for frequently (2). As somebody pointed out last week, don't use "is" for ints and strings (generally speaking). Value is what's important here, not identity. My python coding is yet simple and straight forward enough that I have not had a need yet for "is". Cheers marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: python decimal library dmath.py v0.3 released
On Monday, March 3, 2014 7:34:40 AM UTC-6, Oscar Benjamin wrote: > Python Decimal Library dmathlib.py v0.3 Released > https://code.google.com/p/pythondecimallibrary/ > Is this available on PyPI? It seems there already is a "dmath" package > on PyPI that was written by someone else some time ago so you might > need to use a different name: > Oscar hi Oscar; thanks again for your help. Yes, I actually intended to call it dmathlib.py at first, and then had my brain stuck on dmath, partly because several folks threw that name around, and partly because I got used to abbreviating it and forgot to fix things up name-wise. [ Done ] Actually, code.google tries to help folks with that because if the name is taken you have to create a unique name; which I did, but I forgot to fix up all the references and heading. Thanks again for keeping me accountable. Kind regards, marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: python decimal library dmath.py v0.3 released
On Monday, March 3, 2014 7:34:40 AM UTC-6, Oscar Benjamin wrote: > On 3 March 2014 11:34, Mark H. Harris wrote: > > Is this available on PyPI? It seems there already is a "dmath" package > on PyPI that was written by someone else some time ago so you might > need to use a different name: > Oscar Oscar, thanks again for your help, and for keeping me accountable. I did intend on using the naming convention pythondecimallibrary but got dmath stuck in my mind from the discussions earlier last week. At any rate the naming problem is fixed. Thanks again. Python3.3 Decimal Library v0.3 is Released here: https://code.google.com/p/pythondecimallibrary/ *pdeclib.py* is the decimal library, and *pilib.py* is the PI library. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: python decimal library dmath.py v0.3 released
On Monday, March 3, 2014 10:44:16 AM UTC-6, Oscar Benjamin wrote: > Is it on PyPI though? I was referring to a PyPI name so that people > could install it with "pip install pdeclib" > Oscar hi Oscar, I'm sorry, I completely missed the point of your question. No its not on PyPI, but I don't mind putting it there. Are there special instructions, or is it fairly straight-forward? marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: python decimal library dmath.py v0.3 released
On Monday, March 3, 2014 11:23:13 AM UTC-6, Wolfgang Maier wrote:
> def fact(x):
> """ fact(x)factorial{x} int x > 0
>
> return +Decimal(math.factorial(x))
> to make it return a Decimal rounded to context precision?
hi Wolfgang, I'm not sure. We're doing some things with very large factorials
where (existentially) we want to know how many zeros are coming up and the end
of the very large number (thousands of digits) and 2) what are the last
significant figures (say twenty of them) that are just before the zero chain.
What I don't want is for the Decimal module to overflow (didn't know it would
do that), and we don't want the number rounded in scientific notation at some
number of places. We want to actually see the digits; all of them.
Python will do multiplications til the proverbial cows come home; well, as long
as you don't try it recursively --- killing the recursive depth. Decimal has
some limits internally which I still do not understand (and I have been looking
at the doc and playing with it for hours). If I want to build a BIGNUM int in
memory only the memory should limit what can be built, not some arbitrary limit
inside Decimal.
Does any of this make sense? and 2) can you help me understand the overflow in
Decimal a little bit better. I know you're a busy guy, maybe you just know a
link /
Thanks much.
--
https://mail.python.org/mailman/listinfo/python-list
pip and distutils2-1.0a4
hi folks, I am having a fit with pip this afternoon. I finally got pip installed on this system from a binary blob (what nightmare, talk about 1987). Anyway, pip is installed, but when I go to PyPI to pull down distutils is gives a message that no such package exists. I feel like Obeewan; "if the archive computer says your planet is not there, it simply does not exist". Can somebody tell me what is the best way to get distutils downloaded to this system? Thanks in advance. Somewhere I heard a rumor that distutils is preloaded with Py3.3.x / is this True? like, I might already have it?? thanks again marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: python decimal library dmath.py v0.3 released
On Monday, March 3, 2014 2:03:19 PM UTC-6, Mark H. Harris wrote: > On Monday, March 3, 2014 11:23:13 AM UTC-6, Wolfgang Maier wrote: Wolfgang, answer is not so much, in fact, not at all. But it is an interesting question for me; where I am continuing to learn the limits of Decimal, and the decimal context. I don't need rounding for integer multiplication, of course. I am interested in arbitrary limits, like emax, for instance. The doc is a little ambiguous. Is emax the max exponent, and if so, is 9 the limit, or is that the default context value which might be bumped up? If so, why have a limit on the emin & emax values? I'm playing with it. Shouldn't a Decimal value be able to continue to grow to the limit of memory if we wanted to be silly about it? According to the doc 'clamping' occurs if the exponent falls outside the range of emin & emax (what is overflow vs clamping ?) if the significant digits are allowed to grow and grow? Well, the doc then states that overflow occurs if we blow past the emax exponent value? What is the difference between overflow and clamping? Am I able to set emin & emax arbitrarily high or low? I have discovered just by playing with integer multiplication that those BIGNUMS don't seem to have a physical limit. Of course there isn't a decimal to keep track of, and they can just grow and grow; wouldn't want to make a Decimal from one of those, other than it is interesting to me as I'm trying to understand Decimal floating point. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: pip and distutils2-1.0a4
On Monday, March 3, 2014 2:53:00 PM UTC-6, Mark Lawrence wrote: > distutils has been part of the standard library for years. hi Mark, that's fabulous, why can't I import it? Because I'm doing something wrong of course. :) marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: pip and distutils2-1.0a4
On Monday, March 3, 2014 3:32:43 PM UTC-6, Robert Kern wrote: > Probably. If you want us to help, you need to show us what you tried, tell us > what results you expected, and copy-paste the output that you got. > Robert Kern hi Robert, well, I finally came up with trying to find setup(). Its a part of distutils.core. So, I tried: from distutils.core import setup from distutils import * Then I tried to run setup() --help-commands and python3 crashed. What did I do wrong? running Py3.3.4 Thanks, marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: python decimal library dmath.py v0.3 released
On Monday, March 3, 2014 3:18:37 PM UTC-6, Mark H. Harris wrote: Yeah, you can set Emin & Emax enormously large (or small), can set off overflow, and set clamping. I am needing a small utility (tk?) that will allow the context to be set manually by the interactive user dynamically (for a particular problem). Its like, one context doesn't fit all. Some of the pdeclib funcs will need to take into account the various signals also. The context manger is fabulous, but not for the average user; all the try block stuff is encapsulated (which makes the coding clean) but it is not obvious in any way what is happening with __init__() , __enter__() and __exit__() (although I did find a couple of good articles on the subject. The 'with localcontext(cts=None) as ctx' is genius, but not for the average user who just wants to get work done with python. So, the bottom line is we have this fabulous speedy decimal module that is nothing short of wonderful for experts, and completely out of the grasp of average users relatively new to python or with limited experience with decimal floating point arithmetic. "They would like to sing soft and sweet, like the cucumber, but they can't!" So, we need a complete wrapper around the decimal module (or better yet we need to make decimal floating point default) so that average users may take advantage of precise floating point math without having to be experts on decimal floating point arithmetic constraints in the new high speed module.:-} marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: python decimal library dmath.py v0.3 released
On Monday, March 3, 2014 4:15:39 PM UTC-6, Wolfgang Maier wrote: > Well, that may be your use-case, but then math.factorial is for you. > On the other hand, you may be interested in getting > context-rounded factorials and rounding to context > precision is what you'd expect from a Decimal function, > so, logically, that's how it should be implemented in your > package if you think it needs to have a fact function (which I'm not sure of). hi Wolfgang, you are absolutely right. I see what you're getting at now. I've stuffed something into the library that really does not belong in that library; it was just convenient for me. I get that. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: pip and distutils2-1.0a4
On Monday, March 3, 2014 4:11:44 PM UTC-6, Robert Kern wrote: >http://docs.python.org/3/distutils/index.html > Robert Kern hi Robert, I'm not whining --really-- but there is so dang much doc out there on how to upload a package to PyPI with every tool under the sun and all of them fancier than they need to be. So, that you! That doc file led me to another doc file that showed me how to build the setup.py file line by line. The real trick is building the src tree (and there are more than several ways to do that) and then matching the setup.py script to the src tree: then, python3 setup.py register python3 setup.py sdist upload python3 setup.py upload whew... I never worked so hard to get one silly tarball on a repository in my life ever... very rewarding; but, and I genuinely mean this, thank you for pointing me in the correct direction, sir. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: python decimal library dmath.py v0.3 released
On Monday, March 3, 2014 4:44:27 PM UTC-6, Wolfgang Maier wrote: > decimal can handle BIGNUMS fairly well, you just need to increase context > Emax. Have you ever tried to calculate stuff with ints as big as MAX_EMAX > (10**99) or even close to it and still had a responsive > system ?? hi Wolfgang, yes correct you are... I've been playing with it; very interesting. I think I've almost got my arms around these things. If I don't get it right in my head, then my library is gonna suck. Still looking, but I think I may have one or two more funcs that have a similar problem to epx(). I've decided to go through them one by one while I'm testing and make sure that they are as efficient as I can make them. Thanks again for your inputs. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: python decimal library dmath.py v0.3 released
On Monday, March 3, 2014 5:34:30 AM UTC-6, Mark H. Harris wrote: > https://code.google.com/p/pythondecimallibrary/ I released my pdeclib module this afternoon on PyPI here: https://pypi.python.org/pypi/pdeclib/0.3 The tarball.gz may be downloaded and installed with: pip install pdeclib Contains:pdeclib.py | pilib.py Thanks again to all who helped me with this beta package. Cheers, marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: python decimal library dmath.py v0.3 released
On Tuesday, March 4, 2014 3:35:48 PM UTC-6, Stefan Krah wrote:
> http://www.bytereef.org/mpdecimal/quickstart.html#factorial-in-pure-python
> Be sure to set MAX_EMAX and MIN_EMIN, that's missing in the example.
> http://www.bytereef.org/mpdecimal/benchmarks.html#arbitrary-precision-libraries
> Stefan Krah
hi Stefan!
Good to hear from you, sir. My hat is off to you for sure,
and thank you very kindly for your good work on the
decimal.Decimal code; ~very nice! {hands clapping}
Thanks for the input above, will read.
Stay in touch. I have an expansion of my decimal idea for
python (stay tuned on python-ideas) which I think will be
for the better, if we can convince wide adoption; could be
an up-hill climb, but who knows.
Its been good to meet you in the code, and now a true
pleasure to meet you on-line as well. Hope to see you sometime
at a python convention perhaps.
Best regards,
Mark H Harris
--
https://mail.python.org/mailman/listinfo/python-list
Re: Geezer learns python
On Tuesday, March 4, 2014 5:03:13 PM UTC-6, notbob wrote:
{snip}
hi notbob,
Get a good book on python3 programming {Barnes and Noble,
Amazon} and please, start with python (3).
Great book: & fabulous tutorial:
Summerfield, Mark. Programming in Python 3: A Complete Introduction to the
Python Language.
Developer's Library. 2nd Edition. (Upper Saddle River: Addison-Wesley, 2010)
The book is 630 pages, illustrated, and explains everything with very
clear insightful use cases, example coding, and exercises. It is also
not a bad reference, although there are better ones. IMHO if you can
purchase just one book on python programming, this is it.
Also, don't forget that google is your friend. You will find the python
community very friendly (as compared to some groups) but folks can
be short if the questions show little or no research. There are great
tutorials on-line for python too, and very good doc.
Start here: http://docs.python.org/3.3/tutorial/
Also Docs: http://docs.python.org/3.3/#
Cheers
marcus
--
https://mail.python.org/mailman/listinfo/python-list
Re: python decimal library dmath.py v0.3 released
On Monday, March 3, 2014 7:46:38 PM UTC-6, Mark H. Harris wrote: > On Monday, March 3, 2014 5:34:30 AM UTC-6, Mark H. Harris wrote: > > > https://code.google.com/p/pythondecimallibrary/ > >https://pypi.python.org/pypi/pdeclib/0.3 Greetings, just a minor update here for version testing and portability. I have tested pdeclib.py | pilib.py on the following distributions: Py2.5 [ not supported, problems with "with" and localcontext ] Py2.6.1 [ runs correctly as written ] Py2.7.2 [ runs correctly as written ] Py2.7.6 [ runs correctly as written ] Py3.2.0 [ runs correctly as written ] Py3.3.4 [ runs very fast ] Py2.7.2 was interesting for me to verify, because that is the version that is currently supported by the QPython people, for the Android platform. I now have pdeclib module loaded on my phone running quite well, Samsung Galaxy SII Android 4.1.2 QPython 0.9.7.2 (Py2.7.2), although not as speedy as 3.3, it imports & runs without errors so far. If you put pdeclib on your Android tablet|phone, you may run the script from your personal directory, of course, or you may place it in the python2.7 lib/site-packages folder and it will be on the PYTHONPATH regardless of which directory you open python2.7.2 over. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: How security holes happen
On Wednesday, March 5, 2014 2:26:12 AM UTC-6, Steven D'Aprano wrote:
> On Wed, 05 Mar 2014 08:37:42 +0200, Marko Rauhamaa wrote:
>
> > If you had tried Python 30 years ago, you'd give it up for any serious
> > work because it would be so slow and consume so much memory.
>
> /facepalm
>
> Python is only 23 years old, so it would have been a good trick to have
> tried it 30 years ago.
hi Steven, QOTD, I go back to the day of the MITS Altair 8800. My
high school had one. I was writing machine code for the Wang 700 series
programmable desk calculator, and punching in code on the Altair 8800,
with toggle switches. I'm one of the guys Bill Gates wrote his famous
open letter to in 1976. I was there. In 1984 the only language being used
to write *anything* in the general sphere of personal computing was either
MS DEBUG.COM (one of my favorites) or BASIC---which was ubiquitous,
where like almost *every* computer booted directly into a BASIC interpreter,
the noted exception being the first IBM PC.
The pre-cursor to python was ABC created at CWI in about 1991. One of
its purposes (according to Guido) was to, and I quote, "Stamp out BASIC".
My first IBM machine was the famous PCjr... booted directly into cartridge
BASIC, or would optionally boot DOS 2.1 from 5" floppy, where I could
run, you guessed it BASICA, using the cartridge rom, or I could optionally
run DEBUG.COM and code up 8086 machine code (not assembler, mind you).
Well, I used my PCjr until 1992 (python was one year old, and ABC would
not run on a PC); when I purchased my 486 SX. Guess what? ---still
coding BASIC, DEBUG.COM... and whoohoo, Turbo Pascal
At IBM we were coding Rexx on the VM370 systems, and then Rexx on the
OS/2 systems; no python, and nothing much else either , oh yes, Turbo BASIC,
Visual BASIC, and of course BASICA although you could then get it as GWBASIC,
... still no python.
Did anyone mention that PCs back in that day were toys. And I do mean toys.
They were slow, they crashed, their graphics sucked, and your storage medium
was a floppy disk. Linus was working in Finland on basic... Richard Stallman
was
working on GNU, Guido was working at CWI on python. The PC really didn't come
into its own (and they were still slow) until the Pentium4. Personal computers
really did not begin to really shine until about 1998 (a mere 16 years ago) when
IBM and other began to take a serious look into gnu/linux research.
PCs were fast enough, had enough memory, and even had python. Of course
most of us were not using it... mostly C of various brands (notably MIX) and
Visual BASIC. Quick BASIC was ubiquitous by that time, and MASM had taken
over for DEBUG.com. Those were the days.
There has been a resurgence of interest in BASIC today; notably Mintoris, and
Chipmunk. But now everyone usually has some flavor of python installed on
their computer (and most don't know it) because python is being used under
the covers as a scripting language of choice. Wide adoption is still coming,
in the future, but the future looks good for python; competing of course with
(notably) Java or Dalvik (Android Java).
In my day computers were slide-rules. Businesses were still using Comptometers
(still being taught on my high school) and the modern age of computing
would not occur for forty years. Trust me, thirty years ago was like the dark
ages of personal computing and python wasn't even a gleam in her daddy's
eye.
If fact, now that I think of it, Monte Python and the Holy Grail came out in
1975,
one year before the MITS Altair 8800 Bill Gates open letter, and one year after
I
graduated from high school.
{world according to me}
marcus
--
https://mail.python.org/mailman/listinfo/python-list
Re: How security holes happen
On Wednesday, March 5, 2014 9:47:40 AM UTC-6, Steven D'Aprano wrote: > Seriously, Lisp is not only one of the oldest high-level languages > around, being almost as old as Fortran and Cobol, but it was one of the > biggest languages of the 1970s and even into the 80s. Lisp was specified by John McCarthy (of Berkeley, CA) in 1958. It is the second oldest computer language behind Fortran, by one year. There is a resurgence of interest in Lisp today (yes, not so much for common lisp) in the Scheme arena. The irony for AI today is that we are finally at the point where the technology can finally do what Alonzo Church and Alan Turing dreamed about. John McCarthy was *way* ahead of his time too. We are at the point where we are wondering again if computer science & technology in software engineering will ever generate a "thinking" entity---self aware, creative, and of course able to generate on it's own, "Cogito ergo sum"> Lisp/Scheme is awesome. But, if I want to have my little 'ol puter do some real work, up comes IDLE and out comes a script in a couple of hours that's "awesome"! I still play around with gnu emacs and lisp. Its fun, educational, and truly enriching beyond words. Check out the site, "Lambda the Ultimate" sometime: http://lambda-the-ultimate.org/ marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: How security holes happen
On Wednesday, March 5, 2014 6:24:52 PM UTC-6, Dennis Lee Bieber wrote: > I must have had a deprived life... > > The only "debug" on a home system I ever used was the one in LS-DOS. > And even then, it was only because an OS update disk arrived with a bad > sector and could not be copied. Not many people realized what they had in front of them. The only reason you might is if you 'grew up' on a system that required machine coding; like the Wang 700 series, or the MITS Altair 8800, or the VIC 20 with VicMon. I grew up with all three. So, before I ever learned a line of BASIC I was coding machine language (not assembler) on the three platforms above... the wang used integrated circuits, but had to processor chip; the MITS used the very first 8080 chip from Intel, and the VIC 20 used the 6502 from Motorola. My first personal computer (I did not own it, it was temporarily loaned to me) was the VIC 20. It only had 5k of memory, so anyone who did any real programming on it purchased the VicMon cartridge which was a 'machine language monitor'. It was "DEBUG.COM" for the VIC 20. When I got the first copy of DOS on floppy and saw DEBUG.COM I knew instantly what it was... a machine language monitor system for reading and writing machine code (8086 / 8088) in memory, or to disk sectors, or to disk as a file-name. It wasn't just a debugger---hardly! It was (and still is, yes, I still use it) a simple clean full-blown machine language monitor capable today just as then, to build sophisticated applications with 1's and 0's/ It was also my cup of tea, as it were. The folks who used the MITS Altair 8800 hated punching code in by hand; gets old fast. But not for me. I loved it, because I was as interested in the 8080 processor as I was in writing programs for it; it was great fun experimenting with memory and the processor. marcus -- https://mail.python.org/mailman/listinfo/python-list
test
test please disregard -- https://mail.python.org/mailman/listinfo/python-list
Re: How security holes happen
On Wednesday, March 5, 2014 7:40:05 PM UTC-6, MRAB wrote: > > The 6502 came from MOS Technology. Motorola made the 6800. Well, not exactly. The MOS 6502 is to the Motorola 6800 what the Zilog Z80 was to the Intel 8080. The same engineers who designed the 6800 moved out and then designed the 6502; actually ended up in a law suit of sorts--- but I don't remember the details. Anyway, the 6502 was bought outright by Commodore, and the rest is history with the VIC20. The engineers at Intel did the same thing... moved out and started Zilog (which still exists today) and began their work on the Z80. By the by, the Z80 is still embedded in many applications today. Although, its not on a 40 pin dip any longer; its a small square about the size of a postage stamp. That is what powers the TI 84+ and the TI 83+ graphing programable calculators. I do some machine coding on the TI 84+ because it can be done on-the-device! The 68000 is the motorola chip that powers the TI89 graphing programable calculator ( my favorite ). Its not so easy to program it with machine code, because the kernel binaries are not well documented (TI hides them) and the user community hasn't probed it enough to know how does it really work. > 5K? Luxury! I started with the Science of Cambridge Mk14. Including the > RAM on the I/O chip, it had 640 bytes. Oh, I know. I thought 5k was a tremendous about of memory at the time, but we soon built and expanded for the slot, added 16k of memory (hand wire-wrapped thank you) and then plugged the VicMon (actually HES MON) into that. Do you remember the IAS (Maniac) at the Institute for Advanced Study (Johnny von Neumann's baby) ? It only had 5k of memory too! They had to use punched cards or punched tape for intermediate results when they were doing their runs calculating the wave function for the hydrogen bomb. At the time, Johnny said, " there will never be a need for for than five machines like this in the whole world!" marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: How security holes happen
On Thursday, March 6, 2014 6:28:58 PM UTC-6, Dennis Lee Bieber wrote: > > The 6502 was NOT a Motorola chip (they had the 6800). The 6502 was MOS That's funny... did you not see what I wrote back to MRAB? Here: The MOS 6502 is to the Motorola 6800 what the Zilog Z80 was to the Intel 8080. The same engineers who designed the 6800 moved out and then designed the 6502; actually ended up in a law suit of sorts--- but I don't remember the details. Anyway, the 6502 was bought outright by Commodore, and the rest is history with the VIC20. -- https://mail.python.org/mailman/listinfo/python-list
test
disregard -- https://mail.python.org/mailman/listinfo/python-list
Re: How security holes happen
On Thursday, March 6, 2014 8:13:02 PM UTC-6, MRAB wrote: > > The Z80's architecture and instruction set is a superset of that of the > 8080; the 6502's architecture and instruction set isn't a superset of, > or even compatible with, that of the 6800 (although it can use the same > I/O, etc, chips). My point is not what, but who. Motorola engineers designed the 6502. A rose is a rose by any other name. Its the people who count... if Motorola had listened to those guys, who knows ... ? neither here nor there now, or course. -- https://mail.python.org/mailman/listinfo/python-list
Re: image processing in python and opencv
On Sunday, March 9, 2014 2:09:25 PM UTC-5, Gary Herron wrote: > i have no idea how to retrieve indexed images stored in ordered dictionary, > using its values like : blue,green,red mean along with contrast, energy, > homogeneity and correlation. as i have calculated the euclidean distance and > i don't know how to display the images which are similar. Its a bot. (spam) -- https://mail.python.org/mailman/listinfo/python-list
Sharing: File Reader Generator with & w/o Policy
hi folks, I am posting to share a File Reader Generator which I have
been playing with, that simplifies reading of text files on-demand:
like log files, config files, small record flat data-bases, &c.
I have two generators to share, one with & one without "policy".
The idea is to have the generator open and close the file (with error
checking: try-finish block) and then maintain its state for on-demand
reading either into memory (as list or dict) or for in-line processing.
I will demonstrate the generators here, and then post the code
following. The generator will be reading a path+filename of a local disk
file and printing it as in this simple case without policy:
>>> from my_utils import *
>>> for record in fName(path+"my_fox"):
print(record)
The quick brown fox jumped
over the lazy dog's tail.
Now is the time for all
good women to come to the
aid of computer science!
>>>
The second generator adds "policy" to the generator processing and
yields tuples, rather than strings. Each tuple contains the record
number (from zero), and record length (minus the line end), and the
record itself (stripped of the line end):
>>>
>>> for record in fnName(path+"my_fox"):
print(record)
(0, 26, 'The quick brown fox jumped')
(1, 25, "over the lazy dog's tail.")
(2, 0, '')
(3, 23, 'Now is the time for all')
(4, 25, 'good women to come to the')
(5, 24, 'aid of computer science!')
>>>
>>>
I will now share the source by allowing the fName(filename) utility
to expose itself. Enjoy:
>>>
>>> for record in fName(path+"my_utils.py"):
print(record)
#-
# fName(filename) generator: file reader iterable
#-
def fName(filename):
try:
fh = open(filename, 'r')
except FileNotFoundError as err_code:
print (err_code)
else:
while True:
linein = fh.readline()
if (linein!=''):
yield(linein.strip('\n'))
else:
break
fh.close()
finally:
None
#-
# fnName(filename) generator: file reader iterable
#-
def fnName(filename):
try:
fh = open(filename, 'r')
except FileNotFoundError as err_code:
print (err_code)
else:
line_count = 0
while True:
linein = fh.readline()
if (linein!=''):
lineout = linein.strip('\n')
length = len(lineout)
yield((line_count, length, lineout))
line_count+=1
else:
break
fh.close()
finally:
None
#-
# {next util}
#-
>>>
mark h harris
--
https://mail.python.org/mailman/listinfo/python-list
test
test -- https://mail.python.org/mailman/listinfo/python-list
Re: Sharing: File Reader Generator with & w/o Policy
On 3/15/14 4:56 PM, MRAB wrote:
I don't like how it always swallows the exception, so you can't tell
whether the file doesn't exist or exists but is empty, and no way to
specify the file's encoding.
Yes, the error handling needs more robustness/ and instead of printing
the errcode, my actual model on system will log it.
Why do you have the 'finally' clause with 'None' in it? Instead of None
you should have 'pass', or, better yet, omit the clause entirely.
Its a stub-in really, and that's all at this point. The 'finally'
happens regardless of whether the exception occurs, and I don't need
anything there yet, just don't want to forget it.
I've been playing around with wrapping generators within generators for
readability and simplicity. Like this, where I'm going to wrap the
fnName(filename) generator within a getnumline(filename) wrapper:
>>> from my_utils import *
>>> def getnumline(filename):
for record in fnName(filename):
yield(record)
>>> line = getnumline("my_foxy")
>>>
>>> next(line)
(0, 26, 'The quick brown fox jumped')
>>>
>>> next(line)
(1, 25, "over the lazy dog's tail.")
>>>
Or this, where I put it all in memory as a dict:
>>> d1={}
>>> for line in getnumline("my_foxy"):
d1[line[0]]=(line[1], line[2])
>>> for key in d1:
print (d1[key])
(26, 'The quick brown fox jumped')
(25, "over the lazy dog's tail.")
(0, '')
(23, 'Now is the time for all')
(25, 'good women to come to the')
(24, 'aid of computer science!')
>>>
marcus
--
https://mail.python.org/mailman/listinfo/python-list
Re: Sharing: File Reader Generator with & w/o Policy
On 3/15/14 4:56 PM, MRAB wrote:
def fName(filename):
try:
with open(filename, 'r') as fh:
for linein in fh:
yield linein.strip('\n')
except FileNotFoundError as err_code:
print(err_code)
[snip]
The "with" confuses me because I am not sure specifically what happens
in the context manager. I'm taking it for granted in this case that
__exit__() closes the file?
I am finding many examples of file handling using the context manager,
but none so far that wrap into a generator; more often and file object.
Is there a preference for file object over generator?
marcus
--
https://mail.python.org/mailman/listinfo/python-list
Re: Sharing: File Reader Generator with & w/o Policy
On 3/15/14 4:56 PM, MRAB wrote:
You can also shorten it somewhat:
Thanks, I like it... I shortened the fnName() also:
#-
# fn2Name(filename) generator: file reader iterable
#-
def fn2Name(filename):
try:
with open(filename, 'r') as fh:<=== can you tell me
line_count = 0
for linein in fh:
lineout = linein.strip('\n')
length = len(lineout)
yield((line_count, length, lineout))
line_count+=1
except FileNotFoundError as err_code:
print(err_code)
#-
... where I can go to find out (for specific contexts) what the
__init__() and __exit__() are actually doing, like for instance in this
case does the filename get closed in __exit__(), and also if errors
occur does the file close automatically? thanks
marcus
--
https://mail.python.org/mailman/listinfo/python-list
Re: Sharing: File Reader Generator with & w/o Policy
On 3/15/14 8:32 PM, Mark Lawrence wrote: Start here http://docs.python.org/3/library/stdtypes.html#context-manager-types Thanks Mark. I have three books open, and that doc, and wading through. You might like to know (as an aside) that I'm done with gg. Got back up here with a real news reader and server. All is good that way. gg has not been stable over the past three weeks, and this weekend it completely quit working. It looks like this reader|client handles the line wrapping correctly. whoohoo. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Sharing: File Reader Generator with & w/o Policy
On 3/15/14 9:01 PM, Steven D'Aprano wrote:
Reading from files is already pretty simple. I would expect that it will
be harder to learn the specific details of custom, specialised, file
readers that *almost*, but not quite, do what you want, than to just
write a couple of lines of code to do what you need when you need it.
Particularly for interactive use, where robustness is less important than
ease of use.
Yes. What I'm finding is that I'm coding the same 4-6 lines of code
with every file open (I do want error handling, at least for
FileNotFoundError) and I only want it to be two lines, read the file
into a list with error handling.
What's "policy"?
That's part of what I personally struggle with (frequently) is do I
place the policy in the generator, or do I handle it on the outside. For
instance, I normally strip the line-end and I want to know the record
lengths. I also may want to know the record number from arrival
sequence. This policy can be handled in the generator; although, I could
have handled it outside too.
for i, line in enumerate(open(pathname + "my_fox")):
print((i, len(line), line))
I like it... and this is where I've always been, when I finally said to
myself, yuk. yes, it technically works very well. But, its ugly. And I
don't mean its technically ugly, I mean its aesthetically ugly and not
user-easy-to-read. (I know that's all subjective)
for line in getnumline(path+"my_foxy")):
print(line)
In this case getnumline() is a generator wrapper around fName(). It of
course doesn't do anything different than the two lines you listed, but
it is immediately easier to tell what is happening; even if you're not
an experienced python programmer.
[Aside: I don't believe that insulating programmers from tracebacks does
them any favours.
Yes. I think you're right about that. But what if they're not
programmers; what if they're just application users that don't have a
clue what a trace-back is, and just want to know that the file does not
exist? And right away they realize that, oops, I spelled the filename
wrong. Yeaah, I struggle with this as I'm trying to simplify, because
personally I want to see the trace back info.
Worse, it's inconsistent! Some errors are handled normally, with an
exception. It's only FileNotFoundError that is captured and printed. So
if the user wants to re-use this function and do something with any
exceptions, she has to use *two* forms of error handling:
Yes. The exception handling needs to handle all normal errors.
(1) wrap it in try...except handler to capture any exception other
than FileNotFoundError; and
(2) intercept writes to standard out, capture the error message, and
reverse-engineer what went wrong.
Ok.
Apart from stripping newlines, which is surely better left to the user
(what if they need to see the newline? by stripping them automatically,
the user cannot distinguish between a file which ends with a newline
character and one which does not), this part is just a re-invention of
the existing wheel. File objects are already iterable, and yield the
lines of the file.
Yes, this is based on my use case, which never needs the line-ends, in
fact they are a pain. These files are variable record length and the
only thing the newline is used for is delimiting the records.
def fnName(filename):
for count, line in enumerate(fName(filename)):
yield (count, len(line), line)
I like this, thanks! enumerate and I are becoming friends.
I like this case philosophically because it is a both | and. The policy
is contained in the wrapper generator using enumerate() and len()
leaving the fName() generator to produce the line.
And you are right about another thing, I just want to use this thing
over and over.
for line in getnumline(filename):
{whatever}
There does seem to be just one way of doing this (file reads) but
there are actually many ways of doing this. Is a file object really
better than a generator, are there good reasons for using the generator,
are there absolute cases for using a file object?
marcus
--
https://mail.python.org/mailman/listinfo/python-list
Re: test
On 3/15/14 8:48 PM, Travis Griggs wrote: On Mar 15, 2014, at 14:24, Mark H Harris wrote: test Pass Thanks Travis. I hated doing that. I have been having a fit with gg, and its taken just a little time to get a real news-reader client for posting. What a fit. Google does really well with some things, but gg is not one of them, IMHO. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Sharing: File Reader Generator with & w/o Policy
On 3/15/14 10:48 PM, Chris Angelico wrote:
There's a cost to refactoring. Suddenly there's a new primitive on the
board - a new piece of language . . . Splitting out all sorts of things into
generators when you could use well-known primitives like enumerate
gets expensive fast {snip}
[1] https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)
Very good to remember. I am finding the temptation to make all kinds of
generators (as you noted above). Its just that the python generator
makes it so easy to define a function that maintains state between calls
(of next() in this case) and so its also so easy to want to use them...
almost forgetting about primitives!
And the rule of three is one of those things that sneaks up on oneself.
I have actually coded about seven (7) such cases when I discovered that
they were all identical. I am noticing that folks code the same file
reader cases "with open() as fh: yadda yadda" and I've noticed that
they are all pretty close to the same. Wouldn't it be nice to have one
simpler getline() or getnumline() name that does this one simple thing
once and for all. But as simple as it is, it isn't. Well, as you say,
use cases need to determine code refactoring.
The other thing I'm tempted to do is to find names (even new names) that
read like English closely (whatever I mean by that) so that there is no
question about what is going on to a non expert.
for line in getnumline(file):
{whatever}
Well, what if there were a project called SimplyPy, or some such, that
boiled the python language down to a (Rexx like) or (BASIC like) syntax
and usage so that ordinary folks could code out problems (like they did
in 1964) and expert users could use it too including everything else
they know about python? Would it be good?
A SimplyPy coder would use constructs similar to other procedural
languages (like Rexx, Pascal, even C) and without knowing the plethora
of Python intrinsics could solve problems, yet not be an "expert".
SimplyPy would be a structured subset of the normal language for
learning and use (very small book/tutorial/ think the Rexx handbook, or
the K&R).
Its a long way off, and I'm just now experimenting. I'm trying to get my
hands around context managers (and other things). This is an idea I got
from Anthony Briggs' Hello Python! (forward SteveHolden) from Manning
books. Its very small, lite weight, handles real work, but--- its still
too big. I am wanting to condense it even further, providing the minimal
basic core language as an end application product rather than the
"expert" computer science language that will run under it.
or, over it, as you like.
(you think this is a nutty idea?)
marcus
--
https://mail.python.org/mailman/listinfo/python-list
Re: Sharing: File Reader Generator with & w/o Policy
On 3/16/14 12:41 AM, Chris Angelico wrote:
Good stuff Chris, and thanks for the footnotes, I appreciate it.
If getline() is doing nothing that the primitive doesn't, and
getnumline is just enumerate, then they're not achieving anything
beyond shielding you from the primitives.
Yes. getline(fn) is returning the raw line minus the newline \n.
And getnumline(fn) is 1) creating a name that is easily recognizable,
and 2) shielding the 'user' from the primitives; yup.
The trouble is that your idea of getnumline(file) might well differ
from someone else's idea of getnumline(file). Using Python's
primitives removes that confusion
I am seeing that; esp for folks used to seeing the primitives; don't
want confusion.
To be quite frank, yes I do think it's a nutty idea. Like most nutty
things, there's a kernel of something good in it, but that's not
enough to build a system on :)
Thanks for your candor. I appreciate that too. Well, like I said,
I'm just experimenting with the idea right now, just playing around
really. In the process I'm coming more up-to-speed with python3.3 all
the time. :)
Python is already pretty simple.
statement == True
We had a discussion along these lines a little while ago, about
designing a DSL [1] for window creation. On one side of the debate was
"hey look how much cleaner the code is if I use this DSL", and on the
other side was "hey look how much work you don't have to do if you
just write code directly".
Was that on python-dev, or python-ideas, or here? I'd like to read
through it sometime.
Well just for grins, here is the updated my_utils.py for compare with
where I started tonight, ending like before with the code:
>>>
>>> for line in getline(path+"my_foxy"):
print (line)
The quick brown fox jumped
over the lazy dog's tail.
Now is the time for all
good women to come to the
aid of computer science!
>>> for line in getnumline(path+"my_foxy"):
print (line)
(0, 26, 'The quick brown fox jumped')
(1, 25, "over the lazy dog's tail.")
(2, 0, '')
(3, 23, 'Now is the time for all')
(4, 25, 'good women to come to the')
(5, 24, 'aid of computer science!')
>>> for line in getline(path+"my_utils.py"):
print (line)
#-
# __fOpen__(filename) generator: file open internal
#-
def __fOpen__(filename):
try:
with open(filename, 'r') as fh:
for linein in fh:
yield linein.strip('\n')
except FileNotFoundError as err_code:
print(err_code)
# think about error handling, logging
finally:
pass
#-
# getnumline(filename) generator: enumerated file reader
#-
def getnumline(filename):
for count, line in enumerate(__fOpen__(filename)):
yield((count, len(line), line))
#-
# getline(filename) generator: raw file reader iterable
#-
def getline(filename):
for line in __fOpen__(filename):
yield(line)
#-
# {next util}
#-
>>>
--
https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
On 3/15/14 11:26 AM, Jayanth Koushik wrote:
This is a very interesting philosophical question, one which I am
surprised no one has answered; although, I think the reason for that
might be entirely obvious.
You actually answered your own question, as you were asking it. If the
doc says "whatever you do, don't push the purple button," well, leave
the purple button alone. :) (I don't know, push it if you want)
If you monitor the PEP process, or have ever taken part in python-ideas,
or python-dev (either directly, or just lurking) you will notice that
python is developed through a very interesting active committee process
(that is really something phenomenal; cool community).
How should one spell a complex number? Should we use i or j ? Should the
imaginary part be set off somehow? Should literals be parsed
differently (or consistently) with correctly formed strings? Who knows,
beats me.
consider:
>>> complex( 3 + 2 j)
SyntaxError: invalid syntax
>>> complex( 3 +2j )
(3+2j)
>>>
I don't know... you tell me.
>>> complex('3+2j')
(3+2j)
>>> complex('3 +2j')
Traceback (most recent call last):
File "", line 1, in
complex('3 +2j')
ValueError: complex() arg is a malformed string
>>>
Again, beats me. I just don't know.
But I do know that the spelling book says, Do it this way:
complex('3+2j').
Seems simple enough.
Philosophically, I tend to think about it this way. A complex number is
like any other number. I would not form a PI string like this> ' 3 .14 1
5 9265 3 . . .' I would rather see it formed like so, '3.1415926535'
This '3 + 2j' is not a number, its an algebraic sum.
This '3+2j' is a complex number. Ok, maybe not, but its closer to
what we expect (I'm sorry, but I like i instead of j )
Also, philosophically, C ignores white space; python does not.
I agree with this now; before I did not. White space is just as much a
part of how interpretation occurs, within symbol processing/parsing.
Some choices are arbitrary, some are community concurrence (PEPs), some
are philosophical, and most are just convenient intuition.
My Greek professor used to say, "there is no 'why' in Greek".
Python is similar.
Cheers
--
https://mail.python.org/mailman/listinfo/python-list
Re: test
On 3/16/14 5:07 AM, Chris “Kwpolska” Warrick wrote: Why not use the mailing list instead? It’s a much easier way to access this place. I prefer to 'pull' rather than receive the 'push'. The newsreader idea is better because threading works better, and because the interface is simpler. I don't know, just preference I guess. I am active on several mailing lists also; they only have list servers (not news Usenet server). The Usenet news reader concept must be fading away, and many isp(s) are not providing the nntp post service these days (Charter stopped it in late 2011). There are still several free post servers out there that do not require registration (some are free but do require registration). What are most active pythoniacs doing with this these days? (beats me) -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
On 3/17/14 12:03 PM, Chris Angelico wrote:
ast.dump(ast.parse("complex( 3 +2j )"))
"Module(body=[Expr(value=Call(func=Name(id='complex', ctx=Load()),
args=[BinOp(left=Num(n=3), op=Add(), right=Num(n=2j))], keywords=[],
starargs=None, kwargs=None))])"
The sole argument to complex() is an expression which sums the integer
3 and the imaginary 2j, which results in the complex (3+2j), which
complex() looks at and returns unchanged. And that's what you see.
~very nice.
Ok, going along with Mark's comment about this bug report:
See http://bugs.python.org/issue9574
This string '3 +2j' should probably be ok from the complex() string
constructor standpoint, right?
I mean, there might be more than one constructor for string, mighten-it?
marcus
--
https://mail.python.org/mailman/listinfo/python-list
Re: test
On 3/17/14 12:03 PM, Mark Lawrence wrote: Thunderbird and gmane, FWIW on Windows 7. I moved my news reader stuff like comp.lang.python over to my Thunderbird mail client yesterday; works well and is as functional as sea-monkey ever was. The client is nice and has none of the short-comings of gg. The server &Thunderbird complain about the line lengths when in excess of 79 characters (says it can't post) but posts anyway. I've seen that at least one|twice. Gmane looks interesting... gonna try it. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
On 3/17/14 11:52 PM, Steven D'Aprano wrote:
On Mon, 17 Mar 2014 11:18:56 -0500, Mark H Harris wrote:
Who knows, beats me.
With respect, that's just because you would make a lousy language
designer :-)
Ouch;-)
"How should one spell a complex number?" There is perfectly good syntax
for complex numbers used by mathematicians and engineers for over a
century. There is no need to invent something different just for the sake
of being different:
Yes: 2+3i or 2+3j
Yes. my Q was rhetorical only. And for the sake of discussion,
particularly on the part of the OP, to think about what one expects
based on experience and common sense, as a mathematician. (that doesn't
mean it will be easy for the lexical parser.
"Should we use i or j ?" There are good reasons for both i and j. This
one comes down to personal preference.
no, not really. nobody writes, e^(jPI) + 1 = 0
Euler wants to see e^(iPI) + 1 = 0 ;-)
"Should the imaginary part be set off somehow?" What do you mean "set
off"? Why do you want to? Since the imaginary part can appear on its own:
simply, is 2j a literal complex part? ...yes 2 j ...no
In other words, there must NEVER be a space between the 2 and j.
This is debatable: 3 +2jalthough, I want to see3+2j
z = 2 + 3j # an expression adding 2 to 3j
z = 5*3j # an expression multiplying 5 by 3j
all good, well until its not
How flexible should the complex constructor be? Should it bend over
backwards to accept any mathematical expression that includes a complex j
suffix, e.g. complex("2**3i")? I think not,
I think not either. But, it is possible to have *many* constructors/
But, really, how often is this a problem? like almost never!
>>> complex( 3 +2j )
(3+2j)
>>>
I don't know... you tell me.
In both cases, the call to complex is redundant. You've already created a
complex number, using syntax, then you pass it to the complex function
which just returns the same number.
Of course. I was merely pointing out that the constructor for
'literals' (whatever you guys mean by that) is 'different' than the
consistency with the string constructor. As Chris pointed out these are
two markedly different animals; one is a valid parse syntax, the other
is a string constructor. But here is my point--- to the user the
difference comes down to semantics, which is not really true.
cf. below
>>> complex('3+2j')
(3+2j)
>>> complex('3 +2j')
Traceback (most recent call last):
File "", line 1, in
complex('3 +2j')
ValueError: complex() arg is a malformed string
Also, philosophically, C ignores white space; python does not.
This was said tongue in cheek... *both* languages inconsistently
observer (and ignore) white space! But, in general, white space is more
important to python, and less important to C.
I'm still hung up on whether I'm a lousy language designer. I guess
we'll know if people use my language (or not)! I suppose they might use
it even though its lousy; on the other hand, it might be too simple for
folks to be able to figure it out. :)
marcus
--
https://mail.python.org/mailman/listinfo/python-list
Re: Question about Source Control
On 3/17/14 8:06 AM, Frank Millman wrote: All my source code resides on an old Linux server, which I switch on in the morning and switch off at night, but otherwise hardly ever look at. It uses 'samba' to allow sharing with Windows, and 'nfs' to allow sharing with other Linux machines. hi Frank, I am using GIT and code.google.com. https://code.google.com/p/pythondecimallibrary/ I have not used Code Google prior to the pdeclib project; however, I plan to use it in the future extensively, at least for my open source projects (and when I am thinking about bringing another person on board. Code Google permits three version|control|access systems (I use GIT, a very simple command line interface). The thing is that the code resides on a person's machine as a clone of the repository, and is assessable from anywhere in the world, allows multiple developer participation, allows multiple branches|merge|master, and allows access to the source on-line (browse|edit), and permits new members to clone the repository from anywhere. Downloads are zipped. The down-side is also the up-side. Code Google is an open source developer collaborative environment for sharing & managing. Anything you put there belongs to everyone in the project, and can be viewed by anyone in the world (which is kinda the point of open source). There is a supreme benefit to having multiple eyes on the code. People maybe not even involved in the project directly will comment on the code (and they are not shy). You code will improve dynamically and radically (if you have the guts for it). It took me a couple of hours to get up to speed with Code Google. It took another hour or so to come up to speed with GIT. You need to create the project on Code Google first. Then on your machine, in the code directory (the directory actually holding the source files that you are going to make a part of your project) you do these things: git init this builds the .git subdirectory needed for push git add file-name add each filename you want to commit and push git remove removes any unwanted files git commit -a edit your commit comments here , or provide default git push https://code.google.com/p/whateveryourprojectnameis/ master sends the files on their way other files:.gitconfig.netrc You will place your name, email, and method (use simple) in the .gitconfig file. The .netrc file will contain the login info for code google machine. Read the GIT manual on-line; its pretty easy too. https://www.kernel.org/pub/software/scm/git/docs/user-manual.html http://git-scm.com/documentation Cheers -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 3/20/14 9:58 AM, notbob wrote: I've installed python 3.3 on my Slack box, which by default comes with python 2.7. I know how to fire up the different IDLE environments, but how do I differentiate between the scripts? hi notbob, the two (or more) IDLE environments run very nicely side-by-side. If you access your scripts from the same directory (I do not) there really is no problem. The reason is that the .pyc files created for python2.x are only used by python2. The .pyc files for python3.x are kept (by a naming convention) in __pycache__ , so there really is no problem. Having said that, the only problem is that your script for python3 might not run in python2 (for various reasons) but the problem is not that the scripts are contained in the same folder. I keep my python2 scripts in one folder ~/Documents/Python2/ and my python3 scripts in another one ~/Documents/Python3/ I add the two folders in the python paths browser (using site-packages) so that when I start IDLE for python2 it pulls its scripts from ~/Documents/Python2/ and when I start IDLE for python3 it pulls its scripts from ~/Documents/Python3/ There are *many* ways to organize this. Often I have to maintain two scripts (packages) one for each version. Although, I try to make my scripts run in both environments. Often I have IDLE(2) ane IDLE(3) running and testing at the same time on the same box. This works very well. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 3/20/14 12:23 PM, notbob wrote: What the heck is a .pyc file and how are they created? Actually, I can see it's a compiled binary, but I where did it come from? The world according to me: python is an interpreter (vs compiler) which converts your source code into tokens and then into a bytecode. The process takes time. So, the solution is to place the tokenized stuff into a .pyc file so that the process does not have to be repeated unless, of course, the source has changed since the last .pyc file create. It used to be that the .pyc files went into the same dir as the source (that's how it works for python2) but now with python3 they go into a directory in your source tree called __pycache__, and they are named based on python version (a way better scheme for sure). If you wanted to you could run your python scripts from the .pyc file alone. In other words, you may import as long as the .pyc file exists and the source does not need to be there. Some folks use this (not recommended) trick to hide or obfuscate their source from their users). marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 3/20/14 12:47 PM, Marko Rauhamaa wrote: I've seen it done, but at least in those Python 2 days the pyc format changed between minor releases of Python, so Python itself had to be shipped with the pyc files. hi Marko, yeah, I have not done this; being that the concept is contrary to my principles and sensibilities these days. So, 1) no intellectual property 2) no software idea patents 3) no obfuscated code 4) ship the source, or don't ship anything/ In my view coding (and all other aspects of computer science including software engineering) is a liberal art; it should be open, free (libre), and available to everyone. People learn best by doing, and the do best by reading what others have done before them. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 3/20/14 2:53 PM, Alan Meyer wrote: #!/usr/bin/env python Only use the "python2" or "python3" versions if you really have a reason to do so. It gets tricky for distribution (you need docs for your distros, imho) because #!/usr/bin/env python means different things on different systems. I actually have three major versions of python2 and 2 major versions of python3 on my primary system at this point. On my machine python2.6 is "python". That is because that system shipped with 2.6 and many of the subsystem stuff depends on python2.6 / When I call python2 that means python2.7.6 / When I call python3 that means python3.3.4 / I can also call python2.7, which is 2.7.2 / You get the idea. There is no one set rule, because there are many distros (gnu/linux) that use python at various versions, and they all us different setups. Really , you need an install script to snoop out the configurables. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 3/20/14 4:28 PM, notbob wrote: No wonder the latest O'Reilly book, Learning Python, 5th ed, is 1600 pgs. I coulda swore someone sed python is easy. ;) nb Python is easy, but its not simple. Python is elegant, and full of art, but it has no paucity of constructs, types, and opportunities for confusion. My goal for designing SimplyPy (for instance)is to present the beautiful heart of python (as Mark Summerfield calls it) and subsume the complexities of the fulness of python within a simple interface, BUT without limiting it. Python is easy enough to teach children (I've done it), but its "complete and elegant enough" for the most scientific of professionals. You do not need to know the fulness of python in order to use it. It is possible (even elegant) to use python (in a Rexx style) not at all recognized as "pythonized" code, and yet very very simple and powerful. The beauty of python, in my view, is the flexibility and extensibility of the namespace with something more than the minimalist approach of Lisp, BUT with the elegance of the language called python. Get Mark Summerfield's Programming Python 3. Its really quite good, and in my opinion better that the O'Reilly book, especially for new users. Just an opinion of course. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: CallBack function in C Libraries.
On 3/20/14 6:16 PM, fienspr...@gmail.com wrote: def TheProc(c_int): fpgui.fpgFormWindowTitle(0, 'Boum') return 0 TheProcF = CMPFUNC(TheProc) Traceback (most recent call last): File "_ctypes/callbacks.c", line 314, in 'calling callback function' TypeError: TheProc() takes exactly 1 argument (0 given) What is wrong ? You defined TheProc(c_init) to take exactly 1 argument. But when you called it, you didn't provide the argument. So, you got a traceback indicating that TheProc() takes exactly one argument. Give the function call its required argument and the error will go away... well, at least that one. Cheers -- https://mail.python.org/mailman/listinfo/python-list
Re: CallBack function in C Libraries.
On 3/21/14 7:02 AM, fienspr...@gmail.com wrote:
Yep, Many thanks for help
Hum, i have find the solution, it was in "CallBack function" in help-doc.
No, it was not in the "CallBack function" in help-doc ...
def TheProc(): <== you moved c_int from here ...
fpgui.fpgFormWindowTitle(0, 'Boum')
return 0
{snip}
CMPFUNC = CFUNCTYPE(c_int) < and placed it here ...
TheProcF = CMPFUNC(TheProc)<== so that when you called TheProc ...
... it wasn't "expecting" exactly one parameter. So, your python
traceback no longer warns about the parameter 'mismatch' in the defined
function TheProc().
I'm not picking on you, but this error was obvious; as was it's
solution, so I'm just wondering ?
Cheers
--
https://mail.python.org/mailman/listinfo/python-list
Re: Implement multiprocessing without inheriting parent file handle
On 3/21/14 10:28 AM, Antony Joseph wrote: How can i implement multiprocessing without inherit file descriptors from my parent process? I'll bite... If what you mean by 'multiprocessing' is forking a process, to get a child process, which will then do some parallel processing for some reason, the answer is two-fold: 1) you can't, and 2) you might try using threads. (there are other answers too) When you fork a process the only differences between the child and the parent is 1) process number, and 2) one is the 'parent' and one is the 'child'. They are 'exact' copies of one another. In socket daemons the parent always listens on a given port, then forks a child process to establish a secondary port(s) to handle the comm link; at that point (instant) both the parent and the child ask a simple question, "Am I the parent?" If so, the code goes back to listening... if not, the code (the child) establishes the necessary comm ports and handles the server request. When finished the child notifies the parent and ends. You can try parent/child arrangements (maybe use rpc, or shared memory segments for inter process comm), or you might try threads... which are a separate unit of execution (not a full process copy) but with access to the parent's memory. Otherwise, you might want to tell the list some of the background of your difficulty, or put the difficulty in pythonic terms, or simply ask your python related question with as much simplified but complete detail as possible. Is there a python question in there someplace? marcus -- https://mail.python.org/mailman/listinfo/python-list
