Re: Are the critiques in "All the things I hate about Python" valid?

[Steven D'Aprano]

On Tue, 20 Feb 2018 02:35:37 +1100, Chris Angelico wrote:

>  But C is a language saddled with so much history and backward
> compatibility constraints that there are some things you just CAN'T make
> into errors

Indeed. C is not even close to a safe language, hence the move to create 
(and more importantly, convince people to use!) systems languages like 
Rust and D which combine C's ability to generate fast code without 
(unnecessarily) compromising type safety.



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Antoon Pardon]

On 19-02-18 16:18, Ned Batchelder wrote:
> On 2/19/18 9:54 AM, Steven D'Aprano wrote:
>> On Mon, 19 Feb 2018 13:28:26 +, Paul Moore wrote:
>>
>>> [1] The most basic question, which people making such claims often
>>> can't
>>> answer, is "Do you mean that values are strongly typed, or that names
>>> are? Or did you mean that variables are, because if so Python doesn't
>>> even have variables in the sense that you mean" Programming language
>>> semantics are complex.
>> An excellent point.
>>
>> The distinction between typing *values* and *names* is a good one.
>>
>>
>>
>
> I guess I'll have to continue to grit my teeth as people say, "Python
> doesn't have variables."   Why can't we say, "Python's variables work
> differently than other languages"?
>
> --Ned.

Which other languages. It seems python variables seem to work just like
lisp, scheme and smalltalk.

-- 
Antoon

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Ned Batchelder]

On 2/20/18 5:47 AM, Antoon Pardon wrote:

On 19-02-18 16:18, Ned Batchelder wrote:

On 2/19/18 9:54 AM, Steven D'Aprano wrote:

On Mon, 19 Feb 2018 13:28:26 +, Paul Moore wrote:


[1] The most basic question, which people making such claims often
can't
answer, is "Do you mean that values are strongly typed, or that names
are? Or did you mean that variables are, because if so Python doesn't
even have variables in the sense that you mean" Programming language
semantics are complex.

An excellent point.

The distinction between typing *values* and *names* is a good one.




I guess I'll have to continue to grit my teeth as people say, "Python
doesn't have variables."   Why can't we say, "Python's variables work
differently than other languages"?

--Ned.

Which other languages. It seems python variables seem to work just like
lisp, scheme and smalltalk.


C.

That is one of the reasons for my frustration: the "Python has no 
variables" slogan is incredibly C-centric.  I understand the importance 
of C, and in the early days of Python, there was good reason to assume 
that people were familiar with C.  These days, there are far more 
mainstream languages that work just as Python does.


To your "work just like" list we can add Javascript, Ruby, PHP, and Java 
(for objects, not primitives).


--Ned.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Antoon Pardon]

On 19-02-18 15:25, Steven D'Aprano wrote:
>
>> Ones like C++ has already tied itself itself up in knots just doing the
>> basics; I'm not sure how it would handle even my 1,3,5,7,9 type.
>>
>> But Python has classes and can do some of this stuff; how would it
>> handle a numeric type that is constrained to be whole numbers within
>> 0..9 inclusive?
> This becomes easy at run-time:
>
> class Digit(int):
> def __new__(cls, arg):
> instance = super().__new__(cls, arg)
> if not 0 <= instance <= 9:
> raise ValueError('argument is out of range')
> return instance
>
> The above is obviously not a full-blown production-ready class. But it 
> illustrates the basic concept. This is the sort of thing that dynamic 
> languages excel at: enforcing constraints at run-time which are hard to 
> enforce at compile-time.

I don't see how dynamic languages are excelling here. Writing code that
ensures a number
of constraints can be done just as easily in a static language.

Personnally I would prefer the type system of Pascal and Modula2 with
their interval type
above a Digit class in python. For the simple reason that once you had
declared a variable
like this:
    x: 1 .. 10;

Each assignment to x would then implicitly do something like an assert
to checks the constraint,
so it would be impossible to ever assign 11 to x, without an error being
thrown.

There is no such possibility in Python. You can off course start with x
= Digit(5), but the language
won't stop you from doing x = 11 later.

I'm not proficient with C++, but IIUC, you could make a class in C++ and
have the constructor and
copy operator check for these kind of things. True it would be run-time
checks but that would
already be more than Python can give.

-- 
Antoon.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Paul Moore]

On 20 February 2018 at 11:18, Antoon Pardon  wrote:
> Personnally I would prefer the type system of Pascal and Modula2 with
> their interval type
> above a Digit class in python. For the simple reason that once you had
> declared a variable
> like this:
> x: 1 .. 10;
>
> Each assignment to x would then implicitly do something like an assert
> to checks the constraint,
> so it would be impossible to ever assign 11 to x, without an error being
> thrown.
>
> There is no such possibility in Python. You can off course start with x
> = Digit(5), but the language
> won't stop you from doing x = 11 later.

All that is saying is that in Pascal, variables have types, whereas in
Python values have types but variables (names ;-)) don't. It's true,
but not particularly important in toy examples like this. In larger
scale programs, tracking the "type" of what gets assigned to a
variable can be really useful, and carefully managed types can help
with this. Pascal/Modula2 (and C/C++) have the compiler do this,
Python has a separate tool (MyPy). Early C compilers used to have
linters that did some checks outside of the compiler - maybe someday
Python will build MyPy into the compiler (although I suspect not).

Also, tracking "types" is only half the battle. There are probably
very few people who have never mistakenly assigned NULL to a pointer
in C that shouldn't be null. Or even in Java, which is supposed to not
allow things like that. And tracking const types in C is widely
acknowledged to be a mixed blessing at best. Where does "type" end and
"documented constraint or programming contract" start?

> I'm not proficient with C++, but IIUC, you could make a class in C++ and
> have the constructor and
> copy operator check for these kind of things. True it would be run-time
> checks but that would
> already be more than Python can give.

That (run-time checks) is exactly the same as Python gives. In C++,
variables have types so you could ensure that you could only assign a
value of your digit type to a given variable, but as I said above
that's a separate point.

It's somewhat unrelated (scoping is a different topic than assignment)
but you can do

{
int x = 2;
{
char *x = "hello";
}
}

in C, so names can have different types even in C (it's just
variables, or names within a specific scope, that have types
associated with them).

Summary: Different programming languages have different semantics.
Which really isn't that surprising...

Paul
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python on Android?

[Chris Angelico]

On Mon, Feb 19, 2018 at 3:57 AM, Johannes Findeisen  wrote:
> On Sun, 18 Feb 2018 20:57:02 +1100
> Chris Angelico wrote:
>
>> Does anyone have experience with running Python scripts on Android
>> phones? I have a brother (honestly! I'm not actually using a phone
>> myself!) who's trying to run one of my scripts in QPython, which
>> claims to be version 3.2.2. I think that really truly is a Python 3.2
>> implementation - probing for newer features suggests that it actually
>> doesn't even support the u"..." syntax that came (back) in with Python
>> 3.3. So... does anyone know of a Python interpreter that's compatible
>> with 3.4 or better and runs on Android?
>>
>
> There is an App for Android called "Pydroid 3". You can find it in
> the Google Play Store [0]. It provides a Python interpreter in version
> 3.6.2 in its current release.
>
> The Python binary is installed under
>
> /data/user/0/ru.iiec.pydroid3/files/arm-linux-androideabi/bin/python
>
> but I can not access it in a normal terminal without being user "root"
> but it is usable from within the terminal included in the Pydroid App.

Many thanks for all the suggestions. Pydroid is the one that has
worked; he's now able to run stuff happily from the terminal. Next
step is to create an icon that invokes it, but that's looking rather
harder (probably means I'm going to have to learn Kivy, and I already
have no shortage of projects...). Everything's working in the terminal
(even a read-write $HOME, which we didn't have previously), and I'm
pretty happy with that!

All suggestions were read and are appreciated, even though I'm only
quoting the one we ended up going with. Thank you Kirill, MRAB, Abdur,
and Johannes!

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Steven D'Aprano]

On Tue, 20 Feb 2018 12:18:47 +0100, Antoon Pardon wrote:

> On 19-02-18 15:25, Steven D'Aprano wrote:
>>
>>> Ones like C++ has already tied itself itself up in knots just doing
>>> the basics; I'm not sure how it would handle even my 1,3,5,7,9 type.
>>>
>>> But Python has classes and can do some of this stuff; how would it
>>> handle a numeric type that is constrained to be whole numbers within
>>> 0..9 inclusive?
>> This becomes easy at run-time:
>>
>> class Digit(int):
>> def __new__(cls, arg):
>> instance = super().__new__(cls, arg)
>> if not 0 <= instance <= 9:
>> raise ValueError('argument is out of range')
>> return instance
>>
>> The above is obviously not a full-blown production-ready class. But it
>> illustrates the basic concept. This is the sort of thing that dynamic
>> languages excel at: enforcing constraints at run-time which are hard to
>> enforce at compile-time.
> 
> I don't see how dynamic languages are excelling here. Writing code that
> ensures a number of constraints can be done just as easily in a static
> language.

*Just* as easily? Really?

Can you tell us which languages can enforce at compile-time that integer 
N is a multiple of four but not a multiple of 100 unless it is also a 
multiple of 400? (The same constraint as leap years.)

What type declaration would you write for that?

Its easy to make overblown claims about how great static typing is, but 
people didn't invent dynamically typed languages because they wanted to 
program in a worse language. They did it because dynamic typing allows us 
to do things which are hard, or impossible, in statically typed languages.


> Personnally I would prefer the type system of Pascal and Modula2 with
> their interval type
> above a Digit class in python. For the simple reason that once you had
> declared a variable
> like this:
>     x: 1 .. 10;


I agree that Pascal-style interval types are nice, but they're also 
limited to intervals, and *integer* intervals at that. Pascal doesn't 
support floating point ranges, such as "x is a Real between 0 and 1".

How would you write a type declaration for numbers like these:

4, 6, 8, 24, 26, 48, 50, 124, 126, 342, 344, ... 3909821048582988050

in the language of your choice?

Yes, there is a pattern: one less than, and one more than, powers of 5 
and 7, up to a maximum of 2**64.

That is, 5±1, 25±1, 125±1, ... 7±1, 49±1, 343±1, ...

Its one thing to say that a type system could enforce this at compile-
time. Its another to demonstrate an existing type system which actually 
does.


> Each assignment to x would then implicitly do something like an assert
> to checks the constraint,
> so it would be impossible to ever assign 11 to x, without an error being
> thrown.

As I remember it, Pascal range checking is just dynamic typing in 
disguise. Statically, x is just an integer, with no interval checking 
performed at compile-time except for assignment by literals. Everything 
else is run-time range checking.

By which I mean, the compiler would complain if you tried:

var
  x: 1 .. 10;
begin
  x := 11;
end;

but it would allow this:

var
  a, b: integer;
  x: 1 .. 10;
begin
  a := 10;
  b := 1;
  x := a + b;
end;

However, the second would generate a runtime range check error and halt 
the program.

That at least is how the Lightspeed Pascal (later Think Pascal) compiler 
on the Apple Mac operated, and as far as I know all other Pascal 
compilers worked the same.

Now that was over 30 years ago, and I daresay that type checkers these 
days are more sophisticated and powerful than Pascal's pretty simple 
checker. But still, there's only so much you can do at compile-time.


> There is no such possibility in Python. You can off course start with x
> = Digit(5), but the language
> won't stop you from doing x = 11 later.


Of course you're right that Python won't stop you assigning (say) a float 
to x. On the other hand, Pascal and C won't allow you to assign a string 
to something which previously was an integer. The need to create new 
labels for things just to placate the compiler is one of the more 
annoying things about static typing. Yes, x was a number, now its a 
string. If *I* can keep track of that, why can't the compiler?


> I'm not proficient with C++, but IIUC, you could make a class in C++ and
> have the constructor and
> copy operator check for these kind of things. True it would be run-time
> checks but that would
> already be more than Python can give.

Sure. Its a different approach, and not without its merits.



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Steven D'Aprano]

On Mon, 19 Feb 2018 16:34:29 +0100, Anders Wegge Keller wrote:

> På Mon, 19 Feb 2018 15:15:19 + (UTC) Steven D'Aprano
>  skrev:
>> On Mon, 19 Feb 2018 14:06:36 +0100, Anders Wegge Keller wrote:
>> 
>> > Array is not even close to providing a strongly typed container.
>> 
>> That's a mighty powerful claim that goes against the documentation for
>> the array module. Can you back your claims up?
>> 
>> Here's an array and a list:
> 
>  Make me an array of tuples with two integers and a string, and we can
>  talk.

The array module's failure to support the specific type you want has no 
bearing on whether or not Python is statically typed.

The question isn't "does Python provide you with every imaginable 
homogeneous array type you might ever want?", we already know the answer 
to that is no.

The question is your claim that Python objects aren't strongly typed, and 
your obvious attempt to avoid answering my challenge is answer enough. If 
you could meet the challenge, you would have done it.



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[bartc]

On 20/02/2018 12:11, Paul Moore wrote:

On 20 February 2018 at 11:18, Antoon Pardon  wrote:



There is no such possibility in Python. You can off course start with x
= Digit(5), but the language
won't stop you from doing x = 11 later.



I'm not proficient with C++, but IIUC, you could make a class in C++ and
have the constructor and
copy operator check for these kind of things. True it would be run-time
checks but that would
already be more than Python can give.


I don't know if that counts. In Pascal (and presumably Ada) then all the 
gubbins need to make this work properly:


  var x: 1..10;

  x = 10;
  x = x + 1;   { error? }

would already be in place. Trying to emulate that within a language is 
complex and unwieldy, and someone has to know how to do it, and then do 
it. If someone else creates an add-on for it, then those tend to be 
large and cumbersome (because they have to have every conceivable bell 
and whistle). And it's an extra dependency.


The end result: if I wanted to sit down right now and have a variable 
and/or type in Python or C++ that is constrained to be within 1..10, 
then I couldn't. I'd have to use a generic integer type.


And in fact, in Python, I couldn't even do that, as I can assign 
anything at all to x.


This is not necessarily undesirable: part of the point of dynamic 
languages is being informal and having less discipline imposed so that 
things can get done more rapidly. But enforced discipline can also be 
useful.



It's somewhat unrelated (scoping is a different topic than assignment)
but you can do

{
 int x = 2;
 {
 char *x = "hello";
 }
}

in C, so names can have different types even in C (it's just
variables, or names within a specific scope, that have types
associated with them).


That's scope; Python has that too. (Although not C's block scopes and 
its bizarre rules which mean that you can have up 5 different 'x' 
meanings even within the same block. And an unlimited number of 'x' 
scopes within the same function.


(This is allowed in C:   int L; L: L=10; goto L; )

--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Antoon Pardon]

On 20-02-18 13:11, Paul Moore wrote:
> On 20 February 2018 at 11:18, Antoon Pardon  wrote:
>> Personnally I would prefer the type system of Pascal and Modula2 with
>> their interval type
>> above a Digit class in python. For the simple reason that once you had
>> declared a variable
>> like this:
>> x: 1 .. 10;
>>
>> Each assignment to x would then implicitly do something like an assert
>> to checks the constraint,
>> so it would be impossible to ever assign 11 to x, without an error being
>> thrown.
>>
>> There is no such possibility in Python. You can off course start with x
>> = Digit(5), but the language
>> won't stop you from doing x = 11 later.
> All that is saying is that in Pascal, variables have types, whereas in
> Python values have types but variables (names ;-)) don't. It's true,
> but not particularly important in toy examples like this. In larger
> scale programs, tracking the "type" of what gets assigned to a
> variable can be really useful, and carefully managed types can help
> with this. Pascal/Modula2 (and C/C++) have the compiler do this,
> Python has a separate tool (MyPy).

In Pascal and Modula2 type checking was not limited to compile time. Part
of that type checking was done at by the runtime enviroment.

>> I'm not proficient with C++, but IIUC, you could make a class in C++ and
>> have the constructor and
>> copy operator check for these kind of things. True it would be run-time
>> checks but that would
>> already be more than Python can give.
> That (run-time checks) is exactly the same as Python gives.

No it isn't exactly the same. Those runtime checks are implicit. They are like
a contract made at declaration time, which make it impossible to assign 
something
to the variable that doesn't meet the constraint without the program throwing an
error.

You can't do something like that in Python.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Anders Wegge Keller]

På Tue, 20 Feb 2018 12:28:25 + (UTC)
Steven D'Aprano  skrev:
> On Mon, 19 Feb 2018 16:34:29 +0100, Anders Wegge Keller wrote:
> 
> > På Mon, 19 Feb 2018 15:15:19 + (UTC) Steven D'Aprano
> >  skrev:  
> >> On Mon, 19 Feb 2018 14:06:36 +0100, Anders Wegge Keller wrote:
> >>   
>  [...]  
> >> 
> >> That's a mighty powerful claim that goes against the documentation for
> >> the array module. Can you back your claims up?
> >> 
> >> Here's an array and a list:  
> > 
> >  Make me an array of tuples with two integers and a string, and we can
> >  talk.  
> 
> The array module's failure to support the specific type you want has no 
> bearing on whether or not Python is statically typed.

 You claimed Array could do what I requested, i.e. container type that
guaranteed only one type inside. Furthermore, you are misrepresenting C with
malice. 

 I don't care why you feel that a simple observation is a personal attack,
but I see you behave as a spoiled kid. I haven\t got the time for it, sop go
and pout in your corner. 

-- 
//Wegge
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Paul Moore]

On 20 February 2018 at 13:04, Antoon Pardon  wrote:
> On 20-02-18 13:11, Paul Moore wrote:
>> On 20 February 2018 at 11:18, Antoon Pardon  wrote:
>>> Personnally I would prefer the type system of Pascal and Modula2 with
>>> their interval type
>>> above a Digit class in python. For the simple reason that once you had
>>> declared a variable
>>> like this:
>>> x: 1 .. 10;
>>>
>>> Each assignment to x would then implicitly do something like an assert
>>> to checks the constraint,
>>> so it would be impossible to ever assign 11 to x, without an error being
>>> thrown.
>>>
>>> There is no such possibility in Python. You can off course start with x
>>> = Digit(5), but the language
>>> won't stop you from doing x = 11 later.
>> All that is saying is that in Pascal, variables have types, whereas in
>> Python values have types but variables (names ;-)) don't. It's true,
>> but not particularly important in toy examples like this. In larger
>> scale programs, tracking the "type" of what gets assigned to a
>> variable can be really useful, and carefully managed types can help
>> with this. Pascal/Modula2 (and C/C++) have the compiler do this,
>> Python has a separate tool (MyPy).
>
> In Pascal and Modula2 type checking was not limited to compile time. Part
> of that type checking was done at by the runtime enviroment.

So? What point are you making? (I genuinely don't see - you surely
aren't saying that Python can't implement runtime checks, and this is
all related to your original comment that "There is no such
possibility in Python").

>>> I'm not proficient with C++, but IIUC, you could make a class in C++ and
>>> have the constructor and
>>> copy operator check for these kind of things. True it would be run-time
>>> checks but that would
>>> already be more than Python can give.
>> That (run-time checks) is exactly the same as Python gives.
>
> No it isn't exactly the same. Those runtime checks are implicit. They are like
> a contract made at declaration time, which make it impossible to assign 
> something
> to the variable that doesn't meet the constraint without the program throwing 
> an
> error.
>
> You can't do something like that in Python.

I *am* (reasonably) proficient in C++, and (other than the "values
have types rather than variables/names" point I already stated was a
difference in how the languages work) I don't see anything in what
you're describing as "things C++ can do" that Python can't.

Sigh. Languages are different. That's my point. What's yours? If it's
that Python is worse than (some other language) then so what? Probably
true in some cases, but what makes you think you'll get enthusiastic
approval for such a statement in a Python group?

Bored now.

Paul
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Antoon Pardon]

On 20-02-18 13:24, Steven D'Aprano wrote:
> On Tue, 20 Feb 2018 12:18:47 +0100, Antoon Pardon wrote:
>
>> On 19-02-18 15:25, Steven D'Aprano wrote:
 Ones like C++ has already tied itself itself up in knots just doing
 the basics; I'm not sure how it would handle even my 1,3,5,7,9 type.

 But Python has classes and can do some of this stuff; how would it
 handle a numeric type that is constrained to be whole numbers within
 0..9 inclusive?
>>> This becomes easy at run-time:
>>>
>>> class Digit(int):
>>> def __new__(cls, arg):
>>> instance = super().__new__(cls, arg)
>>> if not 0 <= instance <= 9:
>>> raise ValueError('argument is out of range')
>>> return instance
>>>
>>> The above is obviously not a full-blown production-ready class. But it
>>> illustrates the basic concept. This is the sort of thing that dynamic
>>> languages excel at: enforcing constraints at run-time which are hard to
>>> enforce at compile-time.
>> I don't see how dynamic languages are excelling here. Writing code that
>> ensures a number of constraints can be done just as easily in a static
>> language.
> *Just* as easily? Really?
>
> Can you tell us which languages can enforce at compile-time that integer 
> N is a multiple of four but not a multiple of 100 unless it is also a 
> multiple of 400? (The same constraint as leap years.)

Why should this be done at compile time? I say a static language can do
the same as a dynamic language and your counter point is to ask for how
that static language can do something extra.

The point I am making is that you claim dynamic languages are excelling
by being less demaning of the dynamic language.

So yes the static language can check those kind of restraints at runtime
just as easily as a dynamic language.

> What type declaration would you write for that?
>
> Its easy to make overblown claims about how great static typing is, but 
> people didn't invent dynamically typed languages because they wanted to 
> program in a worse language. They did it because dynamic typing allows us 
> to do things which are hard, or impossible, in statically typed languages.

Maybe but you didn't give an example of something that is hard of impossible
in a statically typed language. There is nothing impossible or hard in checking
a number of constraints during runtime in a statically typed language.

> I agree that Pascal-style interval types are nice, but they're also 
> limited to intervals, and *integer* intervals at that. Pascal doesn't 
> support floating point ranges, such as "x is a Real between 0 and 1".
>
> How would you write a type declaration for numbers like these:
>
> 4, 6, 8, 24, 26, 48, 50, 124, 126, 342, 344, ... 3909821048582988050
>
> in the language of your choice?
>
> Yes, there is a pattern: one less than, and one more than, powers of 5 
> and 7, up to a maximum of 2**64.
>
> That is, 5±1, 25±1, 125±1, ... 7±1, 49±1, 343±1, ...

Well as far as I know you could do this in C++ by having the constructor and
copy-operator make the needed checks.

> Its one thing to say that a type system could enforce this at compile-
> time. Its another to demonstrate an existing type system which actually 
> does.

I am not talking about compile time. There is nothing that prevents a
statically typed language to do some of the checks at runtime.

>> Each assignment to x would then implicitly do something like an assert
>> to checks the constraint,
>> so it would be impossible to ever assign 11 to x, without an error being
>> thrown.
> As I remember it, Pascal range checking is just dynamic typing in 
> disguise. Statically, x is just an integer, with no interval checking 
> performed at compile-time except for assignment by literals. Everything 
> else is run-time range checking.

So? As far as I know Pascal is generally considered a statically typed
language. That some of the constraints imposed by the type can only
be checked at runtime doesn't contradict that the type of a variable
is determined at compile time.

> Of course you're right that Python won't stop you assigning (say) a float 
> to x. On the other hand, Pascal and C won't allow you to assign a string 
> to something which previously was an integer. The need to create new 
> labels for things just to placate the compiler is one of the more 
> annoying things about static typing. Yes, x was a number, now its a 
> string. If *I* can keep track of that, why can't the compiler?

Is it really that annoying? Most examples I have seen here where the
same variable was assigned multiple types, was labeled a code smell
that needed to be approved by review or something like that, on this list.

People praise the dynamic nature of Python here on this list and then
often enough seem to recoil when they see a piece of code really using
that dynamism.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Antoon Pardon]

 I'm not proficient with C++, but IIUC, you could make a class in C++ and
 have the constructor and
 copy operator check for these kind of things. True it would be run-time
 checks but that would
 already be more than Python can give.
>>> That (run-time checks) is exactly the same as Python gives.
>> No it isn't exactly the same. Those runtime checks are implicit. They are 
>> like
>> a contract made at declaration time, which make it impossible to assign 
>> something
>> to the variable that doesn't meet the constraint without the program 
>> throwing an
>> error.
>>
>> You can't do something like that in Python.
> I *am* (reasonably) proficient in C++, and (other than the "values
> have types rather than variables/names" point I already stated was a
> difference in how the languages work) I don't see anything in what
> you're describing as "things C++ can do" that Python can't.

In C++ I can do something like:

  SomeClass MyVar;

And after that the kind of possible assignments to MyVar are constraint. It
makes the runtime throw an error when somewhere the program tries to assign
something to MyVar that isn't allowed by SomeClass.

You can't put such constraints on names in Python.

In C++ I can do some like:
    Some_Class: MyVar;

And after that, It will be impossible to assign a value to MyVar that
doesn't meet the
constraints imposed by the constructor/copy operator. You have put
somekind of
contract on the name MyVar, that limits the kind of things assignable to
it. You
can't put such constraints on a name in Python.
>
> Sigh. Languages are different. That's my point.

So, if languages are different, why the difficulty in accepting one can
do something the other can't?

>  What's yours? If it's
> that Python is worse than (some other language) then so what? Probably
> true in some cases, but what makes you think you'll get enthusiastic
> approval for such a statement in a Python group?

So you only want to see praisal for python? One can't express how one
prefers specific
features from other languages?


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Chris Angelico]

On Wed, Feb 21, 2018 at 12:38 AM, Antoon Pardon  wrote:
> Why should this be done at compile time? I say a static language can do
> the same as a dynamic language and your counter point is to ask for how
> that static language can do something extra.
>
> The point I am making is that you claim dynamic languages are excelling
> by being less demaning of the dynamic language.
>
> So yes the static language can check those kind of restraints at runtime
> just as easily as a dynamic language.

So what's the point of a "static language" if all it's doing is the
same thing that any other language can do?

The whole point of static analysis is that you can verify correctness
BEFORE something gets into production. That means you have the
potential to catch bugs before it's too late. If all you're going to
do is check everything at run time, it's not static analysis any more.
The question is: Can you create a strong compile-time type system that
can verify correctness WITHOUT running the code?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Chris Angelico]

On Wed, Feb 21, 2018 at 12:53 AM, Antoon Pardon  wrote:
> In C++ I can do something like:
>
>   SomeClass MyVar;
>
> And after that the kind of possible assignments to MyVar are constraint. It
> makes the runtime throw an error when somewhere the program tries to assign
> something to MyVar that isn't allowed by SomeClass.
>
> You can't put such constraints on names in Python.
>
> In C++ I can do some like:
> Some_Class: MyVar;
>
> And after that, It will be impossible to assign a value to MyVar that
> doesn't meet the
> constraints imposed by the constructor/copy operator. You have put
> somekind of
> contract on the name MyVar, that limits the kind of things assignable to
> it. You
> can't put such constraints on a name in Python.

Okay. Now create a constraint on a name in C++ such that it can only
accept integers representing A.D. years which, on the Gregorian
calendar, are leap years. (Using a dedicated integer-like type is
permitted.) It must accept all multiples of four, except those which
are multiples of one hundred, unless they're also multiples of four
hundred.

That's what Steve asked for. Can you do it? Or is the C++ type system
not flexible enough for that?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Paul Moore]

On 20 February 2018 at 13:53, Antoon Pardon  wrote:

> You can't put such constraints on names in Python.

I know. That's what *I* said some time ago.

>> Sigh. Languages are different. That's my point.
>
> So, if languages are different, why the difficulty in accepting one can
> do something the other can't?

I don't know. Who finds it difficult? I don't. What I find difficult
is understanding what you're saying other languages can do that I
haven't already agreed with.

>>  What's yours? If it's
>> that Python is worse than (some other language) then so what? Probably
>> true in some cases, but what makes you think you'll get enthusiastic
>> approval for such a statement in a Python group?
>
> So you only want to see praisal for python? One can't express how one
> prefers specific features from other languages?

Of course you can. Go right ahead.

Paul
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[bartc]

On 20/02/2018 13:38, Antoon Pardon wrote:


People praise the dynamic nature of Python here on this list and then
often enough seem to recoil when they see a piece of code really using
that dynamism.


Maybe everyone has their own ideas of how dynamic a language should be.


(I use another language that I call 'dynamic'. But the only dynamic 
thing is that variables have a dynamic type - the variable's type is a 
runtime attribute.


But, function names are static (they will always be function names). 
Module names are static. Type names (including user-defined ones) are 
static. Named constants are static. Source code is static (it only 
exists at compile-time). Attribute names are static; they have to be 
declared at compile-time. Variable names themselves are static: they 
can't become function or class or module names. Module imports are 
static (they are not done at runtime and can't be conditional). 
Operators are static and cannot overridden.


AFAIK, all these are dynamic in Python (not sure about operators).)

--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Antoon Pardon]

On 20-02-18 14:55, Chris Angelico wrote:
> On Wed, Feb 21, 2018 at 12:38 AM, Antoon Pardon  wrote:
>> Why should this be done at compile time? I say a static language can do
>> the same as a dynamic language and your counter point is to ask for how
>> that static language can do something extra.
>>
>> The point I am making is that you claim dynamic languages are excelling
>> by being less demaning of the dynamic language.
>>
>> So yes the static language can check those kind of restraints at runtime
>> just as easily as a dynamic language.
> So what's the point of a "static language" if all it's doing is the
> same thing that any other language can do?

Who says that is all static languages are doing? Steven claimed dynamic 
languages
excelled at runtime checks. I counter by stating that statically typed languages
are just as good at runtime checks. How do you infer from that, that all
that statically languages do, is the same as a dynamic language? 

-- 
Antoon
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Antoon Pardon]

On 20-02-18 15:04, Paul Moore wrote:
> On 20 February 2018 at 13:53, Antoon Pardon  wrote:
>
>> You can't put such constraints on names in Python.
> I know. That's what *I* said some time ago.

So why did you bother complaining to me when I wrote it?


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: could use some help with this problem! I've been working on it for days but cant seem to get it right !

[Ben Bacarisse]

Marc Cohen  writes:

> USING PYTHON 2:

Why is that?

> Write a program to play this game. This may seem tricky, so break it
> down into parts. Like many programs, we have to use nested loops (one
> loop inside another). In the outermost loop, we want to keep playing
> until we are out of stones.

You almost never /have/ to use nested loops.  Has the course got this
far without introducing the idea of a function?


> So, the basic outline of the program should be something like this:
>
> totalStones = 100
>
> maxStones = 5

maxTake or maxMove might be a more helpful name.

> pile = TOTAL # all stones are in the pile to start
>
> while [pile is not empty]:
>
> while [player 1's answer is not valid]:
>
> [ask player 1]
>
> [execute player1’s move]
>
> Do the same for player 2…. (this can be achieved by a for loop)

Is the idea for the program to play an optimal strategy for player 2, or
is the program simply doing the housekeeping -- verifying moves and
tracing the pile of stones?


-- 
Ben.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Antoon Pardon]

On 20-02-18 14:58, Chris Angelico wrote:
> On Wed, Feb 21, 2018 at 12:53 AM, Antoon Pardon  wrote:
>> In C++ I can do something like:
>>
>>   SomeClass MyVar;
>>
>> And after that the kind of possible assignments to MyVar are constraint. It
>> makes the runtime throw an error when somewhere the program tries to assign
>> something to MyVar that isn't allowed by SomeClass.
>>
>> You can't put such constraints on names in Python.
>>
>> In C++ I can do some like:
>> Some_Class: MyVar;
>>
>> And after that, It will be impossible to assign a value to MyVar that
>> doesn't meet the
>> constraints imposed by the constructor/copy operator. You have put
>> somekind of
>> contract on the name MyVar, that limits the kind of things assignable to
>> it. You
>> can't put such constraints on a name in Python.
> Okay. Now create a constraint on a name in C++ such that it can only
> accept integers representing A.D. years which, on the Gregorian
> calendar, are leap years. (Using a dedicated integer-like type is
> permitted.) It must accept all multiples of four, except those which
> are multiples of one hundred, unless they're also multiples of four
> hundred.
>
> That's what Steve asked for. Can you do it? Or is the C++ type system
> not flexible enough for that?

Steve had multiple contributions in this thread. I didn't react to the
one where he asked for that.

I reacted to his assertion that dynamic languages excell at [run time
checks] as if static languages are somehow limited at run time checks.

writing a Digit Class in a dynamic language that checks whether the number
you are about to assign is a digit, doesn't strike me as that much different
from just writing a function that does the same kind of checking.

Plus, in a statically typed language you can put constraints on the variables
that will ensure the compilor will implicitly call the needed functions to
check (because they are part of the constructor/copy operator) which you
can't do in a dynamically typed language. So IMO the statically typed 
languages are at the advantage here.
-- 
Antoon.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Replying on a tweet with Twython

[Steven D'Aprano]

On Sat, 17 Feb 2018 21:27:52 +0100, Cecil Westerhof wrote:

[...]
>> Okay. What happens when you try?
> 
> Then the tweet is posted as a reply on the the first tweet.
> 
> (So problem solved.)


Ah, sorry, I did not understand your second post. I thought you were 
posting it as an update to the problem, and didn't understand that you 
were saying it was the solution to the problem.



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: solve_ivp problem (scipy 1.0.0)

[AB]

Hello

I don't know why but my answer got lost somehow, so I'm sending it once 
more, hopefully with better luck.


W dniu 2018-02-19 o 11:02, Thomas Jollans pisze:

On 2018-02-18 14:39, A.Brozi wrote:

Hello

In new "scipy" (1.0.0) I've found procedure "solve_ivp", which makes it
possible to use "events" in order to terminate the ode solution when
some condition is satisfied.
The precise moment of termination (the value of independent variable) is
to be found in "t_events", but I cannot find the dependent variable(s)
value(s) at the termination moment.
Am I missing something? Or it's simply not possible (hopefully 'not yet')?

Regards
Andrzej Brozi


Isn't the solution passed back as ‘y’?


Yes, it is. But the vector "y" contains only values corresponding to the 
time moments given in "t_eval". It doesn't contain the value 
corresponding to the time of event function passing zero.
In this situation a trajectory of a projectile hitting ground will 
terminate at a point above ground.
I've succeeded to find one walk-around for this problem: if the "t_eval" 
vector is not supplied, then the last element of the solution "y" will 
be the desired value.
Using this method it may be necessary to supply some reasonably small 
value of "max_step" (otherwise the solution may contain too few points). 
Unfortunately I don't see a simple way to guarantee the solution not to 
contain too many points (without "t_eval" it will contain all the points 
computed).


Regards
Andrzej Brozi
--
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Steven D'Aprano]

On Tue, 20 Feb 2018 15:23:44 +0100, Antoon Pardon wrote:

>> Okay. Now create a constraint on a name in C++ such that it can only
>> accept integers representing A.D. years which, on the Gregorian
>> calendar, are leap years. (Using a dedicated integer-like type is
>> permitted.) It must accept all multiples of four, except those which
>> are multiples of one hundred, unless they're also multiples of four
>> hundred.
>>
>> That's what Steve asked for. Can you do it? Or is the C++ type system
>> not flexible enough for that?
> 
> Steve had multiple contributions in this thread. I didn't react to the
> one where he asked for that.

Yes you did: you refused to meet the challenge, stating (and I quote):

"Why should this be done at compile time?"

https://mail.python.org/pipermail/python-list/2018-February/730995.html



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python on Android?

[Cholo Lennon]

On 20/02/18 11:50, Paul Rubin wrote:

Chris Angelico  writes:

probably means I'm going to have to learn Kivy


Is SL4A still around?  Maybe it's an alternative.



QPython 2 & 3, both have samples that use SL4A.

--
Cholo Lennon
Bs.As.
ARG
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python on Android?

[Cholo Lennon]

On 18/02/18 06:57, Chris Angelico wrote:

Does anyone have experience with running Python scripts on Android
phones? I have a brother (honestly! I'm not actually using a phone
myself!) who's trying to run one of my scripts in QPython, which
claims to be version 3.2.2. I think that really truly is a Python 3.2
implementation - probing for newer features suggests that it actually
doesn't even support the u"..." syntax that came (back) in with Python
3.3. So... does anyone know of a Python interpreter that's compatible
with 3.4 or better and runs on Android?

Personal experiences trump just searching the web...



Currently people from QPython are implementing Python 3.6. They already 
have a beta version. On google play is called "QPy3.6 - Python3.6 for 
QPython (BETA)". Disclaimer: I didn't test it.



--
Cholo Lennon
Bs.As.
ARG
--
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Steven D'Aprano]

On Tue, 20 Feb 2018 14:12:08 +0100, Anders Wegge Keller wrote:

> På Tue, 20 Feb 2018 12:28:25 + (UTC) Steven D'Aprano
>  skrev:
>> On Mon, 19 Feb 2018 16:34:29 +0100, Anders Wegge Keller wrote:
>> 
>> > På Mon, 19 Feb 2018 15:15:19 + (UTC) Steven D'Aprano
>> >  skrev:
>> >> On Mon, 19 Feb 2018 14:06:36 +0100, Anders Wegge Keller wrote:
>> >>   
>>  [...]
>> >> 
>> >> That's a mighty powerful claim that goes against the documentation
>> >> for the array module. Can you back your claims up?
>> >> 
>> >> Here's an array and a list:
>> > 
>> >  Make me an array of tuples with two integers and a string, and we
>> >  can talk.
>> 
>> The array module's failure to support the specific type you want has no
>> bearing on whether or not Python is statically typed.
> 
>  You claimed Array could do what I requested, i.e. container type that
> guaranteed only one type inside.

And that's exactly what array does: it guarantees only one type inside. 
It doesn't happen to be the type you want (a tuple of two integers and a 
string), but that's irrelevant to the question of whether the arrays and 
their content are strongly typed or not.

If you want to say that array doesn't solve your problem, I have no 
argument with that. I'm not surprised: array is intentionally a very 
restricted type. I mentioned it as an example of something *similar* to 
what you want: a homogeneous sequence type with strong typing. I never 
said it would solve your (unknown, unstated) problems.

https://mail.python.org/pipermail/python-list/2018-February/730916.html



> Furthermore, you are misrepresenting C with malice.

Am I? With *malice* you say. What gives you such insight into my state of 
mind?

I don't think I've said very much about C except to say that it's known 
to not be type-safe. I don't think that ought to be controversial to 
anyone. C and C++ are well-known to be unsafe languages:

https://blog.regehr.org/archives/213

and type-safety is a subset of that. That's why there's so much interest 
in new languages like Go and Rust. But I also suggested that some level 
of type-unsafety is probably unavoidable for a systems language.

But okay, if I've misrepresented something about C, please explain, I'm 
happy to learn better.


>  I don't care why you feel that a simple observation is a personal
>  attack,

Who mentioned anything about a personal attack?

You're making technical claims that Python values aren't strongly typed. 
I think you're wrong, and said so, but offered to admit that *I* was 
wrong if you can demonstrate the correctness of your claims by actually 
changing the type of a list or array object in Python.

You've been unable to do so.

Rather than engage in good faith discussion, you're now trying to 
distract by making insinuations about my character (claiming I'm acting 
out of "malice", making me out to be complaining about "personal 
attacks") and now personal insults:

> but I see you behave as a spoiled kid.

> go and pout in your corner.


The bottom line is, you've made technical claims that you are unable to 
support. If you can back up those claims, then I will learn something. 
How about you?



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Any users of statistics.mode() here?

[Steven D'Aprano]

statistics.mode() currently raises an exception if there is more than one 
mode.

Is anyone using this function in production? Or not using it because it 
doesn't do what you want, as the case may be?


-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Ian Kelly]

On Tue, Feb 20, 2018 at 8:38 AM, Steven D'Aprano
 wrote:
> On Tue, 20 Feb 2018 15:23:44 +0100, Antoon Pardon wrote:
>
>>> Okay. Now create a constraint on a name in C++ such that it can only
>>> accept integers representing A.D. years which, on the Gregorian
>>> calendar, are leap years. (Using a dedicated integer-like type is
>>> permitted.) It must accept all multiples of four, except those which
>>> are multiples of one hundred, unless they're also multiples of four
>>> hundred.
>>>
>>> That's what Steve asked for. Can you do it? Or is the C++ type system
>>> not flexible enough for that?
>>
>> Steve had multiple contributions in this thread. I didn't react to the
>> one where he asked for that.
>
> Yes you did: you refused to meet the challenge, stating (and I quote):
>
> "Why should this be done at compile time?"
>
> https://mail.python.org/pipermail/python-list/2018-February/730995.html

I really don't understand what point you're driving at here, Steven.
The original claim (by you) was that dynamic languages excel at
"enforcing constraints at run-time which are hard to enforce at
compile-time". The counter-argument, as I understand, it was that
while the constraints may be hard to enforce at compile-time, they are
just as easy to enforce at run-time in a static language as in a
dynamic language, so that can't really be considered a *strength* per
se of dynamic languages. You then followed this up by issuing a
challenge to enforce this as a compile-type check in C++.

Obviously this has not been done [1], but just as obviously it could
not be done at compile-time in a dynamic language either, so I don't
see how any of this justifies your claim that being a static language
somehow makes constraints harder to enforce.

[1] But I have no doubt that it could be done in a language with a
sufficiently advanced type system. Just by way of example, the Haskell
wiki offers an example of quicksort implemented in the Haskell type
system: 
https://wiki.haskell.org/Type_arithmetic#An_Advanced_Example_:_Type-Level_Quicksort
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Are the critiques in "All the things I hate about Python" valid?

[Wild, Marcel, Prof]

I scarcely know Python, and I have no intention delving into it further.
 I was forced to use Python because it features binary decision diagrams, which 
MATHEMATICA doesn't. Coming from Mathematica the account of Nathan Murphy reads 
like a nightmare.

The one point that stroke me the most was the schism between Python 2 and 3. No 
such thing with Mathematica: All its 11 or more versions are fully compatible, 
I never experienced any problems in this regard.

Another point is the bad online help provided to "teach yourself" Python. For 
instance, it took me more than an hour to find out how to negate a Boolean 
variable, whereas in Mathematica you would just type "Negation" in the Wolfram 
Documentation search window, and get the information you need.

I know one pays for Mathematica whereas Python is open source, but I've come to 
realize now that this money is very well spent!

Question: Apart from a few commands not available in Mathematica, such as 
expr2bdd, is there really any domain of computation where Mathematica is 
inferior to Python?

Marcel

-Original Message-
From: Python-list [mailto:python-list-bounces+mwild=sun.ac...@python.org] On 
Behalf Of bartc
Sent: 19 February 2018 02:35 PM
To: python-list@python.org
Subject: Re: Are the critiques in "All the things I hate about Python" valid?

On 19/02/2018 02:59, Chris Angelico wrote:
> On Mon, Feb 19, 2018 at 1:14 PM, bartc  wrote:

>> How would even a type for the odd numbers from 1 to 10 inclusive work?
>> (That, a type consisting of one of the values in {1,3,5,7,9}.) Would
>> they be ordered or unordered? Can I do arithmetic with them: will 3*3
>> work, but not 3*5?
>
> The type is "positive odd number below ten" and could be written as
> int(1..9|1%2). That is an orderable type; you can say that 3 < 7, for
> instance. And yes, arithmetic would be defined just fine;

Sometimes, the reason for creating a special numerical type is precisely so you 
can't do arithmetic on them, if it's not meaningful for the type.

So the special type of the values 65..90 might not allow the type be multiplied 
or divided, or added to itself. Because they represent characters A..Z. Or 
house numbers. Or the age of pensioners. (You'd need to convert to ordinary 
integers, is that is allowed.)

  there's no
> requirement for the result of an operation to have the same type as
> its inputs:

>
 5 / 2 # two integers
> 2.5

Try that when the type of {1..13} represents playing card ordinal values.

Type systems get rapidly very complicated when you have to deal with arbitrary 
sets of values and with arbitrary rules of interaction.
Someone has to devise a programming language to allow all that without tying 
itself up in knots. Someone else has to program in it. And someone else has to 
try and understand it!

Ones like C++ has already tied itself itself up in knots just doing the basics; 
I'm not sure how it would handle even my 1,3,5,7,9 type.

But Python has classes and can do some of this stuff; how would it handle a 
numeric type that is constrained to be whole numbers within
0..9 inclusive?

--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
The integrity and confidentiality of this email is governed by these terms / 
Die integriteit en vertroulikheid van hierdie e-pos word deur die volgende 
bepalings gereël. http://www.sun.ac.za/emaildisclaimer
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Rick Johnson]

On Tuesday, February 20, 2018 at 9:40:37 AM UTC-6, Steven D'Aprano wrote:
[...]
> Yes you did: you refused to meet the challenge, stating (and I quote):

I'm always entertained by Steven's so-called "challenges". You see, Steven is
addicted to winning, and he'll do anything to win a debate, even construct a
challenge that is obviously untenable. A typical example of Steven's
absurd challenges goes something like this:


from absurd.challenges.missonimpossible import Message

body = """
MISSON: MOVE YOURSELF FROM YOUR CURRENT POSITION ON THE
ON THIS EARTH TO THE TOP OF THE EIFFEL TOWER IN PARIS,
FRANCE.

CAVEAT_1: You cannot use public or private modes of
transportation. Including, (but not limited to): planes,
trains automobiles, boats, jet-skis, roller- skates,
skate boards, kites, gliders, bicycles, tricycles,
unicycles, big- wheels, hot-air balloons, magic carpets,
etc...

CAVEAT_2: Neither may you move yourself using your own
forms of bodily locomotion. Including (but not limited
to): crawling, walking, running, jogging, rolling,
skipping, jumping, hopping, cartwheels, backflips,
etc...

CAVEAT_3: Neither may you utilize the animal kingdom to
transport yourself. Including (but not limited to):
Being carried by an army of ants, a flock of birds, a
gang of gorilla, or a pod of orca, etc...

CAVEAT_4: If you happen to be at the top of the Eiffel
tower upon learning of this challenge, it doesn't count.
But please do post a pic on Instagram, as i rather enjoy
a good view. Thanks :-)

CAVEAT_5: Teleportation is strictly forbidden! Although
it'd be a neat trick. And if you have a working
prototype i'd love to stop by for a personal
demonstration and have a chance to make copies of the
schematics and the code base. (for documentation
purposes only, of course)

This is your misson, should you choose to accept it...
"""

if __name__ == '__main__':
msg = Message(title="Loco-motion", body=body)
msg.play_async("misson_impossible.mp3")
print msg
msg.after(10, exit)
raw_input('\nThis message will self destruct in ~10 seconds...')

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Richard Damon]

> On Feb 20, 2018, at 8:58 AM, Chris Angelico  wrote:
> 
>> On Wed, Feb 21, 2018 at 12:53 AM, Antoon Pardon  wrote:
>> In C++ I can do something like:
>> 
>>  SomeClass MyVar;
>> 
>> And after that the kind of possible assignments to MyVar are constraint. It
>> makes the runtime throw an error when somewhere the program tries to assign
>> something to MyVar that isn't allowed by SomeClass.
>> 
>> You can't put such constraints on names in Python.
>> 
>> In C++ I can do some like:
>>Some_Class: MyVar;
>> 
>> And after that, It will be impossible to assign a value to MyVar that
>> doesn't meet the
>> constraints imposed by the constructor/copy operator. You have put
>> somekind of
>> contract on the name MyVar, that limits the kind of things assignable to
>> it. You
>> can't put such constraints on a name in Python.
> 
> Okay. Now create a constraint on a name in C++ such that it can only
> accept integers representing A.D. years which, on the Gregorian
> calendar, are leap years. (Using a dedicated integer-like type is
> permitted.) It must accept all multiples of four, except those which
> are multiples of one hundred, unless they're also multiples of four
> hundred.
> 
> That's what Steve asked for. Can you do it? Or is the C++ type system
> not flexible enough for that?
> 
> ChrisA
> -- 
> https://mail.python.org/mailman/listinfo/python-list

Such a class would be fairly trivial to write in C++, or I suspect Python.

In C++ you would have a constructor and possibilities an assignment operator 
that takes an integer, tests it for validity and throw/asserts if it is 
incorrect. (Depending on other requirements, you might allow or not implicit 
conversions)
It probably also has a constructor and an assignment operator that takes a 
‘LeapYear’ and just uses it.
To be usable, it will need something to allow you to get the integer value out, 
might be implicit or explicit.

The big issue with such a type, and why it doesn’t make much sense as a type, 
is that there is very little that can be done with such a type, as there is no 
interesting operation for which the type is at least mostly closed under, at 
best it is closed under +400*n
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Rhodri James]

On 20/02/18 17:11, Wild, Marcel, Prof  wrote:

I scarcely know Python, and I have no intention delving into it further.
  I was forced to use Python because it features binary decision diagrams, 
which MATHEMATICA doesn't. Coming from Mathematica the account of Nathan Murphy 
reads like a nightmare.



I have to admit, I have no idea what you're talking about.  I suspect, 
though, that you would find a similar discussion of any other 
programming language at least as nightmarish.



The one point that stroke me the most was the schism between Python 2 and 3. No 
such thing with Mathematica: All its 11 or more versions are fully compatible, 
I never experienced any problems in this regard.


The schism is not as wide as you are implying.  Aside from "print" 
becoming a function, which is blindingly obvious whenever you trip over 
it, there is relatively little reason why an ordinary Pythonista would 
care whether he or she was running Python 2 or Python 3.  Python 3.5 vs 
Python 3.7 is much more likely to be a relevant question, because of 
course Python has evolved new features over time.


The statement "all its [...] versions are fully compatible" implies 
Mathematica hasn't evolved over those versions.  I sincerely doubt that 
is true.



Another point is the bad online help provided to "teach yourself" Python. For instance, 
it took me more than an hour to find out how to negate a Boolean variable, whereas in Mathematica 
you would just type "Negation" in the Wolfram Documentation search window, and get the 
information you need.


This is likely to be a personal thing.  Mathematica ties you firmly to 
its IDE; you get all the bells and whistles of that IDE, but only the 
bells and whistles of that IDE.  Python doesn't tie you to anything in 
particular, so you have to provide your own bells and whistles (but can 
provide any you can find or create).


That said, you are not making a good case for your research skills. 
Googling "python boolean negation" got me the information in under a 
minute, including the Firefox startup time.  Reading through the Boolean 
Expressions part of the online documentation at docs.python.com took 
little longer, though admittedly that isn't meant for beginners.  Even 
firing up a Python interpreter and typing


>>> help("not")

didn't take that long (and honestly, "negation" is not the first word I 
think of when inverting booleans).




I know one pays for Mathematica whereas Python is open source, but I've come to 
realize now that this money is very well spent!

Question: Apart from a few commands not available in Mathematica, such as 
expr2bdd, is there really any domain of computation where Mathematica is 
inferior to Python?


Not knowing much about Mathematica, all I can say is "almost certainly."

--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Ben Finney]

"Wild, Marcel, Prof "  writes:

> I scarcely know Python, and I have no intention delving into it
> further.

That's fine. This is a forum for those who do have an ongoing interest
in Python. I think your needs would be better served elsewhere.

-- 
 \   “Prediction is very difficult, especially of the future.” |
  `\   —Niels Bohr |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[bartc]

On 20/02/2018 19:04, Dennis Lee Bieber wrote:

On Tue, 20 Feb 2018 17:11:05 +, "Wild, Marcel, Prof "
 declaimed the following:



So the special type of the values 65..90 might not allow the type be multiplied 
or divided, or added to itself. Because they represent characters A..Z. Or 
house numbers. Or the age of pensioners. (You'd need to convert to ordinary 
integers, is that is allowed.)



Off-hand -- if you are storing the /age of pensioners/, you have an
inappropriate data model... Age being a time varying value computed as:
time_now - date_of_birth
and date_of_birth is the proper entity for storage...


If you wanted a scientifically exact value, maybe.

But someone who's 24.157094 years old now won't say their age is 
24.157094 (and 24.157104 five minutes later). They will usually say they 
are 24, until they are 25 (much older people prefer to round upwards, 
for some reason).


So age is usually colloquially specified as an integer from 1 to around 
100. Other than for young children where the lack of precision requires 
the use of fractions or to switch to whole numbers of months or weeks.



--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Grant Edwards]

On 2018-02-20, Rhodri James  wrote:

> The schism is not as wide as you are implying.  Aside from "print" 
> becoming a function, which is blindingly obvious whenever you trip over 
> it, there is relatively little reason why an ordinary Pythonista would 
> care whether he or she was running Python 2 or Python 3.

Any ordinary Pythonista to deals with raw data "bytes" cares a great
deal.  There are major differences between the Py2 and Py3 in that
area, and they're a royal PITA to deal with.

-- 
Grant Edwards   grant.b.edwardsYow! Are you mentally here
  at   at Pizza Hut??
  gmail.com

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid? (Posting On Python-List Prohibited)

[bartc]

On 20/02/2018 19:35, Lawrence D’Oliveiro wrote:

On Wednesday, February 21, 2018 at 1:43:41 AM UTC+13, bartc wrote:

In Pascal (and presumably Ada) then all the
gubbins need to make this work properly:

var x: 1..10;

x = 10;
x = x + 1;   { error? }


Error on both statements. Pascal doesn’t allow a statement to just consist of 
an expression. At least, it didn’t the last time I checked.


OK, I forgot it needs := for assignment.


Besides, it’s not clear what the point is of doing a comparison between those 
terms and throwing the result away.


Many languages including Python allow exactly that.

(The ones I create make it an error. Only certain kinds of expression 
terms also have versions that can meaningfully be independent statements.)


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[MRAB]

On 2018-02-20 19:17, bartc wrote:

On 20/02/2018 19:04, Dennis Lee Bieber wrote:

On Tue, 20 Feb 2018 17:11:05 +, "Wild, Marcel, Prof "
 declaimed the following:



So the special type of the values 65..90 might not allow the type be multiplied 
or divided, or added to itself. Because they represent characters A..Z. Or 
house numbers. Or the age of pensioners. (You'd need to convert to ordinary 
integers, is that is allowed.)



Off-hand -- if you are storing the /age of pensioners/, you have an
inappropriate data model... Age being a time varying value computed as:
time_now - date_of_birth
and date_of_birth is the proper entity for storage...


If you wanted a scientifically exact value, maybe.

But someone who's 24.157094 years old now won't say their age is
24.157094 (and 24.157104 five minutes later). They will usually say they
are 24, until they are 25 (much older people prefer to round upwards,
for some reason).

So age is usually colloquially specified as an integer from 1 to around
100. Other than for young children where the lack of precision requires
the use of fractions or to switch to whole numbers of months or weeks.

The point he was making is that if you store a person's age, you'd have 
to update it every year. It's far better to store the date of birth and 
calculate the age on demand.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Any users of statistics.mode() here?

[Jason Friedman]

> statistics.mode() currently raises an exception if there is more than one
> mode.
>

I am an infrequent user of this package and this function.  My two cents:
* Leave the current behavior as-is.
* Continue to throw an exception for no data.
* Add an argument, named perhaps mutli=False, that if set to True causes
the function to a return a list of modes, including if there is only a
single mode.  statistics.mode((1, 2, 2, 3, 3, 4, 4, 5), multi=True) would
return [2, 3, 4].
* Would still throw StatisticsError if no data or if every element occurs
exactly the same number of times (for example,
statistics.mode(range(10), multi=True))
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Rick Johnson]

On Tuesday, February 20, 2018 at 2:18:31 PM UTC-6, MRAB wrote:

> The point he was making is that if you store a person's age, you'd have 
> to update it every year. It's far better to store the date of birth and 
> calculate the age on demand.

*AHEM*

At the risk of being labeled a "quibbler" (which, in the
grander scheme is not really all that bad considering some
of the names that have been attributed to me), i must say
your advice is only "sound advice" in cases where the age
will not be queried frequently.

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 last second of every year,
instead of doing the age calculation many times a second.
Heck, even if the frequency is multiple time a day, a valid
argument could be made.

Of course. Outside of buggy loop that, much to the chagrin
of the code monkey who wrote it waxes infinite, i cannot
image many scenarios in which someone's age would be queried
many times a second.

But hey, this is Python-list after all. And i wouldn't be a
true pal i didn't point out an implicit corner case.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[bartc]

On 20/02/2018 20:17, MRAB wrote:

On 2018-02-20 19:17, bartc wrote:

On 20/02/2018 19:04, Dennis Lee Bieber wrote:
On Tue, 20 Feb 2018 17:11:05 +, "Wild, Marcel, Prof 
"

 declaimed the following:



So the special type of the values 65..90 might not allow the type be 
multiplied or divided, or added to itself. Because they represent 
characters A..Z. Or house numbers. Or the age of pensioners. (You'd 
need to convert to ordinary integers, is that is allowed.)



Off-hand -- if you are storing the /age of pensioners/, you have an
inappropriate data model... Age being a time varying value computed as:
    time_now - date_of_birth
and date_of_birth is the proper entity for storage...


If you wanted a scientifically exact value, maybe.

But someone who's 24.157094 years old now won't say their age is
24.157094 (and 24.157104 five minutes later). They will usually say they
are 24, until they are 25 (much older people prefer to round upwards,
for some reason).

So age is usually colloquially specified as an integer from 1 to around
100. Other than for young children where the lack of precision requires
the use of fractions or to switch to whole numbers of months or weeks.

The point he was making is that if you store a person's age, you'd have 
to update it every year. It's far better to store the date of birth and 
calculate the age on demand.


People are making too much of my example of a type consisting of a set 
of special values.


Anyway the values might not relate to an individual; they could be 
indices into a data structure so that C[65] gives you the number of 
65-year-olds or something, or 67 is the age at which someone is entitled 
to a pension.


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Chris Angelico]

On Wed, Feb 21, 2018 at 7:42 AM, Rick Johnson
 wrote:
> On Tuesday, February 20, 2018 at 2:18:31 PM UTC-6, MRAB wrote:
>
>> The point he was making is that if you store a person's age, you'd have
>> to update it every year. It's far better to store the date of birth and
>> calculate the age on demand.
>
> *AHEM*
>
> At the risk of being labeled a "quibbler" (which, in the
> grander scheme is not really all that bad considering some
> of the names that have been attributed to me), i must say
> your advice is only "sound advice" in cases where the age
> will not be queried frequently.
>
> 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 last second of every year,
> instead of doing the age calculation many times a second.
> Heck, even if the frequency is multiple time a day, a valid
> argument could be made.

Nope. Even if you need the age many times per second, it's still
better to store the date of birth, because you eliminate boundary
conditions and duplicated data. But that's assuming you're storing the
age of *a person*. If the age in question is a boundary ("motor
insurance premiums are increased if the driver is 65 years or older"),
then it's still sane to store the age.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Any users of statistics.mode() here?

[MRAB]

On 2018-02-20 20:20, Jason Friedman wrote:

statistics.mode() currently raises an exception if there is more than one
mode.



I am an infrequent user of this package and this function.  My two cents:
* Leave the current behavior as-is.
* Continue to throw an exception for no data.
* Add an argument, named perhaps mutli=False, that if set to True causes
the function to a return a list of modes, including if there is only a
single mode.  statistics.mode((1, 2, 2, 3, 3, 4, 4, 5), multi=True) would
return [2, 3, 4].
* Would still throw StatisticsError if no data or if every element occurs
exactly the same number of times (for example,
statistics.mode(range(10), multi=True))

I think that it would be better to have a separate function instead of 
having the function sometimes return a single value and sometimes a list 
of values.


There's an interesting answer here:

http://mathforum.org/library/drmath/view/61375.html
--
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Christian Gollwitzer]

Am 20.02.18 um 14:58 schrieb Chris Angelico:

Okay. Now create a constraint on a name in C++ such that it can only
accept integers representing A.D. years which, on the Gregorian
calendar, are leap years. (Using a dedicated integer-like type is
permitted.) It must accept all multiples of four, except those which
are multiples of one hundred, unless they're also multiples of four
hundred.

That's what Steve asked for. Can you do it? Or is the C++ type system
not flexible enough for that?


It might be possible to do that with compile-time checking for 
compile-time constants. For runtime checking, you already got the answer 
- provide a


class LeapYear {
LeapYear(int y) {
if (!condition) throw std::runtime_eror();
}
operator = (int y) { ...also test and throw... }
};

then:

LeapYear y2000 = 2000; // works
y2000 = 2004; // works
y2000 = 2001; // throws an error

The difference to Python is that "a=b" and "a+=b" are similar in C++, in 
both cases you call a method on the object "a", whereas in Python the 
first one is handled independently of the type of "a".


If you insist in compile-time checking, I think it's possible, though 
I'm not one of those C++ wizards to implement it from up my sleeve. The 
basic technique will be that you make your LeapYear 
constructible/assignable from a static type only where constructino of 
the type fails if the condition is not met. So


class LeapYear {
...
template operator = (LeapYearCheck y)
{
// at this point, we are sure that LeapYearCheck succeeded
}
};

LeapYearCheck could be implemented using template metaprogramming 
(quite horrible) or the new funky constexpr feature in C++11/C++14 (less 
horrible).


However this will throw an error whenever the compiler can't prove that 
the year is a leap year, effectively only when it can be computed at 
compile time, which certainly limits the usefulness of this type.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Rick Johnson]

On Tuesday, February 20, 2018 at 2:51:56 PM UTC-6, Chris Angelico wrote:
[...]
> Nope. Even if you need the age many times per second, it's still
> better to store the date of birth, because you eliminate boundary
> conditions and duplicated data.

You failed to provide any examples proving this assertion of
yours. I can't imagine how either would be a problem.

> But that's assuming you're storing the age of *a person*.
> If the age in question is a boundary ("motor insurance
> premiums are increased if the driver is 65 years or
> older"), then it's still sane to store the age.

The boundary problem you outline here is a simple matter of
checking the age annually and increasing the premium if the
person is 65 years or older, and has nothing to do with
whether or not the age is calculated once a year or upon
every request.

def annual_probe(self, geriatricMarker=65):
self.age += 1
if self.age >= geriatricMarker:
self.increase_premium()

But obviously this "data" should reside in a database, not be
instanced into OO objects.

-- 
https://mail.python.org/mailman/listinfo/python-list

How to transform this as a service

[Maroso Marco]

Hi everyone, i need this program to run as a service.

This program basically check an email account (gmail) and looks if there is
mail from a specific email account, then reads the subject line and splits the 
text found assigning the left part (before the ; ) to the password, and the 
right part to the comand to be executed.
It should loop continuosly waiting a specific time given in a file called 
timing.ini (seconds)

My program seems to have a problem and i don't understand which! Firstly it 
worked and now just went to run it again and it doesnt. I have different 
versions of python installed on my pc.

Can someone please tell me how to transform it in a service to run on Windows?

I found some solutions but i don't understand how to implement it correctly
This is my code, any help is really apreciated, i'm loosing my nights on this 
and can't get it working.




import imaplib
import os
import email
import email.header
import time
import subprocess

def mailcontroller():

# Set user, pass and allowed mail for giving commands
plusmail = "anemailaddr...@gmail.com"
googlepass = "thepassword"
captain = "autorizedemailacco...@gmail.com"

# Set vars for IMAP access
M = imaplib.IMAP4_SSL('imap.gmail.com')
M.login(plusmail, googlepass)
M.select()

# Set search on UNSEEN messages
status, response = M.search(None, '(UNSEEN)')
unread_msg_nums = response[0].split()


# Mark as read
for e_id in unread_msg_nums:
M.store(e_id, '+FLAGS', '\Seen')

# cycle messages sent from autorized email address
typ, data = M.search(None, 'From',(captain))

for num in data[0].split():
typ, data = M.fetch(num, '(RFC822)')
msg = email.message_from_string(data[0][1])
decode = email.header.decode_header(msg['Subject'])[0]
subject = unicode(decode[0])
comando = subject

if googlepass in subject:

# print 'Message %s: %s' % (num, subject)
# Split subject line
googlepass,comando = subject.split(";")
# Execute command
#os.system(comando)
# Execute command with alternate method
subprocess.call(comando)
# Delete email
M.store(num, '+FLAGS', '\\Deleted')

M.close()
M.logout()

# Read ini file for timer settings
timing = open('timing.ini', 'r').read()
# Convert timer value from string to int
time.sleep(int(timing))

while True:
mailcontroller()










-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to transform this as a service

[Maroso Marco]

Il giorno martedì 20 febbraio 2018 23:42:27 UTC+1, Maroso Marco ha scritto:
> Hi everyone, i need this program to run as a service.
> 
> This program basically check an email account (gmail) and looks if there is
> mail from a specific email account, then reads the subject line and splits 
> the text found assigning the left part (before the ; ) to the password, and 
> the right part to the comand to be executed.
> It should loop continuosly waiting a specific time given in a file called 
> timing.ini (seconds)
> 
> My program seems to have a problem and i don't understand which! Firstly it 
> worked and now just went to run it again and it doesnt. I have different 
> versions of python installed on my pc.
> 
> Can someone please tell me how to transform it in a service to run on Windows?
> 
> I found some solutions but i don't understand how to implement it correctly
> This is my code, any help is really apreciated, i'm loosing my nights on this 
> and can't get it working.
> 
> 
> 
> 
> import imaplib
> import os
> import email
> import email.header
> import time
> import subprocess
> 
> def mailcontroller():
> 
> # Set user, pass and allowed mail for giving commands
> plusmail = "anemailaddr...@gmail.com"
> googlepass = "thepassword"
> captain = "autorizedemailacco...@gmail.com"
> 
> # Set vars for IMAP access
> M = imaplib.IMAP4_SSL('imap.gmail.com')
> M.login(plusmail, googlepass)
> M.select()
> 
> # Set search on UNSEEN messages
> status, response = M.search(None, '(UNSEEN)')
> unread_msg_nums = response[0].split()
> 
> 
> # Mark as read
> for e_id in unread_msg_nums:
> M.store(e_id, '+FLAGS', '\Seen')
> 
> # cycle messages sent from autorized email address
> typ, data = M.search(None, 'From',(captain))
> 
> for num in data[0].split():
> typ, data = M.fetch(num, '(RFC822)')
> msg = email.message_from_string(data[0][1])
> decode = email.header.decode_header(msg['Subject'])[0]
> subject = unicode(decode[0])
> comando = subject
> 
> if googlepass in subject:
> 
> # print 'Message %s: %s' % (num, subject)
> # Split subject line
> googlepass,comando = subject.split(";")
> # Execute command
> #os.system(comando)
> # Execute command with alternate method
> subprocess.call(comando)
> # Delete email
> M.store(num, '+FLAGS', '\\Deleted')
> 
> M.close()
> M.logout()
> 
> # Read ini file for timer settings
> timing = open('timing.ini', 'r').read()
> # Convert timer value from string to int
> time.sleep(int(timing))
> 
> while True:
> mailcontroller()

I would like to implement my code in something like this described here : 
http://www.chrisumbel.com/article/windows_services_in_python
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python on Android?

[Johannes Findeisen]

On Tue, 20 Feb 2018 23:12:23 +1100
Chris Angelico wrote:

> On Mon, Feb 19, 2018 at 3:57 AM, Johannes Findeisen  wrote:
> > On Sun, 18 Feb 2018 20:57:02 +1100
> > Chris Angelico wrote:
> >  
> >> Does anyone have experience with running Python scripts on Android
> >> phones? I have a brother (honestly! I'm not actually using a phone
> >> myself!) who's trying to run one of my scripts in QPython, which
> >> claims to be version 3.2.2. I think that really truly is a Python 3.2
> >> implementation - probing for newer features suggests that it actually
> >> doesn't even support the u"..." syntax that came (back) in with Python
> >> 3.3. So... does anyone know of a Python interpreter that's compatible
> >> with 3.4 or better and runs on Android?
> >>  
> >
> > There is an App for Android called "Pydroid 3". You can find it in
> > the Google Play Store [0]. It provides a Python interpreter in version
> > 3.6.2 in its current release.
> >
> > The Python binary is installed under
> >
> > /data/user/0/ru.iiec.pydroid3/files/arm-linux-androideabi/bin/python
> >
> > but I can not access it in a normal terminal without being user "root"
> > but it is usable from within the terminal included in the Pydroid App.  
> 
> Many thanks for all the suggestions. Pydroid is the one that has
> worked; he's now able to run stuff happily from the terminal. Next
> step is to create an icon that invokes it, but that's looking rather
> harder (probably means I'm going to have to learn Kivy, and I already
> have no shortage of projects...). Everything's working in the terminal
> (even a read-write $HOME, which we didn't have previously), and I'm
> pretty happy with that!
> 
> All suggestions were read and are appreciated, even though I'm only
> quoting the one we ended up going with. Thank you Kirill, MRAB, Abdur,
> and Johannes!

You're welcome!

Take a look at the "Kivy Launcher" App for Android if You don't want to
do deep learning of Kivy. With this App You can just copy some
Python code to the Kivy launcher directory "/sdcard/kivy/"
and execute it with just one click without packaging your own APK file.

Don't know which Python version is included in Kivy Launcher and believe
it is 2.7. but it think Kivy will go over to Python 3.* in the near
future.

Johannes
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Steven D'Aprano]

On Tue, 20 Feb 2018 17:11:05 +, Wild, Marcel, Prof 
wrote:

> I scarcely know Python, and I have no intention delving into it further.
>  I was forced to use Python because it features binary decision
>  diagrams, which MATHEMATICA doesn't. Coming from Mathematica the
>  account of Nathan Murphy reads like a nightmare.

I dare say that was Nathan Murphy's intention. But the ironic thing is 
that by Murphy's standards, Mathematica suffers the same flaws as Python: 
it to is a dynamically typed language with little or no compile-time type 
safety.



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Steven D'Aprano]

On Tue, 20 Feb 2018 22:19:13 +0100, Christian Gollwitzer wrote:

[...]
> LeapYearCheck could be implemented using template metaprogramming
> (quite horrible) or the new funky constexpr feature in C++11/C++14 (less
> horrible).

Thanks Christian. That's certainly interesting, I don't know much about 
template metaprogramming so TIL.

 

-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to transform this as a service

[Steven D'Aprano]

On Tue, 20 Feb 2018 14:41:42 -0800, Maroso Marco wrote:

> My program seems to have a problem and i don't understand which! Firstly
> it worked and now just went to run it again and it doesnt.
[...]
> Can someone please tell me how to transform it in a service to run on
> Windows?

There is absolutely no point in spending time and effort transforming it 
to a service if your program doesn't work. First you need to fix the 
program so that it can reliably and repeatedly work.


Start by explaining, what do you mean by "doesn't work"? Does it:

- raise an exception;

- silently sit and do nothing for hours;

- cause the computer to catch fire;

- something else?

Explain what you expect the script to do, and what it actually does 
instead.

If there is an exception or error, please COPY AND PASTE the EXACT error 
message, if possible. Don't retype it from memory, summarise it, or take 
a screen shot.

How are you running your script? To make it usable as a service, first 
you have to make sure it is usable from the system command prompt 
(command.com, cmd.exe, PowerShell, or whatever you use on Windows these 
days).

Are you sure you are running your script using the right Python version? 
How do you know?



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python on Android?

[Johannes Findeisen]

On Wed, 21 Feb 2018 00:11:24 +0100
Johannes Findeisen wrote:

> On Tue, 20 Feb 2018 23:12:23 +1100
> Chris Angelico wrote:
> 
> > On Mon, Feb 19, 2018 at 3:57 AM, Johannes Findeisen  
> > wrote:  
> > > On Sun, 18 Feb 2018 20:57:02 +1100
> > > Chris Angelico wrote:
> > >
> > >> Does anyone have experience with running Python scripts on Android
> > >> phones? I have a brother (honestly! I'm not actually using a phone
> > >> myself!) who's trying to run one of my scripts in QPython, which
> > >> claims to be version 3.2.2. I think that really truly is a Python 3.2
> > >> implementation - probing for newer features suggests that it actually
> > >> doesn't even support the u"..." syntax that came (back) in with Python
> > >> 3.3. So... does anyone know of a Python interpreter that's compatible
> > >> with 3.4 or better and runs on Android?
> > >>
> > >
> > > There is an App for Android called "Pydroid 3". You can find it in
> > > the Google Play Store [0]. It provides a Python interpreter in version
> > > 3.6.2 in its current release.
> > >
> > > The Python binary is installed under
> > >
> > > /data/user/0/ru.iiec.pydroid3/files/arm-linux-androideabi/bin/python
> > >
> > > but I can not access it in a normal terminal without being user "root"
> > > but it is usable from within the terminal included in the Pydroid App.
> > 
> > Many thanks for all the suggestions. Pydroid is the one that has
> > worked; he's now able to run stuff happily from the terminal. Next
> > step is to create an icon that invokes it, but that's looking rather
> > harder (probably means I'm going to have to learn Kivy, and I already
> > have no shortage of projects...). Everything's working in the terminal
> > (even a read-write $HOME, which we didn't have previously), and I'm
> > pretty happy with that!
> > 
> > All suggestions were read and are appreciated, even though I'm only
> > quoting the one we ended up going with. Thank you Kirill, MRAB, Abdur,
> > and Johannes!  
> 
> You're welcome!
> 
> Take a look at the "Kivy Launcher" App for Android if You don't want to
> do deep learning of Kivy. With this App You can just copy some
> Python code to the Kivy launcher directory "/sdcard/kivy/"
> and execute it with just one click without packaging your own APK file.
> 
> Don't know which Python version is included in Kivy Launcher and believe
> it is 2.7. but it think Kivy will go over to Python 3.* in the near
> future.

I forgot the link to the documentation...

https://kivy.org/docs/guide/packaging-android.html#packaging-your-application-for-kivy-launcher

Johannes
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Steven D'Aprano]

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 last second of every year

Do you really mean to say that everybody in the world has their birthday 
on January 1st? We're not racehorses you know.

Under your scheme, 99.7% of records will return the wrong age (off by 
one) at least once per year. Statistically, 50% of queries will be wrong.


-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: could use some help with this problem! (Posting On Python-List Prohibited)

[Ben Bacarisse]

Lawrence D’Oliveiro  writes:

> On Wednesday, February 21, 2018 at 3:10:25 AM UTC+13, Ben Bacarisse wrote:
>> You almost never /have/ to use nested loops.  Has the course got this
>> far without introducing the idea of a function?
>
> If you are using a function to avoid a nested loop, perhaps that’s not
> such a smart use of a function...

Agreed.  And yet it /might/ be a smart use of one.  Nothing about simply
avoiding a loop is sufficient to make the assessment.

-- 
Ben.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Steven D'Aprano]

On Tue, 20 Feb 2018 10:17:12 -0700, Ian Kelly wrote:

> On Tue, Feb 20, 2018 at 8:38 AM, Steven D'Aprano
>  wrote:
>> On Tue, 20 Feb 2018 15:23:44 +0100, Antoon Pardon wrote:
>>
 Okay. Now create a constraint on a name in C++ such that it can only
 accept integers representing A.D. years which, on the Gregorian
 calendar, are leap years. (Using a dedicated integer-like type is
 permitted.) It must accept all multiples of four, except those which
 are multiples of one hundred, unless they're also multiples of four
 hundred.

 That's what Steve asked for. Can you do it? Or is the C++ type system
 not flexible enough for that?
>>>
>>> Steve had multiple contributions in this thread. I didn't react to the
>>> one where he asked for that.
>>
>> Yes you did: you refused to meet the challenge, stating (and I quote):
>>
>> "Why should this be done at compile time?"
>>
>> https://mail.python.org/pipermail/python-list/2018-February/730995.html
> 
> I really don't understand what point you're driving at here, Steven.

To be perfectly frank, neither do I any more. I fear I've been suckered 
into taking a position I didn't intend to, as often happens when I reply 
to Antoon Pardon.

Obviously both statically and dynamically typed languages are Turing 
Complete, so any constraint you can apply at run-time in one you can 
apply at run-time in the other. How *easy* that is depends on the 
language features, and particularly for older languages, statically typed 
languages tend to be harder and less convenient to write in. There's 
typically more boilerplate, and more time spent placating the type-
checker. Do I need to justify this or can we take it as a given?

So I didn't think I was taking a controversial position to say that 
dynamic languages are good for writing constraints that are enforced at 
run-time, *as opposed to trying to do so within the type-system* which 
was the topic under discussion.

I have argued in the past that the hard distinction between static and 
dynamic languages has been gradually worn away (if it ever existed at 
all!) as statically-typed languages add dynamic features, and dynamically-
typed languages add static features. For example, Java supports run-time 
method dispatch; Python added type annotations to standardise on syntax 
for static type testing.

Antoon's example of Pascal range checking is another run-time feature (a 
form of dynamic typing, in a fifty year old statically typed language no 
less!), as are Eiffel pre- and post-condition assertions (although the 
compiler can optimize them away if it can determine that they always 
hold). I've linked to Steve Yegge a lot,  e.g.:

https://
steve-yegge.blogspot.com.au/2008/05/dynamic-languages-strike-back.html

so I certainly know that there's a certain amount of convergence between 
static and dynamic features and it was never my intention to suggest that 
statically-typed code can't validate values at run-time. That would be a 
ludicrous position to take.

If Antoon was arguing in good faith surely he must have realised I 
couldn't have meant that. By all means call me out on factual 
inaccuracies, but do so in good faith. Don't assume I mean something 
ludicrous.


If you look back at my reply to Bart:

https://mail.python.org/pipermail/python-list/2018-February/730943.html

you will see that the context is a discussion comparing:

compile-time static analysis 

versus 

run-time dynamic checks

strategies. Hence my challenge to perform the same kind of check at 
compile-time using an actual, existing type-system. (Not merely say a 
sufficiently clever type-system can do it and handwave away the practical 
difficulties.)

Of course we can perform arbitrarily complex run-time checks in a 
language with static typing (it might not be as convenient or easy, 
especially if you have to declare every single temporary variable, do a 
lot of explicit casts, never re-use any variable, and use a lot of 
verbose boilerplate, but it can be done).


> The
> original claim (by you) was that dynamic languages excel at "enforcing
> constraints at run-time which are hard to enforce at compile-time". The
> counter-argument, as I understand, it was that while the constraints may
> be hard to enforce at compile-time, they are just as easy to enforce at
> run-time in a static language as in a dynamic language, so that can't
> really be considered a *strength* per se of dynamic languages.

Fair enough -- I acknowledge there's something to what you say, even if I 
wouldn't say it that way.

But in which case, if dynamically typed languages are no easier to use 
than statically typed ones, and no faster, and no more secure, why do 
people use them?

The conventional answer is that they are easier to use, hence more rapid 
prototyping and application development. But if we say that static typed 
languages are *just as easy to use* then the existence and popularity of 
Python, Ruby, Javascript, Perl, Smalltalk, L

Re: Are the critiques in "All the things I hate about Python" valid?

[Chris Angelico]

On Wed, Feb 21, 2018 at 9:01 AM, Rick Johnson
 wrote:
> On Tuesday, February 20, 2018 at 2:51:56 PM UTC-6, Chris Angelico wrote:
> [...]
>> Nope. Even if you need the age many times per second, it's still
>> better to store the date of birth, because you eliminate boundary
>> conditions and duplicated data.
>
> You failed to provide any examples proving this assertion of
> yours. I can't imagine how either would be a problem.

https://en.wikipedia.org/wiki/Database_normalization

I'm not going to do your research for you.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Geldenhuys, J, Prof]

Hi Marcel,

I have read through the article and it seems to me that all of the problems 
described boil down to one important point: use the right tool for the right 
job.  Python is probably not the best language for developing large, complex 
systems (although there are such systems).  Most (or all?) of the concerns that 
Murthy raises (dynamic typing, support for multithreading, performance, 
Python2/3, encapsulation) speak to that.  He is not wrong about any of the 
points, but it could be said that he is expecting too much.  We don't expect a 
carpenter with a hammer to build an entire apartment building, and we don't 
expect a big construction company to build a coffee table.

Python does have many desirable features: it is easy to learn and the code is 
relatively clear.  It is available on most platforms (I can run it directly on 
my phone), and it is easy to port to new platforms.  There are many things that 
Mathematica can do that Python can't, and vice versa.  Right tool/right job.  I 
have often used Python to build prototypes to see if an algorithm works, but 
then I use a more efficient language (like Java or C) for the "real" 
implementation.

Out of interest, Mathematica itself is written in C, C++, and Java, and 
consists of a few million lines of code.  Python has several implementations; 
the "reference" implementation is CPython which is written in C and consists of 
 ~540,000 lines of code.  Because Python is open-source, it has the strengths 
(many contributors) and weaknesses (more difficult to coordinate development) 
that comes from this paradigm.

As far as the documentation is concerned, Python is considered a 
well-documented language.  Of course, individual libraries may not be, but as 
it happens, pyeda has good documentation 
(http://pyeda.readthedocs.io/en/latest/).  I think you may just have been 
unlucky not to have found it.

I think your case illustrates the Python/Mathematica issue well:  you found a 
job for which Mathematica was not the perfect tool and you used Python.  At the 
end of the day, both M & P have their place.  For example, we probably won't 
use either to teach Introduction Computer Science soon, because they both lack 
features that we expect our students to be familiar with at the end of their 
first year.



Prof Jaco Geldenhuys
Medeprofessor: Rekenaarwetenskap  |  Associate Professor: Computer Science
Fakulteit Natuurwetenskappe  |  Faculty of Science
e: g...@sun.ac.za  |  t: +27 21 808 4232  |  a: Algemene Ingenieurswese Gebou 
A519  |  General Engineering Building A519
  
 
 

 
 


On 2018/02/20, 19:11, "Wild, Marcel, Prof "  
wrote:

I scarcely know Python, and I have no intention delving into it further.
 I was forced to use Python because it features binary decision diagrams, 
which MATHEMATICA doesn't. Coming from Mathematica the account of Nathan Murphy 
reads like a nightmare.

The one point that stroke me the most was the schism between Python 2 and 
3. No such thing with Mathematica: All its 11 or more versions are fully 
compatible, I never experienced any problems in this regard.

Another point is the bad online help provided to "teach yourself" Python. 
For instance, it took me more than an hour to find out how to negate a Boolean 
variable, whereas in Mathematica you would just type "Negation" in the Wolfram 
Documentation search window, and get the information you need.

I know one pays for Mathematica whereas Python is open source, but I've 
come to realize now that this money is very well spent!

Question: Apart from a few commands not available in Mathematica, such as 
expr2bdd, is there really any domain of computation where Mathematica is 
inferior to Python?

Marcel

-Original Message-
From: Python-list [mailto:python-list-bounces+mwild=sun.ac...@python.org] 
On Behalf Of bartc
Sent: 19 February 2018 02:35 PM
To: python-list@python.org
Subject: Re: Are the critiques in "All the things I hate about Python" 
valid?

On 19/02/2018 02:59, Chris Angelico wrote:
> On Mon, Feb 19, 2018 at 1:14 PM, bartc  wrote:

>> How would even a type for the odd numbers from 1 to 10 inclusive work?
>> (That, a type consisting of one of the values in {1,3,5,7,9}.) Would
>> they be ordered or unordered? Can I do arithmetic with them: will 3*3
>> work, but not 3*5?
>
> The type is "positive odd number below ten" and could be written as
> int(1..9|1%2). That is an orderable type; you can say that 3 < 7, for
> instance. And yes, arithmetic would be defined just fine;

Sometimes, the reason for creating a sp

Re: Are the critiques in "All the things I hate about Python" valid?

[Chris Angelico]

On Wed, Feb 21, 2018 at 6:39 AM, Geldenhuys, J, Prof 
 wrote:
> I think your case illustrates the Python/Mathematica issue well:  you found a 
> job for which Mathematica was not the perfect tool and you used Python.  At 
> the end of the day, both M & P have their place.  For example, we probably 
> won't use either to teach Introduction Computer Science soon, because they 
> both lack features that we expect our students to be familiar with at the end 
> of their first year.
>

Out of curiosity, what features does Python lack in that area? (I
don't know anything about Mathematica, and it's only tangentially
on-topic at best.) For an intro to comp sci, I would generally expect
to start with a high level language such as Python, or JavaScript
(because of its ubiquity, primarily due to web browser usage), or Ruby
(particularly if you're Japanese). You don't learn about how to manage
memory (because it's done for you), but on the other hand, you don't
learn about how to manage memory (because hey, it's all done for
you!). You don't learn how to wade through a crash dump (because you
have exceptions and tracebacks), you don't learn how to compile for
different platforms, you don't learn all sorts of other things that
aren't necessary for someone's first year in comp sci. So I'm
interested to what such high level languages lack, from the POV of a
first year of comp sci.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are the critiques in "All the things I hate about Python" valid?

[Terry Reedy]

On 2/20/2018 8:38 AM, Antoon Pardon wrote:


People praise the dynamic nature of Python here on this list and then
often enough seem to recoil when they see a piece of code really using
that dynamism.


Dynamic typing is the addition of run-time type information (RTTI) to 
data values.  This allows duck typing of function parameters and 
function code.  Every function that uses duck typing, which is to say, 
most functions written in Python, is 'really using that dynamism' as 
intended.  The concrete type of arguments may change with every call, 
but the function code uses run-time type dispatch to get type-specific 
versions of the operations needed.


For instance, builtin min has a single parameter whose abstract argument 
type is "iterable of '<'-compatible objects".  It's code somewhere 
compares current_min < next_item, which dispatches to current_min.__lt__ 
or possibly next_item.__ge__.  Combining "list of | tuple of | set of | 
frozenset of | iterable of | dict keyed with" witn "ints | doubles | 
strings | bytes | '<'-compatible lists | '<'-compatible tuples" gives 36 
possible concrete input types.  "array of x" gives an indefinite number 
more, as does user additions.  I really like that we do not have to 
define a 'min_collection_type' function for every combination we might 
want to use in a package.


When makes people recoil is abusing dynamism by needlessly rebinding a 
name to objects of different specific type within a single block of code.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: could use some help with this problem! (Posting On Python-List Prohibited)

[Terry Reedy]

On 2/20/2018 7:59 PM, Ben Bacarisse wrote:

Lawrence D’Oliveiro  writes:


On Wednesday, February 21, 2018 at 3:10:25 AM UTC+13, Ben Bacarisse wrote:

You almost never /have/ to use nested loops.  Has the course got this
far without introducing the idea of a function?


If you are using a function to avoid a nested loop, perhaps that’s not
such a smart use of a function...


Agreed.  And yet it /might/ be a smart use of one.  Nothing about simply
avoiding a loop is sufficient to make the assessment.


If one were using functional style, one would use tail recursive 
functions instead of *any* explicit loops.



--
Terry Jan Reedy


--
https://mail.python.org/mailman/listinfo/python-list

Re: Python on Android?

[Abdur-Rahmaan Janhangeer]

here is a kivy launcher tutorial i once wrote :
https://wp.me/p7UB6x-kB

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

On 18 Feb 2018 13:59, "Chris Angelico"  wrote:

Does anyone have experience with running Python scripts on Android
phones? I have a brother (honestly! I'm not actually using a phone
myself!) who's trying to run one of my scripts in QPython, which
claims to be version 3.2.2. I think that really truly is a Python 3.2
implementation - probing for newer features suggests that it actually
doesn't even support the u"..." syntax that came (back) in with Python
3.3. So... does anyone know of a Python interpreter that's compatible
with 3.4 or better and runs on Android?

Personal experiences trump just searching the web...

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python on Android?

[Chris Angelico]

On Wed, Feb 21, 2018 at 4:44 PM, Abdur-Rahmaan Janhangeer
 wrote:
> here is a kivy launcher tutorial i once wrote :
> https://wp.me/p7UB6x-kB
>

Thanks. I'm currently a dozen or so tabs deep into learning Kivy, and
am just starting to get to looking into launchers.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python on Android?

[Abdur-Rahmaan Janhangeer]

writing this especially to thank you hey XD pydroid3 suports qt5 and
matplotlib o_0 numpy and sci-kit really, what an amazing discovery !!!

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

On 18 Feb 2018 13:59, "Chris Angelico"  wrote:

> Does anyone have experience with running Python scripts on Android
> phones? I have a brother (honestly! I'm not actually using a phone
> myself!) who's trying to run one of my scripts in QPython, which
> claims to be version 3.2.2. I think that really truly is a Python 3.2
> implementation - probing for newer features suggests that it actually
> doesn't even support the u"..." syntax that came (back) in with Python
> 3.3. So... does anyone know of a Python interpreter that's compatible
> with 3.4 or better and runs on Android?
>
> Personal experiences trump just searching the web...
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list