[Python-ideas] Re: Restricting access to sensitive APIs with a permission model like Deno

[Paul Bryan]

I'm of the opinion that trying to sandbox an otherwise unaltered
runtime and standard library will run into the same walls as previous
attempts. My sense of this is if the Python community had the appetite
for effective fine-grained access control policies, it would require
embedding enforcement into the stdlib modules themselves. Pretty much a
refactor across the board.
___
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/2S7WBMIHFF5O2POQG2MON7THP3GVZCBT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Restricting access to sensitive APIs with a permission model like Deno

[Paul Bryan]

For such a thing to be useful, it will ultimately need to percolate up
to users to understand what they are getting themselves into by using
some application. Would this be correct in your view?

Would permissions be attached to individual modules? Packages? Would
they be declarative ahead of time, or be more of the more modern
Android model of asking for permission as code executes?

On Sun, 2023-02-26 at 01:21 +, python--- via Python-ideas wrote:
> Hello all,
> 
> Supply chain attacks are becoming a pressing concern in software
> development due to the large number of dependencies and multiple
> attack vectors. Using third party modules (libraries, packages etc) 
> is always a risk but the true potential of these attacks is now being
> weaponized. One way to deal with the risk is by limiting access to
> sensitive APIs like filesystem, shell, network and ffi so that
> packages which aren't explicitly granted permissions cannot use them,
> reducing their ability to do damage.
> 
> For example, a yaml parser should not need to use ffi, network nor
> shell. A command line argument parser library should not use network,
> ffi nor filesystem. Deno, a runtime for Typescript contains an
> interesting implementation of a permissions model for APIs.
> 
> I strongly think Python could benefit from such functionality and
> hacked together a quick experiment here:
> https://github.com/R9295/cpython
> Currently, it only prevents module imports in a very elementary
> manner but perhaps it can be of use to spark a discussion for an
> implementation.
> 
> Looking forward to your thoughts,
> Aarnav
> ___
> 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/MZNP5ZJBLMUO74PMZGWJGM6TAZXBK5AS/
> 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/S6HI6WDXN4IEPNEXF3LLT5MIV4AHTPYK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing variable scope control

[Paul Bryan]

It seems to me it would safer to do this in conjunction with 
contextvars.ContextVar.


On Wed, Nov 30 2022 at 08:44:50 PM +0100, Benedict Verhegghe 
 wrote:

A context manager could be used for this. On exit it should delete the
variables created inside it. Someting like this:

class Scope:
def __enter__(self):
self._globals = list(globals().keys())
return self
def __exit__(self, exc_type, exc_value, traceback):
del_vars = [var for var in globals()
if var not in self._globals]
for var in del_vars:
del globals()[var]

Then one can write:

with Scope():
a = 1
with Scope():
b = 2
# no more b here
# no more a or b here

Maybe such an (optimized) context manager could be added to Python?


Op 29/11/2022 om 02:49 schreef Anony Mous:
As it stands now, to create a local scope, you must define a 
function.


However, there are many cases where various things can reasonably be
done inline. Preparatory code is often done this way.

Good coding practice is generally accepted to be that variables are
local if at all possible. However, in direct, inline Python code, 
we're

inherently creating variables with a global scope.

We don't actually need a function for this kind of code; but a local
scope would often be valuable (as we see with lambda.) Moving things 
off

into a function can create a circumstance where we have to go looking
for the function. When something is a "one-shot" as in global
preparatory code, that's doing more work, and creating more 
indirection,

than needs actually be done. But global operations have their own
pitfalls, one of which is variable collisions. So Python sort of 
drives

us to make "one-use" functions where lambdas are insufficient to the
case in order to control locality.

You can end up writing things like...

def PrepOne():
 for MyCount in range(0,10):
 pass

PrepOne()

...which achieves the locality desired for variable MyCount, but is
clunky. It also clutters the global namespace with prepOne, which 
has no

good reason to exist.

So I'm thinking of something along these lines:

local:# <== or whatever syntax makes sense
 for MyCount in range(0,10):
 pass

So in that example, the code is inline - runs as part of the global,
sequential code execution - but the variable MyCount is local and 
goes

"poof" once the local: scope is exited.

This is the scoping equivalent of a pair of curly braces in c and 
c++. I

would like to see it be nestable, as scopes are in c/c++:

local:# <== or whatever syntax makes sense
 for MyCount in range(0,10):
 local:
 for YourCount in range(0,MyCount+1)
 pass

There, MyCount is available in both scopes (the first local: is an
enclosing scope) and YourCount is available only in the second 
local: scope.


Or, local: could be very strict, and require further syntax to
incorporate a previous scope, something like this:

local:# <== or whatever syntax makes sense
 for MyCount in range(0,10):
 local:
 incorporate MyCount # <== or whatever syntax makes sense
 for YourCount in range(0,MyCount+1)
 pass

Lastly, I suggest that the global keyword be used to expose global 
scope

variables, just as it is within def functions:

TheirCount = 10
local:# <== or whatever syntax makes sense
 global TheirCount
 for MyCount in range(0,TheirCount):
 local:
 for YourCount in range(0,TheirCount)
 pass

This would also be useful within normal functions, and again allows 
the
program flow to be linear rather than calling a 
function-within-a-function.


___
Python-ideas mailing list -- python-ideas@python.org 

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



Message archived at 


Code of Conduct: 

___
Python-ideas mailing list -- python-ideas@python.org 

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



Message archived at 


Code of Conduct: 


___
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@pyth

[Python-ideas] Re: Add copy to pathlib

[Paul Bryan]

For my edification, how is copy in pathlib proposed to be implemented?
Just call out to the OS to do the copy? Do the copy by reading and
writing?

On Tue, 2022-10-18 at 19:24 -0400, Todd wrote:
> On Tue, Oct 18, 2022 at 6:26 PM Chris Angelico 
> wrote:
> > On Wed, 19 Oct 2022 at 09:17, Todd  wrote:
> > >
> > > On Tue, Oct 18, 2022 at 5:00 PM Chris Angelico 
> > wrote:
> > >>
> > >> On Wed, 19 Oct 2022 at 06:50, Todd  wrote:
> > >> >
> > >> > Currently, pathlib supports pretty much all common filesystem
> > operations. You can create, move, and delete both files and
> > directories. One big omission is copying. You need shutil for that.
> > >> >
> > >> > Whatever the original intent might have been behind pathlib,
> > it is now effectively the standard tool for filesystem operations.
> > As such, excluding copying alone from basic operations creates an
> > unnecessary hurdle for users. It also increases the difficulty of
> > doing such operations since there is no hint within the pathlib
> > documentation on how to copy, new users basically need to google it
> > to find out.  That is fine for less common operations, but far from
> > ideal from a basic one like copying.
> > >> >
> > >>
> > >> Ah. I would look at solving this the other way: since this
> > really
> > >> isn't a path operation (in the same sense that moving/renaming
> > and
> > >> deleting are), keep it in shutil, but improve discoverability
> > with a
> > >> docs reference.
> > >>
> > >> ChrisA
> > >
> > >
> > > How is it any less of a "path operation" than moving files,
> > reading and writing files, making directories, and deleting files?
> > 
> > At a file system level, those are nothing more than directory entry
> > manipulation. (Reading and writing might count as slightly more
> > than
> > that, but practicality beats purity.) Copying a file involves a lot
> > more work, and is not a simple operation done in the directory
> > entry,
> > so it's more of a separate tool.
> > 
> 
> 
> Yes, and I would say practically copying a file is at least as much a
> valid part of pathlib as basic file/io. File i/o is a builtin for
> python, so putting it pathlib is even less useful than copying, which
> requires a separate import.
>  
> > Also, not everyone agrees on what
> > "copying" means, so there'll be various platform-specific concepts.
> > 
> 
> 
> But Python already has such a tool, we are simply exposing it in a
> more convenient way. 
>  
> > In theory, you could take literally every possible action that
> > could
> > be done on a file and make it into a Path method. Do we need a
> > method
> > to read a .WAV file and return its headers, or is that better left
> > in
> > the 'wave' module? There's a reason that huge slabs of Python are
> > built on protocols rather than methods. Assuming that
> > shutil.copyfile
> > accepts Path objects (and if it doesn't, that should definitely be
> > fixed), is it really a problem for the Path objects to not have a
> > copy
> > method?
> > 
> 
> 
> Operating on specific file types (other than text files) is not
> considered a core filesystem operation in any operating system I
> know. In contrast copying is, such as in UNIX 1, Multics, PC-DOS 1.0,
> and OS/2. 
> 
> Again, whatever the original intent behind pathlib was, its effective
> use today is as the primary recommended way to deal with basic file
> operations. From what I can tell, copying is pretty much universally
> treated as a basic file operation in pretty much every major
> operating system.
> ___
> 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/VWTK6HERNQDYPIZF3GR7IHJFTQWSEGTL/
> 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/72GMTHSBAPIVIJVTFWENACCLMRJ5ISBN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add __name__ to functools.partial object

[Paul Bryan]

+0

Questions:

1. What's the use case for partial having __name__?
2. Does this imply it should have __qualname__ as well?
3. What name would be given to (an inherently anonymous) lambda?

Notes:

1. I would prefer __name__ to be more qualifying like its repr (e.g.
partial(foo, "x") → "")


On Mon, 2022-08-29 at 21:31 -0700, Charles Machalow wrote:
> Hey folks,
> 
> I propose adding __name__ to functools.partial.
> 
> >>> get_name = functools.partial(input, "name: ")
> >>> get_name()
> name: hi
> 'hi'
> >>> get_name.__name__
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: 'functools.partial' object has no attribute
> '__name__'
> >>> get_name.func
> 
> >>> get_name.func.__name__
> 'input'
> 
> We could set __name__ based off of partial.func.__name__ or we could
> try to set it to something like 'partial calling func.__name__'
> 
> If the callable doesn't have a name, we could fall back to a None
> __name__ or set it to something generic. 
> 
> Even lambdas have __name__ set:
> 
> >>> l = lambda: input('name: ')
> >>> l.__name__
> ''
> 
> This proposal makes __name__ on partial objects more useful than the
> current behavior of __name__ on lambda objects as well. We could port
> over similar functionality to lambda if we'd like.
> 
> - Charlie Scott Machalow
> ___
> 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/WK3FO357ORPVAD3XRUBRH6IHIYSPS3G2/
> 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/6VD7SCZFP5KXGPRIFRTVYUUN7RANKZFR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Void type

[Paul Bryan]

It's unclear to me what `Void` is meant to provide in your example. Is
your hope for a `Void` value to not be passed as a parameter to the
wrapped function? 

On Sun, 2022-07-24 at 17:55 +, Крупенков Михаил wrote:
> Hello, I'll give an example:
> 
> def func(param="default"):
>     ...
> 
> def func_wrapper(..., param="default"):
>    ...
>    func(param)
> 
> We have to duplicate value of parameter "default" if we want to use
> this as the default. Or we can do that:
> 
> def func(param="default"):
>     ...
> 
> def func_wrapper(..., *args):
>    ...
>    func(*args)
> 
> But it won't always be possible. In addition, auto-completion in IDEs
> won't work.
> It would be cool to have an empty type like Void (not None) for
> explicit full control:
> 
> def func(param="default"):
>     ...
> 
> def func_wrapper(..., param=Void):
>    ...
>    func(param)
> ___
> 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/R464MUFZ4T2PRT4EPOIPKSHGDXSOB25E/
> 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/F5N3V6FS6LNDCKVZ3OQE7ZUJM3DMROOB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Typescript-Like Notational Shortcuts

[Paul Bryan]

On Tue, 2022-05-31 at 21:08 +, kevinlu1...@gmail.com wrote:

> On the theme of the addition of pip operators to indicate union, I
> was wondering what people think of using the following shortcuts for
> type hints.

> * type[] be a short-hand for List[type]
I'm at -½ on this idea. Using list[type] isn't really problematic for
me today.  

> * [type1, type2, type3] be a shorthand for Tuple[type1, type2, type3]
I think this would problematic because today it already validly
expresses a list containing the elements: type1, type2 and type3. And
all it saves is 5 characters: `tuple`.

> * similar ideas for dictionaries and callables with (perhaps with
> javascript-like arrow notations?)

I'm +1 for the idea of a more intuitive callable type hint syntax.

> I just think something like this would be easier to read. For
> example, a lot of functions that return tuples generally are
> immediately unpacked when it's used, so I think this is a more clear
> and concise way of stating that this is that it returns three
> elements: an element of type1, an element of type2 and an element of
> type3. In other words, the fact that it's a tuple does not matter
> much.

___
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/NTAPUM62BK6V7XXMJNR6AXS4TQMMQZRT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dataclass field argument to allow converting value on init

[Paul Bryan]

I think we are saying the same thing. I don't think this would require
another parameter if type checkers are capable of inferring the type
from the parameter to the function to be called on init.

On Wed, 2022-06-29 at 21:26 +, Steve Jorgensen wrote:
> Paul Bryan wrote:
> > Could the type hint for the __init__ parameter be inferred from the
> > (proposed) init_fn's own parameter type hint itself?
> > On Tue, 2022-06-28 at 16:39 +, Steve Jorgensen wrote:
> 
> I think I was already suggesting that possibility "an optional
> argument to `InitFn` or maybe that can be derived from the signature
> of the function that `InitFn` refers to." Are we saying the same
> thing?
> ___
> 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/W6SYLYIQLORAJJCVXYPZFLV25XZG43DH/
> 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/2AY76OOTBGB7YIEA5FHMTMLFUDF72L5F/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dataclass field argument to allow converting value on init

[Paul Bryan]

Could the type hint for the __init__ parameter be inferred from the
(proposed) init_fn's own parameter type hint itself?

On Tue, 2022-06-28 at 16:39 +, Steve Jorgensen wrote:
> Dexter Hill wrote:
> > Ah right I see what you mean. In my example I avoided the use of
> > `__init__` and specifically `__post_init__` as (and it's probably a
> > fairly uncommon use case), in my actual project, `__post_init__` is
> > defined on a base class, and inherited by all other classes, and I
> > wanted to avoid overriding `__post_init__` (and super-ing). The
> > idea was to have the conversion generated by the dataclass, within
> > the `__init__` no function were required to be defined (similarly
> > to how converters work in attrs).
> > With your suggestion, what do you think about having something
> > similar to `InitVar` so it's more in line with how `__post_init__`
> > currently works? For example, like one of my other suggestions,
> > having a type called `InitFn` which takes two types: the type for
> > `__init__` and the type of the actual field.
> 
> Now I see why you wanted to avoid using __post_init__. I had been
> thinking to try to use __post_init_ instead of adding more ways to
> initialize, but your reasoning makes a lot of sense.
> 
> Would we want something more general that could deal with cases where
> the input does not have a 1-to-1 mapping to the field that differ
> only, perhaps, in type hint? What if we want 1 argument to
> initializes 2 properties or vice verse, etc.?
> 
> In any case, having a new `InitFn` is worth digging into, I don't
> think it needs to have 2 arguments for type since the type annotation
> already covers 1 of those cases. I think it makes the most sense for
> the type annotation to apply to the property and the type of the
> argument to be provided either through an optional argument to
> `InitFn` or maybe that can be derived from the signature of the
> function that `InitFn` refers to.
> ___
> 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/BCN2BUZSM6KH5VSTKHYWI3CB5UVDDNUH/
> 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/Z7BFI6Q57SGMYBT4SFLC5QHNNYTU7FCV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dataclass field argument to allow converting value on init

[Paul Bryan]

What type hint will be exposed for the __init__ parameter? Clearly,
it's not a `str` type in your example; you're passing it an `int` value
in your example. Presumably to overcome this, you'd need yet another
`field` function parameter to provide the type hint for the `__init__`
param?


On Wed, 2022-06-22 at 20:43 +, Dexter Hill wrote:
> The idea is to have a `default_factory` like argument (either in the
> `field` function, or a new function entirely) that takes a function
> as an argument, and that function, with the value provided by
> `__init__`, is called and the return value is used as the value for
> the respective field. For example:
> ```py
> @dataclass
> class Foo:
>     x: str = field(init_fn=chr)
> 
> f = Foo(65)
> f.x # "A"
> ```
> The `chr` function is called, given the value `65` and `x` is set to
> its return value of `"A"`. I understand that there is both `__init__`
> and `__post_init__` which can be used for this purpose, but sometimes
> it isn't ideal to override them. If you overrided `__init__`, and
> were using `__post_init__`, you would need to manually call it, and
> in my case, `__post_init__` is implemented on a base class, which all
> other classes inherit, and so overloading it would require re-
> implementing the logic from it (and that's ignoring the fact that you
> also need to type the field with `InitVar` to even have it passed to
> `__post_init__` in the first place).
> 
> I've created a proof of concept, shown below:
> ```py
> def initfn(fn, default=None):
>     class Inner:
>     def __set_name__(_, owner_cls, owner_name):
>     old_setattr = getattr(owner_cls, "__setattr__")
> 
>     def __setattr__(self, attr_name, value):
> 
>     if attr_name == owner_name:
>     # Bypass `__setattr__`
>     self.__dict__[attr_name] = fac(value)
> 
>     else:
>     old_setattr(self, attr_name, value)
> 
>     setattr(owner_cls, "__setattr__", __setattr__)
> 
>     def fac(value):
>     if isinstance(value, Inner):
>     return default
> 
>     return fn(value)
> 
>     return field(default=Inner())
> ```
> It makes use of the fact that providing `default` as an argument to
> `field` means it checks the value for a `__set_name__` function, and
> calls it with the class and field name as arguments. Overriding
> `__setattr__` is just used to catch when a value is being assigned to
> a field, and if that field's name matches the name given to
> `__set_name__`, it calls the function on the value, at sets the field
> to that instead.
> It can be used like so:
> ```py
> @dataclass
> class Foo:
>     x: str = initfn(fn=chr, default="Z")
> 
> f = Foo(65)
> f2 = Foo()
> 
> f.x # "A"
> f2.x # "Z"
> ```
> It adds a little overhead, especially with having to override
> `__setattr__` however, I believe it would have very little overhead
> if directly implemented in the dataclass library.
> 
> Even in the case of being able to override one of the init functions,
> I still think it would be nice to have as a quality of life feature
> as I feel calling a function is too simple to want to override the
> functions, if that makes sense.
> 
> Thanks.
> Dexter
> ___
> 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/4SM5EVP6MMGGHQMZSJXBML74PWWDHEWV/
> 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/N2JQWHBBKVDK3VJAFVUY5YCT5MZOTPPN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add tz argument to date.today()

[Paul Bryan]

+1. I would suggest `fromtimestamp` also accept an optional timezone
argument.

On Sun, 2022-06-19 at 11:47 -0700, Lucas Wiman wrote:
> Since "today" depends on the time zone, it should be an optional
> argument to date.today(). The interface should be the same as
> datetime.now(tz=None), with date.today() returning the date in the
> system time zone.
> 
> Rationale: It is common for processes to run in different timezones
> than the relevant end user. The most common case is probably a server
> running in UTC, which needs to do date calculations in timezones
> elsewhere. As a contrived example, you might do something like:
> 
>     tomorrow =date.today() + timedelta(days=1)
>     return render_template(..., ship_by_date=tomorrow)
> 
> But then if fulfillment is operating e.g. in US/Pacific time, the
> ship by date suddenly shows two days hence after 5 or 6pm when UTC
> midnight happens.
> 
> In my particular use case, we get some collection of business rules
> about when a particular record is considered "stale" or prioritized,
> and naively using date.today() can lead to off-by-one errors. 
> 
> The way to "fix" the code above is to reference "now":
> 
>     tomorrow =datetime.now(tz=...).date() + timedelta(days=1)
>     return render_template(..., ship_by_date=tomorrow)
> 
> While this is not terrible, it seems like the API between now() and
> today() should be consistent: in reality, they need the same set of
> inputs. Calling date.today(...) is more explicit and specific than
> calling datetime.now(...).date().
> 
> Best wishes,
> Lucas
> 
> ___
> 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/OJI3GBPNNGVZL22EAD723TYIFNF6OWAH/
> 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/CSJRVNR6EWKKNLZ3WCZIO3HUZPZIOZVH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: A string function idea

[Paul Bryan]

I wonder if applying regular expressions would sufficiently address
your use case.

On Mon, 2022-03-28 at 14:13 +0200, StrikerOmega wrote:
> Hello everyone,
> 
> When I am coding in Python I often encounter situations where I have
> a string like this one.
> 
> sample="""
> fruit:apple
> tree:[Apple tree]
> quantity:{5}
> quantity:{3}
> """
> 
> And I want to grab some kind of value from it. 
> 
> So let me introduce you to the grab function. This is the definition:
> 
> def grab(start, end, list_out=False):
> 
> Now, if you want to get the fruit from the sample string you can just
> "grab" it as follows:
> 
> sample.grab(start="fruit:", end="\n")
> >> 'apple'
> 
> You can also "grab" values enclosed in brackets or in any kind of
> character and It works as you would expect.
> 
> sample.grab(start="tree:[", end="]")
> >> 'Apple tree'
> 
> The optional argument "list_out" makes the function return a list of
> values, for cases where there are several of them to grab.
> 
> sample.grab(start="quantity:{", end="}", list_out=True)
> >> [5, 3]
> 
> The "grab" function will return only the first occurrence if
> "list_out" is omitted or passed as False.
> 
> sample.grab(start="quantity:{", end="}")
> >> 5
> 
> sample.grab(start="quantity:{", end="}", list_out=False)
> >> 5
> 
> As you can see, it is incredibly useful for extracting substrings
> from a larger and more complex string and can change the way we parse
> strings for the better. 
> 
> For example, it could simplify the way we parse the fields of HTTP
> headers. It also has many applications for the parsing of
> configuration files and the construction of strings for SQL queries
> and bash commands among others.
> 
> I have implemented this function locally to use it for my personal
> projects and It has proven to be really useful in practice, so I hope
> you find it useful as well and consider adding it as a class method
> for strings in Python.
> 
> Julio Cabria
> Engineering student 
> Autonomous University of Madrid
> ___
> 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/NV7G6W4RHTMMVIUDHQAATSVYFRIV6G7Z/
> 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/WXHJEJBB5BGI7HJJ63NPZDAV7QX6XF4G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops

[Paul Bryan]

1. It aligns with existing syntax in list comprehensions and generator
expressions.
2. In probably majority of cases it would be more readable to me;
"iterate over iterable for items meeting condition:".
3. Could it be easier to optimize an explicit filter expression to
improve iteration performance?

On Wed, 2022-03-02 at 13:37 +1100, Steven D'Aprano wrote:
> On Wed, Mar 02, 2022 at 02:28:33AM +0100, Svein Seldal wrote:
> 
> >     for x in y if x in c:
> >     some_op(x)
> 
> What does this new syntax give us that we don't already have with
> this?
> 
>     for x in y
>     if x in c:
>     some_op(x)
> 
> or the other multiple ways of writing the equivalent code?
> 
> I see no new functionality here. Is the only advantage that you save
> one 
> line and one indent level? Both are cheap.
> 
> To be precise, one extra line in something which is already a
> multiline 
> statement is essentially insignificant, and while an extra indent
> level 
> *can* be important, if you have already used so many indents that it 
> becomes important, you probably should be refactoring your code.
> 
> All I see here is adding to the complexity of the parser and the 
> language for no meaningful benefit. Its not even easier to read, it 
> crams more on one line which in real code with meaningful variable
> names 
> and a meanigful condition starts to get a bit long:
> 
>     # this line desperately needs to be split over two lines
>     for student in students if mean(student.grade(subject) for
> subject in student.get_subjects()) > 0.8):
>     ...
> 
> When I write list comprehensions with an if condition, probably 90%
> of 
> the time I end up moving the if condition to a second or even third
> line 
> of the comprehension. I expect the same will apply here.
> 
> To save one line for maybe 10% of my for...if constructs, I don't
> think 
> it is worth the bother of adding yet another way to do it.
> 
> 

___
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/KTM6XDMOMQW4W7XRDMG7S65EL34GXAZG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops

[Paul Bryan]

Very strong +1.

On Wed, 2022-03-02 at 02:28 +0100, Svein Seldal wrote:
> I'm sorry for reposting, but this message got stuck in moderation 
> approval for 5 days so I figured I should try again.
> 
> 
> I'd like to propose extending the for statement to include
> conditionals 
> akin to comprehensions in order to simplify for loop statements:
> 
>  `for .. in .. if ..:`
> 
> E.g.
> 
>  for x in y if x in c:
>  some_op(x)
> 
> which is functionally equivalent as
> 
>  for x in y:
>  if x not in c:
>  continue
>  some_op(x)
> 
> 
> The `for .. in .. if` syntax is a well-known construct from list 
> comprehension syntax [1]. Other alternative ways to do this with list
> comprehension is:
> 
>  for x in (a for a in y if c):
> 
> or
> 
>  it = (a for a in y if c)
>  for x in it:
> 
> Without having examined all use cases, I believe the same syntax
> should 
> be applied this syntax as for asynchronous comprehensions.
> 
> 
> [1] PEP 202 - List Comprehensions
> [2] PEP 530 - Asynchronous Comprehensions
> 
> 
> Best regards,
> Svein Seldal
> ___
> 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/7IXPROG2ANAFZTHZC4G3HRVXSKRIPXDL/
> 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/JPRJLYUFZOCZAC43CUHMOTZK4W2OCXXQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Literal type alternative syntax

[Paul Bryan]

I like the idea, quite a bit. Unfortunately, string annotations are
currently reserved for type annotations (particularly for forward
references), so`x: str` and `x: "str"` are currently equivalent. This
would rule-out using string literals in the manner you suggest.

On Sat, 2022-02-05 at 23:21 +0400, Abdulla Al Kathiri wrote:
> Hello all, 
> 
> Why can’t we use the literals directly as types? For example, 
> 
> x: Literal[1, 2, 3] = 3 
> name: Literal[“John”] | None = “John"
> 
> Become …. 
> 
> x: 1 | 2 | 3 = 3 
> name: “John” | None = “John"
> 
> 
> def open(file: Path | str, mode: “w” | “a” = “w”): … 
> 
> Best Regards, 
> 
> Abdulla 
> ___
> 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/IJ74AQRHCIIICNWYYBQTSQD2BQASRSBL/
> 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/DPZ6Y5B4C32X2QGNKDH72ZIDQNTGJWYK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revisiting a frozenset display literal

[Paul Bryan]

+1

On Wed, 2022-01-19 at 07:20 +, Ben Rudiak-Gould wrote:
> My preferred syntax for a frozenset literal would be something like
> 
>     {1, 2, 3}.freeze()
> 
> This requires no new syntax, and can be safely optimized at compile
> time (as far as I can tell).
> 
> set.freeze would be a new method of sets which could also be used at
> run time. It would return a new frozenset object and wouldn't alter
> the set object (so perhaps the name I suggested isn't ideal). Of
> course frozenset.freeze would just return itself.
> 
> ___
> 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/LYGTXEHMUVVPC3DAHUDLMKLP2574GX5L/
> 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/TG7HGCXR3OVR25GPSWXVDRROSUALBES6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: mimetypes.guess_type should not return deprecated mimetype application/x-javascript

[Paul Bryan]

+1

"x-" prefix indicates ad hoc (unofficial), not deprecated.

I agree, an official MIME type should be preferred over an unofficial
one. 


On Tue, 2022-01-18 at 16:26 +, mil...@gmail.com wrote:
> mimetypes are parsed from the file /etc/mime.types
> 
> cat /etc/mime.types | grep javascript
> application/javascript    js
> application/x-javascript  js
> 
> actual:
> mimetypes.guess_type("x.js") == "application/x-javascript"
> -> deprecated mimetype
> 
> expected:
> mimetypes.guess_type("x.js") == "application/javascript"
> 
> spoiler: here, the "x-" part is deprecated.
> 
> mimetypes.guess_type returns the deprecated mimetype
> because python returns the last entry in the /etc/mime.types file
> which is sorted alphabetically
> 
> proposed solution:
> use a smarter conflict-resolution when parsing /etc/mime.types.
> when two entries are found for one file-extension,
> avoid using a deprecated mimetype.
> rfc4329 lists 16 items for "unregistered media type"
> these could be hard-coded as set-of-strings, or as regex.
> 
> related bug report
> https://bugs.python.org/issue46035
> 
> mimetypes.guess_type
> https://docs.python.org/3/library/mimetypes.html#mimetypes.guess_type
> 
> unregistered media type
> https://datatracker.ietf.org/doc/html/rfc4329#section-3
> ___
> 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/V53XGQPIY7ZAISMTQHPHKGWZNSN5EXQG/
> 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/ZVFBHYXGD2EIJIDCKFDOL335AZYY42LJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Paul Bryan]

Interesting. Some apparent downsides:

- doesn't apply to class attributes
- objects with `__slots__` can't dynamically add attributes 

On Wed, 2021-12-15 at 11:13 +1100, Steven D'Aprano wrote:
> Hmmm, well it seems that we already have support for class attribute 
> docstrings, since Python 3.8.
> 
> It's not documented, but soon will be.
> 
> https://bugs.python.org/issue46076
> 
> 
>    class Card:
>   """A card from a standard French deck"""
>   __slots__ = {
>   'suit': 'Either "Spades", "Hearts", "Clubs" or "Diamonds"',
>   'rank': 'A positive integer in the range 2 <= x <= 14'
>   }
> 
> 
> help() already knows to read the docstrings from the slot dict
> values.
> 
> 

___
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/4XBHQSDGK57UDXOCF67XRXC5Q4DDJZSL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Paul Bryan]

If we proceed with using `Annotated`, I suggest it be the last string
in the metadata. Using your example:

spam: Annotated[
  int,
  Positive,
  GreaterThan[1],
  "Doc string goes here..."
  Union[Odd|Literal[2]],
  Prime,
  Wibble,
  Wobble,
] = 2

In other words, strings would be reserved to specify documentation.


On Tue, 2021-12-14 at 11:38 +1100, Steven D'Aprano wrote:
> Thinking more about my example here:
> 
> On Tue, Dec 14, 2021 at 01:50:45AM +1100, Steven D'Aprano wrote:
> 
> >     class MyClass:
> >     """Blah blah blah.
> > 
> >     Variable annotations of the form Annotated[T, 'string',
> > *args]
> >     always interpret the string in the second position as a 
> >     docstring. If you want to use Annotated but without a
> > docstring,
> >     put None in the second position.
> >     """
> >     spam: Annotated[int, 'Yummy meat-like product']
> >     eggs: Annotated[float, 'Goes well with spam', Domain[0, 1]]
> >     cheese: Sequence[str]  # No docstring.
> 
> perhaps a better convention might be that the docstring is the *last*
> item in the Annotated metadata, rather than the second item (after
> the 
> initial type).
> 
> The will allow people to use arbitrarily long augmented types, and 
> follow it with the docstring:
> 
>     spam: Annotated[int,
>     Positive,
>     GreaterThan[1],
>     Union[Odd|Literal[2]],
>     Prime,
>     Wibble,
>     Wobble,
>     "Doc string goes here..."
>     ]=2,
> 
> That will also help ensure that the docstring stands out visually, as
> it 
> will be last in the list, not stuck in the middle.
> 
> 

___
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/LKGQPLEOKJ5J5M4DWQIHLLVPXZE7ILSM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Paul Bryan]

On Mon, 2021-12-13 at 11:22 +1100, Steven D'Aprano wrote:
> On Sun, Dec 12, 2021 at 03:38:23PM -0800, Paul Bryan wrote:
> 
> > OK, so it's not the type, except it kind of is.
> 
> Except it isn't annotating the type, it is annotating the attribute.
> 
> We don't annotate *types*:
> 
>     int: Sequence[str]
> 
> That would be a regular variable or attribute called "int" that just 
> shadowed the builtin type int. We annotate *variables* (including 
> function parameters and class attributes).
> 
> 
> > In my other example, I used `Annotated` to create what I guess is
> > (and 
> > what you suggested) a pseudo-type? When it was annotated it had 
> > nothing to do with any attribute. To reiterate:
> > 
> > SomeType = Annotated[str, "some type"]
> 
> That's not an annotation. That's a type alias.
> 
> Annotations follow a colon, not an equals sign.

1. While I agree that assigning the `Annotated` value to `SomeType`
makes `SomeType` a type alias, what do you call the specific instance
of `Annotated[...]` itself? To date, I've been referring to it as a
type, but that's also muddying the waters here.

2. I've been flyng fast and loose with the term "annotate". No help
from PEP 593, which convolutes the situation with passages such as:

> Annotated is parameterized with a type and an arbitrary list of
> Python values that represent the annotations.

To rephrase, if I add a string "some type" to an `Annotated` instance,
it would not be documenting the (non-existent) attribute, it would
arguably be documenting the type itself. 

Getting concrete:

Coordinate = Annotated[int, "a graph coordinate", ValueRange(-100, 100)]
...
@dataclass
class Point:
  x: Annotated[Coordinate, "the horizontal coordinate"]
  y: Annotated[Coordinate, "the vertical coordinate"]

I suggest that in these uses of strings in `Annotated`, the 1st case
would serve to document the "coordinate" (pseudo-)type, while the 2nd
and 3rd cases would serve to document the attributes themselves. In
some cases, a developer may very well be satisfied with the
documentation of the (pseudo-)type and not override it when annotating
the attribute.

> > `Annotated` certainly appears to be intended to provide hints about
> > the
> > type. In PEP 593, `MaxLen` is an example of prescribing constraints
> > on
> > value. It would apply to an attribute if that attribute was
> > annotated
> > with it as a type hint.
> 
> And until some variable or attribute was actually annotated with it,
> it 
> might as well not exist.

The use of `Annotated` is to decorate an existing type to provide
additional metadata about it. The `Coordinate` type alias in the
example above can be introspected at runtime, independently of its use
in an annotation. If such a type alias were in a module, I would want
its documentation string to be displayed to provide additional context
about it, and help in determining if it's appropriate to use as an
annotation of an variable, parameter, attribute.

> 
> Annotated allows us to create new types, by associating arbitrary 
> metadata with an existing type. The meaning of that metadata is 
> completely unspecified. So we can say:
> 
>     Vec = Annotated[List[Tuple[T, T]], MaxLen(10)]
> 
> but that has no real meaning until you annotate a variable or
> attribute, 
> in which case the Vec type is annotated onto the attribute.

So, I think we agree that an `Annotated` instance results in what's
tantamount to a new type. And I hope by my examples above, we could
agree that it would be reasonable to document such a type in such a way
that its usage in an annotation could either inherit it, or override
it.

> That use-case for Annotated is independent of the proposed use-case 
> here. Sure you can use it to create new types, or type-aliases. But 
> that's not the only thing we can use it for.
> 
> The meaning of MaxLen(10) is unspecified. To a human reader, we can 
> guess that it probably means that the list can have a length of no
> more 
> than 10. Any tooling that comes across it is supposed to ignore it if
> it 
> doesn't know how to interpret it.
> 
> So for all we know, MaxLen(10) is not enforced by any tool, and it is
> purely there as documentation to the reader: "Please don't make your 
> vector longer than ten items".
> 
> We're not limited to only using Annotated to create new types. In an 
> annotation, we can associate arbitrary metadata with the annotated 
> attribute or variable. The interpretation of that metadata is still
> up 
> to the consumer. Is it a type restriction? Is it a docstring? Is it 
> something else? It's en

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Paul Bryan]

On Mon, 2021-12-13 at 09:57 +1100, Steven D'Aprano wrote:
> On Sun, Dec 12, 2021 at 12:48:36PM -0800, Paul Bryan wrote:
> 
> > But what's being annotated, the type or the attribute?
> 
> That's easy to test:
> 
> 
> > > > class A:
> ... attr: Annotated[int, "Doc string"]
> ... 
> > > > int.__annotations__
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: type object 'int' has no attribute '__annotations__'
> 
> 
> Okay, so it's not the type. *wink*

OK, so it's not the type, except it kind of is. In my other example, I
used `Annotated` to create what I guess is (and what you suggested) a
pseudo-type? When it was annotated it had nothing to do with any
attribute. To reiterate:

SomeType = Annotated[str, "some type"]

No attribute here (yet). Only when this is applied as a type hint to an
attribute would it then apply.

class A:
    attr: SomeType

`Annotated` certainly appears to be intended to provide hints about the
type. In PEP 593, `MaxLen` is an example of prescribing constraints on
value. It would apply to an attribute if that attribute was annotated
with it as a type hint.

By the way, to see real code implementing this convention see:
https://github.com/fondat/fondat-core/blob/main/fondat/validation.py#L41

Here's another place that defines annotations that can be used to
enhance API documentation (e.g. OpenAPI):
https://github.com/fondat/fondat-core/blob/main/fondat/annotation.py

(Disclosure: this is code I wrote.)

Being able to define a new type like this using Annotated has proven to
be very powerful. You can apply constraints and 

> It's the *class* that is annotated. But note that the mapping is
> between 
> the attribute name to annotation, so in the sense that attributes are
> represented by their name, it is the attribute that is annotated.

It's unfortunate that the name `Annotated` was selected, because it's
definitely a point that can result in confusion. An attribute can have
an annotation (i.e. has a type hint); however, is `Annotated`
annotating the attribute? It's an object that contains multiple values,
which can be applied to an attribute as an annotation (type hint).

> Unlike modules, classes and functions, the annotation cannot be on
> the 
> attribute's *value*, because the attribute may not even have a value
> at 
> this point. And even if it does, it might be immutable, or like the 
> type, many different attributes, with different annotations, may be 
> sharing the same value.

Agree.

> This rules out putting the docstring on the attribute directly.

Agree.

> The syntax shows us annotating the attribute, and that's exactly what
> got annotated.

I'm still not in aligned on this point. I think I agree that if you
annotate an attribute with `Annotated`, you're defining a pseudo type
that can serve to document the attribute. However, as I've
demonstrated, that can be inherited by defining that type in advance
and using it to annotate multiple attributes. As I suggested, I think a
reasonable approach could be to either take the last string in the
annotation, or combine multiple strings if present.

___
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/YAWO5EUWMC2HLY6XF55GW2NBOW3XTJ4B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Paul Bryan]

On Sun, 2021-12-12 at 12:23 -0800, Christopher Barker wrote:

> As for Typing.Annotated: it has one advantage in that typing tools
> currently (presumably) already accommodate extracting the type
> information from it -- see what typing.get_type_hints() does.

Confirmed. I have tooling today using exactly that to dynamically
generate API documentation.

> yes, it's very clear that any standardized use of annotations needs
> to be compatible with type hints and type checkers, static and
> dynamic. Which i think is Steve's point -- typing.Annotated is indeed
> compatible with those uses.

But what's being annotated, the type or the attribute?

> and yet the docs for typing.Annotated don't seem to say that. So what
> concerns me is that this may break other uses of Annotated, which are
> expecting types to be stored there. One problem with a docstrings is
> that they are  "just a string".  isinstance checks, as mentioned in
> the docs, are not so helpful. So we'd be establishing a new standard:
> “a bare string in an Annotated type is a docstring” -- adding a
> typing,Documented wouldn't be a much bigger lift ( I wonder if making
> it a subclass of Annotated would help).

1. Docstrings today are attached to the things they're documenting by
way of an included `__doc__` attrbute.  `Annotated` is arguably
"attached" to the type, to the extent that the type is embedded in the
annotation itself. Illustration:

SomeType = Annotated[str, "some type"]

class A:
  x: SomeType
  y: SomeType

Clearly, above we documented the type, not the attribute. We could
solve this by allowing it to be re-annotated, which seems perfectly
valid:

SomeType = Annotated[str, "some type"]

class A:
  x: Annotated[SomeType, "x docstring"]
  y: Annotated[SomeType, "y docstring"]

The last bare string could "win" as the prevaling docstring:

>>> SomeType = Annotated[str, "some type"]
>>> U = Annotated[SomeType, "new docstring"]
>>> U
typing.Annotated[str, 'some type', 'new docstring']

Or, doc tools could even include them both to provide a more meaningful
context.

You could argue that since the type annotation of an attribute can be
extended in this manner, `Annotated` is an acceptable way of
documenting an attribute.

2. Adding a typing.Documented would definitely increase verbosity. I
think we may already be pushing the envelope with `Annotated[...]`;
`Annotated[..., Documented(...)] may be an annotation too far. Since
there is not yet a convention for a bare string in `Annotated`, I
suggest we reserve it the purpose of documenting the type or attribute.

> And I note that Annotated flattens nested Annotated types, so having
> both a docstring and other use of Annotated could be a bit tricky.

I think as long as strings are considered documentation—regardless of
where they appear in the annotation—we'd still be on solid ground.

> As for using dataclasses as a way to introduce a convention: that
> could be a good route — but I doubt Eric would go for it[*] and in
> any case, it would in fact be introducing a new convention, so
> getting some consensus on what that convention should be would be
> helpful.
> 
> [*] Eric, of course, can speak for himself, but so far, dataclasses
> deliberately don’t do anything with annotations other than pass them
> on, and there is active debate about whether they should do more, and
> if so, what? 

I don't think dataclasses have to do anything with them. I'm literally
embedding strings in Annotated today, for this exact purpose, with no
impact on dataclasses. I think the work would be in documentation tools
to interpret the annotations and produce something usable to the
developer.

___
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/AAYG4NR4O3L7HIPTO4JOVJ2I2HKKA2H4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Paul Bryan]

On Sat, 2021-12-11 at 17:02 -0800, Christopher Barker wrote:

> It [Annotated] has a number of possible unspecified uses, but
> fundamentally, it's about the adding information to the type, not to
> the attribute -- e.g. not really intended for docstrings.

Ah, good point. I've conflated the two because dataclass attributes are
used to define the schema of the dataclass. For general purpose
attribute docstrings (module, class), I agree Annotated is probably
inappropriate. 

> Perhaps a better way to do that than to use Annotated would be to
> introduce new "thing", maybe in teh typoing module, like
> "Documented":

I think this will suffer from the same problem as Annotated: it would
document the type, not the attribute itself.

> Anyway, what I'm getting at is that it needs to be determined whare
> to put the docstrings before we can get very far with this idea.

How is Sphinx is pulling the string below the attribute? Whatever
mechanism is to be used, I propose it must allow for runtime
introspection.

___
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/LG7NQUZ67XTVXUAEXRTNHTXFXIH4NDYC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Paul Bryan]

I think that because Sphinx could interpret strings below attributes
for documentation, that perhaps we should go in that direction in
Python proper.

Personally, I find this more readable:

  class C:
x: Annotated[str, "Doc string"]
    y: Annotated[int, "Doc string"]

over:

  class C:
x: str
    "Doc string"
y: int
"Doc string"


On Sun, 2021-12-12 at 10:00 +1100, Steven D'Aprano wrote:
> On Sat, Dec 11, 2021 at 10:07:50AM -0800, Christopher Barker wrote:
> 
> > Where/how should class attribute doc strings be stored?
> > 
> > Tacked on to the class __doc__ ?
> > Another dict?
> > __attr_doc__
> > Added to __annotaions__ ?
> > Something else?
> 
> Didn't we decide there was an existing feature for this, no need for 
> new syntax?
> 
> > > > from typing import Annotated
> > > > class C:
> ... x: Annotated[int, "Doc string"] = 123
> ... 
> > > > C.x
> 123
> > > > C.__annotations__
> {'x': typing.Annotated[int, 'Doc string']}
> 
> 

___
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/MEFYE3FPMI7L4QPO4PRJ424IJ3HPXFEN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Paul Bryan]

On Thu, 2021-12-09 at 19:01 +, Simão Afonso wrote:
> I'm using docstrings bellow the attributes (analogous to functions
> and
> classes), I think it works well.
> It helps with distinguishing the class docstring from the arguments.

I think you'll find on close inspection that those strings don't "go
anywhere" (i.e. they're not in help documentation, they're not
introspectable.)

> On 2021-12-08 13:25:55, Ricky Teachey wrote:
> > On Wed, Dec 8, 2021 at 1:20 PM Paul Bryan  wrote:
> > > I believe a Annotated[..., str] could become an attribute
> > > docstring if by
> > > consensus we deem it to be so. I can't see any disadvantages,
> > > perhaps save
> > > for the verbosity of `Annotated`. It certainly seems like an
> > > advantage to
> > > use an existing mechanism rather than define a new one that would
> > > appear to
> > > require changes to the interpreter.
> > 
> > I think this would be better than nothing. But it is a little
> > verbose. And
> > it requires you to supply the type hint.
> > 
> > I use type hinting, but I don't want to use it every time I provide
> > an
> > Annotation/docstring.
> 
> In this case, why not use the current behaviour of putting the
> docstring
> below the attribute?

There is no current behaviour to leverage.

> 
> Shouldn't typing be encouraged on dataclasses, at least?
> ___
> 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/SG33WQJCHQUG23NKETD6FCPSYIWP5U4T/
> 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/H2MCTFUABNPYC2746G5D56W4DDRDORID/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Paul Bryan]

On Thu, 2021-12-09 at 12:32 +1100, Steven D'Aprano wrote:
> On Wed, Dec 08, 2021 at 09:45:35AM -0800, Paul Bryan wrote:
> 
> > I propose there is already a viable option in typing.Annotated.
> > Example: 
> > 
> > @dataclass
> > class InventoryItem:
> >     """Class for keeping track of an item in inventory."""
> >     
> >     name: Annotated[str, "Short name of the item."]
> >     unit_price: Annotated[float, "Price per unit in dollar."]
> >     ...
> 
> Oh nice! Guido's time machine strikes again.
> 
> So dataclasses could recognise Annotated and populate `__attrdoc__`.

Indeed.

> Should all classes do the same? How about top level module variables?

If we started with dataclass, it could be performed in the dataclass
decorator and make_dataclass functions. I think this would be low-
hanging fruit compared to classes and modules.


___
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/XWSFSHUYMTUVYGVTZLS2GFBEZVQQEZ4C/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Paul Bryan]

I believe a Annotated[..., str] could become an attribute docstring if
by consensus we deem it to be so. I can't see any disadvantages,
perhaps save for the verbosity of `Annotated`. It certainly seems like
an advantage to use an existing mechanism rather than define a new one
that would appear to require changes to the interpreter.

On Wed, 2021-12-08 at 13:04 -0500, Ricky Teachey wrote:
> On Wed, Dec 8, 2021 at 12:46 PM Paul Bryan  wrote:
> > I propose there is already a viable option in typing.Annotated.
> > Example: 
> > 
> > @dataclass
> > class InventoryItem:
> > """Class for keeping track of an item in inventory."""
> > 
> > name: Annotated[str, "Short name of the item."]
> > unit_price: Annotated[float, "Price per unit in dollar."]
> > ...
> > 
> > 
> > I've been using this in production code for about a year (with code
> > that generates OpenAPI document), with additional validation
> > constraints, and it's proving to be quite usable. 
> > 
> > Paul
> > 
> 
> 
> As I noted in the previous thread, a big downside IMO of using
> Annotated for docstrings is it really makes the help() output quite
> messy. The "docstrings" appear in at least 5 different places (as
> part of the Annotation objects).
> 
> This could be fixed, I guess. But that would skip over a question
> that gets raised here, which is: are a docstring and an annotation
> really the same thing? Are there disadvantages to assuming they are?
> 
> ---
> 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/DCQNO4OS3COA5CAIB2FVXRQAIXDIOKCD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2

[Paul Bryan]

I propose there is already a viable option in typing.Annotated.
Example: 

@dataclass
class InventoryItem:
"""Class for keeping track of an item in inventory."""

name: Annotated[str, "Short name of the item."]
unit_price: Annotated[float, "Price per unit in dollar."]
...

I've been using this in production code for about a year (with code
that generates OpenAPI document), with additional validation
constraints, and it's proving to be quite usable. 

Paul

On Wed, 2021-12-08 at 11:50 +, tmkehrenb...@gmail.com wrote:
> A few weeks ago, I proposed on this mailing list to write docstrings
> for
> class attributes like this:
> 
> @dataclass
> class A:
>     x: int
>     """Docstring for x."""
> 
> The main criticism, I think, was that it is weird to have the
> docstring
> *below* the attribute.
> 
> To solve this problem, I propose to introduce a new kind of string: a
> d-string ('d' for 'docstring'; alternatively also 'v' because it
> looks a
> bit like a downward arrow, or 'a' for 'attribute docstring'). A d-
> string
> is a normal string, except that it is stored in __attrdoc__ when used
> inside a class. It is stored with the name of the variable *below*
> it as the key.
> 
> Examples:
> 
> @dataclass
> class InventoryItem:
>     """Class for keeping track of an item in inventory."""
>     
>     d"""Short name of the item."""
>     name: str
>     d"""Price per unit in dollar."""
>     unit_price: float
>     d"""Available quantity currently in the warehouse."""
>     quantity_on_hand: int = 0
> 
> 
> InventoryItem.__attrdoc__ == {
>     "name": "Short name of the item.",
>     "unit_price": "Price per unit in dollar.",
>     "quantity_on_hand": "Available quantity currently in the
> warehouse.",
> }
> 
> 
> 
> class HttpRequest(Enum):
>     """Types of HTTP requests."""
>     
>     d"""GET requests are used to retrieve data."""
>     GET = auto()
>     d"""POST requests are used to insert/update remote data."""
>     POST = auto()
> 
> 
> HttpRequest.__attrdoc__ == {
>     "GET": "GET requests are used to retrieve data.",
>     "POST": "POST requests are used to insert/update remote data.",
> }
> 
> d-strings can be combined with raw strings by using the prefix rd or
> dr.
> d-strings could also be used to document module-level constants:
> 
> # in my_module.py:
> d"Number of days in a week."
> DAYS_PER_WEEK: Final = 7
> 
> 
> my_module.__attrdoc__ == {"DAYS_PER_WEEK": "Number of days in a
> week."}
> 
> -Thomas
> ___
> 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/VV5MOSIRVSTRDTA5NFVVUXGD2JFBERRS/
> 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/IC7B7DMUO2WRF3IUSLN4GAJJ65E3MOSQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing iterator objects with map, filter, reduce methods

[Paul Bryan]

1. Noted: Python's for statement will happily iterate over an object
that only implements __next__.
2. The documentation is pretty clear on what is expected of an
iterator: implement __next__ and __iter__.
3. It is perfectly reasonable for __iter__ to return something other
than self; the documentation already reflects this.
4. If you believe the documentation is in error or the requirement
should be relaxed, then further discussion is probably warranted.

On Mon, 2021-11-29 at 00:22 -0500, David Mertz, Ph.D. wrote:
> On Mon, Nov 29, 2021, 12:16 AM Paul Bryan  wrote:
> > And the second link?
> 
> Same comments, basically. But the more germane thing is that even
> assuming a class has both .__next__() and .__iter__(), it is
> perfectly reasonable for the latter to return something other than
> `self`.
> 
> The Foo and Bar classes are slightly contrived, but I've written
> production code where e.g. `iter(thing)` returns a new
> `thing.__class__` instance rather than self.
> 
> 
> > 
> > On Mon, 2021-11-29 at 00:11 -0500, David Mertz, Ph.D. wrote: If
> > you 
> > > On Sun, Nov 28, 2021, 11:43 PM Paul Bryan 
> > > wrote:
> > > > According to
> > > > https://docs.python.org/3/glossary.html#term-iterator and
> > > > https://docs.python.org/3/library/stdtypes.html#typeiter,
> > > > iterators must implement the __iter__ method.
> > > > 
> > > 
> > >  
> > > From your first link:
> > > 
> > > > CPython implementation detail: CPython does not consistently
> > > > apply the requirement that an iterator define __iter__().
> > > > 
> > > 
> > > 
> > > That said, I don't think the description at the link is very
> > > good.  Anyway, it's different from what I teach, and also
> > > different from how Python actually behaves.  E.g.:
> > > 
> > > > >>> class Foo:
> > > > ...     def __iter__(self):
> > > > ...         return Bar()
> > > > ...
> > > > >>> class Bar:
> > > > ...     def __next__(self):
> > > > ...         if random() > 0.5:
> > > > ...             raise StopIteration
> > > > ...         return "Bar"
> > > > ...
> > > > >>> for x in Foo():
> > > > ...     print(x)
> > > > ...
> > > > Bar
> > > > Bar
> > > > Bar
> > > 
> > > 
> > > Or anyway, what would you call `bar := Bar()` if not "an
> > > iterator?!
> > > 
> > > > On Sun, 2021-11-28 at 22:02 -0500, David Mertz, Ph.D. wrote:
> > > > > On Sun, Nov 28, 2021, 8:59 PM Steven D'Aprano 
> > > > > > To be an iterator, your object needs:
> > > > > > 
> > > > > > 1. a `__next__` method which returns the next value;
> > > > > > 2. and an `__iter__` method which returns self.
> > > > > 
> > > > > That's not quite right.
> > > > > 
> > > > > An iterator only needs .__next__(), and an iterable only
> > > > > needs .__iter__(). Returning self is a convenient, and
> > > > > probably the most common, way of creating an object that is
> > > > > both. But exceptions exist, and remain iterators and/or
> > > > > iterables.
> > > > > 
> > > > 
> > > > 
> > 
> > 

___
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/E3WYSX52KOFDHP3NNSZRBKDLIENGMUY3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing iterator objects with map, filter, reduce methods

[Paul Bryan]

And the second link?

On Mon, 2021-11-29 at 00:11 -0500, David Mertz, Ph.D. wrote:
> On Sun, Nov 28, 2021, 11:43 PM Paul Bryan  wrote:
> > According to https://docs.python.org/3/glossary.html#term-iterator
> > and https://docs.python.org/3/library/stdtypes.html#typeiter,
> > iterators must implement the __iter__ method.
> > 
> 
>  
> From your first link:
> 
> > CPython implementation detail: CPython does not consistently apply
> > the requirement that an iterator define __iter__().
> > 
> 
> 
> That said, I don't think the description at the link is very good. 
> Anyway, it's different from what I teach, and also different from how
> Python actually behaves.  E.g.:
> 
> > >>> class Foo:
> > ...     def __iter__(self):
> > ...         return Bar()
> > ...
> > >>> class Bar:
> > ...     def __next__(self):
> > ...         if random() > 0.5:
> > ...             raise StopIteration
> > ...         return "Bar"
> > ...
> > >>> for x in Foo():
> > ...     print(x)
> > ...
> > Bar
> > Bar
> > Bar
> 
> 
> Or anyway, what would you call `bar := Bar()` if not "an iterator?!
> 
> > On Sun, 2021-11-28 at 22:02 -0500, David Mertz, Ph.D. wrote:
> > > On Sun, Nov 28, 2021, 8:59 PM Steven D'Aprano 
> > > > To be an iterator, your object needs:
> > > > 
> > > > 1. a `__next__` method which returns the next value;
> > > > 2. and an `__iter__` method which returns self.
> > > 
> > > That's not quite right.
> > > 
> > > An iterator only needs .__next__(), and an iterable only needs
> > > .__iter__(). Returning self is a convenient, and probably the
> > > most common, way of creating an object that is both. But
> > > exceptions exist, and remain iterators and/or iterables.
> > > 
> > 
> > 

___
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/K5ACCN5KFMKZYJQU3O5GQHIUJV6THCCQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing iterator objects with map, filter, reduce methods

[Paul Bryan]

According
to https://docs.python.org/3/glossary.html#term-iterator and 
https://docs.python.org/3/library/stdtypes.html#typeiter,
 iterators must implement the __iter__ method.

On Sun, 2021-11-28 at 22:02 -0500, David Mertz, Ph.D. wrote:
> On Sun, Nov 28, 2021, 8:59 PM Steven D'Aprano 
> > To be an iterator, your object needs:
> > 
> > 1. a `__next__` method which returns the next value;
> > 2. and an `__iter__` method which returns self.
> 
> That's not quite right.
> 
> An iterator only needs .__next__(), and an iterable only needs
> .__iter__(). Returning self is a convenient, and probably the most
> common, way of creating an object that is both. But exceptions exist,
> and remain iterators and/or iterables.
> 
> ___
> 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/FWRNYVLPJV7SZD5E2M5LP2GYECKBONPG/
> 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/GIDOVVCH262MTKZKVFY7FNXJTR5EBM75/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Runtime-accessible attribute docstrings

[Paul Bryan]

I too have used plain strings in Annotated[...] to document fields in
dataclasses.

On Thu, 2021-11-18 at 13:51 -0500, Ricky Teachey wrote:
> On Thu, Nov 18, 2021 at 1:39 PM Thomas Grainger 
> wrote:
> > Ricky Teachey wrote:
> > > Could this be a use case for typing.Annotated?
> > > In [6]: from dataclasses import dataclass
> > > In [7]: from typing import Annotated
> > > In [8]: class A:
> > >    ...:     """Docstring for class A."""
> > >    ...:     x: Annotated[int, "Docstring for x"]
> > >    ...:     y: Annotated[bool, "Docstring for y"] = True
> > > In [9]: A.__annotations__
> > > Out[9]:
> > > {'x': typing.Annotated[int, 'Docstring for x'],
> > >  'y': typing.Annotated[bool, 'Docstring for y']}
> > > The syntax is a bit arduous; I'd be in favor of thinking through
> > ways to
> > > make it easier to write. But the basic functionality already
> > exists;
> > > there's no reason to duplicate it with another language feature.
> > > Rick.
> > > ---
> > > Ricky.
> > > "I've never met a Kentucky man who wasn't either thinking about
> > going home
> > > or actually going home." - Happy Chandler
> > > On Thu, Nov 18, 2021 at 5:50 AM tmkehrenb...@gmail.com wrote:
> > > > Stephen J. Turnbull wrote:
> > > > @standard_class_docstring_parser
> > > >     class A:
> > > >         """
> > > >         Class docstring.
> > > >         x:  Docstring for x
> > > >         y:  Docstring for y
> > > >         """
> > > >         x: int
> > > >         y: bool = True
> > > > Oh, this is actually a nice idea. You could have a
> > > > decorator that parses reST and then according
> > > > to some conventions extracts the attribute
> > > > docstrings. I think I will try to write something like
> > > > that.
> > > > Thomas
> > > > ___
> > > > 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/F2QJ3Q.
> > ..
> > > > Code of Conduct: http://python.org/psf/codeofconduct/
> > > >
> > 
> > I think you need to use another type rather than a plain string
> > here eg:
> > 
> > 
> > ```
> > @dataclasses.dataclass(frozen=True)
> > class Doc:
> >     v: str
> > 
> > @dataclasses.dataclass
> > class A:
> >     """docstring for class A."""
> >     x: typing.Annotated[int, Doc("docstring for x")]
> > ```
> > 
> 
> 
> I don't know why you would? It seems to work just fine with a plain
> string?
> 
> One thing that is bad about it: the class member "docstrings"
> (actually the annotations) are repeated all over the place (look like
> 4 times total?) in the help() output-- example is below:
> 
> >>> help(A)
> Help on class A in module __main__:
> 
> class A(builtins.object)
>  |  A(x: typing.Annotated[int, 'docstring for x']) -> None
>  |
>  |  docstring for class A.
>  |
>  |  Methods defined here:
>  |
>  |  __eq__(self, other)
>  |
>  |  __init__(self, x: typing.Annotated[int, 'docstring for x']) ->
> None
>  |
>  |  __repr__(self)
>  |
>  |  -
> -
>  |  Data descriptors defined here:
>  |
>  |  __dict__
>  |      dictionary for instance variables (if defined)
>  |
>  |  __weakref__
>  |      list of weak references to the object (if defined)
>  |
>  |  -
> -
>  |  Data and other attributes defined here:
>  |
>  |  __annotations__ = {'x': typing.Annotated[int, 'docstring for x']}
>  |
>  |  __dataclass_fields__ = {'x':
> Field(name='x',type=typing.Annotated[int,...
>  |
>  |  __dataclass_params__ =
> _DataclassParams(init=True,repr=True,eq=True,or...
>  |
>  |  __hash__ = None
> 
> ---
> 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/BXCEE4G6SDYWI4LQMTPZ3AWAJN2I3EMD/
> 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/KG67DQKZYMDZNZTLSZIHSYG5IGBH2REG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Invalidate list iterators after size changes?

[Paul Bryan]

Is this behavior of list iteration guaranteed by documentation
anywhere? A quick search didn't yield any results for me.

If not, I suggest either:

a) it gets documented so developers can rely on it, or
b) the lack of guarantee is documented so that we can reserve a change
of behavior later.

Paul


On Sun, 2021-10-10 at 13:17 +1300, Greg Ewing wrote:
> On 9/10/21 11:24 am, Tyler Hou via Python-ideas wrote:
> > Right now, the following code is valid in Python 3.9 (and
> > infinitely loops):
> > 
> > ```
> > lst = [1, 2, 3]
> > for i in lst:
> >  lst.append(i)
> > ```
> > 
> > 1. If the size of a list, set, or dict changes, invalidate all
> > existing iterators to that containers.
> 
> This would break Plex. I use a loop like that as part of the
> NFA-to-DFA conversion to calculate the epsilon-closure of a
> state (although obviously there are conditions on adding things
> to the list that ensure it terminates).
> 

___
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/I76YHMMZESG55EBSQRJURXLFHKB6TQTF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dict_items.__getitem__?

[Paul Bryan]

+1. These would be handy for any iterable. It'll works on dict keys and
values; bonus.

On Wed, 2021-10-06 at 15:42 +0100, Alex Waygood wrote:
> > Whether they are added to dict or itertools, there are still nine
> > of 
> > them
> 
> No, the suggestion was to add two functions to itertools (first() and
> last(), which would work with any iterable, not just dicts), rather
> than adding nine methods to the dict interface. This was precisely
> why I was saying that I liked the itertools solution more.
> 
> > On 6 Oct 2021, at 15:01, Steven D'Aprano 
> > wrote:
> > 
> > On Wed, Oct 06, 2021 at 11:11:09AM +0100, Alex Waygood wrote:
> > > > The temptation to insist "see, YAGNI!" at this point I shall
> > > > resist.
> > > 
> > > *You* might not need it, but I've seen it come up a lot on Stack 
> > > Overflow, and all too often people end up going for the much less
> > > efficient solution. I personally have also written code with
> > > practical 
> > > applications using `next(iter(mydict))`.
> > 
> > Under what circumstances do you care what the first key in a dict
> > is, 
> > without going on to care about the second, third, fourth etc?
> > 
> > They are surely extremely niche, or artificial, or both, e.g. the 
> > Stackoverflow problem you link to: "find the first non-repeating 
> > character in a string -- using only one loop". Why the *first*
> > rather 
> > than any, or all?
> > 
> > In any case, the presence of one or two uses for a piece of 
> > functionality doesn't mandate that we make this a builtin. Your
> > solution 
> > with next() is perfectly adequate.
> > 
> > The other suggested methods are even more obscure. Why have a
> > method 
> > for returning the first value, without knowing the key?
> > 
> > "I don't know what the first key is, and I don't care, but I know
> > that 
> > whatever it is, it maps to the value 17."
> > 
> > Now what are you going to do with that knowledge? This seems like a
> > method in desperate need of a use-case.
> > 
> > 
> > [...]
> > > I agree that it's a lot of methods to add. That's precisely why I
> > > prefer Inada Naoki's suggestion of additions to itertools
> > 
> > Whether they are added to dict or itertools, there are still nine
> > of 
> > them, and they are pretty much near clones of each other:
> > 
> >    # first_ and last_ whatsits 
> >    next([iter|reversed](obj.[keys|values|items]()))
> > 
> > if you will excuse the misuse of hybrid Python/BNF syntax :-)
> > 
> > 
> > 
> > -- 
> > 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-
> > id...@python.org/message/T3TOFAFBPGY44LOVKSMVZJGBNQ7MUNEL/
> > 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/OCVRRJPZQCQ6UKVKR4GQRJFWAUJNDFK6/
> 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/5EJWQFXWOERWNRF4QEIESGY3DPHZZFOA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Syntax Sugar for __name__ == "__main__" boilerplate?

[Paul Bryan]

Thanks for finding that.

While I don't feel strongly one way or the other, I do think the
discussion is worthwhile.

As I understand, the arguments for:
- let's get rid of boilerplate, that many (esp. beginners) may not
understand
- you could add command line arguments and return values in a more
natural way

As I understand, the arguments against:
- it's just 2 lines of code; this isn't a big problem being solved
- boilerplate serves to teach a fundamental concept about the loading
and execution of Python modules
- there may not be a clean way to maintain compatibility with previous
versions of Python

Paul

On Sat, 2021-10-02 at 12:21 -0400, Eric V. Smith wrote:
> See the rejected PEP 299 for a previous version of this idea:
> https://www.python.org/dev/peps/pep-0299/
> 
> And a discussion on python-dev:
> https://mail.python.org/pipermail/python-dev/2006-March/062951.html
> 
> Eric
> 
> On 10/1/2021 3:38 PM, Paul Bryan wrote:
> 
> > 
> > How about the following?
> > 
> > def __main__():
> >     ...
> > Behavior:
> > 
> > 1. Load module as normal.
> > 2. If __name__ is "__main__" or module is named in python -m, call
> > __main__ function.
> > 
> > Paul
> > 
> > 
> > On Fri, 2021-10-01 at 15:35 -0400, Jonathan Crall wrote:
> > 
> > > I was curious if / what sort of proposals have been considered
> > > for simplifying the pattern: 
> > > 
> > > ``` 
> > > def main():
> > >     ...
> > > 
> > > if  __name__ == "__main__":
> > >     main()
> > > ```
> > > 
> > > I imagine this topic must have come up before, so I'd be
> > > interested in any relevant history. 
> > > 
> > > But unless I'm missing something, it seems like adding some
> > > easier alternative to this cumbersome entrypoint syntax would be
> > > worth considering.
> > > 
> > > My motivation for writing this suggestion is in an attempt to
> > > stop a common anti-pattern, where instead of defining a `main`
> > > function (or a function by any other name) an simply calling that
> > > by adding the above two lines, a lot of Python users I work with
> > > will just start dumping their logic into the global scope of the
> > > module.
> > > 
> > > Needless to say, this can have consequences. If there was some
> > > default builtin, let's call it `__main__` for now (open to
> > > suggestions), that took a function as an argument and
> > > conditionally executed it if `__name__ == "__main__"` in the
> > > caller's scope, that would allow us to simplify the above
> > > boilerplate to a single line with no extra indentation:
> > > 
> > > ```
> > > def main():
> > >     ...
> > > 
> > > __main__(main)
> > > ``` 
> > > 
> > > In addition to being simpler, it would allow users to avoid the
> > > trap of adding logic that impacts the global scope. It would also
> > > save me some keystrokes, which I'm always grateful for.
> > > 
> > > Furthermore, it could be used as a decorator (and the use-case
> > > wouldn't be unreasonable!), and we all know how much new Python
> > > users love decorators when they find out about them.
> > > 
> > > ```
> > > @__main__
> > > def main():
> > >     ...
> > > ```
> > > 
> > > Maybe having such a builtin would discourage globals and help new
> > > users get the use-decorators-everywhere bug out of their system.
> > > 
> > > --
> > > -Dr. Jon Crall (him)
> > > ___
> > > 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/FKQS2NEI5RQMTX53N77KQQDFZ6HZONXU/
> > > 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/RNB5YYTGQIV4CRPUZEZTADKG7WJ4YY3B/
> > Code of C

[Python-ideas] Re: Syntax Sugar for __name__ == "__main__" boilerplate?

[Paul Bryan]

For sure. I think there can be room for improvement in modules though.

On Fri, 2021-10-01 at 20:43 +0100, Thomas Grainger wrote:
> FYI you can already use package/__main__.py which is runnable with
> `python -m package` and you don't need the `if __name__ ==
> "__main__":`
> https://docs.python.org/3.10/library/__main__.html#main-py-in-python-packages
> 
> On Fri, 1 Oct 2021, 20:39 Paul Bryan,  wrote:
> > How about the following?
> > 
> > def __main__():
> >     ...
> > 
> > 
> > Behavior:
> > 
> > 1. Load module as normal.
> > 2. If __name__ is "__main__" or module is named in python -m, call
> > __main__ function.
> > 
> > Paul
> > 
> > 
> > On Fri, 2021-10-01 at 15:35 -0400, Jonathan Crall wrote:
> > > I was curious if / what sort of proposals have been considered
> > > for simplifying the pattern: 
> > > 
> > > ```
> > > def main():
> > >     ...
> > > 
> > > if  __name__ == "__main__":
> > >     main()
> > > ```
> > > 
> > > I imagine this topic must have come up before, so I'd be
> > > interested in any relevant history. 
> > > 
> > > But unless I'm missing something, it seems like adding some
> > > easier alternative to this cumbersome entrypoint syntax would be
> > > worth considering.
> > > 
> > > My motivation for writing this suggestion is in an attempt to
> > > stop a common anti-pattern, where instead of defining a `main`
> > > function (or a function by any other name) an simply calling that
> > > by adding the above two lines, a lot of Python users I work with
> > > will just start dumping their logic into the global scope of the
> > > module.
> > > 
> > > Needless to say, this can have consequences. If there was some
> > > default builtin, let's call it `__main__` for now (open to
> > > suggestions), that took a function as an argument and
> > > conditionally executed it if `__name__ == "__main__"` in the
> > > caller's scope, that would allow us to simplify the above
> > > boilerplate to a single line with no extra indentation:
> > > 
> > > ```
> > > def main():
> > >     ...
> > > 
> > > __main__(main)
> > > ``` 
> > > 
> > > In addition to being simpler, it would allow users to avoid the
> > > trap of adding logic that impacts the global scope. It would also
> > > save me some keystrokes, which I'm always grateful for.
> > > 
> > > Furthermore, it could be used as a decorator (and the use-case
> > > wouldn't be unreasonable!), and we all know how much new Python
> > > users love decorators when they find out about them.
> > > 
> > > ```
> > > @__main__
> > > def main():
> > >     ...
> > > ```
> > > 
> > > Maybe having such a builtin would discourage globals and help new
> > > users get the use-decorators-everywhere bug out of their system.
> > > 
> > > --
> > > -Dr. Jon Crall (him)
> > > ___
> > > 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/FKQS2NEI5RQMTX53N77KQQDFZ6HZONXU/
> > > 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/RNB5YYTGQIV4CRPUZEZTADKG7WJ4YY3B/
> > 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/4QQRV7NBGQK63OUXEQI7QZSE5L2VGUHY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Syntax Sugar for __name__ == "__main__" boilerplate?

[Paul Bryan]

How about the following?

def __main__():
    ...

Behavior:

1. Load module as normal.
2. If __name__ is "__main__" or module is named in python -m, call
__main__ function.

Paul


On Fri, 2021-10-01 at 15:35 -0400, Jonathan Crall wrote:
> I was curious if / what sort of proposals have been considered for
> simplifying the pattern: 
> 
> ```
> def main():
>     ...
> 
> if  __name__ == "__main__":
>     main()
> ```
> 
> I imagine this topic must have come up before, so I'd be interested
> in any relevant history. 
> 
> But unless I'm missing something, it seems like adding some easier
> alternative to this cumbersome entrypoint syntax would be worth
> considering.
> 
> My motivation for writing this suggestion is in an attempt to stop a
> common anti-pattern, where instead of defining a `main` function (or
> a function by any other name) an simply calling that by adding the
> above two lines, a lot of Python users I work with will just start
> dumping their logic into the global scope of the module.
> 
> Needless to say, this can have consequences. If there was some
> default builtin, let's call it `__main__` for now (open to
> suggestions), that took a function as an argument and conditionally
> executed it if `__name__ == "__main__"` in the caller's scope, that
> would allow us to simplify the above boilerplate to a single line
> with no extra indentation:
> 
> ```
> def main():
>     ...
> 
> __main__(main)
> ``` 
> 
> In addition to being simpler, it would allow users to avoid the trap
> of adding logic that impacts the global scope. It would also save me
> some keystrokes, which I'm always grateful for.
> 
> Furthermore, it could be used as a decorator (and the use-case
> wouldn't be unreasonable!), and we all know how much new Python users
> love decorators when they find out about them.
> 
> ```
> @__main__
> def main():
>     ...
> ```
> 
> Maybe having such a builtin would discourage globals and help new
> users get the use-decorators-everywhere bug out of their system.
> 
> --
> -Dr. Jon Crall (him)
> ___
> 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/FKQS2NEI5RQMTX53N77KQQDFZ6HZONXU/
> 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/RNB5YYTGQIV4CRPUZEZTADKG7WJ4YY3B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allow dataclasses's auto-generated __init__ to optionally accept **kwargs and pass them to __post_init_

[Paul Bryan]

I'm in favour of keyword-only arguments in dataclasses; however
accepting arbitrary **kwargs seems pretty exotic to me. As Eric has
suggested, this seems like a job for some kind of wrapper or decorator.

On Mon, 2021-09-20 at 14:28 +, thomas.d.mc...@gmail.com wrote:
> Sorry for the double post, if the first one passed... I typed Enter
> too soon by accident :(
> 
> TL;DR: Add a `strict` keyword option to the dataclass constructor
> which, by default (True), would keep the current behavior, but
> otherwise (False) would generate an __init__ that accepts arbitrary
> **kwargs and that passes them to an eventual __post_init__.
> 
> Use case: I'm developing a client for a public API (that I don't
> control). I'd like this client to be well typed so my users don't
> have to constantly refer to the documentation for type information
> (or just to know which attributes exist in an object). So I turned to
> dataclasses (because they're fast and lead to super clean/clear
> code).
> 
> @dataclass
> class Language:
>     iso_639_1: Optional[str]
>     name: Optional[str]
>     
> Then my endpoint can look like this
> 
> def get_language() -> Language:
>     result = requests.get(...)
>     return Language(**result.json)
> 
> That's fine but it poses a problem if the API, the one I have no
> control over, decides overnight to add a field to the Language model,
> say 'english_name'. No change in the API number because to them,
> that's not a breaking change (I would agree). Yet every user of my
> client will see "TypeError: __init__() got an unexpected keyword
> argument 'english_name'" once this change goes live and until I get a
> chance to update the client code. Other clients return plain dicts or
> dict wrappers with __get_attr__ functionality (but without
> annotations so what's the point). Those wouldn't break.
> 
> I've looked around for solutions and what I found
> (https://stackoverflow.com/questions/55099243/python3-dataclass-with-kwargsasterisk
> ) ranged from "you'll have to redefine the __init__, so really you
> don't want dataclasses" to "define a 'from_kwargs' classmethod that
> will sort the input dict into two dicts, one for the __init__ and one
> of extra kwargs that you can do what you want with".
> 
> Since I'm pretty sure I _do_ want dataclasses, that leaves me with
> the second solution: the from_kwargs classmethod. I like the idea but
> I'm not a fan of the execution. First, it means my dataclasses don't
> work like regular ones, since they need this special factory. Second,
> it does something that's pretty trivial to do with **kwargs, as we
> can use **kwargs unpacking to sort parameters instead of requiring at
> least 2 additional function calls (from_kwargs() and
> dataclass.fields()), a loop over the dataclass fields and the
> construction of yet another dict (all of which has a performance
> cost).
> 
> 
> My proposal would be to add a `strict=True` default option to the
> dataclass constructor. the default wouldn't change a thing to the
> current behavior. But if I declare:
> 
> @dataclass(strict=False)
> class Language:
>     iso_639_1: Optional[str]
>     name: Optional[str]
> 
> 
> Then the auto-generated __init__ would look like this:
>     
>     def __init__(self, iso_639_1, name, **kwargs):
>     ...
>     self.__post_init__(..., **kwargs)  # if dataclass has a
> __post_init__
> 
> 
> This would allow us to achieve the from_kwargs solution in a much
> less verbose way, I think. 
> 
> 
> @dataclass(strict=False)
> class Language:
>     iso_639_1: Optional[str]
>     name: Optional[str]
>     
>     extra_info: dict = field(init=False)
>     
>     def __post_init__(self, **kwargs)
>     if kwargs:
>     logger.info(
>     f'The API returned more keys than expected for model
> {self.__class__.__name__}: {kwargs.keys()}. '
>     'Please ensure that you have installed the latest
> version of the client or post an issue @ ...'
>     )
>     self.extra_info = kwargs
> 
> 
> I'm not married to the name `strict` for the option, but I think the
> feature is interesting, if only to make dataclasses *optionally* more
> flexible. You don't always have control over the attributes of the
> data you handle, especially when it comes from external APIs. Having
> dataclasses that don't break when the attributes evolves can be a
> great safeguard.
> 
> Outside of my (somewhat specific, I'll admit) use-case, it would also
> allow dataclasses to be used for types that are inherently flexible.
> Imagine:
> 
> @dataclass(strict=False)
> class SomeTranslatableEntitiy:
>     name: Optional[str]
>     name_translations: dict[str, str] = field(init=False)
>     
>     def __post_init__(self, **kwargs)
>     self.name_translations = {
>     k: kwargs.pop(k)
>     for k, v in kwargs.keys()
>     if k.startswith('name_')  # e.g: 'name_en', 'name_fr'
>     }
> 
> Thanks for reading :)
> ___

[Python-ideas] Re: Create a @deprecated decorator (annotation)

[Paul Bryan]

I'm +1 on deprecation decorator, with some way to represent it so that
it can be determined at runtime (e.g. dunder).


On Thu, 2021-07-29 at 20:52 +, Leonardo Freua wrote:
> This is a good example of how using a decorator to express
> depreciation is much better and less polluting the method, as the
> depreciation message doesn't need to be in the method body.
> 
> In my view, it would be interesting for Python to natively have the
> ability to annotate deprecated methods.
> ___
> 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/BVYHXKUUCXD3D2JSSBEIEF2WR2PV2TLI/
> 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/OSR6OAEHQRXT6FLQE25UHOIM37RFULFH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Why do we have two obvious ways to create a simple data structure? Let's deprecate one.

[Paul Bryan]

I'm with you; since dataclasses were introduced, namedtuple has not see
any use from me, though none of my uses have demanded ultra-high
efficiency either.

I wonder how many users are currently relying on namedtuple __getitem__
semantics though. that's functionality dataclasses do not (currently)
have.

Random thought I don't know the answer to: Any reason __slots__ can't
be used on a dataclass to improve efficiency?


On Wed, 2021-07-28 at 22:22 +, pa...@lexyr.com wrote:
> [Migrating the discussion from https://bugs.python.org/issue44768.]
> 
> PEP 20 says:
> 
> > There should be one-- and preferably only one --obvious way to do
> > it.
> 
> There are two ways to create a simple named type to store data:
> collections.namedtuple and dataclasses.dataclass. I propose
> deprecating namedtuple.
> 
> As far as the interface is concerned, the namedtuple is almost
> completely equivalent to a frozen dataclass - with some iterability
> syntactic sugar thrown in. I don't think there are use cases for
> namedtuple that would not be trivial to rewrite with dataclasses.
> 
> As far as the implementation is concerned, the namedtuple is faster.
> If efficiency is a concern, why do we make our users decide? We can
> choose the most efficient one on the library's end. C++ does
> something similar with bool vectors - the library has a special case
> for where it would be more optimal to use a different data structure
> underneath.
> 
> 
> TL;DR: If dataclass is so good, why keep namedtuple around?
> ___
> 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/UQRCDWMFNC5NRLLQCTYPOEGWJOIV7BGJ/
> 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/4NOUPTLNNJJMM3XSN3WEK32NWRJDAVRD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Deprecation APIs and language tooling

[Paul Bryan]

I like the idea in principle.

Could be as simple the presence of a __deprecated__ attribute on the
class or function being deprecated. A simple decorator could set it.

On Mon, 2021-07-12 at 19:37 +0100, Sergei Lebedev wrote:
> Hi python-ideas,
> 
> The subject is by no means new nor unique, and in fact has been
> discussed on python-ideas at least once before as well as in
> python/mypy#2403..
> 
> However, to date, there seems to be no standard way of deprecating
> things declaratively, and ~every major library has its own internal
> API for that. For example, 
> 
> * numpy.deprecate,
> * similar decorators in pandas and TensorFlow, 
> * twisted.python.deprecate, 
> * warn_about_renamed_method in Django,
> * etc etc. 
> 
> The proliferation of deprecation APIs itself is not a problem, but it
> does make it difficult (if not impossible) for language tooling to
> consume that deprecation information and help users of these
> libraries write better code. 
> 
> Imagine, if there was a standard way to flag something as deprecated.
> That would allow, for example, an IDE or a linter to statically flag
> a particular usage site as problematic and, assuming such information
> is available, to suggest an auto-generated fix (see @Deprecated in
> Kotlin, for example). 
> 
> What do you think? Is anyone interested in discussing this further
> and perhaps sketching an API which could work reasonably well for
> library authors as well as for tooling?
> 
> Cheers,
> Sergei
> ___
> 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/EABCXCALZFRDH7CKMUL4YHFBQFOBUWN7/
> 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/45QIBHG6WTZYYGBKLANFKCD2LJL75RZ7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: An alternate idea for escaping in string interpolation

[Paul Bryan]

It looks like you're suggesting hard-coding specific language escape
conventions into f-strings?

What if instead you were to allow delegation to some filter function?
Then, it's generic and extensible.


def html(value: Any):
    filtered = ... # filter here
    return filtered

f'{!!html}...'


Paul


On Sat, 2021-06-26 at 23:19 -0700, Bruce Leban wrote:
> This is a response in part to Thomas Güttler's "Pre PEP: Python
> Literals" but I am starting a separate thread because I think it
> deserves separate discussion, and it's not a direct response to that
> proposal.
> 
> Here's the problem: we want to allow escaping in strings to prevent
> injection in HTML, SQL, etc.
> 
> Proposed solutions generally concentrate on a new kind of escaped
> format string. I won't go into detail on why I don't like these ideas
> because others have already covered that ground.
> 
> Instead, here's what I think is a better solution: a mechanism to
> allow formatting with html and sql escaping.
> 
> Specifically, I suggest these changes:
> 
> (1) Modify string formatting (str.format and f-strings) to add new
> conversions !html !sql !xml, which escape characters for embedding in
> html, sql, and xml respectively.**
> 
> (2) Modify string formatting to allow these new conversions to be
> added to the current conversions, e.g. !s!html.
> 
> (3) Modify string formatting to add a new syntax that specifies a
> conversion to use for all subsequent interpolations. The proposed
> syntax is a replacement_field that starts with two exclamation
> points. The replacement field itself expands to nothing and only
> affects the conversion of subsequent fields. Thus
> 
>     f"{!!html}{text!r}"
> 
> is equivalent to
> 
>     f"{text!r!html}"
> 
> A replacement field of {!!} resets the default conversion.
> 
> Yes, this is more typing than t-strings or backticks but EIBTI. And I
> believe this expands on existing format functions in a way that will
> be much more clear to someone encountering this new mechanism. And
> it's more flexible as it allows more granular control of escaping as
> in this example:
> 
>     f"""
>     {title!html}
>     {pre_rendered_html_body}
>     """
> 
> 
> **It's unclear if there's any functional benefit of having both html
> and xml encoding other than clarity of usage. Also, it would be nice
> to have a mechanism for adding additional conversions but I don't
> want to complicate the discussion at this point. Are there other
> standard escape mechanisms that would be worth including?
> 
> --- Bruce
> 
> 
> 
> ___
> 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/IJ7DAMTCBJQD5UEAV444DG5GALYN3U6C/
> 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/PP7CO35YAAMRGYHXSO5TY5ARW2EWXBBM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Fill in missing contextvars/asyncio task support

[Paul Bryan]

On Wed, 2021-06-23 at 21:18 -0700, yselivanov...@gmail.com wrote:

> I'm +1 to add a 'context' keyword-argument to
> 'asyncio.create_task()'. It will still be copied. I believe I've
> explained *why* the copy is still necessary in this thread.

+1.

Paul

___
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/Q4RCU2HDV34WUZBVR35NIARDQXDAFNTF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: The name Ellipsis should be a constant

[Paul Bryan]

+1

On Tue, 2021-06-01 at 05:46 +1000, Chris Angelico wrote:
> On Tue, Jun 1, 2021 at 5:40 AM David Mertz  wrote:
> > 
> > I think making 'Ellipsis' a reserved word is too much.  The analogy
> > with non-reserved words like `int`, `str`, `map`, `print`, and so
> > on, illustrate this, I think.  I.e. redefining those is likely to
> > cause bad things to happen, but we're consenting adults, and in the
> > end they are just names.
> > 
> > However, I think improving the repr() of the Ellipsis object itself
> > to remind users of the connection with its special literal `...` is
> > a great idea.
> > 
> 
> Originally, the notation "..." could only be used inside a subscript,
> and anywhere else, you'd have to spell it "Ellipsis". Now that you
> can
> use "..." anywhere, would it be worth switching the repr to just be
> that?
> 
> 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/EK7DPA4ORNFAE3PVE44KPF7NAYO7B3P7/
> 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/C3QQI3VUZB3MRKTCVERKZHNE4YGUZ52E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: The name Ellipsis should be a constant

[Paul Bryan]

Fixing typo:

>>> s = str
>>> str = int
>>> str

>>> s


On Mon, 2021-05-31 at 08:31 -0700, Paul Bryan wrote:
> Because ... is still bound to the original Ellipsis. Just as "s"
> below will remain bound to the original str.
> 
> >>> s = str
> >>> str = int
> >>> int
> 
> >>> s
> 
> 
> Paul
> 
> On Mon, 2021-05-31 at 16:16 +0100, MRAB wrote:
> > On 2021-05-31 15:55, Paul Bryan wrote:
> > > If you're proposing prevention of monkey patching Ellipsis, I
> > > think 
> > > you'll have to go all-in on all builtins.
> > > 
> > > For example:
> > > 
> > > > > > str = int
> > > 
> > > > > > str
> > > 
> > > 
> > > 
> > > > > > str == int
> > > 
> > > True
> > > 
> > > 
> > If you rebind str to int, the repr of str will say ,
> > so you 
> > can tell that something's happened, but the repr of ... is always 
> > 'Ellipsis', even though you've rebound Ellipsis.
> > 
> > > 
> > > On Mon, 2021-05-31 at 11:37 -0300, André Roberge wrote:
> > > > In Python `...` is referred to as `Ellipsis` and cannot be
> > > > assigned to.
> > > > Yet, one can assign any value to the name `Ellipsis`.
> > > > 
> > > > Consider the following:
> > > > 
> > > > ```
> > > > > > > ...
> > > > Ellipsis
> > > > > > > ... == Ellipsis
> > > > True
> > > > > > > Ellipsis
> > > > Ellipsis
> > > > > > > Ellipsis = 3
> > > > > > > Ellipsis
> > > > 3
> > > > > > > ... = 4
> > > >   File "", line 1
> > > >     ... = 4
> > > >     ^
> > > > SyntaxError: cannot assign to Ellipsis
> > > > > > >   # But I just did assign a new value to the name
> > > > > > > Ellipsis above.
> > > > > > > Ellipsis
> > > > 3
> > > > > > > ...
> > > > Ellipsis
> > > > > > > ... == Ellipsis
> > > > False
> > > > ```
> > > > 
> > > > For consistency, `Ellipsis` (the name) should **always** refer
> > > > to the 
> > > > same object that `...` refers to, so that both could not be
> > > > assigned a 
> > > > new value.
> > > > 
> > ___
> > 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/NE2FAW3XDFYUIMILV4BC2XT6VKLC4P6V/
> > 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/UTNK34FPS7OHK5X3OLCYXWFZ4HNUKJDI/
> 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/P4U32JFIIV3FSD4DTPO7XBDIUUIEPYTX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: The name Ellipsis should be a constant

[Paul Bryan]

Because ... is still bound to the original Ellipsis. Just as "s" below
will remain bound to the original str.

>>> s = str
>>> str = int
>>> int

>>> s


Paul

On Mon, 2021-05-31 at 16:16 +0100, MRAB wrote:
> On 2021-05-31 15:55, Paul Bryan wrote:
> > If you're proposing prevention of monkey patching Ellipsis, I think
> > you'll have to go all-in on all builtins.
> > 
> > For example:
> > 
> > > > > str = int
> > 
> > > > > str
> > 
> > 
> > 
> > > > > str == int
> > 
> > True
> > 
> > 
> If you rebind str to int, the repr of str will say , so
> you 
> can tell that something's happened, but the repr of ... is always 
> 'Ellipsis', even though you've rebound Ellipsis.
> 
> > 
> > On Mon, 2021-05-31 at 11:37 -0300, André Roberge wrote:
> > > In Python `...` is referred to as `Ellipsis` and cannot be
> > > assigned to.
> > > Yet, one can assign any value to the name `Ellipsis`.
> > > 
> > > Consider the following:
> > > 
> > > ```
> > > > > > ...
> > > Ellipsis
> > > > > > ... == Ellipsis
> > > True
> > > > > > Ellipsis
> > > Ellipsis
> > > > > > Ellipsis = 3
> > > > > > Ellipsis
> > > 3
> > > > > > ... = 4
> > >   File "", line 1
> > >     ... = 4
> > >     ^
> > > SyntaxError: cannot assign to Ellipsis
> > > > > >   # But I just did assign a new value to the name Ellipsis
> > > > > > above.
> > > > > > Ellipsis
> > > 3
> > > > > > ...
> > > Ellipsis
> > > > > > ... == Ellipsis
> > > False
> > > ```
> > > 
> > > For consistency, `Ellipsis` (the name) should **always** refer to
> > > the 
> > > same object that `...` refers to, so that both could not be
> > > assigned a 
> > > new value.
> > > 
> ___
> 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/NE2FAW3XDFYUIMILV4BC2XT6VKLC4P6V/
> 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/UTNK34FPS7OHK5X3OLCYXWFZ4HNUKJDI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: The name Ellipsis should be a constant

[Paul Bryan]

If you're proposing prevention of monkey patching Ellipsis, I think
you'll have to go all-in on all builtins.

For example:

>>> str = int
>>> str

>>> str == int
True

Paul

On Mon, 2021-05-31 at 11:37 -0300, André Roberge wrote:
> In Python `...` is referred to as `Ellipsis` and cannot be assigned
> to. 
> Yet, one can assign any value to the name `Ellipsis`.
> 
> Consider the following:
> 
> ```
> >>> ...
> Ellipsis
> >>> ... == Ellipsis
> True
> >>> Ellipsis
> Ellipsis
> >>> Ellipsis = 3
> >>> Ellipsis
> 3
> >>> ... = 4
>   File "", line 1
>     ... = 4
>     ^
> SyntaxError: cannot assign to Ellipsis
> >>>  # But I just did assign a new value to the name Ellipsis above.
> >>> Ellipsis
> 3    
> >>> ...
> Ellipsis
> >>> ... == Ellipsis
> False
> ```
> 
> For consistency, `Ellipsis` (the name) should **always** refer to the
> same object that `...` refers to, so that both could not be assigned
> a new value.
> 
> André Roberge
> ___
> 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/KDQ3OHALLXVZJIGPC4BMPVS2XH3VFPJV/
> 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/UZCWHAO4YVOKPZ6JA264MRD27QRBSKD4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

[Paul Bryan]

s/non-integer/non-decimal-integer/

On Fri, 2021-05-14 at 11:23 -0700, Paul Bryan wrote:
> I'll vote: bad. I don't think non-integer representations of fraction
> attributes should be considered valid when expressing as a literal.
> 
> On Fri, 2021-05-14 at 14:17 -0400, Ricky Teachey wrote:
> > On Fri, May 14, 2021 at 2:09 PM Ricky Teachey 
> > wrote:
> > > On Fri, May 14, 2021 at 1:14 PM André Roberge
> > >  wrote:
> > > > 
> > > > You can already experiment with this.
> > > > 
> > > > 
> > > 
> > > 
> > > Thanks Andre I tried it out and it works great.
> > > 
> > > Do the appended capital Fs make these numbers look like some kind
> > > of hexadecimal representation or is it just me?
> > > 
> > 
> > 
> > Actually it just hit me: I don't know if this will be considered a
> > big difficulty or not, but currently you can write division
> > operations using hexadecimal numbers:
> > 
> >  >>> 0xF / 0xF
> >  1.0
> > 
> > And this works in Andre's experimental implementation like so for
> > fractions of hex numbers:
> > 
> >  >>> 0xF / 0xF F
> >  Fraction(1, 1)
> > 
> > But it looks... funny. I don't know if is is good or bad. It just
> > is.
> >  
> > 
> > ---
> > 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/JRRIRYO45UFLF5XTDK6PQQFW2GNX6J4X/
> > 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/NBRDJPMW7D22VZIVUKXBHBAQ7UBQJXGJ/
> 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/M5VEVJI3UZHJXJ6IC7F3QML5ZJXDZ6ZA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

[Paul Bryan]

I'll vote: bad. I don't think non-integer representations of fraction
attributes should be considered valid when expressing as a literal.

On Fri, 2021-05-14 at 14:17 -0400, Ricky Teachey wrote:
> On Fri, May 14, 2021 at 2:09 PM Ricky Teachey 
> wrote:
> > On Fri, May 14, 2021 at 1:14 PM André Roberge
> >  wrote:
> > > 
> > > You can already experiment with this.
> > > 
> > > 
> > 
> > 
> > Thanks Andre I tried it out and it works great.
> > 
> > Do the appended capital Fs make these numbers look like some kind
> > of hexadecimal representation or is it just me?
> > 
> 
> 
> Actually it just hit me: I don't know if this will be considered a
> big difficulty or not, but currently you can write division
> operations using hexadecimal numbers:
> 
>  >>> 0xF / 0xF
>  1.0
> 
> And this works in Andre's experimental implementation like so for
> fractions of hex numbers:
> 
>  >>> 0xF / 0xF F
>  Fraction(1, 1)
> 
> But it looks... funny. I don't know if is is good or bad. It just is.
>  
> 
> ---
> 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/JRRIRYO45UFLF5XTDK6PQQFW2GNX6J4X/
> 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/NBRDJPMW7D22VZIVUKXBHBAQ7UBQJXGJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

[Paul Bryan]

On Fri, 2021-05-14 at 15:15 +, Martin Teichmann wrote:

> So, my argument is, this change will benefit many people, and be of
> only a small disadvantage to others. That disadvantage is that yes,
> there will be places where it does not work, so libraries need to get
> fixed. But this is the case with every Python update. Once it will be
> working, there will be no disadvantage anymore.

Why not support a new division operator and/or fraction literal to
avoid breakage altogether?

Paul

___
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/HLUMXVLNLMOFGJOYYOUTLKZVOE7E7JQF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

[Paul Bryan]

And I've just learned something. 🙂

On Fri, 2021-05-14 at 11:28 -0300, André Roberge wrote:
> 
> 
> On Fri, May 14, 2021 at 11:23 AM Paul Bryan  wrote:
> > I like the idea of supporting fractions to maintain more precision
> > in calculations. I wonder if this should fall outside the scope of
> > a standard library and be implemented in an external library. I'd
> > lean toward inclusion in stdlib.
> > 
> 
> 
> It already exists.
> 
> https://docs.python.org/3/library/fractions.html
> 
> André Roberge
>  
> > 
> > ___
> > 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/HUMMOSBZYLSPP7NOMBD3Z4MSQ3VBDKBK/
> > 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/HJRILYF5K5DMSTZOQYE3ELX6WOHP7IRB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

[Paul Bryan]

I like the idea of supporting fractions to maintain more precision in
calculations. I wonder if this should fall outside the scope of a
standard library and be implemented in an external library. I'd lean
toward inclusion in stdlib.

A couple of thoughts, which should result in zero breakage of existing
code:

1. Mirror `decimal.Decimal`, allowing expression of fraction with
something like `fraction.Fraction(numerator, denominator)`. 
2. Add a new division operator that yields `fraction.Fraction`.

Paul


On Fri, 2021-05-14 at 12:12 +, Martin Teichmann wrote:
> Hi list,
> 
> when dividing two integers, the result is a float, which means we
> immediately lose precision. This is not good if you want to use code
> which supports higher precision. Decimals come to mind, but also
> sympy. This loss of precision could be avoided if the result of a
> division is a fraction instead: a fraction is exact.
> 
> So when writing Decimal(1/3), currently we lose the precision in the
> division, something that the Decimal module cannot undo. With my
> proposal, the entire precision is retained, and it works as expected.
> This is even more clear for sympy, a Package for symbolic
> calculations: currently, sympy cannot do much about "1/2 * m * v**2",
> although it looks like a perfectly fine formula. But sympy only sees
> "0.5" instead of "1/2", which is not usable in symbolic calculations.
> 
> I am aware that this would be a huge change. But we have had such a
> change in the past, from integers having a floor division in Python
> 2, to a float in Python 3. Compared to this, this is actually a small
> change: the value of the result is only different by the small
> pecision loss of floats. The bigger problem is caused by the fact
> that some code may rely on the fact that a value is a float. This can
> be fixed easily by simply calling float(), which is also backwards-
> compatible, it will work on older versions of Python as well.
> 
> I have prototyped this here:
> https://github.com/tecki/cpython/tree/int-divide-fraction
> The prototype uses the fractions.Fraction class written in Python as
> result for integer true divisions. I expected that to go horribly
> wrong, but astonishingly it did not. Only a small number of tests of
> Python fail, mostly those where it is explicitly tested whether an
> object is a float. So I lowered the bar even more and tried to
> compile and test numpy. And also there, except some tests that very
> explicitly require floats, it worked fine.
> 
> In order to showcase how that would look like, let me give an example
> session:
> 
>     >>> 5/6-4/15
>     17/30
>     >>> a=22/7
>     >>> f"{a}"
>     '22/7'
>     >>> f"{a:f}"
>     '3.142857'
>     >>> from decimal import Decimal
>     >>> Decimal(1/3)
>     Decimal('0.')
> 
> As a comparison, the same with current Python:
> 
>     >>> 5/6-4/15
>     0.5667
>     >>> a=22/7
>     >>> f"{a}"
>     '3.142857142857143'
>     >>> f"{a:f}"
>     '3.142857'
>     >>> from decimal import Decimal
>     >>> Decimal(1/3)
>    
> Decimal('0.14829616256247390992939472198486328125')
> 
> Cheers
> 
> Martin
> ___
> 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/RM4JDTGQCOW3MGIKIGEP2BIFOTFFAZI4/
> 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/HUMMOSBZYLSPP7NOMBD3Z4MSQ3VBDKBK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`

[Paul Bryan]

+1

On Sun, 2021-05-09 at 16:45 +, Thomas Grainger wrote:
> now that python2.7 is EOL, it might be worth resurrecting this syntax
> as discussed in https://www.python.org/dev/peps/pep-3100/#id13
> 
> eg, python 3.11 could support
> ```
> try:
>     ...
> except (E1, E2, E3) as e:
>     ...
> ```
> 
> as equivalent to 
> 
> ```
> try:
>     ...
> except E1, E2, E3 as e:
>     ...
> ```
> 
> see also
> https://mail.python.org/archives/list/python-...@python.org/thread/HSN6ESRB4BD6IUIPKLMNP4TPBQPWHBFK/
> ___
> 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/WQOMBT4Z22EIFB53WN54E52AYS3QBKAV/
> 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/GERIYIVX6XGH6JILDWSF4ISKC5IWQ3MN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespaces!

[Paul Bryan]

Response inline.

On Mon, 2021-05-03 at 23:30 +0100, Matt del Valle wrote:
> @Paul Bryan, I'll try to address your questions one-by-one
> 
> > 1. It seems that I could get close to what you're aiming for by
> > just using underscores in names, and grouping them together in the
> > class definition. Is there any advantage to declaring methods in a
> > namespace beyond indentation and the dot notation?
> > 
> 
> 
> What you're suggesting (using underscores for namespacing) is
> something I've seen done many times (and done myself plenty of times)
> and it's precisely one of the main things that I think could be
> better under this proposal. Reusing a prefix like that across methods
> has always felt a bit hacky to me and like it doesn't follow the DRY
> principle very well. If you wanted to rename the prefix at a later
> point you would have to go through every single method that uses it,
> instead of just doing a single refactor/rename on the name at the top
> of the namespace block.

Sure, it's a bit hacky, but virtually every editor can do it in a few
keystrokes, assuming no naming collision that requires you to cherry-
pick values to be substituted.

> But you've pretty much perfectly identified the benefits here, I'll
> just elaborate on them a bit.
> 
> - the indentation visually separates blocks of conceptually-grouped
> attributes/methods in the actual code (a gain in clarity when code is
> read)
> - the dot notation you use to invoke such methods improves the
> experience for library consumers by giving a small amount
> conceptually-linked autocompletions at each namespace step within a
> class with a large API, rather getting a huge flat list.
> 
> Furthermore, the proposed namespaces have other selling-points
> outside of the use-case of grouping methods within a class.
> 
> While the benefit of namespaces within modules is more dubious
> because you can use class blocks for namespacing (and people often
> do),  can see a few ways that the namespace proposal is better:
> 
> - you can put functions inside a namespace block, which would become
> methods if you had put them in a class block
> - you don't have the same (in some cases extremely unintuitive)
> scoping/variable binding rules that you do within a class block (see
> the link in my doc). It's all just module scope.
> - it mode clearly indicates intent (you don't want a whole new class,
> just a new namespace)
> 
> When using the namespaces within a method (using self):
> 
> - It allows you to namespace out your instance attributes without
> needing to create intermediate objects (an improvement to the memory
> footprint, and less do-nothing classes to clutter up your codebase)
> - While the above point of space complexity will not alway be
> relevant I think the more salient point is that creating intermediate
> objects for namespacing is often cognitively more effort than it's
> worth. And humans are lazy creatures by nature. So I feel like having
> an easy and intuitive way of doing it would have a positive effect on
> people's usage patterns. It's one of those things where you likely
> wouldn't appreciate the benefits until you'd actually gotten to play
> around with it a bit in the wild. For example, you could rewrite
> this:
> 
> class Legs:
> def __init__(self, left, right):
> self.left, self.right = left, right
> 
> 
> class Biped:
> def __init__(self):
> self.legs = Legs(left=LeftLeg(), right=RightLeg())
> 
> As this:
> 
> class Biped:
> def __init__(self):
> namespace self.legs:
> left, right = LeftLeg(), RightLeg()
> 
> And sure, the benefit for a single instance of this is small. But
> across a large codebase it adds up. It completely takes away the
> tradeoff between having neatly namespaced code where it makes sense
> to do so and writing a lot of needless intermediate classes. 

So, is it a prerequisite that whatever object in which I'm trying to
establish a namespace must support getattr/setattr?

Also, it occurs to me that if I can declare a namespace in any object,
I might be tempted to (or might inadvertently) monkey patch external
objects with it. Any thoughts on guarding against that, or is this
"we're adults here" case?

> SimpleNamespace does not help you here as much as you would think
> because it cannot be understood by static code analysis tools when
> invoked like this:
> 
> class Biped:
> def __init__(self):
> self.legs = SimpleNamespace(left=LeftLeg(), right=RightLeg())
> 
> So it is a terrible idea to use it in this way to write any kind of
> library code. You could invoke it declaratively:
> 
> class Biped:
> def __in

[Python-ideas] Re: Namespaces!

[Paul Bryan]

Correction:

4. What would you expect getattr(A.B, "C") to yield?

Paul

On Mon, 2021-05-03 at 12:10 -0700, Paul Bryan wrote:
> I've read the proposal, and this thread.
> 
> Questions:
> 
> 1. It seems that I could get close to what you're aiming for by just
> using underscores in names, and grouping them together in the class
> definition. Is there any advantage to declaring methods in a
> namespace beyond indentation and the dot notation?
> 
> 2. If __dict__ contains "B.C" and "B", then presumably the
> interpreter would need to try combinations against the outer __dict__
> as well as B. Is the namespace proxy you've mentioned intended to
> prevent further lookup in the "B" attribute?
> 
> 3. Can namespaces be nested? If so, will their attributed they always
> resolve to flat set of attributes in the encapsulating class?
> 
> 4. What would you expect getattr("A.B", "C") to yield?
> 
> Paul
> 
> On Mon, 2021-05-03 at 19:49 +0100, Stestagg wrote:
> > The first example in the doc lays out the difference:
> > 
> > Assignments within the namespace block have this special behaviour
> > whereby the assigned-to name is changed to be:
> > ‘.’
> > And the assignment is made in the ‘parent scope’ of the namespace.
> > 
> > I.e. (again, as described in the doc):
> > 
> > class A:
> >     Namespace B:
> >         C = 1
> > 
> > Results in:
> > 
> > A.__dict__ == {‘B.C’: 1, ‘B’: }
> > 
> > Note the ‘B.C’ entry
> > 
> > Now for me, the only place where is starts to be interesting is
> > with methods within namespaces, where the ‘self’ binding is made
> > against to top-level class, and not against the namespace.  This
> > does make for some nicer nested API definitions (a-la pandas
> > DataFrame.str.xxx methods) where an intermediate name os used just
> > to group and organise methods.
> > 
> > 
> > 
> > On Mon, 3 May 2021 at 19:40, David Mertz  wrote:
> > > On Mon, May 3, 2021 at 6:37 PM Stestagg 
> > > wrote:
> > > > On Mon, 3 May 2021 at 19:24, David Mertz 
> > > > wrote:
> > > > > So yes... as I thought, SimpleNamespace does EVERYTHING
> > > > > described by the proposal, just without needing more
> > > > > keywords:
> > > > > 
> > > > 
> > > > 
> > > > Except that the code and description of the proposal explicitly
> > > > outline behaviours that SimpleNamespace does not provide (and
> > > > aren’t trivially possible to add)
> > > > 
> > > 
> > > 
> > > I've looked and been unable to find an example of that. Can you
> > > show one?
> > > 
> > > 
> > > 
> > > ___
> > > 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/YTARLBP3TIARJ4FUEPPDZAUIS33P2C3Q/
> > > 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/UAZBIPDC3DRSA5A2GST72KDO2Y2R6RBX/
> 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/Q2OTIBAPH7GUBAMKOY3DF3HZWQI4OZMO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespaces!

[Paul Bryan]

I've read the proposal, and this thread.

Questions:

1. It seems that I could get close to what you're aiming for by just
using underscores in names, and grouping them together in the class
definition. Is there any advantage to declaring methods in a namespace
beyond indentation and the dot notation?

2. If __dict__ contains "B.C" and "B", then presumably the interpreter
would need to try combinations against the outer __dict__ as well as B.
Is the namespace proxy you've mentioned intended to prevent further
lookup in the "B" attribute?

3. Can namespaces be nested? If so, will their attributed they always
resolve to flat set of attributes in the encapsulating class?

4. What would you expect getattr("A.B", "C") to yield?

Paul

On Mon, 2021-05-03 at 19:49 +0100, Stestagg wrote:
> The first example in the doc lays out the difference:
> 
> Assignments within the namespace block have this special behaviour
> whereby the assigned-to name is changed to be:
> ‘.’
> And the assignment is made in the ‘parent scope’ of the namespace.
> 
> I.e. (again, as described in the doc):
> 
> class A:
>     Namespace B:
>         C = 1
> 
> Results in:
> 
> A.__dict__ == {‘B.C’: 1, ‘B’: }
> 
> Note the ‘B.C’ entry
> 
> Now for me, the only place where is starts to be interesting is with
> methods within namespaces, where the ‘self’ binding is made against
> to top-level class, and not against the namespace.  This does make
> for some nicer nested API definitions (a-la pandas DataFrame.str.xxx
> methods) where an intermediate name os used just to group and
> organise methods.
> 
> 
> 
> On Mon, 3 May 2021 at 19:40, David Mertz  wrote:
> > On Mon, May 3, 2021 at 6:37 PM Stestagg  wrote:
> > > On Mon, 3 May 2021 at 19:24, David Mertz  wrote:
> > > > So yes... as I thought, SimpleNamespace does EVERYTHING
> > > > described by the proposal, just without needing more keywords:
> > > > 
> > > 
> > > 
> > > Except that the code and description of the proposal explicitly
> > > outline behaviours that SimpleNamespace does not provide (and
> > > aren’t trivially possible to add)
> > > 
> > 
> > 
> > I've looked and been unable to find an example of that. Can you
> > show one?
> > 
> > 
> > 
> > ___
> > 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/YTARLBP3TIARJ4FUEPPDZAUIS33P2C3Q/
> > 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/UAZBIPDC3DRSA5A2GST72KDO2Y2R6RBX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing The Theme of Python Docs Site

[Paul Bryan]

I think improving the online documentation is a good idea.

How can this effort avoid merely addressing subjective preferences?
Beauty in the eye of the beholder, and all that.

This appears to be the current style guide:
https://devguide.python.org/documenting/

It largely focuses on content. Would it be worth codifying additional
aesthetic and usability objectives, and build consensus around them?

Are there other sites that have refreshed their styles we can learn
from? For example, Wikipedia did a refresh last year.

Paul


On Mon, 2021-05-03 at 13:57 +0400, Abdur-Rahmaan Janhangeer wrote:
> Time from someone clever with CSS in Sphinx may be all it takes.
> 
> Yes, agree 👍, i am not suggesting other
> docs systems but just reconsidering the style.
> 
> @Marc indeed raised the question of overall
> consistency which i guess will be addressed one 
> day or the other. As for the wiki besides, look
> there are many, many issues in terms of outdated
> content.
> ___
> 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/WLKNFY52PSOQFK5TKPI2APTLDVLO3RSH/
> 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/QVBOKPU2KNEDRTMQEICR73MB6AYTVWFD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing The Theme of Python Docs Site

[Paul Bryan]

On Sun, 2021-05-02 at 23:07 +0400, Abdur-Rahmaan Janhangeer wrote:

> Oh seems like you are a dinosaur needing some carbon dating.

It seems you need to review the Python Community Code of Conduct:
https://www.python.org/psf/conduct/

Please see the sections regarding being respectful and insults, jokes
or put downs.

Paul

___
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/DYXHQOGPGHMNKYPIOO2R6JNVFXBMM6QB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing The Theme of Python Docs Site

[Paul Bryan]

A recipe to have an idea be marginalized or ignored:

1. Start by denigrating the work of others with pejoratives like
"cranky" and "unpleasant".
2. Do not provide any support to back such a claim, or call out any
specific usability issue. 
3. Imply that the content is deficient, without qualification.
4. Point to something that you just seem to like better, without
comparison.
5. (Probably) expect others to implement your idea. Your work here is
done.

Paul

On Fri, 2021-04-30 at 10:06 +0400, Abdur-Rahmaan Janhangeer wrote:
> Greetings,
> 
> A proposal to change the theme of the 
> Python docs. Great softwares are not 
> distinguished by docs crankiness and
> unpleasantness. 
> 
> Though what's more important is the 
> content, nevertheless it can be made 
> more enjoyable to read.
> 
> The Masonite docs for example is quite
> nice: 
> https://docs.masoniteproject.com/
> 
> Kind Regards,
> 
> Abdur-Rahmaan Janhangeer
> about | blog 
> github
> Mauritius
> ___
> 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/TMK7ROBHGDFBPHXID7R3FAD23VSGK7FH/
> 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/KS2MKJVC7PPNAAQUMDDKP5XKZHUSWYQ3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Greek alphabet in built-in`string` module

[Paul Bryan]

I agree. It would be great to get something more than what the
simplistic `unicodedata.category(...)` returns; for example, what
Unicode group a character falls in.

On Sat, 2021-04-10 at 00:29 +1000, Chris Angelico wrote:
> On Sat, Apr 10, 2021 at 12:15 AM Paul Bryan  wrote:
> > 
> > This sounds more like a Unicode thing than a generic string thing.
> > And, in Uncode, Greek characters are included in multiple
> > groupings. Searching for "Theta" to see what we get:
> > 
> > Greek and Coptic:
> > U+0398 GREEK CAPITAL LETTER THETA
> > U+03B8 GREEK SMALL LETTER THETA
> > U+03D1 GREEK THETA SYMBOL
> > U+03F4 GREEK CAPITAL THETA SYMBOL
> > 
> > Phonetic Extensions Supplement:
> > U+1DBF MODIFIER LETTER SMALL THETA
> > 
> > Mathematical Alphanumeric Symbols:
> > U+1D6AF MATHEMATICAL BOLD CAPITAL THETA
> > U+1D6B9 MATHEMATICAL BOLD CAPITAL THETA SYMBOL
> > U+1D6C9 MATHEMATICAL BOLD SMALL THETA
> > (... 17 more Thetas in this group! ...)
> > 
> > If you were to pick a definitive set of Greek characters for your
> > use case, would it be in the Mathematical Alphanumeric Symbols
> > category? Would others' expected use of Greek characters match
> > yours, or would it need to be inclusive of all Greek characters
> > across groupings?
> > 
> > I'm beginning to sense a metal container containing wriggly
> > things...
> > 
> 
> But I think you've also nailed the correct solution. Python comes
> with
> [1] a unicodedata module, which would be the best way to define these
> sorts of sets. It's a tad messy to try to gather the correct elements
> though, so maybe the best way to do this would be a
> unicodedata.search() function that returns a string of all characters
> with a particular string in their names, or something like that.
> 
> ChrisA
> 
> [1] technically, CPython and many other implementations come with,
> but
> there are some (eg uPy) that don't
> ___
> 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/5MRAFMNZQ27DDAA7ZRD2E55OAFKWD734/
> 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/RJBE2WZV4BM2INB2HR7FLHOR45XM73MB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Greek alphabet in built-in`string` module

[Paul Bryan]

This sounds more like a Unicode thing than a generic string thing. And,
in Uncode, Greek characters are included in multiple groupings.
Searching for "Theta" to see what we get:

Greek and Coptic:
U+0398 GREEK CAPITAL LETTER THETA
U+03B8 GREEK SMALL LETTER THETA
U+03D1 GREEK THETA SYMBOL
U+03F4 GREEK CAPITAL THETA SYMBOL

Phonetic Extensions Supplement:
U+1DBF MODIFIER LETTER SMALL THETA

Mathematical Alphanumeric Symbols:
U+1D6AF MATHEMATICAL BOLD CAPITAL THETA
U+1D6B9 MATHEMATICAL BOLD CAPITAL THETA SYMBOL
U+1D6C9 MATHEMATICAL BOLD SMALL THETA
(... 17 more Thetas in this group! ...)

If you were to pick a definitive set of Greek characters for your use
case, would it be in the Mathematical Alphanumeric Symbols category?
Would others' expected use of Greek characters match yours, or would it
need to be inclusive of all Greek characters across groupings?

I'm beginning to sense a metal container containing wriggly things...

Paul

On Fri, 2021-04-09 at 12:59 +, mitchell.negus...@gmail.com wrote:
> I was wondering if it might be reasonable to consider adding a set of
> Greek letters to the constants in the `string` module. In my mind,
> the format would follow the existing convention—constants for both
> `greek_lowercase` and `greek_uppercase`, as well as a combined
> constant `greek_letters`.
> 
> Judging by how these constants are defined in the module, this seems
> like it might be an almost trivially easy addition (with minimal
> future maintenance required), and could provide a neat little
> functionality. Where Python 3 already uses unicode strings, I don't
> believe this would cause any backward compatibility issues. 
> 
> The only one drawback I can see might be polluting the namespace if
> it is not a commonly used feature. That said, the Greek alphabet is
> used so commonly in math/science that I'd hazard a guess it might be
> valuable for some, especially as unicode becomes increasingly
> prevalent. Obviously developers could build their own similar
> constant just by creating a string with those characters, but this
> would save a step, whether that's adding a dependency or
> copying/pasting a handful of characters. I also anticipate that the
> argument may come up that this opens a can of worms, and then why not
> include even more symbols. I think that is a valid concern, though I
> think the Greek alphabet is somewhat unique in it's prevalence (due
> to it's use in math/science), on top of the fact that it is both
> limited and permanent (in a way that things like logograms and emojis
> may not be).
> 
> I'm certainly not an expert on the Python source code though, so
> please correct me if there's an obvious reason not to add this or if
> this has been debated before :)
> ___
> 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/STABL2VLT2XQV3XO6S7OBVAABJR6QVEN/
> 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/6PBD5CGGX6RT6WAP5W5RIZQ7TBZ2RVOQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python Idea - extension of 'with'

[Paul Bryan]

I think I like it.

Q. Safe to assume this would catch exceptions from both the call to
`open` as well as the call to `open.__enter__`?

Q. What about something even more verbose (descriptive) like`try with
open(...) as cfg:`?  🙂

Paul


On Thu, 2021-04-08 at 15:59 +0100, anthony.flury via Python-ideas
wrote:
> We are all familiar with the `with` statement for context managers,
> so that the resources are correctly finalized/closed in case of an
> exception either in terms
> of the resources being allocated of the processing.
> It is very common though to wrap the `with block` in an outer `try`
> block, since although we know that the resource has been closed, at
> an 'application' level it is still neccessary
> to deal with the exception - an example might be : 
> 
> > 
> > try:
> >     with open('config.cfg', 'r') as cfg:
> >         # Process the open  file
> >     config = load_config(cfg)
> > except FileNotFound:
> >     logging.info('Config file not found - using default
> > configuration')
> > except PermissionError:
> >     logging.warning('Cannot open config .cfg - using default
> > configuration')
> >     config = default_config()
> > else:
> >     logging.info('Using config from config.cfg')
> > 
> It struck me that this is probably quite a common idiom, and we have
> the main processing (of the opened resources) indented twice just to
> accommodate
> the outer try block.
> I was wondering whether a worthwhile extension might be to allow the
> `with` statement to have an `except` and  `else` clauses which would
> have the same
> semantics as wrapping the `with` block with a try - for example the
> above would now look like:
> 
> > 
> > with open('config.cfg', 'r') as cfg:
> >     # Process the open  file
> >     config = load_config(cfg)
> > except FileNotFound:
> >     logging.info('Config file not found - using default
> > configuration')
> > except PermissionError:
> >     logging.warning('Cannot open config .cfg - using default
> > configuration')
> >     config = default_config()
> > else:
> >     logging.info('Using config from config.cfg')
> > 
> Treating the 'with' as an implied `try` would reduce the march to the
> right - now the key processing of the resource is now indented only
> one level - and the association of the exception
> from the `with` block is syntactically clear.
> I am not good enough with core development to put together a working
> prototype, but I can imagine that this simple extension would be
> worth while, but I would be more than happy to author a PEP for this
> if it gets some initial positive feedback.
> Open questions - that I have - should we allow `except`, `else` and
> `finally` clauses (or just `except` and `else` - do we need `finally`
> here).
> -- 
> Anthony Flury
> Moble: +44 07743 282707
> Home: +44 (0)1206 391294
> email: anthony.fl...@btinternet.com    
> ___
> 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/ITNCZD2GOQS7TQF7XYFWFYABDP5ZNS5G/
> 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/BG3RT7F7FKCBURC45HCBQXPZL4FPOAOD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allow Annotated annotation in dataclass

[Paul Bryan]

Haven't seen a reply to this yet, so I'll start the bidding at 2¢.

Generally, I like the idea of using Annotated in this fashion. I'm
currently using it for expressing validation rules and hints about how
parameters are handled in HTTP requests. Handy!

If = field(...) weren't already established, I'd say it should be as an
annotated value instead of an assignment. Since = field(...) pattern is
well established, I'm not so sure what the value would be of changing
this in dataclass now.

Paul

On Sat, 2021-04-03 at 20:57 +, brianmar...@gmail.com wrote:
> typing.Annotated could be used to build dataclasses. Using Annotated
> will allow libraries to add functionality to a dataclass without
> having to change dataclass creation or behavior. The example below
> shows how a dataclass could be implemented. It continues the example
> of struct2 shown in pep593. From a dataclass point of view, the
> Sample and AnnotatedSample would be equivalent.
> 
> ```python
> @dataclass
> class Sample:
>     a: int
>     b: int
>     c: int = field(default=5)
>     d: int = 10
>     e: int = field(default=10)
> 
> 
> @packed
> @dataclass
> class AnnotatedSample:
>     a: Annotated[int, ctype("I")]
>     b: int
>     c: Annotated[int, field(default=5), ctype("I")]
>     d: Annotated[int, ctype("h")] = 10
>     e: Annotated[int, ctype("h")] = field(default=10)
> 
> out_bytes = struct2.pack(AnnotatedSample())
> ```
> When parsing the Annotated parameters, the dataclass decorator will
> only look at the type parameter and ```field``` parameter if present.
> If not Annotated, it falls back to existing behavior.
> 
> Let me know what you think. 
> Thanks!
> ___
> 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/TI4ZHEJSP5NWPO4NHR2EKNZQYLZMGR2J/
> 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/7MDAK2NUFUCMVDYDV3NG3FI2QZFA6AA3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allow syntax "func(arg=x if condition)"

[Paul Bryan]

I've encountered the same issue, either matching the default values in
the else clause (and hoping they won't later be changed) or having to
revert to building a kwargs dict, and then in multiple `if` statements,
conditionally including arguments.

I've also felt this same pain building dicts with conditionally-
included items. I can't recall such pain with lists as illustrated, or
with list comprehensions for that matter.

+0 on the suggested syntax. I can't comment on complexity to implement
in the interpreter.

 
On Sat, 2021-03-20 at 14:36 -0700, Peter O'Connor wrote:
> bump!
> 
> On Wed, Jan 13, 2021 at 9:32 AM Peter O'Connor
>  wrote:
> > I often find that python lacks a nice way to say "only pass an
> > argument under this condition".  (See previous python-list email in
> > "Idea: Deferred Default Arguments?")
> > 
> > Example 1: Defining a list with conditional elements
> >     include_bd = True
> >     current_way = ['a'] + (['b'] if include_bd else
> > [])+['c']+(['d'] if include_bd else [])
> >     new_way = ['a', 'b' if include_bd, 'c', 'd' if include_bd]
> >     also_new_way = list('a', 'b' if include_bd, 'c', 'd' if
> > include_bd)
> >     
> > Example 2: Deferring to defaults of called functions
> >     def is_close(a, b, precicion=1e-9): 
> >         return abs(a-b) < precision
> > 
> >     def approach(pose, target, step=0.1, precision=None):  
> >        # Defers to default precision if not otherwise specified:
> >         velocity = step*(target-pose) \
> >             if not is_close(pose, target, precision if precision is
> > not None) \  
> >             else 0 
> >         return velocity
> > 
> > Not sure if this has been discussed, but I cannot see any clear
> > downside to adding this, and it has some clear benefits (duplicated
> > default arguments and **kwargs are the scourge of many real world
> > code-bases)
> > 
> ___
> 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/KM2Y3BFF2GDVPS56Z7TX2VMZXJEKKRHZ/
> 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/TS4GOT6VU3QK6G2GJ2OFUL4F3VS7RDXI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Dataclass (or get_type_hints) wishlist item: Optional[...]

[Paul Bryan]

With some of the dataclass threads in python-ideas ongoing, I wanted to
add another to the fray.

There's an area where typing.get_type_hints on dataclass and __init__
produce inconsistent results. Example:

@dataclass
class Foo:
    x: int = None

>>> typing.get_type_hints(Foo)
{'x': }

>>> typing.get_type_hints(Foo.__init__)
{'x': typing.Optional[int], 'return': }

My wish list item would be for the dataclass annotations to match
__init__'s.

Rationale: by explicitly specifying a default value of a different
type, the resulting type annotation for the field should be a Union of
the specified type and the type of the default value.

I might go so far as to say this could be how the type hints of
function parameters should be encoded. Example to illustrate my
thoughts—it does not work this way presently:

def foo(x: str = 1):
    ...

>>> typing.get_type_hints(foo)
{'x': typing.Union[str, int]}

This example could be construed as an error that a static type checker
should catch and flag; if this is the consensus, then I fall back on
the proposal to only supporting Union[type, None]—i.e.
Optional[type]—which is how get_type_hints performs currently.

Thoughts?

Paul
___
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/PC6RHDXNRIDBRDJAPXR5W32OCT7AQ4SO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dataclasses: position-only and keyword-only fields

[Paul Bryan]

+1 to Matt's points here. I get the desire for symmetry with / and * in
params, but I'm not convinced it's useful enough to warrant the
complexity of the approaches being proposes. I think a @dataclass(...,
kwonly=True) would solve > 90% of the issues with dataclass usability
today.

On Sat, 2021-03-13 at 06:41 -0500, Matt Wozniski wrote:
> On Fri, Mar 12, 2021, 11:55 PM Eric V. Smith 
> wrote:
> > There have been many requests to add keyword-only fields to
> > dataclasses. 
> > These fields would result in __init__ parameters that are keyword-
> > only. 
> > As long as I'm doing this, I'd like to add positional-only fields
> > as well.
> 
> Have there also been requests for positional-only fields?
> 
> 
> The more I digest this idea, the more supporting positional-only
> fields sounds like a bad idea to me. The motivation for adding
> positional-only arguments to the language was a) that some built-in
> functions take only positional arguments, and there was no consistent
> way to document that and no way to match their interface with pure
> Python functions, b) that some parameters have no semantic meaning
> and making their names part of the public API forces library authors
> to maintain backwards compatibility on totally arbitrary names, and
> c) that functions like `dict.update` that take arbitrary keyword
> arguments must have positional-only parameters in order to not
> artificially reduce the set of keyword arguments that may be passed
> (e.g., `some_dict.update(self=5)`).
> 
> None of these cases seem to apply to dataclasses. There are no
> existing dataclasses that take positional-only arguments that we need
> consistency with. Dataclasses' constructors don't take arbitrary
> keyword arguments in excess of their declared fields. And most
> crucially, the field names become part of the public API of the
> class. Dataclass fields can never be renamed without a risk of
> breaking existing users. Taking your example from the other thread:
> 
> ```
> @dataclasses.dataclass
> class Comparator:
>     a: Any
>     b: Any
>     _: dataclasses.KEYWORD_ONLY
>     key: Optional[Callable[whatever]] = None
> ```
> 
> The names `a` and `b` seem arbitrary, but they're not used only in
> the constructor, they're also available as attributes of the
> instances of Comparator, and dictionary keys in the `asdict()`
> return. Even if they were positional-only arguments to the
> constructor, that would forbid calling
> 
> comp = Comparator(a=1, b=2, key=operator.lt)
> 
> but it would still be possible to call
> 
> comp = Comparator(1, 2, key=operator.lt)
> print(comp.a, comp.b)
> 
> Preventing them from being passed by name to the constructor seems to
> be adding an inconsistency, not removing one.
> 
> Perhaps it makes sense to be able to make init-only variables be
> positional-only, since they don't become part of the class's public
> API, but in that case it seems it could just be a flag passed to
> `InitVar`. Outside of init-only variables, positional-only arguments
> seem like a misfeature to me.
> 
> ~Matt
> 
> ___
> 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/LPUHXVDHW7QQR4KNOQQTNWT6UJ2CHDBI/
> 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/DWMTQCOHZG233R5POM74RUTOYP3AV6FH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[Paul Bryan]

Using your example (thanks, seeing a concrete example is helpful) it
appears you can do it the SQL way in Python too:

x = (1
,2
,3
)


On Fri, 2021-03-12 at 16:35 -0500, Eric V. Smith wrote:
> On 3/12/2021 3:37 PM, Greg Ewing wrote:
> > On 13/03/21 5:02 am, Ned Batchelder wrote:
> > > I think the only reason anyone ever used leading commas to begin
> > > with 
> > > was because of languages that didn't allow a final trailing
> > > comma.  
> > > In those worlds, to keep the editing smooth, people moved the
> > > commas 
> > > to the beginning of the line,
> > 
> > Which doesn't help unless the language allows leading commas that
> > are ignored, and I've never seen a language like that. 
> 
> Things are added to the end of lists more often than to the front.
> For 
> example, column names in SQL or parameters in Python.
> 
> Because SQL doesn't allow trailing commas, I've often seen things 
> written as:
> 
> select a
> ,b
> ,c
> ,d
> 
> Then when you want to add "e" to the end, you just duplicate the ",d"
> row and change "d" to "e".
> 
> For Python, you'd do:
> 
> select(a,
> b,
> c,
> d,
> )
> 
> And then similarly add "e," to the end.
> 
> Anyway, since Python already allows trailing commas, I see no need to
> add leading ones. Which is a feature I've never seen in any language,
> either. And it would make it slightly easier to leave off the first 
> parameter.
> 
> Eric
> 
> ___
> 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/R6AU26PL4QK5LFMW25PP2VUVLFSTDGX6/
> 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/TDAA4F7S55KS2UHDKJTN6SFBHKDGYTYF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Implicit line continuation for method chaining

[Paul Bryan]

My inclination would be to cede code formatting to a tool like Black
and focus on function:
https://black.readthedocs.io/en/stable/


On Fri, 2021-03-12 at 15:32 +, Matt Williams wrote:
> Hi,
> 
> It's becoming more popular in Python to have interfaces which are
> built around method chaining as a way of applying operations to data.
> For example in pandas is moving more towards a default model where
> methods do not change the object in-place but instead return an
> altered version (or at least an altered view) of it.
> 
> The major downside to method chaining is that it ends up creating
> long lines of code which can become hard to read. The two main
> solutions to this are 1) break down the chain and give the steps
> their own variable names and 2) split it over multiple lines using
> `\` as a line continuation.
> 
> e.g.:
> 
>   y = x.rstrip("\n").split(":")[0].lower()
> 
> would become
> 
>   y = x.rstrip("\n") \
>    .split(":")[0] \
>    .lower()
> 
> I find the continuation character visually distracting, easy to
> forget and does not allow for line-by-line commenting (causing
> `SyntaxError: unexpected character after line continuation
> character`):
> 
>   y = x.rstrip("\n") \
>    .split(":")[0] \  # grab the key name
>    .lower()
> 
> My idea is to alter the syntax of Python to allow doing:
> 
>   y = x.rstrip("\n")
>    .split(":")[0]
>    .lower()
> 
> i.e., not requiring an explicit line continuation character in the
> case where the next line starts with a period.
> 
> I've had a search through the archives and I couldn't see this
> discussion before. Feel free to point me to it if I've missed
> anything.
> 
> Cheers,
> Matt
> ___
> 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/LWB3U5BTGC4CT26U4AB676SKGED3ZOEX/
> 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/X7NMRC4FMO4LBB7E2XP4D76FXZ5MMZVY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[Paul Bryan]

It seems your proposal is intended to address an aesthetic concern. Is
there a case where using a leading comma would make something
actually easier or more intuitive to express over the use of trailing
comma?

On Fri, 2021-03-12 at 10:34 +, roland.puntaier--- via Python-ideas
wrote:
> I had posted this as https://github.com/python/peps/issues/1867
> The discussion so far is below.
> 
> Please make some arguments.
> 
> The major point to me is, that the symmetry is broken,
> which leads to extra editing actions, like removing the comma in the
> first line.
> I guess, this was the reason to allow the comma after the last
> line/entry: `[1,2,]`.
> ``[,1,2]`` should also be allowed, too.
> 
> The best argument is one that says: less or more effort in this or
> that situation.
> For example, with `[1,2,]`, in line-wise formatting,
> one can do without special action at the last line (removing the
> comma there).
> 
> All code from previous versions of Python would still work
> after a `[,1,2]` syntax allowance were introduced.
> 
> 
> =
> 
> rpuntaie wrote:
> =
> 
> 
> Allow initial comma
> ===
> 
> Final comma works:
> 
>     t = (
>  1,
>  2,
>     )
>     x = [
>  1,
>  2,
>     ]
>     y = {
>  1,
>  2,
>     }
>     z = {
>  1:11,
>  2:22,
>     }
>     def fun(
>   a,
>   b,
>  ):
>   pass
> 
> Initial comma does not work:
> 
>     t = (
>  , 1
>  , 2
>     )
>     x = [
>  , 1
>  , 2
>     ]
>     y = {
>  , 1
>  , 2
>  }
>     z = {
>  , 1:11
>  , 2:22
>  }
>     def fun(
>  , a
>  , b
>  ):
>   pass
> 
> 
> To make the syntax symmetric in this regard\
> gives more freedom to format the code.
> 
> I occasionally found the restriction an unnecessary nuisance.
> 
> Before writing a PEP, I would like to discuss,
> 
> -   whether something like that has been proposed already?
> -   what counter-arguments there could be?
> 
> =
> 
> pxeger wrote:
> =
> 
> 
> This is not the appropriate place to propose language changes.
> Try the [python-
> ideas](https://mail.python.org/mailman3/lists/python-ideas.python.org/
> )
> mailing list. However, I don't think you'll get anyone to agree.
> 
> What kind of code style are you using where you want to put commas at
> the start of the line? That is totally non-standard
> (see [PEP 8](https://www.python.org/dev/peps/pep-0008)), ugly, and
> confusing.
> 
> Arbitrary symmetry is not a good reason for changing the language. We
> don't have a `tnirp` function just for the sake of symmetry with
> `print` because it would be pointless and add extra complication
> 
> 
> =
> 
> rpuntaie wrote:
> =
> 
> 
> I surely agree, that not ignoring the sequence is essential. Else one
> would loose identifier space and thus information. I would never have
> the idea to make all permutations of `p.r.i.n.t` point to the same
> function. Therefore you just made a bad example.
> 
> But the comma is just a separator. Why did they allow to have the
> comma before a closing bracket/parenthesis/brace? Because of symmetry
> between lines, is my guess.
> 
> Occasionally one sees many spaces just the have the final comma
> aligned vertically. That could be avoided by placing the comma at the
> beginning.
> 
> I personally also have a macro in the editor that evaluates a line in
> the parameter list, but drops an initial comma before doing that.
> Therefore this is my preferred formatting.
> 
> I don't think that [PEP](https://www.python.org/dev/peps/pep-0008)
> is wrong. I just don't want to be restricted by unnecessary rules.
> Rules need to have a reason beyond someone dictating them. If that is
> the case, I follow them, because I see the reason, but not because
> someone dictates them.
> 
> I'll go to
> [Python Ide
> as](https://mail.python.org/mailman3/lists/python-ideas.python.org/),
> then. Thanks.
> ___
> 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/E3HYA7AWLHTD3MCWVBRH7AT3GLGXFUOG/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas maili

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Paul Bryan]

The syntax of what you're proposing seems fairly intuitive (they might
not even need to be callable).  I'm struggling to envision how the
context manager would acquire scope to mark fields up in the (not yet
defined) dataclass, and to capture the attributes that are being
defined within.


On Thu, 2021-03-11 at 22:53 +, Matt del Valle wrote:
Disclaimer: I posted this earlier today but I think due to some first-
post moderation related issues (that I've hopefully now gotten sorted o

ut!) it may not have gone through. I'm posting this again just in case.

 If it's gone through and you've already seen it then I'm super sorry, 

please just ignore this.

If something like what you're suggesting were to be implemented I would

 much rather it be done with context managers than position-
dependent special values, because otherwise you once again end up in a 

situation where it's impossible to easily subclass a dataclass (which w

as one of the primary reasons this conversation even got started in the

 first place). So, for example: 

import dataclasses


@dataclasses.dataclass
class SomeClass:
c: bool = False
# a normal field with a default value does not
# prevent subsequent positional fields from
# having no default value (such as 'a' below)
# however, all further normal fields now must
# specify a default value (such as 'd' below)

with dataclasses.positional():
a: int
b: float = 3.14
# once a positional field with a default value shows up
# all further positional fields and ALL normal fields
# (even retroactively!) must also specify defaults
# (for example, field 'c' above is
# now forced to specify a default value)

with dataclasses.keyword():
e: list
f: set = dataclasses.field(default_factory=set)
# once a keyword field with a default value shows up
# all further keyword fields must also specify defaults

d: dict = dataclasses.field(default_factory=dict)
# This ordering is clearly insane, but the essential
# point is that it works even with weird ordering
# which is necessary for it to work when subclassing
# where the order will almost always be wonky
#
# A sane version of the above would be:


@dataclasses.dataclass
class SomeClass:
with dataclasses.positional():
a: int
b: float = 3.14

c: bool = False
d: dict = dataclasses.field(default_factory=dict)

with dataclasses.keyword():
e: list
f: set = dataclasses.field(default_factory=set)

# either of the above will generate an __init__ like:
def __init__(self, a: int, b: float = 3.14,
 /, c: bool = False, d: dict = None,
 *, e: list, f: set = None):
self.a = a
self.b = b
self.c = c
self.d = dict() if d is None else d
self.e = e
self.f = set() if f is None else f
# parameters are arranged in order as
# positional -> normal -> keyword
# within the order they were defined in each
# individual category, but not necessarily
# whatever order they were defined in overall
#
# This is subclass-friendly!
#
# it should hopefully be obvious that we could
# have cut this class in half at literally any
# point (as long as the the parent class has
# the earlier arguments within each category)
# and put the rest into a child class and
# it would still have worked and generated the
# same __init__ signature
#
# For example:


@dataclasses.dataclass
class Parent:
with dataclasses.positional():
a: int

c: bool = False

with dataclasses.keyword():
e: list


@dataclasses.dataclass
class Child(Parent):
with dataclasses.positional():
b: float = 3.14

d: dict = dataclasses.field(default_factory=dict)

with dataclasses.keyword():
f: set = dataclasses.field(default_factory=set)
# Child now has the same __init__ signature as
# SomeClass above

(In case the above code doesn't render properly on your screen, I've up

loaded it to GitHub at: https://github.com/matthewgdv/dataclass_arg_co
ntextmanager/blob/main/example.py)

Honestly, the more I think about it, the more I love the idea of someth
ing like this (even if it's not exactly the same as my suggestion). Rig
ht now dataclasses do not support the full range of __init__ signatures
 you could generate with a normal class, and they are extremely hostile
 to subclassing. That is a failing that often forces people to fall bac
k to normal classes in otherwise ideal dataclass use-case situations.

On Thu, Mar 11, 2021 at 10:15 PM Paul Bryan  wrote:
> If you're proposing something like this, then I think it would be com

> 
> patible:
> 
> class Hmm:
>  #
>  this: int
>  that: float
>  #
>

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Paul Bryan]

If you're proposing something like this, then I think it would be
compatible:

class Hmm:
 #
 this: int
 that: float
 #
 pos: PosOnly
 #
 these: str
 those: str
 #
 key: KWOnly
 #
 some: list


On Thu, 2021-03-11 at 14:06 -0800, Ethan Furman wrote:
> On 3/11/21 10:50 AM, Paul Bryan wrote:
> > On Thu, 2021-03-11 at 10:45 -0800, Ethan Furman wrote:
> > > On 3/10/21 9:47 PM, Eric V. Smith wrote:
> > > 
> > > > I'm not sure of the best way to achieve this. Using flags to
> > > > field()
> > > > doesn't sound awesome, but could be made to work. Or maybe
> > > > special
> > > > field names or types? I'm not crazy about that, but using
> > > > special
> > > > types would let you do something like:
> > > > 
> > > > @dataclasses.dataclass
> > > > class Point:
> > > >  x: int = 0
> > > >  _: dataclasses.KEYWORD_ONLY
> > > >  y: int
> > > >  z: int
> > > >  t: int = 0
> > > 
> > > Maybe something like this?
> > > 
> > >  class Hmm:
> > >  #
> > >  this: int
> > >  that: float
> > >  #
> > >  pos: '/'
> > >  #
> > >  these: str
> > >  those: str
> > >  #
> > >  key: '*'
> > >  #
> > >  some: list
> > > 
> > >  >>> Hmm.__dict__['__annotations__']
> > >  {
> > >  'this': ,
> > >  'that': ,
> > >  'pos': '/',
> > >  'these': ,
> > >  'those': ,
> > >  'key': '*',
> > >  'some': ,
> > >  }
> > > 
> > > The name of 'pos' and 'key' can be convention, since the actual
> > > name
> > > is irrelevant.  They do have to be unique, though.  ;-)
> > 
> > It's current convention (and is used by typing module and static
> > type
> > checkers) that string annotations evaluate to valid Python types.
> 
> So make '/' and '*' be imports from dataclasses:
> 
>  from dataclasses import dataclass, PosOnly, KWOnly
> 
> --
> ~Ethan~
> ___
> 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/6L4W5OB23FBWZ7EZYDNCYSGT2CUAKYSX/
> 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/VPSE34Z35XOXGFJMGTMLWDAMF7JKJYOJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add lazy import statement to protect legitimate circular imports from failing

[Paul Bryan]

It would be resolved at the time the value is accessed in the lazy map.
The map then stores the resultant value to avoid attempting to re-
import the module on every access.

On Fri, 2021-03-12 at 08:31 +1100, Chris Angelico wrote:
> On Fri, Mar 12, 2021 at 8:24 AM Paul Bryan  wrote:
> > 
> > Probably one of countless examples of performing lazy imports, for
> > precisely the reason of preventing circular imports:
> > https://github.com/fondat/fondat-core/blob/main/fondat/lazy.py
> > 
> 
> In the case of circular imports, at what point should the lazy import
> be resolved?
> 
> 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/J63KSEX5B3UC6SHQ4ZZJK4G4DUUTIUZW/
> 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/VM433CUAI634J67SYF32DZKJBCXMTNSC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add lazy import statement to protect legitimate circular imports from failing

[Paul Bryan]

Of course, you could encapsulate your imports inside of functions, that
import only once called. However, there are plenty of cases where that
is not practical.

Probably one of countless examples of performing lazy imports, for
precisely the reason of preventing circular imports:
https://github.com/fondat/fondat-core/blob/main/fondat/lazy.py

I would be happy if such a feature found its way into the language (in
the manner like you suggest). Setting aside the complexities in the
interpreter, it would possibly require a new keyword, which is a high
bar to clear.

On Thu, 2021-03-11 at 21:07 +, Matt del Valle wrote:
> I don't really have any knowledge of the Python interpreter's
> internals so I'm afraid any suggestions of mine on implementation
> details are going to be shots in the dark.
> 
> That said, my intuition tells me that something similar to the proxy
> object pattern currently used by many lazy import implementations
> maybe could work here, with the interpreter creating some sort of
> 'lazy import proxy' object on this line rather than performing the
> import:
> 
> > from .extremely_expensive_module lazy import SomeClass
> 
> 
> And then when it actually is used in any way as part of any code that
> isn't another lazy import statement (normal import statements and
> even assignment statements that don't modify the object or attempt to
> access its attributes would count) it actually gets fully imported at
> that point in time, and all references anywhere in the application to
> this 'lazy import proxy' are swapped to point at the real object.
> 
> You could have it so that if you tried to lazy import an object that
> is actually already a 'lazy import proxy' you would just get a
> reference to it rather than provisioning a new one. This would allow
> you to 'chain' lazy import statements across several modules to defer
> the import until the object (be it a module or a class) is actually
> used.
> 
> Since I don't know enough about the implementation of the interpreter
> I couldn't really say if there's a way that normal objects could just
> be treated precisely as they are now with no loss of performance,
> while still giving 'lazy import objects' their special treatment. I
> suppose that's part of the point of this discussion. Hopefully people
> who know more can chime in.
> 
> I definitely do think that there would be value in allowing all
> objects to be lazily imported via support for the 'from x import y'
> statement, not just modules, but I accept this is something people
> will have their own opinions on, and that mine isn't special. My
> earlier examples highlight situations where I think a lazy
> implementation of the normal 'import x' statement wouldn't be enough,
> and 'from x import y' would be needed.
> 
> On Fri, Feb 5, 2021 at 2:13 PM Chris Angelico 
> wrote:
> > On Sat, Feb 6, 2021 at 12:51 AM Matt del Valle
> >  wrote:
> > >
> > > Unfortunately, [lazy importers are] fundamentally incapable of
> > dealing with 'from x import y' syntax, because this is always
> > loaded eagerly by the Python interpreter.
> > >
> > 
> > This is because it's fundamentally hard.
> > 
> > > With the increasingly widespread adoption of type hints I think
> > it is time to revive the proposal for lazy imports as an official
> > language feature.
> > >
> > 
> > Are you writing this proposal assuming PEP 563 behaviour? If type
> > hints are the primary justification, it may be less necessary. But
> > lazy importing does have other value.
> > 
> > > It also is fundamentally incapable of handling this other
> > extremely common usage pattern:
> > >
> > > some_library/ __init__.py
> > >
> > > > __all__ = ["SomeClass", "AnotherClass"]
> > > >
> > > > from .extremely_expensive_module import SomeClass
> > > > from .another_extremely_expensive_module import AnotherClass
> > >
> > > some_module.py
> > >
> > > > from some_library import  SomeClass
> > 
> > Hmm.
> > 
> > Okay. Let's talk semantics, not syntax. What exactly should the
> > interpreter do with this line? Is there an actual object in the
> > module
> > dictionary under the name "SomeClass", and if so, what sort of
> > object?
> > 
> > One possible meaning for this kind of "lazy from import" would be
> > to
> > maintain a table of import definitions, just like the module
> > dictionary. (I would be inclined to say that this can ONLY be done
> > at
> > module level; lazy imports inside a class or function seem less
> > useful
> > and more hassle than they're worth. But if you disagree, feel free
> > to
> > expand this to other namespaces.) Whenever a module name is looked
> > up,
> > the interpreter looks first in the module dictionary, and then if
> > it's
> > not found, tries the lazy imports; upon finding the import
> > definition,
> > it removes it, performs the import, and stuffs the object into the
> > module dictionary.
> > 
> > This would be a fair amount of hassle, and it'd have a performance
> > impact on EVERY module name lookup (and eve

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Paul Bryan]

It's current convention (and is used by typing module and static type
checkers) that string annotations evaluate to valid Python types.

On Thu, 2021-03-11 at 10:45 -0800, Ethan Furman wrote:
> On 3/10/21 9:47 PM, Eric V. Smith wrote:
> 
> > I'm not sure of the best way to achieve this. Using flags to
> > field() doesn't sound awesome, but could be made to work. Or maybe
> > special field names or types? I'm not crazy about that, but using
> > special types would let you do something like:
> > 
> > @dataclasses.dataclass
> > class Point:
> >  x: int = 0
> >  _: dataclasses.KEYWORD_ONLY
> >  y: int
> >  z: int
> >  t: int = 0
> 
> Maybe something like this?
> 
>  class Hmm:
>  #
>  this: int
>  that: float
>  #
>  pos: '/'
>  #
>  these: str
>  those: str
>  #
>  key: '*'
>  #
>  some: list
> 
>  >>> Hmm.__dict__['__annotations__']
>  {
>  'this': ,
>  'that': ,
>  'pos': '/',
>  'these': ,
>  'those': ,
>  'key': '*',
>  'some': ,
>  }
> 
> The name of 'pos' and 'key' can be convention, since the actual name
> is irrelevant.  They do have to be unique, though.  ;-)
> 
> --
> ~Ethan~
> ___
> 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/BIAVX4O6JRPQY7S3XG2IX6BSBZLAR2NS/
> 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/BKEP55A72KOF6PWYGJEDXZPMN5CBTL6D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Paul Bryan]

Given that @dataclass is a decorator, and otherwise you're just
defining a class, some concerns:

1. Such proposed syntax would require a change to the language
specification. 

2. It would seem that / and * in a class not decorated with @dataclass
would be of no other utility.

Paul

On Thu, 2021-03-11 at 10:08 -0500, Ricky Teachey wrote:
> On Thu, Mar 11, 2021 at 10:00 AM Ethan Furman 
> wrote:
> > On 3/11/21 4:20 AM, Ricky Teachey wrote:
> > 
> > > This might be a bit of an extreme step to take, but has new
> > syntax for this ever been discussed? Here I am using the same
> > indicator for keyword arguments as in a function signature, hanging
> > on a line by itself:
> > > 
> > ...
> > > @dataclasses.dataclass
> > > class Comparator:
> > >      /  # args become positional after this line
> > >      a: Any
> > >      b: Any
> > >      *  # args become kwd args after this line
> > >      key: Optional[Callable[whatever]] = None
> > 
> > Actually, the '/' indicates that names /before/ it are positional
> > only.
> > 
> > --
> > ~Ethan~
> > 
> 
> 
> Yes you're of course correct! Sorry!
> 
> So the corrected version would be:
> 
> @dataclasses.dataclass
> class Comparator:
>     a: Any
>     b: Any
>      /  # args before this line positional only
>     *  # args become kwd args after this line
>     key: Optional[Callable[whatever]] = None
> 
> ---
> 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/L6Y5C7CFPEQECK5OWVOI4CKAYGHBHAPM/
> 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/FJDZ4TDKDSERY5P6F4CU777QC5IEEKHW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

[Paul Bryan]

In my experience, a dataclass with more than a few attributes makes
using positional arguments unwieldy and error-prone. 

I would think something like @dataclass(kwonly=bool) with default of
False would be reasonably clean to implement and understand.

While I appreciate supporting existing behavior for backward
compatibility, I'm not so clear on the value of supporting a hybrid of
positional and keyword __init__ arguments. Could you shed some light on
your reasoning for supporting it?


On Thu, 2021-03-11 at 00:47 -0500, Eric V. Smith wrote:
> As I've said before, I'm not opposed to the feature of keyword-only
> arguments. I think it would be a great addition.
> However, the proposal from Laurie O is only for changing fields
> without default values following fields with default values to be
> keyword-only. At least that's how I understand it.
> So, that means that:
> @dataclasses.dataclass
> class Point:
>     x: int = 0
>     y: int
>     z: int
>     t: int = 0
> Would generate a __init__ with this signature:
> def __init__(self, x=0, *, y, z, t=0):
> While it's an interesting application, I think that's just too
> limiting. Among other things, I can't define a dataclass where all
> fields are keyword-only, or a class where there's only a single field
> and it's keyword-only. I also have to have at least one keyword-only
> field (here, y) that has no default value. z and t can have defaults,
> but not y.
> What I'd like to see is some way of having keyword-only arguments,
> with or without defaults. And I'd also like to see if we could get
> support for positional-only arguments at the same time.
> I'm not sure of the best way to achieve this. Using flags to field()
> doesn't sound awesome, but could be made to work. Or maybe special
> field names or types? I'm not crazy about that, but using special
> types would let you do something like:
> @dataclasses.dataclass
> class Point:
>     x: int = 0
>     _: dataclasses.KEYWORD_ONLY
>     y: int
>     z: int
>     t: int = 0
> And the dataclasses machinery would ignore the "_" field except for
> making everything after it keyword-only. Here the name "_" isn't
> special: any field (of any name) that's of type
> dataclasses.KEYWORD_ONLY would be ignored except for the keyword-only
> changing behavior. In some ways, it's like dataclasses.ClassVar,
> where the type is treated specially and the field doesn't become a
> __init__ argument.
> There are also issues with inheritance that would need to be thought
> through. This idea could also be extended for positional-only.
> I'm open to other suggestions.
> Eric
> On 3/10/2021 10:22 AM, Guido van Rossum wrote:
> 
> > ___
> > Python-ideas mailing list -- 
> > To unsubscribe send an email to 
> > 
> > Message archived at 
> > Code of Conduct: 
> -- 
> Eric V. Smith
> ___
> 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/XSAYT2MFOIBYHYINDHLPR7V2WHCWRYPE/
> 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/UGNLUWT4OQC2JMEXSNIJRRCC4KMBE6XJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: class(obj) could return obj.__class__

[Paul Bryan]

Err, why is it insufficient?

On Wed, 2021-03-03 at 14:03 -0800, Paul Bryan wrote:
> Since class is a keyword, this is unlikely. Why is type(o) not
> insufficient?
> 
> On Wed, 2021-03-03 at 22:59 +0100, Hans Ginzel wrote:
> > > > > class c: pass
> > > > > o = c()
> > > > > o.__class__
> > 
> > > > > class(o)
> >     File "", line 1
> >   class(o)
> >    ^
> > SyntaxError: invalid syntax
> 

___
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/E5YNJX3IN2VAY7BBFKJCU4GVBSXBSKGV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: class(obj) could return obj.__class__

[Paul Bryan]

Since class is a keyword, this is unlikely. Why is type(o) not
insufficient?

On Wed, 2021-03-03 at 22:59 +0100, Hans Ginzel wrote:
> > > > class c: pass
> > > > o = c()
> > > > o.__class__
> 
> > > > class(o)
>     File "", line 1
>   class(o)
>    ^
> SyntaxError: invalid syntax

___
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/DW6MDI3DESDFGU4QAMZA5Q5RM3UGP2SM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Barrier Object in asyncio lib

[Paul Bryan]

Sorry, didn't see Jonathan's example.

On Sat, 2021-02-27 at 01:12 +0000, Paul Bryan wrote:
> Could somone provide a concrete example on a proposed use of such an
> asyncio.Barrier?
> 
> On Fri, 2021-02-26 at 14:19 -0800, Guido van Rossum wrote:
> > On Fri, Feb 26, 2021 at 10:09 AM Yves Duprat 
> > wrote:
> > > I was expecting an explanation about the initial request. 
> > > Is there an oversight (??) or an another reason to not have a
> > > Barrier primitive in asyncio ?
> > > 
> > 
> > 
> > Probably because nobody working on asyncio at the time had any
> > experience using threading.Barrier. I know that I have used all the
> > other primitives, but I don't recall ever having used Barrier. I
> > don't think there's anything deeper than that. You should probably
> > just open a bpo issue (mention this thread) and submit a PR linked
> > there. I can't promise to review it though. :-)
> >  
> > ___
> > 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/GNUCKA2MCVROCVLWRQUTMUG7CGOVQQV6/
> > 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/WIQBCDBZSJQDDBDQQSOYLU4C2XIBGDKN/
> 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/F2GKBLMU5JBYNUGDPBGNGTRZGBCH3M2R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Barrier Object in asyncio lib

[Paul Bryan]

Could somone provide a concrete example on a proposed use of such an
asyncio.Barrier?

On Fri, 2021-02-26 at 14:19 -0800, Guido van Rossum wrote:
> On Fri, Feb 26, 2021 at 10:09 AM Yves Duprat 
> wrote:
> > I was expecting an explanation about the initial request. 
> > Is there an oversight (??) or an another reason to not have a
> > Barrier primitive in asyncio ?
> > 
> 
> 
> Probably because nobody working on asyncio at the time had any
> experience using threading.Barrier. I know that I have used all the
> other primitives, but I don't recall ever having used Barrier. I
> don't think there's anything deeper than that. You should probably
> just open a bpo issue (mention this thread) and submit a PR linked
> there. I can't promise to review it though. :-)
>  
> ___
> 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/GNUCKA2MCVROCVLWRQUTMUG7CGOVQQV6/
> 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/WIQBCDBZSJQDDBDQQSOYLU4C2XIBGDKN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Have virtual environments led to neglect of the actual environment?

[Paul Bryan]

I think it's a classic case of dependency hell.

OS packagers are rebundling Python packages as OS packages and
expressing their own OS-package dependency graphs. Then, you sudo pip
install something that has a conflicting dependency, it bypasses OS
packaging, and *boom*.

I find tools like pipx go a long way to solve this, as they install a
Python package and all of its dependencies in its own venv. This is
great for Python apps, and (kinda) treats them like apps on platforms
like Android, where all app dependencies are bundled and isolated from
others.

I think it would great if OS vendors did something similar to pipx for
Python-based apps: bundle the app and all of its dependencies into its
own venv.

 
On Tue, 2021-02-23 at 19:45 -0500, Random832 wrote:
> I was reading a discussion thread
> 
> about various issues with the Debian packaged version of Python, and
> the following statement stood out for me as shocking:
> 
> Christian Heimes wrote:
> > Core dev and PyPA has spent a lot of effort in promoting venv
> > because we don't want users to break their operating system with
> > sudo pip install.
> 
> I don't think sudo pip install should break the operating system. And
> I think if it does, that problem should be solved rather than merely
> advising users against using it. And why is it, anyway, that
> distributions whose package managers can't coexist with pip-installed
> packages don't ever seem to get the same amount of flak for "damaging
> python's brand" as Debian is getting from some of the people in the
> discussion thread? Why is it that this community is resigned to
> recommending a workaround when distributions decide the site-packages
> directory belongs to their package manager rather than pip, instead
> of bringing the same amount of fiery condemnation of that practice as
> we apparently have for *checks notes* splitting parts of the stdlib
> into optional packages? Why demand that pip be present if we're not
> going to demand that it works properly?
> 
> I think that installing packages into the actual python installation,
> both via distribution packaging tools and pip [and using both
> simultaneously - the Debian model of separated dist-packages and
> site-packages folders seems like a reasonable solution to this
> problem] can and should be a supported paradigm, and that virtual
> environments [or more extreme measures such as shipping an entire
> python installation as part of an application's deployment] should
> ideally be reserved for the rare corner cases where that doesn't work
> for some reason.
> 
> How is it that virtual environments have become so indispensable,
> that no-one considers installing libraries centrally to be a viable
> model anymore? Are library maintainers making breaking changes too
> frequently, reasoning that if someone needs the old version they can
> just venv it? Is there some other cause?
> ___
> 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/KMRNKSVEPHAXA7BHFT4PWX4EKWYUF4G7/
> 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/2VYJAJHHGOOPFQA6U7ATBKREMAC66CXW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: SimpleNamespace vs object

[Paul Bryan]

I agree, I don't think it justifies a builtin, because it is so simple
to just define your own empty class. That said, it does come in handy,
and I do use it for same reasons others have expressed.


On Thu, 2021-02-18 at 11:50 +1300, Greg Ewing wrote:
> On 18/02/21 3:51 am, Ricky Teachey wrote:
> > I would personally love for SimpleNamespace to get a shorter name
> > and 
> > become a built-in. It is a fantastic object to use in all kinds of 
> > situations
> 
> I find myself disagreeing with that. It's dead simple to define
> your own blank-object class, and you get to give it a name that
> reflects what you're really doing with it. I don't understand
> why there's such a fascination with things like SimpleNamespace.
> 

___
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/EMKHIVA27CVGVDJPJHQ4O2BY6IZXDWRN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding PathLiteral class and existing object instance to pathlib

[Paul Bryan]

I wonder how that is substantially different than:

from pathlib import Path as p
p() / "foo"

or perhaps more verbosely, but arguably more readable:

from pathlib import Path
Path() / "foo"

Paul


On Tue, 2021-02-16 at 01:07 +, mwmajewsk wrote:
> P.S. the code snippet I mentioned is not rendering with mailman
> archives, here it is again;
> 
> from pathlib import path_literal as p
> p/"foo"
> 
> the result is:
> PosixPath('foo')
> ___
> 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/ARV4RO2YVDWGT4JQLPYJIIDYCYILLKQY/
> 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/BAFAGNN3PNHR6BK37XHWBCMSZPHL6NZX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Type hinting **kwargs

[Paul Bryan]

I'm encountering a situation where it would be far cleaner to use
**kwargs (multiple functions taking the same set of parameters); I'd
like to have type hints, and avoid repeating multiple function
definitions, explicitly enumerating all parameters for each function
definition.

Therefore, I'd like to have some meaningful type hint for **kwargs.
 First, I thought TypedDict would be a great fit, until I found this
passage in PEP 589:

> These features were left out from this PEP, but they are potential
> extensions to be added in the future:
> ...
> TypedDict can't be used for specifying the type of a **kwargs
> argument. This would allow restricting the allowed keyword arguments
> and their types. According to PEP 484, using a TypedDict type as the
> type of **kwargs means that the TypedDict is valid as the value of
> arbitrary keyword arguments, but it doesn't restrict which keyword
> arguments should be allowed. The syntax **kwargs: Expand[T] has been
> proposed for this [11].
> ...
> [11]  https://github.com/python/mypy/issues/4441

In the mypy issue discussion, there seems to be two issues:

1. Ambiguity of whether the type hint applies to the **kwargs dict vs.
each value in the dict. I think this could be a red herring; kwargs
presents as a dict and I think TypedDict can unambiguously represent
the structure of that dict. I don't see how it should be different than
any other dict parameter being defined as a function parameter.

2. A question of whether one needs to assume that for a TypedDict, the
type validator should assume total=False. I think what keys are
required should be explicitly determined by the TypedDict (required
keys inferred from total). I suspect the issue could be that mypy may
not be able to determine this during static type analysis? 

In summary, **kwargs is a dict; TypedDict can specify its structure;
static type checker limitations should not necessarily restrict its use
in this way.

Therefore, I propose a short PEP be drafted to codify the validity of
using TypedDict to specify the type of a **kwargs argument.

Paul

___
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/F64KJNO7FB4ONPNV5H2EVSJQ5IPU2ECW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP for experimental/provisional features

[Paul Bryan]

To clarify, the point of __provisional__ would be to enable some
syntactical feature in the language that should not be considered
stable? I'm not sure I see a reason to use this for a new module or
package in stdlib for example; a docstring or perhaps some decorator
like @provisional could indicate a class or function is not ready for
prime time. 

If I'm correct, then the contract of __provisional__ would be:
 * here's a new language feature you can use
 * it's subject to change in future releases; you'll need to change
   your code accordingly if it changes
 * because it's language change, it's unlikely you can conditionally
   choose which syntax to use based on the version of Python being used
 * you enable it explicitly and accept the instability of the language
   feature

Paul


On Sun, 2021-02-07 at 13:14 +, sascha.schlemmer--- via Python-ideas
wrote:
> Reading the latest discussion about PEP 622/634-636 on the Python Dev
> mailing list, I've noticed there appears to be confusion about what
> `__future__` imports are supposed to be used for. Multiple people in
> that thread (and probably elsewhere in one of the many many threads
> about these PEPs) have suggested including pattern matching as a
> "provisional" or "experimental"  feature that is enabled by an import
> from `__future__`. 
> 
> I don't want to discuss whether `__future__` is the correct place for
> this however (and I also don't want to discuss PEP 622/634-636
> specifically). Instead I'd like to propose a `__provisional__`
> namespace (or whatever color you favor for your bike shed) for new
> language features/ standard library modules that might undergo
> breaking changes over a couple of subsequent python releases. This is
> similar to how many applications start in a version V0.1 and undergo
> changes until they mature and reach V1.0.
>  
> From the user perspective this would allow more "adventurous" users
> to play with the latest features (with the clear warning attached
> that they might have to adapt their own code over subsequent python
> releases) while anyone else can just ignore the new feature for now.
> From the perspective of the language designers the advantage I see is
> that they can get a first version of a feature out to real users to
> collect feedback on whether the feature is used as they imagined it
> being used and change/iterate the design if need be. It is simply
> unrealistic to get something like `asyncio` or PEP 622/634-636
> perfect and feature complete on the first try or otherwise wait
> indefinitely until something is ready. 
> 
> Some thoughts what `__provisional__` SHOULD and SHOULD NOT be used
> for:
> - `__provisional__` SHOULD be useable at the users own discretion
> (e.g. no use of provisional features in the standard library etc. )
> 
> - `__provisional__` SHOULD be a place for features with a vast design
> space that need to "ripen" as use cases are explored (`asyncio` would
> have been the poster child candidate for `__provisional__`)
> 
> - features SHOULD only be placed in `__provisional__` if there is a
> clear commitment to the feature (the general feature is accepted by
> the SC before being included in `__provisional__`). `__provisional__`
> SHOULD NOT be a place where contentious PEPs are thrown into willy-
> nilly and postpone the decision of whether to accept a PEP or not.
> Otherwise users would not only have to deal with changes to a feature
> (they obviously showed interest in using) but also with complete
> removal/deprecation. 
> 
> - `__provisional__` SHOULD only be used for features that are
> additive to the language and don't change existing code (which is
> what imho. what `__future__` is for). 
> - `__provisional__` SHOULD have a clearly defined process (timelines
> etc.)
> 
> 
> Alternative ideas that have been mentioned (in threads about PEP
> 622/634-636 and elsewhere) and why I personally don't think they are
> sufficient:
> 
> - "just throw together a library that parses strings and uses
> `eval`,  put it on pypi to see how that goes": For features that
> require new syntax this just doesn't work imho. Using
> `pep622_lib.match("put your match statement here")` is a very poor
> substitute for trying this out due to the influence design choices
> such as keywords, indentation etc. have on usability. Examples for
> this are syntax highlighting, autocomplete/autoindent/autoformat and
> linting which you just don't get this way.
> 
> - various degrees of: "solve the issue of contention over new
> languages features once and for all by introducing
> macros/preprocessors to the language": Against this I have just my
> personal plea "please don't turn python into lisp/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/pyt

[Python-ideas] Re: Parameter documentation

[Paul Bryan]

A little less verbose:

import typing.Annotated as A

def request(
method: A[str, "The method to perform"],
url: A[str, "The URL to submit request to"],
...
) -> Response:
"""Constructs and sends a request."""
...


On Fri, 2021-01-29 at 13:43 -0800, abed...@gmail.com wrote:
> *I was hoping for something a little less verbose
> 
> I left out the word "verbose". I'll tripple check my next post. Sorry
> again.
> On Friday, January 29, 2021 at 3:41:17 PM UTC-6 abed...@gmail.com
> wrote:
> > That could work. I'm not super familiar with typing.Annotated. I
> > was hoping for something a little less though my example doesn't
> > really show that with the way used commas.
> > Thinking about it more, it should be possible for the parser to
> > recognize a comma followed by a comment within a function
> > signature, so something like the following should be possible:
> > 
> > def request(
> >     method: str, # the method to perform
> >     url: str, # the URL to submit request for
> >     ...
> > ) -> Response: # the response to the request
> >     """Constructs and sends a request."""
> >     ...
> > 
> > Though it's a bit of a special case because you can't remove the
> > white-space and get the same result:
> > 
> > def request(method: str, # The method to perform url: str, # this
> > doesn't work ...
> > ) -> Response:
> >     # This also is a bit weird
> >     """Constructs and sends a request"""
> > 
> > so maybe it's better to mandate that the doc be a string literal:
> > 
> > def request(
> >     method: str, "the method to perform"
> >     url: str, "the URL to submit request for"
> >     ...
> > ) -> Response: "the response to the request"
> >     """Constructs and sends a request."""
> >     ...
> > 
> > Which would look weird with different white-space, but be
> > equivalent:
> > 
> > def request(method: str, "The method to perform" url: str, "this
> > doesn't work" ...
> > ) -> Response:
> >     """This also is a bit weird"""
> >     """Constructs and sends a request"""
> > 
> > The weirdest part about that is the doc string for "method" is
> > after the comma and precedes "url".
> > 
> > Anyway, this was a half-baked thought for reducing some minor
> > repetition and putting documentation closer to where it's relevant.
> > If it comes at the expense of a lot of noise (Annotated[]
> > everywhere) or a confusing syntax hack (like above), it's probably
> > not worth it.
> > On Friday, January 29, 2021 at 2:46:55 PM UTC-6 Paul Bryan wrote:
> > > Or now, thinking more about it, why not simplify it by having a
> > > string literal in Annotated just represent its docstring? 
> > > 
> > > def request(
> > > method: Annotated[str, "The method to perform"],
> > > url: Annotated[str, "The URL to submit request to"],
> > > ...
> > > ) -> Response:
> > > """Constructs and sends a request."""
> > > ...
> > > 
> > > 
> > > 
> > > On Fri, 2021-01-29 at 20:40 +, Paul Bryan wrote:
> > > > Perhaps this would be a good opportunity to start looking at
> > > > typing.Annotated[...] as a mechanism for parameter
> > > > documentation? Something like:
> > > > 
> > > > def request(
> > > > method: Annotated[str, Doc("The method to perform")],
> > > > url: Annotated[str, Doc("The URL to submit request to")],
> > > > ...
> > > > ) -> Response:
> > > > """Constructs and sends a request."""
> > > > ...
> > > > 
> > > > 
> > > > On Fri, 2021-01-29 at 12:33 -0800, abed...@gmail.com wrote:
> > > > Sorry, I accidentally hit "post message" too soon. The idea is
> > > > that python would somehow construct a more complete doc-string
> > > > from the function doc-string and it's signature/parameter doc-
> > > > strings.
> > > > 
> > > > On Friday, January 29, 2021 at 2:29:51 PM UTC-6
> > > > abed...@gmail.com wrote:
> > > > > Currently, pytho

[Python-ideas] Re: Parameter documentation

[Paul Bryan]

Or now, thinking more about it, why not simplify it by having a string
literal in Annotated just represent its docstring? 

def request(
method: Annotated[str, "The method to perform"],
url: Annotated[str, "The URL to submit request to"],
...
) -> Response:
"""Constructs and sends a request."""
    ...


On Fri, 2021-01-29 at 20:40 +, Paul Bryan wrote:
> Perhaps this would be a good opportunity to start looking at
> typing.Annotated[...] as a mechanism for parameter documentation?
> Something like:
> 
> def request(
> method: Annotated[str, Doc("The method to perform")],
> url: Annotated[str, Doc("The URL to submit request to")],
> ...
> ) -> Response:
> """Constructs and sends a request."""
> ...
> 
> 
> On Fri, 2021-01-29 at 12:33 -0800, abed...@gmail.com wrote:
> Sorry, I accidentally hit "post message" too soon. The idea is that
> python would somehow construct a more complete doc-string from the
> function doc-string and it's signature/parameter doc-strings.
> 
> On Friday, January 29, 2021 at 2:29:51 PM UTC-6 abed...@gmail.com
> wrote:
> > Currently, python allows variable documentation via PEP 526. For
> > most functions with short parameter lists that can fit in a
> > reasonable column limit, I prefer the traditional declaration style
> > with Google-style doc strings:
> > 
> > def connect_to_next_port(self, minimum: int) => int: 
> >     """Connects to the next available port.
> > 
> >     Args:
> >         minimum: A port value greater or equal to 1024.
> > 
> >     Returns:
> >         The new minimum port.
> > 
> >     Raises:
> >         ConnectionError: If no available port is found.
> >     """
> >     ...code...
> > 
> > However, when a signature gets too long, I prefer to list the
> > parameters vertically:
> > 
> > def request(
> >         method: Method,
> >         url: Str,
> >         params: Dict = None,
> >         data: Dict = None,
> >         json: Str = None,
> >         headers: Dict = None,
> >         cookies: Dict = None,
> >         files: Dict = None,
> >         ...) => Response:
> >     """Constructs and sends a Request
> >     
> >     Args: ... """
> >     
> > In which case, it would be nice to in-line some documentation
> > instead of repeating the whole parameter list in the doc string.
> > Something like:
> > 
> > def request(
> >         method: Method
> >         #method for the new Request: ``GET``,``POST``, etc.
> >         ,
> >         url: Str
> >         #URL for the request
> >         ,
> >         params: Dict = None
> >         ...) => Response:
> >     """Constructs and sends a Request"""
> > 
> > 
> > 
> > 
> ___
> 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/4YJIVCZ5OIACU74UGZJECRMLTZWVDMOZ/
> 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/5LUVCKIFIFV7FI6HT55L2PNCDE355LXC/
> 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/IC4GKPTGGULZS5XSB5PT5G5ZPRL5SKWA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Parameter documentation

[Paul Bryan]

Perhaps this would be a good opportunity to start looking at
typing.Annotated[...] as a mechanism for parameter documentation?
Something like:

def request(
method: Annotated[str, Doc("The method to perform")],
url: Annotated[str, Doc("The URL to submit request to")],
...
) -> Response:
"""Constructs and sends a request."""
...


On Fri, 2021-01-29 at 12:33 -0800, abed...@gmail.com wrote:
> Sorry, I accidentally hit "post message" too soon. The idea is that
> python would somehow construct a more complete doc-string from the
> function doc-string and it's signature/parameter doc-strings.
> 
> On Friday, January 29, 2021 at 2:29:51 PM UTC-6 abed...@gmail.com
> wrote:
> > Currently, python allows variable documentation via PEP 526. For
> > most functions with short parameter lists that can fit in a
> > reasonable column limit, I prefer the traditional declaration style
> > with Google-style doc strings:
> > 
> > def connect_to_next_port(self, minimum: int) => int: 
> >     """Connects to the next available port.
> > 
> >     Args:
> >         minimum: A port value greater or equal to 1024.
> > 
> >     Returns:
> >         The new minimum port.
> > 
> >     Raises:
> >         ConnectionError: If no available port is found.
> >     """
> >     ...code...
> > 
> > However, when a signature gets too long, I prefer to list the
> > parameters vertically:
> > 
> > def request(
> >         method: Method,
> >         url: Str,
> >         params: Dict = None,
> >         data: Dict = None,
> >         json: Str = None,
> >         headers: Dict = None,
> >         cookies: Dict = None,
> >         files: Dict = None,
> >         ...) => Response:
> >     """Constructs and sends a Request
> >     
> >     Args: ... """
> >     
> > In which case, it would be nice to in-line some documentation
> > instead of repeating the whole parameter list in the doc string.
> > Something like:
> > 
> > def request(
> >         method: Method
> >         #method for the new Request: ``GET``,``POST``, etc.
> >         ,
> >         url: Str
> >         #URL for the request
> >         ,
> >         params: Dict = None
> >         ...) => Response:
> >     """Constructs and sends a Request"""
> > 
> > 
> > 
> > 
> ___
> 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/4YJIVCZ5OIACU74UGZJECRMLTZWVDMOZ/
> 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/5LUVCKIFIFV7FI6HT55L2PNCDE355LXC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dataclass: __init__ kwargs and Optional[type]

[Paul Bryan via Python-ideas]

Added myself to the nosy list.

Seems like the suggested kw_only: str variant—perhaps it should also
support Iterable—would allow continued support for positional
arguments. Is your idea around positional-only arguments different? 

Another thought  I had was around Optional and default-None semantics:
Optional[type] should safely default to None in __init__; I'm thinking
the opposite could also be supported (default of None can imply
Optional type in annotation). 

Given various objectives, would it make sense to codify in a PEP to
build consensus?


On Mon, 2021-01-25 at 11:07 -0500, Eric V. Smith wrote:
> See https://bugs.python.org/issue33129. I've not done much with this
> issue, because I'm not crazy about the API, and I'd like to do
> something with positionally-only arguments at the same time. But I
> think in general it's a good idea.
> Eric
> On 1/24/2021 3:07 PM, Paul Bryan via Python-ideas wrote:
> 
> The main benefits of this proposal:
> 
> - the order of fields (those with defaults, those without) is
> irrelevant
> - don't need to pedantically add default = None for Optional values
> 
> On Sun, 2021-01-24 at 19:46 +, Paul Bryan via Python-ideas wrote:
> 
> > I've created a helper class in my own library that enhances the
> > existing dataclass:
> > 
> > a) __init__ accepts keyword-only arguments,
> > b) Optional[...] attribute without a specified default value would
> > default to None in __init__.
> > 
> > I think this could be useful in stdlib. I'm thinking a dataclass
> > decorator parameter like "init_kwonly" (default=False to provide
> > backward compatibility) that if True would implement this behavior.
> > 
> > Thoughts?
> > 
> > ___
> > 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/2NLPDOV2XJBQU5LX3SA3XEQ6CTOQEZA7/
> > 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/T2BBB4LA3LLPRZRF4TRR6YBROTX7CGBD/
> 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/LP6LCIZ6UOPMWSVALPWF67TC7CA5BZME/
> 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/IUEZPYGYVBQAGV6RJTLAT3WAK62ASIYR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dataclass: __init__ kwargs and Optional[type]

[Paul Bryan via Python-ideas]

The main benefits of this proposal:

- the order of fields (those with defaults, those without) is
irrelevant
- don't need to pedantically add default = None for Optional values

On Sun, 2021-01-24 at 19:46 +0000, Paul Bryan via Python-ideas wrote:
> I've created a helper class in my own library that enhances the
> existing dataclass:
> 
> a) __init__ accepts keyword-only arguments,
> b) Optional[...] attribute without a specified default value would
> default to None in __init__.
> 
> I think this could be useful in stdlib. I'm thinking a dataclass
> decorator parameter like "init_kwonly" (default=False to provide
> backward compatibility) that if True would implement this behavior.
> 
> Thoughts?
> 
> ___
> 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/2NLPDOV2XJBQU5LX3SA3XEQ6CTOQEZA7/
> 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/T2BBB4LA3LLPRZRF4TRR6YBROTX7CGBD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] dataclass: __init__ kwargs and Optional[type]

[Paul Bryan via Python-ideas]

I've created a helper class in my own library that enhances the
existing dataclass:

a) __init__ accepts keyword-only arguments,
b) Optional[...] attribute without a specified default value would
default to None in __init__.

I think this could be useful in stdlib. I'm thinking a dataclass
decorator parameter like "init_kwonly" (default=False to provide
backward compatibility) that if True would implement this behavior.

Thoughts?

___
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/2NLPDOV2XJBQU5LX3SA3XEQ6CTOQEZA7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a "closed for" loop (was "PEP 533 Redux?")

[Paul Bryan via Python-ideas]

Reading through the PEP again and some of the discussion, I think I now
better understand the issue.

If we were to undertake a change in for's behavior, unless the
generator is actually explicitly scoped to the for statement (and
doesn't survive outside of the loop, which is not how it works today),
closing would not make sense, and could expose other undesirable side-
effects.

The generator consumer would need to be aware that it needs to be
closed (or aclosed) and do so explicitly. Problematic example I can
think of: partially iterating the generator, terminating the loop,
doing something, then continuing to iterate.

I'm not a fan of adding a keyword to a for loop to do explicit closing.

My takeaway with what I know now: I now consider generators
establishing context(s) to be an anti-pattern. I've now refactored my
code to require the context to be in place prior to the creation of the
generator. In my case, it actually makes it far easier for the API
consumer to reason about the scope of the context and behavior of the
generator. Explicit is better than implicit.

Thanks to you and to everyone else that have discussed this. 

Paul


On  Wed, 2021-01-06 at 21:24 +, Brendan Moloney wrote:
> I mentioned this off-hand in the other thread, but the more I think
> about it the more I think it is a reasonable compromise between the
> two schools of thought on PEP 533.
> 
> Wouldn't the new PEG parser allow a "closed for" statement without
> breaking code that uses "closed" as a variable (it would be a context
> sensitive keyword)?
> 
> The users who work in the space that cares about such things can
> start writing:
> closed for document in read_newline_separated_json(path):
> ...
> Instead of:
> with closing(read_newline_separated_json(path)) as genobj:
> for document in genobj:
> ...
> 
> It is still on the API consumer to know when they need to use a
> "closed for" loop, but at least they don't have to restructure their
> code, and there would be no backwards incompatibility.
> 
> If we want to get really crazy we can also allow an "open for" loop
> and kick off a very long deprecation process where eventually an
> unadorned for loop would become "closed" by default.
> 
> Thanks,
> Brendan
> ___
> 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/MZIVRIM5JLS5YOAEVBIJFHVROZ3AJRI5/
> 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/HMJBQ7MBN6XSTQB7ND7WLL66NMIT3RXU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 533 Redux?

[Paul Bryan via Python-ideas]

In this case, I was able to change my code to require the context be
established outside of the call to the asynchronous generator. It puts
more burden on the caller to setup context before making the call.

Without a solution in place, is there a legitimate case for a context
manager being entered (and not exited) within a generator iteration?
 If not, would some kind of warning be appropriate (or even possible)?


On Thu, 2020-12-31 at 21:49 +, Brendan Moloney wrote:
> This bit me a while back, and I spent some time reading through the
> PEP 533 discussion. It was determined that changing the default
> behavior of for loops would break too much code.
> 
> I wonder if the new PEG parser would allow us to decorate for loops
> with context sensitive keywords to override this default behavior
> without requiring code restructuring (adding a with statement).
> 
> From: Paul Bryan via Python-ideas 
> Sent: Thursday, December 31, 2020 12:06 PM
> To: python-ideas@python.org
> Subject: [EXTERNAL] [Python-ideas] PEP 533 Redux? 
> I've now encountered an issue I believe that PEP 533 was intended to
> address:
> 
> When an asynchronous context manager is created within an
> asynchronous generator, if the generator is not iterated fully, the
> context manager will not exit until the event loop cancels the task
> by raising a CancelledError, long after the context manager is
> assumed to be out of scope. Per PEP 525, I can call aclose coroutine
> method to cleanup the generator, but it requires the code iterating
> to be aware that that closing the generator is necessary. 
> 
> Any appetite for putting PEP 533 back on the table to address this
> issue?
> 
> ___
> 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/4OYH7YOGOX4SZUF2UF47DOG5RWBGFV5L/
> 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/HXHEG62HYOCNQS2RBM6HK5CHZ5D37TUD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] PEP 533 Redux?

[Paul Bryan via Python-ideas]

I've now encountered an issue I believe that PEP 533 was intended to
address:

When an asynchronous context manager is created within an asynchronous
generator, if the generator is not iterated fully, the context manager
will not exit until the event loop cancels the task by raising
a CancelledError, long after the context manager is assumed to be out
of scope. Per PEP 525, I can call aclose coroutine method to cleanup
the generator, but it requires the code iterating to be aware that that
closing the generator is necessary. 

Any appetite for putting PEP 533 back on the table to address this
issue?

___
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/AM277CEKUEDGGIWYY3QSKYPW5OEICFGQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Standalone bool?

[Paul Bryan]

I'm interested in knowing when (id(x), x) would be preferable over
(type(x), x).

On Mon, 2020-12-21 at 17:52 +, David Mertz wrote:
> On Mon, Dec 21, 2020 at 5:27 PM Christopher Barker
>  wrote:
> > Surely what you're looking for is some kind of typed hash table?
> > 
> > Maybe, maybe not. My impression is that the Typed hash  table is a
> > kluge to get around this one issue. As others have pointed out, 1
> > and 1.0 are considered equal, and thus hash the same — a typed
> >  hash table would not consider them the same. And while maybe
> > useful, it would violate the spirit of duck typing. If you really
> > want that kind of static typing, maybe Python is not the language
> > for the job.
> > 
> 
> 
> I've occasionally wanted an "identity set".  Except, after I want it,
> I pretty quickly always realize I don't actually want it.  Exactly
> what strings and integers will actually be interned, etc? There's a
> lot of implementation dependent stuff there that isn't a clear
> semantics (I mean, it's knowable, but too complex).
> 
> In any case, I know how to write that in a few lines if I feel like
> having it.  Basically just use pairs `(id(x), x)` in a set.  That's
> more specific than `(type(x), x)`, although both have their own
> gotchas.
>  
> 
> ___
> 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/PWFX7WBNRQN5UBT27R2SOUBMUOXGVF6P/
> 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/4N6EFYRFOWFSK7O4NQCSUMAFTOIUIDXP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Standalone bool?

[Paul Bryan]

Hmm, I see ints, floats and decimal.Decimal all produce the same hashes
for integer values, so they also suffer the same fate in sets and
dicts.

On Mon, 2020-12-21 at 03:09 -0500, David Mertz wrote:
> I sure hope this never happens! It would break millions of working
> lines and kill a common useful pattern.
> 
> ntrue = sum(this == that for this, that in items)
> 
> -100.
> 
> On Mon, Dec 21, 2020, 3:00 AM Paul Bryan  wrote:
> > I know this has come up in the past.
> > 
> > Could the consensus have changed regarding bool's inheritance from
> > int?
> > 
> > This is not intuitive (to me), and recently bit me as a bug:
> > 
> > Python 3.9.1 (default, Dec 13 2020, 11:55:53) 
> > [GCC 10.2.0] on linux
> > Type "help", "copyright", "credits" or "license" for more
> > information.
> > >>> {1,True}
> > {1}
> > 
> > 
> > I've worked around it by storing tuple(type, value) in the set,
> > which is fugly. Yes, I need mixed types in the set, and I'm using
> > the set for efficient lookup.
> > 
> > A contrived example I dreamed-up, which I also find non-intuitive:
> > 
> > >>> x = {}
> > >>> x[True] = 1
> > >>> x
> > {True: 1}
> > >>> x[1] = 1
> > >>> x
> > {True: 1}
> > 
> > 
> > Maybe a wish list item for Python 4.0?
> > 
> > ___
> > 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/3GIWJ3IOTZMJ3ZFPJPQ3EF3SSLBEOSID/
> > 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/73N4MHFPIINAH6R2SI64KHISH53CEIQF/
> 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/R4VT76SDOTIESYOZACKJL54ED56EJMZ4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Standalone bool?

[Paul Bryan]

Wouldn't that still work if bool's __int__ returns 1?

On Mon, 2020-12-21 at 03:09 -0500, David Mertz wrote:
> I sure hope this never happens! It would break millions of working
> lines and kill a common useful pattern.
> 
> ntrue = sum(this == that for this, that in items)
> 
> -100.
> 
> On Mon, Dec 21, 2020, 3:00 AM Paul Bryan  wrote:
> > I know this has come up in the past.
> > 
> > Could the consensus have changed regarding bool's inheritance from
> > int?
> > 
> > This is not intuitive (to me), and recently bit me as a bug:
> > 
> > Python 3.9.1 (default, Dec 13 2020, 11:55:53) 
> > [GCC 10.2.0] on linux
> > Type "help", "copyright", "credits" or "license" for more
> > information.
> > >>> {1,True}
> > {1}
> > 
> > 
> > I've worked around it by storing tuple(type, value) in the set,
> > which is fugly. Yes, I need mixed types in the set, and I'm using
> > the set for efficient lookup.
> > 
> > A contrived example I dreamed-up, which I also find non-intuitive:
> > 
> > >>> x = {}
> > >>> x[True] = 1
> > >>> x
> > {True: 1}
> > >>> x[1] = 1
> > >>> x
> > {True: 1}
> > 
> > 
> > Maybe a wish list item for Python 4.0?
> > 
> > ___
> > 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/3GIWJ3IOTZMJ3ZFPJPQ3EF3SSLBEOSID/
> > 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/6YLVV2AWGTWXYO4G4TAUAGUQKDPS35OA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Standalone bool?

[Paul Bryan]

I know this has come up in the past.

Could the consensus have changed regarding bool's inheritance from int?

This is not intuitive (to me), and recently bit me as a bug:

Python 3.9.1 (default, Dec 13 2020, 11:55:53) 
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> {1,True}
{1}

I've worked around it by storing tuple(type, value) in the set, which
is fugly. Yes, I need mixed types in the set, and I'm using the set for
efficient lookup.

A contrived example I dreamed-up, which I also find non-intuitive:

>>> x = {}
>>> x[True] = 1
>>> x
{True: 1}
>>> x[1] = 1
>>> x
{True: 1}

Maybe a wish list item for Python 4.0?

___
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/3GIWJ3IOTZMJ3ZFPJPQ3EF3SSLBEOSID/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal: typing.affix_type_hints

[Paul Bryan]

Agree that implementation I propose is trivial.

I'm not sure what the benefit of overwriting a string literal in
__annotations__ with the ForwardRef would be when it can be overwritten
with the already evaluated value, hence why I was proposing the latter.

On Thu, 2020-12-10 at 23:00 -0800, Guido van Rossum wrote:
> That looks like a two-line convenience function using no private
> APIs, so you can easily include that in your own toolbox if you need
> it.
> 
> If your concern is that get_type_hints() is too slow, submit a PR
> that makes it faster. There's a cache built into ForwardRef, but it
> appears to be ineffective because a new ForwardRef instance is
> created each time when get_type_hints() encounters a string value.
> Maybe the ForwardRef instance should be stored back into
> `__annotations__`?
> 
> On Thu, Dec 10, 2020 at 10:43 PM Paul Bryan  wrote:
> > With PEP 563 behavior going mainstream in Python 3.10, I see some
> > ramifications, especially for runtime validation of type hints:
> > 
> > 1. PEP 563 is changing the scope of evaluation of type hints, and
> > in some cases it is not feasible to move that scope to the
> > annotated object's globals. (I appreciate the reality that such
> > cases would evade static type checkers.)
> > 
> > 2. The typing.get_type_hints function causes annotation(s) to be
> > evaluated from strings for every call, incurring a potentially
> > significant runtime penalty depending on how often type hints are
> > evaluated at runtime.
> > 
> > To address both of these issues, I'm proposing that a new function
> > be added to typing: affix_type_hints.
> > 
> > I'm thinking something like this:
> > 
> > 
> > def affix_type_hints(obj, globalns=None, localns=None):
> > """
> > Affixes an object's type hints to the object.
> > 
> > Type hints are affixed by first being resolved through
> > get_type_hints, then by storing the result in the object's
> > __annotations__ attribute.
> > 
> > If the object is a class, this function will affix annotations from
> > all
> > superclasses.
> > """
> > 
> > if hints := typing.get_type_hints(obj, globalns, localns,
> > include_extras=True):
> > obj.__annotations__ = hints
> > 
> > 
> > 
> > Advantages:
> > 
> > 1. The time and scope of type hint affixation are under the control
> > of the caller. Future references can be realized before type hints
> > are affixed. If there is a novel local scope required to resolve
> > the type hint, it can be supplied in-context; future calls to
> > get_type_hints inherit the benefit of such pre-resolution.
> > 
> > 2.  Annotations will not be re-evaluated on repeated calls to
> > get_type_hints.
> > 
> > 3. It doesn't require a change to the behavior of the
> > get_type_hints function.
> > 
> > 
> > Disadvantages:
> > 
> > 1. Subclasses inheriting superclass annotations may be undesirable.
> > 
> > 2. Monkey-patching __annotations__ may be considered an anti-
> > pattern. 
> > 
> > 3. Maybe allowing re-evaluation on every get_type_hints call is
> > desirable? (I'd rather avoid the potential for side-effects.)
> > 
> > 4. The cited example is a 2-line function; perhaps its triviality
> > makes it unjustified to add to the stdlib.
> > 
> > 
> > Alternatives:
> > 
> > 1. A caching version of get_type_hints. It looks like
> > ForwardRef.__forward_value__ could actually deliver if annotations
> > were encoded as ForwardRef objects instead of string literals. Am I
> > missing a way for ForwardRef to cache evaluated values when
> > get_type_hints is called?
> > 
> > 2. Something I haven't considered? Please let me know.
> > 
> > 
> > Paul
> > ___
> > 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/GZ7QGEABF624C6SKHUG7CWQAJ3XTJLIO/
> > 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/XULTMMAOQKQEOQRQTZBMIPDDUCNGHRNM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Proposal: typing.affix_type_hints

[Paul Bryan]

With PEP 563 behavior going mainstream in Python 3.10, I see some
ramifications, especially for runtime validation of type hints:

1. PEP 563 is changing the scope of evaluation of type hints, and in
some cases it is not feasible to move that scope to the annotated
object's globals. (I appreciate the reality that such cases would evade
static type checkers.)

2. The typing.get_type_hints function causes annotation(s) to be
evaluated from strings for every call, incurring a potentially
significant runtime penalty depending on how often type hints are
evaluated at runtime.

To address both of these issues, I'm proposing that a new function be
added to typing: affix_type_hints.

I'm thinking something like this:


def affix_type_hints(obj, globalns=None, localns=None):
"""
Affixes an object's type hints to the object.

Type hints are affixed by first being resolved through
get_type_hints, then by storing the result in the object's
__annotations__ attribute.

If the object is a class, this function will affix annotations from all
superclasses.
"""

if hints := typing.get_type_hints(obj, globalns, localns, 
include_extras=True):
obj.__annotations__ = hints


Advantages:

1. The time and scope of type hint affixation are under the control of
the caller. Future references can be realized before type hints are
affixed. If there is a novel local scope required to resolve the type
hint, it can be supplied in-context; future calls to get_type_hints
inherit the benefit of such pre-resolution.

2.  Annotations will not be re-evaluated on repeated calls to
get_type_hints.

3. It doesn't require a change to the behavior of the get_type_hints
function.


Disadvantages:

1. Subclasses inheriting superclass annotations may be undesirable.

2. Monkey-patching __annotations__ may be considered an anti-pattern. 

3. Maybe allowing re-evaluation on every get_type_hints call is
desirable? (I'd rather avoid the potential for side-effects.)

4. The cited example is a 2-line function; perhaps its triviality makes
it unjustified to add to the stdlib.


Alternatives:

1. A caching version of get_type_hints. It looks like
ForwardRef.__forward_value__ could actually deliver if annotations were
encoded as ForwardRef objects instead of string literals. Am I missing
a way for ForwardRef to cache evaluated values when get_type_hints is
called?

2. Something I haven't considered? Please let me know.


Paul
___
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/GZ7QGEABF624C6SKHUG7CWQAJ3XTJLIO/
Code of Conduct: http://python.org/psf/codeofconduct/