Re: Are the critiques in "All the things I hate about Python" valid?
Tim Delaney writes: [...] > As others have said, typing is about how the underlying memory is treated. No. It is much more than that. Typing is about everything you can say about a given statement. Some type systems are focusing on type labels only (like most statically typed programming languages), others are fairly elaborate (for instance, Eiffel's, if requires/ensures are considered part of the type system). There is a wide range of type systems, more or less practical depending on your needs (see https://www.cis.upenn.edu/~bcpierce/tapl/ if you want to see how far you can go with typing). [...] > C is statically and weakly typed. Variables know their types at compile > time (static typing). It is a feature of the language that you can cast any > pointer to any chunk of memory to be a pointer to any other type (normally > via void *). This is not coercion - it takes the bit pattern of memory of > one type and interprets it as the bit pattern for another type, and is weak > typing. No. C has much stronger rules, not on casting, but on accessing the pointees, which basically invalidates your argument. Refer to the C standard for details. > Python is strongly and dynamically typed. In Python, once you create an > object, it remains that type of object, no matter what you do to it*. That > makes it strongly typed. [...] But you can modify the class (not __class__) in whatever way you want. For instance: class X(object): def f(self): ... ... del X.f So, in Python, knowing that object x is an instance of class X tells you... essentially nothing. Call this strong typing if you want. In terms of type systems, it is (strong) simplistic-typing based on type labels, and labels carry no information whatsoever. Dynamic typing lets you avoid doing nonsense with bit-patterns, as you say, by gracefully crashing at run-time instead of performing "unexpected" actions. "Unexpected" is defined by the whole *execution* of the program up to the point where typing takes place. To understand whether a Python statement x.f() is meaningful (which is what typing is about), you have to know the full sequence of actions that have taken place on x *and* on its class (and on everything that that call may use) since the beginning of the program. For any non-trivial program, this is usually way too complex to capture, testing will be incomplete, and all you can do is run your program and see whether is goes through. As a general rule, if that's all you expect from typing, then, fine, call this "strong". I won't go as far, and just say that it is good enough for the programs I use Python for. -- Alain. -- https://mail.python.org/mailman/listinfo/python-list
How to reset system proxy using pyhton code
Hi,
I am using below python code (Python 2.7) to reset the proxy of my Ubuntu
(Cent OS 6) system, but I am unable to reset the proxy:
Code :
import os
print "Unsetting http..."
os.system("unset http_proxy")
os.system("echo $http_proxy")
print "http is reset"
Output :
Unsetting http...
http://web-proxy..xxx.net:8080
http is reset
Process finished with exit code 0
It should not return ' http://web-proxy..xxx.net:8080 ' in output.
I run the same unset command from terminal , then I see that proxy is
reset:
[trex@sumlnxvm ~]$ unset $HTTP_PROXY
[trex@sumlnxvm ~]$ echo $HTTP_PROXY
[trex@sumlnxvm ~]$
Please suggest how to reset system proxy using Python Code
Regards,
Sumit
--
https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
On Mon, Feb 19, 2018 at 7:40 PM, Alain Ketterlin
wrote:
> Tim Delaney writes:
>> C is statically and weakly typed. Variables know their types at compile
>> time (static typing). It is a feature of the language that you can cast any
>> pointer to any chunk of memory to be a pointer to any other type (normally
>> via void *). This is not coercion - it takes the bit pattern of memory of
>> one type and interprets it as the bit pattern for another type, and is weak
>> typing.
>
> No. C has much stronger rules, not on casting, but on accessing the
> pointees, which basically invalidates your argument. Refer to the C
> standard for details.
Really? What rules?
$ cat demo.c; gcc -Wall demo.c; ./a.out
#include
int main() {
float f = 3.14159;
int *i = (int *)&f;
printf("As an integer, %f is %d\n", f, *i);
return 0;
}
As an integer, 3.141590 is 107853
$
Looks to me like C is perfectly happy to interpret a float as an int.
What rules are you seeing violated here?
> But you can modify the class (not __class__) in whatever way you want.
> For instance:
>
> class X(object):
> def f(self): ...
> ...
> del X.f
>
> So, in Python, knowing that object x is an instance of class X tells
> you... essentially nothing. Call this strong typing if you want. In
> terms of type systems, it is (strong) simplistic-typing based on type
> labels, and labels carry no information whatsoever.
Sure you can. And you can do a lot of other things at run time, too.
Monkey-patching doesn't change the fact that x really and truly is an
instance of class X, it just changes what you can do with that object.
So what you're saying is that Python's dynamism makes it possible to
disrupt duck typing. Sure, I'll grant you that. But the type system
itself isn't broken by that.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
On 17-02-18 21:11, Chris Angelico wrote: > On Sun, Feb 18, 2018 at 1:47 AM, Ian Kelly wrote: >> On Fri, Feb 16, 2018 at 9:32 PM, Chris Angelico wrote: >>> You'd be surprised how rarely that kind of performance even matters. >>> The author of that article cites C# as a superior language, but in the >>> rewrite from C# to Python (the same one I mentioned in the other >>> post), I sped the program up incredibly. Part of that is because C# >>> requires the startup of its framework (in my case that's Mono) just as >>> Python does, and partly it's because the simplicity of Python let me >>> eliminate a number of unnecessary HTTP requests. Trust me, your choice >>> of language doesn't help you if it means you do three (sequential) >>> HTTP requests when one would have done. Clean code has its own >>> advantages. >> Okay, I'm curious. How did C# force you to make extra HTTP requests >> that were no longer necessary when you rewrote in Python? > It didn't *force* those requests to be made, but the code was so large > and convoluted that I doubt its original author realized that the > requests were being repeated. Pseudo-coded: But was that a reflection on C# or on the original author? -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
On 2/19/2018 4:14 AM, Chris Angelico wrote:
On Mon, Feb 19, 2018 at 7:40 PM, Alain Ketterlin
wrote:
Tim Delaney writes:
C is statically and weakly typed. Variables know their types at compile
time (static typing). It is a feature of the language that you can cast any
pointer to any chunk of memory to be a pointer to any other type (normally
via void *). This is not coercion - it takes the bit pattern of memory of
one type and interprets it as the bit pattern for another type, and is weak
typing.
No. C has much stronger rules, not on casting, but on accessing the
pointees, which basically invalidates your argument. Refer to the C
standard for details.
Really? What rules?
$ cat demo.c; gcc -Wall demo.c; ./a.out
#include
int main() {
float f = 3.14159;
int *i = (int *)&f;
printf("As an integer, %f is %d\n", f, *i);
return 0;
}
As an integer, 3.141590 is 107853
$
Looks to me like C is perfectly happy to interpret a float as an int.
What rules are you seeing violated here?
The last time I tried, C was also willing to ints and arrays thereof as
an array of chars. (I vaguely remember Fortran doing something like this
also. One Fortran int = four chars.) The C memory model is a linear
sequence of bytes, each consisting of at least 8 bits. One means for
malware attacks it is to disguise and insert binary code bytes as
character bytes and then trick the CPU into executing the 'characters'.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
On Mon, Feb 19, 2018 at 8:36 PM, Antoon Pardon wrote: > On 17-02-18 21:11, Chris Angelico wrote: >> On Sun, Feb 18, 2018 at 1:47 AM, Ian Kelly wrote: >>> On Fri, Feb 16, 2018 at 9:32 PM, Chris Angelico wrote: You'd be surprised how rarely that kind of performance even matters. The author of that article cites C# as a superior language, but in the rewrite from C# to Python (the same one I mentioned in the other post), I sped the program up incredibly. Part of that is because C# requires the startup of its framework (in my case that's Mono) just as Python does, and partly it's because the simplicity of Python let me eliminate a number of unnecessary HTTP requests. Trust me, your choice of language doesn't help you if it means you do three (sequential) HTTP requests when one would have done. Clean code has its own advantages. >>> Okay, I'm curious. How did C# force you to make extra HTTP requests >>> that were no longer necessary when you rewrote in Python? >> It didn't *force* those requests to be made, but the code was so large >> and convoluted that I doubt its original author realized that the >> requests were being repeated. Pseudo-coded: > > But was that a reflection on C# or on the original author? > A bit of both. It's the language's fault that simple operations take dozens of lines of code, and the author's fault for not noticing the redundancies. It's virtually impossible to keep thousands of lines of code in your head, so the language's lack of good primitives increases the complexity of the code and thus allows redundancy to lie hidden. But my main point in the original post was that C# cannot possibly *help* if most of the time is spent in HTTP requests. I could have naively transformed the code into Python without seeing any measurable performance drop, despite Python being "slower" than C#. Makes no difference what language you write in, if you're waiting on the network... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
Chris Angelico writes:
> On Mon, Feb 19, 2018 at 7:40 PM, Alain Ketterlin
> wrote:
>> No. C has much stronger rules, not on casting, but on accessing the
>> pointees, which basically invalidates your argument. Refer to the C
>> standard for details.
>
> Really? What rules?
Look at the C11 standard, section 6.3.2.3 ("Pointers"), 6.5.§6-7
("effective types"), and 6.5.3.2 ("Address and indirection operators").
It is tiring to constantly correct misunderstandings about pointer
casting and dereferencing.
> $ cat demo.c; gcc -Wall demo.c; ./a.out
[...]
If you don't know what undefined behavior is, better avoid C. Your
program has UB, anything can happen, including a seemingly sensible
result.
>> But you can modify the class (not __class__) in whatever way you want.
>> For instance:
>>
>> class X(object):
>> def f(self): ...
>> ...
>> del X.f
>>
>> So, in Python, knowing that object x is an instance of class X tells
>> you... essentially nothing. Call this strong typing if you want. In
>> terms of type systems, it is (strong) simplistic-typing based on type
>> labels, and labels carry no information whatsoever.
>
> Sure you can. And you can do a lot of other things at run time, too.
> Monkey-patching doesn't change the fact that x really and truly is an
> instance of class X, it just changes what you can do with that object.
> So what you're saying is that Python's dynamism makes it possible to
> disrupt duck typing. Sure, I'll grant you that. But the type system
> itself isn't broken by that.
I didn't say it is broken. I said: it does very little.
-- Alain.
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to reset system proxy using pyhton code
On 2018-02-19 09:57, Sum J wrote:
> Hi,
>
> I am using below python code (Python 2.7) to reset the proxy of my Ubuntu
> (Cent OS 6) system, but I am unable to reset the proxy:
I'm sure you know this, but CentOS and Ubuntu are two different things.
>
> Code :
> import os
> print "Unsetting http..."
> os.system("unset http_proxy")
> os.system("echo $http_proxy")
> print "http is reset"
Please pay attention to indentation when pasting Python code. I know
what you mean, but as such this code wouldn't even run.
>
> Output :
> Unsetting http...
> http://web-proxy..xxx.net:8080
> http is reset
> Process finished with exit code 0
>
> It should not return ' http://web-proxy..xxx.net:8080 ' in output.
>
> I run the same unset command from terminal , then I see that proxy is
> reset:
>
> [trex@sumlnxvm ~]$ unset $HTTP_PROXY
> [trex@sumlnxvm ~]$ echo $HTTP_PROXY
It is not possible to modify a parent process's environment from within
a child process. Can I interest you in a shell function or alias?
If you want to remove the environment variable for future processes you
start from your python script, simply modify os.environ. For example:
(using an environment variable I actually have on my system)
% cat del_env.py
import os
os.system('echo desktop $XDG_SESSION_DESKTOP')
print('removing')
del os.environ['XDG_SESSION_DESKTOP']
os.system('echo desktop $XDG_SESSION_DESKTOP')
% python del_env.py
desktop gnome
removing
desktop
% echo $XDG_SESSION_DESKTOP
gnome
-- Thomas
>
> [trex@sumlnxvm ~]$
>
>
> Please suggest how to reset system proxy using Python Code
>
> Regards,
> Sumit
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: solve_ivp problem (scipy 1.0.0)
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’? -- Thomas -- https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
On Mon, Feb 19, 2018 at 9:04 PM, Alain Ketterlin
wrote:
> Chris Angelico writes:
>
>> On Mon, Feb 19, 2018 at 7:40 PM, Alain Ketterlin
>> wrote:
>
>>> No. C has much stronger rules, not on casting, but on accessing the
>>> pointees, which basically invalidates your argument. Refer to the C
>>> standard for details.
>>
>> Really? What rules?
>
> Look at the C11 standard, section 6.3.2.3 ("Pointers"), 6.5.§6-7
> ("effective types"), and 6.5.3.2 ("Address and indirection operators").
> It is tiring to constantly correct misunderstandings about pointer
> casting and dereferencing.
>
>> $ cat demo.c; gcc -Wall demo.c; ./a.out
> [...]
>
> If you don't know what undefined behavior is, better avoid C. Your
> program has UB, anything can happen, including a seemingly sensible
> result.
Sure it can. But I don't know what you can mean by "stronger rules" if
all it says is "that's undefined". Saying that behaviour is undefined
does NOT mean that C has a stronger type system. I got no errors, not
even a warning in -Wall mode, so there is no indication that my code
did something wrong.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
On Mon, 19 Feb 2018 09:40:09 +0100, Alain Ketterlin wrote:
> Tim Delaney writes:
>
> [...]
>> As others have said, typing is about how the underlying memory is
>> treated.
>
> No. It is much more than that. Typing is about everything you can say
> about a given statement.
"Everything"? Truly *everything*?
Given:
# engage the type system somehow...
# declare a, b, c: non-negative integers
a = abs(int(input("Give me an integer")))
b = a*a
c = (a+1)*(a+1)
can you give me an example of a type-system which is capable of telling
me that:
if (c - b) % 2 == 1:
print("hello world")
else:
fire_missiles()
will never fire the missiles?
I'd be impressed enough with a type system that knew that a%2 was always
0 or 1, although I suppose there could be some that already know that.
Hell, I'd even be impressed if it could tell that c was not zero...
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
Chris Angelico writes:
> On Mon, Feb 19, 2018 at 9:04 PM, Alain Ketterlin
> wrote:
>> Look at the C11 standard, section 6.3.2.3 ("Pointers"), 6.5.§6-7
>> ("effective types"), and 6.5.3.2 ("Address and indirection operators").
>> It is tiring to constantly correct misunderstandings about pointer
>> casting and dereferencing.
>>
>>> $ cat demo.c; gcc -Wall demo.c; ./a.out
>> [...]
>>
>> If you don't know what undefined behavior is, better avoid C. Your
>> program has UB, anything can happen, including a seemingly sensible
>> result.
>
> Sure it can. But I don't know what you can mean by "stronger rules" if
> all it says is "that's undefined". Saying that behaviour is undefined
> does NOT mean that C has a stronger type system. I got no errors, not
> even a warning in -Wall mode, so there is no indication that my code
> did something wrong.
I used "stronger rules" in response to the OP claim ("C lets you
manipulate memory freely"). Undefined behavior is part of the semantics
of C, the same way infinite loops of signed-integer overflow are. What
compilers can do about it is a different matter. This is well
documented, those that want to ignore UB are on their own. Anyway, I
think it is irrelevant here. Search for "What every programmer should
know about undefined behavior" if you are interested.
-- Alain.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
On Mon, Feb 19, 2018 at 9:24 PM, Steven D'Aprano
wrote:
> On Mon, 19 Feb 2018 09:40:09 +0100, Alain Ketterlin wrote:
>
>> Tim Delaney writes:
>>
>> [...]
>>> As others have said, typing is about how the underlying memory is
>>> treated.
>>
>> No. It is much more than that. Typing is about everything you can say
>> about a given statement.
>
> "Everything"? Truly *everything*?
>
> Given:
>
> # engage the type system somehow...
> # declare a, b, c: non-negative integers
> a = abs(int(input("Give me an integer")))
> b = a*a
> c = (a+1)*(a+1)
>
> can you give me an example of a type-system which is capable of telling
> me that:
>
> if (c - b) % 2 == 1:
> print("hello world")
> else:
> fire_missiles()
>
> will never fire the missiles?
>
> I'd be impressed enough with a type system that knew that a%2 was always
> 0 or 1, although I suppose there could be some that already know that.
>
> Hell, I'd even be impressed if it could tell that c was not zero...
>
A type system, per se? I don't think so. But static analysis CAN
figure out that sort of thing (obviously, since we as humans can do
it), and I wouldn't be surprised in the least if tools like Coverity
could detect this.
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 writes:
> On Mon, 19 Feb 2018 09:40:09 +0100, Alain Ketterlin wrote:
>
>> Tim Delaney writes:
>>
>> [...]
>>> As others have said, typing is about how the underlying memory is
>>> treated.
>>
>> No. It is much more than that. Typing is about everything you can say
>> about a given statement.
>
> "Everything"? Truly *everything*?
Everything you can say.
> Given:
>
> # engage the type system somehow...
> # declare a, b, c: non-negative integers
> a = abs(int(input("Give me an integer")))
> b = a*a
> c = (a+1)*(a+1)
>
> can you give me an example of a type-system which is capable of telling
> me that:
>
> if (c - b) % 2 == 1:
> print("hello world")
> else:
> fire_missiles()
>
> will never fire the missiles?
Your example is ridiculously simple for all theorem provers I know (not
on Python code of course, since you can't even be sure int() etc. have
not been redefined).
Here is one that makes your point much better:
if a**n + b**n == c**n:
print("hello world")
else:
fire_missiles()
> I'd be impressed enough with a type system that knew that a%2 was always
> 0 or 1, although I suppose there could be some that already know that.
>
> Hell, I'd even be impressed if it could tell that c was not zero...
Your claim essentially is: since we cannot prove everything, let's not
even try to prove anything. Go on if you think this is the right way to
think about typing.
-- Alain.
--
https://mail.python.org/mailman/listinfo/python-list
Re: [OT] multicore/cpu history Re: Are the critiques in "All the things I hate about Python" valid?
On Mon, Feb 19, 2018 at 10:39 PM, Adriaan Renting wrote: > I remember running 2 Mendocino 300 MHz Celerons on a Pentium II Xeon > motherboard to get a > multi-cpu machine for running multiple virtual machines for testing > purposes around 1998. > This was not as Intel intended, but a quite cheap consumer grade > hardware solution. > Thanks! That's the sort of thing I was looking for. Out of curiosity, what was the purpose of that rig and its dual CPUs? Were you running the host system on one CPU and the guest on another? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[OT] multicore/cpu history Re: Are the critiques in "All the things I hate about Python" valid?
Adriaan Renting| Email: rent...@astron.nl Software Engineer Radio Observatory ASTRON | Phone: +31 521 595 100 (797 direct) P.O. Box 2 | GSM: +31 6 24 25 17 28 NL-7990 AA Dwingeloo | FAX: +31 521 595 101 The Netherlands| Web: http://www.astron.nl/~renting/ >>> On 17-2-2018 at 22:02, in message , Chris Angelico wrote: > On Sun, Feb 18, 2018 at 5:05 AM, Steven D'Aprano > wrote: >> On Sat, 17 Feb 2018 15:25:15 +1100, Chris Angelico wrote: >> ... >>> Totally not true. The GIL does not stop other threads from running. >>> Also, Python has existed for multiple CPU systems pretty much since its >>> inception, I believe. (Summoning the D'Aprano for history lesson?) >> >> If you're talking about common desktop computers, I think you're >> forgetting how recent multicore machines actually are. I'm having >> difficulty finding when multicore machines first hit the market, but it >> seems to have been well into the 21st century -- perhaps as late as 2006 >> with the AMD Athelon 64 X2: > > No, I'm talking about big iron. Has Python been running on multi-CPU > supercomputers earlier than that? > >> By the way, multiple CPU machines are different from CPUs with multiple >> cores: >> >> http://smallbusiness.chron.com/multiple-cpu-vs-multicore-33195.html > > Yeah, it was always "multiple CPUs", not "multiple cores" when I was > growing up. And it was only ever in reference to the expensive > hardware that I could never even dream of working with. I was always > on the single-CPU home-grade systems. > Multicore became a thing with the Pentium 4 hyperthreading around ~2002 for consumers, and multi cpu was a thing much longer, even with "consumer grade" hardware: I remember running 2 Mendocino 300 MHz Celerons on a Pentium II Xeon motherboard to get a multi-cpu machine for running multiple virtual machines for testing purposes around 1998. This was not as Intel intended, but a quite cheap consumer grade hardware solution. ... > > ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
Alain Ketterlin : > Your claim essentially is: since we cannot prove everything, let's not > even try to prove anything. Go on if you think this is the right way to > think about typing. This discussion is far too metaphysical. Static type declarations give you something at a cost. They give you: * Performance (by several orders of magnitude). * Static type checking (-> better quality). They cost: * More code to type (-> worse quality, lower productivity). In my experience it is far easier to produce correct code in Python than in, say, C++ or Java. Back to metaphysics: OO has spent far too much energy in ontology. You shouldn't judge an object based on the class it belongs to. Marko -- https://mail.python.org/mailman/listinfo/python-list
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
Python with PyDev on Visual Studio Code
Hi All, I'm happy to announce that PyDev (http://www.pydev.org) can now be used for Python development on Visual Studio Code! The first release already provides features such as code analysis, code completion, go to definition, symbols for the workspace and editor, code formatting, find references, quick fixes and more (see http://www.pydev.org/vscode/ for details). All features have a strong focus on speed and have been shaped by the usage on PyDev over the last 14 years, so, I believe it's already pretty nice to use... there are still some big things to integrate (such as the PyDev debugger), but those should come on shortly. The requisites are having java 8 (or higher) installed on the system (if it doesn't find it automatically the java home location may need to be specified in the settings -- http://www.pydev.org/vscode/ has more details) and Python 2.6 or newer. By default it should pick the python executable available on the PATH, but it's possible to specify a different python executable through the settings on VSCode (see http://www.pydev.org/vscode/settings.html for details). Below, I want to share some of the things that are unique in PyDev and are now available for VSCode users: - Niceties from PyDev when typing such as auto-adding self where needed (note that having the editor.formatOnType setting turned on is a requisite for that to work). - Really fast code-completion, code-analysis and code-formatting engines. - Code completion provides options to import modules, top level classes, methods and variables (python.pydev.preferredImportLocation can be used to determine the location of the import). - Quick fix which automatically allows adding an import for unresolved symbols. - In-file navigation to previous or next class or method through Ctrl+Shift+Up and Ctrl+Shift+Down. See: http://www.pydev.org/vscode/ for more information! Cheers, -- Fabio Zadrozny -- Software Developer PyDev on VSCode http://pydev.org/vscode PyVmMonitor - Profile Python on VSCode http://www.pyvmmonitor.com/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
På Mon, 19 Feb 2018 04:39:31 + (UTC) Steven D'Aprano skrev: > On Mon, 19 Feb 2018 04:26:32 +0100, Anders Wegge Keller wrote: > > > På Mon, 19 Feb 2018 08:47:14 +1100 > > Tim Delaney skrev: > >> On 18 February 2018 at 22:55, Anders Wegge Keller > >> wrote: > > > > > [...] > > > >> You couldn't have got the above much more wrong. > > > >> As others have said, typing is about how the underlying memory is > >> treated. > > > > And that is exactly my point. Python does not have a typed list. It > > have a list that takes whatever is thrown into it. > > > > I'll skip the rest, as you totally missed the point. > > I think its actually you have totally missed the point. What you want is > a homogeneous list, a list which only accepts items of the same type. The > built-in list is not that data structure, but Python already has > something similar: see the array module. Given that I'm the one making a point about the unwarranted smugness, I know that I'm not missing anything. Array is not even close to providing a strongly typed container. For all of the yakking about other languages weak, blah, BCPL, blah, I still wonder where that need to feel superior to anything else comes from. Python isn't particular strong typed. In fact, apart from asking an object what type it is, types are not that important. It's the interface that matters. I wonder why this is a sore point for Python developers? -- //Wegge -- https://mail.python.org/mailman/listinfo/python-list
Re: Python with PyDev on Visual Studio Code
Fabio Zadrozny wrote: See: http://www.pydev.org/vscode/ for more information! That page includes so many dead links that it looks like a joke. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2 to 3 Conversion
On 18/02/18 16:18, Wildman via Python-list wrote: But that's only going to show one (uplink) address. If I needed to get ALL addresses for ALL network adapters, I'd either look for a library, and if one wasn't easily found, I'd shell out to the "ip" command and parse its output.:) I considered using the "ip" command but I prefer not to depend on external programs if I can get around it. I know that might be considered silly but that's just me. It's not silly at all, but for Linux networking it might be the best idea. I believe in theory you are supposed to use libnl (in some suitable wrapping), but my experience with that is that it is badly documented and horrendously unreliable. -- 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?
On 19 February 2018 at 13:06, Anders Wegge Keller wrote: > Python isn't particular strong typed. In fact, apart from asking an object > what type it is, types are not that important. It's the interface that > matters. I wonder why this is a sore point for Python developers? Because there's a long history of people claiming that "strongly typed" languages are fundamentally better than "scripting languages" (and putting Python in the "scripting language" class) without either being clear about what "strongly typed" means, or about whether Python is actually strongly typed or not[1], maybe? The reality is that the term "strongly typed" can be made to mean whatever you want it to mean in these debates, and such claims usually turn out to be little more than statements "yah boo my language is better than yours and your language sucks". Paul [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. -- https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
On Mon, 19 Feb 2018 20:14:32 +1100, Chris Angelico wrote: > As an integer, 3.141590 is 107853 $ > > Looks to me like C is perfectly happy to interpret a float as an int. Yes, but that's not an *automatic* coercion. To count as weakly typed, the compiler has to do it automatically, without an explicit cast or conversion. I understand well that many people criticise C for making it too easy for the programmer to violate type-safety (or even for allowing it *at all*), but that's an orthogonal issue -- and probably essential for a systems language. D, Rust and other new-generation systems languages which have much stronger type systems than C nevertheless also allow programmers to escape from the type system when necessary. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: Python with PyDev on Visual Studio Code
Sorry, it was a glitch on the template when moved to another folder (just fixed). On Mon, Feb 19, 2018 at 10:08 AM, ElChino wrote: > Fabio Zadrozny wrote: > > See: http://www.pydev.org/vscode/ for more information! >> > > That page includes so many dead links that it looks > like a joke. > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
On Mon, 19 Feb 2018 12:19:14 +0100, Alain Ketterlin wrote:
> Steven D'Aprano writes:
>
>> On Mon, 19 Feb 2018 09:40:09 +0100, Alain Ketterlin wrote:
>>
>>> Tim Delaney writes:
>>>
>>> [...]
As others have said, typing is about how the underlying memory is
treated.
>>>
>>> No. It is much more than that. Typing is about everything you can say
>>> about a given statement.
>>
>> "Everything"? Truly *everything*?
>
> Everything you can say.
>
>> Given:
>>
>> # engage the type system somehow...
>> # declare a, b, c: non-negative integers
>> a = abs(int(input("Give me an integer")))
>> b = a*a
>> c = (a+1)*(a+1)
>>
>> can you give me an example of a type-system which is capable of telling
>> me that:
>>
>> if (c - b) % 2 == 1:
>> print("hello world")
>> else:
>> fire_missiles()
>>
>> will never fire the missiles?
>
> Your example is ridiculously simple for all theorem provers I know (not
> on Python code of course, since you can't even be sure int() etc. have
> not been redefined).
I didn't ask about theorem provers. I asked about type systems.
https://en.wikipedia.org/wiki/Automated_theorem_prover
One could, in principle, add a theorem prover to a type system, or at
least add certain theorem-proving-like functionality to it, but at what
point does the type checker become complex enough that we can no longer
trust it? If you don't understand the proof that code is bug-free, you're
really trusting that the type-checker is bug-free.
> Here is one that makes your point much better:
>
> if a**n + b**n == c**n:
> print("hello world")
> else:
> fire_missiles()
Either way, I doubt any existing type systems could eliminate the dead
code in those examples. If you know of one which would, I'd be interested
to hear about it.
>> I'd be impressed enough with a type system that knew that a%2 was
>> always 0 or 1, although I suppose there could be some that already know
>> that.
>>
>> Hell, I'd even be impressed if it could tell that c was not zero...
>
> Your claim essentially is: since we cannot prove everything, let's not
> even try to prove anything. Go on if you think this is the right way to
> think about typing.
That's not what I am saying. You're putting words into my mouth and
criticising me for a position much more extreme than I've expressed.
If you search the archives to this list, you'll see that I've frequently
supported Python adding type-hints to the language[1], to allow tools
like MyPy and various linters to perform static analysis on Python code.
Especially for large projects, that can be helpful.
Type-checking is yet another tool for gathering evidence (not "proving")
that a program is correct, together with (among others) code review and
especially testing.
As Donald Knuth said:
"Beware of bugs in the above code; I have only proved it correct, not
tried it."
What I object to is the idea that static type-checking is "indispensable"
or sufficient. Its one tool out of many, and more dispensable than some
of the others.
Even in a big project, which would you rather give up: all testing, or
all static type checking?
I don't just mean all formal tests, but even running the code to see if
it works. Literally "it compiles, ship it!". No, I don't think so.
Testing is truly indispensable, whether they are formal tests or not.
Static typing and "type-safety", not so much.
[1] If you search far back enough, you may find me taking a more extreme
position that static typing was unnecessary. That was a much younger and
more naive me.
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
On Mon, 19 Feb 2018 12:35:19 +, bartc wrote:
> 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!
Indeed. That's exactly the point I'm making.
A type-system that allowed you to express extremely fine-grained
distinctions would be effectively a fully fledged programming language
itself, probably even Turing Complete, and so our type-specifications
would be as error-prone as the code we write now.
Probably more so, due to the requirements that type specifications be a
lot more compact than the rest of the code we write.
> 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.
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
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. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
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:
import array
arr = array.array('I')
lst = []
Without cheating (more on this below), your challenge is to do *any* of
the following (your choice):
1. Change the type of the object currently assigned to arr to
a string (or any other non-array type of your choice); OR
2. Change the type of the object currently assigned to lst to
a string (or any other non-list type of your choice); OR
3. Assign a string (or any other non-integer value of your
choice) to any position in the array; OR
4. Assign a negative integer to any position in the array.
If you can do any of those things (with the restrictions given below),
I'll happily acknowledge that I was wrong, you were right, and Python's
"strong typing" is much weaker than I thought (or even non-existent).
On the other hand, if you can't do any of them, I expect you to
acknowledge that you were wrong.
Here are the restrictions ("no cheating"):
- You can't replace, shadow, monkey-patch or otherwise modify
the array module or the array.array type.
- Assigning a new object to the variable name "arr" does not
count as changing the type of the existing array object. You
must change the type of the instance, not replace it with
another instance.
- Likewise for the lst variable name. You must change the type
of the object, not re-assign a new object to the same name.
- Any sort of hack involving ctypes is interesting, but doesn't
count; we know that ctypes can break all sorts of invariants
by manipulating the C engine. Only standard Python code is
permitted.
- Likewise you aren't allowed to patch the interpreter. It must
be the standard CPython interpreter, version 2.4 or greater.
- Nor are you allowed to "cheat" by redefining builtins like
print, repr, type, id, sys.displayhook, sys.stdout etc in
order to fake output.
- Exploiting bugs in the interpreter to cause side-effects
don't count (its a bug, not a language feature).
- Any other clever trick that goes against the spirit of the
requirements will be interesting to see, but not count as
a success.
The spirit of the requirements are that you demonstrate the ability to do
something like this:
old_lst = lst # get a second reference to the list object
assert type(lst) is type([])
do_stuff(lst) # do something clever to the list object...
assert type(lst) is not type([]) # OMG you changed the type!
assert old_lst is lst # still the same object
(Similar for arr.)
I don't believe that you can do this. I believe that you have failed to
understand what we're talking about when we say Python has strong,
dynamic typing, but I'll be happy for you to prove me wrong.
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
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. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2 to 3 Conversion
On Mon, Feb 19, 2018 at 11:32 PM, Rhodri James wrote: > On 18/02/18 16:18, Wildman via Python-list wrote: >>> >>> But that's only going to show one (uplink) address. If I needed to get >>> ALL addresses for ALL network adapters, I'd either look for a library, >>> and if one wasn't easily found, I'd shell out to the "ip" command and >>> parse its output.:) >>> >> I considered using the "ip" command but I prefer not to >> depend on external programs if I can get around it. I >> know that might be considered silly but that's just me. > > > It's not silly at all, but for Linux networking it might be the best idea. > I believe in theory you are supposed to use libnl (in some suitable > wrapping), but my experience with that is that it is badly documented and > horrendously unreliable. Agreed. Obviously the first choice is to look in the standard library for the functionality you want, but it's not there (at least, I couldn't find it). Then your next choices, if I'm not mistaken, are: * Random third-party packages you might find on PyPI * Opaque IOCTLs * Wrapping a poorly-documented C library * Invoking a subprocess and parsing its output When those are the choices, the subprocess option doesn't look too bad. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
Ned Batchelder : > 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"? Because they don't? Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
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. -- //Wegge -- https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
On Tue, Feb 20, 2018 at 12:34 AM, Steven D'Aprano
wrote:
> On Mon, 19 Feb 2018 20:14:32 +1100, Chris Angelico wrote:
>
>> As an integer, 3.141590 is 107853 $
>>
>> Looks to me like C is perfectly happy to interpret a float as an int.
>
> Yes, but that's not an *automatic* coercion. To count as weakly typed,
> the compiler has to do it automatically, without an explicit cast or
> conversion.
Fair enough. If you ignore warnings, then C does have that kind of weak typing:
$ cat demo.c
#include
int main() {
float f = 3.14159;
int *i = &f;
printf("As an integer, %f is %d\n", f, *i);
return 0;
}
$ gcc demo.c
demo.c: In function ‘main’:
demo.c:5:14: warning: initialization from incompatible pointer type
[-Wincompatible-pointer-types]
int *i = &f;
^
$
GCC was quite happy to compile that code, even though the type of "&f"
is "pointer to float", and it's being assigned to a variable of type
"pointer to int". 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; so in terms of "how safe is C?", I'd have to
say that warnings (especially those that are enabled by default - I
didn't need to say "-Wall" for this test), count as "disallowing",
especially if all the major compilers emit warnings on the same code.
But I do see the argument that "it compiles, so the language clearly
permits it".
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
On 19 February 2018 at 15: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"? Apologies, Ned. I didn't mean to make your teeth sore :-) I've found that when people refer to "variables" they pretty much inevitably have a picture in their mind of a named box that "contains" a value (or pointer to a value). They find it difficult to understand that Python doesn't have those boxes but rather names the values directly. Sort of. And yes, that 's very much "sort of". It's certainly just as viable to say to people that Python's idea of variables is different than (say) C's, but in my experience you end up qualifying so much that it's easier to use a different term without the connotations. Sort of like saying "I like apples - the orange ones that are a type of citrus fruit" :-) In common usage I'll happily use the terms "variable" and "name" somewhat interchangeably, but when things degenerate into detail-level picking over specifics, I avoid doing so. I was wrong to casually say "Python doesn't have variables", though - if I want to be detailed and specific, I should make sure my writing reflects that that's what I'm doing. I'm curious - How would you explain Python's "variables" to someone who knows how C variables work, in a way that ensures they don't carry across any unfortunate misconceptions based on how C works? If I had a good way of doing that, maybe I wouldn't need to play apple/orange games when discussing the subject. Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
On Mon, Feb 19, 2018 at 11:35 PM, bartc wrote:
> 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.)
If they represent characters, then they're not integers. They're
characters. Characters are not integers.
House numbers and pensioners' ages are not unitless numbers. If you
truly want to represent these as actual types, then you need to
incorporate the unit in the type, or have a generic "number and unit"
data type. That would then change the operations permitted on that
type.
None of this says anything about the original question, which was
about numbers. Actual, plain, ordinary integers.
>> 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.
And now you're pretending that an enumeration is the same thing as an
integer. You're arguing about a type system, then trying to claim that
everything that can be represented as an integer must be an integer.
Your position is illogical.
> 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?
Do you mean that arithmetic results have to also be constrained, or
that the numeric type must itself only be those few? You could fairly
easily define a data type like this:
Int[0:10] # integer 0...9 inclusive (0..10 inc/exc)
Int[0:10] + Int[0:10] ==> Int[0:19]
Int[0:10] * Int[0:10] ==> Int[0:81]
Int[0:10] / Int[1:10] ==> Fraction
Perfectly sane and useful.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
Paul Moore : > I'm curious - How would you explain Python's "variables" to someone > who knows how C variables work, in a way that ensures they don't carry > across any unfortunate misconceptions based on how C works? Just say that 1. Every Python variable is of the type "Object *". 2. Every Python expression evaluates to a pointer (Object *). 3. Python's "." is equivalent to C's "->". That'll get the main point across pretty fast. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2 to 3 Conversion
On Mon, 19 Feb 2018 12:32:49 +, Rhodri James wrote: > On 18/02/18 16:18, Wildman via Python-list wrote: >>> But that's only going to show one (uplink) address. If I needed to get >>> ALL addresses for ALL network adapters, I'd either look for a library, >>> and if one wasn't easily found, I'd shell out to the "ip" command and >>> parse its output.:) >>> >> I considered using the "ip" command but I prefer not to >> depend on external programs if I can get around it. I >> know that might be considered silly but that's just me. > > It's not silly at all, but for Linux networking it might be the best > idea. I believe in theory you are supposed to use libnl (in some > suitable wrapping), but my experience with that is that it is badly > documented and horrendously unreliable. It looks like libnl would do what I want but there is a problem. When finished, my program will be released in the form of a Debian (*.deb) package and used by, for the most part, 'average' Linux users. These are people that know their way around Linux but know nothing or very little about Python. Installing a package using pip by them is pretty much out of the question. The system's package manager must be able to handle the program's dependencies so third-party packages are out of the question. But thanks for the suggestion. -- GNU/Linux user #557453 "There are only 10 types of people in the world... those who understand Binary... and those who don't." -Spike -- https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
On 2/19/18 10:39 AM, Paul Moore wrote: On 19 February 2018 at 15: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"? Apologies, Ned. I didn't mean to make your teeth sore :-) I've found that when people refer to "variables" they pretty much inevitably have a picture in their mind of a named box that "contains" a value (or pointer to a value). They find it difficult to understand that Python doesn't have those boxes but rather names the values directly. Sort of. And yes, that 's very much "sort of". It's certainly just as viable to say to people that Python's idea of variables is different than (say) C's, but in my experience you end up qualifying so much that it's easier to use a different term without the connotations. Sort of like saying "I like apples - the orange ones that are a type of citrus fruit" :-) In common usage I'll happily use the terms "variable" and "name" somewhat interchangeably, but when things degenerate into detail-level picking over specifics, I avoid doing so. I was wrong to casually say "Python doesn't have variables", though - if I want to be detailed and specific, I should make sure my writing reflects that that's what I'm doing. I'm curious - How would you explain Python's "variables" to someone who knows how C variables work, in a way that ensures they don't carry across any unfortunate misconceptions based on how C works? If I had a good way of doing that, maybe I wouldn't need to play apple/orange games when discussing the subject. I would (and did) explain it like this: https://nedbatchelder.com/text/names1.html That talk was pretty much powered by hating the phrase "Python has no variables" :) --Ned. Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
On 19 February 2018 at 17:11, Ned Batchelder wrote:
> On 2/19/18 10:39 AM, Paul Moore wrote:
>>
>> I'm curious - How would you explain Python's "variables" to someone
>> who knows how C variables work, in a way that ensures they don't carry
>> across any unfortunate misconceptions based on how C works? If I had a
>> good way of doing that, maybe I wouldn't need to play apple/orange
>> games when discussing the subject.
>
> I would (and did) explain it like this:
> https://nedbatchelder.com/text/names1.html
>
> That talk was pretty much powered by hating the phrase "Python has no
> variables" :)
Interesting (and somewhat embarrassing :-() That talk (which I'd
forgotten was yours) was one of the key things that made me start
thinking in terms of Python naming values rather than assigning values
to variables! I still find that your explanation (which never uses the
term "variable" until you refer to the "Python has no variables" idea
at the end) is one of the best ways to describe how Python assignment
works.
But using your explanation as a way to defend a statement that you
don't agree with is wrong, so I'll stop doing that in future. Sorry!
In terms of your talk, would I be right to say that "names" (in the
sense you use them in that talk) are Python's "variables"? That
equates to common usage, so I can go with that ("Python's variables
act like names, unlike other languages"). But I'd hate to replace one
misunderstanding of what you said with another, so let me know if I've
still got it wrong...
Paul
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to run script from interpreter?
On Saturday, February 17, 2018 at 8:50:48 AM UTC-6, Steven D'Aprano wrote: > > For me, the tool I use is a set of re-usable tools: > > - a text editor; > - a system command prompt in a terminal/console window; > - a Python REPL for running code snippets and looking up help(obj). > > Other people prefer a IDE like Spyder (or many others). Either way, > they're designed for the edit-run-debug-edit cycle. I hadn't looked at Spyder, it seems very useful. > I edit the source code of my script in the text editor, then run it from > the command prompt using > > python myscript.py > > If I need the debugger, I use: > > python -i myscript.py > ... > then edit the script to make the tests work. > > The best part of this is each time you run the script, it is guaranteed > to be running *fresh*, with no left-over cruft from previous runs. Good point. But some of that is stuff I'm using, so maybe it has to go in the script. And this from Ian seems to work for me: > py> import foo # Get the module to reload > py> reload(foo) # Reload it > py> from foo import * # Update all the names previously *-imported Thanks all for some good advice. Regards, Allen -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2 to 3 Conversion
On Tue, 20 Feb 2018 02:26:19 +1100, Chris Angelico wrote: > * Opaque IOCTLs Would you mind to elaborate a little about your concerns? -- GNU/Linux user #557453 "There are only 10 types of people in the world... those who understand Binary... and those who don't." -Spike -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2 to 3 Conversion
On Tue, Feb 20, 2018 at 3:49 AM, Wildman via Python-list wrote: > On Mon, 19 Feb 2018 12:32:49 +, Rhodri James wrote: > >> On 18/02/18 16:18, Wildman via Python-list wrote: But that's only going to show one (uplink) address. If I needed to get ALL addresses for ALL network adapters, I'd either look for a library, and if one wasn't easily found, I'd shell out to the "ip" command and parse its output.:) >>> I considered using the "ip" command but I prefer not to >>> depend on external programs if I can get around it. I >>> know that might be considered silly but that's just me. >> >> It's not silly at all, but for Linux networking it might be the best >> idea. I believe in theory you are supposed to use libnl (in some >> suitable wrapping), but my experience with that is that it is badly >> documented and horrendously unreliable. > > It looks like libnl would do what I want but there is > a problem. When finished, my program will be released > in the form of a Debian (*.deb) package and used by, > for the most part, 'average' Linux users. These are > people that know their way around Linux but know > nothing or very little about Python. Installing a > package using pip by them is pretty much out of the > question. The system's package manager must be able > to handle the program's dependencies so third-party > packages are out of the question. > > But thanks for the suggestion. If you're distributing it as a .deb, you don't want to use pip to grab additional libraries. Ideally, you'd want the library to *also* be available through the package manager, which would mean you can simply record it as a dependency. If it's not... it's not gonna be easy. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2 to 3 Conversion
On Tue, Feb 20, 2018 at 3:53 AM, Wildman via Python-list wrote: > On Tue, 20 Feb 2018 02:26:19 +1100, Chris Angelico wrote: > >> * Opaque IOCTLs > > Would you mind to elaborate a little about your > concerns? Look at your original code: it's impossible to figure out what it's doing or whether it's doing it correctly. "Opaque" in this context means that you can't grok the code without external help. This is a code smell, and a strong indication that you're "fiddling" in stuff way lower level than you normally want to be working with. It's usable, but it's dirty and leaves everything up to you (do you know for sure, for instance, if this is backward compatible? Cross-platform?), and that makes it comparable to depending on an external program. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
On 2/19/18 1:01 PM, Paul Moore wrote:
On 19 February 2018 at 17:11, Ned Batchelder wrote:
On 2/19/18 10:39 AM, Paul Moore wrote:
I'm curious - How would you explain Python's "variables" to someone
who knows how C variables work, in a way that ensures they don't carry
across any unfortunate misconceptions based on how C works? If I had a
good way of doing that, maybe I wouldn't need to play apple/orange
games when discussing the subject.
I would (and did) explain it like this:
https://nedbatchelder.com/text/names1.html
That talk was pretty much powered by hating the phrase "Python has no
variables" :)
Interesting (and somewhat embarrassing :-() That talk (which I'd
forgotten was yours) was one of the key things that made me start
thinking in terms of Python naming values rather than assigning values
to variables! I still find that your explanation (which never uses the
term "variable" until you refer to the "Python has no variables" idea
at the end) is one of the best ways to describe how Python assignment
works.
But using your explanation as a way to defend a statement that you
don't agree with is wrong, so I'll stop doing that in future. Sorry!
In terms of your talk, would I be right to say that "names" (in the
sense you use them in that talk) are Python's "variables"? That
equates to common usage, so I can go with that ("Python's variables
act like names, unlike other languages"). But I'd hate to replace one
misunderstanding of what you said with another, so let me know if I've
still got it wrong...
TBH, I forget the exact words I used during the talk, but: names are
Python's variables. That sounds good to me.
--Ned.
--
https://mail.python.org/mailman/listinfo/python-list
Re: c code generator from python
bhattacharya.kush...@gmail.com schrieb am 17.01.2018 um 12:03: > Is there any python framework or any tool as which can generate C code from > python code as it is . http://cython.org/ Stefan -- https://mail.python.org/mailman/listinfo/python-list
Re: Help on convert PyObject to string (c) Python 3.6
Jason Qian via Python-list schrieb am 04.02.2018 um 17:52: >This is the case of calling python from c and the python function will > return a string. Hi Jason, I noticed that you ran into a couple of problems using the C-API, so I suggest looking into Cython instead. It basically translates Python to C and supports optional static usage of C and C++ data types, so you get all the native code interaction *and* all the Python interaction and features, without having to go through the hassle of learning how the Python internals work (and why they don't work for you). The code it generates is probably also faster and safer than what you are currently writing (no offence, just experience from reading and writing a lot of such code). http://cython.org/ Stefan -- https://mail.python.org/mailman/listinfo/python-list
Re: Help on convert PyObject to string (c) Python 3.6
Thanks a lot and I will take a look Cython, On Mon, Feb 19, 2018 at 3:23 PM, Stefan Behnel wrote: > Jason Qian via Python-list schrieb am 04.02.2018 um 17:52: > >This is the case of calling python from c and the python function > will > > return a string. > > Hi Jason, > > I noticed that you ran into a couple of problems using the C-API, so I > suggest looking into Cython instead. It basically translates Python to C > and supports optional static usage of C and C++ data types, so you get all > the native code interaction *and* all the Python interaction and features, > without having to go through the hassle of learning how the Python > internals work (and why they don't work for you). The code it generates is > probably also faster and safer than what you are currently writing (no > offence, just experience from reading and writing a lot of such code). > > http://cython.org/ > > Stefan > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
[ANN] Biovarase ver 2
Biovarase has been updated to version 2, The project has been migrated from python 2.7 to python 3.5 Biovarase is an application to manage clinical quality control data. The purpose of Quality Control Assurance in a clinical laboratory is to allow the control of the performances of an analytical procedure showing an alarm as soon as the trial doesn't result in the degree to respect the defined analytical rules. Biovarase furthermore calculates the classical statistical parameters for the quality control assurance ,e.g. sd, cv%, avg, and even the Imp(%), Bias(%) and TEa (total allowable error) using data retrived from: Current databases on biologic variation: pros, cons and progress Scand J Clin Lab Invest 1999;59:491-500. updated with the most recent specifications made available in 2014. It uses even the famous Westgard's rules to monitor results dataset. All the data are managed by SQLite database and matplotlib. To show levey jennings graph, in the main windows select a test and choose the relative batch. To deactivate/activate a result make double click on it. To insert, update or delete a batch or a result open from File/Batchs and results. To export data to a temp excel file click on File/Export. Biovarase requires Python 3 Biovarase use Tkinter and matplotlib All source code on https://github.com/1966bc/Biovarase I'made it for fun :(. I would appreciate any suggestions you might have. regards beppe -- https://mail.python.org/mailman/listinfo/python-list
How to link to python 3.6.4 library on linux ?
Hi, I am calling python from a c application. It compiles and works fine on the windows. How do I compile and link it on the linux for Python 3.6.4 ? Under python dir, it only have a static library, /opt/Python-3.6.4*/lib*/*libpython3.6m.a* * If I link to it, I got:* */opt/Python-3.6.4/lib/libpython3.6m.a(abstract.o): relocation R_X86_64_32S against `_Py_NotImplementedStruct' can not be used when making a shared object; recompile with -fPIC* */opt/Python-3.6.4/lib/libpython3.6m.a: could not read symbols: Bad value* *Thanks for the help,* -- https://mail.python.org/mailman/listinfo/python-list
Re: [ANN] Biovarase ver 2
On Tue, Feb 20, 2018 at 8:45 AM, Beppe wrote: > > Biovarase has been updated to version 2, > > The project has been migrated from python 2.7 to python 3.5 > > Biovarase is an application to manage clinical quality control data. > > The purpose of Quality Control Assurance in a clinical laboratory is to allow > the control of the performances of an analytical procedure showing an alarm > as soon as the trial doesn't result in the degree to respect the defined > analytical rules. Biovarase furthermore calculates the classical statistical > parameters for the quality control assurance ,e.g. sd, cv%, avg, and even the > Imp(%), Bias(%) and TEa (total allowable error) using data retrived from: > Current databases on biologic variation: pros, cons and progress Scand J Clin > Lab Invest 1999;59:491-500. updated with the most recent specifications made > available in 2014. > It uses even the famous Westgard's rules to monitor results dataset. > All the data are managed by SQLite database and matplotlib. > To show levey jennings graph, in the main windows select a test and choose > the relative batch. > To deactivate/activate a result make double click on it. > To insert, update or delete a batch or a result open from File/Batchs and > results. > To export data to a temp excel file click on File/Export. > > Biovarase requires Python 3 > Biovarase use Tkinter and matplotlib > > All source code on > > https://github.com/1966bc/Biovarase > > I'made it for fun :(. > I would appreciate any suggestions you might have. Cool! Good to see. A few small suggestions, but nothing major. All your git commits are "file upload" apart from the occasional web edit; I would recommend getting familiar with command-line git and making commits with useful messages. (I was hoping to have a look at the changes that you did for Py2 -> Py3, but couldn't find them in the pile of big changes.) I'd also suggest getting an actual LICENSE or COPYING file, since your README says your code is GPL'd. And you may want to look into the formatting of your README - there are a few things that probably should be turned into bulleted lists rather than flowing as paragraphs. But otherwise, cool! I like to see this sort of thing published and open sourced. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How to link to python 3.6.4 library on linux ?
On Tue, Feb 20, 2018 at 8:07 AM, Jason Qian via Python-list wrote: > Hi, > > I am calling python from a c application. > It compiles and works fine on the windows. How do I compile and link > it on the linux for Python 3.6.4 ? > > Under python dir, it only have a static library, > >/opt/Python-3.6.4*/lib*/*libpython3.6m.a* > > * If I link to it, I got:* > > */opt/Python-3.6.4/lib/libpython3.6m.a(abstract.o): relocation R_X86_64_32S > against `_Py_NotImplementedStruct' can not be used when making a shared > object; recompile with -fPIC* > */opt/Python-3.6.4/lib/libpython3.6m.a: could not read symbols: Bad value* > By "calling Python from C", do you mean what the docs call "embedding"? https://docs.python.org/3/extending/embedding.html I would recommend following the tutorial there, if you haven't already. If you have, and the tutorial code doesn't work for you, post your code and what you did, and we'll try to help with that. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: [ANN] Biovarase ver 2
Il giorno lunedì 19 febbraio 2018 23:02:43 UTC+1, Chris Angelico ha scritto: > On Tue, Feb 20, 2018 at 8:45 AM, Beppe wrote: > > > > Biovarase has been updated to version 2, > > > > The project has been migrated from python 2.7 to python 3.5 > > > > Biovarase is an application to manage clinical quality control data. > > > > The purpose of Quality Control Assurance in a clinical laboratory is to > > allow the control of the performances of an analytical procedure showing an > > alarm as soon as the trial doesn't result in the degree to respect the > > defined analytical rules. Biovarase furthermore calculates the classical > > statistical parameters for the quality control assurance ,e.g. sd, cv%, > > avg, and even the Imp(%), Bias(%) and TEa (total allowable error) using > > data retrived from: Current databases on biologic variation: pros, cons and > > progress Scand J Clin Lab Invest 1999;59:491-500. updated with the most > > recent specifications made available in 2014. > > It uses even the famous Westgard's rules to monitor results dataset. > > All the data are managed by SQLite database and matplotlib. > > To show levey jennings graph, in the main windows select a test and choose > > the relative batch. > > To deactivate/activate a result make double click on it. > > To insert, update or delete a batch or a result open from File/Batchs and > > results. > > To export data to a temp excel file click on File/Export. > > > > Biovarase requires Python 3 > > Biovarase use Tkinter and matplotlib > > > > All source code on > > > > https://github.com/1966bc/Biovarase > > > > I'made it for fun :(. > > I would appreciate any suggestions you might have. > > Cool! Good to see. > > A few small suggestions, but nothing major. All your git commits are > "file upload" apart from the occasional web edit; I would recommend > getting familiar with command-line git and making commits with useful > messages. (I was hoping to have a look at the changes that you did for > Py2 -> Py3, but couldn't find them in the pile of big changes.) I'd > also suggest getting an actual LICENSE or COPYING file, since your > README says your code is GPL'd. And you may want to look into the > formatting of your README - there are a few things that probably > should be turned into bulleted lists rather than flowing as > paragraphs. But otherwise, cool! I like to see this sort of thing > published and open sourced. > > ChrisA Well, I don't manage a lot of git hub yet but I will surely keep in mind of your suggestions. Publishing this project and others is the least one that I can do for thanking the python's programmer community of the things that I have learned ...I believe even that I must also work hard on my English thank you very much for your attention Chris -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2 to 3 Conversion
On Tue, 20 Feb 2018 05:39:15 +1100, Chris Angelico wrote: > On Tue, Feb 20, 2018 at 3:53 AM, Wildman via Python-list > wrote: >> On Tue, 20 Feb 2018 02:26:19 +1100, Chris Angelico wrote: >> >>> * Opaque IOCTLs >> >> Would you mind to elaborate a little about your >> concerns? > > Look at your original code: it's impossible to figure out what it's > doing or whether it's doing it correctly. "Opaque" in this context > means that you can't grok the code without external help. This is a > code smell, and a strong indication that you're "fiddling" in stuff > way lower level than you normally want to be working with. It's > usable, but it's dirty and leaves everything up to you (do you know > for sure, for instance, if this is backward compatible? > Cross-platform?), and that makes it comparable to depending on an > external program. > > ChrisA I understand and I agree for the most part. It does concern me that I don't understand the code. Anytime in Linux you start poking around things at kernel level, you need your eyes to be wide open. However, to me it looks like the code is only quarying ioctl and not trying to change any- thing. If this is true, there is no problem. For the issue of backward compatibility, there are good people on a few of the Linux newsgroups that are willing to test code snippets for me. I can get a wide range of distros, desktops and kernel versions. And of course different python3 versions. I know it is impossible to write code that will be guaranteed to run on all conditions. But the test results I get will or should let me know right off if there are glaring problems. As far as cross-platform goes, that is not an issue. Every thing I do is targeted for the Linux platform. I will keep "ip" in mind as a backup plan. As a novice Python programmer, I am looking at the amount of code it will take to parse ip's output compared to the few lines of code it takes to call ioctl. I really appreciate your insight. Thank you. -- GNU/Linux user #557453 "There are only 10 types of people in the world... those who understand Binary... and those who don't." -Spike -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2 to 3 Conversion
On Tue, 20 Feb 2018 05:31:27 +1100, Chris Angelico wrote: > On Tue, Feb 20, 2018 at 3:49 AM, Wildman via Python-list > wrote: >> On Mon, 19 Feb 2018 12:32:49 +, Rhodri James wrote: >> >>> On 18/02/18 16:18, Wildman via Python-list wrote: > But that's only going to show one (uplink) address. If I needed to get > ALL addresses for ALL network adapters, I'd either look for a library, > and if one wasn't easily found, I'd shell out to the "ip" command and > parse its output.:) > I considered using the "ip" command but I prefer not to depend on external programs if I can get around it. I know that might be considered silly but that's just me. >>> >>> It's not silly at all, but for Linux networking it might be the best >>> idea. I believe in theory you are supposed to use libnl (in some >>> suitable wrapping), but my experience with that is that it is badly >>> documented and horrendously unreliable. >> >> It looks like libnl would do what I want but there is >> a problem. When finished, my program will be released >> in the form of a Debian (*.deb) package and used by, >> for the most part, 'average' Linux users. These are >> people that know their way around Linux but know >> nothing or very little about Python. Installing a >> package using pip by them is pretty much out of the >> question. The system's package manager must be able >> to handle the program's dependencies so third-party >> packages are out of the question. >> >> But thanks for the suggestion. > > If you're distributing it as a .deb, you don't want to use pip to grab > additional libraries. Ideally, you'd want the library to *also* be > available through the package manager, which would mean you can simply > record it as a dependency. If it's not... it's not gonna be easy. > > ChrisA Yes, you are correct. Third-party pip packages are always a no-no. Speaking of which, there is a library called Netifaces that will easily do exactly what I want with a few lines of code. But, it is not to be found in any Linux distro's repository that I can find. Oh well... -- GNU/Linux user #557453 "There are only 10 types of people in the world... those who understand Binary... and those who don't." -Spike -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2 to 3 Conversion
On Tue, Feb 20, 2018 at 10:09 AM, Wildman via Python-list wrote: > Yes, you are correct. Third-party pip packages are always > a no-no. > > Speaking of which, there is a library called Netifaces that > will easily do exactly what I want with a few lines of code. > But, it is not to be found in any Linux distro's repository > that I can find. Oh well... > $ apt-cache search netifaces python-netifaces - portable network interface information - Python 2.x python-netifaces-dbg - portable network interface information - Python 2.x debug extension python3-netifaces - portable network interface information - Python 3.x python3-netifaces-dbg - portable network interface information - Python 3.x debug extension $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 9.3 (stretch) Release: 9.3 Codename: stretch The given homepage URL is http://alastairs-place.net/projects/netifaces/ - is that the right one? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2 to 3 Conversion
On Tue, 20 Feb 2018 10:55:28 +1100, Chris Angelico wrote: > The given homepage URL is > http://alastairs-place.net/projects/netifaces/ - is that the right > one? > > ChrisA Yes, that is the right one. Now I'm feeling a little stupid. I should have remembered that many python library package names start with python- or python3-. Problem solved. A thousand thank-you's. -- GNU/Linux user #557453 The cow died so I don't need your bull! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2 to 3 Conversion
On Tue, Feb 20, 2018 at 12:05 PM, Wildman via Python-list wrote: > On Tue, 20 Feb 2018 10:55:28 +1100, Chris Angelico wrote: > >> The given homepage URL is >> http://alastairs-place.net/projects/netifaces/ - is that the right >> one? >> >> ChrisA > > Yes, that is the right one. Now I'm feeling a little stupid. > I should have remembered that many python library package > names start with python- or python3-. > > Problem solved. A thousand thank-you's. > No problem, this is why we don't work alone :) If you can work with that on all the platforms you need, awesome! The dirtiness of calling a subprocess or an opaque IOCTL can be wrapped up nicely inside a library. Always an improvement IMO. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
On 2/19/18 10:35 AM, Chris Angelico wrote:
On Tue, Feb 20, 2018 at 12:34 AM, Steven D'Aprano
wrote:
On Mon, 19 Feb 2018 20:14:32 +1100, Chris Angelico wrote:
As an integer, 3.141590 is 107853 $
Looks to me like C is perfectly happy to interpret a float as an int.
Yes, but that's not an *automatic* coercion. To count as weakly typed,
the compiler has to do it automatically, without an explicit cast or
conversion.
Fair enough. If you ignore warnings, then C does have that kind of weak typing:
$ cat demo.c
#include
int main() {
float f = 3.14159;
int *i = &f;
printf("As an integer, %f is %d\n", f, *i);
return 0;
}
$ gcc demo.c
demo.c: In function ‘main’:
demo.c:5:14: warning: initialization from incompatible pointer type
[-Wincompatible-pointer-types]
int *i = &f;
^
$
GCC was quite happy to compile that code, even though the type of "&f"
is "pointer to float", and it's being assigned to a variable of type
"pointer to int". 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; so in terms of "how safe is C?", I'd have to
say that warnings (especially those that are enabled by default - I
didn't need to say "-Wall" for this test), count as "disallowing",
especially if all the major compilers emit warnings on the same code.
But I do see the argument that "it compiles, so the language clearly
permits it".
ChrisA
One thing to note, that is more an issue with GCC than with C. By the
standard, that is a constraint violation, that requires a diagnostic,
and the C standard says it provides no definition of what should happen
here, which is about as strong as it gets to defining something as an
'Error', the only thing with a stronger requirement is the #error
statement which must not running the program.
GCC has decided that this diagnostic will be considered just a 'Warning'
and provides its own meaning to the statement. You really want to run
with pedantic-errors enabled to get GCC to reject code with constraint
violations.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to link to python 3.6.4 library on linux ?
Thanks Chris, I think I figured it out that when build python on Linux, we need to enable-shared. Thanks again, On Mon, Feb 19, 2018 at 5:04 PM, Chris Angelico wrote: > On Tue, Feb 20, 2018 at 8:07 AM, Jason Qian via Python-list > wrote: > > Hi, > > > > I am calling python from a c application. > > It compiles and works fine on the windows. How do I compile and > link > > it on the linux for Python 3.6.4 ? > > > > Under python dir, it only have a static library, > > > >/opt/Python-3.6.4*/lib*/*libpython3.6m.a* > > > > * If I link to it, I got:* > > > > */opt/Python-3.6.4/lib/libpython3.6m.a(abstract.o): relocation > R_X86_64_32S > > against `_Py_NotImplementedStruct' can not be used when making a shared > > object; recompile with -fPIC* > > */opt/Python-3.6.4/lib/libpython3.6m.a: could not read symbols: Bad > value* > > > > By "calling Python from C", do you mean what the docs call "embedding"? > > https://docs.python.org/3/extending/embedding.html > > I would recommend following the tutorial there, if you haven't > already. If you have, and the tutorial code doesn't work for you, post > your code and what you did, and we'll try to help with that. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
On Friday, February 16, 2018 at 10:25:32 PM UTC-6, Chris Angelico wrote: [...] > This is often touted as a necessity for industrial-grade > software. It isn't. There are many things that a type > system, no matter how sophisticated, cannot catch; for some > reason, though, we don't hear people saying "C is useless > for industrial-grade software because it doesn't have > function contracts". And likewise, there are many problems that a seatbelt cannot protect you against -- like for instance: a car-jacker shooting you in the head at point-blank range. But we don't throw the baby out with the bath water, do we? > Anyway, if you want some system of type checking, you can > use static analysis (eg tools like MyPy) to go over your > code the same way a compiler might. Are you suggesting this project for std-lib inclusion? > "The first glaring issue is that I have no guarantee that > is_valid() returns a bool type." -- huh? It's being used in > a boolean context, and it has a name that starts "is_". How > much guarantee are you looking for? *ANY* object can be > used in an 'if', so it doesn't even matter. This is a > stupidly contrived criticism. > > > Python markets itself as a dynamically-typed programming > > language, similar to Perl, Ruby, or JavaScript. The word > > “dynamically typed” has a positive connotation, more so > > than “weakly typed.” Conversely, the word “strongly typed” > > sounds more positive than saying “statically typed.” > > Those are all different terms, and all of them are > misunderstood. They're not synonyms. The author was underscoring the unfortunate psychological semantics at play when words like "strong" are juxtaposed with words like "weak". Sadly, old boy, i believe you've missed the point! > > Python ships with a threading module; but due to how the > > Python interpreter is implemented, it can only ever run > > one thread at a time. This is due to the infamous Global > > Interpreter Lock (GIL). In an age when the only computers > > around had a single core, this was nothing to fuss over. > > Totally not true. The GIL does not stop other threads from > running. Also, Python has existed for multiple CPU systems > pretty much since its inception, I believe. (Summoning the > D'Aprano for history lesson?) Unfortunately "D'App-ran?...Oh!" is still debugging his hello world program. He'll be along later. Or never... Whichever comes /last/. [...] -- https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
On Saturday, February 17, 2018 at 12:58:49 AM UTC-6, Paul Rubin wrote: [...] > Beyond that, the Python community (with some exceptions) seems to have a > widespread hatred of threads. It instead prefers to handle concurrent > i/o with in-thread async schemes that the rest of the world left behind > in the 1960s. Hmm... and many wonder if the source of that hatred is a direct result of CPython's unholy alliance with the GIL? -- https://mail.python.org/mailman/listinfo/python-list
could use some help with this problem! I've been working on it for days but cant seem to get it right !
USING PYTHON 2: 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. Inside that, we want to keep alternating players. You have the option of either writing two blocks of code, or keeping a variable that tracks the current player. The second way is slightly trickier since we haven't learned lists yet, but it's definitely do-able! Finally, we might want to have an innermost loop that checks if the user's input is valid. Is it a number? Is it a valid number (e.g. between 1 and 5)? Are there enough stones in the pile to take off this many? If any of these answers are no, we should tell the user and re-ask them the question So, the basic outline of the program should be something like this: totalStones = 100 maxStones = 5 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) Note how the important numbers 100 and 5 are stored in a single variable at the top. This is good practice -- it allows you to easily change the constants of a program. For example, for testing, you may want to start with only 15 or 20 stones. Be careful with the validity checks. Specifically, we want to keep asking player 1 for their choice as long as their answer is not valid, BUT we want to make sure we ask them at least ONCE. So, for example, we will want to keep a variable which tracks whether their answer is valid, and set it to False initially. Hint: the final number of stones can’t be negative. The game automatically stops when the number of stones reach zero. -- https://mail.python.org/mailman/listinfo/python-list
Re: Gmane seems to be gone
On Sunday, February 18, 2018 at 8:23:03 PM UTC, Mark Lawrence wrote: > On 18/02/18 18:03, Grant Edwards wrote: > > On 2018-02-18, Dennis Lee Bieber wrote: > >> On Sun, 18 Feb 2018 17:26:54 + (UTC), Grant Edwards > >> declaimed the following: > >> > >>> > >>> It was Yomura who picked up the archive and continued the gateway > >>> service a couple years ago, and they just renewed the domain for > >>> another year, so perhaps it's just a temporary DNS problem? > >> > >>Looks like the DNS update is propagating -- I can now reach gmane; but > >> it hasn't shown any new traffic on any of the groups/lists I follow. > > > > Yay! > > > > Gmane.org just started resolving again, and I'm posting this followup > > from slrn via news.gmane.org. I really should donate some money to > > gmane's operators... > > > > Great stuff :) Of course as gmane wasn't working I posted earlier today > on gg but I believe you've opted out of that so wouldn't have seen it :( > What the hell, normal service is resumed :) > > -- > My fellow Pythonistas, ask not what our language can do for you, ask > what you can do for our language. > > Mark Lawrence Blast, seems like it's down again. Can somebody confirm that I'm correct please, cheers :( -- Kindest regards. Mark Lawrence. -- 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 !
On Tuesday, February 20, 2018 at 5:08:49 AM UTC, Marc Cohen wrote: > USING PYTHON 2: > > 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. > > Inside that, we want to keep alternating players. You have the option of > either writing two blocks of code, or keeping a variable that tracks the > current player. The second way is slightly trickier since we haven't learned > lists yet, but it's definitely do-able! > > Finally, we might want to have an innermost loop that checks if the user's > input is valid. Is it a number? Is it a valid number (e.g. between 1 and 5)? > Are there enough stones in the pile to take off this many? If any of these > answers are no, we should tell the user and re-ask them the question > > So, the basic outline of the program should be something like this: > > totalStones = 100 > > maxStones = 5 > > 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) > > Note how the important numbers 100 and 5 are stored in a single variable at > the top. This is good practice -- it allows you to easily change the > constants of a program. For example, for testing, you may want to start with > only 15 or 20 stones. > > Be careful with the validity checks. Specifically, we want to keep asking > player 1 for their choice as long as their answer is not valid, BUT we want > to make sure we ask them at least ONCE. So, for example, we will want to keep > a variable which tracks whether their answer is valid, and set it to False > initially. > > Hint: the final number of stones can’t be negative. The game automatically > stops when the number of stones reach zero. Sorry old bean but we don't write code for you. So you show us the code that you've been working on for days and tell us what's wrong with it, and we'll point you in the right direction. -- Kindest regards. Mark Lawrence. -- https://mail.python.org/mailman/listinfo/python-list
Re: Are the critiques in "All the things I hate about Python" valid?
On Monday, February 19, 2018 at 1:07:02 PM UTC, Anders Wegge Keller wrote: > På Mon, 19 Feb 2018 04:39:31 + (UTC) > Steven D'Aprano skrev: > > On Mon, 19 Feb 2018 04:26:32 +0100, Anders Wegge Keller wrote: > > > > > På Mon, 19 Feb 2018 08:47:14 +1100 > > > Tim Delaney skrev: > > >> On 18 February 2018 at 22:55, Anders Wegge Keller > > >> wrote: > > > > > > > > [...] > > > > > >> You couldn't have got the above much more wrong. > > > > > >> As others have said, typing is about how the underlying memory is > > >> treated. > > > > > > And that is exactly my point. Python does not have a typed list. It > > > have a list that takes whatever is thrown into it. > > > > > > I'll skip the rest, as you totally missed the point. > > > > I think its actually you have totally missed the point. What you want is > > a homogeneous list, a list which only accepts items of the same type. The > > built-in list is not that data structure, but Python already has > > something similar: see the array module. > > Given that I'm the one making a point about the unwarranted smugness, I > know that I'm not missing anything. Array is not even close to providing a > strongly typed container. For all of the yakking about other languages > weak, blah, BCPL, blah, I still wonder where that need to feel superior to > anything else comes from. > > Python isn't particular strong typed. In fact, apart from asking an object > what type it is, types are not that important. It's the interface that > matters. I wonder why this is a sore point for Python developers? > > > -- > //Wegge Congratulations, you're the first new person I've had on my Dream Team for some months, fresh blood is always so welcome. -- Kindest regards. Mark Lawrence. -- https://mail.python.org/mailman/listinfo/python-list
