Paul Rubin :
> This takes about 4 seconds on a Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz
> laptop (64 bit linux):
Converted to Python3:
#!/usr/bin/env python3
import itertools, time
def candidates():
yield 2
yield 3
On Sat, 11 Apr 2015 12:23 pm, Dave Angel wrote:
> On 04/10/2015 09:42 PM, Steven D'Aprano wrote:
>> On Sat, 11 Apr 2015 05:31 am, sohcahto...@gmail.com wrote:
>>
>>> It isn't document because it is expected. Why would the exception get
>>> caught if you're not writing code to catch it? If you wr
On Sat, 11 Apr 2015 04:08 pm, Paul Rubin wrote:
> Steven D'Aprano writes:
>> It may be a bit slow for very large numbers. On my computer, this takes
>> 20 seconds:
>> py> pyprimes.factors.factorise(2**111+1)
>> [3, 3, 1777, 3331, 17539, 25781083, 107775231312019L]
>
> This takes about 4 seconds
On 11.04.15 10:11, Steven D'Aprano wrote:
Anyway, in modern Python (2.6 onwards), now that string exceptions are gone,
you can supply something to catch everything. Or nothing, for that matter:
BaseException # catch everything
Not everything.
>>> class A: pass
...
>>> try: raise A
... except
Den lördag 11 april 2015 kl. 09:35:22 UTC+2 skrev Steven D'Aprano:
> On Sat, 11 Apr 2015 04:08 pm, Paul Rubin wrote:
>
> > Steven D'Aprano writes:
> >> It may be a bit slow for very large numbers. On my computer, this takes
> >> 20 seconds:
> >> py> pyprimes.factors.factorise(2**111+1)
> >> [3, 3
On 4/10/2015 9:42 PM, Steven D'Aprano wrote:
try:
spam()
except:
# Implicitly an empty tuple.
pass
No, specified as equivalent to 'except BaseException:' (or 'except
(BaseException,):', either of which are different from 'except ():'.
"An expression-less except clause, if prese
$ python2
Python 2.7.8 (default, Oct 20 2014, 15:05:19)
[GCC 4.9.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = 256
>>> b = 256
>>> a is b
True
>>> a = 257
>>> b = 257
>>> a is b
False
>>>
It's not safe to use 'is' to compare integers.
Use ==
--
htt
On 10Apr2015 19:38, Rustom Mody wrote:
On Saturday, April 11, 2015 at 7:53:31 AM UTC+5:30, Dave Angel wrote:
On 04/10/2015 09:42 PM, Steven D'Aprano wrote:
> On Sat, 11 Apr 2015 05:31 am, sohcahtoa82 wrote:
>> It isn't document because it is expected. Why would the exception get
>> caught if y
On 04/11/2015 03:11 AM, Steven D'Aprano wrote:
On Sat, 11 Apr 2015 12:23 pm, Dave Angel wrote:
On 04/10/2015 09:42 PM, Steven D'Aprano wrote:
On Sat, 11 Apr 2015 05:31 am, sohcahto...@gmail.com wrote:
It isn't document because it is expected. Why would the exception get
caught if you're not
On 04/11/2015 06:14 AM, Dave Angel wrote:
On 04/11/2015 03:11 AM, Steven D'Aprano wrote:
On Sat, 11 Apr 2015 12:23 pm, Dave Angel wrote:
On 04/10/2015 09:42 PM, Steven D'Aprano wrote:
On Sat, 11 Apr 2015 05:31 am, sohcahto...@gmail.com wrote:
It isn't document because it is expected. Why w
On Sat, 11 Apr 2015 04:50 pm, Palpandi wrote:
> Hi all,
>
> Can anyone explain about the dependency injection concept in python?
>
> I have a class A. A is used in all other classes(B, C, D, ..). Is it good
> to use dependency injection concept in this situation or else any other
> suggestions?
On Sat, 11 Apr 2015 06:22 pm, Serhiy Storchaka wrote:
> On 11.04.15 10:11, Steven D'Aprano wrote:
>> Anyway, in modern Python (2.6 onwards), now that string exceptions are
>> gone, you can supply something to catch everything. Or nothing, for that
>> matter:
>>
>> BaseException # catch everything
On Sat, 11 Apr 2015 07:27 pm, Cameron Simpson wrote:
> If the empty tuple were to mean "catch everything" then there would not be
> a way to express "catch nothing". Bad bad bad!
# Catch everything:
try:
spam()
except:
pass
# Catch nothing:
spam()
:-)
> Consider this a proof that Py
On Sat, Apr 11, 2015 at 9:00 PM, Steven D'Aprano
wrote:
> Yes, I agree that Python's behaviour here is better than the alternative.
> Having "except ()" catch nothing is consistent with the behaviour with
> other tuples, so I'm okay with that. But it still surprised me :-)
It's worth noting that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/04/15 08:11, Steven D'Aprano wrote:
> But with try...except, an empty exception list means to catch
> *everything*, not nothing:
>
> try: ... except a,b,c: # catches a, b, c
>
> try: ... except a,b: # catches a, b
This example is incorrect. In
If two functions crossreference eachother back and forth what happen with the
local variables.
Will there be a new instance of function holding the variables or do they get
messed up?
--
https://mail.python.org/mailman/listinfo/python-list
On Sun, Apr 12, 2015 at 1:00 AM, wrote:
> If two functions crossreference eachother back and forth what happen with the
> local variables.
>
> Will there be a new instance of function holding the variables or do they get
> messed up?
You mean if one function calls another, and that function ca
Den lördag 11 april 2015 kl. 17:16:09 UTC+2 skrev Chris Angelico:
> On Sun, Apr 12, 2015 at 1:00 AM, wrote:
> > If two functions crossreference eachother back and forth what happen with
> > the local variables.
> >
> > Will there be a new instance of function holding the variables or do they
>
On Sun, Apr 12, 2015 at 1:22 AM, wrote:
> Thanks i was worried, i try to make a generic base choice algorithm that
> should work for anybase, and i just realised that the bignumb add would need
> to call the bignumb subtraction and viceversa. I thought there may be
> instances but i was not su
On Sun, 12 Apr 2015 01:00 am, jonas.thornv...@gmail.com wrote:
> If two functions crossreference eachother back and forth what happen with
> the local variables.
Nothing. They are local to the function that creates them.
> Will there be a new instance of function holding the variables or do the
Den lördag 11 april 2015 kl. 17:26:03 UTC+2 skrev Steven D'Aprano:
> On Sun, 12 Apr 2015 01:00 am, jonas.thornv...@gmail.com wrote:
>
> > If two functions crossreference eachother back and forth what happen with
> > the local variables.
>
> Nothing. They are local to the function that creates the
Chris Angelico wrote:
> The 'x' inside each function is completely separate, no matter how
> many times they get called. They're usually stored on something called
> a "call stack" - you put another sheet of paper on top of the stack
> every time you call a function, local variables are all writte
Steven D'Aprano writes:
> [3, 3, 3, 3, 7, 19, 73, 87211, 262657, 1.4411518807585587e+17]
> Oops, you have a float in there, how did that happen?
Looks like you are using a broken version of Python.
--
https://mail.python.org/mailman/listinfo/python-list
Marko Rauhamaa writes:
> This is slightly faster:...
> def fac(n):
> for c in range(n):
> if c*c > n: ...
That's interesting and says something bad about generators in Python 3.
It's doing 3 times as many trial divisions as the version I posted, and
it's still faster?
xrange in Pytho
Dennis Lee Bieber writes:
>>Oops, you have a float in there, how did that happen?
> Off the top of my head -- I'd suspect an older version of Python that
> promoted 2**111 to a double, rather than to a Long-Int.
No he's being a wise guy. The /= returned a float result in Python 3
after the
Thank you all. I learned a lot.
--
https://mail.python.org/mailman/listinfo/python-list
Paul Rubin :
> Marko Rauhamaa writes:
>> This is slightly faster:...
>> def fac(n):
>> for c in range(n):
>> if c*c > n: ...
>
> That's interesting and says something bad about generators in Python
> 3. It's doing 3 times as many trial divisions as the version I posted,
> and it's sti
Marko Rauhamaa writes:
> I think it mostly says divisions are not so evil as you think they might
> be.
They are bignum divisions which are much more expensive than machine
divisions. And it's not just the divisions, it's also the number of
iterations through the whole loop. And the Python 2 vs
On 4/11/2015 12:23 PM, Thomas 'PointedEars' Lahn wrote:
Chris Angelico wrote:
The 'x' inside each function is completely separate, no matter how
many times they get called. They're usually stored on something called
a "call stack" - you put another sheet of paper on top of the stack
every time
On Apr 11, 2015 5:06 AM, "Steven D'Aprano" <
steve+comp.lang.pyt...@pearwood.info> wrote:
>
> Yes, I agree that Python's behaviour here is better than the alternative.
> Having "except ()" catch nothing is consistent with the behaviour with
> other tuples, so I'm okay with that. But it still surpri
Terry Reedy wrote:
> On 4/11/2015 12:23 PM, Thomas 'PointedEars' Lahn wrote:
>> Chris Angelico wrote:
>>> The 'x' inside each function is completely separate, no matter how
>>> many times they get called. They're usually stored on something called
>>> a "call stack" - you put another sheet of pape
On Sun, Apr 12, 2015 at 4:49 AM, Ian Kelly wrote:
> On Apr 11, 2015 5:06 AM, "Steven D'Aprano"
> wrote:
>>
>> Yes, I agree that Python's behaviour here is better than the alternative.
>> Having "except ()" catch nothing is consistent with the behaviour with
>> other tuples, so I'm okay with that.
On Sun, Apr 12, 2015 at 6:04 AM, Chris Angelico wrote:
> On Sun, Apr 12, 2015 at 4:49 AM, Ian Kelly wrote:
>> On Apr 11, 2015 5:06 AM, "Steven D'Aprano"
>> wrote:
>>>
>>> Yes, I agree that Python's behaviour here is better than the alternative.
>>> Having "except ()" catch nothing is consistent
On Sun, Apr 12, 2015 at 3:52 AM, Paul Rubin wrote:
>> PS Note that you're being "wasteful" by multiplying c*c over and over
>
> Yeah this is a reasonable point, though most of the c's should fit in a
> machine word, at least in my 64-bit system. I think Python still
> separates ints and longs in
On 4/11/2015 3:19 PM, Thomas 'PointedEars' Lahn wrote:
Terry Reedy wrote:
On 4/11/2015 12:23 PM, Thomas 'PointedEars' Lahn wrote:
Chris Angelico wrote:
The 'x' inside each function is completely separate, no matter how
many times they get called. They're usually stored on something called
a "
On 11Apr2015 21:21, Chris Angelico wrote:
But I agree, it would be very nice if Python 3 could have abolished
the truly confusing part of this, where "except:" catches everything.
Forcing people to spell it "except BaseException:" would fix all of
this. How hard is it to deprecate and then remov
On Sun, Apr 12, 2015 at 7:37 AM, Cameron Simpson wrote:
> On 11Apr2015 21:21, Chris Angelico wrote:
>>
>> But I agree, it would be very nice if Python 3 could have abolished
>> the truly confusing part of this, where "except:" catches everything.
>> Forcing people to spell it "except BaseExceptio
Terry Reedy wrote:
> On 4/11/2015 3:19 PM, Thomas 'PointedEars' Lahn wrote:
>> Terry Reedy wrote:
>>> What Chris is describing is one local namespace (sheet of paper) per
>>> function *call*.
>> I *know* what he is describing: the *call* stack.
>
> My comment above was directed not at you specifi
On 12Apr2015 07:52, Chris Angelico wrote:
On Sun, Apr 12, 2015 at 7:37 AM, Cameron Simpson wrote:
On 11Apr2015 21:21, Chris Angelico wrote:
But I agree, it would be very nice if Python 3 could have abolished
the truly confusing part of this, where "except:" catches everything.
Forcing people
Am Samstag, 11. April 2015 09:14:50 UTC+2 schrieb Marko Rauhamaa:
> Paul Rubin :
>
> > This takes about 4 seconds on a Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz
> > laptop (64 bit linux):
>
> Converted to Python3:
>
> #!/usr/
On Sun, Apr 12, 2015 at 9:08 AM, Cameron Simpson wrote:
> Catching all exceptions isn't terribly common, _except_ in service routines
> that wrap "unknown" operations. Classic example from my Asynchron class:
>
>def call(self, func, *a, **kw):
> ''' Have the Asynchron call `func(*a,**kw)`
On 4/11/2015 5:10 PM, Chris Angelico wrote:
On Sun, Apr 12, 2015 at 3:52 AM, Paul Rubin wrote:
PS Note that you're being "wasteful" by multiplying c*c over and over
Yeah this is a reasonable point, though most of the c's should fit in a
machine word, at least in my 64-bit system. I think Pyt
On Sun, Apr 12, 2015 at 9:58 AM, Terry Reedy wrote:
> I believe longobject effectively represents ints in base 2**15 or 2**30 (or
> 31?) for 32 and 64 bit machines, so that products of 'digits' fit in a
> single machine word. (I am not sure if the increased size for 64 bit
> machines was implemen
I want to create graphs with using collusion API from annotated text
has anyone used the api? do you have any better suggestion too?
--
https://mail.python.org/mailman/listinfo/python-list
On Sun, 12 Apr 2015 02:31 am, Paul Rubin wrote:
> Steven D'Aprano writes:
>> [3, 3, 3, 3, 7, 19, 73, 87211, 262657, 1.4411518807585587e+17]
>> Oops, you have a float in there, how did that happen?
>
> Looks like you are using a broken version of Python.
Well, we know about people who blame thei
On Sun, 12 Apr 2015 07:37 am, Cameron Simpson wrote:
> On 11Apr2015 21:21, Chris Angelico wrote:
>>But I agree, it would be very nice if Python 3 could have abolished
>>the truly confusing part of this, where "except:" catches everything.
>>Forcing people to spell it "except BaseException:" would
On Sun, 12 Apr 2015 09:08 am, Cameron Simpson wrote:
> Also, IMO, a bare "except:" syntax is far more pleasing to the eye than
> "except magic_exception_name_that+gets_everything:".
And that is exactly what makes bare excepts an attractive nuisance!
I'm going to channel a newbie, cowboy or just
Steven D'Aprano writes:
> Ah, the penny drops! Are you using Python 2.7 with old-style division? That
> would explain it.
Yes, see also the use of the print statement in that post. I'm
surprised the code compiled at all in Python 3.
> Nice! Except that your fac() function has a bug: it includes
On Sun, 12 Apr 2015 02:24 pm, Paul Rubin wrote:
> Steven D'Aprano writes:
>> Ah, the penny drops! Are you using Python 2.7 with old-style division?
>> That would explain it.
>
> Yes, see also the use of the print statement in that post. I'm
> surprised the code compiled at all in Python 3.
I w
Thomas, before I reply to your comment, I have a meta-comment to make.
Your signature says "Please do not cc me. / Bitte keine Kopien per E-Mail."
which suggests that you do not want to be emailed. But your post included
an explicit "Mail-Copies-To: use...@pointedears.de" header which compliant
ne
On 12Apr2015 09:21, Chris Angelico wrote:
On Sun, Apr 12, 2015 at 9:08 AM, Cameron Simpson wrote:
Catching all exceptions isn't terribly common, _except_ in service routines
that wrap "unknown" operations. Classic example from my Asynchron class: [...]
try:
r = func(*a, **kw)
On 12Apr2015 16:33, Cameron Simpson wrote:
Finally, if we were to expunge support for "except:", one would also need a
cast iron guarrentee that no exception could possibly occur which was not a
subclass of BaseException. I'd expect that to mean that "raise" of a
non-instance of BaseException
On 12Apr2015 14:18, Steven D'Aprano
wrote:
On Sun, 12 Apr 2015 09:08 am, Cameron Simpson wrote:
Also, IMO, a bare "except:" syntax is far more pleasing to the eye than
"except magic_exception_name_that+gets_everything:".
And that is exactly what makes bare excepts an attractive nuisance!
I'
53 matches
Mail list logo
