Re: Python 3.10 Fizzbuzz
On Tue, Feb 28, 2023 at 04:05:19PM -0500, avi.e.gr...@gmail.com wrote: Is it rude to name something "black" to make it hard for some of us to remind them of the rules or claim that our personal style is so often the opposite that it should be called "white" or at least shade of gray? The usual kidding aside, I have no idea what it was called black but in all seriousness this is not a black and white issue. Opinions may differ when a language provides many valid options on how to write code. If someone wants to standardize and impose some decisions, fine. But other may choose their own variant and take their chances. https://pypi.org/project/grey/ https://pypi.org/project/white/ https://pypi.org/project/blue/ https://pypi.org/project/oitnb/ :o It amuses me that opinionated formatter, with very little configurability by design, in the face of differing opinions just results in forks or wrappers that modify the behaviours that might otherwise have been configuration options. Simon -- https://mail.python.org/mailman/listinfo/python-list
Re: Baffled by readline module
On Fri, Mar 10, 2023 at 06:37:56AM -0800, Grant Edwards wrote: On 2023-03-10, Weatherby,Gerard wrote: I'll have to remember that one. It doesn't really fit my current use case, but there are others where it would work nicely. However, cmd.Cmd does not provide command recall and editing. According to the page above, that's provided by the readline module There is also prompt_toolkit[1] for even more fancy command‐line handling. The documentation even states it “can be a very advanced pure Python replacement for GNU readline, but it can also be used for building full screen applications.” (It doesn’t depend on readline or libedit.) It’s used by IPython for its history, editing, and completion features. If cmd with readline is overkill for your use case then this is even more so, but I thought it worth a mention. Simon -- https://mail.python.org/mailman/listinfo/python-list
Re: Distributing program for Linux
On Tue, Mar 14, 2023 at 04:43:14PM +0100, Loris Bennett wrote: If I write a system program which has Python >= 3.y as a dependency, what are the options for someone whose Linux distribution provides Python 3.x, where x < y? The docs suggest creating your own package or building and installing from source: https://docs.python.org/3/using/unix.html To install from source, use ‘make altinstall’ (instead of ‘make install’) to avoid shadowing your system Python version. The alternative interpreter should be qualified with . version, e.g. python3.11 Depending on the package manager used by the distribution, ‘checkinstall’ could be used to build from source and install as a package without rolling your own. https://wiki.debian.org/CheckInstall On Ubuntu check out the deadsnakes PPA: https://launchpad.net/~deadsnakes/+archive/ubuntu/ppa Or use python-build from pyenv to install to a custom location: https://github.com/pyenv/pyenv/wiki/Common-build-problems#installing-a-system-wide-python Simon -- https://mail.python.org/mailman/listinfo/python-list
Re: Implementing a plug-in mechanism
On Thu, Mar 16, 2023 at 07:45:18AM +1300, dn via Python-list wrote: There is a PyPi library called pluggy (not used it). I've used informal approaches using an ABC as a framework/reminder (see @George's response). typing.Protocol is also useful here as the plugin interface can be defined separately not requiring inheriting from an ABC. Simon -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall -- https://mail.python.org/mailman/listinfo/python-list
Re: Friday finking: IDE 'macro expansions'
On Fri, Mar 17, 2023 at 11:55:38AM +1300, dn via Python-list wrote: Do you make use of your IDE's expansionist tendencies, and if-so, which ones? Unix (well, GNU/Linux) is my IDE ;) Simon -- https://mail.python.org/mailman/listinfo/python-list
Re: Friday finking: IDE 'macro expansions'
On Fri, Mar 17, 2023 at 02:05:50PM +0100, Roel Schroeven wrote: Even better than simply highlighting is (IMO) a thing called "Rainbow Braces" or "Bracket Pair Colorization" I recently learned about: both braces of a matching pair get the same color, while other pairs get other colors. I have to say I like it quite a lot. It's in VS Code these days; possible there are implementations or extensions for other editors and IDEs as well. VS Code also supports ‘semantic highlighting’: Instead of simply highlighting syntax, highlight the same identifiers in the same colours, with the aim of helping you see them through the flow of the code. Simon -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall -- https://mail.python.org/mailman/listinfo/python-list
ipaddress (was: Re: for a 'good python')
On Thu, Apr 13, 2023 at 04:00:59PM +0100, Barry wrote: Ipaddress was developed outside of the std lib and later added i recall. I used it prior to it being in the standard library: https://pypi.org/project/ipaddr/ Simon -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall -- https://mail.python.org/mailman/listinfo/python-list
Re: Continuing indentation
On 4 March 2016 23:31:43 GMT+00:00, Erik wrote: >On 04/03/16 21:14, sohcahto...@gmail.com wrote: >> You guys are spending way too much time fighting over something that >is clearly subjective. Nobody is "correct" here. There's no right and >wrong, just simple preference. > >I will take that as a vote +1 that PEP8 is wrong (*). ;) > >E. > >(*) PEP8 defines a specific format and you are stating that no specific > >format can be considered correct. Style guides are always going to be considered incorrect by some people, but they should aim more for consistency (the hobgoblin that may be), which is what makes code easier to grok. Stop arguing, start thinking about others who will have to read your code. What is better in your subjective opinion means very little. Having commonly understandable style is what matters, and what style guides help (including PEP8). Simon -- Sent from Kaiten Mail. Please excuse my brevity. -- https://mail.python.org/mailman/listinfo/python-list
Re: numpy arrays
On 23 March 2016 10:06:56 GMT+00:00, Heli wrote: >Hi, > >I have a 2D numpy array like this: > >[[1,2,3,4], > [1,2,3,4], > [1,2,3,4] > [1,2,3,4]] > >Is there any fast way to convert this array to > >[[1,1,1,1], > [2,2,2,2] > [3,3,3,3] > [4,4,4,4]] Use the transpose() method: http://docs.scipy.org/doc/numpy-1.10.0/reference/generated/numpy.ndarray.transpose.html Simon -- Sent from Kaiten Mail. Please excuse my brevity. -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs for indentation & Spaces for alignment in Python 3?
On 6 December 2014 03:04:48 GMT+00:00, Michael Torrie wrote: >On 12/05/2014 07:31 PM, Ned Batchelder wrote: >> This is a perfect example! The code (with tabs as >--- and leading >> spaces as .) is: >> >> >---if (!list_empty(pending)) >> >--->---ret = list_first_entry(pending, struct async_entry, >> >--->--->--->---...domain_list)->cookie; >> >> Now, display it in your editor with tabs set to four spaces: >> >> >---if (!list_empty(pending)) >> >--->---ret = list_first_entry(pending, struct async_entry, >> >--->--->--->---...domain_list)->cookie; > >However, a conscientious programmer knows that tabs could be >arbitrarily >sized, so he would never do that. Instead he would do: > > >---if (!list_empty(pending)) > >--->---ret = list_first_entry(pending, struct async_entry, > >--->---...domain_list)->cookie; > >Which under the heretical tab size of 4: > >---if (!list_empty(pending)) > >--->---ret = list_first_entry(pending, struct async_entry, > >--->---...domain_list)->cookie; Not every programmer is as conscientious in the first of place, and that's far easier to get wrong than just agreeing to stick to one thing. This is why (often more rigid) style guides (or rather policies) exist. Maybe we should sack such programmers regardless of their other abilities instead of forcing all, including the conscientious, programmers to adhere to strict style policies? While I like the idea, I think that a slap on the wrist and a bit of re-indentation/re-alignment is all that is necessary (although I have worked with people who consider pure style changes to be a sin too). Simon -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On 25 February 2015 21:24:37 GMT+00:00, Chris Angelico wrote: >On Thu, Feb 26, 2015 at 7:45 AM, Mark Lawrence > wrote: >> http://www.slideshare.net/pydanny/python-worst-practices >> >> Any that should be added to this list? Any that be removed as not >that bad? > >Remove the complaint about id. It's an extremely useful variable name, >and you hardly ever need the function. You can add one character and avoid the conflict with "id_" and not require anyone else maintaining the code to think about it. As rare as the conflict is, I think the ease of avoiding it makes the extra character a practical defensive technique. I agree it is not a worst case. Simon -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On 26 February 2015 00:11:24 GMT+00:00, Ben Finney wrote: >> Yes, but my point is: You shouldn't need to rebind those names (or >> have names "true" and "false" for 0 and 1). > >That's not what you asked, though. You asked “When would 0 mean true >and >1 mean false?” My answer: in all Unix shell contexts. > >> Instead, use "success" and "failure". > >You'd better borrow the time machine and tell the creators of Unix. The >meme is already established for decades now. 0 = success and non-zero = failure is the meme established, rather than 0 = true, non-zero = false. It's not just used by UNIX, and is not necessarily defined by the shell either (bash was mentioned elsewhere in the thread). There is probably a system that pre-dates UNIX that I uses/used this too, but I don't know. C stdlib defines EXIT_SUCCESS = 0, yet C99 stdbool.h defines false = 0. That shells handle 0 as true and non-zero as false probably stems from this (or similar in older languages). The " true" command is defined to have an exit status of 0, and "false" an exit status of 1. The value is better thought of an error level, where 0 is no error and non-zero is some error. The AmigaOS shell conventionally takes this further with higher values indicating more critical errors, there's even a "failat N" command that means exit the script if the error level is higher than N. None of the above is a good reason to use error *or* success return values in Python--use exceptions!--but may be encountered when running other processes. Simon -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On 26 February 2015 21:23:34 GMT+00:00, Ben Finney wrote: >Simon Ward writes: >> 0 = success and non-zero = failure is the meme established, rather >> than 0 = true, non-zero = false. > >That is not the case: the commands ‘true’ (returns value 0) and ‘false’ >(returns value 1) are long established in Unix. So that *is* part of >the >meme I'm describing. I mentioned the true and false. OK, so it's a meme, but it's based on a false (pun intended) understanding of exit status codes. That success evaluates to true and failure evaluates to false does not mean the values of truth and falseness are inverted. No programming language other than that provided by system shells I have used evaluates 0 to true. The shell case is unique because it typically runs processes and has to deal with exit status codes. It feels quite natural to me that, if COMMAND completes successfully (exit code 0) then writing "if COMMAND ; then : true bit ; else : false bit ; fi" should execute the true bit, but that doesn't mean all boolean logic is inverted. true is define to return 0, or no error. false is defined to return 1, or error. They are just commands though, and the exit codes are still exit codes, not boolean values. >> None of the above is a good reason to use error *or* success return >> values in Python--use exceptions!--but may be encountered when >running >> other processes. > >Right. But likewise, don't deny that “true == 0” and “false == >non-zero” >has a wide acceptance in the programming community too. I can't deny that, but I can state what things really mean and point out why everybody is doing it wrong. Simon -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On 27 February 2015 20:06:25 GMT+00:00, I wrote: >I mentioned the true and false. OK, so it's a meme, but it's based on a >false (pun intended) understanding of exit status codes. That success >evaluates to true and failure evaluates to false does not mean the >values of truth and falseness are inverted. No programming language >other than that provided by system shells I have used evaluates 0 to >true. I hope the following examples from bash illustrate this: $ (( 0 )) && echo success $ (( 1 )) && echo success success $ (( 0 )) ; echo $? 1 $ (( 1 )) ; echo $? 0 Simon -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On 27 February 2015 20:06:25 GMT+00:00, Simon Ward wrote: > >I mentioned the true and false. OK, so it's a meme, but it's based on a >false (pun intended) understanding of exit status codes. That success >evaluates to true and failure evaluates to false does not mean the >values of truth and falseness are inverted. No programming language >other than that provided by system shells I have used evaluates 0 to >true. > >The shell case is unique because it typically runs processes and has to >deal with exit status codes. It feels quite natural to me that, if >COMMAND completes successfully (exit code 0) then writing "if COMMAND ; >then : true bit ; else : false bit ; fi" should execute the true bit, >but that doesn't mean all boolean logic is inverted. I pointed my partner at this thread, and she said we were using too many of the same words to mean different things. To quote: "you're both using yes or no terms to answer a question that doesn't necessarily need a "yes" or "no" answer. It's still a point of discussion (existentialism next!) but the basic idea seems to be that once the exit code is understood as an error value it is not necessarily true or false. This is what I tried to say originally so I don't disagree. My partner is not a software developer by profession, she deals with food and nutrition and bakes nice cakes. I have encouraged her to learn Python to help with some of her work, which involves calculation of nutritional values and a lot of statistics. Programming idioms should not be lost on her, but she can, and does, point out the bits she is unfamiliar with our has trouble understanding. Simon -- https://mail.python.org/mailman/listinfo/python-list
Re: Query on Python 3.2 and supported OpenSSL Versions
On Mon, May 25, 2015 at 09:33:06AM +, Donal Duane wrote: > > Hi Python Users, > > I was hoping you might be able to assist me with a query: > > 2 Questions: > > > 1. Could Python 3.2, when compiled against OpenSSL 1.0.0j, be > affected by the poodle bug? > https://www.openssl.org/~bodo/ssl-poodle.pdf Yes, POODLE is two things: 1. Due to client‐side fallback mechanisms outside of SSL and TLS, it is possible to force a client to connect with a different version of the protocol, i.e. a protocol downgrade. 2. Due to the way padding is implemented in SSL 3.0 there is a padding oracle attack on CBC mode ciphers. This affects all implementations of SSL 3.0, and some of TLS 1.0 (but not OpenSSL). All versions of OpenSSL (that support SSL 3.0) are affected by (2) because it is inherent in the protocol. The fix is not to allow SSL, and enable the latest versions of TLS. Later versions of OpenSSL (0.9.8zc, 1.0.0o, 1.0.1j) added a workaround, the TLS_FALLBACK_SCSV mechanism, which allows clients to specify when they have falled back to an earlier version, preventing downgrade attacks (1). It only works if the both the client and server support the mechanism, and if SSL 3.0 is used it is still affected by the padding oracle attack (2). > 2. If yes - are the following OpenSSL versions approved for use > with Python 3.2: I can’t answer for approved but I have builds of Python than use OpenSSL 0.9.8 and 1.0.1 and it should build against any version in these branches. I also have pyOpenSSL built against these branches. Simon -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall -- https://mail.python.org/mailman/listinfo/python-list
Re: Bug!
On 23 August 2015 00:06:44 BST, Chris Angelico wrote: >Precisely. Every time you support multiple versions of some >dependency, you have to test your code on all of them, and in the >common case (new features added in newer versions), you have to target >the oldest and weakest version. Just don't add features to older versions. They're in maintenance or bugfix mode. > When you're writing a Python program >that has to run on CPython back as far as 2.4, there's a lot you can't >do... Just deprecate then drop the stuff you don't want to support any more. This is part of the standard software lifecyle to me. If you care about your users that might not be ready to upgrade provide security fixes for the older versions. If you don't care, well I wouldn't want to use your software in production. > dropping support for everything pre-2.7 lets you improve your >code significantly. Does dropping support for Python 2.4 consist of >"undercutting RHEL users"? Nope. It's that same pragmatism - I want a >cleaner codebase. RHEL 4 might still be supported (is it? haven't paid attention) but there should be no obligation to provide new features. Have a development branch or mainline, that doesn't stop you from having "stable" rele > >CPython 3.4 will continue to run on Windows XP. If you're still using >an old Windows, you just have to keep using an old Python too. >Eventually Python 3.4 will be out of support, but at that point, it's >no different from the OS anyway. There's nothing stopping you from >using an ancient OS, an ancient CPython, and an ancient Python >application, if that's what it requires... I'm not sure what OS people >are running Python 1.5 on, but if anyone complains that it doesn't >install properly on Windows 10, I rather doubt that python.org will >release a patch :) > >ChrisA -- Sent from Kaiten Mail. Please excuse my brevity. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python's re module and genealogy problem
On 11 June 2014 13:23:14 BST, BrJohan wrote: >For some genealogical purposes I consider using Python's re module. > >Rather many names can be spelled in a number of similar ways, and in >order to match names even if they are spelled differently, I will build > >regular expressions, each of which is supposed to match a number of >similar names. As has been mentioned, you probably want to look at fuzzy matching algorithms rather than aiming at regular expressions, although a quick search suggests there has been some work on fuzzy matching with regular expressions[1]. >Now, my problem: Is there a way to decide whether any two - or more - >of >those regular expressions will match the same string? If your regexes are truly regular expressions (see [2]*) then they represent regular languages[3], which are really sets. The intersection of these, is another regular language. If you test the string against this it will also match both original languages. (*this only mentions back references, but I think the look-ahead/behind assertions are also non-regular) [1]: http://laurikari.net/tre/about/ [2]: https://en.wikipedia.org/wiki/Regular_expression#Patterns_for_non-regular_languages [3]: https://en.wikipedia.org/wiki/Regular_language Simon -- Sent from Kaiten Mail. Please excuse my brevity. -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On 3 July 2014 18:31:04 BST, Tobiah wrote: >Coworker takes PEP8 as gospel and uses 4 spaces >to indent. I prefer tabs. Boss want's us to >unify. This isn't worth arguing about. Pick a convention, it's probably going to be a compromise, get used to it. PEP8 is as good a base as any, and is (mostly) directly supported by various syntax checking tools such as flake8 and pylama (which I think both use the pep8 tool underneath), and the modes of various editors. Any good editor will make indentation painless, whichever method you settle on. >Anyway, I gave up the 80 char line length long >ago, having little feeling for some dolt on >a Weiss terminal that for some reason needs to >edit my code. Putting the code factoring considerations aside, because others have already mentioned them and I'm sure others will, there are some other practical reasons for limiting line width: I often use multiple editors side-by-side or in split window mode. If I'm limited to one screen I'll probably also have documentation open on that screen. Having to side scroll, or have a single editor take up most of the width of the display forcing switching between windows, seems to me to be more harmful than good for productivity. There is plenty of research on the readability of prose, less so on code, but some of the considerations apply to code too. I'll pick out three of them. The first probably applies less to code (because code is generally line-based and the line widths vary; it's not just a big wall of text): people tend to find it harder to track from one line to the next with longer lines of text. The second has to do with focus: as the reader continues along a line of text their focus dwindles, it seems that starting a new line renews focus. Thirdly, it may seem unintuitive given that we appear to have more capacity for horizontal movement of the eyes, but excessively long lines can cause more work for them potentially inducing eyestrain. We focus near the centre. Our peripheral vision either side is less discerning of details and more on movement (such as an attacker). We must move our eyes to continue reading long lines, and possibly even move our heads. This is a problem for vertical movement too, and happens if lines are too short. (I have no idea how this affects readers of vertical scripts.) > I feel rather the same about the >spaces and tabs, given that most people seem to >be using editors these days that are configurable >to show tabs a four characters. Conversely, those same editors can probably automatically indent and unindent a configurable amount of spaces. If you don't use such an editor, and you really can't tolerate the different style, you can use another tool to reindent your code. Simon -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On 4 July 2014 15:54:50 BST, Marko Rauhamaa wrote: >Even if we accepted that to be bad style, there's nothing on the screen >that would warn against such usage: the lines seemingly align >perfectly, >and the code runs as expected. If using vim, set list and listchars, you get to highlight tabs and trailing spaces. Simon -- https://mail.python.org/mailman/listinfo/python-list
Re: Global indent
On 22 August 2014 19:44:39 BST, "Neil D. Cerutti" wrote: >This sort of simple task [indenting blocks of text] is why fancy text editors >were invented. > >I use and recommend gvim (press > in select mode using the standard >python plugin), but there are plenty of options out there. Even without the Python add-on this should work. It shifts the text based on the 'shiftwidth' setting. I vaguely remember using some other editors (one or more of Nedit, Gedit, Kate, Notepad++, Eclipse) that use, or can be configured to use, the tab key to indent selected text rather than replacing it with a tab character. Shift-tab probably out dented too. Simon -- Sent from Kaiten Mail. Please excuse my brevity. -- https://mail.python.org/mailman/listinfo/python-list
Re: Teaching Python
On 29 September 2014 14:18:31 BST, Gabor Urban wrote: >my 11 years old son and his classmate told me, that they would like to >learn Python. They did some programming in Logo and turtle graphics, >bat >not too much. > >Doesn anybody has an idea how to start? "How to Think Like a Computer Scientist - Learning with Python 3": http://openbookproject.net/thinkcs/python/english3e/ If you're after a printed book, the original (I believe) author's current version is here: http://www.greenteapress.com/thinkpython/thinkpython.html Simon -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] spelling colour / color was Re: Toggle
On 11 October 2014 10:37:51 BST, Christian Gollwitzer wrote: >I tend to agree that British English is the "correct" version for me, >since I'm European, though not British. > >The usage of -ise in verbs, however, is a newer attempt to set the >British English apart from the American: > > http://blog.oxforddictionaries.com/2011/03/ize-or-ise/ and > http://www.oxforddictionaries.com/words/ize-ise-or-yse > >Being a non-native English speaker/writer, I myself stick to the >recommendations of the Oxford dictionary. Oxford Dictionaries online is not just British English, it derives common usage from a corpus of English used around the world: http://www.oxforddictionaries.com/words/what-are-the-main-differences-between-the-oed-and-odo http://www.oxforddictionaries.com/words/the-oxford-english-corpus Simon -- https://mail.python.org/mailman/listinfo/python-list
RE: Python application launcher (for Python code)
On 20 February 2017 22:56:31 GMT+00:00, Deborah Swanson wrote: > Basically, I now have quite a few Python programs I use frequently, > and > as time goes on my collection and uses of it will grow. Right now I > just > want a way to select which one I'd like to run and run it A Python application should be treated as any other application and be runnable by whatever mechanisms the operating system provides, there's your application launcher. The main niggle is that a Python file is not a "native" executable, so the OS or shell running under the OS needs to be told to use the Python interpreter to run it. For many shells on Linux (or the kernel itself) this can be done with the "shebang" on the first line. For Windows you generally associate the Python file type with the Python interpreter (done when Python is installed), or create shortcuts specifying the Python interpreter as the executable (or make executable files using some other tool). >×I'd like it to be a standalone application and some sort of system of >categories > would be nice. The freedesktop.org menu specification[1] provides a common format for defining application menus including organisation such as categories and hierarchies. The Windows start menu can be arranged how you wish, but I'm not aware of an implementation of the menu specification on Windows. [1]: https://www.freedesktop.org/wiki/Specifications/menu-spec/ > I'm migrating tasks I've always done in Excel to Python, and I have a > sketchy idea of features I'd like to open Excel with, but I hate Excel > VBA so much that I haven't written an on_Open macro for Excel yet. > What > I'd like to open with is mostly a menu of macros I'd like to have > available for any code I'm running, possibly opening different > environments for different kinds of tasks, that sort of thing. I also > plan to use sqlite3 for permanent data storage, matplotlib for charts, > and tkinter for interfaces. That's all in the planning stages, but one > thing that seems like an obvious need is a way to keep related code > and > its associated data, charts, etc, easily accessible to each other, > like > they are when they're all bundled together in an Excel workbook. I > have > a few ideas about how to do that, but I'm also interested in what > other > people have done. Possibly what you actually want is a development environment. Mine is made up of a shell with convenience functions, a text editor and a few other independent things. Some prefer to use an IDE, such as IDLE[2], where this is all integrated into one convenient application. From some of what you said above I suggest taking a look at Jupyter Notebook[3] and/or the underlying iPython[4] shell. [2]: https://docs.python.org/3/library/idle.html [3]: http://jupyter.org/ [4]: https://ipython.org/ Simon -- Sent from Kaiten Mail. Please excuse my brevity. -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: Addition of a .= operator
On Wed, May 24, 2023 at 05:18:52PM +1200, dn via Python-list wrote:
Note that the line numbers correctly show the true cause of the
problem, despite both of them being ValueErrors. So if you have to
debug this sort of thing, make sure the key parts are on separate
lines (even if they're all one expression, as in this example), and
then the tracebacks should tell you what you need to know.
Yes, an excellent example to show newcomers to make use of 'the
information *provided*' - take a deep breath and read through it all,
picking-out the important information...
However, returning to "condense this into a single line", the
frequently-seen coding is (in my experience, at least):
quantity = float( input( "How many would you like? " ) )
which would not produce the helpful distinction between
line-numbers/function-calls which the above (better-formatted) code
does!
Old thread I know, but thought it was worth pointing out that Python 3.11
brought in fine-graned error locations in tracebacks[1]:
$ python3.10 asin.py
Enter a small number: 4
Traceback (most recent call last):
File "/home/p10365088/asin.py", line 3, in
print(math.asin(float(input("Enter a small number: "
ValueError: math domain error
$ python3.11 asin.py
Enter a small number: 4
Traceback (most recent call last):
File "/home/p10365088/asin.py", line 3, in
print(math.asin(float(input("Enter a small number: "
^
ValueError: math domain error
[1]: https://docs.python.org/3/whatsnew/3.11.html#whatsnew311-pep657
Regards,
Simon
--
A complex system that works is invariably found to have evolved from a
simple system that works.—John Gall
--
https://mail.python.org/mailman/listinfo/python-list
