Re: Problems with python3.6 on one system, but OK on another
Cecil Westerhof writes: > I build python3.6 on two systems. On one system everything is OK: > Python 3.6.0 (default, Jan 21 2017, 11:19:56) > [GCC 4.9.2] on linux > Type "help", "copyright", "credits" or "license" for more information. > > > But on another I get: > Could not find platform dependent libraries > Consider setting $PYTHONHOME to [:] > Python 3.6.0 (default, Jan 21 2017, 12:20:38) > [GCC 4.8.5] on linux > Type "help", "copyright", "credits" or "license" for more information. > > Probably not a big problem, but just wondering what is happening here. > On both systems PYTHONHOME is not set and with the old version (3.4.5) > I did/do not get this message. A Python installation consists of two parts: the Python binary (i.e. the Python interpreter) and the Python runtime library (everything not built into the interpreter itself). When you start Python, you effectively start the binary. This then tries to locate the parts forming its runtime library. Essentially, there are two parts: platform independent (i.e. Python modules/packages) and platform dependent (usually shared objects implemented in "C" or "C++"). The binary is using heuristics to locate those parts, involving the (usually internal) variables "prefix" and "exec_prefix" for the platform independent and dependent parts, respectively. On some platforms, the operating system allows a binary to determine the full path it has been started from. On those platforms, the above mentioned heuristics may use this path to locate the runtime library parts. On other platforms, default values for "prefix" and "exec_prefix" are determined during the Python generation. As a consequnece, something must have gone wrong with the generation or installation of your badly behaving Python. To start the investigation, I would look at the binaries' notion of "prefix" and "exec_prefix". You can find them via >>> import sys >>> sys.prefix, sys.exec_prefix On a "*nix" like platform, you should find the platform dependent parts of the runtime library unter "/lib/Python/lib-dynload". Check whether this directory exists and is not empty. -- https://mail.python.org/mailman/listinfo/python-list
Re: Adding colormaps?
you have here a full example , for another version not significant changes: http://matplotlib.org/examples/color/colormaps_reference.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Using python to start programs after logging in
On Thursday 19 Jan 2017 20:08 CET, Cecil Westerhof wrote: > I am writing a python program to start the programs that need to be > started after logging in. I published what I have until now at: https://github.com/CecilWesterhof/PythonScripts/blob/master/startPrograms.py I do not mind some feedback. ;-) Next step is to write a GUI program to maintain the database. That is new territory for me. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof -- https://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] "Immutable Builder" Pattern and Operator
On 23.01.2017 14:28, Soni L. wrote: > > > On 23/01/17 11:18 AM, M.-A. Lemburg wrote: >> On 23.01.2017 14:05, Soni L. wrote: >>> Yeah but the dotequals operator has many other benefits: >>> >>> long_name .= __call__ # cast to callable >>> long_name .= wrapped # unwrap >>> etc >>> >>> And it also looks neat. >> I don't see this an being a particular intuitive way of writing >> such rather uncommon constructs. >> >> The syntax is not clear (what if you have an expression on the RHS) >> and it doesn't save you much in writing (if long_name is too long >> simply rebind it under a shorter name for the purpose of the code >> block). > > It's literally sugar for repeating the name and moving the dot to the > right. I think it's clearer than most other compound operators in that > it doesn't affect precedence rules. > > `x += y`, for any code `y`, is equivalent to `x = x + (y)`, not `x = x + > y`. > > `x .= y`, for any code `y`, is equivalent to `x = x . y`, not `x = x . > (y)`. Well, then please consider these: x .= y + z x .= y * z x .= y.z x .= y.z() >> Also note that rebinding different objects to the same name >> in the same block is often poor style and can easily lead to >> hard to track bugs. >> > > Rebinding different objects to the same name in rapid succession > is fine. Not in my book :-) It may be fine if the object type stays the same or in those few cases, where you want to accept multiple different types for a parameter and then coerce these to a type that you use in the rest of the code block. But even in those cases, debugging becomes easier if you keep the original binding in place (since you then know where the new values originated). This is not good style... x = 'abc' x = len(x) x = [x, 1] x = ''.join(str(a) for a in x) print (x) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jan 23 2017) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ -- https://mail.python.org/mailman/listinfo/python-list
Re: How to create a socket.socket() object from a socket fd?
Op 22-01-17 om 01:52 schreef Grant Edwards: > Newsgroups: gmane.comp.python.general > From: Grant Edwards > Subject: Re: How to create a socket.socket() object from a socket fd? > References: > > > Followup-To: > > > > I'm still baffled why the standard library fromfd() code dup()s the > descriptor. > > According to the comment in the CPython sources, the author of > fromfd() is guessing that the user wants to be able to close the > descriptor separately from the socket. > > If the user wanted the socket object to use a duplicate descriptor for > some reason, the caller should call os.dup() -- it's only _eight_ > keystrokes. Eight keystrokes that makes it obvious to anybody reading > the code that there are now two descriptors and you have to close both > the original descriptor and the socket. > > When you create a Python file object from a file descriptor using > os.fdopen(), does it dup the descriptor? No. Would a reasonable > person expect socket.fromfd() to duplicate the descriptor? No. > > Should it? > > No. The standard response to issues like this is: A foolish consistency is the hobgoblin of little minds -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] "Immutable Builder" Pattern and Operator
On Monday, January 23, 2017 at 2:11:53 PM UTC, M.-A. Lemburg wrote: > On 23.01.2017 14:28, Soni L. wrote: > > > > > > On 23/01/17 11:18 AM, M.-A. Lemburg wrote: > >> On 23.01.2017 14:05, Soni L. wrote: > >>> Yeah but the dotequals operator has many other benefits: > >>> > >>> long_name .= __call__ # cast to callable > >>> long_name .= wrapped # unwrap > >>> etc > >>> > >>> And it also looks neat. > >> I don't see this an being a particular intuitive way of writing > >> such rather uncommon constructs. > >> > >> The syntax is not clear (what if you have an expression on the RHS) > >> and it doesn't save you much in writing (if long_name is too long > >> simply rebind it under a shorter name for the purpose of the code > >> block). > > > > It's literally sugar for repeating the name and moving the dot to the > > right. I think it's clearer than most other compound operators in that > > it doesn't affect precedence rules. > > > > `x += y`, for any code `y`, is equivalent to `x = x + (y)`, not `x = x + > > y`. > > > > `x .= y`, for any code `y`, is equivalent to `x = x . y`, not `x = x . > > (y)`. > > Well, then please consider these: > > x .= y + z > x .= y * z > x .= y.z > x .= y.z() > > >> Also note that rebinding different objects to the same name > >> in the same block is often poor style and can easily lead to > >> hard to track bugs. > >> > > > > Rebinding different objects to the same name in rapid succession > > is fine. > > Not in my book :-) > > It may be fine if the object type stays the same or > in those few cases, where you want to accept multiple > different types for a parameter and then coerce these > to a type that you use in the rest of the code block. > > But even in those cases, debugging becomes easier if > you keep the original binding in place (since you then > know where the new values originated). > > This is not good style... > > x = 'abc' > x = len(x) > x = [x, 1] > x = ''.join(str(a) for a in x) > print (x) > > -- > Marc-Andre Lemburg > eGenix.com > The wrong list methinks :) Kindest regards. Mark Lawrence. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to create a socket.socket() object from a socket fd?
On 2017-01-23, Antoon Pardon wrote: > Op 22-01-17 om 01:52 schreef Grant Edwards: >> Newsgroups: gmane.comp.python.general >> From: Grant Edwards >> Subject: Re: How to create a socket.socket() object from a socket fd? >> References: >> >> >> Followup-To: >> >> >> >> I'm still baffled why the standard library fromfd() code dup()s the >> descriptor. >> >> According to the comment in the CPython sources, the author of >> fromfd() is guessing that the user wants to be able to close the >> descriptor separately from the socket. >> >> If the user wanted the socket object to use a duplicate descriptor for >> some reason, the caller should call os.dup() -- it's only _eight_ >> keystrokes. Eight keystrokes that makes it obvious to anybody reading >> the code that there are now two descriptors and you have to close both >> the original descriptor and the socket. >> >> When you create a Python file object from a file descriptor using >> os.fdopen(), does it dup the descriptor? No. Would a reasonable >> person expect socket.fromfd() to duplicate the descriptor? No. >> >> Should it? >> >> No. > > The standard response to issues like this is: > >A foolish consistency is the hobgoblin of little minds And wise consistency is the foundation of a good language design. -- Grant Edwards grant.b.edwardsYow! I'm wet! I'm wild! at gmail.com -- https://mail.python.org/mailman/listinfo/python-list
How coding in Python is bad for you
The article is here http://lenkaspace.net/index.php/blog/show/111 Kindest regards. Mark Lawrence. -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On Tue, Jan 24, 2017 at 4:24 AM, wrote: > The article is here http://lenkaspace.net/index.php/blog/show/111 I would respond point-by-point if I thought the author had a clue. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Is it possible to get the Physical memory address of a variable in python?
how we can access the value from using id.. like x=10 id(x) 3235346364 how i can read value 10 using id 3235346364 -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On 01/23/2017 09:34 AM, Chris Angelico wrote: On Tue, Jan 24, 2017 at 4:24 AM, wrote: The article is here http://lenkaspace.net/index.php/blog/show/111 I would respond point-by-point if I thought the author had a clue. Yeah, arguing with that person will be a waste of time. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to get the Physical memory address of a variable in python?
On Tue, Jan 24, 2017 at 4:49 AM, Sourabh Kalal wrote: > how we can access the value from using id.. > like x=10 > id(x) > 3235346364 > > how i can read value 10 using id 3235346364 No, you can't. That isn't a memory address - it's just a unique identifier. Python doesn't have memory addresses. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to get the Physical memory address of a variable in python?
On 1/23/2017 12:49 PM, Sourabh Kalal wrote: how we can access the value from using id.. like x=10 id(x) 3235346364 how i can read value 10 using id 3235346364 *In Python*, you cannot. Ids are mainly for internal use of implementations. Implementors also use them to test their implementation. *CPython* comes with a module (ctypes) that can be used to muck around with interpreter internals, but it is definitely not for beginners. I don't know about other implementations. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to get the Physical memory address of a variable in python?
On Mon, Jan 23, 2017 at 12:49 PM, Chris Angelico wrote: > > On Tue, Jan 24, 2017 at 4:49 AM, Sourabh Kalal wrote: > > how we can access the value from using id.. > > like x=10 > > id(x) > > 3235346364 > > > > how i can read value 10 using id 3235346364 > > No, you can't. That isn't a memory address - it's just a unique > identifier. Python doesn't have memory addresses. Well, it might be, but that would be very implementation-dependent. Any attempt to treat an id as a memory address and interpret the object at that address as the beginning of a PyObject of any kind will be fragile in the extreme. Even if you have two different implementations at hand which both use memory addresses as convenient ids, there's no guarantee that the address represents that start of a CPython PyObject. >>> hex(3235346364) '0xc0d777bc' There. *Now* you have an address. Hack to your heart's content. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to get the Physical memory address of a variable in python?
Sourabh Kalal wrote: > how we can access the value from using id.. > like x=10 > id(x) > 3235346364 > > how i can read value 10 using id 3235346364 Use ctypes: $ python3 Python 3.4.3 (default, Nov 17 2016, 01:08:31) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> ctypes.c_ubyte.from_address(id(10) + 24).value = 11 >>> 10 == 11 True :) -- https://mail.python.org/mailman/listinfo/python-list
Re: Adding colormaps?
Den 2017-01-23 skrev blue : > you have here a full example , for another version not significant changes: > http://matplotlib.org/examples/color/colormaps_reference.html Thanks but this only shows how to use it once you have it. When I run this code I get an error message telling it can't find any of those new colormaps. /Martin -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On 2017-01-23, breamore...@gmail.com wrote: > The article is here http://lenkaspace.net/index.php/blog/show/111 I don't really think any of his points are valid, but one way that programming in Python is bad for you: * It reduces your tolerance for progamming in PHP zero. If you end up assigned to a PHP project, you end up miserable and unpleasant to work with or just plain unemployed. -- Grant Edwards grant.b.edwardsYow! MERYL STREEP is my at obstetrician! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On 01/23/2017 10:34 AM, Chris Angelico wrote: > I would respond point-by-point if I thought the author had a clue. Yeah a pretty bizarre, flame-bait blog post. Glad I use an ad-blocker as a matter of course. I'm uncertain as to why Mark chose to post that particular little gem to the list. It's neither thought-provoking nor terribly insightful. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to get the Physical memory address of a variable in python?
On Tue, Jan 24, 2017 at 6:05 AM, Skip Montanaro wrote: > On Mon, Jan 23, 2017 at 12:49 PM, Chris Angelico wrote: >> >> On Tue, Jan 24, 2017 at 4:49 AM, Sourabh Kalal wrote: >> > how we can access the value from using id.. >> > like x=10 >> > id(x) >> > 3235346364 >> > >> > how i can read value 10 using id 3235346364 >> >> No, you can't. That isn't a memory address - it's just a unique >> identifier. Python doesn't have memory addresses. > > Well, it might be, but that would be very implementation-dependent. > Any attempt to treat an id as a memory address and interpret the > object at that address as the beginning of a PyObject of any kind will > be fragile in the extreme. Even if you have two different > implementations at hand which both use memory addresses as convenient > ids, there's no guarantee that the address represents that start of a > CPython PyObject. > hex(3235346364) > '0xc0d777bc' > > There. *Now* you have an address. Hack to your heart's content. No, you now have a hexadecimal representation of an integer. Memory addresses are integers; Python object identifiers are also integers. The fact that they may happen to correspond *in CPython* is basically a coincidence. In a language like C, where pointers and memory addresses are real things, you can work with an integer and dereference it to get the data at that address. In BASIC, where I first learned programming, you have specific instructions to mess with memory (I have fond memories of messing around with segment zero to change the status of Caps Lock etc, and of peeking and poking in video memory, and stuff). But in Python, that exists only in ctypes, and that only because ctypes is basically C. rosuav@sikorsky:~$ python3 Python 3.7.0a0 (default:cebc9c7ad195, Jan 24 2017, 06:55:19) [GCC 6.2.0 20161027] on linux Type "help", "copyright", "credits" or "license" for more information. >>> objs = [object() for _ in range(10)] >>> [id(x) for x in objs] [140652901773504, 140652901773520, 140652901773536, 140652901773552, 140652901773568, 140652901773584, 140652901773600, 140652901773616, 140652901773632, 140652901773648] These could well be memory addresses, but... >>> objs = [object() for _ in range(10)] >>> [id(x) for x in objs] [2, 3, 4, 5, 6, 7, 8, 9, 10, 11] ... these almost certainly aren't. They are, however, unique integer values (the 'objs' list guarantees that all objects are simultaneously alive, ergo the IDs must be unique). Other Python implementations are free to do what they like. Quite a few do seem to use something like a memory address (uPy, PyPy, PyPyJS), but not all: Brython 3.3.0 on Netscape 5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 >>> objs = [object() for _ in range(10)] >>> [id(x) for x in objs] [54, 55, 56, 57, 58, 59, 60, 61, 62, 63] There's basically no way to go from an ID to the object. If you know what data type it is (eg an integer, as in the OP's example), you can reach in and grab the contents, but there's no way to write this function: def deref(id): ... # assert deref(id(x)) is x The best you could do, in terms of parlour tricks, is to test it only on small integers, where ctypes can get you the value of the integer, and thanks to small-int-caching, it will actually be the same object. But it won't work for larger integers. It's not a pointer. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to get the Physical memory address of a variable in python?
On 01/23/2017 10:49 AM, Sourabh Kalal wrote: > how we can access the value from using id.. > like x=10 > id(x) > 3235346364 > > how i can read value 10 using id 3235346364 Many objects in python such as numbers like 10 or strings are immutable; they can never be altered once called into existance. When you assign to a variable, you are binding the variable name to an object. So if you later took your x variable and re-assigned it to value 11, the id of x would change to reflect this new object 11. If you could find the memory address in your example where 10 is stored, and then modified it, you could mess up a lot of things because the interpreter is free to optimize and to use the same 10 object every places where 10 is assigned to a variable. -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On Tue, Jan 24, 2017 at 6:59 AM, Grant Edwards wrote: > On 2017-01-23, breamore...@gmail.com wrote: > >> The article is here http://lenkaspace.net/index.php/blog/show/111 > > I don't really think any of his points are valid, but one way that > programming in Python is bad for you: > > * It reduces your tolerance for progamming in PHP zero. If you end >up assigned to a PHP project, you end up miserable and unpleasant >to work with or just plain unemployed. I believe that's "bad for you" in the sense that chocolate is bad for you. It isn't. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to get the Physical memory address of a variable in python?
On Mon, Jan 23, 2017 at 2:17 PM, Chris Angelico wrote: >> There. *Now* you have an address. Hack to your heart's content. > > No, you now have a hexadecimal representation of an integer. You missed my attempt at levity, I think. S -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On Tue, 24 Jan 2017 07:19:42 +1100, Chris Angelico wrote: > On Tue, Jan 24, 2017 at 6:59 AM, Grant Edwards > wrote: >> On 2017-01-23, breamore...@gmail.com wrote: >> >>> The article is here http://lenkaspace.net/index.php/blog/show/111 >> >> I don't really think any of his points are valid, but one way that >> programming in Python is bad for you: >> >> * It reduces your tolerance for progamming in PHP zero. If you end >>up assigned to a PHP project, you end up miserable and unpleasant to >>work with or just plain unemployed. > > I believe that's "bad for you" in the sense that chocolate is bad for > you. > > It isn't. > > ChrisA chocolate is a poison (lethal dose for a human approx 22lb) -- Make headway at work. Continue to let things deteriorate at home. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to get the Physical memory address of a variable in python?
On Tue, Jan 24, 2017 at 7:26 AM, Skip Montanaro wrote: > On Mon, Jan 23, 2017 at 2:17 PM, Chris Angelico wrote: >>> There. *Now* you have an address. Hack to your heart's content. >> >> No, you now have a hexadecimal representation of an integer. > > You missed my attempt at levity, I think. Ahh, I guess I did. Sadly, it is all too true that there is no statement so ridiculous that it's unquestionably a joke. An ill-informed person could easily come out with exactly the same comment. :( ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Adding colormaps?
(sorry for top-posting) I does not appear to be possible in matplolibrc (1). But you can use matplotlib.cm.register_cmap to register new cmaps (2) such as these (3). (Note: I did not try this) (1)http://matplotlib.org/1.4.0/users/customizing.html (2)http://matplotlib.org/api/cm_api.html (3)https://github.com/BIDS/colormap/blob/master/colormaps.py From: Python-list on behalf of Martin Schöön Sent: Saturday, January 21, 2017 8:42:29 PM To: python-list@python.org Subject: Re: Adding colormaps? Den 2017-01-21 skrev Gilmeh Serda : > On Wed, 18 Jan 2017 21:41:34 +, Martin Schöön wrote: > >> What I would like to do is to add the perceptually uniform sequential >> colormaps introduced in version 1.5.something. I would like to do this >> without breaking my Debian system in which Matplotlib version 1.4.2 is >> the newest version available in the repo. > > Haven't checked, but I assume you can get the source. Compile it but > don't install it and then use the result in virtualenv, maybe? > I am hoping for directions to a config file to download and place somewhere... /Martin -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
sola dosis facit venenum ~ Paracelsus (1493-1541) From: Python-list on behalf of alister Sent: Monday, January 23, 2017 8:32:49 PM To: python-list@python.org Subject: Re: How coding in Python is bad for you On Tue, 24 Jan 2017 07:19:42 +1100, Chris Angelico wrote: > On Tue, Jan 24, 2017 at 6:59 AM, Grant Edwards > wrote: >> On 2017-01-23, breamore...@gmail.com wrote: >> >>> The article is here http://lenkaspace.net/index.php/blog/show/111 >> >> I don't really think any of his points are valid, but one way that >> programming in Python is bad for you: >> >> * It reduces your tolerance for progamming in PHP zero. If you end >>up assigned to a PHP project, you end up miserable and unpleasant to >>work with or just plain unemployed. > > I believe that's "bad for you" in the sense that chocolate is bad for > you. > > It isn't. > > ChrisA chocolate is a poison (lethal dose for a human approx 22lb) -- Make headway at work. Continue to let things deteriorate at home. -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On 2017-01-23, alister wrote: > On Tue, 24 Jan 2017 07:19:42 +1100, Chris Angelico wrote: >> I believe that's "bad for you" in the sense that chocolate is bad for >> you. >> >> It isn't. > > chocolate is a poison (lethal dose for a human approx 22lb) That's a meaningless statement. *Everything* is a poison in sufficient quantities. -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On Monday, January 23, 2017 at 3:41:17 PM UTC-5, Jon Ribbens wrote: > On 2017-01-23, alister wrote: > > On Tue, 24 Jan 2017 07:19:42 +1100, Chris Angelico wrote: > >> I believe that's "bad for you" in the sense that chocolate is bad for > >> you. > >> > >> It isn't. > > > > chocolate is a poison (lethal dose for a human approx 22lb) > > That's a meaningless statement. *Everything* is a poison > in sufficient quantities. I think you need to calibrate your sarcasm filter ;-). By the way coffee is also dangerous - especially in 50lbs bags (when it hits you). -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On Tue, Jan 24, 2017 at 8:04 AM, Adam M wrote: > On Monday, January 23, 2017 at 3:41:17 PM UTC-5, Jon Ribbens wrote: >> On 2017-01-23, alister wrote: >> > On Tue, 24 Jan 2017 07:19:42 +1100, Chris Angelico wrote: >> >> I believe that's "bad for you" in the sense that chocolate is bad for >> >> you. >> >> >> >> It isn't. >> > >> > chocolate is a poison (lethal dose for a human approx 22lb) >> >> That's a meaningless statement. *Everything* is a poison >> in sufficient quantities. > > I think you need to calibrate your sarcasm filter ;-). By the way coffee is > also dangerous - especially in 50lbs bags (when it hits you). Or with sufficient velocity. The LD50 of lead is about 450mg/kg [1], which means that a typical 70kg human could ingest about 31 grams of lead and have a fifty-fifty chance of survival. But just a few grams of lead at the speed of sound will probably kill you. [2] ChrisA [1] http://whs.rocklinusd.org/documents/Science/Lethal_Dose_Table.pdf [2] https://xkcd.com/444/ -- https://mail.python.org/mailman/listinfo/python-list
String Replacement
I have a string like "Trump is $ the president of USA % Obama was $ the president of USA % Putin is $ the premier of Russia%" Here, I want to extract the portions from $...%, which would be "the president of USA", "the president of USA", "the premier of Russia" and would work some post extraction jobs, like I may split them or annotate them and may replace them back to its own position with the edited string. In the end it may look like "Trump is the/DET president/NN of/PREP USA/NN Obama was the/DET president/NN of/PREP USA/NN Putin is the/DET premier/NN of/PREP Russia/NN" I am working around replace and re.sub If any one may kindly suggest. I am using Python2.7.12 on MS-Windows 7 Thanking in Advance -- https://mail.python.org/mailman/listinfo/python-list
Re: String Replacement
On Tue, Jan 24, 2017 at 8:23 AM, wrote: > I have a string like > > "Trump is $ the president of USA % Obama was $ the president of USA % Putin > is $ the premier of Russia%" > > Here, I want to extract the portions from $...%, which would be > > "the president of USA", > "the president of USA", > "the premier of Russia" > > and would work some post extraction jobs, like I may split them or annotate > them and may replace them > back to its own position with the edited string. > The simplest solution would be a regex. Have a shot at it and see how you go; if you get stuck, post code. > I am using Python2.7.12 on MS-Windows 7 Any particular reason you're not using Python 3? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to get the Physical memory address of a variable in python?
On Monday, January 23, 2017 at 5:59:42 PM UTC, Sourabh Kalal wrote: > how we can access the value from using id.. > like x=10 > id(x) > 3235346364 > > how i can read value 10 using id 3235346364 What are you trying to achieve here? If you'd explain that rather than how you're trying to achieve it you're likely to get better answers. Kindest regards. Mark Lawrence. -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On Mon, 23 Jan 2017 20:39:26 +, Jon Ribbens wrote: > On 2017-01-23, alister wrote: >> On Tue, 24 Jan 2017 07:19:42 +1100, Chris Angelico wrote: >>> I believe that's "bad for you" in the sense that chocolate is bad for >>> you. >>> >>> It isn't. >> >> chocolate is a poison (lethal dose for a human approx 22lb) > > That's a meaningless statement. *Everything* is a poison > in sufficient quantities. Yes, even water. -- GNU/Linux user #557453 The cow died so I don't need your bull! -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On 23/01/2017 17:34, Chris Angelico wrote: On Tue, Jan 24, 2017 at 4:24 AM, wrote: The article is here http://lenkaspace.net/index.php/blog/show/111 I would respond point-by-point if I thought the author had a clue. I thought points 1 to 4 were valid, in that the assertions were true. Point 5 (memory leaks) I haven't experienced. Point 6 (libraries depending on libraries...) is probably true in other languages too. Point 7 (Python claiming to be general purpose) I don't have an opinion about. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On Tue, Jan 24, 2017 at 8:55 AM, BartC wrote: > On 23/01/2017 17:34, Chris Angelico wrote: >> >> On Tue, Jan 24, 2017 at 4:24 AM, wrote: >>> >>> The article is here http://lenkaspace.net/index.php/blog/show/111 >> >> >> I would respond point-by-point if I thought the author had a clue. > > > I thought points 1 to 4 were valid, in that the assertions were true. 1 is wrong - there is structure, same as in every language. Or if it's true, it's true in every language. 2 is also trivially true - you can ALWAYS define variables wrongly. Yes, okay, so you don't have data type checking, but that's only going to catch a specific subset of errors. 3, well, okay. But if you get your indentation wrong in C++, Java, etc, it should fail code review. 4 is flat out wrong. > Point 5 (memory leaks) I haven't experienced. Me neither - Python doesn't leak memory, and in fact CPython has leak testing as part of its test suite. You are *far* more likely to experience memory leaks in a C program than a Python one. > Point 6 (libraries depending on libraries...) is probably true in other > languages too. And far more so. He says "(because, let's face it, Python by itself doesn't support much)" - that's flat wrong. Python's standard library is _excellent_ compared to many other languages'. > Point 7 (Python claiming to be general purpose) I don't have an opinion > about. He doesn't even have a decent point in there. We're so insular because we think Python is general? Huh? > But for a big project, Python code can become a big mess very quickly, > unless there is an experienced programmer to guide the development process. So... can you name a language where a bunch of novices can build a huge project with no scaling troubles? Honestly? Get yourself an expert, at least in an advisory role. Not one of his points is truly valid, other than the ones that are trivially valid and true of every language. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On 01/23/2017 01:55 PM, BartC wrote: On 23/01/2017 17:34, Chris Angelico wrote: On Tue, Jan 24, 2017 at 4:24 AM, breamoreboy wrote: The article is here http://lenkaspace.net/index.php/blog/show/111 I would respond point-by-point if I thought the author had a clue. I thought points 1 to 4 were valid, in that the assertions were true. Seriously? 1. Structure - having a predefined structure does not keep your program from becoming a mess. 2. Lying - any language can have poorly named parameters. 3. Meaning based on indentation - flat-out wrong: x += 1 does exactly what it says, whether it's indented once, twice, or seven times. 4. No compiler & no feedback - Python code is compiled, and feedback is available via linters, mypy, etc. The only thing proven by that essay is that Lenka is a lousy Python programmer. He (she?) didn't even tag the article with Python, instead using the tags Java, C++, and ActionScript. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: How to create a socket.socket() object from a socket fd?
On 01/23/2017 09:00 AM, Grant Edwards wrote: On 2017-01-23, Antoon Pardon wrote: The standard response to issues like this is: A foolish consistency is the hobgoblin of little minds And wise consistency is the foundation of a good language design. Otherwise known as: if there's not a /very/ good reason to make them different, make them the same. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On 23/01/2017 21:04, Adam M wrote: On Monday, January 23, 2017 at 3:41:17 PM UTC-5, Jon Ribbens wrote: On 2017-01-23, alister wrote: On Tue, 24 Jan 2017 07:19:42 +1100, Chris Angelico wrote: I believe that's "bad for you" in the sense that chocolate is bad for you. It isn't. chocolate is a poison (lethal dose for a human approx 22lb) That's a meaningless statement. *Everything* is a poison in sufficient quantities. I think you need to calibrate your sarcasm filter ;-). By the way coffee is also dangerous - especially in 50lbs bags (when it hits you). What a way to go... 50lbs of coffee beans made into espresso and 22lbs of chocolate to eat with all those tiny cups. Yes, the article is clickbait which is why I delight in reading them with ad and script blockers turned up to maximum. -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On 01/23/2017 11:24 AM, breamore...@gmail.com wrote: > The article is here http://lenkaspace.net/index.php/blog/show/111 > > Kindest regards. > > Mark Lawrence. > Beyond silly. Languages - like all tools - can be used properly or badly. -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On 01/23/2017 02:19 PM, Chris Angelico wrote: > On Tue, Jan 24, 2017 at 6:59 AM, Grant Edwards > wrote: >> On 2017-01-23, breamore...@gmail.com wrote: >> >>> The article is here http://lenkaspace.net/index.php/blog/show/111 >> >> I don't really think any of his points are valid, but one way that >> programming in Python is bad for you: >> >> * It reduces your tolerance for progamming in PHP zero. If you end >>up assigned to a PHP project, you end up miserable and unpleasant >>to work with or just plain unemployed. > > I believe that's "bad for you" in the sense that chocolate is bad for you. > > It isn't. > > ChrisA > It's bad for you in the same sense tha chocolate is bad for you - if you melt it and pour it into your ears... -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On 23/01/2017 22:09, Chris Angelico wrote: On Tue, Jan 24, 2017 at 8:55 AM, BartC wrote: On 23/01/2017 17:34, Chris Angelico wrote: On Tue, Jan 24, 2017 at 4:24 AM, wrote: The article is here http://lenkaspace.net/index.php/blog/show/111 I would respond point-by-point if I thought the author had a clue. I thought points 1 to 4 were valid, in that the assertions were true. 1 is wrong - there is structure, same as in every language. Or if it's true, it's true in every language. Python (I think in common with other scripting languages) allows you to place statement outside functions, either before, after or in-between functions. While functions themselves, as well as imports, can be conditionally defined. 2 is also trivially true - you can ALWAYS define variables wrongly. Yes, okay, so you don't have data type checking, but that's only going to catch a specific subset of errors. With Python, you can take function names that you've defined, imported modules, or math.pi, and set them all to "edward g robinson". (The name just came into my head..) 3, well, okay. But if you get your indentation wrong in C++, Java, etc, it should fail code review. With C++ or Java, it's possible to tell the indentation is wrong (because of the extra redundancy of having the indentation /and/ block delimiters). That's a bit harder in Python making source more fragile. 4 is flat out wrong. (About having no compiler.) Yes (C)Python does have a byte-code compiler but there are a vast range of errors that it cannot trap at compile-time because of its dynamic nature. Maybe you can run tools to do extra analyses, but as it's normally used, many errors are not detected until execution. Spelling errors in names for example. (Actually when I tested my assertion above I assigned to math.p rather than math.pi; no error not even at runtime, just the wrong result. Or technically the right one, as math.pi still had the usual value!) I'm not criticising it, just stating facts which may well have been the experience of the guy who wrote the article, giving the impression of a more chaotic, free-for-all language than they may have been used to, or expected. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On Tue, Jan 24, 2017 at 11:44 AM, BartC wrote:
> On 23/01/2017 22:09, Chris Angelico wrote:
>> 1 is wrong - there is structure, same as in every language. Or if it's
>> true, it's true in every language.
>
>
> Python (I think in common with other scripting languages) allows you to
> place statement outside functions, either before, after or in-between
> functions. While functions themselves, as well as imports, can be
> conditionally defined.
In other words, Python doesn't have arbitrary, useless structure by
forcing you to put everything inside a class definition and then
inside a method, as in Java. How is that a reason that Python is "bad
for you"?
REXX has even less structure than Python - it doesn't even have
functions, just labels, so you can actually have two functions that
share a common tail. And yes, you can abuse that horrendously to
create unreadable code. Is REXX a bad language because of that? No.
You can use structure badly, and you can use freedom badly.
> 2 is also trivially true - you can
>>
>> ALWAYS define variables wrongly. Yes, okay, so you don't have data
>> type checking, but that's only going to catch a specific subset of
>> errors.
>
>
> With Python, you can take function names that you've defined, imported
> modules, or math.pi, and set them all to "edward g robinson". (The name just
> came into my head..)
Yes, and? You can do that in other languages too. So? Again, how is
this proof that Python is "bad for you"?
>> 3, well, okay. But if you get your indentation wrong in C++,
>> Java, etc, it should fail code review.
>
>
> With C++ or Java, it's possible to tell the indentation is wrong (because of
> the extra redundancy of having the indentation /and/ block delimiters).
> That's a bit harder in Python making source more fragile.
With C++ or Java, it's possible to tell that the braces are misplaced
(because of the extra redundancy). When that happens, the compiler
won't tell you; it'll just silently do the wrong thing. In Python,
that can't happen. Python is therefore more robust.
What's to say which is correct?
>> 4 is flat out wrong.
>
>
> (About having no compiler.) Yes (C)Python does have a byte-code compiler but
> there are a vast range of errors that it cannot trap at compile-time because
> of its dynamic nature.
>
> Maybe you can run tools to do extra analyses, but as it's normally used,
> many errors are not detected until execution. Spelling errors in names for
> example. (Actually when I tested my assertion above I assigned to math.p
> rather than math.pi; no error not even at runtime, just the wrong result. Or
> technically the right one, as math.pi still had the usual value!)
Plenty of editors can catch those even before you run the code. And
there are languages with far more structure that still don't protect
you against very common classes of bug.
if (i = 1) {
printf("i is 1 now.");
}
Some compilers will give you a warning for this code, if you ask for
all warnings to be enabled. Others won't. The C language doesn't
protect you. Should we abolish C?
> I'm not criticising it, just stating facts which may well have been the
> experience of the guy who wrote the article, giving the impression of a more
> chaotic, free-for-all language than they may have been used to, or expected.
And because it's not what he's used to, it is a fundamentally bad
language. That's the sign of a badly uninformed post.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On Tue, Jan 24, 2017 at 11:55 AM, Dennis Lee Bieber wrote: > On Mon, 23 Jan 2017 22:55:19 +, mm0fmf declaimed the > following: > > >>50lbs of coffee beans made into espresso and 22lbs of chocolate to eat >>with all those tiny cups. >> > How about just 75lbs of chocolate covered espresso beans Can you fire them out of a machine gun? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On 24/01/2017 00:56, Chris Angelico wrote:
On Tue, Jan 24, 2017 at 11:44 AM, BartC wrote:
With C++ or Java, it's possible to tell the indentation is wrong (because of
the extra redundancy of having the indentation /and/ block delimiters).
That's a bit harder in Python making source more fragile.
With C++ or Java, it's possible to tell that the braces are misplaced
(because of the extra redundancy). When that happens, the compiler
won't tell you; it'll just silently do the wrong thing. In Python,
that can't happen. Python is therefore more robust.
What's to say which is correct?
I don't get you. Start with this code
if 0:
print ("one")
print ("two")
print ("three")
It prints "three". Now the second indent accidentally gets deleted:
if 0:
print ("one")
print ("two")
print ("three")
It still runs, but now prints "two", "three". Take the same code with
block delimiters, and take out that same indent:
if 0 then
print ("one")
print ("two")
endif
print ("three")
It still compiles, it still runs, and still shows the correct "three" as
output. And the discrepancy can be caught by extra tools (that you say
ought to be used), or it is obvious visually anyway that the "two" line
belongs with the "one" line not the "three" line.
Yes, delimiters can be placed wrongly, but that is a harder error to
make just by pressing one key (deleting a tab, or pressing Tab).
(Someone is now going to tell me that it is possible to declare:
endif = 0
in Python, and use 'endif' at the end of a block just like my example.
Now any adjacent line one tab out of place will be equally obvious.
However, no one does that! The language needs to require it and enforce it.)
but as it's normally used,
many errors are not detected until execution.
Plenty of editors can catch those even before you run the code.
Extra tools...
(But how would it catch assigning to a wrongly spelled attribute?)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On Tue, 24 Jan 2017 08:55 am, BartC wrote: > On 23/01/2017 17:34, Chris Angelico wrote: >> On Tue, Jan 24, 2017 at 4:24 AM, wrote: >>> The article is here http://lenkaspace.net/index.php/blog/show/111 >> >> I would respond point-by-point if I thought the author had a clue. > > I thought points 1 to 4 were valid, in that the assertions were true. Assertions can be true and still nonsense criticisms. "Oh my gawd, this car goes forward AND backwards!!! What a pile of guano!" What he's describing as flaws in language are seen by many as strengths of the language. Not only can Python go forward and backward, it can turn around corners as well! The author seems to want a B&D language which will force him to do The Right Thing™ whether you want to or not. He seems to care about a very narrow definition of correctness, and doesn't mind how many weeks or months it takes him to write the code, or for that matter, how many years it takes him to learn how to write the code in one of his preferred languages: "...it takes years to build up a sense of what is good and what is bad coding practise" The reason why Python has become the #1 language for scientific computing is that for most such programmings, the extra level of safety you (allegedly) get from heavyweight C++ and Java style coding frameworks is unjustified. You're not building a nuclear reactor. With Python, you can get reliable *enough* code quickly, rather than bulletproof code that takes you forever. Or I should say, *allegedly* bulletproof. There's no actual reliable, objective evidence that coding in Java or C++ leads to actually more reliable code, rather than just the false sense of security that because it was *really really hard* to get the compiler to accept your code, it must have been protecting you from all sorts of bad things. Maybe it was, maybe it wasn't. > Point 5 (memory leaks) I haven't experienced. I suspect he's using memory leak in the sense, if you hold onto data forever, the memory used by that data will never be available for re-use. Reading his post, I get the impression he's the sort of programmer who believes in never, ever, ever, ever re-using a variable, so he might do something like: raw_data = collect_raw_data() # generates 10GB of data data_after_step_one = massage(raw_data) data_after_step_two = process(data_after_step_one) ... sorted_data = sorted(data_after_step_ten) and then wonders why he's running out of memory. "That's a memory leak!" But perhaps not. Maybe he's just using a lot of badly written C extensions that do leak memory. Or maybe he's one of the unlucky few who have stumbled across genuine memory leaks in the interpreter, but hasn't bothered to report it as a bug or upgrade to a version where it is fixed. Or maybe he's just mistaken. Or lying. > Point 6 (libraries depending on libraries...) is probably true in other > languages too. "I must have installed at least 30 libraries" Really? 30? As many as that? You poor thing. > Point 7 (Python claiming to be general purpose) I don't have an opinion > about. Python is an object-oriented language which encourages multi-paradigm coding styles: OOP, functional and even procedural. The underlying data model is based on objects, but that doesn't imply that you must or even should write all your code in an OO style. I suspect this guy is just a Java or C++ bigot. I have nothing against those who like to program in Java or C++, that's cool. I have my opinion on the languages themselves, but that's often a matter of personal taste. But when somebody says: "For example, encapsulation, one of the basic principles in OO is non-existant in Python." as he does, that's a form of the "no true Scotsman" fallacy. He is asserting that *his* (probably taken from Java?) definition of encapsulation is the only one. And that's why I call him a bigot. In a figurative sense -- the author might be the sweetest, most open and unprejudiced guy in the world when it comes to skin colour or religion for all I know. https://en.wikipedia.org/wiki/Object-oriented_programming#Encapsulation -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On Tue, Jan 24, 2017 at 12:47 PM, BartC wrote:
> On 24/01/2017 00:56, Chris Angelico wrote:
>>
>> On Tue, Jan 24, 2017 at 11:44 AM, BartC wrote:
>
>
>>> With C++ or Java, it's possible to tell the indentation is wrong (because
>>> of
>>> the extra redundancy of having the indentation /and/ block delimiters).
>>> That's a bit harder in Python making source more fragile.
>>
>>
>> With C++ or Java, it's possible to tell that the braces are misplaced
>> (because of the extra redundancy). When that happens, the compiler
>> won't tell you; it'll just silently do the wrong thing. In Python,
>> that can't happen. Python is therefore more robust.
>>
>> What's to say which is correct?
>
> Take the same code with block
> delimiters, and take out that same indent:
>
> if 0 then
> print ("one")
> print ("two")
> endif
> print ("three")
>
> It still compiles, it still runs, and still shows the correct "three" as
> output.
My point is that you *assume* that showing just "three" is the correct
behaviour. Why? Why do you automatically assume that the indentation
is wrong and the endif is correct? All you have is that the two
disagree.
That's the sort of (presumably unintentional) bias that comes from
your particular history of programming languages. Some languages teach
you that "foo" and "Foo" are the same name. Others teach you that the
integer 1 and the string "1" aren't materially different. Still others
leave you believing that bytes and characters are perfectly
equivalent. All those assumptions are proven wrong when you switch to
a language that isn't like that, and indentation is the same.
So what's to say which is more important? Surely it's nothing more
than your preconceived ideas, and could easily be different if you had
different experiences?
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On Tue, Jan 24, 2017 at 12:55 PM, Steve D'Aprano wrote: > Reading his post, I get the impression he's the sort of programmer who > believes in never, ever, ever, ever re-using a variable, so he might do > something like: > > raw_data = collect_raw_data() # generates 10GB of data > data_after_step_one = massage(raw_data) > data_after_step_two = process(data_after_step_one) > ... > sorted_data = sorted(data_after_step_ten) > > and then wonders why he's running out of memory. "That's a memory leak!" How is that any different in any other language? I don't understand how even this is a criticism of Python. If you were working in Java, say, you'd have basically the same result - keep all the stuff, keep all the memory usage. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On Tuesday 24 January 2017 13:38, Chris Angelico wrote:
> On Tue, Jan 24, 2017 at 12:47 PM, BartC wrote:
>> Take the same code with block
>> delimiters, and take out that same indent:
>>
>> if 0 then
>> print ("one")
>> print ("two")
>> endif
>> print ("three")
>>
>> It still compiles, it still runs, and still shows the correct "three" as
>> output.
>
> My point is that you *assume* that showing just "three" is the correct
> behaviour. Why? Why do you automatically assume that the indentation
> is wrong and the endif is correct? All you have is that the two
> disagree.
It's Bart's special language, so the correct behaviour is whatever he says it
is :-)
But more seriously, it's easy to typo an extra indent. It's harder to typo
"endif" when you actually meant to type, oh, "ending = 1 if condition else 3",
say. So faced with ambiguity, and the insistence that the right way to break
ambiguity is to guess ("Do What I Mean, dammit!!!") the most likely guess is
that the indentation is wrong.
But not guaranteed. That's the thing about being ambiguous -- there is a chance
that the indentation is correct.
This *especially* applies to languages like C, when open/close delimiters
optional if the block is only a single statement, and where the delimiters are
only a single character.
And sure enough, C is prone to indent/brace mismatch errors.
When I design my killer language, it won't fail when there's a mismatch between
indentation and open/close delimiters. Nor will it just give priority to one or
the other. Instead, it will learn from your errors and typos in order to
determine which you are statistically more likely to want, and silently compile
the code that way. But without changing the source code, of course.
--
Steven
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." - Jon Ronson
--
https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On Tuesday 24 January 2017 13:41, Chris Angelico wrote: > On Tue, Jan 24, 2017 at 12:55 PM, Steve D'Aprano > wrote: >> Reading his post, I get the impression he's the sort of programmer who >> believes in never, ever, ever, ever re-using a variable, so he might do >> something like: >> >> raw_data = collect_raw_data() # generates 10GB of data >> data_after_step_one = massage(raw_data) >> data_after_step_two = process(data_after_step_one) >> ... >> sorted_data = sorted(data_after_step_ten) >> >> and then wonders why he's running out of memory. "That's a memory leak!" > > How is that any different in any other language? I don't understand > how even this is a criticism of Python. If you were working in Java, > say, you'd have basically the same result - keep all the stuff, keep > all the memory usage. Keep in mind that I'm only *guessing* from the impression that the author gives. I don't *know* that is what he's doing. He makes all these claims about Python, but doesn't show his code, so the best we can do is try to predict what could plausibly explain the observation. -- Steven "Ever since I learned about confirmation bias, I've been seeing it everywhere." - Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
Chris Angelico wrote: On Tue, Jan 24, 2017 at 11:55 AM, Dennis Lee Bieber wrote: On Mon, 23 Jan 2017 22:55:19 +, mm0fmf declaimed the following: 50lbs of coffee beans made into espresso and 22lbs of chocolate to eat with all those tiny cups. How about just 75lbs of chocolate covered espresso beans Can you fire them out of a machine gun? And if you can, should you use a Bren or a Spandau? (Sorry, I've been watching too many lindybeige videos about machine guns recently. Just throw a pommel at me.) -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On Tue, Jan 24, 2017 at 3:22 PM, Steven D'Aprano
wrote:
> But more seriously, it's easy to typo an extra indent. It's harder to typo
> "endif" when you actually meant to type, oh, "ending = 1 if condition else 3",
> say. So faced with ambiguity, and the insistence that the right way to break
> ambiguity is to guess ("Do What I Mean, dammit!!!") the most likely guess is
> that the indentation is wrong.
>
> But not guaranteed. That's the thing about being ambiguous -- there is a
> chance
> that the indentation is correct.
Indeed. I teach JavaScript as well as Python, and I've seen some
pretty horrendous indentation flaws (examples available if people ask
privately, but I will anonymize them because I'm not here to shame
students) - but there have been nearly as many cases where the
indentation's fine and the bracket nesting isn't. I probably sound
like a broken record [1] with the number of times I've said "check
your indentation", as a hint to where the missed-out close brace or
parenthesis is. True, with "endif" it's a bit harder to typo, but it's
still just as easy to make a copy-and-paste error and end up with code
like this:
if condition:
statement
endif
statement
endif
What's this code meant to do? Can't know.
Remember: If you have only one clock, it might be right and it might
be wrong, but it's consistent. If you have two clocks and they
disagree, you have no clue what the time is.
ChrisA
[1] Wonder how many of today's generation of programmers have actually
heard a record skip...
--
https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On Tuesday 24 January 2017 15:41, Chris Angelico wrote:
> Remember: If you have only one clock, it might be right and it might
> be wrong, but it's consistent. If you have two clocks and they
> disagree, you have no clue what the time is.
During the golden age of sail, there was a saying, never go to sea with two
chronometers. Take one, or three, but never two.
Obviously the lesson here is that programming languages should have *three*
ways of setting out the structure:
if condition:
{
BEGIN
code goes here
}
END
> [1] Wonder how many of today's generation of programmers have actually
> heard a record skip...
Haven't you heard? Vinyl is making a comeback. Seriously.
--
Steven
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." - Jon Ronson
--
https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On Tue, Jan 24, 2017 at 4:00 PM, Steven D'Aprano
wrote:
> On Tuesday 24 January 2017 15:41, Chris Angelico wrote:
>
>> Remember: If you have only one clock, it might be right and it might
>> be wrong, but it's consistent. If you have two clocks and they
>> disagree, you have no clue what the time is.
>
> During the golden age of sail, there was a saying, never go to sea with two
> chronometers. Take one, or three, but never two.
>
> Obviously the lesson here is that programming languages should have *three*
> ways of setting out the structure:
>
> if condition:
> {
> BEGIN
> code goes here
> }
> END
>
No no no. You have two orthogonal styles (indentation and tokens), but
then you added another of the same style (another pair of tokens). You
need a third orthogonal style. I suggest that each nesting level be
heralded by an increase in indentation, an open brace, and a new text
colour.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
in 770207 20170124 005601 Chris Angelico wrote: >REXX has even less structure than Python - it doesn't even have >functions, just labels, so you can actually have two functions that >share a common tail. And yes, you can abuse that horrendously to >create unreadable code. Is REXX a bad language because of that? No. >You can use structure badly, and you can use freedom badly. Of course Rexx has functions! -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On Tue, Jan 24, 2017 at 6:00 PM, Bob Martin wrote: > in 770207 20170124 005601 Chris Angelico wrote: > >>REXX has even less structure than Python - it doesn't even have >>functions, just labels, so you can actually have two functions that >>share a common tail. And yes, you can abuse that horrendously to >>create unreadable code. Is REXX a bad language because of that? No. >>You can use structure badly, and you can use freedom badly. > > Of course Rexx has functions! Built-ins, yes, but when you define your own, it's by giving a label. It isn't a function until it's called as a function. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
PhotoImage.paste
I'm trying to build a tkinter GUI with python 3.5, and would like to interactively adjust the color palette for an image by moving the mouse in the canvas using PIL. In pseudo-code, I have something like palette=color_map(x,y) # x,y are scalars indicating the position of the mouse in the Canvas image.putpalette(palette) photo.paste(image) This works just fine, but is very slow. The photo.paste(image) step takes about 0.15 s (using an image that is 4k x 4k). I read the manual on effbot, and they caution that the paste method would be slow if the image is display --- and I'm guessing that's what I'm doing. So my question is, what alternatives do I have to speed that step up. Thank you for any thoughts you might have... -Russell -- https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
Am 23.01.17 um 18:24 schrieb breamore...@gmail.com: The article is here http://lenkaspace.net/index.php/blog/show/111 I don't agree with it (unsurprisingly), even though Python is not my favourite language in itself, but a viable compromise for many circumstances. Below is a point-by-point reply. (BTW, Lenka Pitonakova is a lady of Slova origin, so we should refer to her as "she") 1. Having the code in shoehorned into a given structure is no guarantee for clean code. Look at messy Java inheritance diagrams with hundreds of Factory objects all creating themselves around the code that solves the real problem 2. It is true that the prototype of a function can be more descriptive, if it includes type information (such as "list", "dict" etc.). See https://www.python.org/dev/peps/pep-0484/ The documentation is needed in any case to understand, what the function does. Mandatory types do not prevent bad naming of the arguments. 3. Significant indentation has been discussed over and over, with no clear result. Humans need indentation to identify structure in a large chunk of code. Brace language programmers use auto-indenters to do that, Python uses the layout to deduce the code blocks. Both can fail; most notably, missing braces in if clauses lead to several security bugs in the past, while white space can be messed up more easily. So that's a standoff. 4. It's true that a strict compiler can find errors earlier. Most notably, Haskell detects many errors during compile time. Linters exist for that purpose in interpreted languages. Still no compiler can actually catch semantic errors, which means that automated tests are needed anyway. 5. This is wrong. Python does have a garbage collector, but it uses reference counting (CPython) - so in simple cases you know exactly how to release the memory held by big objects. Unless you use a flawed library. 6. There are even more bad libraries for C and Java. Writing interfaces to libraries that do not fit together is actually a much greater pain in these languages. 7. This is actually the same argument as 6. Bad programmers wrote some code, which you want to use. That is independent of the language, maybe in a more strict language the author wouldn't bother to give you the code at all! Scientific software was always horrible, previously people used impenetrable FORTRAN 77, thankfully they use Python now. Lack of encapsulation is a featurenot a bug. Christian -- https://mail.python.org/mailman/listinfo/python-list
