Kirill Balunov writes:
> I am a little bit confused with `locals` builtin in these moments:
>
> 1. The documentation says that _free varaibles_ are returned, which seems
> incorrect description. In my mind the term free variable refers to
> variables used in a function that are not local variables
Steven D'Aprano writes:
> Interesting, I'll certainly have a good read of that, thanks. But I
> fear I mislead you: you seem to have understood that either all the
> parameters are None, or none of them are, whereas what I meant was
> that they can vary independently of each other.
I think that
On Tue, 27 Feb 2018 09:15:12 +1100, Ben Finney wrote:
> Steven D'Aprano writes:
>
>> I have a class with a large number of parameters (about ten) assigned
>> in `__init__`. The class then has a number of methods which accept
>> *optional* arguments with the same names as the constructor/initiali
On Mon, 26 Feb 2018 16:23:39 -0800, Rick Johnson wrote:
> On Monday, February 26, 2018 at 5:44:18 PM UTC-6, MRAB wrote: [...]
>> Before using or'd-logic, you need to know whether the value could be
>> falsey, e.g. 0.
>
> True. However. Steven failed to provide any info that might help us
> determ
On Mon, 26 Feb 2018 17:39:43 +0100, Peter Otten wrote:
[...]
> I have not yet looked into dataclasses. Don't they handle the __init__()
> part? Anyway, here's my attempt to make spam() less spammy:
I'm not too concerned about __init__, it's only one method :-)
> $ cat attrs_to_args_decorator.p
On Mon, Feb 26, 2018 at 8:55 PM, Ian Kelly wrote:
> On Mon, Feb 26, 2018 at 8:09 PM, Steven D'Aprano
> wrote:
>> Yes you did: "the last second of every year" is always 23:59:59 of 31st
>> December, and it is always the same time and date "every year".
>
> Except when it's 23:59:60 or 23:59:61 (wh
On Tue, Feb 27, 2018 at 2:55 PM, Ian Kelly wrote:
> On Mon, Feb 26, 2018 at 8:09 PM, Steven D'Aprano
> wrote:
>> Yes you did: "the last second of every year" is always 23:59:59 of 31st
>> December, and it is always the same time and date "every year".
>
> Except when it's 23:59:60 or 23:59:61 (wh
On Tue, Feb 27, 2018 at 12:18 PM, Rick Johnson
wrote:
> On Tuesday, February 20, 2018 at 5:45:36 PM UTC-6, Steven D'Aprano wrote:
>> On Tue, 20 Feb 2018 12:42:23 -0800, Rick Johnson wrote:
>>
>> > For instance, if the age is queried many times a second,
>> > it would be a much wiser design to set-
On Mon, Feb 26, 2018 at 8:09 PM, Steven D'Aprano
wrote:
> Yes you did: "the last second of every year" is always 23:59:59 of 31st
> December, and it is always the same time and date "every year".
Except when it's 23:59:60 or 23:59:61 (which hasn't yet happened but could).
--
https://mail.python.
On Mon, 26 Feb 2018 17:18:38 -0800, Rick Johnson wrote:
[...]
> So, for instance: if your birthday is January 25th 1969, the last second
> of the last day of your _first_ year is January 24th 1970 @ 11:59:59PM.
> And the last second of the last day of your _second_ year is January
> 24th 1971 @ 11
On Mon, 26 Feb 2018 17:18:38 -0800, Rick Johnson wrote:
> On Tuesday, February 20, 2018 at 5:45:36 PM UTC-6, Steven D'Aprano
> wrote:
>> On Tue, 20 Feb 2018 12:42:23 -0800, Rick Johnson wrote:
>>
>> > For instance, if the age is queried many times a second, it would be
>> > a much wiser design to
On Tue, Feb 27, 2018 at 12:57 PM, bartc wrote:
> On 27/02/2018 00:35, Chris Angelico wrote:
>>
>> On Tue, Feb 27, 2018 at 11:17 AM, Steven D'Aprano
>> wrote:
>>>
>>> On Tue, 27 Feb 2018 02:09:53 +1100, Chris Angelico wrote:
>>>
You're still reimplementing the C code in Python, which is ineff
On 27/02/2018 00:35, Chris Angelico wrote:
On Tue, Feb 27, 2018 at 11:17 AM, Steven D'Aprano
wrote:
On Tue, 27 Feb 2018 02:09:53 +1100, Chris Angelico wrote:
You're still reimplementing the C code in Python, which is inefficient.
Have you considered going back to the *actual algorithm* and
im
On Tue, 27 Feb 2018 12:25:30 +1300,
Gregory Ewing wrote:
> Seb wrote:
>> I was wondering is whether there's a faster way of multiplying each
>> row (1x3) of a matrix by another matrix (3x3), compared to looping
>> through the matrix row by row as shown in the code.
> Just multiply the two matric
On Tuesday, February 20, 2018 at 5:45:36 PM UTC-6, Steven D'Aprano wrote:
> On Tue, 20 Feb 2018 12:42:23 -0800, Rick Johnson wrote:
>
> > For instance, if the age is queried many times a second,
> > it would be a much wiser design to set-up an event that
> > will advance the age at the end of the l
On Mon, Feb 26, 2018 at 4:25 PM, Steven D'Aprano
wrote:
> On Mon, 26 Feb 2018 21:55:35 +0300, Kirill Balunov wrote:
>> 2. The documentation has a note that "The contents of this dictionary
>> should not be modified". Which implies that it is a read only mapping.
>> So the question why it is `dict`
On Tue, Feb 27, 2018 at 11:17 AM, Steven D'Aprano
wrote:
> On Tue, 27 Feb 2018 02:09:53 +1100, Chris Angelico wrote:
>
>> You're still reimplementing the C code in Python, which is inefficient.
>> Have you considered going back to the *actual algorithm* and
>> implementing that idiomatically in Py
On Tue, 27 Feb 2018 02:09:53 +1100, Chris Angelico wrote:
> You're still reimplementing the C code in Python, which is inefficient.
> Have you considered going back to the *actual algorithm* and
> implementing that idiomatically in Python? I think you'll find that (a)
> the code is more readable,
On Monday, February 26, 2018 at 5:44:18 PM UTC-6, MRAB wrote:
[...]
> Before using or'd-logic, you need to know whether the value
> could be falsey, e.g. 0.
True. However. Steven failed to provide any info that might
help us determine the types of these parameters, and as
such, i was forced to tak
On Mon, 26 Feb 2018 21:55:35 +0300, Kirill Balunov wrote:
> Hi,
>
> I am a little bit confused with `locals` builtin in these moments:
>
> 1. The documentation says that _free varaibles_ are returned, which
> seems incorrect description.
I can't answer that, sorry.
> 2. The documentation has
On 2/26/2018 1:55 PM, Kirill Balunov wrote:
Hi,
I am a little bit confused with `locals` builtin in these moments:
1. The documentation says that _free varaibles_ are returned, which seems
incorrect description. In my mind the term free variable refers to
variables used in a function that are n
On 2018-02-26 21:12, Rick Johnson wrote:
On Monday, February 26, 2018 at 8:44:14 AM UTC-6, Steven D'Aprano wrote:
I have a class with a large number of parameters (about
ten) assigned in `__init__`. The class then has a number of
methods which accept *optional* arguments with the same
names as t
Seb wrote:
I was wondering is whether there's a faster way of
multiplying each row (1x3) of a matrix by another matrix (3x3), compared
to looping through the matrix row by row as shown in the code.
Just multiply the two matrices together.
If A is an nx3 matrix and B is a 3x3 matrix, then
C = A
On Monday, February 26, 2018 at 9:40:54 AM UTC, Negru Popi wrote:
> Define 2 lists. The first one must contain the integer values 1, 2 and 3 and
> the second one the string values a, b and c. Iterate through both lists to
> create another list that contains all the combinations of the A and B
>
On Mon, Feb 26, 2018 at 3:12 PM, Dan Stromberg wrote:
> On Mon, Feb 26, 2018 at 2:07 PM, Ian Kelly wrote:
>> Taking LMGTFY to a whole new level of rudeness by obviously not even
>> bothering to read the entire paragraph before responding.
>
> Is LMGTFY rude? I think maybe it was back when it sai
Steven D'Aprano writes:
> I have a class with a large number of parameters (about ten) assigned
> in `__init__`. The class then has a number of methods which accept
> *optional* arguments with the same names as the
> constructor/initialiser parameters. If those arguments are None, the
> defaults
On Mon, Feb 26, 2018 at 2:07 PM, Ian Kelly wrote:
> On Mon, Feb 26, 2018 at 2:40 PM, Dan Stromberg wrote:
>> On Mon, Feb 26, 2018 at 8:53 AM, Seb wrote:
>>> On Sun, 25 Feb 2018 18:52:14 -0500,
>>> Terry Reedy wrote:
>>>
>>> [...]
>>>
numpy has a matrix multiply function and now the '@' mat
On Mon, Feb 26, 2018 at 2:40 PM, Dan Stromberg wrote:
> On Mon, Feb 26, 2018 at 8:53 AM, Seb wrote:
>> On Sun, 25 Feb 2018 18:52:14 -0500,
>> Terry Reedy wrote:
>>
>> [...]
>>
>>> numpy has a matrix multiply function and now the '@' matrix multiply
>>> operator.
>>
>> Yes, but what I was wonderi
On Mon, Feb 26, 2018 at 2:37 PM, Ian Kelly wrote:
> On Mon, Feb 26, 2018 at 1:09 PM, wrote:
>> def foo(self, *args, **kwargs):
>> assert len(args) == 0
>
> Better:
>
> def foo(self, **kwargs):
>
>> So, use the inspect module to detect the valid arguments
>> from the class initializer
On Mon, Feb 26, 2018 at 8:53 AM, Seb wrote:
> On Sun, 25 Feb 2018 18:52:14 -0500,
> Terry Reedy wrote:
>
> [...]
>
>> numpy has a matrix multiply function and now the '@' matrix multiply
>> operator.
>
> Yes, but what I was wondering is whether there's a faster way of
> multiplying each row (1x3)
On Mon, Feb 26, 2018 at 1:09 PM, wrote:
> def foo(self, *args, **kwargs):
> assert len(args) == 0
Better:
def foo(self, **kwargs):
> So, use the inspect module to detect the valid arguments
> from the class initializer. Then use **kwargs in every
> class method. It would be nice if
On Monday, February 26, 2018 at 8:44:14 AM UTC-6, Steven D'Aprano wrote:
> I have a class with a large number of parameters (about
> ten) assigned in `__init__`. The class then has a number of
> methods which accept *optional* arguments with the same
> names as the constructor/initialiser parameter
On Monday, February 26, 2018 at 12:57:25 PM UTC+5:30, Chris Angelico wrote:
> On Mon, Feb 26, 2018 at 5:19 AM, wrote:
> > Why we don’t use:
> >
> > for _ in _ in _
> >
> > Instead of
> >
> > for _ in _:
> > for _ in _:
> >
> > Ex:
> >
> > Names = ["Arya","Pupun"]
> >
> > for name in Names
On 26/02/2018 20:27, bartc wrote:
On 26/02/2018 19:50, Chris Angelico wrote:
On Tue, Feb 27, 2018 at 6:37 AM, Rick Johnson
So what? Latency is latency. And whether it occurs over the
course of one heavily recursive algorithm that constitutes
the depth and breadth of an entire program (a la fi
On 26/02/2018 19:50, Chris Angelico wrote:
On Tue, Feb 27, 2018 at 6:37 AM, Rick Johnson
So what? Latency is latency. And whether it occurs over the
course of one heavily recursive algorithm that constitutes
the depth and breadth of an entire program (a la fib()), or
it is the incremental cumu
On Monday, February 26, 2018 at 3:44:14 PM UTC+1, Steven D'Aprano wrote:
> I have a class with a large number of parameters (about ten) assigned in
> `__init__`. The class then has a number of methods which accept
> *optional* arguments with the same names as the constructor/initialiser
> parame
On 2018-02-26, Kirill Balunov wrote:
> Currently `str.join` raises `TypeError` if there are any non-string values
> in iterable, including `bytes` objects. Is it an awful idea to implicitly
> _cast_ elements in iterable to their `str` or `repr` representation?
Yes, that's an awful idea. PHP pul
On Tue, Feb 27, 2018 at 6:54 AM, Kirill Balunov wrote:
>> print(*iterable, sep=", ")
>
>
> Thanks, I apologize :-) and why I always manage to find complicated ways...
Hey, that's why we have the list :) I call this a success.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
>
> print(*iterable, sep=", ")
Thanks, I apologize :-) and why I always manage to find complicated ways...
With kind regards,
-gdg
2018-02-26 22:43 GMT+03:00 Chris Angelico :
> On Tue, Feb 27, 2018 at 6:38 AM, Kirill Balunov
> wrote:
> > Currently `str.join` raises `TypeError` if there are an
On Tue, Feb 27, 2018 at 6:37 AM, Rick Johnson
wrote:
> On Monday, February 26, 2018 at 4:39:22 AM UTC-6, Steven D'Aprano wrote:
>> On Sun, 25 Feb 2018 19:26:12 -0800, Rick Johnson wrote:
>>
>> > On Friday, February 23, 2018 at 8:48:55 PM UTC-6, Steven D'Aprano wrote:
>> > [...]
>> > > Take the Fib
On Tue, Feb 27, 2018 at 6:38 AM, Kirill Balunov wrote:
> Currently `str.join` raises `TypeError` if there are any non-string values
> in iterable, including `bytes` objects. Is it an awful idea to implicitly
> _cast_ elements in iterable to their `str` or `repr` representation? Was
> this question
On Monday, February 26, 2018 at 4:39:22 AM UTC-6, Steven D'Aprano wrote:
> On Sun, 25 Feb 2018 19:26:12 -0800, Rick Johnson wrote:
>
> > On Friday, February 23, 2018 at 8:48:55 PM UTC-6, Steven D'Aprano wrote:
> > [...]
> > > Take the Fibonacci double-recursion benchmark. Okay, it
> > > tests how w
Currently `str.join` raises `TypeError` if there are any non-string values
in iterable, including `bytes` objects. Is it an awful idea to implicitly
_cast_ elements in iterable to their `str` or `repr` representation? Was
this question adressed before?
As for me there are two valid points: On one
Hi,
I am a little bit confused with `locals` builtin in these moments:
1. The documentation says that _free varaibles_ are returned, which seems
incorrect description. In my mind the term free variable refers to
variables used in a function that are not local variables nor parameters of
that func
On 26/02/2018 17:05, Ben Bacarisse wrote:
bartc writes:
A C version is given below. (One I may have messed around with, which
I'm not sure works properly. For an original, google for Marsaglia and
KISS64 or SUPRKISS64.)
The version I know uses unsigned integers. Did you change then to signe
On Mon, Feb 26, 2018 at 8:06 AM, Chris Angelico wrote:
> On Tue, Feb 27, 2018 at 1:41 AM, Steven D'Aprano
> wrote:
>> I have a class with a large number of parameters (about ten) assigned in
>> `__init__`. The class then has a number of methods which accept
>> *optional* arguments with the same n
On Monday, February 26, 2018 at 6:23:24 AM UTC+5:30, Rick Johnson wrote:
> On Sunday, February 25, 2018 at 12:19:56 PM UTC-6, arya.ku...@gmail.com wrote:
>
> > Ex:
> >
> > Names = ["Arya","Pupun"]
> >
> > for name in Names:
> >for c in name:
> >print(c)
> >
> > instead use:
> >
> >
On Monday, February 26, 2018 at 6:20:06 AM UTC+5:30, Ian wrote:
> On Sun, Feb 25, 2018 at 11:19 AM, wrote:
> > Why we don’t use:
> >
> > for _ in _ in _
> >
> > Instead of
> >
> > for _ in _:
> > for _ in _:
> >
> > Ex:
> >
> > Names = ["Arya","Pupun"]
> >
> > for name in Names:
> >fo
On Monday, February 26, 2018 at 8:51:35 PM UTC+5:30, Ian wrote:
> On Sun, Feb 25, 2018 at 8:05 PM, INADA Naoki wrote:
> > https://docs.python.org/3.6/library/itertools.html#itertools.product
>
> I don't see how you would use itertools.product to do what the OP
> asked for. You could use itertools
On Monday, February 26, 2018 at 3:59:40 AM UTC-6, Steven D'Aprano wrote:
> On Sun, 25 Feb 2018 20:22:17 -0800, Rick Johnson wrote:
> (We tried painting Go Faster stripes on the server, and it
> didn't work.)
Well of course the server won't work after you drip water-
based paint all over the circu
On Mon, Feb 26, 2018 at 9:53 AM, Seb wrote:
> On Sun, 25 Feb 2018 18:52:14 -0500,
> Terry Reedy wrote:
>
> [...]
>
>> numpy has a matrix multiply function and now the '@' matrix multiply
>> operator.
>
> Yes, but what I was wondering is whether there's a faster way of
> multiplying each row (1x3)
bartc writes:
> A C version is given below. (One I may have messed around with, which
> I'm not sure works properly. For an original, google for Marsaglia and
> KISS64 or SUPRKISS64.)
The version I know uses unsigned integers. Did you change then to signed?
For a Python version, go back to the
Steven D'Aprano wrote:
> I have a class with a large number of parameters (about ten) assigned in
> `__init__`. The class then has a number of methods which accept
> *optional* arguments with the same names as the constructor/initialiser
> parameters. If those arguments are None, the defaults are
On Sun, 25 Feb 2018 18:52:14 -0500,
Terry Reedy wrote:
[...]
> numpy has a matrix multiply function and now the '@' matrix multiply
> operator.
Yes, but what I was wondering is whether there's a faster way of
multiplying each row (1x3) of a matrix by another matrix (3x3), compared
to looping th
On 26/02/2018 15:09, Chris Angelico wrote:
On Tue, Feb 27, 2018 at 2:02 AM, bartc wrote:
On 26/02/2018 14:04, bartc wrote:
On 26/02/2018 13:42, Ned Batchelder wrote:
Well, once you notice that the
Python code had N=1e5, and the C code had N=1e9 :) If you want to
experiment, with N=
On 02/26/2018 07:28 AM, Rhodri James wrote:
On 26/02/18 14:41, Steven D'Aprano wrote:
I have a class with a large number of parameters (about ten) assigned in
`__init__`. The class then has a number of methods which accept
*optional* arguments with the same names as the constructor/initialiser
p
On 2/26/18 10:09 AM, Chris Angelico wrote:
On Tue, Feb 27, 2018 at 2:02 AM, bartc wrote:
On 26/02/2018 14:04, bartc wrote:
On 26/02/2018 13:42, Ned Batchelder wrote:
Well, once you notice that the
Python code had N=1e5, and the C code had N=1e9 :) If you want to
experiment, with N=1e5
On 26/02/18 14:41, Steven D'Aprano wrote:
I have a class with a large number of parameters (about ten) assigned in
`__init__`. The class then has a number of methods which accept
*optional* arguments with the same names as the constructor/initialiser
parameters. If those arguments are None, the d
On Sun, Feb 25, 2018 at 8:05 PM, INADA Naoki wrote:
> https://docs.python.org/3.6/library/itertools.html#itertools.product
I don't see how you would use itertools.product to do what the OP
asked for. You could use itertools.chain.from_iterable, though:
py> names = ['Jack', 'Susan']
py> list(chai
On 26-02-18 15:41, Steven D'Aprano wrote:
> I have a class with a large number of parameters (about ten) assigned in
> `__init__`. The class then has a number of methods which accept
> *optional* arguments with the same names as the constructor/initialiser
> parameters. If those arguments are No
Le 26/02/18 à 15:41, Steven D'Aprano a écrit :
I have a class with a large number of parameters (about ten) assigned in
`__init__`. The class then has a number of methods which accept
*optional* arguments with the same names as the constructor/initialiser
parameters. If those arguments are None,
On Tue, Feb 27, 2018 at 2:02 AM, bartc wrote:
> On 26/02/2018 14:04, bartc wrote:
>>
>> On 26/02/2018 13:42, Ned Batchelder wrote:
>
>
>> Well, once you notice that the
>>>
>>> Python code had N=1e5, and the C code had N=1e9 :) If you want to
>>> experiment, with N=1e5, the final number should
On Tue, Feb 27, 2018 at 1:41 AM, Steven D'Aprano
wrote:
> I have a class with a large number of parameters (about ten) assigned in
> `__init__`. The class then has a number of methods which accept
> *optional* arguments with the same names as the constructor/initialiser
> parameters. If those argu
On 26/02/2018 14:04, bartc wrote:
On 26/02/2018 13:42, Ned Batchelder wrote:
Well, once you notice that the
Python code had N=1e5, and the C code had N=1e9 :) If you want to
experiment, with N=1e5, the final number should be 5255210926702073855.
OK, I'll try that.
I have that Python v
On 26-02-18 15:41, Steven D'Aprano wrote:
> I have a class with a large number of parameters (about ten) assigned in
> `__init__`. The class then has a number of methods which accept
> *optional* arguments with the same names as the constructor/initialiser
> parameters. If those arguments are No
On 26/02/2018 14:34, Chris Angelico wrote:
I'm glad _someone_ funded PyPy, anyhow. It's a great demonstration of
what can be done.
And it's good that /someone/ at least understands how PyPy works, as I
don't think many people do.
Apparently it doesn't optimise 'hot paths' within a Python pr
I have a class with a large number of parameters (about ten) assigned in
`__init__`. The class then has a number of methods which accept
*optional* arguments with the same names as the constructor/initialiser
parameters. If those arguments are None, the defaults are taken from the
instance attr
Define 2 lists. ...
[...]
Help me !
Sounds like homework. Have you tried anything? Does it work?
--
https://mail.python.org/mailman/listinfo/python-list
On Tue, Feb 27, 2018 at 12:03 AM, Steven D'Aprano
wrote:
> On Mon, 26 Feb 2018 22:34:00 +1100, Chris Angelico wrote:
>> Removing the GIL from CPython is not about "speeding up" the language or
>> the interpreter, but about improving parallelism.
>
> It is about speeding up threaded code which is C
On 26/02/2018 13:42, Ned Batchelder wrote:
On 2/26/18 7:13 AM, bartc wrote:
A C version is given below. (One I may have messed around with, which
I'm not sure works properly. For an original, google for Marsaglia and
KISS64 or SUPRKISS64.)
Most integers are unsigned, which have well-defined
On 26/02/18 13:42, Ned Batchelder wrote:
Also, I note that you said, "Most integers are unsigned", but the C code
has them all declared as signed? It doesn't seem to have mattered to
your result, but I'm not an expert on C portability guarantees.
C explicitly leaves the behaviour of signed ar
On 2/26/18 7:13 AM, bartc wrote:
On 26/02/2018 11:40, Chris Angelico wrote:
On Mon, Feb 26, 2018 at 10:13 PM, bartc wrote:
Below is the first draft of a Python port of a program to do with
random
numbers. (Ported from my language, which in turned ported it from a C
program by George Marsaglia
On Mon, 26 Feb 2018 22:34:00 +1100, Chris Angelico wrote:
[...]
>> (We tried painting Go Faster stripes on the server, and it didn't
>> work.)
>
> Steven Middlename D'Aprano! You should know better than that. "It didn't
> work" is not good enough. What actually happened?
A truck crashed into the
On 26/02/2018 12:06, Antoon Pardon wrote:
On 23-02-18 02:27, Steven D'Aprano wrote:
Why do you care about the 50 million calls? That's crazy -- the important
thing is *calculating the Fibonacci numbers as efficiently as possible*.
No necessarily.
David Beazley in his talks sometimes uses an i
On 24-02-18 06:18, Terry Reedy wrote:
> On 2/23/2018 11:32 AM, Python wrote:
>>
>> Doing that would completely fail to accomplish the task of comparing
>> the performance of recursive function calls in the two languages,
>> which is what the benchmark was designed to do.
>
> That is an non goal bec
On 26/02/2018 11:40, Chris Angelico wrote:
On Mon, Feb 26, 2018 at 10:13 PM, bartc wrote:
Below is the first draft of a Python port of a program to do with random
numbers. (Ported from my language, which in turned ported it from a C
program by George Marsaglia, the random number guy.)
However,
On 23-02-18 02:27, Steven D'Aprano wrote:
> Why do you care about the 50 million calls? That's crazy -- the important
> thing is *calculating the Fibonacci numbers as efficiently as possible*.
No necessarily.
David Beazley in his talks sometimes uses an ineffecient algorithm for
calculating
fib
On Mon, Feb 26, 2018 at 10:13 PM, bartc wrote:
> Below is the first draft of a Python port of a program to do with random
> numbers. (Ported from my language, which in turned ported it from a C
> program by George Marsaglia, the random number guy.)
>
> However, running it quickly exhausts the memo
On Mon, Feb 26, 2018 at 8:57 PM, Steven D'Aprano
wrote:
> On Sun, 25 Feb 2018 20:22:17 -0800, Rick Johnson wrote:
>
>> So of course, speed is not and should not be the
>> primary concern, but to say that execution speed is of _no_ concern is
>> quite absurd indeed.
>
> I'm pretty sure that nobody
On 26/02/2018 09:22, Steven D'Aprano wrote:
On Sun, 25 Feb 2018 21:19:19 -0800, Rick Johnson wrote:
I agree with your sarcasm. And that's why these types of auto
conversions should be optional. I agree that most times it's more
practical to let python handle the dirty details. But in some case
Christian Gollwitzer wrote:
> Am 26.02.18 um 10:40 schrieb sotaro...@gmail.com:
>> Define 2 lists. The first one must contain the integer values 1, 2 and 3
>> and the second one the string values a, b and c. Iterate through both
>> lists to create another list that contains all the combinations of
On Sun, 25 Feb 2018 19:26:12 -0800, Rick Johnson wrote:
> On Friday, February 23, 2018 at 8:48:55 PM UTC-6, Steven D'Aprano wrote:
> [...]
>> Take the Fibonacci double-recursion benchmark. Okay, it tests how well
>> your language does at making millions of function calls. Why?
>
> Because making
Hi,
I would like to know if its possible to detect or decode ultrasonic
signals in mobiles devices like Android with Python?
For a introduction to ultrasonic tracking, see:
https://www.wired.com/2016/11/block-ultrasonic-signals-didnt-know-tracking/
Thank you,
Etienne
--
Etienne Robillard
On Sun, 25 Feb 2018 20:22:17 -0800, Rick Johnson wrote:
> So of course, speed is not and should not be the
> primary concern, but to say that execution speed is of _no_ concern is
> quite absurd indeed.
I'm pretty sure that nobody here has said that speed is of no concern.
Rather, I would argue
Am 26.02.18 um 10:40 schrieb sotaro...@gmail.com:
Define 2 lists. The first one must contain the integer values 1, 2 and 3 and
the second one the string values a, b and c. Iterate through both lists to
create another list that contains all the combinations of the A and B elements.
The final li
Define 2 lists. The first one must contain the integer values 1, 2 and 3 and
the second one the string values a, b and c. Iterate through both lists to
create another list that contains all the combinations of the A and B elements.
The final list should look like one of the 2 lists:
1. [1a, 1b,
On Sun, 25 Feb 2018 21:19:19 -0800, Rick Johnson wrote:
> I agree with your sarcasm. And that's why these types of auto
> conversions should be optional. I agree that most times it's more
> practical to let python handle the dirty details. But in some cases,
> where you need to squeeze out a few
87 matches
Mail list logo
