[Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
On Sat, Jun 27, 2020 at 6:40 AM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Keara Berlin writes: > > I wouldn't object to > > When writing English, write clearly and understandably. Consider > your audience -- many readers of your comments in Python sources > will be non-native speakers. "The Elements of Style" by Strunk > and White provides a set of guidelines some consider useful in > writing clearly and understandably. Me neither, I think we can add some meaning to what "Strunk & White" means in the PEP without removing the reference. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/H2JCQFY7LINL4S4O5BJHJNO7QE777ZQQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
On Fri, Jun 26, 2020 at 9:43 PM Steven D'Aprano wrote: > I dislike Strunk and White, and don't follow it myself (except by > accident, as it were) but I've worked with neuro-atypical programmers > who found it really useful to have a common standard that they could > follow and reduce the uncertainty of what makes for good writing. > I agree. I would like to reinforce that many software engineers today are _not_ native English speakers but work with English codebases and write documentation in English. Any standard is better than just asking for "clear and easily understandable" and hoping that for some reason every person, no matter where they were born and how they learned English, will share your definition of "clear and easily understandable" by accident. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3MOO4LSWEAOAULDPN4LBHQWIHIRR7U5K/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Allow signal suppression
On Thu, Jun 25, 2020 at 5:09 PM Yonatan Zunger via Python-ideas < python-ideas@python.org> wrote: > Hey everyone, > > I've been developing code which (alas) needs to operate in a runtime > environment which is quite *enthusiastic* about sending SIGTERMs and the > like, and where there are critical short sections of code that, if > interrupted, are very hard to resume without some user-visible anomaly > happening. > I find, for reasons you have already mentioned, having a "suppress all signals" something _really_ strange in userland code. But maybe I just have never seen a case in which it makes sense. Are you sure that the problem isn't "a runtime environment which is quite enthusiastic about sending SIGTERMs"? ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KJUNFGDEEMNL6IOUAUTOOT6TISO3RMGI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Bringing the print statement back
If f and g are unary functions, f g 0 is evaluated as f(g(0))? Asking
because you didn't mention composition. That is, could we have `print
"hello", input "Name:"` instead of `print "hello", input("Name:")`?
Overall, I am against this because I like the "explicitness" of using
parenthesis for function calls, and have never found their presence to be
an issue. Additionally, I prefer when there is only one way of doing
something, even if I don't like the way itself, as that is one less thing
to think about.
The "the first argument cannot start with a parenthesis or bracket" part
(which is understandable) adds even more complexity to this.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/KJTYZU3ZRBJRNVOOFXXT3C2VUFMHXZPJ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: len(path) == len(str(path))
"So I implemented `PurePath.__len__` as `str(len(path))`." Sure you meant len(str(path)), right? "Serhiy and Remi objected, because it might not be obvious that the length of the path would be the length of string." I find this _really_ unintuitive. If anything, I would expect len(p) to be the "depth" of the path, which doesn't make a lot of sense if it is not an absolute path. It is a -1 from me because, besides what I outlined above, if you need the length of the string representation, len(str(p)) is quite short and obvious already. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/UU5I46IHXHNSQNCET6XPPPVZD5IN634D/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
> > I believe I speak for a significant majority of professional programmers > when I say that eye-candy like this adds no value to the language for me. > It gives me no new capabilities, I don't see it making me more productive, > and we have syntax that works quite well already. > This speaks for me. Not only such an addition requires substantial support, which it doesn't seem to be gathering, it requires some quantitative evidence that this is better than what we already have in some meaningful aspect. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IYT344CYIOOI7FJAOERTE5ID5EYEJFMY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
> > I would like to comment that the graphical presentation, at least in > IDEs/where the font can be controlled, can be achieved using fonts: > Precisely. Nicer than the arrow symbol, it would be to type "-" + ">" and get an arrow visually. The same can be done about getting >= as a single symbol and == and === and <=> as single symbols. It seems like a matter of code presentation, not code itself. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/EGNUQPQRONDFJ7SLCOP6CCMLTVH4OJYK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: IDEA: Allow override of all assignments of a built in type to be a different type
I've written my share of mathematical and physics software by now and arbitrary-precision rational numbers are hardly ever a good solution to problems you might be having. Paul Moore has mentioned how few keystrokes this syntax would actually save: add to this the fact that there are probably very few uses of arbitrary-precision rational numbers in real-world Python code and this will look a lot of added complexity for little benefit. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/M2ZNFJWAWYTNQV7XKM3BEQOK6PRU6TPE/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS
I disagree. Changing this in the PEP will make an absurd amount of code which is PEP-8 compliant no longer so. Also, the refactoring may not always be trivial as the lowercase names may already be in use. I'd suggest violating PEP-8 instead of trying to change it. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Using sha512 instead of md5 on python.org/downloads
If the discussion gets to which SHA-2 should be used, I would like to point out that SHA-512 is not only twice the width of SHA-256 but also faster to compute (anecdotally) on most 64-bit platforms. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Using sha512 instead of md5 on python.org/downloads
Would this change actually help people who need to use FIPS? Other than that this change would only decrease the already very small probability of a corrupted download hashing the same, which isn't a bad thing. If it could make some users' jobs easier, even if it by no means helps guaranteeing the authenticity of the downloaded file, it might be worth considering. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Should Python have user-defined constants?
This could also be useful if one eventually wanted to implement constant optimizations in the interpreter as it would be possible to detect constants when they are declared without any code analysis. This would be "constant" as in Java constants right? Referential constants, so that if an object were mutable you would still be able to change its internal state. -- Bernardo Sulzbach http://www.mafagafogigante.org/ mafagafogiga...@gmail.com ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Run length encoding
On 2017-06-11 00:13, David Mertz wrote: Bernardo Sulzbach posted a much prettier version than mine that is a bit shorter. But his is also somewhat slower (and I believe asymptotically so as the number of equal elements in subsequence goes up). He needs to sum up a bunch of 1's repeatedly rather than do the O(1) `len()` function. Constructing a list from an iterator of size N is in O(N). Summing N elements is in O(N). I don't think it is asymptotically slower, just slower because of implementation details. -- Bernardo Sulzbach http://www.mafagafogigante.org/ mafagafogiga...@gmail.com ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Run length encoding
On 2017-06-10 23:20, Neal Fultz wrote: Hello python-ideas, I am very new to this, but on a different forum and after a couple conversations, I really wished Python came with run-length encoding built-in; after all, it ships with zip, which is much more complicated :) The general idea is to be able to go back and forth between two representations of a sequence: |[1,1,1,1,2,3,4,4,3,3,3]| and |[(1, 4), (2, 1), (3, 1), (4, 2), (3, 3)]| where the first element is the data element, and the second is how many times it is repeated. We can currently do it like this in one line: [(k, sum(1 for _ in g)) for k, g in groupby(sequence)] However, it is slower than a "dedicated" solution. Additionally, I don't know if what you are proposing is generic enough for the standard library. -- Bernardo Sulzbach http://www.mafagafogigante.org/ mafagafogiga...@gmail.com ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)
On 05/14/2017 01:53 AM, Brendan Barnwell wrote: On 2017-05-13 21:07, Simon Ramstedt wrote: Here are the pros and cons I could come up with for the proposed method: (+) Simpler and more explicit. I don't really see how that's simpler or more explicit. In one respect it's clearly less explicit, as the "self" is implicit. I cannot imagine that the average Python programmer would consider this to be simpler or more explicit than the current way of creating objects. Some purists may argue in your favor, saying that by not having the _x attribute your code is more robust as you cannot accidentally change _x later and end up modifying how a method works. I don't think this is worse. However, I do think it is unnecessary. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Allow random.choice, random.sample to work on iterators
On 2016-11-30 19:11, Chris Kaynor wrote: All that said, I would not be opposed to Python including a random.reservoir_choice (probably not the best name) function *in addition* to random.choice. The algorithm has its uses, but enough drawbacks and gotchas that it likely is not a good candidate for a fallback. I think this may be the path of least resistance for this. Even if this does imply one or two new functions in random, it may be better than changing random.choice. If these functions would be used enough by enough end users to justify this change is debatable, however. -- Bernardo Sulzbach http://www.mafagafogigante.org/ mafagafogiga...@gmail.com ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Allow random.choice, random.sample to work on iterators
On 2016-11-30 17:57, Chris Kaynor wrote: On Wed, Nov 30, 2016 at 11:52 AM, Chris Kaynor <ckay...@zindagigames.com> wrote: There are also issues with how it should behave on iterables that cannot be re-iterated (eg, random.choice will consume the iterator, and could only be called once safely). I meant to include a sample in my previous e-mail: Consider that this code will not produce the "correct" results (for a reasonable definition of correct): a = (i for i in range(100)) # Pretend this does something more interesting, and isn't a trivial generator - maybe a file object reading by line. randomEntries = [random.choice(a) for i in range(10)] In such a case you should explicitly use a sample. I see your example as the caller's fault, which ignored the fact that the iterator would change after calls to choice. Hold the first 10 (in this case). For every subsequent element, randomly choose to replace one of the "held" ones by it (with a diminishing probability). Assume this does not offer the same performance as loading everything into memory. But it isn't meant to do so, as if you need / can / want, you could just shove it all into a list and use what we currently have. -- Bernardo Sulzbach http://www.mafagafogigante.org/ mafagafogiga...@gmail.com ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Allow random.choice, random.sample to work on iterators
On 2016-11-30 17:25, Random832 wrote: Currently these functions fail if the supplied object has no len(). There are algorithms for this task that can work on any finite iterator (for example, files as a stream of lines), and the functions could fall back to these if there is no len(). I like the idea, as long as it does not add too much overhead to currently existing code. It could be a special code path for reservoir sampling (I assume) for both functions (the first taking only one sample from the stream). -- Bernardo Sulzbach http://www.mafagafogigante.org/ mafagafogiga...@gmail.com ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] (no subject)
On 2016-11-29 02:58, victor rajewski wrote: NameError: name 'reponse' is not defined A better message might be: You're trying to use the value of 'reponse', but that variable hasn't got a value yet. You can give it a value earlier in the code, or it could be a typo. You have a variable called 'response' - is that the one you meant? This is a really nice feature. GHC and Clang do it for several things and it usually helps (when a live highlighter isn't available). Given that these are HS students, presumably seeing Python for the first time, shouldn't they be using PyCharm to get used to PEP 8 (no l[10]=14) and other best practices (e.g., such as using 'with' instead of 'try/finally' when possible)? This would provide live syntactic (and some semantic) highlighting with short human-readable messages. Overall, I already find Python's exceptions quite readable, and your suggestions propose some VERY long lines which would certainly wrap at a terminal. Maybe this should be an optional feature. -- Bernardo Sulzbach http://www.mafagafogigante.org/ mafagafogiga...@gmail.com ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PythonOS
On 11/06/2016 08:25 PM, victor rajewski wrote: What do you think? I'm not in a state to do all of this myself, but could give it a start if there is interest in the concept. Even though there is nothing wrong with the idea, I think there is not enough motivation for it. Most of the people learning Python for tinkering around with robots or doing some statistics will both be able to and eventually need to learn some basic system administration. Also, in comparison with some other languages, at least under Linux and BSD systems, setting up a Python environment is very straightforward. It is packaged for most distributions out there and executing a script does not require any cryptic initiation rituals. All in all, I don't know if this solves a problem or not. Sent from my mobile device. please. Please excuse brevity and any errors. Did you type all that in a touchscreen? -- Bernardo Sulzbach http://www.mafagafogigante.org/ mafagafogiga...@gmail.com ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Leave off "else" in ternary expression
On 10/28/2016 01:28 PM, Todd wrote: The idea would be to allow this syntax: x = a if b Which would be equivalent to: x = a if b else x What if x has not been defined yet? -- Bernardo Sulzbach http://www.mafagafogigante.org/ mafagafogiga...@gmail.com ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] if-statement in for-loop
On 09/11/2016 06:36 AM, Dominik Gresch wrote: So I asked myself if a syntax as follows would be possible: for i in range(10) if i != 5: body Personally, I find this extremely intuitive since this kind of if-statement is already present in list comprehensions. What is your opinion on this? Sorry if this has been discussed before -- I didn't find anything in the archives. I find it interesting. I thing that this will likely take up too many columns in more convoluted loops such as for element in collection if is_pretty_enough(element) and ...: ... However, this "problem" is already faced by list comprehensions, so it is not a strong argument against your idea. I am still unsure about whether or not the pattern you describe is frequent enough to justify special syntax. Not to mention that the current way to do it is already **very** readable. Just notice how for e in l: if e != 2: ... and for e in l if e != 2: ... read essentially the same and take about the same number of keystrokes. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Shuffled
On 09/06/2016 03:37 PM, Sven R. Kunze wrote: Besides being a silly argument, it's an interesting solution. Does it really work? I remember Microsoft utilizing a similar approach for their browser selection tool which led to a skewed probability distribution. Maybe, I wrong here though. Yes. The key is evaluated only once, so each element gets a pseudo-random number. Sorting this list leads to a shuffle. However, a super-linear shuffle, whilst Fisher-Yates is a linear solution and also requires less additional memory. Lastly, although it is obvious, from a software engineering standpoint, this is a mere weird hack. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
