Re: Assignment Versus Equality
On Wed, Jun 29, 2016 at 4:45 PM, Steven D'Aprano wrote: > On Wednesday 29 June 2016 15:51, Lawrence D’Oliveiro wrote: > >> On Wednesday, June 29, 2016 at 5:26:46 PM UTC+12, Steven D'Aprano wrote: >>> BUT in Python 3, the distinction between int and long is gone by dropping >>> int and renaming long as "int". So all Python ints are BIGNUMs. >> >> I don’t understand what the problem is with this. Is there supposed to be >> some issue with performance? Because I can’t see it. > > If there is a performance hit, it's probably pretty small. It may have been > bigger back in Python 3.0 or 3.1. > > [steve@ando ~]$ python2.7 -m timeit -s "n = 0" "for i in xrange(1): n += > i" > 100 loops, best of 3: 1.87 msec per loop > > [steve@ando ~]$ python3.3 -m timeit -s "n = 0" "for i in range(1): n += i" > 1000 loops, best of 3: 1.89 msec per loop > > > Although setting debugging options does make it pretty slow: > > [steve@ando ~]$ python/python-dev/3.6/python -m timeit -s "n = 0" "for i in > range(1): n += i" > 100 loops, best of 3: 13.7 msec per loop That's not necessarily fair - you're comparing two quite different Python interpreters, so there might be something entirely different that counteracts the integer performance. (For example: You're creating and disposing of large numbers of objects, so the performance of object creation could affect things hugely.) To make it somewhat fairer, add long integer performance to the mix. Starting by redoing your test: rosuav@sikorsky:~$ python2.7 -m timeit -s "n = 0" "for i in xrange(1): n += i" 1 loops, best of 3: 192 usec per loop rosuav@sikorsky:~$ python2.7 -m timeit -s "n = 1<<100" "for i in xrange(1): n += i" 1000 loops, best of 3: 478 usec per loop rosuav@sikorsky:~$ python3.4 -m timeit -s "n = 0" "for i in range(1): n += i" 1000 loops, best of 3: 328 usec per loop rosuav@sikorsky:~$ python3.4 -m timeit -s "n = 1<<100" "for i in range(1): n += i" 1000 loops, best of 3: 337 usec per loop rosuav@sikorsky:~$ python3.5 -m timeit -s "n = 0" "for i in range(1): n += i" 1000 loops, best of 3: 369 usec per loop rosuav@sikorsky:~$ python3.5 -m timeit -s "n = 1<<100" "for i in range(1): n += i" 1000 loops, best of 3: 356 usec per loop rosuav@sikorsky:~$ python3.6 -m timeit -s "n = 0" "for i in range(1): n += i" 1000 loops, best of 3: 339 usec per loop rosuav@sikorsky:~$ python3.6 -m timeit -s "n = 1<<100" "for i in range(1): n += i" 1000 loops, best of 3: 343 usec per loop (On this system, python3.4 and python3.5 are Debian-shipped builds of CPython, and python3.6 is one I compiled from hg today. There's no visible variance between them, but just in case. I don't have a python3.3 on here for a fair comparison with your numbers, sorry.) The way I read this, Python 2.7 is noticeably slower with bignums, but visibly faster with machine words. Python 3, on the other hand, has consistent performance whether the numbers fit within a machine word or not - which is to be expected, since it uses bignums for all integers. PyPy's performance shows an even more dramatic gap: rosuav@sikorsky:~$ pypy -m timeit -s "n = 0" "for i in xrange(1): n += i" 10 loops, best of 3: 7.59 usec per loop rosuav@sikorsky:~$ pypy -m timeit -s "n = 1<<100" "for i in xrange(1): n += i" 1 loops, best of 3: 119 usec per loop rosuav@sikorsky:~$ pypy --version Python 2.7.10 (5.1.2+dfsg-1, May 17 2016, 18:03:30) [PyPy 5.1.2 with GCC 5.3.1 20160509] Sadly, Debian doesn't ship a pypy3 yet, so for consistency, I picked up the latest available pypy2 and pypy3 from pypy.org. rosuav@sikorsky:~/tmp$ pypy2-v5.3.1-linux64/bin/pypy -m timeit -s "n = 0" "for i in xrange(1): n += i" 10 loops, best of 3: 7.58 usec per loop rosuav@sikorsky:~/tmp$ pypy2-v5.3.1-linux64/bin/pypy -m timeit -s "n = 1<<100" "for i in xrange(1): n += i" 1 loops, best of 3: 115 usec per loop rosuav@sikorsky:~/tmp$ pypy3.3-v5.2.0-alpha1-linux64/bin/pypy3 -m timeit -s "n = 0" "for i in range(1): n += i" 10 loops, best of 3: 7.56 usec per loop rosuav@sikorsky:~/tmp$ pypy3.3-v5.2.0-alpha1-linux64/bin/pypy3 -m timeit -s "n = 1<<100" "for i in range(1): n += i" 1 loops, best of 3: 115 usec per loop Performance comparable to each other (and to the Debian-shipped one, which is nice - as Adam Savage said, I love consistent data!), and drastically different between machine words and bignums. So it looks like PyPy *does* have some sort of optimization going on here, without ever violating the language spec. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Assignment Versus Equality
On Wednesday, June 29, 2016 at 6:46:04 PM UTC+12, Steven D'Aprano wrote: > On Wednesday 29 June 2016 15:51, Lawrence D’Oliveiro wrote: > >> On Wednesday, June 29, 2016 at 5:26:46 PM UTC+12, Steven D'Aprano wrote: >>> BUT in Python 3, the distinction between int and long is gone by dropping >>> int and renaming long as "int". So all Python ints are BIGNUMs. >> >> I don’t understand what the problem is with this. Is there supposed to be >> some issue with performance? Because I can’t see it. > > If there is a performance hit, it's probably pretty small. It may have been > bigger back in Python 3.0 or 3.1. > > [steve@ando ~]$ python2.7 -m timeit -s "n = 0" "for i in xrange(1): n += > i" > 100 loops, best of 3: 1.87 msec per loop > > [steve@ando ~]$ python3.3 -m timeit -s "n = 0" "for i in range(1): n += i" > 1000 loops, best of 3: 1.89 msec per loop Here is what I tried: ldo@theon:python_try> python2 int_speed_test.py 2 ** 6 is 2 ** 6: True 100 iterations of “a = 2 ** 6 // 2 ** 4” took 0.0624719s = 6.24719e-08s/iteration 2 ** 9 is 2 ** 9: False 100 iterations of “a = 2 ** 9 // 2 ** 6” took 0.0506701s = 5.06701e-08s/iteration 2 ** 20 is 2 ** 20: False 100 iterations of “a = 2 ** 20 // 2 ** 12” took 0.0441589s = 4.41589e-08s/iteration 2 ** 64 is 2 ** 64: False 100 iterations of “a = 2 ** 64 // 2 ** 32” took 0.138092s = 1.38092e-07s/iteration 2 ** 96 is 2 ** 96: False 100 iterations of “a = 2 ** 96 // 2 ** 64” took 0.1142s = 1.142e-07s/iteration ldo@theon:python_try> python3 int_speed_test.py 2 ** 6 is 2 ** 6: True 100 iterations of “a = 2 ** 6 // 2 ** 4” took 0.0230309s = 2.30309e-08s/iteration 2 ** 9 is 2 ** 9: False 100 iterations of “a = 2 ** 9 // 2 ** 6” took 0.0231234s = 2.31234e-08s/iteration 2 ** 20 is 2 ** 20: False 100 iterations of “a = 2 ** 20 // 2 ** 12” took 0.020053s = 2.0053e-08s/iteration 2 ** 64 is 2 ** 64: False 100 iterations of “a = 2 ** 64 // 2 ** 32” took 0.0182259s = 1.82259e-08s/iteration 2 ** 96 is 2 ** 96: False 100 iterations of “a = 2 ** 96 // 2 ** 64” took 0.0173797s = 1.73797e-08s/iteration As you can see, Python 3 is actually *faster* than Python 2, particularly with smaller-magnitude integers. -- https://mail.python.org/mailman/listinfo/python-list
I need a pure python module from PyPI without additional packages on my OS.
I heard about cairo, but it required installed on my computer before. -- https://mail.python.org/mailman/listinfo/python-list
Re: Can math.atan2 return INF?
On Sunday 26 June 2016 09:40, Gregory Ewing wrote:
> Marko Rauhamaa wrote:
>> pdora...@pas-de-pub-merci.mac.com (Pierre-Alain Dorange):
>>
>>>Near a black hole 3.7 seconds can last an infinite time...
>>
>> Which phenomenon prevents a black hole from ever forming. Yet
>> astronomers keep telling us they are all over the place.
>
> Astronomers have observed objects whose behaviour is
> entirely consistent with the existence of black holes
> as predicted by general relativity.
Indeed.
There's a common myth going around that black holes take an infinite amount of
time to form, or another way of putting it is that it takes an infinite amount
of time for something to fall into a black hole, and therefore "black holes
can't really exist". This myth comes about because people don't fully
understand the (admittedly mind-boggling) implications of General Relativity.
First, you must accept that *your* experiences are not the only valid
experiences. Just because *you* never see the black hole form, doesn't mean it
doesn't form. You just don't get to experience it yourself.
So, let's consider a thought experiment. Imagine three astronauts, Tim, Bill
and Graham ("we do anything, anytime"). Tim and Graham are in separate space
ships, dropping straight towards a black hole under free fall. Bill is watching
them from a safely orbiting space station.
Graham drops towards the black hole, as does Tim. Neither can see the black
hole directly, or at least they can't see the *inside* of the black hole, since
no light can escape it, but they can see it by its effect on the starlight: the
black hole acts like a great big lens, bending light. If they line up their
space ships with the black hole directly between them and a distant star, they
will see one of the more amazing sights of the universe: gravitational lensing.
The (somewhat reddened) light from the star will be bent around the black hole,
so that the star will appear to be a donut of light with a black centre.
As Graham falls, he pays close attention to the distance from his ship to the
black hole. That's easy to do: he can tell how fast he is going thanks to
Bill's space station, which transmits a steady radio signal for him, a steady
clock sending one pulse per second.[1]
But as Graham gets closer and closer to the event horizon, he notices Bill's
radio signals have a higher and higher frequency, and appear to be sped up...
at the end, just before he loses his nerve and fires the retro-rockets before
crossing the event horizon, the signals are coming thousands of pulses per
second.
When Graham returns to the space station, he finds a *much* older Bill waiting
for him. Bill insists he was sending one pulse per second, as agreed, but that
Graham has been gone for many years. Graham insists that he has only been gone
a few days, and Bill has obviously been partying very hard indeed to look like
this after such a short time. But after sitting down with Albert Einstein's
head[2], they reconcile their two differing experiences:
As seen by Bill, in Bill's frame of reference far from the black hole, Graham's
experiences have been slowed down enormously. But Graham sees things
differently: he experiences his own frame of reference at the same speed he
always has, and see's *Bill's* frame of reference as being immensely sped up.
Neither is "right" and the other is "wrong", neither frame of reference is
privileged over the other. BOTH are right, even though they contradict each
other. That's the nature of the universe we live in.
What about Tim?
Tim is so engrossed by the view of the gravitational lensing that he forgets to
fire the retro-rockets, and before he knows it, he's crossed the event horizon
and there's no going back.
For a sufficiently large black hole, he might not even have noticed the
transition. From his perspective, he's still distant from the singularity
(being so small and distant, he can't quite make out what it looks like), and
space-time is still quite flat for a sufficiently large black hole. Tim can
still see out, although the incoming light is getting bluer, and he's still
receiving Bill's clock signals, though like Graham he sees them as drastically
sped up.
If Tim has sufficiently powerful rockets with enough fuel, he could *not quite*
escape: he could change his space ship's trajectory enough to avoid the
hypothetical singularity for days, weeks, years, as long as the fuel lasts. But
nothing he can do will allow him to escape the event horizon. (Well, maybe
faster-than-light travel, if his hyperdrive will still work this close to a
black hole.)
And as invariably as tomorrow follows today, he's getting closer to the
supposed singularity, and long before he reaches it, both Tim and his space
ship will be torn apart into atoms by the ever-increasing tidal forces, and
then even the atoms torn apart. And then, well we really have no idea what
happens if you try to squeeze an electron into a
Re: Assignment Versus Equality
On 29/06/2016 06:26, Steven D'Aprano wrote: BUT in Python 3, the distinction between int and long is gone by dropping int and renaming long as "int". So all Python ints are BIGNUMs. In principle Python might use native 32 or 64 bit ints for small values and secretly promote them to BIGNUMs when needed, but as far as I know no implementation of Python currently does this. Presumably the implementation of BIGNUMs would already do something like this: a number that fits into 64 bits would only use 64 bits. The overheads of dealing with both small BIGNUMs and big ones, or a mix, might be lost in the other overheads of CPython. But I remember when playing with my tokeniser benchmarks earlier this year that switching from dealing with strings, to integers, didn't make things much faster (I think they actually made it slower sometimes). Even if Python has extremely efficient string handling, we know that low-level string ops normally take longer than low-level integer ops. So maybe small-integer handling already had enough overhead that implementing them as small BIGNUMs didn't make much difference, but it simplified the language. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Assignment Versus Equality
On Wednesday, June 29, 2016 at 9:49:23 PM UTC+12, BartC wrote: > Even if Python has extremely efficient string handling, we know that > low-level string ops normally take longer than low-level integer ops. Maybe part of the general principle that, on modern machines, memory is cheap, but accessing memory is expensive? -- https://mail.python.org/mailman/listinfo/python-list
Re: "for/while ... break(by any means) ... else" make sense?
There are many posts trying to explain the else after for or while. Here is my take on it: There are three ways of getting out of a (for/while) loop: throw, break or the iterator gets exhausted. The question is, how cab we tell which way we exited? For the throw, we have the except clause. This leaves us to differentiatr between break and normal exhaustion of the iterator. This is that the else clause is for: we enter the body iff the loop iterator was exhausted. A lot of discussion goes around the actual keyword used: else. Opinions may differ, but I for one would have chosen 'then' as a keyword to mark something that naturally happens as part of the for statement but after the looping is over; assuming break jumps out of the entire statement, it makes sense that it skips the 'then' body as well. (In the same way, I prefer 'catch' to 'except' as a correspondent to 'throw', but all of this is just bikeshedding). At a language design level, the decision was made to reuse one of the existing keywords and for better or worse, 'else' was chosen, which can be thought of as having no relation to the other use of the same keyword in the 'if' statement. The only rationale behind this was to save one keyword. The search analogy often used for justifying 'else' is (to me) totally bogus, since the same argument can be used to support replacing the keyword 'for' by the keyword 'find' and have looping only as a side-effect of a search. I hope this gives you some sense of closure. Best, VS -- https://mail.python.org/mailman/listinfo/python-list
Re: Assignment Versus Equality
On 29/06/2016 10:56, Lawrence D’Oliveiro wrote:
On Wednesday, June 29, 2016 at 9:49:23 PM UTC+12, BartC wrote:
Even if Python has extremely efficient string handling, we know that
low-level string ops normally take longer than low-level integer ops.
Maybe part of the general principle that, on modern machines, memory is cheap,
but accessing memory is expensive?
No, it's just fewer instructions. If you do the equivalent of a==b where
both are integers, it might be a couple of instructions in native code.
If both are strings, even of one character each (say the code is
choosing to compare "A" with "B" instead of ord("A") with ord("B"), then
it's a /lot/ more than two instructions.
(With Python there's the side-issue of actually getting the integer
values. Having to call ord() doesn't help the case for using integers.)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Operator Precedence/Boolean Logic
Moved from thread "Assignment Versus Equality" where this is less relevant
On Wednesday, June 29, 2016 at 8:06:10 AM UTC+5:30, Steven D'Aprano wrote:
> On Tue, 28 Jun 2016 12:10 am, Rustom Mody wrote:
>
> > Analogy: Python's bool as 1½-class because bool came into python a good
> > decade after python and breaking old code is a bigger issue than fixing
> > control constructs to be bool-strict
>
> That analogy fails because Python bools being implemented as ints is not a
> bug to be fixed, but a useful feature.
>
> There are downsides, of course, but there are also benefits. It comes down
> to a matter of personal preference whether you think that bools should be
> abstract True/False values or concrete 1/0 values. Neither decision is
> clearly wrong, it's a matter of what you value.
>
> Whereas some decisions are just dumb:
>
> https://www.jwz.org/blog/2010/10/every-day-i-learn-something-new-and-stupid/
When we were kids we used to have 'pillow-fights' -- such fun!
So if we are in a link-pillow-fight here is a link
https://mail.python.org/pipermail/python-ideas/2016-June/040780.html
in which python-dev Nick Coghlan answers the question:
> Q: ...supporting arithmetical operations (1+True==2) was a primary
> intention, in which case my question is "why?".
>
> Nick: The inheritance from int meant the default behaviour was to support
> type-promoting integer arithmetic operations in addition to bitwise
> arithmetic.
>
> That changes the question from "Why support that?" to "Why do the extra
> design, documentation and implementation work needed to prevent that?".
>
> The fact that "1 + True == 2" is surprising hasn't proven to be enough to
> motivate anyone to define the precise subset of operations they want to
> prevent, and then make the case for those restrictions as Python's native
> behaviour.
Well enough of link-ing.
There are many aspects of bool's ½-assed status as a legitimate bool-type
of which 1+True==2 is a silly but not very significant/expensive consequence.
More significant...
Steven D'Aprano wrote:
> So we have falsey values:
>
> - None
> - zeroes (0, 0.0, 0j, etc)
> - empty dict {}
> - empty sets and frozensets
> - empty strings '' and b'' (in Python 2: u'' and '')
> - empty lists, tuples and other sequences
>
> and truthy values:
>
> - object
> - non-zero numbers
> - non-empty dicts
> - non-empty sets and frozensets
> - non-empty strings
> - non-empty sequences
>
> This is an improvement over other languages like Javascript, Ruby, etc where
> the division between truthy and falsey appears to be fairly arbitrary.
Likewise and more strongly
Chris wrote :
> If your RedBlackTree object were always *true*, I'd
> call it a missing feature ("please add a __bool__ that distinguishes
> empty trees from trees with content"), but always *false* would be a
> bug. A SortedDict implies by its name that it should be extremely
> dict-like, so that would be a strong argument for its truthiness to
> follow a dict's. Either way, the misbehaviour gets pointed back at the
> object in question.
And Marko wrote:
> I don't particularly like Python's falsey/truthy semantics,
> but I can live with it. The biggest problem I have with it is the
> absence of an emptiness predicate. I'd like to be able to write:
> The point is, Python has already declared that __bool__ is the
> canonical emptiness checker. You could even say that it's the
> principal purpose of the __bool__ method.
In short,
- Steven hints that empty/non-empty is some sort of *generic* property of data
structures
- Chris strengthens that to include types outside of builtins -- Red-Black trees
- Marko (thankfully adding the I dont like) connects emptiness to the dunder
__bool__
So here's some questions for the bool-fans
Please show me how we would define __bool__ for
1. Graphs -- the kind mathematicians define with "Let G =(V,E) be a graph..."
2. Automata which in a way are special kinds of graphs
3. Regular Expressions which mathematically are related to automata
And pragmatically are (more) present in python than the first two
It may (or may not) be helpful to pretend that python which already has
a regexp module/type also has explicit regexp syntax a la Perl.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Assignment Versus Equality
On Wednesday, June 29, 2016 at 8:06:10 AM UTC+5:30, Steven D'Aprano wrote: > On Tue, 28 Jun 2016 12:10 am, Rustom Mody wrote: > > > Analogy: Python's bool as 1½-class because bool came into python a good > > decade after python and breaking old code is a bigger issue than fixing > > control constructs to be bool-strict > > That analogy fails because Python bools being implemented as ints is not a > bug to be fixed, but a useful feature. > > There are downsides, of course, but there are also benefits. It comes down > to a matter of personal preference whether you think that bools should be > abstract True/False values or concrete 1/0 values. Neither decision is > clearly wrong, it's a matter of what you value. > > Whereas some decisions are just dumb: > > https://www.jwz.org/blog/2010/10/every-day-i-learn-something-new-and-stupid/ Answered in "Operator Precedence/Boolean" thread where this is more relevant -- https://mail.python.org/mailman/listinfo/python-list
Re: Can math.atan2 return INF?
Steven D'Aprano : > There's a common myth going around that black holes take an infinite > amount of time to form, That appears to be the case. (Identical discussion points here: http://astronomy.stackexchange.com/questions/2441/does-matter-accumulat e-just-outside-the-event-horizon-of-a-black-hole>.) > or another way of putting it is that it takes an infinite amount > of time for something to fall into a black hole, That's not another way of putting it. That's a completely different story. > and therefore "black holes can't really exist". This myth comes about > because people don't fully understand the (admittedly mind-boggling) > implications of General Relativity. No, the fundamental question here is whether it makes scientific sense to speculate about topics that are beyond the reach of science. Few scientists speculate about what went on before the Big Bang, for example. > First, you must accept that *your* experiences are not the only valid > experiences. Just because *you* never see the black hole form, doesn't > mean it doesn't form. You just don't get to experience it yourself. The main point: the only direct information we can ever have about black holes is by falling into one. Since none of that information can be communicated back, it cannot be considered any more scientific than the religions' beliefs about life after death (you can verify, say, Christianity by dying but that doesn't make it valid science). anyone that asserts a singularity exists inside a black hole is simply saying that the mathematical model they're using says there is one http://astronomy.stackexchange.com/questions/2441/does-matter-a ccumulate-just-outside-the-event-horizon-of-a-black-hole#comment21507 _2448> > Neither is "right" and the other is "wrong", neither frame of > reference is privileged over the other. BOTH are right, even though > they contradict each other. That's the nature of the universe we live > in. Nobody has claimed otherwise. > Tim is so engrossed by the view of the gravitational lensing that he > forgets to fire the retro-rockets, and before he knows it, he's > crossed the event horizon and there's no going back. > > For a sufficiently large black hole, he might not even have noticed > the transition. From his perspective, he's still distant from the > singularity (being so small and distant, he can't quite make out what > it looks like), and space-time is still quite flat for a sufficiently > large black hole. Tim can still see out, although the incoming light > is getting bluer, and he's still receiving Bill's clock signals, > though like Graham he sees them as drastically sped up. By the time the event horizon hits Tim at the speed of light, Tim will have received all of our Universe's signals at an ever accelerating frequency and increasing power. He will have seen the End of the World before leaving it. We have no way of telling if your prediction would be true for Tim inside the black hole. > Tim's spaceship appears to be *asymptotically* approaching the event > horizon, in some sort of horrible version of Zeno's Paradoxes: each > minute that goes by, Tim gets closer to the event horizon by a > *smaller* amount as time slows down for him (as seen by Bill and > Graham on the space station). Correct, and very relevant. In fact, that's the reason the even horizon never even appears to form to us outsiders. The star just keeps on collapsing for ever. That is true even for Tim who can't experience a true black hole before it hits him. > Although their perspectives are very different, neither is "more > right" than the other. No, but only one of them can be examined scientifically. Heisenberg's uncertainty principle was at first presented as some sort of limitation to what we can know. Nowadays, it is viewed more fundamentally as a law of physics; en electron cannot fall in the nucleus of an atom because it would end up violating Heisenberg's uncertainty principle. Similarly, the Universe does not owe us an answer to what happens to Tim. The Universe will come to an end (even for Tim) before the question comes to the fore. The cosmic teenage hacker who created our virtual world probably simply typed this in that part of his code: raise NotImplementedError() thus terminating Tim's thread. > From our frame of reference, we seem them asymptotically approaching > the event horizon, but never cross it. More than that, we see the star collapsing but never quite being able to create an event horizon. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Operator Precedence/Boolean Logic
On Wed, Jun 29, 2016 at 8:21 PM, Rustom Mody wrote:
>
> Please show me how we would define __bool__ for
>
> 1. Graphs -- the kind mathematicians define with "Let G =(V,E) be a graph..."
>
> 2. Automata which in a way are special kinds of graphs
>
> 3. Regular Expressions which mathematically are related to automata
> And pragmatically are (more) present in python than the first two
>
> It may (or may not) be helpful to pretend that python which already has
> a regexp module/type also has explicit regexp syntax a la Perl.
Probably the easiest way, for each of these objects, is to not define
__bool__ at all, or to define it thus:
def __bool__(self):
return True
If an object isn't a container, but is just a "thing", then it is by
definition true. The contrast isn't between [1] and [], but rather
between object() and None. It's perfectly reasonable for an object to
be always true - that's what the default object type does. You could
perhaps argue that a graph can be empty, but unless you're frequently
wanting to distinguish between empty graphs and non-empty graphs, I'd
stick with the default and make them always true. Note, for instance:
>>> bool(re.compile(""))
True
I think that's about as empty as a regex can be, and it's still true.
And regex match objects are always true, too - the match functions
will all return None if there's no match. Not all objects need to be
able to be falsey.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Language improvement: Get more from the `for .. else` clause
Sure. Simple use-case: Decorate the yielded values and the return value of a generator. Right now, with `yield from` you can only decorate the return value, whereas with a for loop you can decorate the yielded values, but you sacrifice the returned value altogether. ``` def ret_decorator(target_generator): returned_value = yield from target_generator() return decorate_ret(returned_value) def yield_decorator(target_generator): for yielded_value in target_generator: yield decorate_yield(yielded_value) # Nothing to return. the target return value was # consumed by the for loop ``` With the proposed syntax, you can decorate both: ``` def decorator(target_generator): for yielded_value in target_generator: yield decorate_yield(yielded_value) else returned_value: return decorate_ret(returned_value) ``` Please let me know if you are interested in a more concrete case such as a domain-specific application (I can think of progress bars, logging, transfer rate statistics ...). Best, VS On Mon, Jun 27, 2016 at 5:06 PM, Michael Selik wrote: > On Mon, Jun 27, 2016 at 12:53 AM Victor Savu < > victor.nicolae.s...@gmail.com> wrote: > >> capture the [StopIteration] value in the `else` statement of the `for` >> loop >> > > I'm having trouble thinking of a case when this new feature is necessary. > Can you show a more realistic example? > -- https://mail.python.org/mailman/listinfo/python-list
Re: "for/while ... break(by any means) ... else" make sense?
Steven D'Aprano at 2016/6/29 UTC+8 10:43:52AM wrote: > The "else" in for...else has nothing to do with any "if" inside the for > block. Yes, the "else" has nothing to do with "break" syntactically in Python language, but semantically in English it cause confusion. When I said "insane", I just want to emphasis this situation. "else" should appear only when there is a "break" in the "for" block, then "for ...break... else ..." become perfectly alright semantically. Never think of it in "for ...else ..." or the confusion bond to come up:-) --Jach -- https://mail.python.org/mailman/listinfo/python-list
Re: Assignment Versus Equality
On Wed, 29 Jun 2016 06:09 pm, Chris Angelico wrote: > On Wed, Jun 29, 2016 at 4:45 PM, Steven D'Aprano > wrote: >> On Wednesday 29 June 2016 15:51, Lawrence D’Oliveiro wrote: >> >>> On Wednesday, June 29, 2016 at 5:26:46 PM UTC+12, Steven D'Aprano wrote: BUT in Python 3, the distinction between int and long is gone by dropping int and renaming long as "int". So all Python ints are BIGNUMs. >>> >>> I don’t understand what the problem is with this. Is there supposed to >>> be some issue with performance? Because I can’t see it. >> >> If there is a performance hit, it's probably pretty small. It may have >> been bigger back in Python 3.0 or 3.1. >> >> [steve@ando ~]$ python2.7 -m timeit -s "n = 0" "for i in xrange(1): n >> [+= i" >> 100 loops, best of 3: 1.87 msec per loop >> >> [steve@ando ~]$ python3.3 -m timeit -s "n = 0" "for i in range(1): n >> [+= i" >> 1000 loops, best of 3: 1.89 msec per loop >> >> >> Although setting debugging options does make it pretty slow: >> >> [steve@ando ~]$ python/python-dev/3.6/python -m timeit -s "n = 0" "for i >> [in >> range(1): n += i" >> 100 loops, best of 3: 13.7 msec per loop > > That's not necessarily fair - you're comparing two quite different > Python interpreters, so there might be something entirely different > that counteracts the integer performance. Um, the two code snippets do the same thing. Comparing two different versions of the same interpreter is *precisely* what I intended to do: - is CPython using boxed native ints faster than CPython using boxed BigNums, post unification? No, my test doesn't precisely compare performance of boxed native ints versus boxed BigNums for the same version, but I don't care about that. I care about whether the Python interpeter is slower at int arithmetic since unifying int and long, and my test shows that it isn't. > (For example: You're > creating and disposing of large numbers of objects, so the performance > of object creation could affect things hugely.) Sure. But in real life code, you're likely to be creating and disposing of large numbers of objects. And both versions create and dispose of the same objects, so the test is fair to both versions. > To make it somewhat > fairer, add long integer performance to the mix. Starting by redoing > your test: Why? That's irrelevant. The comparison I'm looking at is whether arithmetic was faster using boxed native ints in older versions. In other words, has there been a performance regression between 2.7 and 3.3? For int arithmetic, the answer is No. I can make guesses and predictions about why there is no performance regression: - native ints were amazingly fast in Python 2.7, and BigNums in Python 3.3 are virtually as fast; - native ints were horribly slow in Python 2.7, and changing to BigNums is no slower; - native ints were amazingly fast in Python 2.7, and BigNums in Python 3.3 are horribly slow, BUT object creation and disposal was horribly slow in 2.7 and is amazingly fast in 3.3, so overall it works out about equal; - int arithmetic is so fast in Python 2.7, and xrange() so slow, that what I actually measured was just the cost of calling xrange, and by mere coincidence it happened to be almost exactly the same speed as bignum arithmetic in 3.3. But frankly, I don't really care that much. I'm not so much interested in micro-benchmarking individual features of the interpreter as caring about the overall performance, and for that, I think my test was reasonable and fair. > rosuav@sikorsky:~$ python2.7 -m timeit -s "n = 0" "for i in > xrange(1): n += i" > 1 loops, best of 3: 192 usec per loop > rosuav@sikorsky:~$ python2.7 -m timeit -s "n = 1<<100" "for i in > xrange(1): n += i" > 1000 loops, best of 3: 478 usec per loop Now *that's* an unfair benchmark, because we know that BigNums get slower as they get bigger. A BigNum with 30+ digits is not going to perform like a BigNum with 8 digits. The right test here would be: python2.7 -m timeit -s "n = 0L" "for i in xrange(1): n += i" On my machine, I get these figures: [steve@ando ~]$ python2.7 -m timeit -s "n = 0" "for i in xrange(1): n += i" 1000 loops, best of 3: 2.25 msec per loop [steve@ando ~]$ python2.7 -m timeit -s "n = 0L" "for i in xrange(1): n += i" 100 loops, best of 3: 2.33 msec per loop which suggests that even in 2.7, the performance difference between native ints and BigNums was negligible for smallish numbers. But of course if we use huge BigNums, they're more expensive: [steve@ando ~]$ python2.7 -m timeit -s "n = 1 << 100" "for i in xrange(1): n += i" 100 loops, best of 3: 2.44 msec per loop although apparently not *that* much more expensive on my machine. Let's try something bigger: [steve@ando ~]$ python2.7 -m timeit -s "n = 1 << 1000" "for i in xrange(1): n += i" 100 loops, best of 3: 4.23 msec per loop Now you can see the cost of really BigNums. But still, that's about 300 digits, so not too shabby. -- Steven
Re: Operator Precedence/Boolean Logic
On Wed, 29 Jun 2016 08:21 pm, Rustom Mody wrote: > So if we are in a link-pillow-fight here is a link > https://mail.python.org/pipermail/python-ideas/2016-June/040780.html > in which python-dev Nick Coghlan answers the question: > >> Q: ...supporting arithmetical operations (1+True==2) was a primary >> intention, in which case my question is "why?". >> >> Nick: The inheritance from int meant the default behaviour was to support >> type-promoting integer arithmetic operations in addition to bitwise >> arithmetic. >> >> That changes the question from "Why support that?" to "Why do the extra >> design, documentation and implementation work needed to prevent that?". >> >> The fact that "1 + True == 2" is surprising hasn't proven to be enough to >> motivate anyone to define the precise subset of operations they want to >> prevent, and then make the case for those restrictions as Python's native >> behaviour. Nick is a very senior core developer, and we would be foolish to ignore his opinion, but that doesn't make his comments gospel. To Nick, having 1+True return 2 is an accident of implementation, where it is too much work to prevent it for the minimal gain it would give. And historically, that was Guido's attitude back when Python gained a bool type. (Initially Python gained to pseudo-constants, True and False, set equal to 1 and 0; then in the following release it gained a built-in type bool that subclassed int, with exactly two instances, True and False.) But it is my argument that with (roughly) ten years of experience with us, we can say that 1+True == 2 is not just an unfortunate accident of implementation that we are forced to live with because nobody wants to do the work to correct it. Rather, it is a useful and desirable feature. If I were designing a new language from scratch, I would probably follow Python's lead and use an int subclass for bools. As I said before, this isn't to dispute or deny the fact that bools-as-ints have unfortunate consequences. But they have useful consequences too, and in my opinion they outweigh the bad ones. If you disagree, okay, you disagree. I like broccoli and hate streaky bacon, others feel the opposite way. I'm lucky that Python, due to historical accident, ended up working the way I prefer. When you design your own language, you can make it work the way you prefer. [...] > More significant... > > Steven D'Aprano wrote: > >> So we have falsey values: Note that the question of truthy/falsey duck-typed bools is independent of whether bools are abstract flags or concrete ints. A language could: - have a dedicated, abstract bool type, like Pascal does; - completely do without a dedicated bool type, and just have truthy/falsey values, like Python 1.5 did; - allow all values to be treated as truthy/falsey values, but have a concrete (int-subclass) bool type as the canonical true/false, like Python 2 & 3 does; - allow all values to be treated as truthy/falsey values, but have an abstract bool type as the canonical true/false, like Javascript does. So the question of truthy/falsey values is orthogonal to the question of whether bool should inherit from int. > In short, > - Steven hints that empty/non-empty is some sort of *generic* property of > data structures - Chris strengthens that to include types outside of > builtins -- Red-Black trees - Marko (thankfully adding the I dont like) > connects emptiness to the dunder __bool__ It's not just a hint. Python has a convention that empty collections should be treated as falsey; likewise empty sequences; likewise "empty" numbers. And non-empty ones should be treated as truthy. This is built into the way the interpreter decides whether something is truthy or falsey. Given: if spam: ... else: ... Python decides which branch to take as follows: - if spam has a __len__ method, and spam.__len__() returns 0, then spam is falsey and the `else` branch is taken; - if spam.__len__() returns a non-zero number, then spam is truthy and the `if` branch is taken; - otherwise, if spam has a __nonzero__ method (__bool__ in Python 3), if it returns a falsey value, then spam is falsey; - but if it returns a truthy value, then spam is truthy; - and if spam has neither a __len__ nor a __nonzero__ / __bool__ method, then by default it is truthy. > So here's some questions for the bool-fans > > Please show me how we would define __bool__ for > > 1. Graphs -- the kind mathematicians define with "Let G =(V,E) be a > graph..." I would make the empty graph (zero nodes) falsey, and non-empty graphs (one or more nodes) truthy. > 2. Automata which in a way are special kinds of graphs As above. > 3. Regular Expressions which mathematically are related to automata > And pragmatically are (more) present in python than the first two Can you even have an empty regular expression? What does it match? Possibly nothing at all. Ideally, I would have the empty regular expression be falsey, and all others tru
Re: Assignment Versus Equality
On 29/06/2016 13:36, Steven D'Aprano wrote: On Wed, 29 Jun 2016 06:09 pm, Chris Angelico wrote: That's not necessarily fair - you're comparing two quite different Python interpreters, so there might be something entirely different that counteracts the integer performance. No, my test doesn't precisely compare performance of boxed native ints versus boxed BigNums for the same version, but I don't care about that. I care about whether the Python interpeter is slower at int arithmetic since unifying int and long, and my test shows that it isn't. For int arithmetic, the answer is No. I can make guesses and predictions about why there is no performance regression: - native ints were amazingly fast in Python 2.7, and BigNums in Python 3.3 are virtually as fast; - native ints were horribly slow in Python 2.7, and changing to BigNums is no slower; - native ints were amazingly fast in Python 2.7, and BigNums in Python 3.3 are horribly slow, BUT object creation and disposal was horribly slow in 2.7 and is amazingly fast in 3.3, so overall it works out about equal; - int arithmetic is so fast in Python 2.7, and xrange() so slow, that what I actually measured was just the cost of calling xrange, and by mere coincidence it happened to be almost exactly the same speed as bignum arithmetic in 3.3. But frankly, I don't really care that much. I'm not so much interested in micro-benchmarking individual features of the interpreter as caring about the overall performance, and for that, I think my test was reasonable and fair. I think there are too many things going on in CPython that would dominate matters beyond the actual integer arithmetic. I used this little benchmark: def fn(): n=0 for i in range(100): n+=i for k in range(100): fn() With CPython, Python 2 took 21 seconds (20 with xrange), while Python 3 was 12.3 seconds (fastest times). I then ran the equivalent code under my own non-Python interpreter (but a version using 100% C to keep the test fair), and it was 2.3 seconds. (That interpreter keeps 64-bit integers and bigints separate. The 64-bit integers are also value-types, not reference-counted objects.) When I tried optimising versions, then PyPy took 7 seconds, while mine took 0.5 seconds. Testing the same code as C, then unoptimised it was 0.4 seconds, and optimised, 0.3 seconds (but n was declared 'volatile' to stop the loop being eliminated completely). So the actual work involved takes 0.3 seconds. That means Python 3 is spending 12.0 seconds dealing with overheads. The extra ones of dealing with bigints would get lost in there! (If I test that same code using an explicit bigint for n, then it's a different story. It's too complicated to test for C, but it will likely be a lot more than 0.3 seconds. And my bigint library is hopelessly slow, taking some 35 seconds. So from that point of view, Python is doing a good job of managing a 12-second time using a composite integer/bigint type. However, the vast majority of integer code /can be done within 64 bits/. Within 32 bits probably. But like I said, it's possible that other overheads come into play than just the ones of using bigints, which I would imagine are streamlined.) -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Operator Precedence/Boolean Logic
On Wednesday, June 29, 2016 at 6:38:16 PM UTC+5:30, Steven D'Aprano wrote:
> On Wed, 29 Jun 2016 08:21 pm, Rustom Mody wrote:
> > 3. Regular Expressions which mathematically are related to automata
> > And pragmatically are (more) present in python than the first two
>
> Can you even have an empty regular expression? What does it match? Possibly
> nothing at all.
>
> Ideally, I would have the empty regular expression be falsey, and all others
> truthy, but I wouldn't be too upset if all regexes were True.
Salutations!
Chris fell into the trap -- if I take his "" as
> I think that's about as empty as a regex can be,
You have not fallen in... Admirable!
What you need is a negative lookahead empty re (?!)
>>> re.findall("", "")
['']
>>> re.findall("(?!)", "")
[]
>>> re.findall("(?!)", "a")
[]
>>> re.findall("", "a")
['', '']
>>>
The other answers -- graphs and automata -- are questionable and/or wrong
You may wish to think about them again?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Assignment Versus Equality
On Wed, Jun 29, 2016 at 11:24 PM, BartC wrote: > I used this little benchmark: > > def fn(): > n=0 > for i in range(100): > n+=i > > for k in range(100): > fn() Add, up the top: try: range = xrange except NameError: pass Otherwise, your Py2 tests are constructing a million-element list, which is a little unfair. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Assignment Versus Equality
On Wed, Jun 29, 2016 at 10:36 PM, Steven D'Aprano wrote: >> rosuav@sikorsky:~$ python2.7 -m timeit -s "n = 0" "for i in >> xrange(1): n += i" >> 1 loops, best of 3: 192 usec per loop >> rosuav@sikorsky:~$ python2.7 -m timeit -s "n = 1<<100" "for i in >> xrange(1): n += i" >> 1000 loops, best of 3: 478 usec per loop > > Now *that's* an unfair benchmark, because we know that BigNums get slower as > they get bigger. A BigNum with 30+ digits is not going to perform like a > BigNum with 8 digits. On its own, perhaps. But then I do the exact same tests on Python 3, and the numbers are virtually identical - suggesting that the bignum slowdown isn't all that significant at all. But in case you're worried, I'll do it your way too: rosuav@sikorsky:~$ python2.7 -m timeit -s "n = 0" "for i in xrange(1): n += i" 1 loops, best of 3: 192 usec per loop rosuav@sikorsky:~$ python2.7 -m timeit -s "n = 1<<100" "for i in xrange(1): n += i" 1000 loops, best of 3: 476 usec per loop rosuav@sikorsky:~$ python2.7 -m timeit -s "n = 0L" "for i in xrange(1): n += i" 1000 loops, best of 3: 476 usec per loop So, once again, my system shows that there's a definite slowdown from using bignums - and it's the same whether I start with 1<<100 or 0L. (In this particular run, absolutely precisely the same, but other runs showed numbers like 479 and 486.) What's different about your system that you see short ints as performing exactly the same as long ints? Obviously you're running on a slower computer than mine (you're seeing msec values compared to my usec), but that shouldn't be significant. Is there a massive architectural difference? rosuav@sikorsky:~$ uname -a Linux sikorsky 4.6.0-1-amd64 #1 SMP Debian 4.6.1-1 (2016-06-06) x86_64 GNU/Linux ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Can math.atan2 return INF?
On Wed, Jun 29, 2016, at 05:35, Steven D'Aprano wrote: > Although their perspectives are very different, neither is "more > right" than the other. I think usually the idea that there are "no privileged frames of reference" doesn't go so far as to include ones from which it is impossible to send information to the rest of. When it's impossible for observations to be transmitted back to Earth (or to anywhere else), you've crossed a line from science to philosophy. -- https://mail.python.org/mailman/listinfo/python-list
Re: Assignment Versus Equality
On 29/06/2016 14:35, Chris Angelico wrote: On Wed, Jun 29, 2016 at 11:24 PM, BartC wrote: I used this little benchmark: def fn(): n=0 for i in range(100): n+=i for k in range(100): fn() Add, up the top: try: range = xrange except NameError: pass Otherwise, your Py2 tests are constructing a million-element list, which is a little unfair. It made little difference (21 seconds instead of 20 seconds). But that was on Windows. I remember that Python was much more sluggish on Windows than under Ubuntu on the same machine. (Maybe the Windows version was 32-bits or something.) Trying it on Ubuntu, Py2 takes 6 seconds (using xrange otherwise it's 9 seconds) , while pypy (2.7) manages 0.35 seconds. pypy normally excels with such loops, but I recall also that it had some trouble with this particular benchmark, which this version must have fixed. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: "for/while ... break(by any means) ... else" make sense?
On 2016-06-29, Steven D'Aprano wrote: [...] > is "insane" too, but still legal. The Python interpreter does not > judge your code. That's what Usenet is for. -- Grant Edwards grant.b.edwardsYow! I'm a nuclear at submarine under the gmail.compolar ice cap and I need a Kleenex! -- https://mail.python.org/mailman/listinfo/python-list
Re: Operator Precedence/Boolean Logic
On 2016-06-29, Steven D'Aprano wrote: > To Nick, having 1+True return 2 is an accident of implementation, My recollection is that it was not an accident of impliementation. It was an intentional descision to provide compatibility with many years worth of programs that were written before there was either a boolean type or built-in True/False integer values. Those programs often did this at the top: True = 1 False = 0 Having True and False evaluate as 1 and 0 in an integer expression context guaranteed that those programs would to continue to work with minimal changes. -- Grant Edwards grant.b.edwardsYow! Life is a POPULARITY at CONTEST! I'm REFRESHINGLY gmail.comCANDID!! -- https://mail.python.org/mailman/listinfo/python-list
Re: Operator Precedence/Boolean Logic
On 2016-06-29, Grant Edwards wrote: > On 2016-06-29, Steven D'Aprano wrote: >> To Nick, having 1+True return 2 is an accident of implementation, > > My recollection is that it was not an accident of impliementation. It > was an intentional descision to provide compatibility with many years > worth of programs that were written before there was either a boolean > type or built-in True/False integer values. > > Those programs often did this at the top: > > True = 1 > False = 0 > > Having True and False evaluate as 1 and 0 in an integer expression > context guaranteed that those programs would to continue to work with > minimal changes. I thought it was more for things like this: "%d widget%s" % (widgets, (widgets != 1) * "s") i.e. using boolean expressions as numeric expressions, rather than explicitly setting the identifiers True and False to be numbers. -- https://mail.python.org/mailman/listinfo/python-list
Re: Language improvement: Get more from the `for .. else` clause
On Wed, Jun 29, 2016 at 7:11 AM Victor Savu wrote: > Please let me know if you are interested in a more concrete case such as a > domain-specific application (I can think of progress bars, logging, > transfer rate statistics ...). > Yes, please. I'd like to compare the proposed syntax against the solution with the current syntax. -- https://mail.python.org/mailman/listinfo/python-list
Re: Iteration, while loop, and for loop
On Tue, Jun 28, 2016 at 11:58 AM, Grant Edwards
wrote:
> On 2016-06-28, Tim Chase wrote:
>> On 2016-06-29 01:20, Steven D'Aprano wrote:
>>> While loops are great for loops where you don't know how many
>>> iterations there will be but you do know that you want to keep
>>> going while some condition applies:
>>>
>>> while there is still work to be done:
>>> do some more work
>>
>> I find this particularly the case when the thing being iterated over
>> can be changed, such as a queue of things to process:
>>
>> items = deque()
>> items.append(root_node)
>> while items:
>> item = items.popleft()
>> process(item)
>> items.extend(item.children)
>
> Yep, I often do something similar when processing a block of data
> bytes comprising a sequence of "things" of varying number of bytes.
>
> data = read_a_blob_of_bytes()
> while data:
> #figure out how long the first "thing" is
> len = 'data'>
> handle_thing(data[:len])
> data = data[len:]
>> But then, if you wrap up your "while" loop as a generator that yields
>> things, you can then use it in a "for" loop which seems to me like
>> the Pythonic way to do things. :-)
>
> Yea, I keep telling myself that, but I never actually do it.
Here you go:
import collections
class MutableIterator:
def __init__(self, iterable):
self._stopped = False
self.replace(iterable)
def __iter__(self):
return self
def __next__(self):
if self._stopped:
raise StopIteration
while self._iterator or self._iterables:
if self._iterator:
try:
return next(self._iterator)
except StopIteration:
self._iterator = None
if self._iterables:
self._iterator = iter(self._iterables.popleft())
self._stopped = True
raise StopIteration
def clear():
self._iterables.clear()
self._iterator = None
def replace(self, iterable):
self._check_stopped()
self._iterables = collections.deque([iterable])
self._iterator = None
def append(self, item):
self.extend([item])
def extend(self, iterable):
self._check_stopped()
self._iterables.append(iterable)
def _check_stopped(self):
if self._stopped:
raise ValueError('Tried to mutate a stopped iterator')
# Example:
>>> mi = MutableIterator('bananas')
>>> for char in mi:
... if char == 'a':
... mi.extend(' yum')
... print(char, end='')
...
bananas yum yum yum
--
https://mail.python.org/mailman/listinfo/python-list
Re: "for/while ... break(by any means) ... else" make sense?
On 6/29/2016 6:01 AM, Victor Savu wrote: There are many posts trying to explain the else after for or while. My take: a while statement *is* a repeated if statement, and that is how it is implemented. while condition: true() is equivalent to and implemented in machine language without a native while command as if condition: true() goto label An else clause is executed exactly when the condition is false. This understanding is useful in understanding how and why tail recursion is equivalent to and can be converted to a while loop. def f(n, accum): if recurse: return f(g(n), h(n, accum)) else: return accum What does the recursive call do? It assigns new values to the parameters and goes to the top of the code. Since it is a tail call, the old parameter bindings are not needed. So the above does the same as def f(n, accum): if recurse: n, accum = g(n), h(n, accum goto label else: return accum which is the same, by the above, as def f(n, accum): while recurse: n, accum = g(n), h(n, accum else: return accum In other words, convert properly formatted tail recursion (where the condition is the recurse condition, rather than the terminate condition) by replacing 'if' with 'while' and the tail recursive call with unpacking assignment. It is conventional to drop the else:, but it is implicitly still there. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Operator Precedence/Boolean Logic
On Wed, 29 Jun 2016 11:30 pm, Rustom Mody wrote: > The other answers -- graphs and automata -- are questionable and/or wrong > > You may wish to think about them again? You may wish to justify your assertion. -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Operator Precedence/Boolean Logic
On Thu, 30 Jun 2016 01:00 am, Grant Edwards wrote: > On 2016-06-29, Steven D'Aprano wrote: > >> To Nick, having 1+True return 2 is an accident of implementation, > > My recollection is that it was not an accident of impliementation. It > was an intentional descision to provide compatibility with many years > worth of programs that were written before there was either a boolean > type or built-in True/False integer values. You're right ... I was thinking accident of history and wrote accident of implementation :-( -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Iteration, while loop, and for loop
On Thu, 30 Jun 2016 01:29 am, Ian Kelly wrote:
> On Tue, Jun 28, 2016 at 11:58 AM, Grant Edwards
> wrote:
[...]
>>> But then, if you wrap up your "while" loop as a generator that yields
>>> things, you can then use it in a "for" loop which seems to me like
>>> the Pythonic way to do things. :-)
>>
>> Yea, I keep telling myself that, but I never actually do it.
>
> Here you go:
>
> import collections
>
> class MutableIterator:
[snip 8 methods and 33 lines of code]
> # Example:
>
mi = MutableIterator('bananas')
for char in mi:
> ... if char == 'a':
> ... mi.extend(' yum')
> ... print(char, end='')
> ...
> bananas yum yum yum
I'm curious what REPL you are using, because in the vanilla Python
interactive interpreter, the output if over-written by the prompt. That is,
what I see in Python 3.6 is:
py> nas yum yum yumpy>
unless I take steps to prevent that. See below.
But there's no need to go to such effort for a mutable iterator. This is
much simpler:
py> mi = list('bananas')
py> for char in mi:
... if char == 'a':
... mi.extend(' yum')
... print(char, end='')
... else: # oh no, the feared for...else!
... # needed to prevent the prompt overwriting the output
... print()
...
bananas yum yum yum
py>
This example shows two things:
(1) There's no need for a MutableIterator, we have list;
(2) Anyone who says that for...else without break is useless is wrong.
--
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Assignment Versus Equality
Marko Rauhamaa wrote: -- / \ / (almost) \ N |black || | hole |S \/ \ / -- / / compass needle / The compass needle shows that the probe is "frozen" and won't budge no matter how long we wait. All your experiment shows is that the last information we had about the magnet is that it was nearly stationary just above the horizon. It doesn't prove that the probe itself is frozen, any more than the fact that a photograph you took of something last month doesn't move proves that the object you photographed is stuck in the state it was in a month ago. Keep in mind that changes in the magnetic field propagate at the speed of light and are subject to the same redshift, etc. as any other signal. It doesn't matter whether you use a permanent magnet, an electric charge, or coconuts banged together in morse code, relativity still applies. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: "for/while ... break(by any means) ... else" make sense?
On Wed, 29 Jun 2016 08:01 pm, Victor Savu wrote: > There are many posts trying to explain the else after for or while. Here > is my take on it: > > There are three ways of getting out of a (for/while) loop: throw, break or > the iterator gets exhausted. - reaching the end of the loop - raise (not throw) - return (if inside a function) - calling os.abort() - calling os._exit() - break So at least six ways. > The question is, how cab we tell which way we exited? I'm not really sure that is the right question to ask, but okay, let's continue and see where this goes. > For the throw, we have the except clause. Which `except` clause? `except` is not part of the for statement, it is completely independent. There may, or may not, be an `except` clause anywhere in your code. In either case, the `raise` behaves like a GOTO, jumping to the nearest `except` clause (if any). That may be inside the loop: for x in seq: try: do_something(x) except Error: ... or outside the loop: try: for x in seq: do_something(x) except Error: ... or there may be no except clause at all, and control is transferred to the top-level error handler (if any) or to the Python interpreter, which then prints a stack trace and exits. > This leaves us to > differentiatr between break and normal exhaustion of the iterator. Following `return`, the function returns and transfer returns to the caller's code. Following os.abort(), the interpreter exits in the hardest, quickest manner possible. Following os._exit(), the interpreter exits without doing any normal cleanup or processing. In those two cases, we cannot run any Python code after the function is called, so the question of distinguishing them from ending the loop normally doesn't come up. Nevertheless, they do exit the loop. > This is > that the else clause is for: we enter the body iff the loop iterator was > exhausted. The way I would put it is that we enter the body of the `else` statement when the loop reaches the end. That applies to both `while` and `for` loops, and it applies to looping over sequences using the sequence protocol instead of the iterator protocol. It applies to empty sequences (the loop reaches the end immediately). And it even applies to infinite loops: if the loop never ends, the `else` statement never runs. And most importantly, if we transfer control out of the `for` statement using *any* other mechanism (break, return, raise, os.abort, ...) then the `else` statement never runs because we have jumped past it. > I for one would have chosen 'then' as a keyword to mark > something that naturally happens as part of the for statement but after > the looping is over; I agree with this. > assuming break jumps out of the entire statement, it > makes sense that it skips the 'then' body as well. And this. > (In the same way, I > prefer 'catch' to 'except' as a correspondent to 'throw', There is no "throw" in Python, there is "raise". > but all of this > is just bikeshedding). At a language design level, the decision was made > to reuse one of the existing keywords and for better or worse, 'else' was > chosen, which can be thought of as having no relation to the other use of > the same keyword in the 'if' statement. The only rationale behind this was > to save one keyword. Agreed. -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: "for/while ... break(by any means) ... else" make sense?
On Thu, Jun 30, 2016 at 10:27 AM, Steven D'Aprano wrote: > Following os.abort(), the interpreter exits in the hardest, quickest manner > possible. os.kill(os.getpid(), 9) Now THAT is the hardest way to abort. You ain't comin' back from this one! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Can math.atan2 return INF?
On Wednesday, June 29, 2016 at 10:55:03 PM UTC+12, Marko Rauhamaa wrote: > No, the fundamental question here is whether it makes scientific sense > to speculate about topics that are beyond the reach of science. Few > scientists speculate about what went on before the Big Bang, for > example. On the contrary. The cosmic microwave background is too smooth to be explained by a simple Big Bang. Hence the invention of cosmic inflation, to try to smooth it out. Trouble is, once you turn on the inflation field, how do you turn it off? But if you don’t turn it off, then you get an infinite series of Big Bangs, not just one. So you see, like it or not, we are drawn to the conclusion that there *was* indeed something before our particular Big Bang. Every time somebody tries to point to an example of a “topic that is beyond the reach of science”, it seems to get knocked over eventually. -- https://mail.python.org/mailman/listinfo/python-list
Re: Can math.atan2 return INF?
On Thursday, June 30, 2016 at 7:03:30 AM UTC+5:30, Lawrence D’Oliveiro wrote: > On Wednesday, June 29, 2016 at 10:55:03 PM UTC+12, Marko Rauhamaa wrote: > > No, the fundamental question here is whether it makes scientific sense > > to speculate about topics that are beyond the reach of science. Few > > scientists speculate about what went on before the Big Bang, for > > example. > > On the contrary. The cosmic microwave background is too smooth to be > explained by a simple Big Bang. Hence the invention of cosmic inflation, to > try to smooth it out. Trouble is, once you turn on the inflation field, how > do you turn it off? But if you don’t turn it off, then you get an infinite > series of Big Bangs, not just one. > > So you see, like it or not, we are drawn to the conclusion that there *was* > indeed something before our particular Big Bang. > > Every time somebody tries to point to an example of a “topic that is beyond > the reach of science”, it seems to get knocked over eventually. What is the physics that you folks are talking of ... Ive no idea OTOH Computer Science HAPPENED because mathematicians kept hotly disputing for more than ½ a century as to what is legitimate math and what is theology/mysticism/etc: In particular the question: "Are real numbers really real?" is where it starts off... http://blog.languager.org/2015/03/cs-history-0.html -- https://mail.python.org/mailman/listinfo/python-list
Re: "for/while ... break(by any means) ... else" make sense?
On Thursday, June 30, 2016 at 6:58:42 AM UTC+5:30, Chris Angelico wrote: > On Thu, Jun 30, 2016 at 10:27 AM, Steven D'Aprano wrote: > > Following os.abort(), the interpreter exits in the hardest, quickest manner > > possible. > > os.kill(os.getpid(), 9) > > Now THAT is the hardest way to abort. You ain't comin' back from this one! Is it? | On Windows, signal() can only be called with SIGABRT, SIGFPE, SIGILL, SIGINT, | SIGSEGV, or SIGTERM. A ValueError will be raised in any other case. from https://docs.python.org/3.5/library/signal.html 9 may still work?? Dunno... -- https://mail.python.org/mailman/listinfo/python-list
Re: Can math.atan2 return INF?
On Thu, Jun 30, 2016 at 12:13 PM, Rustom Mody wrote: > ... hotly disputing for more than ½ a century... You keep using that character. Is it just to show off that you can? I was always taught to match the style of the rest of the sentence, so this would be "half a century". Same for most of your other uses - it would be far more grammatically appropriate to use the word "half". ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Meta decorator with parameters, defined in explicit functions
On Tuesday, June 28, 2016 at 5:03:08 PM UTC+12, Ben Finney wrote: > There is a clever one-line decorator that has been copy-pasted without > explanation in many code bases for many years:: > > decorator_with_args = lambda decorator: lambda *args, **kwargs: lambda > func: decorator(func, *args, **kwargs) > > My problem with this is precisely that it is clever: it explains nothing > about what it does, has many moving parts that are not named, it is > non-obvious and lacks expressiveness. It is written in a somewhat roundabout way: why not just decorator_with_args = lambda decorator, *args, **kwargs : lambda func : decorator(func, *args, **kwargs) ? Could it be this was not valid in earlier versions of Python? Anyway, it’s a function of a function returning a function. Example use (off the top of my head): my_decorator = decorator_with_args(actual_func_to_call)(... remaining args for actual_func_to_call) (for the original version) or my_decorator = decorator_with_args(actual_func_to_call,... remaining args for actual_func_to_call) (for the simpler version). Then an example use would be @my_decorator def some_func... which would call “actual_func_to_call” with some_func plus all those extra args, and assign the result back to some_func. > I would like to see a more Pythonic, more explicit and expressive > replacement with its component parts easily understood. I don’t know why this fear and suspicion of lambdas is so widespread among Python users ... former Java/C# programmers, perhaps? -- https://mail.python.org/mailman/listinfo/python-list
Re: Meta decorator with parameters, defined in explicit functions
On Tuesday, June 28, 2016 at 5:03:08 PM UTC+12, Ben Finney wrote: > decorator_with_args = lambda decorator: lambda *args, **kwargs: lambda > func: decorator(func, *args, **kwargs) Ah, I see why there are 3 lambdas, instead of 2. It’s so that you can write decorator_func = decorator_with_args(actual_func) then you can use it like this: @decorator_func(...additional args for actual_func...) def some_func... to invoke actual_func(some_func, ... additional args for actual_func...) on some_func, and assign the result back to some_func. -- https://mail.python.org/mailman/listinfo/python-list
Re: Assignment Versus Equality
On Thu, 30 Jun 2016 10:29 am, Gregory Ewing wrote: > All your experiment shows is that the last information we had > about the magnet is that it was nearly stationary just above > the horizon. > > It doesn't prove that the probe itself is frozen, any more than > the fact that a photograph you took of something last month > doesn't move proves that the object you photographed is > stuck in the state it was in a month ago. The easy way to see that it isn't frozen in place is to try to fly down to meet it. > Keep in mind that changes in the magnetic field propagate at > the speed of light and are subject to the same redshift, etc. > as any other signal. It doesn't matter whether you use a > permanent magnet, an electric charge, or coconuts banged > together in morse code, relativity still applies. An electric charge is a much better approach. Because it is a monopole, it is detectable from a distant more easily than a magnetic bipole, and while magnets are going to be vaporised into plasma (hence losing their magnetic field), electrons are electrons (at least until you get into the quantum gravity regime, at which point we don't know what happens). -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Meta decorator with parameters, defined in explicit functions
On Thu, 30 Jun 2016 12:43 pm, Lawrence D’Oliveiro wrote:
> On Tuesday, June 28, 2016 at 5:03:08 PM UTC+12, Ben Finney wrote:
>> There is a clever one-line decorator that has been copy-pasted without
>> explanation in many code bases for many years::
>>
>> decorator_with_args = lambda decorator: lambda *args, **kwargs:
>> lambda func: decorator(func, *args, **kwargs)
>>
>> My problem with this is precisely that it is clever: it explains nothing
>> about what it does, has many moving parts that are not named, it is
>> non-obvious and lacks expressiveness.
>
> It is written in a somewhat roundabout way: why not just
>
> decorator_with_args = lambda decorator, *args, **kwargs : lambda func
> : decorator(func, *args, **kwargs)
>
> ? Could it be this was not valid in earlier versions of Python?
Your version has a much inferior API than the original. You can't wrap your
decorators ahead of time, you have to keep calling decorator_with_args each
time you want to use them. Contrast your version:
# LDO's version
import functools
decorator_with_args = (
lambda decorator, *args, **kwargs :
lambda func : decorator(func, *args, **kwargs)
)
def chatty(func, name, age, verbose=True):
if verbose:
print("decorating function...")
@functools.wraps(func)
def inner(*args, **kwargs):
print("Hi, my name is %s and I am %d years old!" % (name, age))
return func(*args, **kwargs)
return inner
@decorator_with_args(chatty, "Bob", 99)
def calculate(x, y, z=1):
return x+y-z
@decorator_with_args(chatty, "Sue", 35, False)
def spam(n):
return ' '.join(['spam']*n)
Here's the original. It's a much better API, as the decorator "chatty" only
needs to be wrapped once, rather than repeatedly. For a library, it means
that now you can expose "chatty" as a public function, and keep
decorator_with_args as an internal detail, instead of needing to make them
both public:
# original meta decorator version
import functools
decorator_with_args = (
lambda decorator:
lambda *args, **kwargs:
lambda func: decorator(func, *args, **kwargs)
)
@decorator_with_args
def chatty(func, name, age, verbose=True):
if verbose:
print("decorating function...")
@functools.wraps(func)
def inner(*args, **kwargs):
print("Hi, my name is %s and I am %d years old!" % (name, age))
return func(*args, **kwargs)
return inner
@chatty("Bob", 99)
def calculate(x, y, z=1):
return x+y-z
@chatty("Sue", 35, False)
def spam(n):
return ' '.join(['spam']*n)
Think of the use-case where you are the author of a library that provides
various decorators. `decorator_with_args` is an implementation detail of
your library: *you* say:
@decorator_with_args
def chatty(func, name, age, verbose=True): ...
@decorator_with_args
def logged(func, where_to_log): ...
@decorator_with_args
def memoise(func, cache_size): ...
and then offer chatty, logged and memoise as public functions to the users
of your library, who just write:
@memoise(1000)
def myfunc(arg): ...
etc. as needed. But with your version, you have to make decorator_with_args
a public part of the API, and require the user to write:
@decorator_with_args(memoise, 1000)
def myfunc(arg): ...
which I maintain is a much inferior API for the users of your library.
> I don’t know why this fear and suspicion of lambdas is so widespread among
> Python users ... former Java/C# programmers, perhaps?
Not so much fear as a little healthy respect for them, I think.
--
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
Errors in installation of matplotlib and pandas on Macbook
Hello everyone, I am very new to Macbook and python. I have installed python through MacPorts and when I check if all the packages I required are installed properly, I get the following traceback errors for matplotlib and pandas packages. Can anyone suggest me how I can rectify the same? I tried to check the file "/usr/local/lib/python2.7/site-packages/matplotlib/__init__.py" using vim command but it is empty. Please suggest me ... Bomidis-MacBook-Pro:~ madhavan$ which python /usr/local/bin/python Bomidis-MacBook-Pro:~ madhavan$ which ipython /usr/local/bin/ipython Bomidis-MacBook-Pro:~ madhavan$ python -V Python 2.7.11 Bomidis-MacBook-Pro:~ madhavan$ python Python 2.7.11 (default, Jun 17 2016, 20:01:51) [GCC 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import numpy >>> print(numpy.version.full_version) 1.11.1 >>> import scipy >>> print(scipy.version.full_version) 0.17.1 >>> import netCDF4 >>> import h5py >>> import nltk >>> import matplotlib Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python2.7/site-packages/matplotlib/__init__.py", line 1131, in rcParams = rc_params() File "/usr/local/lib/python2.7/site-packages/matplotlib/__init__.py", line 975, in rc_params return rc_params_from_file(fname, fail_on_error) File "/usr/local/lib/python2.7/site-packages/matplotlib/__init__.py", line 1100, in rc_params_from_file config_from_file = _rc_params_in_file(fname, fail_on_error) File "/usr/local/lib/python2.7/site-packages/matplotlib/__init__.py", line 1018, in _rc_params_in_file with _open_file_or_url(fname) as fd: File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/contextlib.py", line 17, in __enter__ return self.gen.next() File "/usr/local/lib/python2.7/site-packages/matplotlib/__init__.py", line 1000, in _open_file_or_url encoding = locale.getdefaultlocale()[1] File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py", line 543, in getdefaultlocale return _parse_localename(localename) File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py", line 475, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: UTF-8 >>> import pandas Traceback (most recent call last): File "", line 1, in File "/Library/Python/2.7/site-packages/pandas/__init__.py", line 39, in from pandas.core.api import * File "/Library/Python/2.7/site-packages/pandas/core/api.py", line 10, in from pandas.core.groupby import Grouper File "/Library/Python/2.7/site-packages/pandas/core/groupby.py", line 18, in from pandas.core.frame import DataFrame File "/Library/Python/2.7/site-packages/pandas/core/frame.py", line 39, in from pandas.core.series import Series File "/Library/Python/2.7/site-packages/pandas/core/series.py", line 2944, in import pandas.tools.plotting as _gfx # noqa File "/Library/Python/2.7/site-packages/pandas/tools/plotting.py", line 27, in import pandas.tseries.converter as conv File "/Library/Python/2.7/site-packages/pandas/tseries/converter.py", line 7, in import matplotlib.units as units File "/usr/local/lib/python2.7/site-packages/matplotlib/__init__.py", line 1131, in rcParams = rc_params() File "/usr/local/lib/python2.7/site-packages/matplotlib/__init__.py", line 975, in rc_params return rc_params_from_file(fname, fail_on_error) File "/usr/local/lib/python2.7/site-packages/matplotlib/__init__.py", line 1100, in rc_params_from_file config_from_file = _rc_params_in_file(fname, fail_on_error) File "/usr/local/lib/python2.7/site-packages/matplotlib/__init__.py", line 1018, in _rc_params_in_file with _open_file_or_url(fname) as fd: File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/contextlib.py", line 17, in __enter__ return self.gen.next() File "/usr/local/lib/python2.7/site-packages/matplotlib/__init__.py", line 1000, in _open_file_or_url encoding = locale.getdefaultlocale()[1] File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py", line 543, in getdefaultlocale return _parse_localename(localename) File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py", line 475, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: UTF-8 Look forward to your response, Thanks and regards, Madhavan -- https://mail.python.org/mailman/listinfo/python-list
Re: "for/while ... break(by any means) ... else" make sense?
On Wed, Jun 29, 2016, at 22:26, Rustom Mody wrote: > > os.kill(os.getpid(), 9) > > > > Now THAT is the hardest way to abort. You ain't comin' back from > > this one! > > Is it? > > | On Windows, signal() can only be called with SIGABRT, SIGFPE, > | SIGILL, SIGINT, SIGSEGV, or SIGTERM. A ValueError will be raised in > | any other case. And SIGBREAK (it being missing from this list is a doc bug). > from https://docs.python.org/3.5/library/signal.html > > 9 may still work?? Dunno... That's signal, not kill. You can call kill on Windows with any integer. Only CTRL_C_EVENT and CTRL_BREAK_EVENT (which aren't, AIUI, equal to SIGINT and SIGBREAK, which is unfortunate for cross-platform code) do anything interesting, the rest call TerminateProcess with the given value. -- https://mail.python.org/mailman/listinfo/python-list
Re: Errors in installation of matplotlib and pandas on Macbook
On Thursday, June 30, 2016 at 3:51:56 PM UTC+12, Madhavan Bomidi wrote: > Bomidis-MacBook-Pro:~ madhavan$ which python > /usr/local/bin/python Apple already includes a(n obsolete) version of Python with its OS. Trying to override this with a newer version could easily lead to conflicts. -- https://mail.python.org/mailman/listinfo/python-list
Re: "for/while ... break(by any means) ... else" make sense?
On Thu, 30 Jun 2016 11:28 am, Chris Angelico wrote: > On Thu, Jun 30, 2016 at 10:27 AM, Steven D'Aprano > wrote: >> Following os.abort(), the interpreter exits in the hardest, quickest >> manner possible. > > os.kill(os.getpid(), 9) > > Now THAT is the hardest way to abort. You ain't comin' back from this one! The docs say it will abort in the hardest way possible, by dumping core or equivalent. I *think* I recall seeing os.abort() actually segfault at some point, but I can't replicate that now. I tried to find the actual implementation of os.abort(), but I couldn't work out where it was or what it does. Can somebody enlighten me? -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Errors in installation of matplotlib and pandas on Macbook
Can you please suggest me what I shall do to make sure all the libraries that I have indicated above work in python? I don't know how I can get back to obsolete version of Python. Please suggest me the commands or references of previous posts, if any. Thanks and regards, Madhavan -- https://mail.python.org/mailman/listinfo/python-list
Re: "for/while ... break(by any means) ... else" make sense?
On Thu, Jun 30, 2016 at 2:12 PM, Steven D'Aprano wrote: > On Thu, 30 Jun 2016 11:28 am, Chris Angelico wrote: > >> On Thu, Jun 30, 2016 at 10:27 AM, Steven D'Aprano >> wrote: >>> Following os.abort(), the interpreter exits in the hardest, quickest >>> manner possible. >> >> os.kill(os.getpid(), 9) >> >> Now THAT is the hardest way to abort. You ain't comin' back from this one! > > The docs say it will abort in the hardest way possible, by dumping core or > equivalent. I *think* I recall seeing os.abort() actually segfault at some > point, but I can't replicate that now. > > I tried to find the actual implementation of os.abort(), but I couldn't work > out where it was or what it does. Can somebody enlighten me? My expectation is that it'd be something like this: def abort(): if sys.platform == 'windows': some_win32_api_call() signal.signal(signal.SIGABRT, signal.SIG_DFL) kill(getpid(), signal.SIGABRT) Certainly, after a call to os.abort() under Linux, the process is recorded as having terminated with signal 6 (SIGABRT), and the intended purpose of that signal is "abort the process abnormally, possibly dumping core". ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: "for/while ... break(by any means) ... else" make sense?
On Wed, Jun 29, 2016 at 11:12 PM, Steven D'Aprano wrote:
> On Thu, 30 Jun 2016 11:28 am, Chris Angelico wrote:
>
>> On Thu, Jun 30, 2016 at 10:27 AM, Steven D'Aprano
>> wrote:
>>> Following os.abort(), the interpreter exits in the hardest, quickest
>>> manner possible.
>>
>> os.kill(os.getpid(), 9)
>>
>> Now THAT is the hardest way to abort. You ain't comin' back from this one!
>
> The docs say it will abort in the hardest way possible, by dumping core or
> equivalent. I *think* I recall seeing os.abort() actually segfault at some
> point, but I can't replicate that now.
>
> I tried to find the actual implementation of os.abort(), but I couldn't work
> out where it was or what it does. Can somebody enlighten me?
Right here:
https://hg.python.org/cpython/file/default/Modules/posixmodule.c#l10528
Here's the entire implementation of os.abort:
{
abort();
/*NOTREACHED*/
Py_FatalError("abort() called from Python code didn't abort!");
return NULL;
}
abort(3) is a standard C function, see the manpage. If execution
somehow makes it past the abort() call, Python does its best to make
sure it really doesn't by calling Py_FatalError, which dumps a scary
message to stderr along with any traceback it can get its hands on,
then calls abort() again. I tried setting a signal handler for
SIGABRT (I tried `signal.signal(signal.SIGABRT, print)`), but it
didn't trigger a Py_FatalError call on OSX or Linux.
On Windows, abort() causes the "some.exe has stopped working" dialog
to pop up and "search for solutions". Similarly, the Crash Reporter
pops up on OSX.
--
Zach
--
https://mail.python.org/mailman/listinfo/python-list
Re: Errors in installation of matplotlib and pandas on Macbook
On Thu, Jun 30, 2016 at 1:51 PM, Madhavan Bomidi wrote: > File > "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py", > line 475, in _parse_localename > raise ValueError, 'unknown locale: %s' % localename > ValueError: unknown locale: UTF-8 This looks like a problem in your environment. "UTF-8" is not a locale; usually you'll want something else first. For me, it's "en_AU.utf8" (although I believe UTF-8 works fine in place of utf8). What language do you primarily speak, and what country are you in? Put their two-letter codes together, and you'll get something like "en_US.utf8" (English, USA), or "tr_TR.utf8" (Turkish, Turkey), or "pt_BR.utf8" (Portuguese, Brazil). Once you know what locale you want to be using, though, you'll need someone who knows Macs to help you select that appropriately. Worst case, run this command before starting Python: export LC_ALL=en_AU.utf8 That may help. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
How to extract error information after failing to call Py_initialize()
Hello Experts,
I sent my issue to Python help email list. Matt from that list suggested me to
ask help from "Python list".
The link described how to get error information from Python after Python is
initialized. It didn't meet my requirement.
http://mateusz.loskot.net/posts/2011/12/01/python-sys-stdout-redirection-in-cpp/index.html
Thanks,
Marshal
发件人: Tu Marshal
发送时间: 2016年6月29日 18:31
收件人: h...@python.org
主题: How to extract error information after failing to call Py_initialize()
Hello Experts,
Our windows application is using Python C API. But some customers reported our
application crashed during Python initialization. Unfortunately we cannot
reproduce the issue.
We are thinking if we dump more error information to the crash report so that
we can narrow the issue down. I did some experiment to redirect stderr streame
to file so that I can get the error information back. But the piece of codes
don't seem to work. In Python initialize method, the stderr would be redirected
to "a preliminary stderr printer" from comments. Any ideas?
int main()
{
FILE* stream = freopen("stderr.txt", "w", stderr);
Py_Initialize();
fclose(stream);
}
Thanks,
Marshal
--
https://mail.python.org/mailman/listinfo/python-list
Re: "for/while ... break(by any means) ... else" make sense?
On Thu, Jun 30, 2016, at 00:12, Steven D'Aprano wrote: > I tried to find the actual implementation of os.abort(), but I > couldn't work out where it was or what it does. Can somebody > enlighten me? It's in posixmodule.c, it calls abort(), which is a standard C function, equivalent to killing the process with SIGABRT. The core dump behavior is defined as the default signal behavior as SIGABRT in POSIX. Windows has its own additional behavior for the abort function: https://msdn.microsoft.com/en-us/library/k089yyh0.aspx It's not a "segfault", but both behaviors (core dump on unix, and error reporting popup on windows) are reminiscent of it, so that may be what you're thinking of. -- https://mail.python.org/mailman/listinfo/python-list
Re: Errors in installation of matplotlib and pandas on Macbook
Hello ChrisA, Thanks for your suggestion. My script works fine when I run the command 'export LC_ALL=en_AU.utf8' before starting python. I am from India and using US English and international keyboard. I also tried using the command 'export LC_ALL=en_USA.utf8' and the python script works fine. How can I avoid running this command everytime when I want to start Python? Can I add the following two lines to .bash_profile? export LC_CTYPE=en_US.utf8 export LC_ALL=en_US.utf8 Look forward to your response. Thanking you in advance, Madhavan -- https://mail.python.org/mailman/listinfo/python-list
Re: Errors in installation of matplotlib and pandas on Macbook
On Thu, Jun 30, 2016 at 3:54 PM, Madhavan Bomidi wrote: > > Thanks for your suggestion. My script works fine when I run the command > 'export LC_ALL=en_AU.utf8' before starting python. > > I am from India and using US English and international keyboard. I also tried > using the command 'export LC_ALL=en_USA.utf8' and the python script works > fine. How can I avoid running this command everytime when I want to start > Python? > > Can I add the following two lines to .bash_profile? > > export LC_CTYPE=en_US.utf8 > export LC_ALL=en_US.utf8 That would possibly work, but more likely, there'll be some way in your Mac's configuration/settings menus to set your locale. If you get that set correctly, you should be able to leave those lines out of your .bash_profile and still have everything work. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Can math.atan2 return INF?
Marko Rauhamaa wrote: By the time the event horizon hits Tim at the speed of light, Tim will have received all of our Universe's signals at an ever accelerating frequency and increasing power. He will have seen the End of the World before leaving it. I don't think that's right. From the point of view of an infalling observer, nothing particularly special happens at the event horizon. Being able to see into the future would count as rather special, I would have thought. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Errors in installation of matplotlib and pandas on Macbook
Hello ChrisA, Thanks for your suggestion. I have typed the following on Terminal: $ locale LANG= LC_COLLATE="C" LC_CTYPE="C" LC_MESSAGES="C" LC_MONETARY="C" LC_NUMERIC="C" LC_TIME="C" LC_ALL="C" How should I modify the profile/configuration of locale permanently? Is it possible to do this on terminal other than using 'export' command always and including the commands in .bash_profile? How does this locale configuration affect other processes or software on the Macbook? I also get another problem with selfupdate of Mac port. Below is the error message. Is this a problem of configuration in the locale? -- $ port -v selfupdate ---> Updating MacPorts base sources using rsync rsync: failed to connect to rsync.macports.org: Operation timed out (60) rsync error: error in socket IO (code 10) at /BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-47/rsync/clientserver.c(105) [receiver=2.6.9] Command failed: /usr/bin/rsync -rtzv --delete-after rsync://rsync.macports.org/release/tarballs/base.tar /opt/local/var/macports/sources/rsync.macports.org/release/tarballs Exit code: 10 Error: Error synchronizing MacPorts sources: command execution failed To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets Error: /opt/local/bin/port: port selfupdate failed: Error synchronizing MacPorts sources: command execution failed --- Look forward to your response, Thanks and regards, Madhavan -- https://mail.python.org/mailman/listinfo/python-list
Re: Assignment Versus Equality
Gregory Ewing : > All your experiment shows is that the last information we had about > the magnet is that it was nearly stationary just above the horizon. > > It doesn't prove that the probe itself is frozen, any more than the > fact that a photograph you took of something last month doesn't move > proves that the object you photographed is stuck in the state it was > in a month ago. Interaction defines scientific reality. Things that don't interact don't exist. Call it cosmic duck-typing: you are what you appear to be. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Can math.atan2 return INF?
Lawrence D’Oliveiro : > Every time somebody tries to point to an example of a “topic that is > beyond the reach of science”, it seems to get knocked over eventually. Of course, an experiment trumps theory, always. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Can math.atan2 return INF?
On Thursday, June 30, 2016 at 11:54:54 AM UTC+5:30, Marko Rauhamaa wrote: > Lawrence D’Oliveiro : > > Every time somebody tries to point to an example of a “topic that is > > beyond the reach of science”, it seems to get knocked over eventually. > > Of course, an experiment trumps theory, always. The scholastics would call the question: "How many angels can dance on a pin" a 'thought-experiment' -- https://mail.python.org/mailman/listinfo/python-list
Re: Can math.atan2 return INF?
Gregory Ewing : > Marko Rauhamaa wrote: >> By the time the event horizon hits Tim at the speed of light, Tim will >> have received all of our Universe's signals at an ever accelerating >> frequency and increasing power. He will have seen the End of the World >> before leaving it. > > I don't think that's right. From the point of view of an infalling > observer, nothing particularly special happens at the event horizon. > Being able to see into the future would count as rather special, I > would have thought. Yeah, you have a point: IF you could stand still, you would see light from behind as blue-shifted, precisely the flip side of gravitational redshifting for distant observers. However, if you were traveling on a free-fall geodesic, you would see no blueshift from light directly behind, because you and it would be in the same inertial reference frame. http://physics.stackexchange.com/questions/26185/what-will-th e-universe-look-like-for-anyone-falling-into-a-black-hole> Marko -- https://mail.python.org/mailman/listinfo/python-list
