RE: Short-circuit Logic
> From: steve+comp.lang.pyt...@pearwood.info
> Subject: Re: Short-circuit Logic
> Date: Fri, 31 May 2013 05:13:51 +
> To: python-list@python.org
>
> On Fri, 31 May 2013 00:03:13 +0300, Carlos Nepomuceno wrote:
>
>>
>>> From: steve+comp.lang.pyt...@pearwood.info Subject: Re: Short-circuit
>>> Logic
>>> Date: Thu, 30 May 2013 05:42:17 + To: python-list@python.org
>> [...]
>>> Here's another way, mathematically equivalent (although not necessarily
>>> equivalent using floating point computations!) which avoids the
>>> divide-by- zero problem:
>>>
>>> abs(a - b) < epsilon*a
>>
>> That's wrong! If abs(a) < abs(a-b)/epsilon you will break the
>> commutative law. For example:
>
> What makes you think that the commutative law is relevant here?
How can't you see?
I'll requote a previous message:
}On Thu, 30 May 2013 13:45:13 +1000, Chris Angelico wrote:
}
}> Let's suppose someone is told to compare floating point numbers by
}> seeing if the absolute value of the difference is less than some
}> epsilon.
}
}Which is usually the wrong way to do it! Normally one would prefer
}*relative* error, not absolute:
Since we are considering Chris's supposition ("to compare floating point
numbers") it's totally relevant to understand how that operation can be
correctly implemented.
> Many things break the commutative law, starting with division and
> subtraction:
>
> 20 - 10 != 10 - 20
>
> 1/2 != 2/1
>
> Most comparison operators other than equality and inequality:
>
> (23 < 42) != (42 < 23)
>
> String concatenation:
>
> "Hello" + "World" != "World" + "Hello"
>
> Many operations in the real world:
>
> put on socks, then shoes != put on shoes, then socks.
>
That's is totally irrelevant in this case. The commutative law is essential to
the equality operation.
> But you are correct that approximately-equal using *relative* error is
> not commutative. (Absolute error, on the other hand, is commutative.) As
> I said, any form of "approximate equality" has gotchas. But this gotcha
> is simple to overcome:
>
> abs(a -b) < eps*max(abs(a), abs(b))
>
> (Knuth's "approximately equal to" which you give.)
>
>
>> This discussion reminded me of TAOCP and I paid a visit and bring the
>> following functions:
>
> "TAOCP"?
The Art of Computer Programming[1]! An old book full of excellent stuff! A MUST
READ ;)
http://www-cs-faculty.stanford.edu/~uno/taocp.html
[1] Knuth, Donald (1981). The Art of Computer Programming. 2nd ed. Vol. 2. p.
218. Addison-Wesley. ISBN 0-201-03822-6.
>
>
> --
> Steven
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: Can anyone please help me in understanding the following python code
On 30May2013 21:54, bhk...@gmail.com wrote: | One final question, Is there a way to edit the message once it has been posted? Essentially, no. If there's some error in a post, reply to it yourself with a correction. Transparency is a good thing. Revisionist history pretty much is not. -- Cameron Simpson Well, it's one louder, isn't it? It's not ten. You see, most blokes are gonna be playing at ten, you're on ten here, all the way up, all the way up, all the way up, you're on ten on your guitar, where can you go from there? Where? Nowhere, exactly. What we do is, if we need that extra push over the cliff, you know what we do? Eleven. Exactly. One louder. - Nigel Tufnel, _This Is Spinal Tap_ -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Fri, 31 May 2013 00:03:13 +0300, Carlos Nepomuceno wrote: > >> From: steve+comp.lang.pyt...@pearwood.info Subject: Re: Short-circuit >> Logic >> Date: Thu, 30 May 2013 05:42:17 + To: python-list@python.org > [...] >> Here's another way, mathematically equivalent (although not necessarily >> equivalent using floating point computations!) which avoids the >> divide-by- zero problem: >> >> abs(a - b) < epsilon*a > > That's wrong! If abs(a) < abs(a-b)/epsilon you will break the > commutative law. For example: What makes you think that the commutative law is relevant here? Many things break the commutative law, starting with division and subtraction: 20 - 10 != 10 - 20 1/2 != 2/1 Most comparison operators other than equality and inequality: (23 < 42) != (42 < 23) String concatenation: "Hello" + "World" != "World" + "Hello" Many operations in the real world: put on socks, then shoes != put on shoes, then socks. But you are correct that approximately-equal using *relative* error is not commutative. (Absolute error, on the other hand, is commutative.) As I said, any form of "approximate equality" has gotchas. But this gotcha is simple to overcome: abs(a -b) < eps*max(abs(a), abs(b)) (Knuth's "approximately equal to" which you give.) > This discussion reminded me of TAOCP and I paid a visit and bring the > following functions: "TAOCP"? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Can anyone please help me in understanding the following python code
Got It!!!, Finally. Thanks Dave So, the control goes back to the place after the recursive function is called once the no. of element is equal to one and starts merging after which it will again start to split the remaining items. Thank you Chris for your multiple explanations. One final question, Is there a way to edit the message once it has been posted? -- http://mail.python.org/mailman/listinfo/python-list
Re: Can anyone please help me in understanding the following python code
Got It!!!, Finally. Thanks Dave So, the control goes back to the place after the recursive function is called once the no. of element is equal to one and starts merging after which it will again start to split the remaining items. Thank you Chris for your multiple explanations. It was also very useful. One final question, Is there a way to edit the message once it has been posted? -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On 05/30/2013 07:10 PM, Nobody wrote: > This is why technical drawings which include regularly-spaced features > will normally specify the positions of features relative to their > neighbours instead of (or as well as) relative to some origin. If I am planting trees, putting in fence posts, or drilling lots of little holes in steel, I am actually more likely to measure from the origin (or one arbitrary position). I trust that the errors accumulating as the tape measure marks were printed on the tape is less than the error I'd accumulate by digging a hole, and measuring from there to the next hole. And definitely when drilling a series of holes I'll never measure hole to hole to mark. If I measure from the origin than any error for the hole is limited to itself as much as possible rather than passing on the error to subsequent hole positions. If I was making a server rack, for example, having the holes consistently near their desired position is necessary. Tolerances are such that my hole can be off by as much as a 1/16" of inch of my desired position and it would still be fine, but not if each hole was off by an additional 1/16". I guess what I've described is accuracy vs precision. In the case of the server rack accuracy is important, and precision can be more coarse depending on the screw size and the mount type (threaded hole vs square hole with snap-in nut). -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
Steven D'Aprano於 2013年5月30日星期四UTC+8上午10時28分57秒寫道： > On Wed, 29 May 2013 10:50:47 -0600, Ian Kelly wrote: > > > > > On Wed, May 29, 2013 at 8:33 AM, rusi wrote: > > >> 0.0 == 0.0 implies 5.4 == 5.4 > > >> is not a true statement is what (I think) Steven is saying. 0 (or if > > >> you prefer 0.0) is special and is treated specially. > > > > > > It has nothing to do with 0 being special. A floating point number will > > > always equal itself (except for nan, which is even more special), and in > > > particular 5.4 == 5.4. But if you have two different calculations that > > > produce 0, or two different calculations that produce 5.4, you might > > > actually get two different numbers that approximate 0 or 5.4 thanks to > > > rounding error. If you then compare those two ever-so-slightly > > > different numbers, you will find them unequal. > > > > EXACTLY! > > > > The problem does not lie with the *equality operator*, it lies with the > > calculations. And that is an intractable problem -- in general, floating > > point is *hard*. So the problem occurs when we start with a perfectly > > good statement of the facts: > > > > "If you naively test the results of a calculation for equality without > > understanding what you are doing, you will often get surprising results" > > > > which then turns into a general heuristic that is often, but not always, > > reasonable: > > > > "In general, you should test for floating point *approximate* equality, > > in some appropriate sense, rather than exact equality" > > > > which then gets mangled to: > > > > "Never test floating point numbers for equality" > > > > and then implemented badly by people who have no clue what they are doing > > and have misunderstood the nature of the problem, leading to either: > > > > * de facto exact equality testing, only slower and with the *illusion* of > > avoiding equality, e.g. "abs(x-y) < sys.float_info.epsilon" is just a > > long and slow way of saying "x == y" when both numbers are sufficiently > > large; > > > > * incorrectly accepting non-equal numbers as "equal" just because they > > happen to be "close". > > > > > > The problem is that there is *no one right answer*, except "have everyone > > become an expert in floating point, then judge every case on its merits", > > which will never happen. > > > > But if nothing else, I wish that we can get past the rank superstition > > that you should "never" test floats for equality. That would be a step > > forward. > > > > > > > > -- > > Steven The string used to represent a floating number in a computer language is normally in the decimal base of very some limited digits. Anyway with the advances of A/D-converters in the past 10 years which are reflected in the anttena- transmitter parts in phones, the long integer part in Python can really beat the low cost 32- 64 bit floating computations in scientific calculations. -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On May 31, 12:36 am, Steven D'Aprano wrote: > > But even if only a minority of programmers can master languages like > Lisp, Haskell, or Scheme, doesn't mean that *all* programmers can't learn > something from them. Functional programming is at least 50% a philosophy: > > * pass arguments to functions, and return results, rather than getting > and setting state from a variable. Yes that's the sense in which I am using the term. More such ideas of FP that can be used by all sorts of programmers across the board (not just FPers) is here: http://blog.languager.org/2012/10/functional-programming-lost-booty.html > On Thu, 30 May 2013 10:12:22 -0700, rusi wrote: > > On Thu, May 30, 2013 at 9:34 AM, Ma Xiaojun > > wrote: > >> Wait a minute! Isn't the most nature way of doing/thinking "generating > >> 9x9 multiplication table" two nested loop? > > > Thats like saying that the most natur(al) way of using a car is to > > attach a horse to it. > >[...] > > Likewise in the world of programming, 90% of programmers think > > imperative/OO programming is natural while functional programming is > > strange. Just wait 10 years and see if things are not drastically > > different! > > It won't be. Functional programming goes back to Lisp, which is nearly as > old as Fortran and older than Cobol. There have been many decades for > functional languages to become mainstream, but they've never quite done > it. There's no reason to think that the next decade will see a change to > this. Depends on how you define your terms. Comprehensions and lambdas have come into python. From where? [Lambdas have even got into C++ !!] Also LINQ in C# is inspired by comprehensions Generics were not there in C# and Java early editions. Now they've been retrofitted -- Origin SML. Almost every modern language supports garbage collection. Origin Lisp Numpy is a rip-off of APL. [Ripping off is a tribute. Non- acknowledgement is sad...] TAOCP -Vol 1 is a gigantic exercise on how to do lisp without lisp. Also called Greenspun's 10th law: http://c2.com/cgi/wiki?GreenspunsTenthRuleOfProgramming > Some modern Functional languages are really neat, like Haskell, but I > think the sad truth is that to really master them (and not just make do > with a small percentage of their functionality) is beyond 90% of > programmers. I'm not ashamed to admit that I struggle with advanced FP > concepts. Yes Haskell is HARD. Gets harder with each new major addition. Which is why I suggest using Haskell core (ie minus most fancy features) as an *ideology* rather than as a *technology*. Which is what I am suggesting in my course proposal https://moocfellowship.org/submissions/the-dance-of-functional-programming-languaging-with-haskell-and-python "Think with Haskell --- Code into Python" Want to contribute ? Well actually the last applies to anyone who is interested -- suggestions welcome!! -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Fri, May 31, 2013 at 10:13 AM, Rick Johnson wrote: > What if you need to perform operations on a sequence (more than once) in a > non-linear fashion? What if you need to modify the sequence whilst looping? > In many cases your simplistic "for loop" will fail miserably. What has this to do with the original question of iterating across integers? What you're now saying is that both the meaning of the current index and the top boundary can change during iteration; that's unrelated to whether to use equality or inequality for comparisons. Oh wait. Rick's back. He's been away so long that I stopped looking for his name in the headers. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
How to Begin Web Development with Python ?
Hello Python developers I have learnt python and used it for various purposes for scietific computing using sage and GUI development using Tkinter and lots more. I want to start web development using python My goal is to learn the web development in python from the basic level and understand the big web development projects like Django , MoinMoin Wiki , Plone and network programming further with twisted. I have found Web2Py to be an easy library to quickly use and develop the web application. Is there any other library to start my development with. and does my plan of learning Web2Py is good for Web development and getting involved in the big projects like Django , MoinMoin Wiki , Plone. *Regards * *Chitrank Dixit * *IIPS-DAVV * *Indore (M.P.) , India * *MCA * *trackleech.blogspot.in* -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
In article , Nobody wrote: > On Thu, 30 May 2013 19:38:31 -0400, Dennis Lee Bieber wrote: > > > Measuring 1 foot from the 1000 foot stake leaves you with any error > > from datum to the 1000 foot, plus any error from the 1000 foot, PLUS any > > azimuth error which would contribute to shortening the datum distance. > > First, let's ignore azimuthal error. > > If you measure both distances from the same origin, and you have a > measurement error of 0.1% (i.e. 1/1000), then the 1000' measurement will > actually be between 999' and 1001', while the 1001' measurement will be > between 1000' and 1002' (to the nearest whole foot). > > Meaning that the distance from the 1000' stake to the 1001' stake could be > anywhere between -1' and 3' (i.e. the 1001' stake could be measured as > being closer than the 1000' stake). > > This is why technical drawings which include regularly-spaced features > will normally specify the positions of features relative to their > neighbours instead of (or as well as) relative to some origin. Not to mention "Do not scale drawing" warnings. Do they still put that on drawings? It was standard practice back when I was learning drafting. > When you're dealing with relative error, the obvious question is > "relative to what?". Exactly. Most programmers are very poorly training in these sorts of things (not to mention crypto, UX, etc). I put myself in that camp too. I know just enough about floating point to understand that I don't really know what I'm doing. I would never write a program where numerical accuracy was critical (say, stress analysis of a new airframe or a nuclear power plant control system) without having somebody who really knew that stuff on the team. -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Thu, 30 May 2013 19:38:31 -0400, Dennis Lee Bieber wrote: > Measuring 1 foot from the 1000 foot stake leaves you with any error > from datum to the 1000 foot, plus any error from the 1000 foot, PLUS any > azimuth error which would contribute to shortening the datum distance. First, let's ignore azimuthal error. If you measure both distances from the same origin, and you have a measurement error of 0.1% (i.e. 1/1000), then the 1000' measurement will actually be between 999' and 1001', while the 1001' measurement will be between 1000' and 1002' (to the nearest whole foot). Meaning that the distance from the 1000' stake to the 1001' stake could be anywhere between -1' and 3' (i.e. the 1001' stake could be measured as being closer than the 1000' stake). This is why technical drawings which include regularly-spaced features will normally specify the positions of features relative to their neighbours instead of (or as well as) relative to some origin. When you're dealing with relative error, the obvious question is "relative to what?". -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
> On Fri, May 31, 2013 at 2:58 AM, rusi wrote: > > On May 30, 5:58 pm, Chris Angelico wrote: > > > The alternative would be an infinite number of iterations, which is far > > > far worse. > > > > There was one heavyweight among programming teachers -- E.W. Dijkstra > > -- who had some rather extreme views on this. > > > > He taught that when writing a loop of the form > > > > i = 0 > > while i < n: > > some code > > i += 1 > > > > one should write the loop test as i != n rather than i < > > n, precisely because if i got erroneously initialized to > > some value greater than n, (and thereby broke the loop > > invariant), it would loop infinitely rather than stop > > with a wrong result. > > > > And do you agree or disagree with him? :) I disagree with > Dijkstra on a number of points, and this might be one of > them. When you consider that the obvious Pythonic version > of that code: > > for i in range(n,m): > some code Maybe from your limited view point. What if you need to perform operations on a sequence (more than once) in a non-linear fashion? What if you need to modify the sequence whilst looping? In many cases your simplistic "for loop" will fail miserably. py> lst = range(5) py> for n in lst: ... print lst.pop() 4 3 2 Oops, can't do that with a for loop! py> lst = range(5) py> while len(lst): ... print lst.pop() 4 3 2 1 0 -- http://mail.python.org/mailman/listinfo/python-list
RE: Short-circuit Logic
> To: python-list@python.org > From: wlfr...@ix.netcom.com > Subject: Re: Short-circuit Logic > Date: Thu, 30 May 2013 19:38:31 -0400 > > On Thu, 30 May 2013 08:48:59 -0400, Roy Smith declaimed > the following in gmane.comp.python.general: > >> >> Analysis of error is a complicated topic (and is much older than digital >> computers). These sorts of things come up in the real world, too. For >> example, let's say I have two stakes driven into the ground 1000 feet >> apart. One of them is near me and is my measurement datum. >> >> I want to drive a third stake which is 1001 feet away from the datum. >> Do I measure 1 foot from the second stake, or do I take out my >> super-long tape measure and measure 1001 feet from the datum? > > On the same azimuth? Using the "super long tape" and ensuring it > traverses the 1000 foot stake is probably going to be most accurate -- > you only have the uncertainty of the positioning of the tape on the > datum, and the small uncertainty of azimuth over the 1000 foot stake. > And even the azimuth error isn't contributing to the distance error. > > Measuring 1 foot from the 1000 foot stake leaves you with any error > from datum to the 1000 foot, plus any error from the 1000 foot, PLUS any > azimuth error which would contribute to shortening the datum distance. Just because you have more causes of error doesn't mean you have lesser accurate measures. If fact, errors may compensate each other. It all depends on the bias (accuracy) and variation (precision) involved in the measurements you are considering. > -- > Wulfraed Dennis Lee Bieber AF6VN > wlfr...@ix.netcom.com HTTP://wlfraed.home.netcom.com/ > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: Surprising difference between StringIO.StringIO and io.StringIO
> > I would expect io.StringIO to be a match for the io.* stuff in Python > 3. So it should care whether it is a binary stream or a text stream. > Whereas StringIO.StringIO is your good old Python 2 StringIO, which expects > strs. > > On that basis, io.StringIO is a text stream, expecting Unicode > objects for transcription. 'str' is, in that context, probably > considered as 'bytes' in Python 3. > Thanks. This example was based on a function in Matplotlib. It appears the author switched from StringIO.StringIO to io.StringIO between 1.1 and 1.2. Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: usage of os.posix_fadvise
On 30May2013 17:54, Wolfgang Maier wrote: | Antoine Pitrou wrote: | >The Linux version of "man posix_fadvise" probably holds the answer: [...] | | Hi Antoine, | you're right and thanks a lot for this great piece of information. [...] | P.S.: Maybe these new os module features could use a bit more documentation? This suggestion comes up a lot WRT to the os.* functions. Unfortunately, the required doco for your issue is very platform dependent as you've just discovered; not merely your distro but the very kernel revisions. Maybe it should be made much more obvious that users _must_ go and consult their platform's documentation for specifics on how their platform implents the interface. On UNIX, that means "man 2 blah" or "man 3 blah", depending. Cheers, -- Cameron Simpson I suppose the solution would be to close the composition window and let my article sit for half an hour or so once I've finished with it, and then go back and proofread it once more. But that would be a pain in the proverbial bifurcated derriere. Part of the experience of flaming is to load a searing missive into the conceptual breech of my SPARCcannon and pull the imaginary lanyard whilst flushed with the adrenaline of mortal combat. - Geoff Miller, -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On 05/30/2013 12:18 AM, Steven D'Aprano wrote: > In some ways, Python is a more pure OOP language than Java: everything in > Python is an object, including classes themselves. > > In other ways, Python is a less pure and more practical language. You > don't have to wrap every piece of functionality in a class. Python > encourages you to write mixed procedural, functional and object oriented > code, whatever is best for the problem you are trying to solve, which is > very much in contrast to Java. Depending on your understanding of what object-oriented means, procedural and functional code is still object-oriented. In fact modules (the "file") are in essence singleton objects that define attributes, but in practice there can only be one instance of this object (module). Seems like in Java a lot of code is needed to implement singletons (factory, etc). module-level code (procedural code) could simply be thought of as singleton initialization/constructor code that's automatically run when the singleton is created, using import or __import__(). At the function level, a simple function is still an object that implements callable. Python's implementation of OO isn't quite smalltalk pure, but it is much more consistent than in Java or C++. But yes, Python does not force you to shoe-horn your programming into one particular pattern. -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Wednesday, May 29, 2013 7:24:48 PM UTC-5, Dan Stromberg wrote: > About the only thing I don't like is: > > var = 1, > > That binds var to a tuple (singleton) value, instead of 1. I don't understand why Python needs tuples anyway; at least not tuple literals!. I mean, i like the idea of a sequence type that is immutable as much as the next fella, however, i just hate the fact that we had to pay for this type with syntactical multiplicity only to be forever a slave to it's resulting quirkiness! Psst: Guido, i think you got screwed! (And they thought Jack was a fool for acquiring those beans!) With the demand for type literals growing all the larger as time goes on and the ASCII char set remaining static, there must be a better way! (And no folks, I'm not suggesting space cadet keyboards!) -- http://mail.python.org/mailman/listinfo/python-list
Re: Surprising difference between StringIO.StringIO and io.StringIO
io.StringIO only accepts Unicode input (i.e. u"multibyte string"),
while StringIO.StringIO accepts either 8 bit input or unicode input.
As you can see in the following excerpt from your traceback, the
'print_list' function creates an 8-bit string, which is then
(probably) passed to 'file.write' as the str variable, which actually
expects a unicode string, resulting in a TypeError:
File "/home/skipm/x86_64-linux3.1/lib/python2.7/traceback.py", line
23, in print_list
' File "%s", line %d, in %s' % (filename,lineno,name))
File "/home/skipm/x86_64-linux3.1/lib/python2.7/traceback.py", line
13, in _print
file.write(str+terminator)
Python 2.x strings default to 8 bit. This is fixed (!) in Python 3.
I'd suggest switching to Python 3 if there is no reason to use 2.x. I
found this [*] little PDF back when I switched from 2 to 3, which was
helpful.
[*]
http://ptgmedia.pearsoncmg.com/imprint_downloads/informit/promotions/python/python2python3.pdf
Greetings,
Göktuğ.
On Thu, May 30, 2013 at 11:46 PM, Skip Montanaro wrote:
> Consider this quick session (Python 2.7 using the tip of the 2.7
> branch in Mercurial):
>
> % python2.7
> Python 2.7.5+ (2.7:93eb15779050, May 30 2013, 15:27:39)
> [GCC 4.4.6 [TWW]] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
import traceback
import StringIO
s1 = StringIO.StringIO()
traceback.print_stack(file=s1)
print s1.getvalue()
> File "", line 1, in
>
import io
s2 = io.StringIO()
traceback.print_stack(file=s2)
> Traceback (most recent call last):
> File "", line 1, in
> File "/home/skipm/x86_64-linux3.1/lib/python2.7/traceback.py", line
> 269, in print_stack
> print_list(extract_stack(f, limit), file)
> File "/home/skipm/x86_64-linux3.1/lib/python2.7/traceback.py", line
> 23, in print_list
> ' File "%s", line %d, in %s' % (filename,lineno,name))
> File "/home/skipm/x86_64-linux3.1/lib/python2.7/traceback.py", line
> 13, in _print
> file.write(str+terminator)
> TypeError: unicode argument expected, got 'str'
print s2.getvalue()
>
> What is it about io.StringIO that it doesn't like strings and requires
> Unicode? This is on an OpenSUSE 12.1 system. I have tried with LANG
> set to the default ("en_US.UTF-8") and to "C". I also tried on a
> Solaris system with an older micro revision of Python 2.7. Same
> result.
>
> Am I missing something about how io.StringIO works? I thought it was
> a more-or-less drop-in replacement for StringIO.StringIO.
>
> Thx,
>
> Skip
> --
> http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
Re: Surprising difference between StringIO.StringIO and io.StringIO
On 30May2013 15:46, Skip Montanaro wrote:
| Consider this quick session (Python 2.7 using the tip of the 2.7
| branch in Mercurial):
|
| % python2.7
| Python 2.7.5+ (2.7:93eb15779050, May 30 2013, 15:27:39)
| [GCC 4.4.6 [TWW]] on linux2
[...]
| >>> import io
| >>> s2 = io.StringIO()
[...]
| File "/home/skipm/x86_64-linux3.1/lib/python2.7/traceback.py", line
| 13, in _print
| file.write(str+terminator)
| TypeError: unicode argument expected, got 'str'
| >>> print s2.getvalue()
|
| What is it about io.StringIO that it doesn't like strings and requires
| Unicode? This is on an OpenSUSE 12.1 system. I have tried with LANG
| set to the default ("en_US.UTF-8") and to "C". I also tried on a
| Solaris system with an older micro revision of Python 2.7. Same
| result.
|
| Am I missing something about how io.StringIO works? I thought it was
| a more-or-less drop-in replacement for StringIO.StringIO.
I would expect io.StringIO to be a match for the io.* stuff in Python
3. So it should care whether it is a binary stream or a text stream.
Whereas StringIO.StringIO is your good old Python 2 StringIO, which expects
strs.
On that basis, io.StringIO is a text stream, expecting Unicode
objects for transcription. 'str' is, in that context, probably
considered as 'bytes' in Python 3.
Cheers,
--
Cameron Simpson
A ship in harbor is safe - but that is not what ships are for. - John A. Shedd
--
http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Thu, 30 May 2013 12:07:40 +0300, Jussi Piitulainen wrote: > I suppose this depends on the complexity of the process and the amount > of data that produced the numbers of interest. Many individual > floating point operations are required to be within an ulp or two of > the mathematically correct result, I think, and the rounding error > when parsing a written representation of a number should be similar. Elementary operations (+, -, *, /, %, sqrt) are supposed to be within +/- 0.5 ULP (for round-to-nearest), i.e. the actual result should be the closest representable value to the exact result. Transcendental functions should ideally be within +/- 1 ULP, i.e. the actual result should be one of the two closest representable values to the exact result. Determining the closest value isn't always feasible due to the "table-maker's dilemma", i.e. the fact that regardless of the number of digits used for intermediate results, the upper and lower bounds can remain on opposite sides of the dividing line. -- http://mail.python.org/mailman/listinfo/python-list
Re: sendmail smtplib.SMTP('localhost') Where is the email?
On 30May2013 15:48, inq1ltd wrote:
| python help,
Please do not make new discussions by replying to an old discussion.
It is not enough to change the subject line; unless you also remove
any References: and In-Reply-To: header lines your message is still
considered part of the old discussion.
| I've tried this code which I got from:
| http://www.tutorialspoint.com/python/python_sending_email.htm
|
| I build this file and run it
[...]
|smtpObj = smtplib.SMTP('localhost')
|smtpObj.sendmail(sender, receivers, message)
|print "Successfully sent email"
[...]
| After running the the file and I get
| "Successfully sent email"
|
| My question is why doesn't webmaster get an email?
Well, this suggests that the message has been accepted by the mail
system on localhost. Not that final delivery was made anywhere else.
You now have to read the log files on your mail system to see what happened.
One easy check to do first is to see if it is still in your mail
system but undelivered. On a UNIX system running the command:
mailq
should tell you that. If the queue is empty, the message has been
sent somewhere and you must dig through the logs to find out where.
If the message is in the queue then the "mailq" command will probably
give a suggestion as to why.
Cheers,
--
Cameron Simpson
As you can see, unraveling even a small part of 'sendmail' can introduce more
complexity than answers.- Brian Costales, _sendmail_
--
http://mail.python.org/mailman/listinfo/python-list
RE: Building a HPC data assimilation system using Python?
Hi Matthew! I'm on a similar quest! I'm still learning the basics of Python so I may not be a good source of information. I'm reading a lot of stuff about how to use Python for the parallelization of code and data and found BSP[1] to be very interesting and perhaps worth the time to learn it! ;) [1] http://www.multicorebsp.com/ > Date: Wed, 29 May 2013 21:27:54 -0700 > Subject: Building a HPC data assimilation system using Python? > From: mattjamesfran...@gmail.com > To: python-list@python.org > > I have a prototype data assimilation code ( an ionospheric nowcast/forecast > model driven by GPS data ) that is written in IDL (interactive data language) > which is a horrible language choice for scaling the application up to large > datasets as IDL is serial and slow (interpreted). > > I am embarking on a project to convert this prototype into an operational > parallel HPC code. In the past I've used C++ for this kind of project and am > comfortable using MPI. On the other hand, I've recently started using python > and appreciate the flexibility and speed of development using python compared > with C++. I have read that there is a trend to use python as the high level > 'glue' for these kind of large number crunching projects, so it would seem > appropriate to go down that path. There are a number of C++ and FORTRAN(!) > libraries I'd need to incorporate that handle things such as the processing > of raw GPS data and computing ionospheric models, so I'd need to be able to > make the appropriate interface for these into python. > > If anyone uses python is this way, I'd appreciate any tips, hints, things to > be careful about and in general any war stories you can relate that you wish > you'd heard before making some mistake. > > Here are the things I have investigated that it looks like I'd probably need > to use: > > * scipy/numpy/matplotlib > * Cython (or pyrex?) for speeding up any bottlenecks that occur in python > code (as opposed to C++/FORTRAN libraries) > * MPI for Python (mpi4py). Does this play nice with Cython? > * Something to interface python with other language libraries. ctypes, swig, > boost? Which would be best for this application? > * Profiling. profile/cprofile are straightforward to use, but how do they > cope with a parallel (mpi4py) code? > * If a C++ library call has its own MPI calls, does that work smoothly with > mpi4py operating in the python part of the code? > > Sorry if some of this is a little basic, I'm trying to get up to speed on > this a quick as I can. > > Thanks in advance! > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: python b'...' notation
On Wednesday, May 29, 2013 3:19:42 PM UTC-7, Cameron Simpson wrote:
> On 29May2013 13:14, Ian Kelly wrote:
>
> | On Wed, May 29, 2013 at 12:33 PM, alcyon wrote:
>
> | > This notation displays hex values except when they are 'printable', in
> which case it displays that printable character. How do I get it to force
> hex for all bytes? Thanks, Steve
>
> |
>
> | Is this what you want?
>
> |
>
> | >>> ''.join('%02x' % x for x in b'hello world')
>
> | '68656c6c6f20776f726c64'
>
>
>
> Not to forget binascii.hexlify.
>
> --
>
> Cameron Simpson
>
>
>
> Every particle continues in its state of rest or uniform motion in a straight
>
> line except insofar as it doesn't. - Sir Arther Eddington
Thanks for the binascii.hexlify tip. I was able to make it work but I did have
to write a function to get it exactly the string I wanted. I wanted, for
example, to display as <0x0A 0x00> or to display as
<0x21 0xFF 0x28 0xC0>.
--
http://mail.python.org/mailman/listinfo/python-list
Re: sendmail smtplib.SMTP('localhost') Where is the email?
On Fri, May 31, 2013 at 5:48 AM, inq1ltd wrote: > python help, > > I've tried this code which I got from: > > http://www.tutorialspoint.com/python/python_sending_email.htm > > I build this file and run it > > After running the the file and I get > > "Successfully sent email" > > My question is why doesn't webmaster get an email? First point: Please send *plain text* emails. Your message came out double-spaced and with absolutely no indentation, which destroys the structure of Python code. (Your script is sufficiently simple that it's fairly clear how it had to be laid out, but when you force us to use our crystal balls for simple stuff like indentation, we can't use them again for something more important. The cooldown on these babies is pretty stiff sometimes.) Secondly, it helps a LOT to tell us what you're running under - Python version, OS, etc. One easy way to do that is to quote the text that the interactive interpreter opens with, eg: Python 2.4.5 (#1, Jul 22 2011, 02:01:04) [GCC 4.1.1] on mingw32 Python 3.4.0a0 (default:5dcd7ee0716a, Mar 30 2013, 08:17:06) [GCC 4.7.2] on linux Now, on to your actual code. The docs say: """This method will return normally if the mail is accepted for at least one recipient. Otherwise it will raise an exception. That is, if this method does not raise an exception, then someone should get your mail.""" That's nice confidence-inducing language, but I take exception (if you'll pardon the pun) to the last part. The only thing this function can know is that the mail has been accepted by the next hop. After that... well, the internet is a scary place, anything could happen. See if your SMTP server (the one running on localhost) has a nice log; you may be able to watch the message get processed by the next hop. By the way, I wouldn't bother with the try/except here. Just let the exception bubble up and be emitted to stderr. It'll be more useful that way :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thursday, May 30, 2013 11:36:54 AM UTC-7, Ian wrote: > I don't object to changing the join method (one of the more > shoe-horned string methods) back into a function, but to my eyes > you've got the arguments backward. It should be: > > def join(sep, iterable): return sep.join(iterable) > > Putting the separator first feels more natural to me because I expect > the separator to usually be short as compared to the iterable, which > is often a longer expression (as is the case in both of your > subsequent usages). Placing the separator first also preserves > consistency of interface with the str.join and bytes.join functions, > as well as the older string.join function. That may all be true, but the join() function shown will return a sequence starting with iterable[0] (followed by sep, and then iterable[1], then sep, etc.). I find it more natural to see iterable as the first argument passed to join() for that reason. Season to taste, I guess. -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Fri, May 31, 2013 at 5:22 AM, Steven D'Aprano wrote: > On Thu, 30 May 2013 16:40:52 +, Steven D'Aprano wrote: > >> On Fri, 31 May 2013 01:56:09 +1000, Chris Angelico wrote: > >>> You're assuming you can casually hit Ctrl-C to stop an infinite loop, >>> meaning that it's trivial. It's not. Not everything lets you do that; >>> or possibly halting the process will halt far more than you intended. >>> What if you're editing live code in something that's had uninterrupted >>> uptime for over a year? >> >> Then more fool you for editing live code. > > Ouch! That came out much harsher than it sounded in my head :( > > Sorry Chris, that wasn't intended as a personal attack against you, just > as a comment on the general inadvisability of modifying code on the fly > while it is being run. Apology accepted :) You're right that, in theory, a staging area is a Good Thing. But it's not always feasible. At work, we have a lot of Pike code that really does keep running indefinitely (okay, we have yet to get anywhere near a year's uptime for administrative reasons, but it'll be plausible once we go live; the >1year figure came from one of my personal projects). While all's going well, code changes follow a sane progression: dev -> alpha -> beta -> live with testing at every stage. What happens when we get a problem, though? Maybe some process is leaking resources, maybe we come under some kind of crazy DOS attack, whatever. We need a solution, and we need to not break things for the currently-connected clients. That means editing the live code. Of course, there are *some* protections; the new code won't be switched in unless it passes the compilation phase (think "except ImportError: keep_existing_code", kinda), and hopefully I would at least spin it up on my dev box before pushing it to live, but even so, there's every possibility that there'll be a specific case that I didn't think of - remembering that we're not talking about iteration from constant to constant, but from variable to constant or constant to variable or variable to variable. That's why I would prefer, in language design, for a 'failed loop' to result in no iterations than an infinite number of them. The infinite loop might be easily caught on my dev test - but only if I pass the code through that exact code path. But to go back to your point about editing live code: You backed down from the implication that it's *foolish*, but I would maintain it at a weaker level. Editing code in a running process is a *rare* thing to do. MOST programming is not done that way. It's like the old joke about the car mechanic and the heart surgeon (see eg http://www.medindia.net/jokes/viewjokes.asp?hid=200 if you haven't heard it, and I will be spoiling the punch line in the next line or so); most programmers are mechanics, shutting down the system to do any work on it, but very occasionally there are times when you need to do it with the engine running. It's like C compilers. Most of us never write them, but a few people (relatively) actually need to drop to the uber-low-level coding and think about how it all works in assembly language. For everyone else, thinking about machine code is an utter waste of time/effort, but that doesn't mean that it's folly for a compiler writer. Does that make sense? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
RE: Python toplevel in a Web page
> From: nob...@nowhere.org > Subject: Python toplevel in a Web page > Date: Thu, 30 May 2013 14:20:18 +0200 > To: python-list@python.org > > Hello, > I wonder if I can find some source code example > of a Python 3 toplevel box in a Web page. > Something simple, no mySQL, no Django hammer, etc. > Just the basics of the technology to get the > content of a small text editor in which the user Do you mean HTML element? > writes some Python script, to be analyzed (eval'ed) > then whose result is to be written in another text box. Analyzed by the browser or server side? > Simple, pythonistic. > Thanks for the pointer, > > franck > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Fri, May 31, 2013 at 4:51 AM, Ian Kelly wrote: > On Thu, May 30, 2013 at 12:44 PM, Chris Angelico wrote: >> On Fri, May 31, 2013 at 4:36 AM, Ian Kelly wrote: >>> I don't object to changing the join method (one of the more >>> shoe-horned string methods) back into a function, but to my eyes >>> you've got the arguments backward. It should be: >>> >>> def join(sep, iterable): return sep.join(iterable) >> >> Trouble is, it makes some sense either way. I often put the larger >> argument first - for instance, I would write 123412341324*5 rather >> than the other way around - and in this instance, it hardly seems as >> clear-cut as you imply. But the function can't be written to take them >> in either order, because strings are iterable too. (And functions that >> take args either way around aren't better than those that make a >> decision.) > > The reason I like having the shorter argument first (at least for > function calls) is for when I'm reading the code. If I'm interested > in the second argument, then to find it I have to scan over the first > argument. I would rather scan over something short like '\n' than > something longer like a list comprehension. It sounds like a trivial > thing, but it really does make it easier to find where an expression > starts and ends when the expression is short. Yes, I do agree with that argument. But there's more to picking argument order than simply "sort by predicted length" :) I'm not saying it's *wrong* to put sep first, just that it's not as clearly-and-obviously-the-one-right-way as you suggested. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
RE: Short-circuit Logic
> From: steve+comp.lang.pyt...@pearwood.info > Subject: Re: Short-circuit Logic > Date: Thu, 30 May 2013 05:42:17 + > To: python-list@python.org [...] > Here's another way, mathematically equivalent (although not necessarily > equivalent using floating point computations!) which avoids the divide-by- > zero problem: > > abs(a - b) < epsilon*a That's wrong! If abs(a) < abs(a-b)/epsilon you will break the commutative law. For example: import sys eps = sys.float_info.epsilon def almost_equalSD(a,b): return abs(a-b) < eps*a #special case a=1 b=1/(1-eps) almost_equalSD(a,b) == almost_equalSD(b,a) Returns False. This discussion reminded me of TAOCP and I paid a visit and bring the following functions: #Floating Point Comparison Operations #Knuth, Donald (1981). The Art of Computer Programming. 2nd ed. Vol. 2. p. 218. Addison-Wesley. ISBN 0-201-03822-6. import sys #floating point comparison: u ≺ v(ε) "definitely less than" (definition 21) def fpc_dlt(u,v,eps=sys.float_info.epsilon): au=abs(u) av=abs(v) return (v-u)> (eps*(au if au>av else av)) # v-u> ε*max(|u|,|v|) #floating point comparison: u ~ v(ε) "approximately equal to" (definition 22) def fpc_aeq(u,v,eps=sys.float_info.epsilon): au=abs(u) av=abs(v) return abs(v-u) <= (eps*(au if au>av else av)) # |v-u| <= ε*max(|u|,|v|) #floating point comparison: u ≻ v(ε) "definitely greater than" (definition 23) def fpc_dgt(u,v,eps=sys.float_info.epsilon): au=abs(u) av=abs(v) return (u-v)> (eps*(au if au>av else av)) # u-v> ε*max(|u|,|v|) #floating point comparison: u ≈ v(ε) "essentially equal to" (definition 24) def fpc_eeq(u,v,eps=sys.float_info.epsilon): au=abs(u) av=abs(v) return abs(v-u) <= (eps*(au if au > Whichever method you choose, there are gotchas to watch out for. > >> http://xkcd.com/1047/ > > Nice! > > > -- > Steven > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Surprising difference between StringIO.StringIO and io.StringIO
Consider this quick session (Python 2.7 using the tip of the 2.7
branch in Mercurial):
% python2.7
Python 2.7.5+ (2.7:93eb15779050, May 30 2013, 15:27:39)
[GCC 4.4.6 [TWW]] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import traceback
>>>
>>> import StringIO
>>> s1 = StringIO.StringIO()
>>> traceback.print_stack(file=s1)
>>> print s1.getvalue()
File "", line 1, in
>>>
>>> import io
>>> s2 = io.StringIO()
>>> traceback.print_stack(file=s2)
Traceback (most recent call last):
File "", line 1, in
File "/home/skipm/x86_64-linux3.1/lib/python2.7/traceback.py", line
269, in print_stack
print_list(extract_stack(f, limit), file)
File "/home/skipm/x86_64-linux3.1/lib/python2.7/traceback.py", line
23, in print_list
' File "%s", line %d, in %s' % (filename,lineno,name))
File "/home/skipm/x86_64-linux3.1/lib/python2.7/traceback.py", line
13, in _print
file.write(str+terminator)
TypeError: unicode argument expected, got 'str'
>>> print s2.getvalue()
What is it about io.StringIO that it doesn't like strings and requires
Unicode? This is on an OpenSUSE 12.1 system. I have tried with LANG
set to the default ("en_US.UTF-8") and to "C". I also tried on a
Solaris system with an older micro revision of Python 2.7. Same
result.
Am I missing something about how io.StringIO works? I thought it was
a more-or-less drop-in replacement for StringIO.StringIO.
Thx,
Skip
--
http://mail.python.org/mailman/listinfo/python-list
sendmail smtplib.SMTP('localhost') Where is the email?
python help,
I've tried this code which I got from:
http://www.tutorialspoint.com/python/python_sending_email.htm
I build this file and run it
---//---
#!/usr/bin/python
import smtplib
sender = "inq1...@inqvista.com"
receivers = ["webmas...@inqvista.com"]
message = """From: jol
To: webmaster
Subject: SMTP e-mail test
This is a test e-mail message.
"""
try:
smtpObj = smtplib.SMTP('localhost')
smtpObj.sendmail(sender, receivers, message)
print "Successfully sent email"
except SMTPException:
print "Error: unable to send email"
--//--
After running the the file and I get
"Successfully sent email"
My question is why doesn't webmaster get an email?
jol
--
http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Thu, May 30, 2013 at 1:30 PM, Neil Cerutti wrote: > On 2013-05-30, Chris Angelico wrote: >> On Thu, May 30, 2013 at 3:10 PM, Steven D'Aprano >> wrote: >>> # Wrong, don't do this! >>> x = 0.1 >>> while x != 17.3: >>> print(x) >>> x += 0.1 >> >> Actually, I wouldn't do that with integers either. > > I propose borrowing the concept of significant digits from the > world of Physics. > > The above has at least three significant digits. With that scheme > x would approximately equal 17.3 when 17.25 <= x < 17.35. > > But I don't see immediately how to calculate 17.25 and 17.35 from > 17.3, 00.1 and 3 significant digits. How about this: while round(x, 1) != round(17.3, 1): pass The second round call may be unnecessary. I would expect the parser to ensure that round(17.3, 1) == 17.3, but I'm not certain that is the case. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and GIL
On Thu, 30 May 2013 18:14:36 +, Ana Marija Sokovic wrote: > Hi, > > Can somebody explain to me how would you proceed in releasing the GIL > and whether you think it will have consequences? In pure Python code, you don't need to worry about the GIL, and in fact you cannot control it. Python controls it. You only need to release the GIL when writing C extensions. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thu, 30 May 2013 10:12:22 -0700, rusi wrote: > On Thu, May 30, 2013 at 9:34 AM, Ma Xiaojun > wrote: >> Wait a minute! Isn't the most nature way of doing/thinking "generating >> 9x9 multiplication table" two nested loop? > > Thats like saying that the most natur(al) way of using a car is to > attach a horse to it. >[...] > Likewise in the world of programming, 90% of programmers think > imperative/OO programming is natural while functional programming is > strange. Just wait 10 years and see if things are not drastically > different! It won't be. Functional programming goes back to Lisp, which is nearly as old as Fortran and older than Cobol. There have been many decades for functional languages to become mainstream, but they've never quite done it. There's no reason to think that the next decade will see a change to this. That's not to say that functional programming isn't one of the big three programming paradigms. But it's third out of the three, and quite a bit behind the other two: Procedural OOP Functional with Logic programming a distant fourth. Well, perhaps even third, ahead of Functional, taking into account that SQL is a form of Logic programming. Some modern Functional languages are really neat, like Haskell, but I think the sad truth is that to really master them (and not just make do with a small percentage of their functionality) is beyond 90% of programmers. I'm not ashamed to admit that I struggle with advanced FP concepts. But even if only a minority of programmers can master languages like Lisp, Haskell, or Scheme, doesn't mean that *all* programmers can't learn something from them. Functional programming is at least 50% a philosophy: * pass arguments to functions, and return results, rather than getting and setting state from a variable. This is a good strategy: it makes it easier to reason about the code, easier to document, easier to test, and makes it practical to use it in threaded code. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On 30/05/2013 19:44, Chris Angelico wrote: On Fri, May 31, 2013 at 4:36 AM, Ian Kelly wrote: On Wed, May 29, 2013 at 8:49 PM, rusi wrote: On May 30, 6:14 am, Ma Xiaojun wrote: What interest me is a one liner: print '\n'.join(['\t'.join(['%d*%d=%d' % (j,i,i*j) for i in range(1,10)]) for j in range(1,10)]) Ha,Ha! The join method is one of the (for me) ugly features of python. You can sweep it under the carpet with a one-line join function and then write clean and pretty code: #joinwith def joinw(l,sep): return sep.join(l) I don't object to changing the join method (one of the more shoe-horned string methods) back into a function, but to my eyes you've got the arguments backward. It should be: def join(sep, iterable): return sep.join(iterable) Trouble is, it makes some sense either way. I often put the larger argument first - for instance, I would write 123412341324*5 rather than the other way around - and in this instance, it hardly seems as clear-cut as you imply. But the function can't be written to take them in either order, because strings are iterable too. (And functions that take args either way around aren't better than those that make a decision.) And additional argument (pun not intended) for putting sep second is that you can give it a default value: def join(iterable, sep=""): return sep.join(iterable) -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On 2013-05-30, Chris Angelico wrote: > On Thu, May 30, 2013 at 3:10 PM, Steven D'Aprano > wrote: >> # Wrong, don't do this! >> x = 0.1 >> while x != 17.3: >> print(x) >> x += 0.1 > > Actually, I wouldn't do that with integers either. I propose borrowing the concept of significant digits from the world of Physics. The above has at least three significant digits. With that scheme x would approximately equal 17.3 when 17.25 <= x < 17.35. But I don't see immediately how to calculate 17.25 and 17.35 from 17.3, 00.1 and 3 significant digits. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Thu, 30 May 2013 16:40:52 +, Steven D'Aprano wrote: > On Fri, 31 May 2013 01:56:09 +1000, Chris Angelico wrote: >> You're assuming you can casually hit Ctrl-C to stop an infinite loop, >> meaning that it's trivial. It's not. Not everything lets you do that; >> or possibly halting the process will halt far more than you intended. >> What if you're editing live code in something that's had uninterrupted >> uptime for over a year? > > Then more fool you for editing live code. Ouch! That came out much harsher than it sounded in my head :( Sorry Chris, that wasn't intended as a personal attack against you, just as a comment on the general inadvisability of modifying code on the fly while it is being run. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: How to get an integer from a sequence of bytes
On 5/30/2013 2:26 PM, Mok-Kong Shen wrote: Am 27.05.2013 17:30, schrieb Ned Batchelder: On 5/27/2013 10:45 AM, Mok-Kong Shen wrote: From an int one can use to_bytes to get its individual bytes, but how can one reconstruct the int from the sequence of bytes? The next thing in the docs after int.to_bytes is int.from_bytes: http://docs.python.org/3.3/library/stdtypes.html#int.from_bytes I am sorry to have overlooked that. But one thing I yet wonder is why there is no direct possibilty of converting a byte to an int in [0,255], i.e. with a constrct int(b), where b is a byte. Presumably you want this to work: >>> int(b'\x03') 3 But you also want this to work: >>> int(b'7') 7 These two interpretations are incompatible. If b'\x03' becomes 3, then shouldn't b'\x37' become 55? But b'\x37' is b'7', and you want that to be 7. --Ned. M. K. Shen -- http://mail.python.org/mailman/listinfo/python-list
OpenMP uses only 1 core as soon as numpy is loaded
I use openMp in a C-extension that has an interface with Python.
In its simplest form I do this:
== code ==
#pragma omp parallel
{
#pragma omp for
for(int i=0; i<10; i++)
{
// multiply some matrices in C
}
}
== end of code ==
This all works fine, and it uses the number of cores I have. But if I import
numpy in my python session BEFORE I run the code, then it uses only 1 core (and
omp_num_procs also returns 1 core, instead of the maximum of 8 cores).
So how does numpy affect openMp, and does it have anything to do with the GIL
or something? I don't use any Python object in my parallel region.
Any help would be appreciated!
Wout
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to get an integer from a sequence of bytes
On 30 mai, 20:42, Ian Kelly wrote:
> On Thu, May 30, 2013 at 12:26 PM, Mok-Kong Shen
>
> wrote:
> > Am 27.05.2013 17:30, schrieb Ned Batchelder:
>
> >> On 5/27/2013 10:45 AM, Mok-Kong Shen wrote:
>
> >>> From an int one can use to_bytes to get its individual bytes,
> >>> but how can one reconstruct the int from the sequence of bytes?
>
> >> The next thing in the docs after int.to_bytes is int.from_bytes:
> >>http://docs.python.org/3.3/library/stdtypes.html#int.from_bytes
>
> > I am sorry to have overlooked that. But one thing I yet wonder is why
> > there is no direct possibilty of converting a byte to an int in [0,255],
> > i.e. with a constrct int(b), where b is a byte.
>
> The bytes object can be viewed as a sequence of ints. So if b is a
> bytes object of non-zero length, then b[0] is an int in range(0, 256).
Well, Python now "speaks" only "integer", the rest is
commodity and there is a good coherency.
>>> bin(255)
'0b'
>>> oct(255)
'0o377'
>>> 255
255
>>> hex(255)
'0xff'
>>>
>>> int('0b', 2)
255
>>> int('0o377', 8)
255
>>> int('255')
255
>>> int('0xff', 16)
255
>>>
>>> 0b
255
>>> 0o377
255
>>> 255
255
>>> 0xff
255
>>>
>>> type(0b)
>>> type(0o377)
>>> type(255)
>>> type(0xff)
jmf
--
http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thu, May 30, 2013 at 12:44 PM, Chris Angelico wrote: > On Fri, May 31, 2013 at 4:36 AM, Ian Kelly wrote: >> I don't object to changing the join method (one of the more >> shoe-horned string methods) back into a function, but to my eyes >> you've got the arguments backward. It should be: >> >> def join(sep, iterable): return sep.join(iterable) > > Trouble is, it makes some sense either way. I often put the larger > argument first - for instance, I would write 123412341324*5 rather > than the other way around - and in this instance, it hardly seems as > clear-cut as you imply. But the function can't be written to take them > in either order, because strings are iterable too. (And functions that > take args either way around aren't better than those that make a > decision.) The reason I like having the shorter argument first (at least for function calls) is for when I'm reading the code. If I'm interested in the second argument, then to find it I have to scan over the first argument. I would rather scan over something short like '\n' than something longer like a list comprehension. It sounds like a trivial thing, but it really does make it easier to find where an expression starts and ends when the expression is short. -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On May 30, 11:36 pm, Ian Kelly wrote:
> On Wed, May 29, 2013 at 8:49 PM, rusi wrote:
> > On May 30, 6:14 am, Ma Xiaojun wrote:
> >> What interest me is a one liner:
> >> print '\n'.join(['\t'.join(['%d*%d=%d' % (j,i,i*j) for i in
> >> range(1,10)]) for j in range(1,10)])
>
> > Ha,Ha! The join method is one of the (for me) ugly features of python.
> > You can sweep it under the carpet with a one-line join function and
> > then write clean and pretty code:
>
> > #joinwith
> > def joinw(l,sep): return sep.join(l)
>
> I don't object to changing the join method (one of the more
> shoe-horned string methods) back into a function, but to my eyes
> you've got the arguments backward. It should be:
>
> def join(sep, iterable): return sep.join(iterable)
>
> Putting the separator first feels more natural to me because I expect
> the separator to usually be short as compared to the iterable, which
> is often a longer expression (as is the case in both of your
> subsequent usages). Placing the separator first also preserves
> consistency of interface with the str.join and bytes.join functions,
> as well as the older string.join function.
This is a subjective view of course...
My problem is not method vs function but the order.
Ive seen/used join dozens of times. Yet I find
"".join(["apple","bear","cat"])
backkwards as compared to
["apple","bear","cat"].join("")
The consistency is a separate question -- not arguing about that. Just
that I dont like the look
--
http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Fri, May 31, 2013 at 4:36 AM, Ian Kelly wrote: > On Wed, May 29, 2013 at 8:49 PM, rusi wrote: >> On May 30, 6:14 am, Ma Xiaojun wrote: >>> What interest me is a one liner: >>> print '\n'.join(['\t'.join(['%d*%d=%d' % (j,i,i*j) for i in >>> range(1,10)]) for j in range(1,10)]) >> >> Ha,Ha! The join method is one of the (for me) ugly features of python. >> You can sweep it under the carpet with a one-line join function and >> then write clean and pretty code: >> >> #joinwith >> def joinw(l,sep): return sep.join(l) > > I don't object to changing the join method (one of the more > shoe-horned string methods) back into a function, but to my eyes > you've got the arguments backward. It should be: > > def join(sep, iterable): return sep.join(iterable) Trouble is, it makes some sense either way. I often put the larger argument first - for instance, I would write 123412341324*5 rather than the other way around - and in this instance, it hardly seems as clear-cut as you imply. But the function can't be written to take them in either order, because strings are iterable too. (And functions that take args either way around aren't better than those that make a decision.) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: How to get an integer from a sequence of bytes
On Thu, May 30, 2013 at 12:26 PM, Mok-Kong Shen wrote: > Am 27.05.2013 17:30, schrieb Ned Batchelder: >> >> On 5/27/2013 10:45 AM, Mok-Kong Shen wrote: >>> >>> From an int one can use to_bytes to get its individual bytes, >>> but how can one reconstruct the int from the sequence of bytes? >>> >> The next thing in the docs after int.to_bytes is int.from_bytes: >> http://docs.python.org/3.3/library/stdtypes.html#int.from_bytes > > > I am sorry to have overlooked that. But one thing I yet wonder is why > there is no direct possibilty of converting a byte to an int in [0,255], > i.e. with a constrct int(b), where b is a byte. The bytes object can be viewed as a sequence of ints. So if b is a bytes object of non-zero length, then b[0] is an int in range(0, 256). -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Wed, May 29, 2013 at 8:49 PM, rusi wrote: > On May 30, 6:14 am, Ma Xiaojun wrote: >> What interest me is a one liner: >> print '\n'.join(['\t'.join(['%d*%d=%d' % (j,i,i*j) for i in >> range(1,10)]) for j in range(1,10)]) > > Ha,Ha! The join method is one of the (for me) ugly features of python. > You can sweep it under the carpet with a one-line join function and > then write clean and pretty code: > > #joinwith > def joinw(l,sep): return sep.join(l) I don't object to changing the join method (one of the more shoe-horned string methods) back into a function, but to my eyes you've got the arguments backward. It should be: def join(sep, iterable): return sep.join(iterable) Putting the separator first feels more natural to me because I expect the separator to usually be short as compared to the iterable, which is often a longer expression (as is the case in both of your subsequent usages). Placing the separator first also preserves consistency of interface with the str.join and bytes.join functions, as well as the older string.join function. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and GIL
On Fri, May 31, 2013 at 4:14 AM, Ana Marija Sokovic wrote: > Hi, > > Can somebody explain to me how would you proceed in releasing the GIL and > whether you think it will have consequences? You release the GIL in C-level code when you don't need to work with Python objects for a while. Simple example is when you need to wait for something - for instance, if you attempt to read from a pipe, you can release the GIL before reading, then reacquire it afterward. The consequence is that you can't do anything with Python objects till you reacquire it. It's like any other resource-guarding mutex lock. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: How to get an integer from a sequence of bytes
Am 27.05.2013 17:30, schrieb Ned Batchelder: On 5/27/2013 10:45 AM, Mok-Kong Shen wrote: From an int one can use to_bytes to get its individual bytes, but how can one reconstruct the int from the sequence of bytes? The next thing in the docs after int.to_bytes is int.from_bytes: http://docs.python.org/3.3/library/stdtypes.html#int.from_bytes I am sorry to have overlooked that. But one thing I yet wonder is why there is no direct possibilty of converting a byte to an int in [0,255], i.e. with a constrct int(b), where b is a byte. M. K. Shen -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Fri, May 31, 2013 at 3:59 AM, rusi wrote:
> On May 30, 10:28 pm, Chris Angelico wrote:
>> On Fri, May 31, 2013 at 3:12 AM, rusi wrote:
>> > You associate the primal (f)act of thinking about programming with
>> > *doing* the generating.
>> > By contrast the functional programmer thinks about what *is* the
>> > result.
>>
>> I wish you'd explain that to my boss :) He often has trouble
>> understanding why sometimes I put two syntactic statements on one
>> line, such as:
>>
>> for (int i=0;i> {
>> //do something with foo[i]
>>
>> }
>>
>> In Python, that would probably be done with a list comprehension or
>> some other form of filtered iteration, and is to my mind a single
>> operation - "iterate over all the marked foo" is just as much a valid
>> loop header as "iterate over all the foo". This is a simple example,
>> and what you say about thinking about what *is* the result doesn't
>> really translate well into a C++ example, but the broader concept
>> applies: there's a difference between code as the compiler/interpreter
>> sees it and code as the programmer sees it, and there is not always a
>> 1:1 correspondence of statements.
>>
>> ChrisA
>
> I had a blog post about line-length in programs
> http://blog.languager.org/2012/10/layout-imperative-in-functional.html
>
> followed by an interesting discussion on the haskell mailing list
> http://groups.google.com/group/haskell-cafe/browse_thread/thread/f146ec7753c5db56/09eb73b1efe79fec
>
> The comment by Alexander Solla was insightful and is probably what you
> are saying.
>
> [Probably!! I am not sure what you are saying!]
Unfortunately a lot of your code specifics don't mean much to me
because I don't speak Haskell, but you are making several similar
points. A line of code should not be defined by the language's syntax,
but by the programmer's intention. A Python example might be:
for x in filter(lambda x: x%5 and x%6,range(40)):
# do something with the numbers that don't count by 5 or 6
Stupid example, but it still puts the conditional inside the loop
header. I'm sure you can come up with a more useful case!
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Python and GIL
Hi, Can somebody explain to me how would you proceed in releasing the GIL and whether you think it will have consequences? Thanks Ana -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
functional VS imperative? mechanical thinking VS mathematical thinking? Sounds interesting. -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On May 30, 10:28 pm, Chris Angelico wrote:
> On Fri, May 31, 2013 at 3:12 AM, rusi wrote:
> > You associate the primal (f)act of thinking about programming with
> > *doing* the generating.
> > By contrast the functional programmer thinks about what *is* the
> > result.
>
> I wish you'd explain that to my boss :) He often has trouble
> understanding why sometimes I put two syntactic statements on one
> line, such as:
>
> for (int i=0;i {
> //do something with foo[i]
>
> }
>
> In Python, that would probably be done with a list comprehension or
> some other form of filtered iteration, and is to my mind a single
> operation - "iterate over all the marked foo" is just as much a valid
> loop header as "iterate over all the foo". This is a simple example,
> and what you say about thinking about what *is* the result doesn't
> really translate well into a C++ example, but the broader concept
> applies: there's a difference between code as the compiler/interpreter
> sees it and code as the programmer sees it, and there is not always a
> 1:1 correspondence of statements.
>
> ChrisA
I had a blog post about line-length in programs
http://blog.languager.org/2012/10/layout-imperative-in-functional.html
followed by an interesting discussion on the haskell mailing list
http://groups.google.com/group/haskell-cafe/browse_thread/thread/f146ec7753c5db56/09eb73b1efe79fec
The comment by Alexander Solla was insightful and is probably what you
are saying.
[Probably!! I am not sure what you are saying!]
--
http://mail.python.org/mailman/listinfo/python-list
usage of os.posix_fadvise
Antoine Pitrou wrote:
>Hi,
>Wolfgang Maier biologie.uni-freiburg.de> writes:
>>
>> Dear all,
>> I was just experimenting for the first time with os.posix_fadvise(), which
>> is new in Python3.3 . I'm reading from a really huge file (several GB) and I
>> want to use the data only once, so I don't want OS-level page caching. I
>> tried os.posix_fadvise with the os.POSIX_FADV_NOREUSE and with the
>> os.POSIX_FADV_DONTNEED flags, but neither seemed to have any effect on the
>> caching behaviour of Ubuntu (still uses all available memory to page cache
>> my I/O).
>> Specifically, I was trying this:
>>
>> import os
>> fd = os.open('myfile', os.O_RDONLY)
>> # wasn't sure about the len parameter in fadvise,
>> # so thought I just use it on the first 4GB
>> os.posix_fadvise(fd, 0, 40, os.POSIX_FADV_NOREUSE) # or DONTNEED
>
>The Linux version of "man posix_fadvise" probably holds the answer:
>
>"In kernels before 2.6.18, POSIX_FADV_NOREUSE had the same semantics
>as POSIX_FADV_WILLNEED. This was probably a bug; since kernel
>2.6.18, this flag is a no-op."
>
>"POSIX_FADV_DONTNEED attempts to free cached pages associated with the
>specified region. This is useful, for example, while streaming large
>files. A program may periodically request the kernel to free cached
>data that has already been used, so that more useful cached pages are
>not discarded instead."
>
>So, in summary:
>
>- POSIX_FADV_NOREUSE doesn't do anything on (modern) Linux kernels
>- POSIX_FADV_DONTNEED must be called *after* you are done with a range of
> data, not before you read it (note that I haven't tested to confirm it >:-))
>
>Regards
>
>Antoine.
Hi Antoine,
you're right and thanks a lot for this great piece of information.
The following quick check works like a charm now:
>>> fo = open('myfile', 'rb')
>>> chunk_size = 16184
>>> last_flush = 0
>>> d = fo.read(chunk_size)
>>> pos = chunk_size
>>> while d:
... d = fo.read(chunk_size)
... pos += chunk_size
... if pos > 20:
... print ('another 2GB read, flushing')
... os.posix_fadvise(fo.fileno(), last_flush, last_flush+pos,
os.POSIX_FADV_DONTNEED)
... last_flush += pos
... pos = 0
With this page caching for my huge file (30 GB in that case) still occurs,
of course, but it never occupies more than 2 GB of memory. This way it
should interfere less with cached data of other applications.
Have to test carefully how much that improves overall performance of the
system, but for the moment I'm more than happy!
Best wishes,
Wolfgang
P.S.: Maybe these new os module features could use a bit more documentation?
--
http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Fri, May 31, 2013 at 3:46 AM, Ma Xiaojun wrote:
> On Fri, May 31, 2013 at 1:28 AM, Chris Angelico wrote:
>> for (int i=0;i> {
>> //do something with foo[i]
>> }
>
> This is interesting!
Yeah, but that's C++. It won't work in Python without this directive:
from __future__ import braces
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Fri, May 31, 2013 at 1:28 AM, Chris Angelico wrote:
> for (int i=0;i {
> //do something with foo[i]
> }
This is interesting!
--
http://mail.python.org/mailman/listinfo/python-list
Re: Encodign issue in Python 3.3.1 (once again)
On Fri, May 31, 2013 at 3:01 AM, Michael Torrie wrote: > On 05/30/2013 08:40 AM, Chris Angelico wrote: >> but if he's actively using the module, he probably knows where to >> find its docs. > > One would hope, but alas one probably hopes in vain. I'm not sure he > wants to spend the time to read the code he's using and understand. > He's in too much of a hurry to simply get a result. Wonder how much less exciting this mailing list would be if he switched to decaf... *ducks for cover* ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Fri, May 31, 2013 at 3:12 AM, rusi wrote: > You associate the primal (f)act of thinking about programming with > *doing* the generating. > By contrast the functional programmer thinks about what *is* the > result. I wish you'd explain that to my boss :) He often has trouble understanding why sometimes I put two syntactic statements on one line, such as: for (int i=0;ihttp://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Fri, May 31, 2013 at 2:58 AM, rusi wrote: > On May 30, 5:58 pm, Chris Angelico wrote: >> The alternative would be an infinite number of iterations, which is far far >> worse. > > There was one heavyweight among programming teachers -- E.W. Dijkstra > -- who had some rather extreme views on this. > > He taught that when writing a loop of the form > > i = 0 > while i < n: > some code > i += 1 > > one should write the loop test as i != n rather than i < n, precisely > because if i got erroneously initialized to some value greater than n, > (and thereby broke the loop invariant), it would loop infinitely > rather than stop with a wrong result. And do you agree or disagree with him? :) I disagree with Dijkstra on a number of points, and this might be one of them. When you consider that the obvious Pythonic version of that code: for i in range(n,m): some code loops over nothing and does not go into an infinite loop (or throw an exception) when n >= m, you have to at least acknowledge that I'm in agreement with Python core code here :) That doesn't mean it's right, of course, but it's at least a viewpoint that someone has seen fit to enshrine in important core functionality. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
THRINAXODON BURTS AN AXON!
THRINAXODON HAS JUST ENTERED THE WORLD OF REASON-RALLY. SUCH WILD BEASTS AS PETER NYIKOS, PZ MYERS, RICHARD DAWKINS, DR. EVIL, JOHN S. WILKINS, JERRY COYNE, MARK ISAAK, SKYEYES, BUDIKKA666, FIDEL TUBARE, SBAELNAVE, BOB CASANOVA, JOHN HARSHMAN, DAVID IAIN GREIG, AND JILLERY WERE THERE. THEY WERE MISREPRESENTING, AND DISTORTING THE TRUTH!!! THRINAXODON REPORTS THIS LIVE. == Thrinaxodon scaring this guy, to DEATH. http://www.youtube.com/watch?v=9Zlzin6PIo8 == Thrinaxodon, in the form of prion, infecting this person's temporal lobe, and causing DEATH SLOWLY http://upload.wikimedia.org/wikipedia/commons/thumb/2/2e/CJD_spongios... ___ ___ YE EVILUTIONISTS, THEY INFECT THE SOUL< AND GIVE YOU NIGHTMARES. THEY GIVE YOU... EVVVOOLUTIONIST"S DESEASE! ___ _ PROOF OF LIFE AFTER DEATH http://media.tumblr.com/tumblr_lxlws5u4tE1qjlz5q.jpg ___ __ === = THRINAXODON KILLS A RABBIT WITH A COUPLE OTHER PEOPLE http://upload.wikimedia.org/wikipedia/commons/7/74/La_Chasse_au_furet... === -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thu, May 30, 2013 at 9:34 AM, Ma Xiaojun wrote: > > On Thu, May 30, 2013 at 10:49 AM, rusi wrote: > > Ha,Ha! The join method is one of the (for me) ugly features of python. > > You can sweep it under the carpet with a one-line join function and > > then write clean and pretty code: > > > > #joinwith > > def joinw(l,sep): return sep.join(l) > > > > def mktable(m,n): > > return [[(j,i,i*j) for i in range(1,m+1)] for j in range(1,n+1)] > > > > def prettyrow(r): > > return joinw(['%d*%d=%d' % ele for ele in r],'\t') > > > > def prettytable(t): > > return joinw([prettyrow(r) for r in t],'\n') > > Wait a minute! Isn't the most nature way of doing/thinking "generating > 9x9 multiplication table" two nested loop? Thats like saying that the most natur(al) way of using a car is to attach a horse to it. Sure if all you've seen are horse-carriages then a horseless carriage will seem nonsensical. Once you get used to horseless carriages the horsed ones would seem quite a nuisance [global warming aside!!] The only problem with this analogy is that you have to imagine the world of horse/horseless 'cars' in 1900 and not 2013. Likewise in the world of programming, 90% of programmers think imperative/OO programming is natural while functional programming is strange. Just wait 10 years and see if things are not drastically different! > > I understand that using "join", we don't need to worry about "one > element doesn't need white space" issue. And that's it. More evidence of the above! join like list-comprehensions are tools for functional programming and not merely ways of writing loops in short. The key difference between the two is seen not in the code you write but in the natural language (English) you use to describe it: > Wait a minute! Isn't the most nature way of doing/thinking "generating > 9x9 multiplication table" two nested loop? You associate the primal (f)act of thinking about programming with *doing* the generating. By contrast the functional programmer thinks about what *is* the result. Please also note the difference in emphasis in your code and mine. Rewriting to make it more obvious: # The main multiplication table building function def multtable(m,n): return [[(j,i,i*j) for i in range(1,m+1)] for j in range(1,n+1)] # The 'icing' to get it into the shape you want def joinw(l,sep): return sep.join(l) def prettytable(t): return joinw([joinw(['%d*%d=%d' % ele for ele in r],'\t') for r in t],'\n') The call that puts them together: >>> print prettytable(multtable(6,7)) The nice thing about the last is that it separates three things: 1. Computing the actual table 2. The string form of that table that looks the way we want 3. Printing that string And I can see each of these separately: In [2]: multtable(2,3) Out[2]: [[(1, 1, 1), (1, 2, 2)], [(2, 1, 2), (2, 2, 4)], [(3, 1, 3), (3, 2, 6)]] In [3]: prettytable(_) Out[3]: '1*1=1\t1*2=2\n2*1=2\t2*2=4\n3*1=3\t3*2=6' In [4]: print _ 1*1=1 1*2=2 2*1=2 2*2=4 3*1=3 3*2=6 --- I would be pleasantly surprised if the double nested loop you think natural, allowed for such a modular separation! -- http://mail.python.org/mailman/listinfo/python-list
Re: Encodign issue in Python 3.3.1 (once again)
On 05/30/2013 08:40 AM, Chris Angelico wrote: > but if he's actively using the module, he probably knows where to > find its docs. One would hope, but alas one probably hopes in vain. I'm not sure he wants to spend the time to read the code he's using and understand. He's in too much of a hurry to simply get a result. -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On 05/30/2013 08:56 AM, Chris Angelico wrote: On Fri, May 31, 2013 at 1:02 AM, Ethan Furman wrote: On 05/30/2013 05:58 AM, Chris Angelico wrote: If you iterate from 1000 to 173, you get nowhere. This is the expected behaviour; this is what a C-style for loop would be written as, it's what range() does, it's the normal thing. Going from a particular starting point to a particular ending point that's earlier than the start results in no iterations. The alternative would be an infinite number of iterations, which is far far worse. If the bug is the extra three zeros (maybe it should have been two), then silently skipping the loop is the "far, far worse" scenario. With the infinite loop you at least know something went wrong, and you know it pretty darn quick (since you are testing, right? ;). You're assuming you can casually hit Ctrl-C to stop an infinite loop, meaning that it's trivial. It's not. Not everything lets you do that; or possibly halting the process will halt far more than you intended. What if you're editing live code in something that's had uninterrupted uptime for over a year? Doing nothing is much safer than getting stuck in an infinite loop. And yes, I have done exactly that, though not in Python. Don't forget, your start/stop figures mightn't be constants, so you might not see it in testing. I can't imagine ANY scenario where you'd actually *want* the infinite loop behaviour, while there are plenty where you want it to skip the loop, and would otherwise have to guard it with an if. We're not talking about skipping the loop on purpose, but on accident. Sure, taking a system down is no fun -- on the other hand, how much data corruption can occur before somebody realises there's a problem, and then how long to track it down to a silently, accidently, skipped loop? -- ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On May 30, 5:58 pm, Chris Angelico wrote: > The alternative would be an infinite number of iterations, which is far far > worse. There was one heavyweight among programming teachers -- E.W. Dijkstra -- who had some rather extreme views on this. He taught that when writing a loop of the form i = 0 while i < n: some code i += 1 one should write the loop test as i != n rather than i < n, precisely because if i got erroneously initialized to some value greater than n, (and thereby broke the loop invariant), it would loop infinitely rather than stop with a wrong result. -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On Fri, May 31, 2013 at 2:40 AM, Wolfgang Keller wrote: > A GUI that can not be used without taking the ten fingers off the > keyboard is indeed entirely unusable for any half-proficient > screenworker. And anyone doing actual productive screenwork every day > for more than just a few months will inevitably (have to) get proficient > (unless completely braindead). My ten fingers stay on my keyboard, which looks somewhat thus: http://www.xbitlabs.com/images/mobile/lenovo-thinkpad-t61/keyboard.jpg See the red dot in the middle? Mouse. See the keys all around it? My hands are all over that. I can casually mouse and keyboard at the same time. Doesn't bother me. THIS is a professional programmer's workspace. :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Google App Engine dev_appserver and pdb?
Is there a way to use pdb to debug Google apps written in Python? When I start the development system to run the app "test" like this - './google_appengine/dev_appserver.py' './test' - I'd like to send the program into debug. I couldn't see anything in the documentation how to do this. If I do this - python -mpdb './google_appengine/dev_appserver.py' './test' - then dev_appserver.py goes into debug but doesn't know anything about "test". -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
> >> suppose I now want the app natively on my phone (because that's all > >> the rage). It's an iPhone. Oh. Apple doesn't support Python. > >> Okay, rewrite the works, including business logic, in Objective C. > >> Now I want it on my android phone. > > > > Those are gadgets, not work tools. > > As a professional programmer I'm afraid you're going to soon find > yourself out of work if you really see things that way. As a "domain expert", I come from the end-user side of "enterprise applications" and again; those are not tools for screenworkers to get actual work done, but consumer crap for fad-driven gadget-addicted kids (regardless of nominal age). > I honestly used to feel that way about graphical user interfaces. A GUI that can not be used without taking the ten fingers off the keyboard is indeed entirely unusable for any half-proficient screenworker. And anyone doing actual productive screenwork every day for more than just a few months will inevitably (have to) get proficient (unless completely braindead). Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Fri, 31 May 2013 01:56:09 +1000, Chris Angelico wrote: > On Fri, May 31, 2013 at 1:02 AM, Ethan Furman > wrote: >> On 05/30/2013 05:58 AM, Chris Angelico wrote: >>> If you iterate from 1000 to 173, you get nowhere. This is the expected >>> behaviour; this is what a C-style for loop would be written as, it's >>> what range() does, it's the normal thing. Going from a particular >>> starting point to a particular ending point that's earlier than the >>> start results in no iterations. The alternative would be an infinite >>> number of iterations, which is far far worse. >> >> If the bug is the extra three zeros (maybe it should have been two), >> then silently skipping the loop is the "far, far worse" scenario. With >> the infinite loop you at least know something went wrong, and you know >> it pretty darn quick (since you are testing, right? ;). > > You're assuming you can casually hit Ctrl-C to stop an infinite loop, > meaning that it's trivial. It's not. Not everything lets you do that; or > possibly halting the process will halt far more than you intended. What > if you're editing live code in something that's had uninterrupted uptime > for over a year? Then more fool you for editing live code. By the way, this is Python. Editing live code is not easy, if it's possible at all. But even when possible, it's certainly not sensible. You don't insist on your car mechanic giving your car a grease and oil change while you're driving at 100kmh down the freeway, and you shouldn't insist that your developers modify your code while it runs. In any case, your arguing about such abstract, hypothetical ideas that, frankly, *anything at all* might be said about it. "What if Ctrl-C causes some great disaster?" can be answered with an equally hypothetical "What if Ctrl-C prevents some great disaster?" > Doing nothing is much safer than getting stuck in an > infinite loop. I disagree. And I agree. It all depends on the circumstances. But, given that we are talking about Python where infinite loops can be trivially broken out of, *in my experience* they are less-worse than silently doing nothing. I've occasionally written faulty code that enters an infinite loop. When that happens, it's normally pretty obvious: something which should complete in a millisecond is still running after ten minutes. That's a clear, obvious, *immediate* sign that I've screwed up, which leads to me fixing the problem. On the other hand, I've occasionally written faulty code that does nothing at all. The specific incident I am thinking of, I wrote a bunch of doctests which *weren't being run at all*. For nearly two weeks (not full time, but elapsed time) I was developing this code, before I started to get suspicious that *none* of the tests had failed, not even once. I mean, I'm not that good a programmer. Eventually I put in some deliberate errors, and they still didn't fail. In actuality, nearly every test was failing, my entire code base was rubbish, and I just didn't know it. So, in this specific case, I would have *much* preferred an obvious failure (such as an infinite loop) than code that silently does the wrong thing. We've drifted far from the original topic. There is a distinct difference between guarding against inaccuracies in floating point calculations: # Don't do this! total = 0.0 while total != 1.0: total += 0.1 and guarding against typos in source code: total = 90 # Oops, I meant 0 while total != 10: total += 1 The second case is avoidable by paying attention when you code. The first case is not easily avoidable, because it reflects a fundamental difficulty with floating point types. As a general rule, "defensive coding" does not extend to the idea of defending against mistakes in your code. The compiler, linter or unit tests are supposed to do that. Occasionally, I will code defensively when initialising tedious data sets: prefixes = ['y', 'z', 'a', 'f', 'p', 'n', 'µ', 'm', 'k', 'M', 'G', 'T', 'P', 'E', 'Z', 'Y'] assert len(prefixes) == 16 but that's about as far as I go. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Fri, May 31, 2013 at 1:02 AM, Ethan Furman wrote: > On 05/30/2013 05:58 AM, Chris Angelico wrote: >> If you iterate from 1000 to 173, you get nowhere. This is the expected >> behaviour; this is what a C-style for loop would be written as, it's >> what range() does, it's the normal thing. Going from a particular >> starting point to a particular ending point that's earlier than the >> start results in no iterations. The alternative would be an infinite >> number of iterations, which is far far worse. > > If the bug is the extra three zeros (maybe it should have been two), then > silently skipping the loop is the "far, far worse" scenario. With the > infinite loop you at least know something went wrong, and you know it pretty > darn quick (since you are testing, right? ;). You're assuming you can casually hit Ctrl-C to stop an infinite loop, meaning that it's trivial. It's not. Not everything lets you do that; or possibly halting the process will halt far more than you intended. What if you're editing live code in something that's had uninterrupted uptime for over a year? Doing nothing is much safer than getting stuck in an infinite loop. And yes, I have done exactly that, though not in Python. Don't forget, your start/stop figures mightn't be constants, so you might not see it in testing. I can't imagine ANY scenario where you'd actually *want* the infinite loop behaviour, while there are plenty where you want it to skip the loop, and would otherwise have to guard it with an if. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On 05/30/2013 05:58 AM, Chris Angelico wrote: On Thu, May 30, 2013 at 10:40 PM, Roy Smith wrote: if somebody were to accidentally drop three zeros into the source code: x = 1000 while x < 173: print(x) x += 1 should the loop just quietly not execute (which is what it will do here)? Will that make your program correct again, or will it simply turn this into a difficult to find bug? If you're really worried about that, why not: If you iterate from 1000 to 173, you get nowhere. This is the expected behaviour; this is what a C-style for loop would be written as, it's what range() does, it's the normal thing. Going from a particular starting point to a particular ending point that's earlier than the start results in no iterations. The alternative would be an infinite number of iterations, which is far far worse. If the bug is the extra three zeros (maybe it should have been two), then silently skipping the loop is the "far, far worse" scenario. With the infinite loop you at least know something went wrong, and you know it pretty darn quick (since you are testing, right? ;). -- ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: The state of pySerial
On 30/05/2013 02:32, Ma Xiaojun wrote: I've already mailed the author, waiting for reply. For Windows people, downloading a exe get you pySerial 2.5, which list_ports and miniterm feature seems not included. To use 2.6, download the tar.gz and use standard "setup.py install" to install it (assume you have .py associated) . There is no C compiling involved in the installation process. For whether Python 3.3 is supported or not. I observed something like: http://paste.ubuntu.com/5715275/ . miniterm works for Python 3.3 at this time. The problem there is that 'desc' is a bytestring, but the regex pattern can match only a Unicode string (Python 3 doesn't let you mix bytestrings and Unicode string like a Python 2). The simplest fix would probably be to decode 'desc' to Unicode. -- http://mail.python.org/mailman/listinfo/python-list
Re: [ANN] pyknon: Simple Python library to generate music in a hacker friendly way.
Thanks a lot, Sir. Just what I was looking for. This is a fantastic library for python. -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
On 30 May 2013 15:47, Eternaltheft wrote:
>> And perhaps you meant for your function to CALL drawBoard(), rather than
>> returning the function object drawBoard.
>>
>> DaveA
>
> do you think it would be better if i call drawBoard?
Please read http://www.catb.org/esr/faqs/smart-questions.html, or
anything similar you can find.
Start from the beginning.
1) What are you doing? Not "what are you doing now" but, from the top,
what is the goal you are trying to achieve?
2) How have you tried to do it? Code would be nice here too, but
don't just send really large blocks of irrelevant code. For example, your
"drawBoard" function would be better surmised as:
def drawBoard(b):
Turtle.speed(0)
Turtle.up()
Turtle.goto(-4 * b, 4 * b)
Turtle.down()
for i in range (8):
Turtle.forward(b)
Turtle.right(90)
... # etc, drawing a board
3) What are you stuck on? In this case, you are stuck on what to do
after you call input("stuff"), if I understand. What do you want to do
- not "how do you want to do it" but what is it that you are doing?
4) Finally, we should understand what calling drawBoard is for. Ask us
again and we'll be much more likely to give good answers.
--
http://mail.python.org/mailman/listinfo/python-list
Re: User Input
> And perhaps you meant for your function to CALL drawBoard(), rather than > returning the function object drawBoard. > DaveA do you think it would be better if i call drawBoard? -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
> And perhaps you meant for your function to CALL drawBoard(), rather than > > returning the function object drawBoard. > > DaveA do you think it would be better if i call drawBoard? -- http://mail.python.org/mailman/listinfo/python-list
Re: Encodign issue in Python 3.3.1 (once again)
On Fri, May 31, 2013 at 12:35 AM, Michael Torrie wrote: > On 05/30/2013 05:47 AM, Νίκος Γκρ33κ wrote: >> The moen i switched "charset = 'utf-8'" => "charset = 'utf8'" all >> started to work properly! > > Glad you have it working. > > Perhaps this should be a lesson to you, Nick. Chris was able to spot > your problem by READING THE DOCUMENTATION, which he probably found > through some quick searching on Google. These are things you can and > should do too. As well as looking at the source code of the modules you > may have downloaded and are using, and understanding how the code works > (or fits together) and how to debug. Well, actually I didn't find the documentation when I did those quick web searches, which is why I ended up looking at the source. That probably doubled the time requirement, and roughly doubled the minimum skill points to cast this spell (programming is an RPG, right?), but if he's actively using the module, he probably knows where to find its docs. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Encodign issue in Python 3.3.1 (once again)
On 05/30/2013 05:47 AM, Νίκος Γκρ33κ wrote: > The moen i switched "charset = 'utf-8'" => "charset = 'utf8'" all > started to work properly! Glad you have it working. Perhaps this should be a lesson to you, Nick. Chris was able to spot your problem by READING THE DOCUMENTATION, which he probably found through some quick searching on Google. These are things you can and should do too. As well as looking at the source code of the modules you may have downloaded and are using, and understanding how the code works (or fits together) and how to debug. You seem to have a tendency to try to attack your problems with rather blunt instruments, and then come to the list where one of the list members invariable does the footwork for you. -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
On 30/05/2013 15:03, Eternaltheft wrote: do you think ti would be better if i call drawBoard? How would I know if you don't quote any context? -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
do you think ti would be better if i call drawBoard? -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this code correct?
Τη Πέμπτη, 30 Μαΐου 2013 4:36:11 μ.μ. UTC+3, ο χρήστης Chris Angelico έγραψε: > Lemme guess, he's next going to ask on the PostgreSQL mailing list. I > mean, that's unrelated to Python, right? Well Chris, i'am not that stupid :) I intend to ask questions unrelated to Python to a list unrelated to Python but related to my subject, whish is 'suexec', that would mean a linux list. -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
On 05/30/2013 09:10 AM, Eternaltheft wrote:
yeah i found out why it wasn't defined before because i tried to put it into a
function.
That's not a sentence, and it doesn't make sense in any permutation I
can do on it.
this is my drawBoard function:
import turtle as Turtle
Turtle.title("Checkers")
b = 75
def drawBoard(b):
Turtle.speed(0)
Turtle.up()
Turtle.goto(-4 * b, 4 * b)
Turtle.down()
for i in range (8):
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
for i in range (1):
Turtle.right(90)
Turtle.forward(b*2)
Turtle.right(90)
for i in range(8):
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
for i in range(1):
Turtle.left(90)
Turtle.forward(b)
Turtle.left(90)
for i in range (8):
Turtle.forward(b)
Turtle.left(90)
Turtle.forward(b)
Turtle.left(90)
Turtle.forward(b)
Turtle.left(90)
Turtle.forward(b)
Turtle.left(90)
Turtle.forward(b)
for i in range (1):
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
for i in range(8):
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
for i in range(1):
Turtle.left(90)
Turtle.forward(b)
Turtle.left(90)
for i in range (8):
Turtle.forward(b)
Turtle.left(90)
Turtle.forward(b)
Turtle.left(90)
Turtle.forward(b)
Turtle.left(90)
Turtle.forward(b)
Turtle.left(90)
Turtle.forward(b)
for i in range (1):
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
for i in range(8):
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
for i in range(1):
Turtle.left(90)
Turtle.forward(b)
Turtle.left(90)
for i in range (8):
Turtle.forward(b)
Turtle.left(90)
Turtle.forward(b)
Turtle.left(90)
Turtle.forward(b)
Turtle.left(90)
Turtle.forward(b)
Turtle.left(90)
Turtle.forward(b)
for i in range (1):
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
for i in range(8):
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
drawBoard(b)
Turtle.done()
it draws an 8x8 board table.
what i initially wanted to do was to return this function if nothing was
inputted from the user. i hope that makes more sense :S
It makes sense if you're also returning a function object when the user
does have something to say. But I can't see how you might be doing
that, unless you're using a lambda to make up a custom function object.
And you still don't show us the function that contains this input
statement. Nor how it gets used. Is the user supposed to supply a
value for b, and you put it in a variable called filename ?
And perhaps you meant for your function to CALL drawBoard(), rather than
returning the function object drawBoard.
--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is this code correct?
On Thu, May 30, 2013 at 11:05 PM, Mark Lawrence wrote: > Please ask questions unrelated to Python on a list that is unrelated to > Python. Lemme guess, he's next going to ask on the PostgreSQL mailing list. I mean, that's unrelated to Python, right? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this code correct?
Τη Πέμπτη, 30 Μαΐου 2013 4:05:00 μ.μ. UTC+3, ο χρήστης Mark Lawrence έγραψε: > Please ask questions unrelated to Python on a list that is unrelated to > Python. Okey, i will. -- http://mail.python.org/mailman/listinfo/python-list
Re: Can anyone please help me in understanding the following python code
On 05/30/2013 08:42 AM, bhk...@gmail.com wrote: http://wiki.python.org/moin/GoogleGroupsPython > In the above output, the control goes to "HERE AFTER SPLIT" after the "Merging" statement which is of-course the last statement in the function.On what condition this is happening. Ideally as per my understanding, after the last statement of a function the control should come out of the function. Please correct me if I am wrong here. There is something with respect-to functions in python that I am not able to understand. I think you misunderstand recursion. And you should study it in a simpler example before trying to tackle that sort function. After the last statement of a function, or after an explicit return statement, the function does indeed return control to whoever called it. And if the call was in the middle of some other function, that's the place where execution will continue. Functions may nest this way to pretty large depths of complexity. If you're not sure you understand that, we should stop here. So in your reply, tell me if you can readily grasp function dfunc() calling cfunc(), which calls bfunc(), which calls afunc(). When afunc() returns, you'll be right in the middle of bfunc(), right after the call was made. Now to recursion. One can write a function which solves a particular problem by doing some of the work, but by calling on other functions which solve simpler subproblems. Recursion comes in when those other functions are simply instances of the same one. So instead of dfunc() calling cfunc(), we have rfunc() calling rfunc() calling rfunc() calling rfunc(). Let's take a classic problem for explaining recursion: factorial. We can write a simple function that solves the problem for 0: def afunc(n): if n == 0: return 1 else: throw-some-exception Silly function, I know. Now let's write one that solves it for one. def bfunc(n): if n == 1: return 1 * afunc(n-1) else: throw-some-exception Now for two: def bfunc(n): if n == 2: return 2 * bfunc(n-1) else: throw-some-exception Notice that each function calls the one above it to solve the "simpler" problem. Now if we wanted this to work for n=100, it would get really tedious. So let's see if we can write one function that handles all of these cases. def rfunc(n): if n == 0: return 1 else: return n * rfunc(n-1) Now if we call this with n==3, it'll make the zero check, then it'll call another function with the value 2. that one will in turn call another function with the value 1. And so on. So this function calls itself, as we say recursively. Now, for this simple case, we could have used a simple loop, or just called the library function. But it's a simple enough example to follow in its entirety (if I've been clear in my writing). Your mergeSort() function calls itself recursively, and each time it does, it passes a *smaller* list to be sorted. Eventually the calls recurse down to a list of size 1, which is already sorted by definition. The check for that is the line if len(alist)>1: near the beginning of the function. That's analogous to my if n==0 line, although to match it most directly, I could have reversed the if/else and written the test as if n!=0 Chris showed you how to change your output so you could see the nesting levels. I have done that sort of thing in the past, and found it very useful. But first you have to understand nested functions, and simple recursion. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this code correct?
On 30/05/2013 13:31, Νίκος Γκρ33κ wrote: This is my last question, everythign else is taken care of. i cant test thjis coe online because i receive this [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] suexec failure: could not open log file [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] fopen: Permission denied [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] Premature end of script headers: koukos.py [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] File does not exist: /home/nikos/public_html/500.shtml when i tail -F /usr/local/apache/logs/error_log & maybe it is correct but it wont run, perhaps somethign with linux? Please ask questions unrelated to Python on a list that is unrelated to Python. -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this code correct?
Τη Πέμπτη, 30 Μαΐου 2013 3:59:21 μ.μ. UTC+3, ο χρήστης Chris Angelico έγραψε: > On Thu, May 30, 2013 at 10:31 PM, Νίκος Γκρ33κ wrote: > > > This is my last question, everythign else is taken care of. > > > > > > i cant test thjis coe online because i receive this > > > > > > [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] suexec failure: > > could not open log file > > > [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] fopen: Permission > > denied > > > [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] Premature end of > > script headers: koukos.py > > > [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] File does not > > exist: /home/nikos/public_html/500.shtml > > > > > > when i tail -F /usr/local/apache/logs/error_log & > > > > > > maybe it is correct but it wont run, perhaps somethign with linux? > > > > I don't know, why not ask on a Linux mailing list? Or have you run > > them out of patience too? > > > > ChrisA I though you guys might know because you "do" linux as well. i tried chown "nikos:nikos ./koukos.py" but doenst do the job either. -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
On Thu, May 30, 2013 at 10:37 PM, Eternaltheft wrote: > sorry about that, i got confused xD. yeah it works good now. > what i meant to say was can i return a function that i made, if the user > inputs nothing? Sure! Anything you want to do, you can do :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
yeah i found out why it wasn't defined before because i tried to put it into a
function.
this is my drawBoard function:
import turtle as Turtle
Turtle.title("Checkers")
b = 75
def drawBoard(b):
Turtle.speed(0)
Turtle.up()
Turtle.goto(-4 * b, 4 * b)
Turtle.down()
for i in range (8):
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
for i in range (1):
Turtle.right(90)
Turtle.forward(b*2)
Turtle.right(90)
for i in range(8):
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
for i in range(1):
Turtle.left(90)
Turtle.forward(b)
Turtle.left(90)
for i in range (8):
Turtle.forward(b)
Turtle.left(90)
Turtle.forward(b)
Turtle.left(90)
Turtle.forward(b)
Turtle.left(90)
Turtle.forward(b)
Turtle.left(90)
Turtle.forward(b)
for i in range (1):
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
for i in range(8):
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
for i in range(1):
Turtle.left(90)
Turtle.forward(b)
Turtle.left(90)
for i in range (8):
Turtle.forward(b)
Turtle.left(90)
Turtle.forward(b)
Turtle.left(90)
Turtle.forward(b)
Turtle.left(90)
Turtle.forward(b)
Turtle.left(90)
Turtle.forward(b)
for i in range (1):
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
for i in range(8):
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
for i in range(1):
Turtle.left(90)
Turtle.forward(b)
Turtle.left(90)
for i in range (8):
Turtle.forward(b)
Turtle.left(90)
Turtle.forward(b)
Turtle.left(90)
Turtle.forward(b)
Turtle.left(90)
Turtle.forward(b)
Turtle.left(90)
Turtle.forward(b)
for i in range (1):
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
for i in range(8):
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
Turtle.right(90)
Turtle.forward(b)
drawBoard(b)
Turtle.done()
it draws an 8x8 board table.
what i initially wanted to do was to return this function if nothing was
inputted from the user. i hope that makes more sense :S
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is this code correct?
On Thu, May 30, 2013 at 10:31 PM, Νίκος Γκρ33κ wrote: > This is my last question, everythign else is taken care of. > > i cant test thjis coe online because i receive this > > [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] suexec failure: could > not open log file > [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] fopen: Permission > denied > [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] Premature end of > script headers: koukos.py > [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] File does not exist: > /home/nikos/public_html/500.shtml > > when i tail -F /usr/local/apache/logs/error_log & > > maybe it is correct but it wont run, perhaps somethign with linux? I don't know, why not ask on a Linux mailing list? Or have you run them out of patience too? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Can anyone please help me in understanding the following python code
Thanks Chris, Wolfgang and Joshua for your replies. In step 2b, all the steps from 1 through 3 are executed again (twice). Soon, those calls will just output "Splitting" followed by "Merging"; and then we go back to 2c. That's why it *seems* that the code goes from 3 to 2c. You'll notice that the call depth decreases when this happens Chris, Can you please let me know what makes the control of the program code go to 2c after the output "Merging". Also, please look into the following output for the same program with more print statements, -- before calling main mergesort Splitting [54, 26, 93, 17, 77, 31, 44, 55, 20] left half before split [54, 26, 93, 17] right half before split [77, 31, 44, 55, 20] Splitting [54, 26, 93, 17] left half before split [54, 26] right half before split [93, 17] Splitting [54, 26] left half before split [54] right half before split [26] Splitting [54] Merging [54] Splitting [26] Merging [26] HERE AFTER SPLIT left half after split [54] right half after split [26] Merging [26, 54] Splitting [93, 17] left half before split [93] right half before split [17] Splitting [93] Merging [93] Splitting [17] Merging [17] HERE AFTER SPLIT left half after split [93] right half after split [17] Merging [17, 93] HERE AFTER SPLIT left half after split [26, 54] right half after split [17, 93] Merging [17, 26, 54, 93] Splitting [77, 31, 44, 55, 20] left half before split [77, 31] right half before split [44, 55, 20] Splitting [77, 31] left half before split [77] right half before split [31] Splitting [77] Merging [77] Splitting [31] Merging [31] HERE AFTER SPLIT left half after split [77] right half after split [31] Merging [31, 77] Splitting [44, 55, 20] ft half before split [44] ght half before split [55, 20] Splitting [44] Merging [44] Splitting [55, 20] eft half before split [55] ight half before split [20] Splitting [55] Merging [55] Splitting [20] Merging [20] HERE AFTER SPLIT left half after split [55] right half after split [20] Merging [20, 55] HERE AFTER SPLIT left half after split [44] right half after split [20, 55] Merging [20, 44, 55] HERE AFTER SPLIT left half after split [31, 77] right half after split [20, 44, 55] Merging [20, 31, 44, 55, 77] HERE AFTER SPLIT left half after split [17, 26, 54, 93] right half after split [20, 31, 44, 55, 77] Merging [17, 20, 26, 31, 44, 54, 55, 77, 93] after calling main mergesort [17, 20, 26, 31, 44, 54, 55, 77, 93] --- In the above output, the control goes to "HERE AFTER SPLIT" after the "Merging" statement which is of-course the last statement in the function.On what condition this is happening. Ideally as per my understanding, after the last statement of a function the control should come out of the function. Please correct me if I am wrong here. There is something with respect-to functions in python that I am not able to understand. -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
On 05/30/2013 08:37 AM, Eternaltheft wrote:
sorry about that, i got confused xD. yeah it works good now.
what i meant to say was can i return a function that i made, if the user inputs
nothing?
There wouldn't be anything to stop you. However, if you have multiple
returns from the same function, it's usually wise to return the same
type of information from each of them. That's why Chris suggested
simply assigning to filename in the if clause.
But without the whole function, and maybe even a description of what the
function is expected to do, we can only guess.
Your comments still make no sense to me,
> filename = input('file name: ')
> if not filename: #i get filename is not defined
But filename IS defined, immediately above. If it were undefined, you'd
not be able to test it here. Big difference between "not defined" and
"is empty string".
>return(drawBoard) #possible to return function when no file input
from user?
If drawBoard is a function object, it's certainly possible to return it.
But again, without seeing the rest of the function, and maybe how it's
intended to be used, I can't confirm whether it makes sense.
--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Thu, May 30, 2013 at 10:40 PM, Roy Smith wrote: > if somebody were to accidentally drop three zeros into the source code: > >> x = 1000 >> while x < 173: >> print(x) >> x += 1 > > should the loop just quietly not execute (which is what it will do > here)? Will that make your program correct again, or will it simply > turn this into a difficult to find bug? If you're really worried about > that, why not: If you iterate from 1000 to 173, you get nowhere. This is the expected behaviour; this is what a C-style for loop would be written as, it's what range() does, it's the normal thing. Going from a particular starting point to a particular ending point that's earlier than the start results in no iterations. The alternative would be an infinite number of iterations, which is far far worse. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Can anyone please help me in understanding the following python code
On Thu, May 30, 2013 at 10:39 PM, wrote: > Chris, Can you please let me know what makes the control of the program code > go to 2c after the output "Merging". It goes like this: 1. [eight element list] 2a. [eight element list] 2b. 1. [four element list] 2b. 2a. [four element list] 2b. 2b.1. [two element list] 2b. 2b.2a. [two element list] 2b. 2b.2b. [two element list] 2b. 2b.2b.1. [one element list] 2b. 2b.2b.2. [one element list] 2b. 2b.2b.3. [one element list] 2b. 2b.2c. [two element list] 2b. 2b.3. [two element list] ... etc etc etc ... Notice how control actually flows from 1, to 2a, to 2b, to 2c, but in between, it goes back to 1? That's recursion. There are four separate function calls here, which you can see going down the page. Each time it gets to step 2b, a whole new "thread" starts, and the previous one doesn't do anything till the inner one reaches step 3 and finishes. That's why the indented output can help; eyeball them going down and you'll see that they don't do anything until the inner one finishes. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this code correct?
Τη Πέμπτη, 30 Μαΐου 2013 3:34:09 μ.μ. UTC+3, ο χρήστης Chris Angelico έγραψε: > On Thu, May 30, 2013 at 10:25 PM, Νίκος Γκρ33κ wrote: > > > #!/usr/bin/python3 > > > # coding=utf-8 > > > (chomp a whole lot of code without any indication of what it ought to do) > > > > Why not run it and see? If it does what it ought to, it's correct; if > > it does something different, it's not. Why do you expect us to do your > > basic testing for you? > > > > ChrisA But i cannot test it locally, i just write the code upload it on my remote server and run it from there. But h=this doenst seem to be a python issue, if it is ill correct it myself, it says somehtign about some suexec -- http://mail.python.org/mailman/listinfo/python-list
Re: Can anyone please help me in understanding the following python code
On Thursday, May 30, 2013 6:09:20 PM UTC+5:30, bhk...@gmail.com wrote: > Thanks Chris, Wolfgang and Joshua for your replies. > > > > --- > > In step 2b, all the steps from 1 through 3 are executed again (twice). > > Soon, those calls will just output "Splitting" followed by "Merging"; > > and then we go back to 2c. That's why it *seems* that the code goes > > from 3 to 2c. You'll notice that the call depth decreases when this > > happens > > > > Chris, Can you please let me know what makes the control of the program code > go to 2c after the output "Merging". > > Also, please look into the following output for the same program with more > print statements, > -- > before calling main mergesort > > Splitting [54, 26, 93, 17, 77, 31, 44, 55, 20] > > left half before split [54, 26, 93, 17] > > right half before split [77, 31, 44, 55, 20] > > Splitting [54, 26, 93, 17] > > left half before split [54, 26] > > right half before split [93, 17] > > Splitting [54, 26] > > left half before split [54] > > right half before split [26] > > Splitting [54] > > Merging [54] > > Splitting [26] > > Merging [26] > > > > HERE AFTER SPLIT > > > > left half after split [54] > > right half after split [26] > > Merging [26, 54] > > Splitting [93, 17] > > left half before split [93] > > right half before split [17] > > Splitting [93] > > Merging [93] > > Splitting [17] > > Merging [17] > > > > HERE AFTER SPLIT > > > > left half after split [93] > > right half after split [17] > > Merging [17, 93] > > > > HERE AFTER SPLIT > > > > left half after split [26, 54] > > right half after split [17, 93] > > Merging [17, 26, 54, 93] > > Splitting [77, 31, 44, 55, 20] > > left half before split [77, 31] > > right half before split [44, 55, 20] > > Splitting [77, 31] > > left half before split [77] > > right half before split [31] > > Splitting [77] > > Merging [77] > > Splitting [31] > > Merging [31] > > > > HERE AFTER SPLIT > > > > left half after split [77] > > right half after split [31] > > Merging [31, 77] > > Splitting [44, 55, 20] > > left half before split [44] > > right half before split [55, 20] > > Splitting [44] > > Merging [44] > > Splitting [55, 20] > > left half before split [55] > > right half before split [20] > > Splitting [55] > > Merging [55] > > Splitting [20] > > Merging [20] > > > > HERE AFTER SPLIT > > > > left half after split [55] > > right half after split [20] > > Merging [20, 55] > > > > HERE AFTER SPLIT > > > > left half after split [44] > > right half after split [20, 55] > > Merging [20, 44, 55] > > > > HERE AFTER SPLIT > > > > left half after split [31, 77] > > right half after split [20, 44, 55] > > Merging [20, 31, 44, 55, 77] > > > > HERE AFTER SPLIT > > > > left half after split [17, 26, 54, 93] > > right half after split [20, 31, 44, 55, 77] > > Merging [17, 20, 26, 31, 44, 54, 55, 77, 93] > > > > after calling main mergesort > > > > [17, 20, 26, 31, 44, 54, 55, 77, 93] > > --- > > In the above output, the control goes to "HERE AFTER SPLIT" after the > "Merging" statement which is of-course the last statement in the function.On > what condition this is happening. > > Ideally as per my understanding, after the last statement of a function the > control should come out of the function. > > Please correct me if I am wrong here. > > There is something with respect-to functions in python that I am not able to > understand. -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
In article , Jussi Piitulainen wrote: > I wonder why floating-point errors are not routinely discussed in > terms of ulps (units in last position). Analysis of error is a complicated topic (and is much older than digital computers). These sorts of things come up in the real world, too. For example, let's say I have two stakes driven into the ground 1000 feet apart. One of them is near me and is my measurement datum. I want to drive a third stake which is 1001 feet away from the datum. Do I measure 1 foot from the second stake, or do I take out my super-long tape measure and measure 1001 feet from the datum? -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
In article , Chris Angelico wrote: > On Thu, May 30, 2013 at 3:10 PM, Steven D'Aprano > wrote: > > # Wrong, don't do this! > > x = 0.1 > > while x != 17.3: > > print(x) > > x += 0.1 > > > > Actually, I wouldn't do that with integers either. There are too many > ways that a subsequent edit could get it wrong and go infinite, so I'd > *always* use an inequality for that: > > x = 1 > while x < 173: > print(x) > x += 1 There's a big difference between these two. In the first case, using less-than instead of testing for equality, you are protecting against known and expected floating point behavior. In the second case, you're protecting against some vague, unknown, speculative future programming botch. So, what *is* the right behavior if somebody were to accidentally drop three zeros into the source code: > x = 1000 > while x < 173: > print(x) > x += 1 should the loop just quietly not execute (which is what it will do here)? Will that make your program correct again, or will it simply turn this into a difficult to find bug? If you're really worried about that, why not: > x = 1 > while x != 173: > assert < 172 > print(x) > x += 1 -- http://mail.python.org/mailman/listinfo/python-list
Re: Can anyone please help me in understanding the following python code
On Thursday, May 30, 2013 6:09:20 PM UTC+5:30, bhk...@gmail.com wrote: > Thanks Chris, Wolfgang and Joshua for your replies. > > > > --- > > In step 2b, all the steps from 1 through 3 are executed again (twice). > > Soon, those calls will just output "Splitting" followed by "Merging"; > > and then we go back to 2c. That's why it *seems* that the code goes > > from 3 to 2c. You'll notice that the call depth decreases when this > > happens > > > > Chris, Can you please let me know what makes the control of the program code > go to 2c after the output "Merging". > > Also, please look into the following output for the same program with more > print statements, > -- > before calling main mergesort > > Splitting [54, 26, 93, 17, 77, 31, 44, 55, 20] > > left half before split [54, 26, 93, 17] > > right half before split [77, 31, 44, 55, 20] > > Splitting [54, 26, 93, 17] > > left half before split [54, 26] > > right half before split [93, 17] > > Splitting [54, 26] > > left half before split [54] > > right half before split [26] > > Splitting [54] > > Merging [54] > > Splitting [26] > > Merging [26] > > > > HERE AFTER SPLIT > > > > left half after split [54] > > right half after split [26] > > Merging [26, 54] > > Splitting [93, 17] > > left half before split [93] > > right half before split [17] > > Splitting [93] > > Merging [93] > > Splitting [17] > > Merging [17] > > > > HERE AFTER SPLIT > > > > left half after split [93] > > right half after split [17] > > Merging [17, 93] > > > > HERE AFTER SPLIT > > > > left half after split [26, 54] > > right half after split [17, 93] > > Merging [17, 26, 54, 93] > > Splitting [77, 31, 44, 55, 20] > > left half before split [77, 31] > > right half before split [44, 55, 20] > > Splitting [77, 31] > > left half before split [77] > > right half before split [31] > > Splitting [77] > > Merging [77] > > Splitting [31] > > Merging [31] > > > > HERE AFTER SPLIT > > > > left half after split [77] > > right half after split [31] > > Merging [31, 77] > > Splitting [44, 55, 20] > > left half before split [44] > > right half before split [55, 20] > > Splitting [44] > > Merging [44] > > Splitting [55, 20] > > left half before split [55] > > right half before split [20] > > Splitting [55] > > Merging [55] > > Splitting [20] > > Merging [20] > > > > HERE AFTER SPLIT > > > > left half after split [55] > > right half after split [20] > > Merging [20, 55] > > > > HERE AFTER SPLIT > > > > left half after split [44] > > right half after split [20, 55] > > Merging [20, 44, 55] > > > > HERE AFTER SPLIT > > > > left half after split [31, 77] > > right half after split [20, 44, 55] > > Merging [20, 31, 44, 55, 77] > > > > HERE AFTER SPLIT > > > > left half after split [17, 26, 54, 93] > > right half after split [20, 31, 44, 55, 77] > > Merging [17, 20, 26, 31, 44, 54, 55, 77, 93] > > > > after calling main mergesort > > > > [17, 20, 26, 31, 44, 54, 55, 77, 93] > > --- > > In the above output, the control goes to "HERE AFTER SPLIT" after the > "Merging" statement which is of-course the last statement in the function.On > what condition this is happening. > > Ideally as per my understanding, after the last statement of a function the > control should come out of the function. > > Please correct me if I am wrong here. > > There is something with respect-to functions in python that I am not able to > understand. -- http://mail.python.org/mailman/listinfo/python-list
Re: Can anyone please help me in understanding the following python code
Thanks Chris, Wolfgang and Joshua for your replies. --- In step 2b, all the steps from 1 through 3 are executed again (twice). Soon, those calls will just output "Splitting" followed by "Merging"; and then we go back to 2c. That's why it *seems* that the code goes from 3 to 2c. You'll notice that the call depth decreases when this happens Chris, Can you please let me know what makes the control of the program code go to 2c after the output "Merging". Also, please look into the following output, before calling main mergesort Splitting [54, 26, 93, 17, 77, 31, 44, 55, 20] left half before split [54, 26, 93, 17] right half before split [77, 31, 44, 55, 20] Splitting [54, 26, 93, 17] left half before split [54, 26] right half before split [93, 17] Splitting [54, 26] left half before split [54] right half before split [26] Splitting [54] Merging [54] Splitting [26] Merging [26] HERE AFTER SPLIT left half after split [54] right half after split [26] Merging [26, 54] Splitting [93, 17] left half before split [93] right half before split [17] Splitting [93] Merging [93] Splitting [17] Merging [17] HERE AFTER SPLIT left half after split [93] right half after split [17] Merging [17, 93] HERE AFTER SPLIT left half after split [26, 54] right half after split [17, 93] Merging [17, 26, 54, 93] Splitting [77, 31, 44, 55, 20] left half before split [77, 31] right half before split [44, 55, 20] Splitting [77, 31] left half before split [77] right half before split [31] Splitting [77] Merging [77] Splitting [31] Merging [31] HERE AFTER SPLIT left half after split [77] right half after split [31] Merging [31, 77] Splitting [44, 55, 20] left half before split [44] right half before split [55, 20] Splitting [44] Merging [44] Splitting [55, 20] left half before split [55] right half before split [20] Splitting [55] Merging [55] Splitting [20] Merging [20] HERE AFTER SPLIT left half after split [55] right half after split [20] Merging [20, 55] HERE AFTER SPLIT left half after split [44] right half after split [20, 55] Merging [20, 44, 55] HERE AFTER SPLIT left half after split [31, 77] right half after split [20, 44, 55] Merging [20, 31, 44, 55, 77] HERE AFTER SPLIT left half after split [17, 26, 54, 93] right half after split [20, 31, 44, 55, 77] Merging [17, 20, 26, 31, 44, 54, 55, 77, 93] after calling main mergesort [17, 20, 26, 31, 44, 54, 55, 77, 93] - In the above output, the control goes to "HERE AFTER SPLIT" after the "Merging" statement which is of-course the last statement in the function.On what condition this is happening. Ideally as per my understanding, after the last statement of a function the control should come out of the function. Please correct me if I am wrong here. There is something with respect-to functions in python that I am not able to understand. -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
sorry about that, i got confused xD. yeah it works good now. what i meant to say was can i return a function that i made, if the user inputs nothing? -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this code correct?
This is my last question, everythign else is taken care of. i cant test thjis coe online because i receive this [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] suexec failure: could not open log file [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] fopen: Permission denied [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] Premature end of script headers: koukos.py [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] File does not exist: /home/nikos/public_html/500.shtml when i tail -F /usr/local/apache/logs/error_log & maybe it is correct but it wont run, perhaps somethign with linux? -- http://mail.python.org/mailman/listinfo/python-list
