[Python-ideas] Re: len(Enum) should raise TypeError

[Thomas Grainger]

mypy does not detect this as a problem because EnumMeta has a `.__len__` method 
https://github.com/python/typeshed/blob/60939b00afede13feeec3cee6f6dfe6eb2df1593/stdlib/enum.pyi#L121

what would the type hints look like if len(Enum) failed but class Foo(Enum): 
pass len(Foo) succeeds?
___
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/RTAF57ZHKB2B75T3OJ73WBNT6JRUQF44/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Use 'bin' in virtual environments on Windows

[Thomas Grainger]

I'd recommend writing a virtualenv plugin that configures 
https://virtualenv.pypa.io/en/latest/extend.html#virtualenv.discovery.discover.Discover

Overriding the interpreter install path here:

https://github.com/pypa/virtualenv/blob/6f8fb11aed7c05a535c30040ce314ae5eec1dcc7/src/virtualenv/create/describe.py#L27

And see what you can make work and what doesn't work
___
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/G4KCMMEMIFHGBWDV7RXDQWHST4ZXSSMC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Use 'bin' in virtual environments on Windows

[Thomas Grainger]

> A practical approach may be to develop some form of library that "hides"
the difference behind some form of API for finding the correct value, get
that added to the stdlib and wait a few years until it's adopted everywhere
(because it's so well-designed and convenient ;-)) Then, you can change the
location. 

Is this the canonical location of this information?

https://github.com/python/cpython/blob/3.10/Lib/sysconfig.py#L56
___
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/FCB675YE3TJEXUU65ZVV5QSJHFDQDJFY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Confusing naming of Optional type should be changed

[Thomas Grainger]

The generic collections in typing were deprecated in favor of the generic
collections in collections.abc. The objects and the types were exposed to
user code, and in the future they will not be

> We don't want there to be warnings about them
> forever

The new  wanrings._deprecated
https://discuss.python.org/t/introducing-warnings-deprecated/14856
automatically removes features, so deprecations cannot be forgotten anymore

On Fri, Jul 1, 2022, 6:19 AM Stephen J. Turnbull 
wrote:

> nveric...@gmail.com writes:
>
>  > I accidentally created another thread in python-dev as I mentioned
>  > above, but ideally Optional and Union should both be deprecated and
>  > phased out for the new syntax.
>
> I think a formal deprecation is a bad idea.  An annotation is an
> object, which has a type.  Both the object and the type are going to
> be visible to users.  We don't want there to be warnings about them
> forever, and Python as a rule does not formally deprecate working code
> that is expected to continue to work indefinitely.
>
> I suspect that it would be difficult to get a stylistic deprecation
> into PEP 8 (IIRC type annotations are still not allowed in stdlib code
> so it would be considered out of scope), but you could try lobbying
> the maintainers of linters.
>
> BTW, I disagree with your arguments that Optional and Union are
> misleading names that can be easily misunderstood, especially in the
> usual context of formal arguments in function definitions.  The
> suggestion of "Noneable" takes the Pythonic implementation of optional
> arguments (by defaulting to None) too seriously, at the expense of the
> syntactic intention: an argument that may be omitted.  Among other
> things, very frequently 'None' is *not* an allowed value in the body
> of the function, some other value is immediately substituted (and PEP
> 671 explicitly tries to automate this process for the common case of a
> mutable default that should be constructed at call time, so that even
> the idiomatic "if arg is None" statement is left out).
>
> "Optional" is the normal term used for such arguments, "union" is the
> technical term for types composed of being either this or that type.
> If you need to know any more than that about those types, you're going
> to have to study up no matter what terms are used.  That's just the
> nature of using natural language words to name things that have a
> precise definition and implementation in software.  Study is required.
>
> Steve
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/LELXP5FPJZWF36NR423ZLVOHGXQTUVKL/
> 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/JCTUUE4NS4TCFPL6JRUWE2V3JG2TX4EJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Thomas Grainger]

No because existence of this attribute is dynamic

On Fri, Jun 25, 2021, 3:44 PM Guido van Rossum  wrote:

> Would a static type checker have found this?
>
> On Fri, Jun 25, 2021 at 02:07 Thomas Grainger  wrote:
>
>> I was debugging some code that was using TLSv1.2 when I expected it to
>> only support TLSv1.3, I tracked it down to a call to:
>>
>> context.miunimum_version = ssl.TLSVersion.TLSv1_3
>>
>> it should have been:
>>
>> context.minimum_version = ssl.TLSVersion.TLSv1_3
>>
>> I'd like invalid attribute assignment to be prevented at runtime
>> ___
>> 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/RPD5OICSY3KLVXKIYWFTABNIA7F7YWG3/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> --
> --Guido (mobile)
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GPCJXBGQYBIT5QYRWUSI3YKU265W4XJY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Thomas Grainger]

urllib3 was also burned by this problem
https://github.com/urllib3/urllib3/issues/2636

On Fri, Jul 9, 2021, 5:39 PM Thomas Grainger  wrote:

> >  if we find time to implement it for 3.11.
>
> https://www.python.org/dev/peps/pep-0543/#configuration
> was Withdrawn
>
> would this need a new PEP?
> ___
> 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/VV7ZQVXICCUXOTBZ4LMWA7TAJSGEEF2V/
> 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/MRYEHDRVAUQUTMSJUUNENO7RQ3IGN2L5/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Thomas Grainger]

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")]
```
___
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/VAQA5BDLL3PZAGDP6YW4Y4APDMMTGQCP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Fwd: Simple curl/wget-like download functionality in urllib (like http offers server)

[Thomas Grainger]

Tom Pohl wrote:
> A question for the Python experts: What is the correct technical term for a 
> functionality like "http.server", i.e., a module with an actual "main" 
> function?

There's some details about it here 
https://docs.python.org/3/library/__main__.html#idiomatic-usage
___
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/JNIFYQHJPQICMRA4U3E5OAMCKZI4UG5D/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Thomas Grainger]

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

[Python-ideas] Re: define an idiomatic way to make a generator that throws StopIteration immediately and add it to PEP8

[Thomas Grainger]

`yield from (,)` produced different byte code when I tried it, so I think it's 
a tad slower

Also yield from doesn't work in async generators
___
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/6COTBSYSGO2L26AK6PR2ZNNXVE6MRZTO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add timeout parameter to Synchronization Primitives in asyncio

[Thomas Grainger]

I'd imagine that context manager here simply wouldn't cancel the current
task if the lock can be acquired in time:

```
async with lock.acquire(timeout=1.0):
await do_things_with_lock()
```

On Mon, 20 Sep 2021, 14:15 Gustavo Carneiro,  wrote:

> On Mon, 20 Sept 2021 at 13:15, Chris Angelico  wrote:
>
>> On Mon, Sep 20, 2021 at 9:48 PM Gustavo Carneiro 
>> wrote:
>> >
>> > Note that you can wrap any of those methods with an asyncio.wait_for().
>> >
>> > try:
>> >try:
>> >await asyncio.wait_for(lock.acquire(), 1.0)
>> >except asyncio.TimeoutError:  # times out after 1 second
>> >print("deadlock!")
>> >return
>> >do_things_with_lock()
>> > finally:
>> >lock.release()
>> >
>> >
>> > Although I must admit, it would be convenient to have a timeout
>> parameter directly in the methods like acquire, especially because it would
>> make timeouts usable directly in the async context manager:
>> >
>> > async with lock.acquire(timeout=1.0):
>> >do_things_with_lock()
>> >
>>
>> How would this signal a timeout to your code? It looks lovely and
>> clean, but there still need to be two branches, so you're not really
>> going to avoid the try/except layer.
>>
>
> Right.  If you needed to handle the timeout, you would need a try except.
> Else the TimeoutError exception that gets raised is unhandled and bubbles
> up.
>
> try:
> async with lock.acquire(timeout=1.0):
> do_things_with_lock()
> except asyncio.TimeoutError:
> print("deadlock!")
> return
>
> I mean, this is just slightly more convenient, probably slightly less
> scary for some people, but that's all.
>
> 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/CBBP7KHS27AF63EW72VXEYZVFLRBSY4R/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> Gustavo J. A. M. Carneiro
> Gambit Research
> "The universe is always one step beyond logic." -- Frank Herbert
> ___
> 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/EIOECL4WGOA37SEXLBXYECZRQFIT7NQ7/
> 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/S2EX6GPFE6OI62DCENGRLUC7I4QW3FAV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add timeout parameter to Synchronization Primitives in asyncio

[Thomas Grainger]

anyio provides a nice context manager that works in both asyncio and trio:

```
import anyio

async def async_fn():
with anyio.move_on_after(1.0) as scope:
async with lock:
scope.deadline = math.inf
await do_things_with_lock()
```
___
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/F2KFDUD76HMFYFJEIMGOETAZYTKUUZFZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Context manager for csv module 'reader' and 'DictReader'?

[Thomas Grainger]

I really like json.loadf I'd also like to see a csv.loadf. not sure the `f`
is needed: you could use @functools.singledispatch

On Mon, 6 Sep 2021, 01:12 Christopher Barker,  wrote:

> On Sun, Sep 5, 2021 at 10:32 AM David Mertz, Ph.D. 
> wrote:
>
>> Most Pandas read methods take either a path-like argument or a file-like
>> argument, and figure out which it is by introspection when called.
>> Actually, most of them even accept a URL-like argument as well
>>
>> I don't think this is a terrible approach. It doesn't make things quite
>> as explicit as the standard library generally does.
>>
>
> The folks in favor of adding this to json are split between overloading
> load() (my preference) and adding a new, explicit method: loadf() or
> something like that. Either way, it's useful. I honestly don't get the
> objection. MY takle is that mosto f the core devs are doing "systsms
> programming" rather than "scripting" -- which means that they a:
>
> Want to be more explicit and robust
> Need more flexibiilty around various file-like objects
> Don't mind a bit more expertise required. (e.g. specifying the encoding
> correctly)
> Don't mind  a couple extra lines of code.
>
> So why add a function to make it simple and easy to read a file fro a
> path-like?
>
> I really wish the core devs would remember how useful Python is as a
> scripting language, and how many people use it that way.
>
> Pandas is a good example, I lot of folks use it in a scripting context, so
> it provided features that make it easy to do so.
>
> -CHB
>
>
> On Sun, Sep 5, 2021, 1:19 PM Christopher Barker 
>> wrote:
>>
>>>
>>> This would only be helpful when the CSV is on the disk but csv.reader()
 takes a file object so that it can used with anything like a socket for
 example. json.load() does the same thing.

>>>
>>> There has been discussion about adding loading from a “path like” to the
>>> JSON lib. See this list about ten months ago and a recent thread on discuss.
>>>
>>> There resistance, but it ended with the idea that maybe there should be
>>> a PEP for a common interface for all “file” readers — eg JSON, CSV, etc..
>>> And that interface could be supported by third party libs. That interface
>>> *maybe* would include a single step load from a path-like functionality.
>>>
>>> It seems to me that it is better to keep a generic interface that are
 composable.

>>>
>>> No one is suggesting removing the load-from-a-file-like interface. I
>>> have no idea why the fact that some people sometimes need a more flexible
>>> interface (maybe most people, even) somehow means that we shouldn’t make
>>> things easy and obvious for a common use case.
>>>
>>> -CHB
>>>
>>>
>>>
>>>
 Cheers,
 Rémi



 ? And something similar for ‘csv.reader’? I’m not wedded to the details
 here.

 The two main reasons I think this might be a positive addition are -

 * you wouldn’t have to know or remember the right way to open a CSV
 file (newline=“”).
 * it elides very common code.

 but perhaps there are things I’m missing here?

 As a side note, I think ‘csv.reader’ could usefully be renamed to
 something else (maybe just Reader?), since it’s kind of out of sync with
 the CamelCase used in ‘DictReader’. But maybe that’s just an attempt at
 foolish consistency :).

 best,
 —titus

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

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

[Python-ideas] Re: Context manager for csv module 'reader' and 'DictReader'?

[Thomas Grainger]

Seems nice, tarfile has a similar shortcut too. I do tend to reach for
pandas now whenever I can for csv processing

On Sun, 5 Sep 2021, 16:10 C. Titus Brown via Python-ideas, <
python-ideas@python.org> wrote:

> Hi all,
>
> the product of Sunday morning idle curiosity...
>
> I’ve been using the csv module a lot, and I’m wondering if there would be
> value in adding a standard mechanism for opening a CSV file (correctly)
> using a context manager?
>
> So, instead of
>
> with open(filename, newline=“”) as fp:
>r = csv.DictReader(fp)
>for row in r:
>   …
>
> support something like
>
> with csv.DictReader.open(filename) as r:
>for row in r:
>   …
>
> ? And something similar for ‘csv.reader’? I’m not wedded to the details
> here.
>
> The two main reasons I think this might be a positive addition are -
>
> * you wouldn’t have to know or remember the right way to open a CSV file
> (newline=“”).
> * it elides very common code.
>
> but perhaps there are things I’m missing here?
>
> As a side note, I think ‘csv.reader’ could usefully be renamed to
> something else (maybe just Reader?), since it’s kind of out of sync with
> the CamelCase used in ‘DictReader’. But maybe that’s just an attempt at
> foolish consistency :).
>
> best,
> —titus
>
> ___
> 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/EKHYCTYMXZG3VI4JYFA3Y3LD3ZNMI3IX/
> 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/RA2RH37O3XHZ4XGQ36OLOZPWU5LOEXMM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a special TypeError subclass for implementation errors

[Thomas Grainger]

Serhiy Storchaka wrote:
> There are two different kinds of TypeError: if the end user passes an
> instance of wrong type and if the author of the library makes an error
> in implementation of some protocols.
> For example, len(obj) raises TypeError in two cases: if obj does not
> have __len__ (user error) and if obj.returns non-integer (implementation
> error). for x in obj raises TypeError if obj does not have __iter__
> (user error) and if iter(obj) does not have __next__ (implementation error).

what's the reason for this not to raise AttributeError? I assume you asked this 
question in relation to the 3.11 changes to `with x:` raising TypeError vs 
AttributeError ?
> User errors can be fixed on user side, implementation errors can only be
> fixed by the author of the class. Even if the user and the author is the
> same person, these errors point to different places of code.
> Would it be worth to add a special TypeError subclass for implementation
> errors to distinguish them from user errors? How to name it
> (ImplementationError, ProtocolError, etc)?

I think ProtocolError would be too easily confused as relating to 
typing.Protocol or asyncio.Protocol
ImplementationError sounds like it's related to `abc`s or NotImplementedError

How about `AttributeNotFoundError` or `AttributeRequiredError` ?
___
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/CGW5TKJJWZSOBYJDGWW3KVTV4XGAZ7CV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] define an idiomatic way to make a generator that throws StopIteration immediately and add it to PEP8

[Thomas Grainger]

the way to make an (aysnc)generator that immediately raises 
Stop(Async)Iteration immediately is to insert an unreachable `yield` statement, 
however there's two ways to do it:

def example():
if False:
yield

or:


def example():
return
yield

currently test_asyncgen.py uses both, eg:

@types.coroutine
def __anext__(self):
if False:
yield "this is a generator-based coroutine"
if self.yielded >= 2:
raise StopAsyncIteration()
else:
self.yielded += 1
return self.yielded

or:


async def agenfn():
try:
await _async_yield(1)
except MyError:
await _async_yield(2)
return
yield

the `if False: yield` version has a disadvantage in that it can be anywhere in 
the function, if this one is chosen then an additional caveat is that it should 
be the first two statements in a function
if `return; yield` version has an disadvantage in that the unreachable yield 
could be inserted after any `return`, if this one is chosen then an additional 
caveat is that it should be the last two statements in a function and de-dented 
as much as syntactically possible.

Which alternative do you prefer? I prefer `return; yield`
___
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/XUGWXWD7VBJWXBJWEGFT3OUEXCAL5GMT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[Thomas Grainger]

Nick Parlante wrote:
> Hi there python-ideas - I've been teaching Python as a first
> programming language for a few years, and from that experience I want
> to propose a change to PEP8. I'm sure the default position for PEP8 is
> to avoid changing it. However, for this one rule I think a good case
> can be made to make it optional, so let me know what you think.
> Let me start with what I've learned from teaching students in Java and
> now in Python. In Java, you use == for ints, but you need to use
> equals() for strings. Of course students screw this up constantly,
> using == in a context that calls for equals() and their code does not
> work right. Then for Java arrays a different comparison function is
> required, and so it goes. To teach comparisons in Python, I simply say
> "just use ==" - it works for ints, for strings, even for lists.
> Students are blown away by how nice and simple this is. This is how
> things should work. Python really gets this right.
> So what is the problem?
> The problem for Python is what I will call the "mandatory-is" rule in
> PEP8, which reads:
> Comparisons to singletons like None should always be done with is or
> is not, never the equality operators.
> For the students, this comes up in the first week of the course with
> lines like "if x == None:" which work perfectly with == but should use
> is/is-not for PEP8 conformance.
> My guess is that this rule is in PEP8 because, within a Python
> implementation, it is within the programmer's mental model that, say,
> False is a singleton. The mandatory-is rule is in PEP8 to reinforce
> that mental model by requiring the is operator. Plus it probably runs
> a tiny bit faster.
> However, for "regular" Python code, not implementing Python, forcing
> the use of is instead of the simpler == is unneeded and unhelpful (and
> analogously forcing "is not" when != works correctly). What is the
> benefit of forcing the is operator there? I would say it spreads an
> awareness of the details of how certain values are allocated within
> Python. That's not much of a benefit, and it's kind of circular. Like
> if programmers were permitted to use ==, they wouldn't need to know
> the details of how Python allocates those values. Being shielded from
> implementation details is a Python strength - think of the Java vs.
> Python story above. Is Java better because it builds an awareness in
> the programmer of the different comparison functions for different
> types? Of course not! Python is better in that case because it lets
> the programmer simply use == and not think about those details.
> Understanding the singleton strategy is important in some corners of
> coding, but forcing the is operator on all Python code is way out of
> proportion to the benefit.
> As a practical matter, the way this comes up for my students is that
> IDEs by default will put warning marks around PEP8 violations in their
> code. Mostly this IDE-coaching is very helpful for students learning
> Python. For example, It's great that beginning Python programmers
> learn to put one space around operators right from the first day.
> Having taught thousands of introductory Python students, the one PEP8
> rule that causes problems is this mandatory-is rule.
> As a teacher, this is especially jarring since the "just use ==" rule
> is so effortless to use correctly. In contrast, the mandatory-is rule
> adds a little pause where the programmer should think about which
> comparison operator is the correct one to use. It's not hard, but it
> feels unnecessary.
> As a contrasting example, in the language C, programmers need to
> understand == vs. is right from the first day. You can't get anything
> done in C without understanding that distinction. However that is just
> not true for regular (not-Python-implementation) Python code, where ==
> works correctly for the great majority of cases.
> Here is my proposal:
> Add the following parenthetical to the mandatory-is rule: (this rule
> is optional for code that is not part of an implementation of Python).
> So in effect, programmers outside of a Python implementation can
> choose to use == or is for the "if x == None:" case. In this way, PEP8
> conforming code before the change is still conforming. Moving forward,
> I would expect that regular code will trend towards using == in such a
> case, reserving is for the rare cases where it is needed for
> correctness.
> PEP8 was originally just for Python implementations, so why is this
> change needed? Because as a practical matter, the vast majority of
> code that is using PEP8 is not part of a Python implementation. This
> may not have been the original mission of PEP8, but it is how things
> have worked out.
> Now we are in a situation where the rules in PEP8 are sent out to this
> ocean of Python programmers of many different ability levels writing
> regular code that is not a Python implementation. One could imagine a
> separate PEP800 style guide for regular code, but we don't 

[Python-ideas] Re: synatx sugar for quickly run shell command and return stdout of shell command as string result

[Thomas Grainger]

subprocess.run(args, capture_output=True, check=True, text=True,
encoding="utf8").stdout ?

On Thu, 26 Aug 2021, 13:55 Evan Greenup via Python-ideas, <
python-ideas@python.org> wrote:

> Currently, when what to execute external command, either os.system() or
> subprocess functions should be invoked.
>
> However, it is not so convenient, it would be nice to use "``" symbol to
> brace the shell command inside.
>
> like:
>
> stdout_result_str = `cat file.txt | sort | grep hello`
>
> Its is enhanced feature which combine both subprocess and os.system
>
> Because, subprocess can return output of file, but does not support pipe
> in command.
>
> While os.system can apply pipe in command but doesn't support return
> stdout result.
>
> This can be very convenient to make python available for some build script
> which ruby now do well like homebrew ...
>
> simply
>
> `echo hello | wc -l` while only execute command and the result will just
> like other unassigned expression, the result will be finally discarded.
>
> There won't be big difficulties to implement.
> ___
> 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/5KKHG6TLBLI46XBPSOBU7FTL5TB57EIC/
> 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/QFMX6LVUNYQ2E537B2ZJTHQXOISCCLLO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

[Thomas Grainger]

Right but this doesn't work with bumpy or pandas
___
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/IOW24AEGNSFDFKQEBJG2HZCUYIU2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

[Thomas Grainger]

>  This is a shortcoming of the language.

this could be fixed if the built-in bool checked to see if the value was a 
numpy.array or a pandas.DataFrame and automatically called `array.size > 0` or 
`df.empty`
___
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/2KIWW7FBVQIETSVZHC3H5NPLRGRMVSNA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

[Thomas Grainger]

here's another fun one "A False midnight": https://lwn.net/Articles/590299/ 
https://bugs.python.org/issue13936#msg212771
___
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/IFVHWIOEYST34IVQVOYX7UA45AU6EQ4O/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

[Thomas Grainger]

In all seriousness this is an actual problem with numpy/pandas arrays where:

```
Python 3.8.10 (default, Jun  2 2021, 10:49:15) 
[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> numpy.array([1, 2, 3])
array([1, 2, 3])
>>> bool(numpy.array([1, 2, 3]))
Traceback (most recent call last):
  File "", line 1, in 
ValueError: The truth value of an array with more than one element is 
ambiguous. Use a.any() or a.all()
>>> bool(numpy.array([]))
:1: DeprecationWarning: The truth value of an empty array is ambiguous. 
Returning False, but in future this will result in an error. Use `array.size > 
0` to check that an array is not empty.
False
>>> import pandas
>>> df = pandas.DataFrame()
>>> bool(df)
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/home/graingert/.virtualenvs/redacted/lib/python3.8/site-packages/pandas/core/generic.py",
 line 1537, in __nonzero__
raise ValueError(
ValueError: The truth value of a DataFrame is ambiguous. Use a.empty, a.bool(), 
a.item(), a.any() or a.all().
```

eg 
https://pandas.pydata.org/pandas-docs/version/1.3.0/user_guide/gotchas.html#using-if-truth-statements-with-pandas
> Should it be True because it’s not zero-length, or False because there are 
> False values? It is unclear, so instead, pandas raises a ValueError:

I'm not sure I believe the author here - I think it's clear. It should be True 
because it's not zero-length.
___
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/P7FA42SYR3DKSVSBAVLIHGSJXO3AT33G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

[Thomas Grainger]

bool((len(collection) == 0) is True) == True and issubclass(True, bool)

On Sun, 22 Aug 2021, 17:09 Valentin Berlier,  wrote:

> > (len(collection) == 0) is True
>
> bool((len(collection) == 0) is True) == True
> ___
> 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/MAPJNXHXGE64QJWLZ27HDPU4NMTI52W5/
> 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/IUMJCWRZMM4JSF6OQTGNAFREOTI7EXHT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Stack-scoped variables

[Thomas Grainger]

asyncio.to_thread creates threads that inherit the current context, according 
to https://www.python.org/dev/peps/pep-0567/#rationale the decimal module 
should use contextvars for this too
___
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/IWP3BYSQW43GYZIABQUBJJEHWJTI2ITI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: multiprocessing: hybrid CPUs

[Thomas Grainger]

Would a work stealing approach work better for you here? Then the only
signalling overhead would be when a core runs out of work

On Thu, 19 Aug 2021, 05:36 Stephen J. Turnbull, <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> Christopher Barker writes:
>
>  > The worker pool approach is probably the way to go, but there is a fair
> bit
>  > of overhead to creating a multiprocessing job. So fewer, larger jobs are
>  > faster than many small jobs.
>
> True, but processing those rows would have to be awfully fast for the
> increase in overhead from 16 chunks x 10^6 rows/chunk to 64 chunks x
> 250,000 rows/chunk to matter, and that would be plenty granular to
> give a good approximation to his 2 chunks by fast core : 1 chunk by
> slow core nominal goal with a single queue, multiple workers
> approach.  (Of course, it almost certainly will do a lot better, since
> 2 : 1 was itself a very rough approximation, but the single queue
> approach adjusts to speed differences automatically.)
>
> And if it's that fast, he could do it on a single core, and still done
> by the time he's finished savoring a sip of coffee. ;-)
>
> Steve
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/TCC7ZZLP7YMOCWSKIC2KXQQVBKT3UIMZ/
> 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/XURUCC3WOCZ3UT6W2FHTJ6NGLCBR5WDO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New 'How to Write a Good Bug Report' Article for Docs

[Thomas Grainger]

Jack DeVries wrote:
> Hi All!
> We are trying to replace a link in the official docs which is now
> broken, but used to link to this article:
> https://web.archive.org/web/20210613191914/https://developer.mozilla.org/en-...
> Can you offer a suggestion for a replacement? The bad link has already
> been removed. Also see the bpo:
> https://bugs.python.org/issue44830
> Also see the rather stale discourse post to the same effect as this
> email (asking for replacement article ideas):
> https://discuss.python.org/t/alternate-article-for-how-to-wite-good-bug-repo...
> Thanks!
> Jack
Looks like the content is back online with a redirect pending

https://github.com/mdn/content/issues/8036#issuecomment-901262333
___
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/32PVUY5IWFOGMFNJB4S5Q4S35K7LZRBD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New 'How to Write a Good Bug Report' Article for Docs

[Thomas Grainger]

It looks like the source moved here 
https://github.com/mdn/archived-content/blob/main/files/en-us/mozilla/qa/bug_writing_guidelines/index.html
___
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/3C35FI2L3CJKIYKU7UPUD5ERNIZ3LGAC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New 'How to Write a Good Bug Report' Article for Docs

[Thomas Grainger]

It looks like it was removed unintentionally because the Mozilla support
pages still reference it
https://support.mozilla.org/en-US/kb/contributors-guide-writing-good-bug#w_existing-guidelines-for-writing-your-first-bug

On Mon, 16 Aug 2021, 18:30 Jack DeVries,  wrote:

> > Is there a reason why we can't just link to the Wayback Machine copy like
> > you did here?
>
> That has been discussed on the bpo thread, we felt that is a clunky
> solution. Another proposed solution on the bpo is for someone to write a
> new document about making good bug reports, pertinent to the cpython
> project.
>
> On Mon, Aug 16, 2021 at 10:53:59AM -0400, Jonathan Goble wrote:
> > On Mon, Aug 16, 2021, 10:30 AM Jack DeVries 
> wrote:
> >
> > > Hi All!
> > >
> > > We are trying to replace a link in the official docs which is now
> > > broken, but used to link to this article:
> > >
> > >
> > >
> https://web.archive.org/web/20210613191914/https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines
> >
> >
> > Is there a reason why we can't just link to the Wayback Machine copy like
> > you did here?
> >
> > >
> > >
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/YY5UUC2ANVUH4VMKNGC4YZH4NSGIFQJ3/
> 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/ACIVEOGHGWKGCLS2ITMFSMHUCR6DPXGZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP idea

[Thomas Grainger]

You can use `T | None`
___
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/G6UWX2W7SQ7VUYOPDKDTULLWOIIWD7RS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP idea

[Thomas Grainger]

Any has the same number of characters as All
___
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/O23FEL4BWZKQF6C7Y5WEOH33FYJISMKB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: `not not x` much faster than `bool(x)`

[Thomas Grainger]

how does it compare with the old:

```
def rh(ham, _bool=bool):
return _bool(ham)
```
___
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/3R4JHMD7RF7SUCYQDWRCTG6NUOELCSDH/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Thomas Grainger]

Specially I'd like to be able to deprecate the `Callable[..., Iterable[T]]`
type of contextlib.contextmanager

See https://github.com/python/typeshed/pull/2773#issuecomment-458872741

On Thu, 29 Jul 2021, 22:00 Thomas Grainger,  wrote:

> I'd like to be able to specificy @deprecate on only some @overloads
>
> On Thu, 29 Jul 2021, 21:59 Paul Bryan,  wrote:
>
>> 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 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/MCE3MXC27VZ2Y7VDVBXV4CCJ56FIHITC/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Thomas Grainger]

I'd like to be able to specificy @deprecate on only some @overloads

On Thu, 29 Jul 2021, 21:59 Paul Bryan,  wrote:

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

[Thomas Grainger]

But heterogeneous iteration would require typing changes

On Thu, 29 Jul 2021, 02:18 Eric V. Smith,  wrote:

> In dataclasses, support for __slots__ is being added in 3.10. Adding
> optional support for iteration would be easy.
>
> --
> Eric V. Smith
>
> On Jul 28, 2021, at 7:29 PM, Paul Bryan  wrote:
>
> 
> 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 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/ESOIUHFM26SPCLP4VZCY7WETXJWFVBOC/
> 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/XXG2WNIZRDHXCLJHDAAHME5CKJV7ZMVF/
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.

[Thomas Grainger]

I've thing I still use NamedTuple for is when I want type safe
heterogeneous iterable unpacking, which is only possible for tuples (and
NamedTuple) eg I'd like to be able to express both:

tx, rx = trio.MemoryChanel[int]()

And:

with trio.MemoryChannel[int]() as channel:
n.start_soon(worker, channel.recieve_channel.clone())

On Thu, 29 Jul 2021, 00:36 Chris Angelico,  wrote:

> On Thu, Jul 29, 2021 at 9:28 AM Paul Bryan  wrote:
> >
> > 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?
> >
>
> It can. It still doesn't get efficiency down to where a namedtuple is,
> and it also doesn't make it into a tuple.
>
> Allow me to simplify matters. You could, instead of using a regular
> tuple, just use a dict with keys that are consecutive integers. This
> would behave in a very similar way, and then you could subclass the
> dict to change the iteration behaviour (or even rely on old-style
> fallback iteration). Does that mean that tuples are nothing but
> special-purpose dicts for efficiency? Not even slightly. They are
> different data structures for different purposes.
>
> It's the same with namedtuple, dataclass, and all the other different
> tools we have. They serve very different purposes. And even if one of
> them could truly be described as a higher-performance less-flexible
> version of another, there'd still be very little benefit to
> deprecating it. Remember that breaking people's code is a VERY serious
> concern.
>
> 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/TWWK23EG3J2MAWDYPDLIIU2FISORYVBR/
> 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/BNJ4JIWBBLFNIMQQVTPI727JATCSCISW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: weakref.link: Keep A alive while B is alive (and/or update WeakKeyDictionary)

[Thomas Grainger]

Would fixing this help? https://bugs.python.org/issue44140

On Tue, 20 Jul 2021, 02:16 Sebastian Berg, 
wrote:

> On Mon, 2021-07-19 at 22:24 +, Mark Gordon wrote:
> > Proposal:
> >
> > Have a weakref.link (not at all attached to the naming) primitive
> > that allows one to keep object A alive while object B is alive. This
> > would be functionally similar to adding A as an attribute of B from
> > the GC's perspective without making any assumptions about what
> > attributes are available in B. Here's a really course example of how
> > this might be used:
> >
>
> Probably, the "stake holders" on this list are well aware.  But, as far
> as I understand, this is (or requires) an "Ephemeron":
>
> https://en.wikipedia.org/wiki/Ephemeron
>
> While I might be tempted to try/use it if Python had it (and was
> available from C), I doubt that it actually matters in practice, for my
> "use case".
>
>
> The "use case", why I was curious about it is for multiple-dispatching
> (to allow users to extend NumPy).
> If you dispatch based on input types and the input type can be deleted,
> the same problem arises:  The (type specific) implementation is
> expected to – and sometimes must – hold a strong reference to the input
> types.  Thus creating an unbreakable circle.
>
> (You can avoid this sometimes, but I don't think you can in general)
>
> An Ephemeron should be able to describe this correctly. I expect even a
> situation like:
>
> func(A, B) -> (A, B, C)
>
> which can be deleted if either `A` or `B` is "almost collectable", but
> must keep alive `C` if both `A` and `B` are alive.
>
> Cheers,
>
> Sebastian
>
>
> > # Associate "extra_data" with "obj" where "extra_data" will lose its
> > reference when "obj" is no longer reachable through strong refs.
> > my_link = weakref.link(obj, extra_data)
> >
> > ...
> >
> > obj, extra_data = my_link()
> > if obj is not None:
> >   do_something(obj, extra_data)
> >
> >
> > This would also allow us to fix or create a new version of
> > WeakKeyDictionary where values can have strong references back to
> > their key without preventing their key from being reclaimed. This has
> > been an issue for tensorflow in the past (see
> > https://github.com/tensorflow/tensorflow/issues/42022) and is likely
> > to be a subtle issue in many more libraries. Even the suggested use
> > case in the docs "This can be especially useful with objects that
> > override attribute accesses." is likely to be broken because of this
> > issue.  While I'd be weary of changing the semantics of an existing
> > data structure it seems highly unlikely anything depends on this
> > behavior since it makes WeakKeyDictionary degrade to behaving like a
> > normal dictionary for that key.
> >
> >
> > Notes:
> > * Not attached to this specific approach or API
> > * Mostly interesting in updating/creating new WeakKeyDictionary as
> > mentioned
> > ___
> > 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/4KBLRV7QYS36NVJNKAJIDCFTH4DF5YSY/
> > 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/7C7EVG5ALBP266T6FROR6L7IK4GULPIS/
> 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/AOFYS2KTGVEZJ2WFY7BOEUZIK2QGMJKY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: builtins for running context managers

[Thomas Grainger]

Right but it's not a status code - it's a callback that you *must* call

On Fri, 16 Jul 2021, 17:17 MRAB,  wrote:

> On 2021-07-16 12:44, Stephen J. Turnbull wrote:
> > Thomas Grainger writes:
> >
> >   > Another example, is a cash point (ATM) won't give you your money
> >   > until you take your card
> >
> > That ATM is effective in enforcing the desired behavior.  In Python
> > you would usually use an exception to force handling.  Returning
> > status codes, or couples of status codes and values, isn't nearly as
> > effective.
> >
> > And a (status, value) couple does nothing to encourage checking the
> > code over (value, status).
> >
> To me, it makes more sense to return (status, value) than (value,
> status) because it's clearer to say "that didn't work, so you can just
> ignore the value" than "here's a value, but it didn't work, so just
> ignore the value even though I mentioned it first".
> ___
> 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/MUAGZXQ3A6CUHL5O6GSGHOECKIJVA2Q3/
> 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/GQEHAVB4PGFAPDKM3FIYRSGS2A2D3MET/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: builtins for running context managers

[Thomas Grainger]

Another example, is a cash point (ATM) won't give you your money until you
take your card

On Fri, 16 Jul 2021, 09:28 Stephen J. Turnbull, <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> Ethan Furman writes:
>
>  > Isn't that javascript?  Javascript idioms are not (necessarily)
>  > Python idioms.
>
> True, but unless there is (preferably) a Python idiom or one from
> another language we borrow from at least somewhat frequently, why not
> adopt the Javascript idiom?
>
> Note: I don't think you were arguing *against* this idiom, just
> querying the relevance.
>
> I did question the OP's "value you need, value you want"
> characterization.  It's not obvious to me you can decide that for the
> caller.
>
>
> ___
> 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/WO74OJRHNJNO3KRRUUM5PKTHR2MQKWL4/
> 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/5MRMZHDIYVEBIEF5MRRUI5GOL6XRJ2FP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: builtins for running context managers

[Thomas Grainger]

Like the nodeback interface, it's (err, val)

On Tue, 13 Jul 2021, 21:31 Ethan Furman,  wrote:

> On 7/13/21 12:43 PM, Thomas Grainger wrote:
>
>  > I used the order I did because it's idiomatic to return the value the
> user needs
>  > followed by the value the user wants.
>
> citation?
>
> --
> ~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/SBUNQOCAQTBWIGRUIP5BMMEEYEN7Y4F4/
> 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/LJLJZRGOZREPMFDOGTGAW36PKZ23YXMG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: builtins for running context managers

[Thomas Grainger]

also https://www.python.org/dev/peps/pep-0343/ probably needs updating - but 
I'm not sure exactly what the code is
___
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/PBTL5T2NQGRBNREW6Z74AGB43ZV63P7V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: builtins for running context managers

[Thomas Grainger]

I used the order I did because it's idiomatic to return the value the user
needs followed by the value the user wants.

On Tue, 13 Jul 2021, 20:24 Serhiy Storchaka,  wrote:

> 13.07.21 18:59, Thomas Grainger пише:
> > given that it's hard to implement this correctly I think there should be
> a builtins.enter and builtins.aenter for use like this:
> >
> >
> > ```
> > @dataclasses.dataclass
> > class WrapCmgr:
> > _cmgr: ContextManager[T]
> >
> > def __enter__(self) -> Wrapped[T]:
> > exit, value = enter(self._cmgr)
> > self.__exit = exit
> > return wrap(value)
> >
> > def __exit__(self, \, t: Type[BaseException] | None, v:
> BaseException, tb: types.TracebackType) -> bool:
> > return self.__exit(t, v, tb)
> > ```
>
> I considered similar idea when worked on issue12022 and issue44471. The
> only difference is that I added the helper in the operator module, and
> my operator.enter() returned the value and the callback in the different
> order.
>
> def enter(cm):
> # We look up the special methods on the type to match the with
> # statement.
> cls = type(cm)
> try:
> enter = cls.__enter__
> exit = cls.__exit__
> except AttributeError:
> raise TypeError(f"'{cls.__module__}.{cls.__qualname__}' object
> does "
> f"not support the context manager protocol")
> from None
> callback = _MethodType(exit, cm)
> return enter(cm), callback
>
> I still investigate possible consequences and alternatives.
>
> Since we need to save the callback as an object attribute in any case,
> one of alternatives is using ExitStack instead of introducing new API.
> It is more heavyweight, but if implemented in C the difference can be
> reduced.
>
> Other alternative is to expose _PyObject_LookupSpecial() at Python
> level. It would be useful not only for __enter__ and __exit__, but for
> other special 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/FAQAGFAFVVAKPAU3U6AMFTKUMZCLK2GY/
> 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/JT3NJWCSDXGQH32FGT5SDP7N7EQEOA2O/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] builtins for running context managers

[Thomas Grainger]

currently lots of code manages contexts incorrectly by doing:

```
@dataclasses.dataclass
class WrapCmgr:
_cmgr: ContextManager[T]

def __enter__(self) -> Wrapped[T]:
return wrap(_cmgr.__enter__())

def __exit__(self, \, t: Type[BaseException] | None, v: BaseException, tb: 
types.TracebackType) -> bool:
return _cmgr.__exit__(t, v, tb)
```


since https://bugs.python.org/issue44471 using `with WrapCmgr(cmgr()):` 
incorrectly raises an AttributeError rather than a TypeError

and https://www.python.org/dev/peps/pep-0343/ still includes this bug, raising 
an AttributeError

```
mgr = (EXPR)
exit = type(mgr).__exit__  # Not calling it yet
value = type(mgr).__enter__(mgr)
```

contextlib.ExitStack also had this bug https://bugs.python.org/issue12022

given that it's hard to implement this correctly I think there should be a 
builtins.enter and builtins.aenter for use like this:


```
@dataclasses.dataclass
class WrapCmgr:
_cmgr: ContextManager[T]

def __enter__(self) -> Wrapped[T]:
exit, value = enter(self._cmgr)
self.__exit = exit
return wrap(value)

def __exit__(self, \, t: Type[BaseException] | None, v: BaseException, tb: 
types.TracebackType) -> bool:
return self.__exit(t, v, tb)
```
___
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/GV5ZCOT3UHLDEMPOCWWDTSDARIB7SYYN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: pathlib.Path(...).json() (again)

[Thomas Grainger]

> It opens the file in the main thread, and not asynchronously, but doesn't
the file itself get read in the other thead, asynchronously? And is there
any extra RAM used?

The file could be on an external network drive and so opening it may block the 
main thread for seconds:

```
with open(the_path, 'rb') as the_file:  # no other tasks can progress while 
opening this file
return await asyncio.to_thread(json.load, the_file)
```

> Also -- and this may be completely my ignorance -- but don't you need to
wrap the json reading in a function anyway so that you can capture the
result somewhere?

asyncio.to_thread is an async function that returns the result of the passed in 
synchronous function, and can run concurrently with other tasks by scheduling 
the synchronous function on a thread



> In short -- no, I don't think JSON is not special enough to get a Path
method, but a simple way to read JSON directly from a Path would be nice.

```
asyncio.to_thread(json.loadf, the_path)
```
would be fine too
___
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/WVA2E4RPLTK5N3NGVT66H4HDH3MURXWC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: pathlib.Path(...).json() (again)

[Thomas Grainger]

It's a utility method, so its usefulness derives from being available 
everywhere without having to patch it in.


For me what's changed is the introduction of `asyncio.to_thread` and PEP 597 
making `pathlib.Path.open` slightly less ergonomic,
___
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/2DNZ6RIC272KIBGXYT5K6IRMM4CUZ3QS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] pathlib.Path(...).json() (again)

[Thomas Grainger]

It's been brought up a few times eg:  
https://github.com/python/cpython/pull/12465

but I really think it's time to be re-considered.


Specifically I love being able to use 
`asyncio.to_thread(pathlib.Path(...).read_text, encoding="utf8")` It does 
exactly the right thing for me! It's great because it interacts with the event 
loop as few times as possible and uses only the RAM absolutely required.


I'm looking to be able to do something like 
`asyncio.to_thread(pathlib.Path(...).json)`

defined as:

```python
def json(self):
import json

with self.open("rb") as f:
return json.load(f)
```

while this may seem simple to implement in my own code it handles a lot of 
stuff for me!, Specifically PEP 538, minimal interactions with the asyncio 
waker pipe, the minimal amount of ram, etc etc.


You might ask - if json why not .html() and .xml() and .csv() ? Well each of 
these formats require specific configuration - eg do you want defused or 
regular exploding xml? Do you want excel style CSV or GNU style CSV? AFAIK json 
is the only format with a one shot zeroconf bytes -> structure format, and so 
makes it worthy of the pathlib shortcut.
___
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/7GYEHWUNPOJZLEWJ5CZCNUVJYEDLGDPM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Thomas Grainger]

>  if we find time to implement it for 3.11.

https://www.python.org/dev/peps/pep-0543/#configuration
was Withdrawn

would this need a new PEP?
___
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/VV7ZQVXICCUXOTBZ4LMWA7TAJSGEEF2V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Thomas Grainger]

Another problem with the assignment API is that the order the attributes
are assigned is important:

Eg check_hostname needs to be assigned before verify_mode or a warning is
raised:

https://github.com/encode/httpx/pull/1687/commits/ed9aabfeff6c18652db918bd0628c94d2513487a

On Mon, 28 Jun 2021, 19:45 Brendan Barnwell,  wrote:

> On 2021-06-28 07:03, Thomas Grainger wrote:
> >> >but in this case the object is security sensitive, and security should
> be much more rigorous in ensuring correctness.
> > It looks like there's a consensus being reached, should I create a bpo?
>
> If we're going to make backwards-incompatible changes to
> SSLContext,
> might it be a good idea to make a cleaner, more Pythonic API while we're
> at it so that people are discouraged from doing attribute-setting at
> all?  Why not have the class accept only valid options at creation time
> and raise an error if any unexpected arguments are passed?  Is there
> even any reason to allow changing the SSLContext parameters after
> creation, or could we just freeze them on instance creation and make
> people create a separate context if they want a different configuration?
>   I think any of these would be better than the current setup that
> expects people to adjust the options by manually setting attributes one
> by one after instance creation.
>
> --
> Brendan Barnwell
> "Do not follow where the path may lead.  Go, instead, where there is no
> path, and leave a trail."
> --author unknown
> ___
> 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/K5ZBPHYL4UUFY7T3VDXZJIEX6WQJCBXG/
> 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/UH5JCFGWUI4SSPNCO26XY37TMFLLF2EH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Thomas Grainger]

httpx.create_ssl_context() is one such utility function


python -m pip install httpx

python

>>> import httpx

>>> ctx = httpx.create_ssl_context()


Ironically the context returned doesn't support ctx.minimum_version
assignment due to another hangnail in the ssl.SSLContext API!


This is fixed in the default branch however
https://github.com/encode/httpx/pull/1714#event-4947041362



On Mon, 28 Jun 2021, 18:32 Jonathan Fine,  wrote:

> Thomas Grainger wrote:
>
> It looks like there's a consensus being reached, should I create a bpo?
>>
>
> Perhaps first state what seems to be the consensus and invite further
> comments before going to bpo.
>
> Disclaimer: I'd like to see both:
>
> 1. Something on PyPi to help persons who are using ssl on current Python.
> 2. Something in a future version of Python, that constrains attribute
> access.
>
> We can do (1) first, and it will help inform (2).
>
> --
> Jonathan
>
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/C5VDWQG26S6PAPTHF5H7ESC6JTMLKCJO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Thomas Grainger]

> but in this case the object is security sensitive, and security should be 
> much more rigorous in ensuring correctness.

It looks like there's a consensus being reached, should I create a bpo?
Thomas Grainger

On Sat, 26 Jun 2021 at 23:03, Ethan Furman  wrote:
>
> On 6/26/21 1:55 PM, Marc-Andre Lemburg wrote:
>  > On 26.06.2021 21:32, Ethan Furman wrote:
>
>  >> In most cases I would agree with you, but in this case the object is 
> security
>  >> sensitive, and security should be much more rigorous in ensuring 
> correctness.
>  >
>  > Isn't this more an issue of API design rather than Python's
>  > flexibility when it comes to defining attributes ?
>
> I think it's both, with the majority of the responsibility being on the API 
> design.
>
>  > IMO, a security relevant API should not use direct attribute
>  > access for adjusting important parameters. Those should always
>  > be done using functions or method calls which apply extra sanity
>  > checks and highlight issues in form of exceptions.
>
> Agreed -- but Python's nature makes it easy to use attribute access to make 
> adjustments, and that should also be
> constrained in security conscious objects.
>
> --
> ~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/W37274R4WDTRXG2Y2U4RPTFHWXBEGZFE/
> 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/MIGA25G5QCIQMI5JILEAEXNYNK54CFA5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Thomas Grainger]

I'd prefer a frozen dataclass with an explicit replace method

On Sat, 26 Jun 2021, 21:56 Marc-Andre Lemburg,  wrote:

> On 26.06.2021 21:32, Ethan Furman wrote:
> > On 6/25/21 5:20 PM, Eric V. Smith wrote:
> >
> >> It seems like many of the suggestions are SSLContext specific. I don't
> think
> > we should be adding
> >> __slots__ or otherwise redefining the interface to that object. Isn't
> this a
> > general "problem" in
> >> python...
> >
> > In most cases I would agree with you, but in this case the object is
> security
> > sensitive, and security should be much more rigorous in ensuring
> correctness.
>
> Isn't this more an issue of API design rather than Python's
> flexibility when it comes to defining attributes ?
>
> IMO, a security relevant API should not use direct attribute
> access for adjusting important parameters. Those should always
> be done using functions or method calls which apply extra sanity
> checks and highlight issues in form of exceptions.
>
> And those are possible in Python without calling type checking,
> linters or other extra tools to the rescue.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts (#1, Jun 26 2021)
> >>> Python Projects, Coaching and Support ...https://www.egenix.com/
> >>> Python Product Development ...https://consulting.egenix.com/
> 
>
> ::: We implement business ideas - efficiently in both time and costs :::
>
>eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>Registered at Amtsgericht Duesseldorf: HRB 46611
>https://www.egenix.com/company/contact/
>  https://www.malemburg.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/53V2RCIDJRE2SVVB7C4FZADIY2LSRMWT/
> 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/7L5GXWJEEQJKKDUJCZUR3KFTV25CY7FU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: concurrent.futures.ProcessPoolExecutor(restart_workers=True)

[Thomas Grainger]

And it's on Python stdlib 3
https://docs.python.org/3/library/multiprocessing.html#multiprocessing.pool.Pool

On Sat, 26 Jun 2021, 17:24 Thomas Grainger,  wrote:

> billiard a multiprocessing py2 fork/backport has
> https://billiard.readthedocs.io/en/latest/library/multiprocessing.html#multiprocessing.pool.multiprocessing.Pool
> with maxtasksperchild
>
> On Sat, 26 Jun 2021, 16:57 Ram Rachum,  wrote:
>
>> Hi guys,
>>
>> I want to have a version of `concurrent.futures.ProcessPoolExecutor` in
>> which every worker process shuts down after each task. I want this because
>> I believe I have a memory leak in my program that I wasn't able to fix.
>> (Possibly it's in C extensions that I use.)
>>
>> Since I'm going to use a process pool anyway, I'm hoping to sidestep this
>> memory leak by launching every task on a worker process that shuts down
>> after it's done.
>>
>> A few years back when I was working at Dell, they did something similar.
>> They had a Python server that had a memory leak, and they worked around it
>> by having a process that can be easily restarted, and then they restarted
>> it often.
>>
>> The plan is that each new work item will run on a fresh process that has
>> no memory leaks from previous work items.
>>
>> I looked at the `futures/process.py` file to see whether I could subclass
>> `ProcessPoolExecutor` and add this functionality, and boy oh boy this is
>> not easy.
>>
>> Do you think it's worthwhile to add this feature to `ProcessPoolExecutor`?
>>
>>
>> Thanks,
>> Ram.
>> ___
>> 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/UNDY7YKBJ4DOB6H45N7T6QK7PVJBIKZV/
>> 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/4UT4F7KHLGS2YV2UQAZZKCCOONP6VNGQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: concurrent.futures.ProcessPoolExecutor(restart_workers=True)

[Thomas Grainger]

billiard a multiprocessing py2 fork/backport has
https://billiard.readthedocs.io/en/latest/library/multiprocessing.html#multiprocessing.pool.multiprocessing.Pool
with maxtasksperchild

On Sat, 26 Jun 2021, 16:57 Ram Rachum,  wrote:

> Hi guys,
>
> I want to have a version of `concurrent.futures.ProcessPoolExecutor` in
> which every worker process shuts down after each task. I want this because
> I believe I have a memory leak in my program that I wasn't able to fix.
> (Possibly it's in C extensions that I use.)
>
> Since I'm going to use a process pool anyway, I'm hoping to sidestep this
> memory leak by launching every task on a worker process that shuts down
> after it's done.
>
> A few years back when I was working at Dell, they did something similar.
> They had a Python server that had a memory leak, and they worked around it
> by having a process that can be easily restarted, and then they restarted
> it often.
>
> The plan is that each new work item will run on a fresh process that has
> no memory leaks from previous work items.
>
> I looked at the `futures/process.py` file to see whether I could subclass
> `ProcessPoolExecutor` and add this functionality, and boy oh boy this is
> not easy.
>
> Do you think it's worthwhile to add this feature to `ProcessPoolExecutor`?
>
>
> Thanks,
> Ram.
> ___
> 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/UNDY7YKBJ4DOB6H45N7T6QK7PVJBIKZV/
> 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/VBMR73IJ52C7HCQ4HJJV7TVB4BEPCLAQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Thomas Grainger]

How about an alternative frozen dataclass with a explicit replace,
configure and create methods?

@dataclasses.dataclass(frozen=True)
class SSLContextFactory:
minimum_version: TLSVersion = TLSVersion.TLSv1_2
options: ...

replace = dataclasses.replace

def configure(self, ctx: SSLContext):
ctx.mimumum_version = self.minimum_version
ctx.options = self.options
...

def create(self):
ctx = SSLContext()
self.configure(ctx)
return ctx

On Fri, 25 Jun 2021, 20:52 Guido van Rossum,  wrote:

> On Fri, Jun 25, 2021 at 12:17 PM Christian Heimes 
> wrote:
>
>> On 25/06/2021 20.17, Guido van Rossum wrote:
>> > On Fri, Jun 25, 2021 at 8:22 AM Bluenix > > > wrote:
>> >
>> > I am not fully aware of how ssl.SSLContext is used, but adding
>> > __slots__ would prevent this. You would see an error similar to:
>> > AttributeError: 'MyClass' object has no attribute 'my_attribute'
>> >
>> >
>> > That's a reasonable solution, except that it's not backwards compatible.
>> > It's possible that there is code out there that for some reason adds
>> > private attributes to an SSLContext instance, and using __slots__ would
>> > break such usage. (They could perhaps fix their code by using a dummy
>> > subclass, but that could well become a non-trivial change to their code,
>> > depending on where they get their SSLContext instances.)
>> >
>> > So unless there's evidence that nobody does that, we're stuck with the
>> > status quo. I'm adding Christian Heimes to the thread in case he has a
>> > hunch either way.
>>
>> I agree, it is a backwards incompatible change. Also __slots__ won't
>> work. The class has class attributes that can be modified in instances.
>>
>
> Oh, I see. There are two class attributes, sslsocket_class and
> sslobject_class, and their docs say they can be overridden per instance.
> Could we perhaps create a custom descriptor that allows both per-instance
> and per-class assignment and lookup?
>
>
>> You cannot have attributes that are both class and instance attributes
>> with __slots__. We'd have to overwrite __setattr__() and block unknown
>> attributes of exact instances of ssl.SSLContext.
>>
>
> Well, if we don't think it's supported behavior to subclass SSLContext,
> perhaps we could do that. The bug in the OP's code (misspelling
> minimum_version in assignment) is pretty hard to find.
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/VGSFW6UXY7NRHZ6OUWJMXABFVVFMHIQN/
> 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/OFABWJUMIUFXQAYFULBNDMIAYGVWOWLH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] disallow assignment to unknown ssl.SSLContext attributes

[Thomas Grainger]

I was debugging some code that was using TLSv1.2 when I expected it to only 
support TLSv1.3, I tracked it down to a call to:

context.miunimum_version = ssl.TLSVersion.TLSv1_3

it should have been:

context.minimum_version = ssl.TLSVersion.TLSv1_3

I'd like invalid attribute assignment to be prevented at runtime
___
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/RPD5OICSY3KLVXKIYWFTABNIA7F7YWG3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extension methods in Python

[Thomas Grainger]

It seems odd that it would be per module and not per scope?

On Tue, 22 Jun 2021, 00:55 Soni L.,  wrote:

>
>
> On 2021-06-21 8:42 p.m., Steven D'Aprano wrote:
> > On Mon, Jun 21, 2021 at 02:54:52PM -0300, Soni L. wrote:
> >
> > > Quite the opposite. You ask the local module (the one that the code was
> > > compiled in), and the module decides whether/when to ask the object
> itself.
> > >
> > > In other words, every
> > >
> > > foo.bar
> > >
> > > would be sugar for
> > >
> > > __getattr__(foo, "bar")
> > >
> > > (where __getattr__ defaults to builtins.getattr) instead of being
> sugar for
> > >
> > > (foo, "bar")
> >
> > All you've done here is push the problem further along -- how does
> > `__getattr__` (`__getattribute__`?) decide what to do?
> >
> > * Why is this extension-aware version per module, instead of a builtin?
> >
> > * Does that mean the caller has to write it in every module they want to
> >   make use of extensions?
> >
> > * Why do we need a second attribute lookup mechanism instead of having
> >   the existing mechanism do the work?
> >
> > * And most problematic, if we have an extension method on a type, the
> >   builtin getattr ought to pick it up.
> >
> >
> > By the way, per-module `__getattr__` already has a meaning, so this name
> > won't fly.
> >
> > https://www.python.org/dev/peps/pep-0562/
> >
> >
>
> No, you got it wrong. Extension methods don't go *on* the type being
> extended. Indeed, that's how they differ from monkeypatching.
>
> The whole point of extension methods *is* to be per-module. You could
> shove it in the existing attribute lookup mechanism (aka the
> builtins.getattr) but that involves runtime reflection, whereas making a
> new, per-module attribute lookup mechanism specifically designed to
> support a per-module feature would be a lot better.
>
> Extension methods *do not go on the type*.
>
> And sure, let's call it __opcode_load_attr_impl__ instead. Sounds good?
> ___
> 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/MTOP22VK2ZC3GWCQHU5RDFVIT5AAR4DW/
> 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/OQOJ3LZLCYKCYJW2ZTHQ2OQULKDFPWVC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Cleaner tracebacks from Python code

[Thomas Grainger]

https://github.com/agronholm/anyio/blob/9eb4671547b01f5e3ba0e0ca602b6aceec15af86/src/anyio/_backends/_asyncio.py#L598

On Sat, 29 May 2021, 20:24 André Roberge,  wrote:

>
>
> On Sat, May 29, 2021 at 3:25 PM Thomas Grainger  wrote:
>
>> pytest  uses __tracebackhide__
>>
>> https://doc.pytest.org/en/latest/example/simple.html#writing-well-integrated-assertion-helpers
>>
>
> Thanks for the reminder.  Pytest takes care of traceback formatting for
> users.  Individual projects can of course do that. But I want to do the
> reverse: I want to limit what users of my projects will see in a traceback,
> without having them specify something in their code.
>
> What I am interested in is having a project-agnostic standardised Python
> way to specify what to show to an end-user when an exception is raised.
>
>>
>> Eg anyio sets __tracebackhide__ = __traceback_hide__ = True to remove
>> internal frames from user Tracebacks
>>
>
> Do you have a specific link to this?  I have looked in the documentation
> as well as in a few modules (_core/_exceptions.py in particular) without
> seeing any reference to this. I am not interested in custom formatting for
> testing, which is something comparatively easy to do.
>
___
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/4UK5HO5X3RLWGCSZYPDASZBVVQT5RRHE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Cleaner tracebacks from Python code

[Thomas Grainger]

pytest  uses __tracebackhide__

https://doc.pytest.org/en/latest/example/simple.html#writing-well-integrated-assertion-helpers

Eg anyio sets __tracebackhide__ = __traceback_hide__ = True to remove
internal frames from user Tracebacks

On Sat, 29 May 2021, 19:21 André Roberge,  wrote:

> With CPython, tracebacks obtained from code written in C can be extremely
> clean compared with functionally equivalent code written in Python.
> Consider the following test file where I am using a local copy of Python's
> datetime.py module.
>
> ```py
> from local_datetime import date
> d = date(2021, 13, 1)
> ```
>
> Executing this code results in the following, very "clean" traceback:
> ```pytb
> Traceback (most recent call last):
>   File "test.py", line 2, in 
> d = date(2021, 13, 1)
> ValueError: month must be in 1..12
> ```
>
> A single line of code is shown, which is the one written by the end-user
> of this library; all code details from inside the library module are hidden.
>
> As it turns out, the datetime module imports (if it is available) the
> _datetime module written in C. If we comment out this import, so that the
> pure Python code is used instead,
> here is the new traceback:
>
> ```pytb
> Traceback (most recent call last):
>   File "test.py", line 2, in 
> d = date(2021, 13, 1)
>   File "C:\Users\andre\local_datetime.py", line 847, in __new__
> year, month, day = _check_date_fields(year, month, day)
>   File "C:\Users\andre\local_datetime.py", line 422, in _check_date_fields
> raise ValueError('month must be in 1..12', month)
> ValueError: ('month must be in 1..12', 13)
> ```
>
> In addition to the call by the end-user of that library, we see some inner
> code of that library that has no practical value to the end-user.
>
> We can suppress some lines of the traceback by replacing the line
>
> ```py
> year, month, day = _check_date_fields(year, month, day)
> ```
> by
> ```py
> try:
> year, month, day = _check_date_fields(year, month, day)
> except Exception:
> _, _, tb = sys.exc_info()
> tb.tb_next = None
> raise
> ```
>
> which simplifies the traceback somewhat:
> ```pytb
> Traceback (most recent call last):
>   File "test.py", line 2, in 
> d = date(2021, 13, 1)
>   File "C:\Users\andre\local_datetime.py", line 848, in __new__
> year, month, day = _check_date_fields(year, month, day)
> ValueError: ('month must be in 1..12', 13)
> ```
> but there is still one line of code from inside the library.
> ===
> Idea: it would be nice if one could somehow define **callables** with a
> custom attribute that
> would indicate that tracebacks should not include frames "below" it.
> More explicitly, using the notation of the above example, imagine that we
> could write
>
> ```py
> date.__hide_tb__ = True
> ```
> and that any call to `date()` that generate a traceback would not show
> frames below the
> calling frame, thus reproducing what we see when using the C code in this
> example.
> For library writers, this would be easily reverted when attempting to
> debug.
> For end users, this would result in much more readable tracebacks,
> unencumbered by extra lines of code that are outside of their control.
>
> 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/WQN7QJUVV62IO3J7ALOJYHS6URYVRDFD/
> 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/MQIGFKW762O2BKXCA5HW7WVSQOI5DPHV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce constant variables in Python

[Thomas Grainger]

This is already available with typing.Final and immutable types:

from typing import Final

ham: Final = 3
ham = 4 # Error

hams: Final[Sequence[str]] = ["ham", "spam"]
hams.append("meat") # Error


On Mon, 24 May 2021, 18:40 Abdur-Rahmaan Janhangeer, 
wrote:

> Greetings,
>
> Just a light-hearted note, if ever the idea is taken seriously,
>
> variable: constant = 10
>
> seems more pythonic to me.
>
> constant variable = 10 opens the doors for
>
> int x = 5 etc
>
> 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/S2CTGF562UST4DM22HO7SLZ3EEWG544G/
> 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/7FK56ZRCC3XP3CIN7DEF3OD3ELUFYGIY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dict.get_deep()

[Thomas Grainger]

seems a bit like https://www.python.org/dev/peps/pep-0505/

eg `d?[1]?[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/ZKYLSYU7U673RX6XQLYBSC2HGEAO5NES/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New Idea: A safe keyword to execute the following statement in a failsafe mode.

[Thomas Grainger]

sounds very much like https://www.python.org/dev/peps/pep-0463/#rejection-notice

I'm concerned with the `safe` defaulting to a bare `except:` which will also 
catch CancelledError other errors that should be re-raised

also 
```
   file = safe open('some_file')
```

does not provide a way to manage the file with a context manager: 

```
f = safe open("some_file")
if f is None:
# do something
else:
with f:
# do something else
```

seems no improvement  than the current:

```
try:
f = open("some_file")
except OSError:
# do something
else:
with f:
# do something else
```
___
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/7MN4G5INW2CZXVMC7KHHUMXIZ3ZZNDBZ/
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:`

[Thomas Grainger]

how about:

```
try:
...
except E1 | E2 | E3 as e:
...
```

it's syntactically valid but is this again: https://bugs.python.org/issue12029
___
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/MKUMC6CCGLRY6IJJF2WD6CSMQUZN5Z2Q/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Thomas Grainger]

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] Re: Revive: PEP 396 -- Module Version Numbers ?

[Thomas Grainger]

> As another data point, flit *requires* that the package has a
> __version__ attribute.

flit no longer requires packages support `__version__` when using PEP 621 
metadata
___
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/6U35SIJKGSYVPAXDGDPMT2G5RGKY7H2Z/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Revive: PEP 396 -- Module Version Numbers ?

[Thomas Grainger]

I prefer to use importlib.metadata.version("dist-name")

On Mon, 12 Apr 2021, 19:51 Christopher Barker,  wrote:

> Over the years, I've seen __version__ used very broadly but not *quite* in
> all packages. I've always known it was a convention, not a requirement. But
> it turns out it's not even a "official" convention.
>
> But it really would be nice if there was a consistent way that I could
> count on to get the version of a package at run time.
>
> Turns out this was suggested in PEP 396 -- and deferred almost 13 years
> ago!
>
> https://www.python.org/dev/peps/pep-0396/
>
> In the status note, it says:
>
> """
> Further exploration of the concepts covered in this PEP has been deferred
> for lack of a current champion interested in promoting the goals of the PEP
> and collecting and incorporating feedback, and with sufficient available
> time to do so effectively.
> """
>
> Well, I may be willing to be that champion, if a core dev is willing to
> sponsor, and I see some interest from this group.
>
> And, well, after 13 years, we've seen __version__ be very broadly, though
> certainly not universally used.
>
> Honestly, I haven't looked to see to what extent setuptools supports it,
> but will, of course, do so if folks think this is worth pursuing.
>
> Or maybe this is a settled issue in setuptools, and we just need to change
> the status of the PEP.
>
> For my part, I FAR prefer the version info to be embedded in the code of
> the package in a simple way, rather than hiding among the
> setuptools/egg/pip metadata, and requiring setuptools.pkg_resources to get
> a version at runtime.
>
> I note that PEP8 uses __version__ as an example of a "module level dunder"
> -- but only suggests where it should be put, not how it be used :-)
>
> Of course, there will be a need to update the PEP to match current
> practice (and setuptools and pip)
>
> Or should this be brought up on The Distutils-SIG list?
>
> -CHB
>
> ,--
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/VP4JWZTXYXGUFI76UR6AIKTSCUK3ZM53/
> 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/3XJBGT3QNGDBVS5LUS4B5FLLXZECBCVC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Basic toolkit for async iterators

[Thomas Grainger]

map and filter are already available as comprehension syntax

However zip and merge are tricky because you'd need to schedule all 
`__anext__()` coroutines from all input AsyncIterables. The stdlib would need 
to know how to spawn tasks in such a way they could be understood by the 
framework that spawned the currently executing coroutine
___
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/ULJQDWGXQQ2W5DB24DHM2EPX5AVZRG5O/
Code of Conduct: http://python.org/psf/codeofconduct/