date:20201006

I have no idea if this is a good idea, but Python already has modules to be
namespaces for a collection of functions and values.

And while a class decorator is *supposed* to return a class, it can, in
fact, return anything. So you can make a decorator that converts a class
definition to a module object:

In [47]: def make_mod(cls):
...: mod = imp.new_module(cls.__name__)
...: for name, attr in vars(cls).items():
...: if not name.startswith("_"):
...: setattr(mod, name, attr)
...: return mod
...:

In [48]: @make_mod
...: class Fake:
...: an_attribute = "this"
...: def a_function(a,b):
...: print("a_function:", a, b)
...:

In [49]: Fake.an_attribute
Out[49]: 'this'

In [50]: Fake.a_function(3, 4)
a_function: 3 4

In [51]: type(Fake)
Out[51]: module

In [52]: vars(Fake)
Out[52]:
{'__name__': 'Fake',
 '__doc__': None,
 '__package__': None,
 '__loader__': None,
 '__spec__': None,
 'an_attribute': 'this',
 'a_function': }

I expect this will give your functions a very odd globals()  though ;-)

But this made me think -- we already have modules, so if we do want a
"namespace" type of some sort, why not simply have syntax for making a
module inline:

new_module:
def this():
pass
x = 4

It would be kind of nice to be able to make anew module without having to
have an actual file (or fake one)

-CHB





-CHB








On Tue, Oct 6, 2020 at 11:02 PM Greg Ewing 
wrote:

> On 7/10/20 2:45 pm, Random832 wrote:
> > I think the feature should allow for the functions to directly access
> > each other from the namespace's scope without requiring an attribute
> > lookup.
>
> That got me thinking, and I came up with this:
>
> def submodule(f):
>return type(f.__name__, (), f())
>
> @submodule
> def Stuff():
>
>def f1():
>  print("First function")
>  f2()
>
>def f2():
>  print("Second function")
>
>return locals()
>
> Stuff.f1()
>
> The only ugly part is the need for the 'return locals()', but that could
> probably be alleviated with a bit of bytecode hacking.
>
> --
> Greg
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/KCUWQDLCNUHAP47DR7L3AJPBPI6H64LM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CAV5DQHBWRFMVCHZI2CFLR5BDUMUXOYC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: CPP Namespaces For Python

2020-10-06 Thread Greg Ewing


On 7/10/20 2:45 pm, Random832 wrote:

I think the feature should allow for the functions to directly access
each other from the namespace's scope without requiring an attribute
lookup.


That got me thinking, and I came up with this:

def submodule(f):
  return type(f.__name__, (), f())

@submodule
def Stuff():

  def f1():
print("First function")
f2()

  def f2():
print("Second function")

  return locals()

Stuff.f1()

The only ugly part is the need for the 'return locals()', but that could
probably be alleviated with a bit of bytecode hacking.

--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KCUWQDLCNUHAP47DR7L3AJPBPI6H64LM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: CPP Namespaces For Python

2020-10-06 Thread Marco Sulla

On Tue, 6 Oct 2020 at 15:33, Alperen Keleş  wrote:
> Cars have different states, MovingCar, IdleCar, ParkingCar...

Well, IMHO the solution is quite more simple:

class Car:
def __init__(self):
self.state = "parking"

def move(self):
if self.state != "moving":
raise StateException("car can't move!")

[...]
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5P2WVGDX6HFUY2JMKJZ7OQP5YGJ5F6PL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Method to efficiently advance iterators for sequences that support random access

On Tue, Oct 6, 2020 at 18:16 Steven D'Aprano  wrote:

> For `__advance__` to be an official Python protocol, it would almost
> certainly have to be of use for *general purpose iterators*, not just
> specialised ones -- and probably not *hypothetical* iterators which may
> not even exist. Do you have concrete examples of your skip list and tree
> iterators that are in wide-spread use?


Yeah, I’m still waiting for the real use case to be revealed. (There my
well be one.)

Specialised iterators can create whatever extra APIs they want to
> support, but the official iterator protocol intentionally has a very
> basic API:
>
> - anything with an `__iter__` method which returns itself;
> - and a `__next__` method that returns the next value, raising
>   StopIteration when exhausted.
>
> This is a bare minimum needed to make an iterator, and we like it that
> way. For starters, it means that generators are iterators.


There’s a precedent though, __length_hint__ (PEP 424).

The OP anticipated this, with “[a] function which dispatches to a dunder
__advance__ method (if one exists) or, as a fallback, calls next
repeatedly.” Clearly the function would be on a par with len() and next().

So it would be optional to implement but the operation would be available
for all iterators (even generators).

If people want to supply objects that support the iterator protocol

but also offer a rich API including:
>
> - peek
> - restart
> - previous
> - jump ahead (advance)
>
> all features that have been proposed, there is nothing stopping you from
> adding those features to your iterator classes. But they all have
> problems if considered to be necessary for *all* iterators.


Strawman, since all except advance() would require some kind of buffering
to build them out of the basics.

I would expect that, given a sufficiently compelling real-world
> use-case, we would be prepared to add a jump ahead method to
> list-iterators, as a specific feature of that iterator, not of all
> iterators.


But the advance() function could support all iterators using the OP’s
fallback.

—Guido
-- 
--Guido (mobile)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4VOHC5TZFDWSQ3GESAJN5KCDN5XAOEQ4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: CPP Namespaces For Python

2020-10-06 Thread Greg Ewing


In Python 3 you can do this without any decorators.
The following works and produces the same output:

class AA:
  def greet(A_instance):
 print("Hello", A_instance.name)

class BB:
  def greet(A_instance):
print("Hi", A_instance.name)

class A:
  def __init__(self, state, name):
self.state = state
self.name = name
  def greet(self):
self.state.greet(self)
  def switchAA(self):
self.state = AA
  def switchBB(self):
self.state = BB

if __name__ == "__main__":
  obj = A(AA, "alperen")
  obj.greet()
  obj.switchBB()
  obj.greet()

--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GL5ULTVXNAT5PWL5YMBH4LGQMIXJHMMQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Method to efficiently advance iterators for sequences that support random access

On Tue, Oct 6, 2020 at 6:16 PM Steven D'Aprano  wrote:

> > My ladder two examples demonstrate that this could have utility outside
> of
> > sequences but for iterators in general.
>
> I'm sorry, I don't know what your ladder two examples are. Did you post
> them in another thread?
>

I think that was an auto-correct for "latter" two examples, i.e. the last
two he gave.

-CHB



-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WNMEMBC2YZJEI2CO4TJAZSZGIEOYF6UF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: CPP Namespaces For Python

On Tue, Oct 6, 2020 at 6:47 PM Random832  wrote:

> On Tue, Oct 6, 2020, at 02:50, Alperen Keleş wrote:
> > 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.
>
> I think new syntax would be better than a decorator (or a metaclass, which
> for some reason never seems to get suggested for these things), because I
> think the feature should allow for the functions to directly access each
> other from the namespace's scope without requiring an attribute lookup.
>

A. New syntax is way too high a bar for a questionable feature. Classes
full of static or class methods were a pattern at my last employer and it
was unpleasant to work with. (Others at the company agreed but it was too
late to change.)

B. At some point we realized that metaclasses have too much power over
subclasses (action at a distance) and we switched to recommending class
decorators. Another problem with metaclasses is that it's a pain to combine
two different metaclasses.

> namespace Foo:
> x=1
> def bar():
> pass
> def baz()
> return bar() + x
>

That could be done with a function and a function decorator. "Proof left as
an exercise for the reader." :-)

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ILN7PSZ3WLZ2RLP3BIQCD2LK46ZLOGSR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: SupportsString Protocol Type Annotation

On Tue, Oct 6, 2020 at 6:50 PM Ricky Teachey  wrote:

> On Tue, Oct 6, 2020 at 9:35 PM Steven D'Aprano 
> wrote:
>
>> On Tue, Oct 06, 2020 at 09:30:06AM -0700, aleksiy123 wrote:
>> > 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.
>>
>

> Why do you care specifically about the `__str__` dunder? Calling str()
>> is one of those protocols that should always succeed, whether the
>> argument defines `__str__`, `__repr__`, or inherits from object.
>>
>> Ignoring the possibility of bugs or deliberate raising, I can't think of
>> any object that doesn't support the str() protocol. Have I missed
>> anything?
>
>

> I was also finding this desire a little puzzling (and thought it might
> just be my inexperience).
>
> And since both `type` and `object` have a __str__ method*, it seems like
> the only way any object could NOT support the str() protocol would be to
> write a __str__ method and deliberately bust it. Right?  Is there even a
> way to create a python object that does not have `__str__` in the MRO?
>
> Seeing as that is the case, and seeing as how the protocol system can't
> look inside your __str__ method to find out whether it is busted at type
> checking time, isn't `Any` all you'll ever need to type-hint the __str__
> protocol?
>
> * and upon checking in fact it is the same __str__ method
>

There's somewhat a precedent -- though it's a questionable one (Luciano
discovered this). It shows how tricky these things are though.

There's a `typing.SupportsFoat` protocol that checks for the presence of a
`__float__` method, and a `typing.SupportsComplex` protocol that checks for
`__complex__`. Ironically, complex numbers have a `__float__` method that
always fails, and floats don't have a `__complex__` method but complex(x)
succeeds if x is a float...

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3DBFHEHNV73YGM3X23EP3QARXD2MWMIA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 637 - problems not solved by existing language

On Wed, Oct 7, 2020 at 1:46 PM Steven D'Aprano  wrote:
> > Recall that we already have literal expressions such as
> > >>> [1, 2, 3] # List literal
> > >>> (1, 2, 3) # Tuple literal
> > >>> {1, 2, 3} # Set literal
>
> Point of terminology: these are not literals (although informally people
> often call them that, including me on occassion). They are *displays*.
>
> One difference between a display and a literal can be seen from the
> byte-code generated:
>
> >>> import dis
> >>> dis.dis(compile('[1,2,3]', '', 'single'))
>   1   0 LOAD_CONST   0 (1)
>   2 LOAD_CONST   1 (2)
>   4 LOAD_CONST   2 (3)
>   6 BUILD_LIST   3
>   8 PRINT_EXPR
>  10 LOAD_CONST   3 (None)
>  12 RETURN_VALUE
>
> The constants 1, 2 and 3 are literals and the compiler can insert them
> directly into the code. The list [1, 2, 3] is not, the compiler has to
> insert code to create the list at runtime.
>

Be careful with this, as it's only a one-way proof. Any literal can
and will be inserted directly as a constant, but there are some
non-literals that can be as well:

>>> dis.dis(lambda x: x in {1, 2+3j, r"a\b"})
  1   0 LOAD_FAST0 (x)
  2 LOAD_CONST   1 (frozenset({1, (2+3j), 'a\\b'}))
  4 CONTAINS_OP  0
  6 RETURN_VALUE

Complex numbers and frozen sets don't technically have literals, but
thanks to compiler magic, they can appear to. (Also, raw string
literals are a thing, but in the compiled code, what you get is just a
string object, further confusing this type of proof.)

Although when it comes to f-strings, I honestly don't know what counts
as a "literal". Is a single f-string a literal? What if two of them
abut - are they one literal or two? The compiler builds the code to do
the formatting and joining as though the parts of the string were
combined (even if they're not all f-strings).

But hey, it wouldn't be python-ideas without pedantry :)

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JLFOCS4X4QM3WAS5DFIRZSVJLXEIOXIZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 637 - problems not solved by existing language

On Tue, Oct 06, 2020 at 04:04:37PM +0100, Jonathan Fine wrote:

> 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".

I believe that the PEP meets that requirement by showing the inelegant 
workarounds used by popular projects in the absence subscript keywords.

PEP 1 doesn't require a PEP to show that the existing language is 
*incapable* of solving the problem. Python is Turing Complete, so it can 
solve any computable problem. There are Turing Complete languages with 
as few as two symbols:

https://esolangs.org/wiki/Jot

so in a sense everything is syntactic sugar. The PEP, in my opinion, 
satisfactorily demonstrates that the existing methods of getting the 
semantics of subscript keywords are awkward and ugly.

> 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/

Having to write something like `B(1, 2, a=3, b=4)[x]` would be an 
example of the awkwardness and inelegance that PEP 637 is designed to 
solve. If your kwkey package was a widely-known, commonly used 
third-party library, it would be a fantastic example of the sort of 
work-around that people fall back on in the absense of keyword 
subscripts.

But I don't think that kwkey is widely used. It is a contrived library 
created in response to this issue being raised on the Python-Ideas 
mailing list, and as such, it would be a very weak example.

A single widely-used example, such as from pandas or xarray, is worth a 
dozen contrived examples.

So I'm not really sure what purpose you see your kwkey library taking in 
this PEP. As I mentioned in a previous post, I cannot tell whether you 
see it as competing with this PEP, complementary to the PEP, or perhaps 
as justifying the PEP?

> 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.

But they don't.

`f()` is legal; `f[]` is not, and will remain not legal.

In addition, the precedences are different. In `f(a,b)` the use of the 
comma to separate arguments take precedence over the use of the comma to 
create tuples. But in `f[a,b]` it is the other way around.

> 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.

Adding slice literals is a separate, unrelated issue. Allowing slice 
syntax `start:stop:step` outside of subscripts is independent and 
orthogonal to this PEP. Please don't burden this PEP with it.

> Recall that we already have literal expressions such as
> >>> [1, 2, 3] # List literal
> >>> (1, 2, 3) # Tuple literal
> >>> {1, 2, 3} # Set literal

Point of terminology: these are not literals (although informally people 
often call them that, including me on occassion). They are *displays*.

One difference between a display and a literal can be seen from the 
byte-code generated:

>>> import dis
>>> dis.dis(compile('[1,2,3]', '', 'single'))
  1   0 LOAD_CONST   0 (1)
  2 LOAD_CONST   1 (2)
  4 LOAD_CONST   2 (3)
  6 BUILD_LIST   3
  8 PRINT_EXPR
 10 LOAD_CONST   3 (None)
 12 RETURN_VALUE

The constants 1, 2 and 3 are literals and the compiler can insert them 
directly into the code. The list [1, 2, 3] is not, the compiler has to 
insert code to create the list at runtime.

> 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.

Adding slice literals isn't enough. I believe that the PEP already 
discusses that we cannot write:

f(spam=1) = 2
del f(spam=1)

and this is a fundamental difference between a subscript and a function 
call.

Of course Python is Turing Complete and we can always perform the same 
operation by creating proxies and wrappers and other levels of 
indirection. As they say, every problem can be solved by adding 
suffi

[Python-ideas] Re: CPP Namespaces For Python

2020-10-06 Thread Ricky Teachey

On Tue, Oct 6, 2020 at 9:49 PM Random832  wrote:

> On Tue, Oct 6, 2020, at 02:50, Alperen Keleş wrote:
> > 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.
>
> I think new syntax would be better than a decorator (or a metaclass, which
> for some reason never seems to get suggested for these things),


I think maybe discussion of the general namespace idea might be a little
off topic for this read (per Guido's comments).

However the metaclass below-- or something like it-- could still help with
the problem? It was actually my attempt at a general namespace object in
the previous namespace thread. It seemed to work ok, and it should work in
this use case:

import types

class namespace(type):
def __new__(mcls, name, bases, dct):
if bases:
raise TypeError("this is a namespace, not a class.")
mod = types.ModuleType(dct.pop("__qualname__"), dct.pop("__doc__",None))
mod.__dict__.update(dct)
return mod

class ns(metaclass=namespace):
class Desc:
def __get__(self, obj, cls):
return None
d = Desc()


if __name__=="__main__":
assert ns.d # success: descriptor protocol broken as expected


But there are probably deficiencies I have not uncovered.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4OVMEZM5DQCKJUPMNNJQ7RMNBLFAPSAP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 637 - problems not solved by existing language

Jonathan,

It sounds like you want to propose a competing PEP that provides your
kwkey as a built-in as an alternative to PEP 637.

I encourage you to do so, although I have no interest in acting as
sponsor, and I fear that your window of opportunity to write a competing
PEP is small.

Alternatively, you could write a PEP that proposes a new kwkey object as
complementary to, not competing with, PEP 637. That would provide a
"kwkey" builtin similar to slice(), and people can explicitly opt-in to
using it:

# plan old PEP 637 semantics
obj[spam, eggs, cheese='cheddar', aardvark=True]

# explicit use of kwkey
obj[kwkey(spam, eggs, cheese='cheddar', aardvark=True)]

Another possibility is that you are not advocating for subscript
keywords, and you prefer the status quo. (Your kwkey project counts as
the status quo. It involves no new syntax or language features. Anyone
can write their own kwkey class, or install a third-party library to use
it.) Perhaps you agreed to co-author PEP 637 to have it rejected once
and for all, not accepted, and you think that the current PEP is not
neutral enough and advocates too strongly for the feature.

PEPs can, and often are, written to be rejected. The PEP then becomes
the canonical record of why the feature has been rejected. It is
unfortunate if you and Stefano had radically opposite reasons for
writing the PEP, but I think that's something the two of you should sort
out and find some middle ground.

Unfortunately Jonathan, I cannot tell from your post what your purpose
is. I cannot tell if you oppose or support PEP 637, whether you want to
propose a competing PEP, a complementary PEP, or just want to get credit
for your kwkey project by having it mentioned in the PEP, or what
exactly you want.

I will comment further on the details in your post in another
message.

--
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/ZXH2W6K7AYKCSGIPXUOBLATLHS2MYLZR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: SupportsString Protocol Type Annotation

2020-10-06 Thread Ricky Teachey

On Tue, Oct 6, 2020 at 9:35 PM Steven D'Aprano  wrote:

> On Tue, Oct 06, 2020 at 09:30:06AM -0700, aleksiy123 wrote:
> > 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.
>
>
> Why do you care specifically about the `__str__` dunder? Calling str()
> is one of those protocols that should always succeed, whether the
> argument defines `__str__`, `__repr__`, or inherits from object.
>
> Ignoring the possibility of bugs or deliberate raising, I can't think of
> any object that doesn't support the str() protocol. Have I missed
> anything?
>
>
>
> --
> Steve
>

I was also finding this desire a little puzzling (and thought it might just
be my inexperience).

And since both `type` and `object` have a __str__ method*, it seems like
the only way any object could NOT support the str() protocol would be to
write a __str__ method and deliberately bust it. Right?  Is there even a
way to create a python object that does not have `__str__` in the MRO?

Seeing as that is the case, and seeing as how the protocol system can't
look inside your __str__ method to find out whether it is busted at type
checking time, isn't `Any` all you'll ever need to type-hint the __str__
protocol?

* and upon checking in fact it is the same __str__ method

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/MLEETQUEF6IND4NXFXL4OGBQN4NYWOMR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: CPP Namespaces For Python

2020-10-06 Thread Random832

On Tue, Oct 6, 2020, at 02:50, Alperen Keleş wrote:
> 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.

I think new syntax would be better than a decorator (or a metaclass, which for 
some reason never seems to get suggested for these things), because I think the 
feature should allow for the functions to directly access each other from the 
namespace's scope without requiring an attribute lookup.

namespace Foo:
x=1
def bar():
pass
def baz()
return bar() + x
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4QP77RRSTAGHBRHFNSEIKY4HL3B7CJXK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: SupportsString Protocol Type Annotation

On Tue, Oct 06, 2020 at 09:30:06AM -0700, aleksiy123 wrote:
> 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.

Why do you care specifically about the `__str__` dunder? Calling str() 
is one of those protocols that should always succeed, whether the 
argument defines `__str__`, `__repr__`, or inherits from object.

Ignoring the possibility of bugs or deliberate raising, I can't think of 
any object that doesn't support the str() protocol. Have I missed 
anything?

-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JQHO2EQ562RLV22ARWTLTRHZ6X7W4HPW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Method to efficiently advance iterators for sequences that support random access

On Tue, Oct 06, 2020 at 02:27:54PM -0700, Caleb Donovick wrote:
> I am +0.3 on this as I don't personally have a need for this but do see the
> utility.
> 
> I can think of a number of examples where an `__advance__` would be
> preferable to any of the proposed solutions:
[...]

For `__advance__` to be an official Python protocol, it would almost 
certainly have to be of use for *general purpose iterators*, not just 
specialised ones -- and probably not *hypothetical* iterators which may 
not even exist. Do you have concrete examples of your skip list and tree 
iterators that are in wide-spread use?

Specialised iterators can create whatever extra APIs they want to 
support, but the official iterator protocol intentionally has a very 
basic API:

- anything with an `__iter__` method which returns itself;
- and a `__next__` method that returns the next value, raising 
  StopIteration when exhausted.

This is a bare minimum needed to make an iterator, and we like it that 
way. For starters, it means that generators are iterators.

If people want to supply objects that support the iterator protocol 
but also offer a rich API including:

- peek
- restart
- previous
- jump ahead (advance)

all features that have been proposed, there is nothing stopping you from 
adding those features to your iterator classes. But they all have 
problems if considered to be necessary for *all* iterators.

I would expect that, given a sufficiently compelling real-world 
use-case, we would be prepared to add a jump ahead method to 
list-iterators, as a specific feature of that iterator, not of all 
iterators.

> A skip list which doesn't support O(1) random access but can advance faster
> than naively calling next repeatedly
> A lazy infinite iterator which can efficiently calculate its state at some
> future point  (e.g. `itertools.count`)

What's your use case for advancing a count object, rather than just 
creating a new one?

it = itertools.count()  # start at 0
process(it)  # process some values
it.advance(state)  # jump forward
process(it)  # process some more values

as opposed to what is already possible:

it = itertools.count()
process(it)
it = itertools.count(state)
process(it)

Real-world use-cases for this feature are far more useful than contrived 
and artifical use-cases unlikely to ever occur in real code.

> My ladder two examples demonstrate that this could have utility outside of
> sequences but for iterators in general.

I'm sorry, I don't know what your ladder two examples are. Did you post 
them in another thread?

-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/I6PN73GZZ5K3L5Z4F6DQWOVHRZ2IMFMD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Method to efficiently advance iterators for sequences that support random access

I’m still waiting for an example of a real app where this matters. --
--Guido (mobile)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JE74XPRXVA6SS4PIQITI4J6ZXMUCY2OS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Method to efficiently advance iterators for sequences that support random access

On Wed, Oct 7, 2020 at 9:06 AM Josh Rosenberg
 wrote:
>
> This:
>
> def advance(it, n):
> try:
> return it[n:]
> except TypeError:
> return itertools.islice(it, n, None)
>
> has the disadvantages of:
>
> 1. Requiring a temporary copy of the data sliced (if len(it) is 1_000_000, 
> and n is 500_000, you're stuck between 500_000 pointless __next__ calls, a 
> 500_000 long temporary list or inefficiently looking up 500_000 elements by 
> index)
> 2. Not working with sequence iterators, only sequences themselves (so if you 
> want to read 1000, skip 1000, read 1000, skip 1000, over and over, you can't 
> just use a single stateful iterator for the whole process without using the 
> consume recipe and calling __next__ 1000 times for each skip)
> 3. Not working with all sorts of things where a dedicated advance 
> implementation would allow efficient skipping, e.g. the new insertion ordered 
> dicts when no deletions have been performed (a state we already track for 
> other reasons) can advance the iterator (for the raw dict, keys, values or 
> items) with the same efficiency as sequences do (and could save a lot of work 
> building and tossing tuples iterating .items() even if it can't assume no 
> dummy entries); the various itertools functions like combinations, 
> permutations and combinations_with_replacement (and in some cases, product) 
> could also be advanced efficiently without the expense of generating the 
> intermediate states.
>
> Point is, the OP's case (a single sequence, advanced exactly once) is the 
> only one that implementation addresses, and it still has scaling issues even 
> then.
>

You trimmed off the part where I actually made a proposal :) As you
may notice from the name of the parameter, this is intended to
actually work with iterators, not sequences.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SYAK5BZZWVFLY4XDRRZTTJEWON3WIR7Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Method to efficiently advance iterators for sequences that support random access

2020-10-06 Thread Josh Rosenberg

This:

def advance(it, n):
try:
return it[n:]
except TypeError:
return itertools.islice(it, n, None)

has the disadvantages of:

1. Requiring a temporary copy of the data sliced (if len(it) is 1_000_000,
and n is 500_000, you're stuck between 500_000 pointless __next__ calls, a
500_000 long temporary list or inefficiently looking up 500_000 elements by
index)
2. Not working with sequence iterators, only sequences themselves (so if
you want to read 1000, skip 1000, read 1000, skip 1000, over and over, you
can't just use a single stateful iterator for the whole process without
using the consume recipe and calling __next__ 1000 times for each skip)
3. Not working with all sorts of things where a dedicated advance
implementation would allow efficient skipping, e.g. the new insertion
ordered dicts when no deletions have been performed (a state we already
track for other reasons) can advance the iterator (for the raw dict, keys,
values or items) with the same efficiency as sequences do (and could save a
lot of work building and tossing tuples iterating .items() even if it can't
assume no dummy entries); the various itertools functions like
combinations, permutations and combinations_with_replacement (and in some
cases, product) could also be advanced efficiently without the expense of
generating the intermediate states.

Point is, the OP's case (a single sequence, advanced exactly once) is the
only one that implementation addresses, and it still has scaling issues
even then.

On Tue, Oct 6, 2020 at 6:21 PM Chris Angelico  wrote:

> On Wed, Oct 7, 2020 at 4:53 AM Christopher Barker 
> wrote:
> >
> > On Tue, Oct 6, 2020 at 10:28 AM Alex Hall  wrote:
> >>
> >>
> >> if you want to iterate through items N to the end, then how do you do
> that without either iterating through the first N and throwing them away,
> or making a slice, which copies the rest of the sequence?
> >>
> >> ```python
> >> for i in range(start, stop):
> >> x = lst[i]
> >> process(x)
> >> ```
> >
> >
> > well yes, of course. but it's kind of a principle in Python that you
> don't use indices to iterate through a sequence :-)
> >
> > And I still like the sequence view idea, because then the creating of
> the "subview" could be done outside the iteration code, which would not
> have to know that it was working with a sequence, rather than any arbitrary
> iterable.
> >
>
> Slices returning views would be elegant, but backward incompatible, so
> it might have to be something like lst.view[start:stop] to create a
> view. I'm not a fan of an "advance this iterator" feature (it'd need a
> dunder on the iterator to make it possible, and I don't see a lot of
> use for it), but perhaps some iterators could themselves support
> slicing. That would be completely backward compatible, since currently
> none of the iterators concerned have any support for indexing. If you
> had that, you could build your own advance() or consume() function,
> something like:
>
> def advance(it, n):
> try:
> return it[n:]
> except TypeError:
> return itertools.islice(it, n, None)
>
> Still unconvinced of its value, but a good use-case would sway me, and
> the C implementation for list_iterator wouldn't be too hard (it'd
> construct a new list_iterator with the same underlying list and an
> incremented index).
>
> ChrisA
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/T52Z25ZMCDVFEWY3W5WMIVO5XSCX46MN/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RQD2XY5KP5TDU2MJXB5VX2D4IO4EOH5T/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Method to efficiently advance iterators for sequences that support random access

2020-10-06 Thread Caleb Donovick

I am +0.3 on this as I don't personally have a need for this but do see the
utility.

I can think of a number of examples where an `__advance__` would be
preferable to any of the proposed solutions:
A skip list which doesn't support O(1) random access but can advance faster
than naively calling next repeatedly
A lazy infinite iterator which can efficiently calculate its state at some
future point  (e.g. `itertools.count`)
A tree iterator could perform efficient `__advance__` by checking the size
of sub trees before descending into them (I'm not sure why you would ever
want to `__advance__` a tree iterator).

My ladder two examples demonstrate that this could have utility outside of
sequences but for iterators in general.

-- Caleb Donovick

On Tue, Oct 6, 2020 at 1:13 PM David Mertz  wrote:

>
> On Tue, Oct 6, 2020, 1:21 PM Christopher Barker
>
>> if you want to iterate through items N to the end, then how do you do
>> that without either iterating through the first N and throwing them away,
>> or making a slice, which copies the rest of the sequence?
>>
>
> it = (lst[i] for i in range(N, len(lst)))
>
> I haven't benchmarked whether this is faster than islice. It might depend
> on how many you wind up consuming.
>
> It's slightly cumbersome to write, I suppose. But it also seems like
> something one RARELY needs.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/F7N5H6CAUJM5BICC4BEEWQDNIDGN2RTR/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HZSIE675BKFI62Y67WTCQ7AEPK5H5YOR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Method to efficiently advance iterators for sequences that support random access

2020-10-06 Thread David Mertz

On Tue, Oct 6, 2020, 1:21 PM Christopher Barker

> if you want to iterate through items N to the end, then how do you do that
> without either iterating through the first N and throwing them away, or
> making a slice, which copies the rest of the sequence?
>

it = (lst[i] for i in range(N, len(lst)))

I haven't benchmarked whether this is faster than islice. It might depend
on how many you wind up consuming.

It's slightly cumbersome to write, I suppose. But it also seems like
something one RARELY needs.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/F7N5H6CAUJM5BICC4BEEWQDNIDGN2RTR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Method to efficiently advance iterators for sequences that support random access

On Wed, Oct 7, 2020 at 4:53 AM Christopher Barker  wrote:
>
> On Tue, Oct 6, 2020 at 10:28 AM Alex Hall  wrote:
>>
>>
>> if you want to iterate through items N to the end, then how do you do that 
>> without either iterating through the first N and throwing them away, or 
>> making a slice, which copies the rest of the sequence?
>>
>> ```python
>> for i in range(start, stop):
>> x = lst[i]
>> process(x)
>> ```
>
>
> well yes, of course. but it's kind of a principle in Python that you don't 
> use indices to iterate through a sequence :-)
>
> And I still like the sequence view idea, because then the creating of the 
> "subview" could be done outside the iteration code, which would not have to 
> know that it was working with a sequence, rather than any arbitrary iterable.
>

Slices returning views would be elegant, but backward incompatible, so
it might have to be something like lst.view[start:stop] to create a
view. I'm not a fan of an "advance this iterator" feature (it'd need a
dunder on the iterator to make it possible, and I don't see a lot of
use for it), but perhaps some iterators could themselves support
slicing. That would be completely backward compatible, since currently
none of the iterators concerned have any support for indexing. If you
had that, you could build your own advance() or consume() function,
something like:

def advance(it, n):
try:
return it[n:]
except TypeError:
return itertools.islice(it, n, None)

Still unconvinced of its value, but a good use-case would sway me, and
the C implementation for list_iterator wouldn't be too hard (it'd
construct a new list_iterator with the same underlying list and an
incremented index).

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/T52Z25ZMCDVFEWY3W5WMIVO5XSCX46MN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments

On Tue, Oct 6, 2020 at 1:16 AM Stefan Behnel  wrote:

> Stefan Behnel schrieb am 29.09.20 um 11:48:
> > One thing that I'm missing from the PEP is the C side of things, though.
> > How are C extension types going to implement this?
> >
> > Will there be two new slot methods for them? Something like (but better
> > named than) "mp_subscript_kw()" and "mp_ass_subscript_kw()"?
> >
> > Would the extension types signal their availability with a new "TP_*"
> class
> > feature flag?
> >
> > Are the slot methods going to use the vectorcall calling convention, i.e.
> > pass the keyword names as a tuple, or should they accept (and thus,
> require
> > the overhead of) a Python dict as argument?
> >
> > This design must clearly be part of the PEP. What's the current status of
> > the discussion there?
>
> So, should I conclude from the silence that there has not been any
> discussion of this so far?
>

That's unfortunately right. I think the main reason is that the PEP authors
are not very familiar with the C API.

You ask some good questions about the style of the API. Right now the only
bit of C API in the PEP is the proposal to add
`PyObject_GetItemWithKeywords()` and friends, which do take a dict as
argument. We could define new slots that have the same signature, or we
could add a new flag to the type object's tp_flags field stating that the
existing slots take a dict as argument.

I'm not sure that we need a vector style API here -- I have a feeling that
this isn't going to be performance critical. (Certainly not for most
people, and not for the PEP authors' use cases.)

If you really want to help, maybe you can do a little prototype coding and
propose a specific API?

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SYS3ZMINR76ZI2LFVLUGQK7LF27R6CX5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Method to efficiently advance iterators for sequences that support random access

2020-10-06 Thread Wes Turner

Arrow Buffers, memoryview, array.array

Apache Arrow Buffers support zero-copy slicing:

> arrow::Buffer can be zero-copy sliced to permit Buffers to cheaply
reference other Buffers, while preserving memory lifetime and clean
parent-child relationships.
>
> There are many implementations of arrow::Buffer, but they all provide a
standard interface: a data pointer and length. This is similar to Python’s
built-in buffer protocol and memoryview objects.
>
> A Buffer can be created from any Python object implementing the buffer
protocol by calling the py_buffer() function.

https://arrow.apache.org/docs/python/memory.html#pyarrow-buffer

https://docs.python.org/3/library/stdtypes.html#memoryview :

> A memoryview has the notion of an element, which is the atomic memory
unit handled by the originating object obj. For many simple types such as
bytes and bytearray, an element is a single byte, but other types such as
array.array may have bigger elements.
>
> len(view) is equal to the length of tolist. If view.ndim = 0, the length
is 1. If view.ndim = 1, the length is equal to the number of elements in
the view. For higher dimensions, the length is equal to the length of the
nested list representation of the view. The itemsize attribute will give
you the number of bytes in a single element.
>
> A memoryview supports slicing and indexing to expose its data.
One-dimensional slicing will result in a subview:

https://docs.python.org/3/c-api/memoryview.html

https://docs.python.org/3/library/array.html#module-array

On Tue, Oct 6, 2020, 1:56 PM Wes Turner  wrote:

> So, Sequence views that do direct addressing with doubly-linked lists?
>
>
> https://docs.python.org/3/library/collections.abc.html#collections.abc.Sequence
>
>
> https://docs.python.org/3/library/stdtypes.html#dict-views :
>
> > The objects returned by dict.keys(), dict.values() and dict.items() are
> view objects. They provide a dynamic view on the dictionary’s entries,
> which means that when the dictionary changes, the view reflects these
> changes.
>
> You may be looking for (directly-addressable) NumPy arrays?
> https://numpy.org/doc/stable/reference/generated/numpy.array.html
>
> https://numpy.org/doc/stable/reference/generated/numpy.ndarray.view.html :
>
> > a.view(ndarray_subclass) or a.view(type=ndarray_subclass) just returns
> an instance of ndarray_subclass that looks at the same array (same shape,
> dtype, etc.) This does not cause a reinterpretation of the memory.
>
>
>
> On Tue, Oct 6, 2020, 1:35 PM Alex Hall  wrote:
>
>> On Tue, Oct 6, 2020 at 7:21 PM Christopher Barker 
>> wrote:
>>
>>>
>>>
>>> On Tue, Oct 6, 2020 at 10:14 AM Marco Sulla <
>>> marco.sulla.pyt...@gmail.com> wrote:
>>>
 What I do not understand is why you need to use the iterator instead
 of using the iterable itself. This way you can jump to whatever
 position without slicing.

>>>
>>> if you want the Nth item, that's easy, yes.
>>>
>>> if you want to iterate through items N to the end, then how do you do
>>> that without either iterating through the first N and throwing them away,
>>> or making a slice, which copies the rest of the sequence?
>>>
>>
>> ```python
>> for i in range(start, stop):
>> x = lst[i]
>> process(x)
>> ```
>>
>> The only problem is that there's slightly more execution in Python-land
>> than in C-land, but that only matters if `process(x)` does very little and
>> you're really concerned about performance. I can see how the proposal could
>> be useful but only in very limited use cases.
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/UQ327GHUIHT46AZU73KM562NFEGNGYUQ/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/344SN3RN7AU26RNPAVCVSAUODUFDQPNC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Method to efficiently advance iterators for sequences that support random access

2020-10-06 Thread Wes Turner

So, Sequence views that do direct addressing with doubly-linked lists?

https://docs.python.org/3/library/collections.abc.html#collections.abc.Sequence


https://docs.python.org/3/library/stdtypes.html#dict-views :

> The objects returned by dict.keys(), dict.values() and dict.items() are
view objects. They provide a dynamic view on the dictionary’s entries,
which means that when the dictionary changes, the view reflects these
changes.

You may be looking for (directly-addressable) NumPy arrays?
https://numpy.org/doc/stable/reference/generated/numpy.array.html

https://numpy.org/doc/stable/reference/generated/numpy.ndarray.view.html :

> a.view(ndarray_subclass) or a.view(type=ndarray_subclass) just returns an
instance of ndarray_subclass that looks at the same array (same shape,
dtype, etc.) This does not cause a reinterpretation of the memory.



On Tue, Oct 6, 2020, 1:35 PM Alex Hall  wrote:

> On Tue, Oct 6, 2020 at 7:21 PM Christopher Barker 
> wrote:
>
>>
>>
>> On Tue, Oct 6, 2020 at 10:14 AM Marco Sulla 
>> wrote:
>>
>>> What I do not understand is why you need to use the iterator instead
>>> of using the iterable itself. This way you can jump to whatever
>>> position without slicing.
>>>
>>
>> if you want the Nth item, that's easy, yes.
>>
>> if you want to iterate through items N to the end, then how do you do
>> that without either iterating through the first N and throwing them away,
>> or making a slice, which copies the rest of the sequence?
>>
>
> ```python
> for i in range(start, stop):
> x = lst[i]
> process(x)
> ```
>
> The only problem is that there's slightly more execution in Python-land
> than in C-land, but that only matters if `process(x)` does very little and
> you're really concerned about performance. I can see how the proposal could
> be useful but only in very limited use cases.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/UQ327GHUIHT46AZU73KM562NFEGNGYUQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/673X4GK3T5G2DOMCRCHD25VMJVAP4S4H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Method to efficiently advance iterators for sequences that support random access

On Tue, Oct 6, 2020 at 10:28 AM Alex Hall  wrote:

>
> if you want to iterate through items N to the end, then how do you do that
> without either iterating through the first N and throwing them away, or
> making a slice, which copies the rest of the sequence?
>
> ```python
> for i in range(start, stop):
> x = lst[i]
> process(x)
> ```
>

well yes, of course. but it's kind of a principle in Python that you don't
use indices to iterate through a sequence :-)

And I still like the sequence view idea, because then the creating of the
"subview" could be done outside the iteration code, which would not have to
know that it was working with a sequence, rather than any arbitrary
iterable.

-CHB

> The only problem is that there's slightly more execution in Python-land
> than in C-land, but that only matters if `process(x)` does very little and
> you're really concerned about performance. I can see how the proposal could
> be useful but only in very limited use cases.
>

that is pretty much the same argument as using islice -- it will iterate
through the first N elements, but at C speed ...

Which is why I see this as "one more use for a sequence view", rather than
enough of a motivator in itself.

-CHB

-CHB

-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EWDIJRNYKHA4AXDIW4DICAUJ5MY2C3KP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: SupportsString Protocol Type Annotation

The nice thing about Protocols is that they are so easy to define, you can
just define them yourself. There's no need to have a "standard" protocol in
typing.py for ever single dunder method in existence.

PS. There's no need for `__slots__ = ()` assuming you're not going to
inherit directly from it (there's really no point).

On Tue, Oct 6, 2020 at 10:29 AM aleksiy123  wrote:

> 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?
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/C66MLTYQNAL3KHZELGME62UQOVGAHM5L/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UOL3NKKVTQCWPYICL6XITMPX44RMAYMC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Method to efficiently advance iterators for sequences that support random access

2020-10-06 Thread Alex Hall

On Tue, Oct 6, 2020 at 7:21 PM Christopher Barker 
wrote:

>
>
> On Tue, Oct 6, 2020 at 10:14 AM Marco Sulla 
> wrote:
>
>> What I do not understand is why you need to use the iterator instead
>> of using the iterable itself. This way you can jump to whatever
>> position without slicing.
>>
>
> if you want the Nth item, that's easy, yes.
>
> if you want to iterate through items N to the end, then how do you do that
> without either iterating through the first N and throwing them away, or
> making a slice, which copies the rest of the sequence?
>

```python
for i in range(start, stop):
x = lst[i]
process(x)
```

The only problem is that there's slightly more execution in Python-land
than in C-land, but that only matters if `process(x)` does very little and
you're really concerned about performance. I can see how the proposal could
be useful but only in very limited use cases.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UQ327GHUIHT46AZU73KM562NFEGNGYUQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] SupportsString Protocol Type Annotation

2020-10-06 Thread aleksiy123

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?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/C66MLTYQNAL3KHZELGME62UQOVGAHM5L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Method to efficiently advance iterators for sequences that support random access

On Tue, Oct 6, 2020 at 10:14 AM Marco Sulla 
wrote:

> What I do not understand is why you need to use the iterator instead
> of using the iterable itself. This way you can jump to whatever
> position without slicing.
>

if you want the Nth item, that's easy, yes.

if you want to iterate through items N to the end, then how do you do that
without either iterating through the first N and throwing them away, or
making a slice, which copies the rest of the sequence?

Is this. big deal? maybe not -- islice is written in C, and pretty darn
fast, but there is a missing efficiency here, which could be addressed by
either providing access to set the iterator "counter", as proposed, or by
providing a view object that could be a slice without copying.

-CHB

> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/QZ5QL3HNNDJYV67RPVATVDRD5R63AOUM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6S735JUS66BTCFSKGLRY2JCYW7GKRAKG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Method to efficiently advance iterators for sequences that support random access

I suspect you will encounter a bit of resistence here, because itertools is
about, well, itertors, and designbed to work with arbitrary iterables, and
what you are looking for is somnethign optimized for Sequences. Which
doesn't mean it couldn't be there.

> Slicing large lists/strings/bytes/tuples is both memory and time
inefficient.

Exactly. Which is why I'd like to have a "view slice", and or more general
sequence view object, as outlined here:

https://github.com/PythonCHB/islice-pep/blob/master/pep-xxx-islice.rst

and discussed on this list here:

https://mail.python.org/archives/list/python-ideas@python.org/message/LEMV3WETPR2B6RXU747TC32EI2E7IRF6/
(from four years ago -- which I only just noticed!)

And more recently:

https://mail.python.org/archives/list/python-ideas@python.org/message/U35BS5OIDCGTL3PTY4DDOT43V3PN72LQ/

That kinda petered out, with from what I could tell, little  (no) interest
from any core devs. But this is another motivating use case -- so time to
revive it?

BTW -- see above, Serhiy Storchak, from four years ago, proposed a
"sequence tools" module -- which would address the "problem" of adding
things to itertools that are only useful for Sequences.

-CHB



-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZFZI2Q5JDWABYBHOUR5QGC4W66GKJKYO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Method to efficiently advance iterators for sequences that support random access

2020-10-06 Thread Marco Sulla

What I do not understand is why you need to use the iterator instead
of using the iterable itself. This way you can jump to whatever
position without slicing.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/QZ5QL3HNNDJYV67RPVATVDRD5R63AOUM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: CPP Namespaces For Python

NOTE 1:
After writing this whole post, I realized that while you used @classmethod,
what you seem to really want is a fully @staticmethod class -- certainly
your example was a static method, and some other posters were talking about
static method (i.e. "it's bad style to have unused parameters in a
function") -- so this answer *may* be not quite write for your use case,
but it does apply to the example given. And I'm having a hard time figuring
out when one might want a fully classmethod class :-), so if that is what
you intended, please post an example that actually uses the "cls" parameter.

NOTE 2:
maybe it was email client mangling, but your code was using two spaces for
indentation (or were those tabs?), you really want to use four spaces to
indent in Python -- trust me on this!

Now the post:

It's really hard to see what you are really working with with such a
(necessarily) short example, but a couple notes:

Cars have different states, MovingCar, IdleCar, ParkingCar...
>
> A car can move between different states and it keeps the same information.
>

Why writing a module does not work has 2 parts, they may be due to my
> insufficient experience with python but I'm switching between the states as
> their API's are executed.


you could use modules as namespaces in this case -- modules are objects,
like everything else in Python, so you could do:

in AA.py:

def greet(A_instance):
 print("Hello", A_instance.name)

BB.py:

def greet(A_instance):
print("Hello", A_instance.name)

main_module.py:

from . import AA, BB

class A:
def __init__(self, state, name):
self.state = state
self.name = name

def greet(self):
self.state.greet(self)

def switchAA(self):
self.state = AA

def switchBB(self):
self.state = BB

and it should all work.

But I agree, that doesn't "feel" right.

However, a "state" to me sounds like a collection of static information --
could your state be stored as a collection of data, in a dict, or maybe a
dataclass? are there actually different methods (actions) involved, that
don't involve the state itself (i.e. self)?

To follow your example:


> class AA:
>   @classmethod
>   def greet(cls, A_instance):
>  print("Hello", A_instance.name)
>
> class BB:
>   @classmethod
>   def greet(cls, A_instance):
> print("Hi", A_instance.name)
>

the difference between these is the content of the message, so you could
write:

from dataclasses import dataclass

@dataclass
class State():
greeting: str

AA = State(greeting="Hello")
BB = State(greeting="Hi")

class A:
def __init__(self, state, name):
self.state = state
self.name = name

def greet(self):
print(self.state.greeting, self.name)

def switchAA(self):
self.state = AA

def switchBB(self):
self.state = BB


if __name__ == "__main__":
obj = A(AA, "alperen")
obj.greet()
obj.switchBB()
obj.greet()

BTW: part of how I got to this solution is the DRY principle (Don't Repeat
Yourself): I looked at your AA and BB greet() methods, and it took me a
second to see what was different about them. They were repeated code: the
only difference was one string. You really don't need/want different
classes (or different methods) if the logic is the same.

But another way to do this, particularly if there IS some different logic
in your different State classes, would be to forget static methods, and
have the state stored in class attributes, and the logic in the methods:

class State:
 def greet(self, A_instance):
 print(self.greeting, A_instance.name)

class AA:
greeting = "Hello"

class BB:
greeting = "Hi"

It seems odd to have a subclass that only specifies a class attribute or
two, but if you really want to use classes in this way, it will accomplish
what you want.

All that being said, an "all_static" decorator, as suggested by Guido and
prototyped by Eric could be a reasonable way to create a collection of
methods in one namespace, if indeed, they are different methods.

-CHB

PS: A reminder about this list -- it's really a better idea for folks
fairly new to the language to start on another forum (e.g. tu...@python.org,
stack overflow, etc) and ask: "how to I accomplish this"? and see what you
get for answers, before you post an idea to ideas for a new language
feature.


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/Q6OZLNWFKAQEE5EU77CBKOKBODD53TOX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Method to efficiently advance iterators for sequences that support random access

2020-10-06 Thread Kevin Mills

Sorry for the duplicate message. I realized two seconds after I sent it, that I
only replied to you and not the group.

I didn't see the `consume` recipe until after I posted, or I probably would've
mentioned it. What I want would have to be done in C, because `it_index` (as
`listiterobject` and `unicodeiterobject` call it, not sure about the other
iterators I mentioned) isn't exposed in Python-land, with the exception of the
`__setstate__` workaround I mentioned before.

Slicing large lists/strings/bytes/tuples is both memory and time inefficient.

I don't think that `__setstate__` would even work with more general iterators,
that's not what I was trying to say.

`itertools.advance` (or maybe it should be called `itertools.consume` for
consistency with the recipe) should use whatever is the most efficient way to
advance the iterator without causing issues. Only iterators that are explicitly
created tied to sequences that support random access would be able to
efficiently jump forward; others would just call `next` repeatedly.
`list_iterator` / `listiterobject` for example doesn't have to worry about
losing any side-effects by jumping ahead.

Does that answer your questions/concerns?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/MP6FLPA2MTGQDYXXB6IEU6R272CXTRAQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Fwd: Re: Experimenting with dict performance, and an immutable dict

2020-10-06 Thread Marco Sulla

In the meanwhile, I updated the code of frozendict to the new 3.10
code. And here I need some help.

As you can see by the new benchs:
https://github.com/Marco-Sulla/cpython/blob/frozendict/frozendict/test/bench.txt

creation of frozendict is not faster anymore. This is because Inada
introduced memcpy to do a fast init of a dict from a "good" dict.

I tried to copy the code for frozendict, but I get a good old memory
corruption. I passed several hours to understand what I'm doing wrong,
without success.

The code is the one commented out at lines 1084 and 2978, starting
with a "it does not work" comment...
https://github.com/Marco-Sulla/cpython/blob/frozendict/Objects/dictobject.c
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CJZMIAHIBY4D2MOAAKPCHTKJDCGFOGF6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 637 - problems not solved by existing language

On Wed, Oct 7, 2020 at 2:08 AM Jonathan Fine  wrote:
> 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.
>

Be aware that this isn't an "expression" in the technical sense. You
can't put the SOMETHING into a variable and then use that variable in
the call or subscript.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XVIIGM5FIYSEVTRFD6JRRBTIEHYS7YRZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: CPP Namespaces For Python

2020-10-06 Thread Eric V. Smith


I was just working on that, although I prefer staticmethod:

def allstatic(cls):
    for key, value in cls.__dict__.items():
    if not key.startswith('__'):
    setattr(cls, key, staticmethod(value))
    return cls

@allstatic
class C:
    def foo(a, b):
    print(f'{a}, {b}')

C.foo('hello', 'world')
C().foo('world', 'hello')

It could be improved depending on the use case, for example checking for 
methods.


Eric

On 10/6/2020 10:42 AM, Guido van Rossum wrote:
I think the OP would be happy with a decorator they can just 
copy-paste. All it needs to do is go over the class dict and apply 
@classmethod to every “normal” function. Probably skip under names.


On Tue, Oct 6, 2020 at 06:46 Ricky Teachey > wrote:


cf. this relatively recent conversation on the same topic-- worth
reading in entirety:


https://mail.python.org/archives/list/python-ideas@python.org/thread/TAVHEKDZVYKJUGZKWSVZVAOGBPLZVKQG/

As I said in that conversation, in the past I have wanted to have
module-like namespaces inside of modules because sometimes it
makes organizational sense to not create a separate, very short,
module file.

Summary of how that thread turned out:

There seemed to be agreement among most of the conversation
participants that this would be a useful idea, and a few different
syntax ideas were batted about (a decorator, totally new syntax).
A few people have experimented with various ways of doing this
using current python but all of the ideas anyone has come up with
so far would require some kind of change to the core language to
make them work. The conversation didn't go any further than that
(to my knowledge).


---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about
going home or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org

To unsubscribe send an email to python-ideas-le...@python.org

https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at

https://mail.python.org/archives/list/python-ideas@python.org/message/QRZXD7PJMGZ5SOJTU2X3I3ZOU6YCTPAE/
Code of Conduct: http://python.org/psf/codeofconduct/

--
--Guido (mobile)

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HP6YM7PWUL6MQJYWTXGVO32MXWQLLFXW/
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2L3PT65HKRLE2SQSE7Y4GGVLXUSPJCY2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] PEP 637 - problems not solved by existing language

2020-10-06 Thread Jonathan Fine

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
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CZPTQAC666MUBCJNCFEIRA2KJ7MGNEDT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: CPP Namespaces For Python