On Sun, May 5, 2019 at 6:42 AM Steven D'Aprano wrote:
> It isn't that I *oppose* moving the checks to class-creation time
> instead of instantiation time, but I'd like to hear more about why it is
> a problem.
This doesn't look like moving checks from one place to another for me.
It is basically
> Another one is that ABCs aren't interfaces at all as they all to have
> actual implementations being encapsulated in them. This causes
> misunderstandings of the code and strange behaviors like in
> `collection.abc` module for instance where there is a lot of
> implementation and some methods
On Sun, May 5, 2019 at 6:42 AM Steven D'Aprano wrote:
>
> On Sun, May 05, 2019 at 04:23:58AM +0300, Serge Matveenko wrote:
> > So, I would like to propose adding a third main object called
> > `interface` in addition to `object` and `type` and to use it to define
> > interface objects. Such
On Sun, May 5, 2019 at 6:40 AM Ryan Gonzalez wrote:
>
> Worth maybe noting that this could play interestingly with PEP 484?
You're right. It already plays along with type hints in different
ways. At the moment it requires an exact match of implementation
method signatures with the interface
On Sun, May 05, 2019 at 04:23:58AM +0300, Serge Matveenko wrote:
> Hi, all!
>
> I believe, almost everybody is familiar with the `abc` package.
>
> The problem is that the ABC class is not a separate thing from
> `object`. So, using ABCs often results in complicated inheritance
> designs and
Worth maybe noting that this could play interestingly with PEP 484?
--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/
On May 4, 2019, 8:24 PM -0500, Serge Matveenko , wrote:
> Hi, all!
>
> I believe, almost everybody is familiar with the
Hi, all!
I believe, almost everybody is familiar with the `abc` package.
The problem is that the ABC class is not a separate thing from
`object`. So, using ABCs often results in complicated inheritance
designs and even in the infamous metaclass conflict.
Another problem is that ABC performs
On Sun, May 05, 2019 at 02:34:27AM +0800, Ronie Martinez wrote:
> It does not interfere with modulo operator as modulo follows a different
> format:
> ```
> a = x % y
> ```
Alas, that's not correct, because + and - are both unary operators as
well as binary operators, so this:
x % + y
is
I don't have any specific knowledge about this, but it probably has not
been done because it could easily cause some subtle bugs that aren't
immediately obvious, and the benefits aren't that great in comparison to
just using the format specification language to produce % representation.
Consider,
Hi Ronie
There's a problem with using % as you suggest. What's the meaning and thus
value of
>>> 300%+57
At present it's 15. You would have it equal to 60.
You motivation is good, but the solution you've proposed might not work. By
the way, Python does care about readability of numeric
Good day!
As Python focuses on readability, why not use % sign for actual percentages?
For example:
```
rate = 0.1058 # float
rate = 10.58% # percent, similar to above
```
It does not interfere with modulo operator as modulo follows a different
format:
```
a = x % y
```
This looks like a
Currently str.format() and f-strings support three converters.
Converting is specified by the "!" character followed by a letter which
denotes the converter.
s: str()
r: repr()
a: ascii()
In some cases it would be useful to apply other converters. One obvious
example is escaping special
12 matches
Mail list logo
