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
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,
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.
O
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
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
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
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, Supports
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.
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", &qu
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.123
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"
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
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'
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 tracke
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/issue39
15 matches
Mail list logo
