[issue1738] filecmp.dircmp does exact match only
Michael Amrhein <[EMAIL PROTECTED]> added the comment: I've implemented an enhanced version of this feature by adding a keyword 'match' to the constructor of class 'dircmp'. It defaults to function 'fnmatch' imported from module 'fnmatch'. This allows to exclude directories and/or files by using patterns like '*.tmp'. By giving a different function it's also possible to use more elaborated patterns, for example, based on regular expressions. Attached patch includes updates of documentation and test cases. -- nosy: +mamrhein versions: +Python 2.6 Added file: http://bugs.python.org/file10005/wildcard.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1738> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1738] filecmp.dircmp does exact match only
Michael Amrhein <[EMAIL PROTECTED]> added the comment: Ok, I've set default arguments (back) to None. Revised patch attached. Defaulting the match function to fnmatch doesn't change the behavior in the "normal" case, i.e. when regular file / directory names are used, like in the default value of ignore. It behaves different in two cases: a) A string given in ignore contains wildcard character(s): In this case this parameter would have no effect in the previous implementation, because the string would not match any file / directory name exactly. In the changed implementation all files / directories matching the pattern would be ignored. If the wildcard(s) were included by intent, this is what probably was intended; if they were included by mistake, both version do not behave as intended. b) File system is case-insensitive: In this case the changed implementation will ignore files / directories which the previous version did not ignore because of a case mismatch. But, on such a file system this is what one would normally expect, I think. So, in both cases, I feel the changed behavior is acceptable. Or did I miss something? Added file: http://bugs.python.org/file10008/add_match_func.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1738> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1738] filecmp.dircmp does exact match only
Michael Amrhein <[EMAIL PROTECTED]> added the comment: > Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: ... > > '*' is a perfectly legal filename character on most filesystems > Oops! Never thought of putting a '*' into a file name. Obviously, I should have tried before ... Ok, then I agree that, for not breaking existing code, the match function should default to string comparison. I'll provide a second revised patch in the next days. And, I'll chain ignore and hide, as you proposed. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1738> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1738] filecmp.dircmp does exact match only
Michael Amrhein <[EMAIL PROTECTED]> added the comment: There is one small issue I would like to discuss: While the comparison of directory and file names in phase1 is case-insensitive on case-insensitive systems (os.path.normcase applied to each name), the filtering of ignore and hide in phase0 isn't. I can't imagine a good reason for this and would like to change it by also applying os.name.normcase to each name in ignore and hide. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1738> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1738] filecmp.dircmp does exact match only
Michael Amrhein <[EMAIL PROTECTED]> added the comment: Here's a 2nd revised patch, which * adds a keyword 'match' to the constructor of class 'dircmp' * defaults 'match' to str.__eq__ * modifies method 'phase0': apply os.name.normcase to each name in ignore and hide * modifies the docs accordingly, incl. an example for using pattern matching * modifies the test case for the default matching * adds a test case for using pattern matching (fnmatch.fnmatch) Added file: http://bugs.python.org/file10078/add_match_func.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1738> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44547] fraction.Fraction does not implement __int__.
New submission from Michael Amrhein : While int, float, complex and Decimal implement __int__, Fraction does not. Thus, checking for typing.SupportsInt for fractions fails, although int() succeeds, because Fraction implements __trunc__. This looks inconsistent. Easiest fix seems to be: Fraction.__int__ = Fraction.__trunc__ -- components: Library (Lib) messages: 396827 nosy: mamrhein priority: normal severity: normal status: open title: fraction.Fraction does not implement __int__. type: behavior versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44547] fraction.Fraction does not implement __int__.
Michael Amrhein added the comment: The background is an implementation of __pow__ for a fixed-point decimal number: SupportsIntOrFloat = Union[SupportsInt, SupportsFloat] def __pow__(self, other: SupportsIntOrFloat, mod: Any = None) -> Complex: if isinstance(other, SupportsInt): exp = int(other) if exp == other: ... handle integer exponent if isinstance(other, SupportsFloat): # fractional exponent => fallback to float return float(self) ** float(other) return NotImplemented I came across SupportsInt and SupportsFloat, because they are used in typeshed as param types for int and float. -- ___ Python tracker <https://bugs.python.org/issue44547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39077] Numeric formatting inconsistent between int, float and Decimal
New submission from Michael Amrhein : The __format__ methods of int, float and Decimal (C and Python implementation) do not interpret the Format Specification Mini-Language in the same way: >>> import decimal as cdec ... cdec.__file__ ... '/usr/lib64/python3.6/decimal.py' >>> import _pydecimal as pydec ... pydec.__file__ ... '/usr/lib64/python3.6/_pydecimal.py' >>> i = -1234567890 ... f = float(i) ... d = cdec.Decimal(i) ... p = pydec.Decimal(i) ... >>> # Case 1: no fill, no align, no zeropad ... fmt = "28," >>> format(i, fmt) ' -1,234,567,890' >>> format(f, fmt) '-1,234,567,890.0' >>> format(d, fmt) ' -1,234,567,890' >>> format(p, fmt) ' -1,234,567,890' >>> # Case 2: no fill, no align, but zeropad ... fmt = "028," >>> format(i, fmt) '-000,000,000,001,234,567,890' >>> format(f, fmt) '-0,000,000,001,234,567,890.0' >>> format(d, fmt) '-000,000,000,001,234,567,890' >>> format(p, fmt) '-000,000,000,001,234,567,890' >>> # Case 3: no fill, but align '>' + zeropad ... fmt = ">028," >>> format(i, fmt) '00-1,234,567,890' >>> format(f, fmt) '-1,234,567,890.0' >>> format(d, fmt) ValueError: invalid format string >>> format(p, fmt) ValueError: Alignment conflicts with '0' in format specifier: >028, >>> # Case 4: no fill, but align '=' + zeropad ... fmt = "=028," >>> format(i, fmt) '-000,000,000,001,234,567,890' >>> format(f, fmt) '-0,000,000,001,234,567,890.0' >>> format(d, fmt) ValueError: invalid format string >>> format(p, fmt) ValueError: Alignment conflicts with '0' in format specifier: =028, >>> # Case 5: fill '0', align '=' + zeropad ... fmt = "0=028," >>> format(i, fmt) '-000,000,000,001,234,567,890' >>> format(f, fmt) '-0,000,000,001,234,567,890.0' >>> format(d, fmt) ValueError: invalid format string >>> format(p, fmt) ValueError: Fill character conflicts with '0' in format specifier: 0=028, >>> # Case 6: fill ' ', align '=' + zeropad ... fmt = " =028," >>> format(i, fmt) '- 1,234,567,890' >>> format(f, fmt) '-1,234,567,890.0' >>> format(d, fmt) ValueError: invalid format string >>> format(p, fmt) ValueError: Fill character conflicts with '0' in format specifier: =028, >>> # Case 7: fill ' ', align '>' + zeropad ... fmt = " >028," >>> format(i, fmt) ' -1,234,567,890' >>> format(f, fmt) '-1,234,567,890.0' >>> format(d, fmt) ValueError: invalid format string >>> format(p, fmt) ValueError: Fill character conflicts with '0' in format specifier: >028, >>> # Case 8: fill ' ', no align, but zeropad ... fmt = " 028," >>> format(i, fmt) '-000,000,000,001,234,567,890' >>> format(f, fmt) '-0,000,000,001,234,567,890.0' >>> format(d, fmt) '-000,000,000,001,234,567,890' >>> format(p, fmt) '-000,000,000,001,234,567,890' >>> # Case 9: fill '_', no align, but zeropad ... fmt = "_028," >>> format(i, fmt) ValueError: Invalid format specifier >>> format(f, fmt) ValueError: Invalid format specifier >>> format(d, fmt) ValueError: invalid format string >>> format(p, fmt) ValueError: Invalid format specifier: _028, >>> # Case 10: fill '_', no align, no zeropad ... fmt = "_28," >>> format(i, fmt) ValueError: Invalid format specifier >>> format(f, fmt) ValueError: Invalid format specifier >>> format(d, fmt) ValueError: Invalid format string >>> format(p, fmt) ValueError: Invalid format specifier: _28, >>> # Case 11: fill '0', align '>', no zeropad ... fmt = "0>28," >>> format(i, fmt) '00-1,234,567,890' >>> format(f, fmt) '-1,234,567,890.0' >>> format(d, fmt) '00-1,234,567,890' >>> format(p, fmt) '00-1,234,567,890' >>> # Case 12: fill '0', align '<', no zeropad ... fmt = "0<28," >>> format(i, fmt) '-1,234,567,89000' >>> format(f, fmt) '-1,234,567,890.000
[issue39077] Numeric formatting inconsistent between int, float and Decimal
Michael Amrhein added the comment:
Mark, I mostly agree with your classifications / proposals.
Regarding cases 3-7 I'd like to suggest a slightly different resolution:
Following my interpretation of the spec ("use zeropad *only* if no align is
given"), "<020", ">020", "^020" and "=020" would be treated equivalent to
"<20", ">20", "^20" and "=20":
format(12345, "<020") -> '-12345 ', not '-1234500'
format(12345, ">020") -> ' -12345', not '00-12345'
format(12345, "^020") -> ' -12345 ', not '000-12345000'
format(12345, "=020") -> '- 12345', not '-0012345'
For '<', '>' and '^' I can't imagine any code depending on the current
behaviour of int and float, so this change is unlikely to break anything.
For '=' it might be reasonable to make an exception (and state it in the doc),
so that "020", "=020", "0=020" and "0=20" are treated as equivalent.
For Decimal this would mean to loosen the behaviour, as you proposed.
--
___
Python tracker
<https://bugs.python.org/issue39077>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39077] Numeric formatting inconsistent between int, float and Decimal
Michael Amrhein added the comment:
Mark, to answer your question regarding the two implementations of Decimals:
No, in the cases I stated above there are no differences in their behaviour.
In order to dig a bit deeper, I wrote a little test:
d = cdec.Decimal("1234567890.1234")
p = pydec.Decimal("1234567890.1234")
for fill in ('', ' ', '_'):
for align in ('', '<', '>', '^', '='):
for sign in ('', '-', '+', ' '):
for zeropad in ('', '0'):
for min_width in ('', '25'):
for thousands_sep in ('', ','):
for precision in ('', '.3', '.5'):
for ftype in ('', 'e', 'f', 'g'):
fmt =
f"{fill}{align}{sign}{zeropad}{min_width}{thousands_sep}{precision}{ftype}"
try:
df = format(d, fmt)
except ValueError:
df = ""
try:
pf = format(p, fmt)
except ValueError:
pf = ""
if df != pf:
print(fmt, df, pf)
It did not reveal any differences. The two implementations are equivalent
regarding the tested combinations.
--
___
Python tracker
<https://bugs.python.org/issue39077>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39077] Numeric formatting inconsistent between int, float and Decimal
Michael Amrhein added the comment:
>
> ... Has anyone checked what C does?
>
#include
int main() {
int i = -12345;
double f = -12345.0;
printf("%-020d\n", i);
printf("%020d\n", i);
printf("%20d\n", i);
printf("%-020f\n", f);
printf("%020f\n", f);
printf("%20f\n", f);
return 0;
}
Output:
-12345
-0012345
-12345
-12345.00
-00012345.00
-12345.00
https://en.cppreference.com/w/c/io/fprintf:
Each conversion specification has the following format:
introductory % character
(optional) one or more flags that modify the behavior of the conversion:
-: the result of the conversion is left-justified within the field (by
default it is right-justified)
+: the sign of signed conversions is always prepended to the result of the
conversion (by default the result is preceded by minus only when it is negative)
space: if the result of a signed conversion does not start with a sign
character, or is empty, space is prepended to the result. It is ignored if +
flag is present.
# : alternative form of the conversion is performed. See the table below
for exact effects otherwise the behavior is undefined.
0 : for integer and floating point number conversions, leading zeros are
used to pad the field instead of space characters. For integer numbers it is
ignored if the precision is explicitly specified. For other conversions using
this flag results in undefined behavior. It is ignored if - flag is present.
Last sentence means that zero-padding is only done when the output is
right-aligned. I can't find an equivalent for Pythons '=' align option.
--
___
Python tracker
<https://bugs.python.org/issue39077>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39077] Numeric formatting inconsistent between int, float and Decimal
Michael Amrhein added the comment: Mark, Eric, sometimes the pressure to be backwards compatible is more of a curse than a blessing. But I can live with your decision. And, yes, I will create two separate issues regarding the docs. -- ___ Python tracker <https://bugs.python.org/issue39077> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39096] Description of "Format Specification Mini-Language" not accurate for Decimal
New submission from Michael Amrhein : The description of the "Format Specification Mini-Language" states for float and Decimal regarding presentation type 'f': "The default precision is 6." Regarding presentation type None it reads: "Similar to 'g', except that fixed-point notation, when used, has at least one digit past the decimal point." While both statements are accurate for float, they don't hold for Decimal. In order to preserve the information about the decimal exponent, in both cases Decimal formatting displays as many fractional digits as dictated by it's exponent. -- assignee: docs@python components: Documentation messages: 358667 nosy: docs@python, mamrhein priority: normal severity: normal status: open title: Description of "Format Specification Mini-Language" not accurate for Decimal type: behavior versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39096> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39077] Numeric formatting inconsistent between int, float and Decimal
Michael Amrhein added the comment: Created new issue for tracking the deficiencies in the documentation: https://bugs.python.org/issue39096. -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue39077> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39096] Description of "Format Specification Mini-Language" not accurate for Decimal
Michael Amrhein added the comment: For a discussion of the different behaviour of float and Decimal see https://bugs.python.org/issue39077. -- ___ Python tracker <https://bugs.python.org/issue39096> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
