[issue39090] Document various options for getting the absolute path from pathlib.Path objects
Vedran Čačić added the comment: > First, I hope we all agree: > 'C:\Windows\..\Program Files' and '/usr/../bin' == relative path I don't agree. To me, absolute means regardless of a reference point. So, absolute path would be a path that refers to the same entity from whichever directory you reference it. And that is surely the case for these two. -- ___ Python tracker <https://bugs.python.org/issue39090> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27198] Adding an assertClose() method to unittest.TestCase
Vedran Čačić added the comment: An important point nobody made, as far as I can see: * the main usability improvement justifying math.isclose is that you don't know the order of magnitude of your correct value--it could be anything (even infinite), and the manner of comparison depends on it. That's why it uses a sensible rel_tol out of the box, but no abs_tol--obviously, since it doesn't want to give nonsense results for e.g. values close to zero. * but when you write tests, you always know the exact value you should get, right? In almost all cases the second argument is a numeric literal. So the delta-approach is perfectly ok in that context, since you're in control of how much discrepancy you're going to tolerate, and in the moment that you're deciding on this, you have the exact value expected right in front of you. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue27198> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47031] math.nan should note that NANs do not compare equal to anything
Vedran Čačić added the comment:
I'm not satisfied with "and" formulation. For all practical purposes, math.nan
is the "same" object as float('nan'), they just represent two ways of referring
to it (or constructing it). To me it sounds a bit like "2 and 1+1 are the only
even prime numbers." I suggest the docs only speak of math.nan here, and
elsewhere to say that they can also be constructed by float('nan').
--
nosy: +veky
___
Python tracker
<https://bugs.python.org/issue47031>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47054] "SyntaxError: non-default argument follows default argument" should be "parameter"
Vedran Čačić added the comment: The problem is more subtle. The thing is, "default parameter" doesn't make sense in this context. Yes, a and b are parameter, but a is not "default parameter" in any sensible way. It is _None_ which is the default argument for parameter a, while parameter b has no default argument. In other words, if the function weren't called with a first argument, the default argument would be used. So, the fix should be a bit more complicated. Maybe, "a parameter without a default follows a parameter with a default"? -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue47054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47007] [doc] str docs are inconsistent with special method lookup
Vedran Čačić added the comment: You mean `type(object).__str__(object)` instead of `type(object).__str__()`, obviously. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue47007> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46945] Quantifier and Expanded Regex Expression Gives Different Results
Vedran Čačić added the comment:
Confirmed. On Python 3.10.2,
>>>
re.findall(r"(((\w)+\w*\3){2}|(\w)+(?=\w*\4)\w*(?!\4)(\w)\w*\5)\w*",'alabama')
[]
yet https://regex101.com/r/uT8gag/1 (with "Python" selected) says it should
match.
--
nosy: +veky
___
Python tracker
<https://bugs.python.org/issue46945>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46908] Debugger jumps to a wrong instruction in for loop
Vedran Čačić added the comment: pdb on Py3.10.2 works fine with that code. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue46908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46757] dataclasses should define an empty __post_init__
Vedran Čačić added the comment: That "except AttributeError" approach is a powerful bug magnet, since it can very easily mask real attribute errors stemming from misspelled attribute names in the __post_init__ call itself. What you should _really_ do is def __post_init__(self): with contextlib.suppress(AttributeError): post_init = super().__post_init__ post_init() But of course, nobody will ever write that. Raymond in his "super considered super" video (https://youtu.be/xKgELVmrqfs?t=2068) says the right thing to do is to make your own root which knows exactly what classes it manages, and drops the supercalls from them (after possibly verifying that all kwargs have actually been used and so on). But in case of dataclasses, usually any class can serve as such a root, and the main reason people use dataclasses is to avoid boilerplate code. So I think it would be a nice compromise. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue46757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46621] Should map(function, iterable, ...) replace StopIteration with RuntimeError?
Vedran Čačić added the comment: Just for the record, I consider PEP 479 one of (very rare) design bugs in Python, and would like it reversed some day. (So anything that helps this outcome, including -1 on this, is welcome.) It subverts the natural property of exceptions (that they bubble through frames undisturbed until caught) for no benefit at all, and it has made me write almost every chained generator since then in a more complex way, adding boilerplate code that converts inner StopIteration to return. I'm sure many others have done so too. Ceterum censeo PEP479em esse delendam. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue46621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46612] Unclear behavior of += operator
Vedran Čačić added the comment: You've managed to write 3 messages already, without at any point mentioning what _really_ happens when you += something. a += b means (is closest to) a = type(a).__iadd__(a, b) You focus all the time on __iadd__ call, disregarding that its result it assigned back to a in scope. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue46612> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46574] itertools.count should work with non-number types
Vedran Čačić added the comment: At one moment, I had a need for itertools.count(datetime.date.today(), datetime.timedelta(days=1)) Of course, it was no problem to write it myself, but still, it would be incredibly neat if it simply worked. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue46574> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46291] [doc] First argument to raise can also be BaseException
Vedran Čačić added the comment: Let me just say that I use `raise SystemExit` all the time. Beats `from sys import exit`, weird error messages about having to type parentheses, and surely beats "oh, am I on Windows so Ctrl+Z, or on Linux so Ctrl+D". :-] I also use `raise KeyboardInterrupt` sometimes in games, to test whether Ctrl+C handling works as expected at precise moments in the game (beats having to guess the millisecond in which to press Ctrl+C:). -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue46291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46033] Duplicated sentence in for statement documentation
Vedran Čačić added the comment: Yes, it's ok. The only slight problem is that is suggests that first item is somehow special, but later it is explained that in fact it is not. :-) I would say "_Each_ item ..." (instead of "First") and without the "this is repeated for every item..." at the end, but as I said, this is also fine. -- ___ Python tracker <https://bugs.python.org/issue46033> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46219] except* assumes that an exception group is truthy
Vedran Čačić added the comment: A long time ago, Python documentation used true and false as adjectives (as opposed to True and False, which are proper names for canonical true/false objects). I think it was BDFL's preference back then. In the meantime, I suppose through JS's influence, Python documentation started to adopt ancient Perl terminology, where truhy and falsy were used as adjectives standing for what was previously known as true and false. I really don't like it, and I think English language is clear enough here (given the help of code font and capital letter) that we don't need to invent new words. Of course, it is up to the community to decide (and maybe the steering council might issue an opinion), but I'm telling you the history and my preference. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue46219> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46033] Duplicated sentence in for statement documentation
Vedran Čačić added the comment: How about adding the words "More precisely," at the beginning of the second sentence? -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue46033> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26120] pydoc: move __future__ imports out of the DATA block
Vedran Čačić added the comment: I thought that _Feature starts with an underscore precisely to evade such listings. Do other "private" module data also get listed? -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue26120> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45988] inspect.signature fails on a @staticmethod
Vedran Čačić added the comment: Of course, signature should be imported from inspect, not from typing. In that case, the example works on Python 3.10 and 3.11. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue45988> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44166] Make IndexError messages for list more informative
Vedran Čačić added the comment: > fix typically isn't replacing s[i] with s[i - 5] ... especially since that will still raise IndexError (in case when i==15 and len(s)==10). ;-P -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue44166> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45971] calendar module issue
Vedran Čačić added the comment: https://docs.python.org/3/library/calendar.html#module-calendar The functions and classes defined in this module use an idealized calendar, the current Gregorian calendar extended indefinitely in both directions. https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar Even if we decide to change this, this is the thing locale should worry about: not every place adopted Gregorian Calendar at the same time, nor in the same way. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue45971> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45908] dict.fromkeys insertion order
Vedran Čačić added the comment: Absolutely, but that's not my problem. I take your sentence to mean that when I do something with a _dict_ argument, it should try to preserve its insertion order as much as possible (given the semantics of the concrete method in question). I agree. But my question is about constructing a dict from something other than a dict (here, a str, simply because it's easiest to visualize). I'm sure you don't mean to say dict.fromkeys retains the insertion order of its argument always, since it's obviously false if you give it a set. What I'd like to be specified here (or elsewhere, but here I think it's useful) is that _iteration order_ of the argument to dict.fromkeys is preserved as _insertion order_ (and therefore iteration order) of the resulting dict. Besides, I don't see any other point where it should be specified... the only other constructor, `dict` itself, gives a very precise description (https://docs.python.org/3/library/stdtypes.html#dict) of how it creates a dict from its argument(s). Of course, there it mattered even before Py3.7, since values were important. In dict.fromkeys values are all the same, but order still matters and should (IMO) be specified. -- ___ Python tracker <https://bugs.python.org/issue45908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45908] dict.fromkeys insertion order
New submission from Vedran Čačić :
I'm sure this is exactly how it should work, I just want to know if you think
it is documented properly, so I can rely on it. In my opinion the docs should
be more precise.
>>> ''.join(dict.fromkeys('axbxc'))
'axbc'
Is this guaranteed by the documentation? Of course, dict iteration order is now
guaranteed to be insertion order, but still, nowhere do the docs say that
fromkeys inserts the keys into new dictionary in order in which they appear in
its argument.
(Probably the reason for this is that dict iteration order was fixed in 3.7,
yet fromkeys existed a long time before that.)
I propose an addition to the documentation:
> Create a new dictionary with keys from iterable (in order) and values set to
> value.
https://docs.python.org/3/library/stdtypes.html
--
assignee: docs@python
components: Documentation
messages: 407136
nosy: docs@python, veky
priority: normal
severity: normal
status: open
title: dict.fromkeys insertion order
versions: Python 3.10, Python 3.11
___
Python tracker
<https://bugs.python.org/issue45908>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45393] help() on operator precedence has confusing entries "await" "x" and "not" "x"
Vedran Čačić added the comment: I guess those old versions were removed because they are "frozen", that is, not receiving doc fixes anymore. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue45393> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41226] Supporting `strides` in `memoryview.cast`
Vedran Čačić added the comment: I surely don't understand what the third argument means. What's (1, 2) there, and what stride does it produce? -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue41226> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()
Vedran Čačić added the comment: Just wanted to say that "raise SystemExit" is shorter than "import sys; sys.exit()", has no special characters (just letters and space) and is really much quicker to write. Yes, it doesn't work if someone rebound SystemExit, but if that's your problem, you have weird coworkers. ;-) -- ___ Python tracker <https://bugs.python.org/issue44603> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()
Vedran Čačić added the comment: > why it would be beneficial to have custom handling like this for exit is that > exit is a site-builtin, not a builtin. In my view, that's exactly why it _shouldn't_ have a special treatment. After all, site can add many more builtins. Do you want all of them to have autocall? -- ___ Python tracker <https://bugs.python.org/issue44603> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35712] Make NotImplemented unusable in boolean context
Vedran Čačić added the comment: Please see the message https://bugs.python.org/issue35712#msg349303. Filtering with those dunder sesqui-dispatch methods really is a bug magnet. -- ___ Python tracker <https://bugs.python.org/issue35712> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45155] Add default arguments for int.to_bytes()
Vedran Čačić added the comment: I'd say yes. Of course, one way to ascertain that would be to conduct a valid pool. ;-) -- ___ Python tracker <https://bugs.python.org/issue45155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45155] Add default arguments for int.to_bytes()
Vedran Čačić added the comment: The poll is invalid, since the option that most people want is deliberately not offered. -- ___ Python tracker <https://bugs.python.org/issue45155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45155] Add default arguments for int.to_bytes()
Vedran Čačić added the comment: My sensibilities are irrelevant here. I'm just saying we already have a standard byte order for data in transit, and it was introduced long before this thing called internet (it was with capital I back then:) started to interest me. -- ___ Python tracker <https://bugs.python.org/issue45155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45155] Add default arguments for int.to_bytes()
Vedran Čačić added the comment: > choose one for the default so that default encoding/decoding will work cross > platform. I think "little" is the most common (intel and arm). Raymond, please don't do this. We already have a "sensible default" in a network context, and it is big endian. Having another "sensible default" opposite to the previous one is really no way to ensure interoperability. (https://xkcd.com/927/ only becomes more ridiculous when the number in question is 2.:) I don't want to think about whether the way machines A and B exchange data can be called "a network" or not. Of course, having the byteorder optional when there's only one (unsigned) byte is good. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue45155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45104] Error in __new__ docs
Vedran Čačić added the comment: The first variant seems best to me. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue45104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45048] subprocess.run(capture_output=Bool) does the opposite of expected
Vedran Čačić added the comment: I think it is exactly what "capture" means: "not allow it to escape" (to the console). Maybe you should read the documentation? -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue45048> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45043] Typo (change 'two' to 'three')
Vedran Čačić added the comment: Matt obviously meant the day of week, but in docs day is meant as day of month. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue45043> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45009] Get last modified date of Folders and Files using pathlib module
Vedran Čačić added the comment: It probably has nothing to do with your bug, but your title is wrong. You are _not_ getting mtime using pathlib (but using os.path instead). That is done like using this approach: https://docs.python.org/3/library/pathlib.html#pathlib.Path.stat Just to eliminate irrelevant details, could you try _actually_ implement the algorithm using the above, and see if the results differ? -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue45009> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44993] enum.auto() starts with one instead of zero
Vedran Čačić added the comment: And CEnum is probably the best name for it. "Int" part is pretty much implied in "C" part. -- ___ Python tracker <https://bugs.python.org/issue44993> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44993] enum.auto() starts with one instead of zero
Vedran Čačić added the comment: _But why should it matter that starting value is the same_ unless you actually use IntEnums for indexing? About your code: what do you _actually_ mean by "equivalent"? I hope you don't think that the memory representation is the same. You keep mentioning APIs and networks, but never concretely... do you intend to say that you somehow serialize those values, send them over the wire and then deserialize them into another language? -- ___ Python tracker <https://bugs.python.org/issue44993> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44993] enum.auto() starts with one instead of zero
Vedran Čačić added the comment: Honestly, I think it's backwards. Either they _do_ matter because of some external factor (you mention network interoperability, though I'd like you to clarify... what exactly did you send over the network?), or they don't matter (if done right, you shouldn't even _notice_ that they start at 1 --- unless you test their truth value, which was the reason for the original departure from the usual practice in the first place). You mention indexing... I _hope_ you're not using IntEnums for indexing tuples (or lists). :-o In such a scenario, you're really much better off cutting the middleman and using objects with attributes directly (an interesting insight: due to the way most objects in Python are implemented, you _still_ have the middlemen integers in the process -- only they are called "hash values" and they _truly_ don't matter:). -- ___ Python tracker <https://bugs.python.org/issue44993> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44993] enum.auto() starts with one instead of zero
Vedran Čačić added the comment: I think you should be even more explicit. If values matter, they _should_ be seen in code. (All of them, not just the first one.) auto() just means "this value doesn't really matter". And it's not really hard to write concrete values instead of auto(), in many instances it's even easier. :-) -- ___ Python tracker <https://bugs.python.org/issue44993> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44993] enum.auto() starts with one instead of zero
Vedran Čačić added the comment: For IntEnum, maybe. But for Enum, the whole point of auto() is that the values don't really matter. The rationale was that with IntEnum, truth testing (which is often used in Python to realize Optional) would distinguish None, and then all true Enums would actually be true in the boolean sense. In a way, most real examples of enums already have some "fake" value which they map to 0. In Python, you idiomatically use None for that. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue44993> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44940] Suggest the use of non-capturing groups in re.findall() and re.finditer() docs
Vedran Čačić added the comment: Also, maybe you should read the following sentence (also in the docs): > If one wants more information about all matches of a pattern than the matched > text, finditer() is useful as it provides match objects instead of strings. It seems that's what you wanted in the first place. -- ___ Python tracker <https://bugs.python.org/issue44940> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44940] Suggest the use of non-capturing groups in re.findall() and re.finditer() docs
Vedran Čačić added the comment: Have you seen the patch? In the patched docs, non-capturing grouping is explicitly mentioned. (Though I myself wouldn't include even that, as it's superfluous with what's said before, obviously it's needed.:) -- ___ Python tracker <https://bugs.python.org/issue44940> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44940] Hint the use of non-capturing group in re.findall() documentation
Vedran Čačić added the comment: Ah, now I see. When some_match.group(0) is called, the whole match is returned. So match can be considered kinda group (quasigroup?:). I see how it can be confusing: python usually starts indexing at 0, and someone might think that a .group(0) would be included in "a list of groups" returned. I'm not sure how best to fix it. Maybe: Alternatively, if grouping parentheses are present in the pattern, return a list of groups captured by them... -- ___ Python tracker <https://bugs.python.org/issue44940> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44940] Hint the use of non-capturing group in re.findall() documentation
Vedran Čačić added the comment: It currently says: ...matches are returned in the order found. If one or more groups are present in the pattern, return a list of groups... I'm not quite sure how it could be clearer. Maybe "Alternatively" at the start of the second sentence? regexr does the same thing, as far as I can see. Match is 'cool', group 1 is empty. Matches are not the same as groups. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue44940> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44931] Add "bidimap" to collections library: a simple bidirectional map
Vedran Čačić added the comment: Your implementation has many problems. First, almost all your complexity claims are wrong, probably because you copied them from Java, which uses balanced trees instead of Python's hash tables. (Also, the method names seem to be copied from Java, using camelCase which is unusual for Python stdlib.) Second, shouldn't _inverse be a weakkey dictionary? Otherwise many operations (e.g. removeValue) will get two dicts out of sync quickly. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue44931> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44663] Possible bug in datetime utc
Vedran Čačić added the comment: Would it be possible to change .utcnow to now return a datetime annotated with UTC "timezone"? After all, now we have timezone-aware datetimes and the convention that naive means local, this behavior might even be considered a bug. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue44663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()
Vedran Čačić added the comment: > In the other hand, special-casing 'quit\n' and 'exit\n' could be seen as > analogous to special-casing '^Z\n' Terry, there is a big difference between special-casing 'exit\n' and special-casing '^Z\n': 'exit' is a perfectly valid identifier (and people use it regularly), ^Z is not. Especially if 'exit\n' exited unconditionally, I think many people would be very frustrated and surprised when trying to inspect the variable called 'exit'. I'd have no objection if something like '!exit' was special-cased, but then there is not much difference between adding a bang before and adding the parentheses after. Alternatively, exit can be proclaimed a keyword, but I really think this is overkill. And please don't think this process that you're starting now will stop at these two words. Much more beginners, according to my experience, try to type `pip install something` inside Python REPL. If we do this, it will be a powerful precedent, and almost surely we will have the "magic mess" later. -- ___ Python tracker <https://bugs.python.org/issue44603> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()
Vedran Čačić added the comment: > based on feedback it seems that almost everyone expects "exit" to exit I don't, and I don't remember being asked. Let me be clear: if exit were a Python keyword, then maybe I would expect that. Or at least, I could convince myself to expect that. But exit is _not_ a keyword, it is not even a builtin, and there is a _strong_ reason for that. One of Guido's many valuable insights about language design is that you shouldn't preclude other uses of names you find convenient for your builtins. See the last line of Zen of Python. And yes, I _have_ used exit as a name for my objects (e.g. as a flag in Pygame, set exit = False at the beginning and exit = True somewhere in the loop when I find out that the game is over). Although I don't recall ever actually typing `exit` into Python REPL to inspect its value, I really think that scenario is plausible (for example, if a game exited prematurely, and I wanted to see whether exit was set to True prematurely, or there was some other reason), and it would _annoy me immensely_ if instead of showing me the status of the flag it would drop me out of Python. In fact, you're proposing to use exit as a keyword, but lying about it to the users. If it were really so important, then it _should_ be a keyword, and at least I'd know that I can't use it for my variables anymore. (It's not the first time such a thing would happen. The same thing happened with `async` a few years ago.) But please don't introduce those "keywords just in a particular context", they are horrible from the perspective of usability. -- ___ Python tracker <https://bugs.python.org/issue44603> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()
Vedran Čačić added the comment: Of course, the "license" mention should be changed in the same way (in the same message). -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue44603> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44607] Teleport method for turtle class
Vedran Čačić added the comment: In my view, turtle is a great tool for exploring _polar_ coordinates. If you set emphasis to rectangular coordinates, there are many tools that are much better. Second, your function might be ok for you, but it is really not suitable for standard library. Probably you meant something like (a method) def teleport(self, *args): restore = self.isdown() self.penup() self.setpos(*args) if restore: self.pendown() -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue44607> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44595] round() gives wrong result
Vedran Čačić added the comment: Have you seen the Note at https://docs.python.org/3/library/functions.html?highlight=Note#round? -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue44595> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44452] Allow paths to be joined without worrying about a leading slash
Vedran Čačić added the comment: It doesn't make sense to "concatenate" one absolute path to another. / has a simple explanation: if you start at /foo, and then do cd bar, you'll end up in /foo/bar. But if you start at /foo, and then do cd /bar, you'll end up in /bar. You mean, some of your users write '/some/path' when they mean 'some/path'? Then the users should be educated about the difference. These are not the same, just like '../some/path' is not the same as them, and '~some/path' is again something very different. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue44452> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44346] Fraction constructor may accept spaces around '/'
Vedran Čačić added the comment: Of course, I'm for it. But we have to be consistent... I was surprised to realize `complex` doesn't accept '2 + 3j' (even though it accepts '(2+3j)', and even '\n2+3j\t'). There are a lot of slippery slopes here (e.g. how about 3_j?). I think that once we allowed _ in integer literals, suddenly we could add more separation between digits than around them in many contexts, and that just seems wrong. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue44346> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44258] Support PEP 515 for Fraction's initialization from string
Vedran Čačić added the comment: How about '1_/_2'? I think making / more separated adds value... though of course, someone will ask about '1 / 2' next. :-) -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue44258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38605] [typing] PEP 563: Postponed evaluation of annotations: enable it by default in Python 3.11
Vedran Čačić added the comment: May I ask, is this going forward? I installed 3.11-dev, it's not there (though __future__ claims it should be). I understand if it isn't done yet, just want to know if there's risk it will be postponed again (or even given up). -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue38605> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44115] Improve conversions for fractions
Vedran Čačić added the comment: Absolutely. I think that's a big part of the reason that as_integer_ratio is there. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue44115> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43701] Add this optionality
Vedran Čačić added the comment: Well, just reverse the order of -= in second statement. If you write =-, it will magically work. ;-) But in the general case, sometimes introducing temporary variables is the simplest solution. The alternative would be to implement pointwise -= for tuples, which would be extremely confusing since they already implement += with a completely different semantics. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue43701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43581] array assignment error
Vedran Čačić added the comment: All three words in the title are wrong. :-D -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue43581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43535] Make str.join auto-convert inputs to strings.
Vedran Čačić added the comment:
Yes, I know what strong typing means, and can you please read again what I've
written? It was exactly about "In the face of ambiguity, refuse the temptation
to guess.", because binary operators are inherently ambiguous when given
differently typed operands. Methods are not: the method _name_ itself is
resolved according to self's type, it seems obvious to me that the arguments
should too. Otherwise "explicit fanatics" would probably want to write
list.append(things, more) instead of things.append(more).
The only reason we're having this conversation is that when it was introduced,
`join` was a function, not a method. If it were a method from the start, we
would've never even questioned its stringification of the iterable elements
(and of course it would do that from the start, cf. set or dict update methods).
Gregory: yes, `bytes` elements are a problem, but that's a completely
orthogonal problem (probably best left for linters). The easiest way to see it:
do you object to (the current behavior of)
>>> s = {2, 7}
>>> s.update(b'Veky')
? :-)
--
___
Python tracker
<https://bugs.python.org/issue43535>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43535] Make str.join auto-convert inputs to strings.
Vedran Čačić added the comment:
Matthew: can you then answer the same question I asked Serhiy?
The example usually given when advocating strong typing is whether 2 + '3'
should be '23' or 5. Our uneasiness with it doesn't stem from coercions between
int and str, but from the fact that + has two distinct meanings.
Of course, binary operators are always like that, even if it's not obvious,
since there's always a tension created by difference of types of the left and
right operand. Even if it's obvious that 2 - '3' should coerce the second
argument to int since str doesn't define -, this can't be a general rule
because e.g. set does (what about 2 - {3}?).
But method calls (and many protocols) are _not_ of that kind. As I said above,
my_set ^ some_list makes us uneasy (even though list doesn't implement ^), but
my_set.symmetric_difference(some_list) doesn't, simply because there is no
ambiguity: there is only one thing we could have meant.
The same can be said about "for x in not_an_iterator", or "if not_a_bool".
--
___
Python tracker
<https://bugs.python.org/issue43535>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43535] Make str.join auto-convert inputs to strings.
Vedran Čačić added the comment: Does strong typing mean you should write if bool(condition): ... or for element in iter(sequence): ... or (more similar to this) my_set.symmetric_difference_update(set(some_iterable)) ? As Eric has said, if there's only one possible thing you could have meant, "strong typing" is just bureaucracy. -- ___ Python tracker <https://bugs.python.org/issue43535> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43535] Make str.join auto-convert inputs to strings.
Vedran Čačić added the comment: I can't find it now, but I seem to remember me having this same proposal (except the part for bytes) quite a few years ago, and you being the most vocal opponent. What changed? Of course, I'm still for it. (Your second list has fourth item extra. But it's clear what you wanted to say.) -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue43535> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34013] Inconsistent SyntaxError for print
Vedran Čačić added the comment: > "It's still one of the most common beginner mistakes" Do you have any data to back this up? I really think it's overblown. On the other hand, if it really _is_ so, how about changing the language? It wouldn't be the first thing that was changed for Py3, and then changed back once people realized the old way was better. It seems to me totally backwards to have a construct in the grammar, only to report it as an error. "I understand you, but you still have to use _this_ way to write what you want." I really think Python shouldn't be that kind of language. -- ___ Python tracker <https://bugs.python.org/issue34013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34013] Inconsistent SyntaxError for print
Vedran Čačić added the comment: Aren't we overthinking this? Python 2 is a dead language. It has reached end of life more than a year ago (and was scheduled to do so in 2015). Why are we still trying to accomodate something that stopped being relevant a long time ago? -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue34013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43213] Shortcut for checking if PurePath object contains str
Vedran Čačić added the comment: While it might be useful, I don't think it is what you want. For example, you wouldn't say it contains 'r/sh', right? I think it should only refer to full names of path parts. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue43213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43205] Python Turtle Colour
Vedran Čačić added the comment: It is just a matter of a different (though not very different) language. As such, it is a duplicate of https://bugs.python.org/issue24990. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue43205> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43085] Loosening | and |= operator type checking restriction
Vedran Čačić added the comment: @Raymond: why can't ABCs have _default_ implementation of | and |=, in terms of other supported methods (such as update)? It seems to me this would be the best of both worlds. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue43085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42500] crash with unbounded recursion in except statement
Vedran Čačić added the comment: Recursion limit is probably set too high, but nonetheless, the program is nonsensical, the line 39 especially. The reason for difference in behavior is that RecursionError is caught by blank except in the earlier Pythons, while it crashes the stack in later ones. In any case, it's almost certain this isn't what you wanted to write. (And yet another reason to remove blank except from Python: it abuse to correct use ratio is probably over two orders of magnitude.) -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue42500> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15034] Document best practices for exceptions
Vedran Čačić added the comment: Terry: of course, if a method is not overridden, there's no need to call super()'s method, since the only thing it would do is call the same thing that would be called without overriding. But of course, if Exception's __init__ does anything, then super() should be called from the overrridden method. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue15034> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35712] Make NotImplemented unusable in boolean context
Vedran Čačić added the comment: ... as it probably should: look at https://bugs.python.org/msg349303 Yes, filtering comprehensions are a frequently used niche, and too long in the "official" parlance. I seem to recall that [x in mylist if x is not None] (instead of triple-x version) was rejected because it was too hard to parse. Maybe now we can really implement it? -- ___ Python tracker <https://bugs.python.org/issue35712> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42222] Modernize integer test/conversion in randrange()
Vedran Čačić added the comment: Yes, the ability to write randrange(1e9) is sometimes nice. And the fact that it might give the number outside the intended range with probability 1e-17 is not really an important argument (people have bad intuitions about very small probabilities). But if we intend to be consistent with range, then of course this must go. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue4> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31504] Documentation for return value for string.rindex is missing when search string is empty
Vedran Čačić added the comment: Maybe you would use 5, but I would use 7 and get the same result. If the docs say "X.rindex(Y) == i means i is the highest index where Y is found in X", and "Y is found in X at i" is interpreted as "X[i:i+len(Y)] == Y" (as Serhiy said), then there is no such (highest) index. I understand what _you_'re saying, but please understand that the docs do not say anything like that. -- ___ Python tracker <https://bugs.python.org/issue31504> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42210] float.hex discards sign from -nan
Vedran Čačić added the comment: inf and -inf are really two different values (in the scope of the standard). Same as 5. and -5., or even 0. and -0. They behave differently in some exactly specified operations, and it is useful. Are there any exactly specified operations whose specifications require the unequal treatment of nans with + and - signs? I don't think so, since it goes against the whole idea of nan as an unspecified number. (If you want to track its _history_, that's what payload is for.) My interpretation is that nan can have a sign bit only so unary minus and absolute value can be implemented quicker (without having to check whether the input is nan) -- not because it carries any useful semantics within the standard. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue42210> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26789] logging: Trying to log during Python finalization with NameError: name 'open' is not defined
Vedran Čačić added the comment: > In the OP, the error is caused by `open` being unavailable, which is a > builtin. According to what Serhiy says, this error would be after step 6 I think you read the post above incorrectly. The phase 3 is the one where open is removed, since it's not a "native" builtin, but imported from io. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue26789> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42060] Usage of assert in http/client.py
Vedran Čačić added the comment: If I understand correctly, those are _private methods_ (names start with underscore). In such cases, asserts can be completely fine, since the library writer controls the situations where the method is called. If it is never called with _UNKNOWN argument, assert is just that, assertion that it is so. (It would be different if it were a public method, since the library writer doesn't know it will never be called with _UNKNOWN.) -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue42060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38250] enum.Flag should be more set-like
Vedran Čačić added the comment:
Flag values are _not_ a set of enabled bits.
At least, it is a weird kind of set where a is the same as {a}. That's why I
mentioned mereology... there is no reasonable "membership", just "inclusion". I
understand that str is not a perfect analogy, but sets are even more wrong.
--
___
Python tracker
<https://bugs.python.org/issue38250>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38250] enum.Flag should be more set-like
Vedran Čačić added the comment: Again, I disagree. `str` used to work like this in Py2.0 (or somewhere around then), only 'x' was in 'xyz', not 'xy'. Then Guido came to his senses. :-) This is not set theory, this is mereology. You don't differentiate between a digit and a one-digit number, a char and a one-char string, and in the same way you shouldn't differentiate between a bit and a one-bit flag. -- ___ Python tracker <https://bugs.python.org/issue38250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38250] enum.Flag should be more set-like
Vedran Čačić added the comment: Of course, if it returns True only on _some_ bits combinations it doesn't make sense. I thought every element of a Boolean span would be _in_ the Foo. But about "zero bit", I still think it's perfectly analogous to '' in 'abc'. -- ___ Python tracker <https://bugs.python.org/issue38250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38250] enum.Flag should be more set-like
Vedran Čačić added the comment:
Just a comment, (1) is analogous to str. iter('abc') gives only 'a', 'b' and
'c', while contains accepts '', 'ab', 'bc', and 'abc' too. At least in my mind,
it's a pretty strong analogy.
--
___
Python tracker
<https://bugs.python.org/issue38250>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41877] Check against misspellings of assert etc. in mock
Vedran Čačić added the comment: Of course, that's why I wrote "my" in quotes above. It's not my solution, it's the idea that many people independently had. Because it is _the_ solution, of course. :-] I'd just like to point out in the above thread (first link you provided), how _many_ people operate under the assumption that "misspelling problems are now solved". I'm sure many of their opinions would be different if they knew we'd be having this discussion now. Let's not make the same mistake again. I assure you that in few more years we'll find some other creative ways to misspell arrest_* methods. ;-) -- ___ Python tracker <https://bugs.python.org/issue41877> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41877] Check against misspellings of assert etc. in mock
Vedran Čačić added the comment: Sorry, but 1) Stability policy is great when we hold on to it. If we add new spellings of assert every few years, what kind of stability it is? "My" solution is of the same type: just add one more thing to the API. But that solution is better, because a) it doesn't clash, and b) it must be done only once. 2) Soundex has nothing to do with it. It was invented to mitigate errors when transferring _sounds_ (phonemes) over the telephone wire. It would surprise me very much if those were in any useful sense correlated with errors encountered typing graphemes on the mechanical keyboard. -- ___ Python tracker <https://bugs.python.org/issue41877> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40066] Enum._convert should change __repr__ and/or __str__ to use module name instead of class name
Vedran Čačić added the comment: > - do you think the change has merit? Absolutely. > - why /shouldn't/ we make the change? Well, standard backward compatibility stuff. :-) -- ___ Python tracker <https://bugs.python.org/issue40066> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41877] Check against misspellings of assert etc. in mock
Vedran Čačić added the comment: It would be a valid argument if the API _worked_. Obviously, it doesn't. Every few years, the same story repeats. "We've found even more missspellings of assert, we need to add them too. They cause real bugs in our tests." I have a strong feeling it will never end. -- ___ Python tracker <https://bugs.python.org/issue41877> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41877] Check against misspellings of assert etc. in mock
Vedran Čačić added the comment: How about we actually _solve_ the problem, instead of masking it with layer upon layer of obfuscation? Python has standalone functions. assert_called (and company) should just be functions, they shouldn't be methods, and the problem is solved elegantly. The whole reason the problem exists in the first place is that Java, where Python copied the API from, has no standalone functions. In Pythonic design, the problem shouldn't exist at all. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue41877> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35765] Document references object x but doesn't show it in the example
Vedran Čačić added the comment: I think it would be simpler to just remove the empty name `x`. "If you have an object, you can ...". -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue35765> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40066] Enum._convert should change __repr__ and/or __str__ to use module name instead of class name
Vedran Čačić added the comment: Noone said it is a requirement, I just said it would be nice to have it factored out as a decorator or something instead of having to write __repr__ over and over again. -- ___ Python tracker <https://bugs.python.org/issue40066> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40066] Enum._convert should change __repr__ and/or __str__ to use module name instead of class name
Vedran Čačić added the comment: If it's considered to be not too backwards-incompatible, I think it would be nice to have str different from repr. That way we can finetune what exactly we need. But we can already do almost exactly that with *int* instead of *str*, so it's not too compelling. Much more important thing is the "repr as inverse of eval". Is there any way we can have that for our own enums (as a mixin or a decorator)? @module_global(re) class RegexFlag(Enum): ... It would be fantastic. :-) -- ___ Python tracker <https://bugs.python.org/issue40066> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41740] Improve error message for string concatenation via `sum`
Vedran Čačić added the comment: The fact that you've forgotten about it is exactly why sum tries to educate you (despite Python being "the language of consenting adults" in most other aspects). The problem (why it doesn't do a good job in that aspect) is that people usually expect sum to act like a 2-arg form of functools.reduce, while in fact it acts like a 3-arg form, with 0 as the initializer. I doubt that Python will change regarding that, but you can sharpen your intuition by asking yourself: what do you expect sum([]) to be? If 0, then you're inconsistent. :-) -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue41740> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41598] Adding support for rounding modes to builtin round
Vedran Čačić added the comment: Well, of course, but that's possible even now, and people still reach for `round`. I guess the problem is that it's too easily accessible. :-) -- ___ Python tracker <https://bugs.python.org/issue41598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41598] Adding support for rounding modes to builtin round
Vedran Čačić added the comment: > Personally, I think I'd rather have easier ways to create Decimal objects Wouldn't everybody? :-P But that's been proposed at least 4 times already and never got anywhere. My proposal is at least original, has a precedent at the above link (strings as surogate literals, preserving value across semantic boundaries), _and_ comes with a natural scope limitation guarantee: noone can argue for '2.1' + '3.5' to be '5.6' (because it is already '2.13.5';), it works only in the first argument of round. Also, the string at that time is not so pointless: many people use round for printing, at that point you are going to convert to str anyway. And round(str(result), digits) gives a nice way to use python's builtin repr capability of "picking the shortest representation" for DWIMming: it's the best of both worlds, your implementation DWIMs, but you're not responsible for corner cases. ;-= But no, I'm not going to Python-ideas, for the same reason I'm not going back to high school: too many bullies, too hard to get your voice heard, mostly because everyone assumes you wouldn't be there if you had anything smart to say. :-/ -- ___ Python tracker <https://bugs.python.org/issue41598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41598] Adding support for rounding modes to builtin round
Vedran Čačić added the comment: > I'd rather add whatever bells and whistles we need (if any) to make it easier > for users who care about this to use Decimal. This made me think. (I have tons of these ideas, but usually am afraid of voicing them unless encouraged by comments such as this one.;) How about this whistle: we allow round to accept str as the first argument? In a very unrelated context (https://www.python.org/dev/peps/pep-0484/#forward-references) Guido has said something like "when literals aren't what they seem, strings are a good enough substitute". Maybe here too? -- ___ Python tracker <https://bugs.python.org/issue41598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41598] rnd() + rndup() in math
Vedran Čačić added the comment: > use more digits to manage rounding in decimal base, not only one but more (i > should think better and experiment on how many) You don't have to. It's infinitely many. :-P Think, how many decimal digits would you need to accurately round numbers to a closest third (one trinary digit)? Here are some decimal digits: 2.1. If the next digit is 5, then it rounds to 2.0. If it is 7, it rounds to 2.1 (base 3). If it is 6, you still don't know anything. It can go arbitrarily far. Of course, the probability is lower with every digit, and at some point it becomes acceptable (you said for yourself it's acceptable even with one extra digit), but it's not mathematically correct. And that one bit was just an illustration. In real life, 64-bit machines usually use at least 80-bit precision, so 16 extra bits. But it doesn't help your case, for the above reasons: this is simply not decimal rounding. -- ___ Python tracker <https://bugs.python.org/issue41598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41598] rnd() + rndup() in math
Vedran Čačić added the comment:
I think you don't know what paraphrasing means. Or maybe I don't know it, but
in any case, I'm well aware what Von Neumann said, and how it is usually
misunderstood in today's society. "Living in the state of sin" is simply an
emotionally powerful metaphor, and it pertains to the philosophical
impossibility of something, whether or not there are strong reasons to "do it
anyway" and even good methods of faking/approximating it. Same as "detecting
infinite loops programmatically", "passing objects by value", or "having side
effects in a referentially transparent language". :-)
I agree that Python is a language where practicality beats purity, and as I
said, there is a sensible interface for the implementation about which we agree
(except for a detail: I'd actually _force_ people to import the rounding modes
from decimal module, to at least hint to them what exactly they are doing and
what the preferred approach is). But I still think that arguments for that are
very weak.
First, yes, there is a very small probability of calculations _randomly_ ending
with abc.de5...0 (in the Platonic sense) [so it actually manifests as a
problem], but there is much greater probability (though still small) that
calculations _theoretically_ ending with abc.de5 actually end with
abc.de4...7 [and thus are rounded down anyway, despite your insistence on
modes]. People _will_ think "hey, I did the right thing by specifying the
mode--why does it still acts funny?"
"there are reasonable use-cases for different rounding modes even when using
floats.": absolutely. But they are _binary_ rounding modes! I think you should
read the standard. It is actually two standards, one for binary and one for
decimal arithmetic. (The second one is implemented fairly faithfully in the
decimal module; the first one is, through libc, the one that Python floats are
based upon).
The [binary] standard says, more or less, that the result should be as if the
value was calculated with the infinite number or extra [binary] digits (of
course, in practice it should just be some extra precision, but again, of
_binary_ digits), and then, when fitting that value into a smaller [binary]
register with smaller available number of [binary] digis, all extra [binary]
digits are discarded (not stored) and some ending [binary] digits retained are
modified according to the value of some of the discarded [binary] digits and
the rounding mode. For example:
"""
The 24-bit significand will stop at position 23, shown as the underlined bit 0
above. The next bit, at position 24, is called the round bit or rounding bit.
It is used to round the 33-bit approximation to the nearest 24-bit number
(there are specific rules for halfway values, which is not the case here). This
bit, which is 1 in this example, is added to the integer formed by the leftmost
24 bits.
"""
You see it speaks about _bits_, not decimal digits. In the same way, _decimal_
rounding would take a value calculated with some extra precision of _decimal_
digits, and when storing them with the smaller number of _decimal_ digits,
discard extra... blah blah as above. But you cannot round binary numbers to
decimal digits. It's as if you tried to round 0.45 to one trinary digit after
the integer point. The answer is 0.1 in base 3, but it isn't expressible in
decimals. And it doesn't work:
>>> Decimal('0.45').quantize(Decimal(1/3))
decimal.InvalidOperation: []
because the authors of quantize have thought about that. The documentation says
"""Unlike other operations, if the length of the coefficient after the quantize
operation would be greater than precision, then an InvalidOperation is
signaled.""" In effect, rounding cannot increase the number of significant
digits. And it would do that if you're rounding to an incompatible base,
whether 2 to 10 or 10 to 3.
--
___
Python tracker
<https://bugs.python.org/issue41598>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41607] pdb - Clickable path to breakpoints
Vedran Čačić added the comment: IDLE has Go to File/Line menu too. I think it would also help there. (Terry, can you confirm?) Not to mention that it would be one thing less to explain to beginners when using pdb. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue41607> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41598] rnd() + rndup() in math
Vedran Čačić added the comment: Yes, and these functions are completely fine for your personal library, if you need such things. But they really have no place in math module, since (1) they aren't always correct, (2) it's incredibly difficult to characterize exactly when they are, and (3) even when they are correct, they just give people wrong impression about floats somehow being decimal numbers. If you need to use floats, reconcile yourself with the idea that they don't represent all decimal numbers, not even the ones with just one decimal place, and any algorithm dealing with decimal digits will be just an approximation. If you want the best approximation the humanity can muster, backed with empirical data and theoretical considerations, use the round() builtin. If you want to just have something that works according to your preconceived notions in some cases, while failing mysteriously in others, use your quick-and-dirty implementations. If you want exact decimal results, use the decimal module, and specify the rounding mode as you wish. -- ___ Python tracker <https://bugs.python.org/issue41598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41598] rnd() + rndup() in math
Vedran Čačić added the comment: Yes, we can do better than ms (whatever that means). And we do exactly that in the `decimal` module. Floats are not the right target for your algorithms, because they don't have decimal digits. It's as if you're trying to round words in English language. :-D (In fact, with words you'd probably have better luck, since they _can_ represent decimal numbers exactly.) -- ___ Python tracker <https://bugs.python.org/issue41598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41591] Comprehensions documentation
Vedran Čačić added the comment: On the contrary, I think it would be much more clearer if it focused on the one that was evaluated in the context. So, _inner_ listcomp is... (instead of "nested listcomp is..."). "Main part of outer" is just beating around the bush. But in fact I'm not motivated enough (nor powerful enough) to actually change this on my own. -- ___ Python tracker <https://bugs.python.org/issue41591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41598] rnd() + rndup() in math
Vedran Čačić added the comment: ROUND_HALF_UP is not chosen because it's popular, but because it's the best way to compensate for errors in representing decimal numbers by binary numbers. Thinking that floats are decimal numbers is going to bite you anyway sooner or later. For example, would you expect (with your implementation) rnd(2.8-1.3) == rnd(1.8-1.3) ? -- ___ Python tracker <https://bugs.python.org/issue41598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41591] Comprehensions documentation
Vedran Čačić added the comment: It refers to the sentence """The result will be a new list resulting from evaluating the expression in the context of the for and if clauses which follow it. """ The expression at the start of listcomp is the one that's evaluated in the context of clauses following it, no matter what kind of expression it is. If it is another listcomp, then you have a nested listcomp, but that's just a nonspecial case. -- ___ Python tracker <https://bugs.python.org/issue41591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41591] Comprehensions documentation
Vedran Čačić added the comment: This is not nested listcomp. Nested listcomp is a listcomp inside a listcomp. What you wrote is one listcomp, with two for-clauses. It does "desugar" into a nested loop, but that doesn't make it a nested listcomp. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue41591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41598] rnd() + rndup() in math
Vedran Čačić added the comment: If we want to proceed with this, much better way would be to add a rounding mode optional argument to `round` builtin. But really, anyone trying to precisely round a decimal representation of a binary floating point number is, to paraphrase von Neumann, living in the state of sin. See https://stackoverflow.com/a/51146310/1875565. -- nosy: +veky ___ Python tracker <https://bugs.python.org/issue41598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
