Hello!
I want to discuss one feature for handful working with shapes of array-like objects.
If we want to pass arrays to function we can declare their sizes directly with argument declaration:
```
def foo(a[m, n], b[n]):
for i in range(m):
for j in range(n):
a[i, j] = b[j]
```
Will be equivalent to
```
def foo(a, b):
m, n = a.__shape__()
n_b = b.__shape__()
if n_b != n:
raise ShapeNotValidException()
...
```
Objects should implement `__shape__` magic method to use this syntax.
Shapes automatically introduced to variables and checked.
Also we can allow more complex checks, e.g.:
```
def bar(a[2,...]):
...
```
will check that first dimension of passed array equals to 2.
Or:
```
def bar(a[n], b[2*n]):
# checks that a.__shape__()[0] == 2 * b.__shape__()[0]
...
```
Currently there are a few Protocols
https://docs.python.org/3/library/typing.html#protocols defined in the
typing module. One that I recently felt like was missing was a typing
annotation for classes with a __str__() method defined. Seems like a fairly
straightforward implementation.
@runtime_checkable
class SupportsString(Protocol): """An ABC with one abstract method
__str__."""
__slots__ = ()
@abstractmethod
def __str__(self) -> str:
pass
Perhaps there is another way to do this that I am missing?
Hi,
Please pardon me if my idea is not making sense or already exists, I'm kind
of new to developing in Python but I had this idea today and I wanted to
share it with you.
I think a class type such as "@functionclass" may be helpful for creating
functions intended to keep a list of methods in a scope.
At the moment, I achieved this via writing "@classmethod" to all my
functions but I think such a decorator might help clarify intent for the
reader and ease the programmers' job.
My regards,
Alperen
str_iterator, bytes_iterator, range_iterator, list_iterator, and tuple_iterator (and probably others) should have a method that is capable of efficiently advancing the iterator, instead of having to call next repeatedly.
I suggest adding an itertools.advance function which dispatches to a dunder __advance__ method (if one exists) or, as a fallback, calls next repeatedly. Then, the iterators mentioned above (and any others capable of efficiently doing so) would implement __advance__, which would directly manipulate their index to efficiently "jump" the desired number of elements in constant-time rather than linear-time.
For example, if you have a large list and want to iterate over it, but skip the first 50000 elements, you should be able to do something like:
it = iter(mylist)
itertools.advance(it, 50000)
Note that you technically can do this with itertools.islice by supplying a start value, but itertools.islice effectively just repeatedly calls next on your behalf, so if you're skipping a lot of elements, it's unnecessarily slow.
As a side note, I noticed that list_iterator has __setstate__ which can be used to (more or less) accomplish this, but that seems very hack-y. Although it is setting the index directly (rather than adding to it), so it'd be more awkward to use if the iterator is already partially exhausted.
it = iter(mylist)
it.__setstate__(50000)
Hey,
python 3.9 introduced the | operator for union types. it would be nice
to have something like that for optional types. maybe like
name: ? int
or
name: int ?
best regards
Sebastian Lübke
SUMMARY
This post asks for some examples that will improve PEP 637, by providing
examples where the existing language specification is not adequate (but PEP
637 is). The rest of this post should tell you why I want these examples,
and what they should look like.
DISCLAIMER
I'm an editor of PEP 637, writing in my personal capacity. And I'm also the
author of package kwkey mentioned below.
SUMMARY
PEP 637 adds to Python's syntax and semantics. It adds statements such as
>>> x[1, 2, a=3, b=4] = val
to the syntax, and adds new associated semantics.
https://www.python.org/dev/peps/pep-0637/
PEP 1, which defines the PEP process, states that any PEP that changes the
existing language specification should clearly explain "why the existing
language specification is inadequate to address the problem that the PEP
solves".
https://www.python.org/dev/peps/pep-0001/#what-belongs-in-a-successful-pep
As part of addressing this question of existing Python being adequate, I
wrote a new package kwey. This package provides, I believe, a class B such
that
>>> B(1, 2, a=3, b=4)[x] = val
is equivalent to
>>> x[1, 2, a=3, b=4] = val
once PEP 637 is implemented. (And if not, please report a bug, and if you
can provide a patch.)
https://pypi.org/project/kwkey/
GOAL
The current version of PEP 637 doesn't mention kwkey. I'd particularly like
us to look for problems where using kwkey as above is not adequate but PEP
637 is adequate.
Aside. Please treat this as a semantic problem, or in other words assume
that
>>> x[SOMETHING]
>>> f(SOMETHING)
impose the same constraint on a well-formed expression SOMETHING.
Here's why. PEP 637 allows syntax such as
>>> x[1:2, 3:4, a=5:6, b=7:8]
and even after PEP 637 (as it currently is)
>>> f(1:2, 3:4, a=5:6, b=7:8)
is forbidden syntax. But PEP 637 is much more than a syntax extension.
Recall that we already have literal expressions such as
>>> [1, 2, 3] # List literal
>>> (1, 2, 3) # Tuple literal
>>> {1, 2, 3} # Set literal
in Python. If current Python turns out to have adequate semantics, then
perhaps adding
>>> (1:2:3) # Slice literal
might by itself be enough. This is why I want particularly semantics
examples. They're worth more.
CONCLUSION
I'd like to see semantic examples of problems that can be adequately solved
by PEP 637, but not by using kwkey. The PEP process says, in so many words,
that such examples should be provided.
--
Jonathan
Hi all,
I've been working in q and k, which is where this idea comes from.
My idea is to make lists and dicts callable, with __call__ =
__getitem__.
So that:
[3,4,5](1) gives 4
{'a':1, 'b': 2}('b') gives 2
Arguably a list is a function which maps from range(len(list)) to the
list entries, and a dictionary is a function that maps from keys to
values.
This would mean that functions designed to take functions, can be
repurposed to take data, for example:
map(lst, idxs) instead of (lst[i] for i in idxs) or map(lambda x:
lst[x], idxs)
map(dct, lst) instead of (dct[l] for l in lst)
sorted(range(len(lst)), key=lst) to calculate the equivalent of
np.argsort
max(range(len(lst)), key=lst) to calculate the equivalent of np.argmax
I couldn't find this being discussed before. Does anyone like it? There
is room for confusion as it would mean that e.g. filter([1,2], [0,1])
would give [0,1] whilst [1] might be expected.
Best,
George Harding
p.s. Thank you to everyone for their work on such a wonderful language.
Hi, My name is Jonatan and i am programming in Python for about 4 years,
I have a great idea, there are iX` methods, such as __ior__, __iadd__,
__iand__ etc.., which implements the |=, +=, &= behavior,
it would be nice if you could implement also __igetattr__ or something,
which means:
instead of
con = "some text here"
con = con.replace("here", "there")
we could do
con = "some text here"
con .= replace("here", "there")
Please let me know what do you think about it, Jonatan
Hey all, I recently ran into some trouble and that I think deserves some
attention. Consider the following case:
class A(ABC):
@abstractmethod
def __lt__(self, other):
pass
@dataclass(order=True)
class B(A):
x: int = 0
class C(B):
pass
Although B technically implements A's abstract methods, it is still
considered an abstract class, and calling B() will fail. However, C is
considered a non-abstract class and calling C() will succeed. This is
because a class's "abstraction" is decided when a class is created. When B
is created it does not implement __lt__, the implementation is added after
creation by the dataclass decorator. Since C inherits from B after having
its __lt__ set, C is considered non-abstract. This will also affect any
"mixin-decorator" such as total_ordering, and also (a less-preferred use
case) implementing abstract methods after class creation.
There are many solutions for this, my proposed solution is for abc.ABCMeta
to implement a __setattr__, that erases unimplemented metaclasses f they
are implemented after class creation, Something along these lines:
class ABCMeta2(ABCMeta):
def __setattr__(self, key, value):
super().__setattr__(key, value)
if key != '__abstractmethods__' and value is not None:
self.__abstractmethods__ -= {key}
Obviously some additional logic is needed to handle sub-classes and such,
but I think it's a good starting point.
Any thoughts?
