[Python-Dev] Re: 3.11 enhanced error location - can it be smarter?

2022-01-20 Thread Barry Scott 


> On 20 Jan 2022, at 02:22, Skip Montanaro  wrote:
> 
> (This really belongs on python-ideas, right?)
> 

I'm commenting on the implementation that is on going. python-ideas does not 
seem right.

Barry

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/VGKLTI5QBBILCHWEMMTIUOB2X5QPMNOS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: RFC on PEP 673: Self Type

2022-01-20 Thread Petr Viktorin 

On 19. 01. 22 21:40, S Pradeep Kumar wrote:



On Mon, Jan 17, 2022 at 7:02 AM Jelle Zijlstra > wrote:




El lun, 17 ene 2022 a las 6:25, Petr Viktorin (mailto:[email protected]>>) escribió:

On Wed, Nov 17, 2021 at 8:31 AM Pradeep Kumar Srinivasan
mailto:[email protected]>> wrote:
 >
 > This PEP [1] introduces a simple and intuitive way to
annotate methods and classmethods that return an instance of
their class. Such methods and classmethods occur quite
frequently, but the existing way to annotate them correctly is
quite arcane and error-prone. The PEP introduces a special type
`Self` to represent the type of the `self` parameter, similar to
the `this` type in TypeScript and the `Self` type in Rust. We
have implementations for mypy and pyright. The PEP does not
affect CPython directly except for the addition of one special
form (Self) to typing.py [2].
 >
 > Since we have reached consensus on the PEP in typing-sig [3],
we wanted to get your comments and suggestions before submitting
to the Steering Council.
 >
 > Thanks,
 > Pradeep Kumar Srinivasan
 > James Hilton-Balfe
 >
 > [1]: https://www.python.org/dev/peps/pep-0673/

 > [2]: Adding `Self` to typing_extensions.py:
https://github.com/python/typing/pull/933

 > [3]: See the comments from typing-sig members on the Google
doc:

https://docs.google.com/document/d/1ujuSMXDmSIOJpiZyV7mvBEC8P-y55AgSzXcvhrZciuI/edit?usp=sharing



Hello, and thanks for the PEP!
Sorry I'm late, but I have two curious questions about the PEP.
I don't think they should hold back accepting the PEP, but I'm
interested in the answers.

The PEP uses `reveal_type`, a function that's appeared in a few PEPs
already, but was never described. Is it a standard function in
typing
tools, something specific to mypy, or pseudocode?


It's a function that doesn't exist at runtime, but when a type
checker sees a call, it emits the inferred type of the argument. It
originated with mypy but I believe has been adopted by all type
checkers.

There's been some talk of adding it to the `typing` module, but that
hasn't happened so far. I opened https://bugs.python.org/issue46414
 to suggest adding it.


Yes, it is a pseudo function that has been adopted afaik by all type 
checkers, e.g., Mypy, Pyre, Pyright. It's useful for debugging type 
errors by using `reveal_type()` and running the type checker. I 
honestly didn't even realize that it wasn't specified in PEP 484 until 
you asked.


Do you suggest adding an explanation in the PEP or is it reasonably 
self-explanatory? I see a few other PEPs using it.


It's reasonably self-explanatory, but it would be nice to document it in 
some central place.
Adding it to typing (https://bugs.python.org/issue46431#msg410942) looks 
promising, if typing-sig can agree on it.





The PEP says "we reject Self in metaclasses."
"Metaclass" can mean "subclass of `type`", or it can refer to how a
value is used -- for example, you can write `class
Foo(metaclass=print): ...`.
In the PEP's example, is MyMetaclass rejected because:
- it's used as a metaclass in a class statement, or
- it's a subclass of `type` (so it's rejected even if unused), or
- it becomes a class of a class?
Or is the exact interpretation best left to the type checker?


The PEP rejects `Self` used in `MyMetaclass` because the class is a 
subclass of `type`. So, there would be a type error even if 
`MyMetaclass` were unused.


In general, the `# Rejected` comment indicates the position at which the 
type checker would emit a type error, as per the convention in other 
typing PEPs. So, in the PEP's metaclass example, we suggest that type 
errors be emitted at the uses of `Self` in the return annotations of 
`__new__` and `__mul__`. (The exact error and position is left up to the 
type checker.)


Thanks for the questions!


That's what I thought. Thanks!
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/A4M2PWILVKPXXMG6WSIUJBSO3OLFTDJM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Discussion about crash tolerance feature for gdbm module

2022-01-20 Thread Dong-hee Na 
I exchanged a mail for investigating details.

Before getting started, please remind the following fact.
- The latest snapshot is always valid, even if corruption has not occurred.

> Why is a separated script needed? / A single script cannot automatically
detect a corrupted database and load the latest snapshot?

So, the author said a separate script is never needed,
if the user reads from the latest snapshot file, it will always be
recovered.
so the user code will be like this.

import dbm.gnu as dbm

# skip check code that all files are exists, origin, even_snapshot, odd_snapshot


if origin is None:

db = dbm.open(origin, 'nx') # For extension format

db.gdbm_failure_atomic(even_snapshot, odd_snapshot) # For snapshot
declaration

else:

latest_snapshot = dbm.gdbm_latest_snapshot(even_snapshot odd_snapshot)

  db = dbm.open(latest_snapshot, 'r') # Open the latest valid snapshot

for k, v in zip('abcdef', 'ghijkl'):
db[k] = v

db.sync()
db.close()


> How is different from simply copying the whole database file?


Under the hood, the gdbm crash-tolerance mechanism *does* (logically) copy
the whole database file, but it does so efficiently, using "reflink"
copies, so the amount of physical storage resources used is minimal.

You may good to read this paper:
https://dl.acm.org/doi/pdf/10.1145/3487019.3487353


Warm Regards,

Dong-hee


2022년 1월 18일 (화) 오후 10:54, Victor Stinner 님이 작성:

> How does someone know if a database is corrupted? Why is a separated
> script needed?
>
> A single script cannot automatically detect a corrupted database and
> load the latest snapshot?
>
> How is different from simply copying the whole database file?
>
> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/JB5JKWEYQI5A44W4J5JTECZ73YAIF3Y3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Discussion about crash tolerance feature for gdbm module

2022-01-20 Thread Dong-hee Na 
For more readable code:
https://gist.github.com/corona10/d4fe0b6367ea6865e37b4369a7d60912

2022년 1월 21일 (금) 오후 12:50, Dong-hee Na 님이 작성:

> I exchanged a mail for investigating details.
>
> Before getting started, please remind the following fact.
> - The latest snapshot is always valid, even if corruption has not occurred.
>
> > Why is a separated script needed? / A single script cannot automatically
> detect a corrupted database and load the latest snapshot?
>
> So, the author said a separate script is never needed,
> if the user reads from the latest snapshot file, it will always be
> recovered.
> so the user code will be like this.
>
> import dbm.gnu as dbm
>
> # skip check code that all files are exists, origin, even_snapshot, 
> odd_snapshot
>
>
> if origin is None:
>
> db = dbm.open(origin, 'nx') # For extension format
>
> db.gdbm_failure_atomic(even_snapshot, odd_snapshot) # For snapshot 
> declaration
>
> else:
>
> latest_snapshot = dbm.gdbm_latest_snapshot(even_snapshot odd_snapshot)
>
>   db = dbm.open(latest_snapshot, 'r') # Open the latest valid snapshot
>
> for k, v in zip('abcdef', 'ghijkl'):
> db[k] = v
>
> db.sync()
> db.close()
>
>
> > How is different from simply copying the whole database file?
>
>
> Under the hood, the gdbm crash-tolerance mechanism *does* (logically) copy
> the whole database file, but it does so efficiently, using "reflink"
> copies, so the amount of physical storage resources used is minimal.
>
> You may good to read this paper: 
> https://dl.acm.org/doi/pdf/10.1145/3487019.3487353
>
>
> Warm Regards,
>
> Dong-hee
>
>
> 2022년 1월 18일 (화) 오후 10:54, Victor Stinner 님이 작성:
>
>> How does someone know if a database is corrupted? Why is a separated
>> script needed?
>>
>> A single script cannot automatically detect a corrupted database and
>> load the latest snapshot?
>>
>> How is different from simply copying the whole database file?
>>
>> Victor
>> --
>> Night gathers, and now my watch begins. It shall not end until my death.
>>
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/SQVHJIMKH4GDACFWUVSY35ZVVKND6R2S/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Adding an `inspect` function to return the signature of a type?

2022-01-20 Thread Steven Troxler 
I've been wondering whether it would make sense to have a function in `inspect` 
that returns the signature of a type, rather than the signature of a specific 
callable object.

I'm not attached to any name for such a function, two ideas are 
`inspect.signature_of` or `inspect.signature_of_type`.

## Context: the behavior of `inspect.signature`

The existing `inspect.signature` function specified in PEP 362 [0] returns the 
call signature of a particular object, in other words given
```
class Dog:
def __init__(self, color: str):
self.color = color
def __call__(self, command: str):
print(command)
```
we will get
```
>>> import inspect
>>> inspect.signature(Dog)

>>> inspect.signature(Dog("brown"))

```

## Outline of the idea

In some cases it might be nice to be able to access the signature of an 
instance of `Dog` given the type `Dog`, without actually needing to instantiate 
it. 

Moreover, there are some cases where it isn't even possible to get a callable 
object, but it still might be nice to have access to an `inspect.Signature` 
object:
- protocols cannot be instantiated. This is particularly relevant to getting 
Signatures because of callback protocols [1] 
- typing.Callable types describe a signature, but again can't be instantiated

If if we had a function to operate on types, it would treat normal classes as 
if calling `inspect.signature` on the `__call__` method of an instance.

For callable types we'd want to do something similar, although this brings up 
some issues: 
- the existing Signature requires parameter names, but a `typing.Callable` 
doesn't have any.
  - One option would be to invent names `__0`, `__1,` etc. Otherwise we'd have 
to make the name optional.
- it's not obvious how to support PEP 612 ParamSpecs, and even less obvious how 
to support PEP 646 in full generality

I have some code snippets running through how simple cases might work, as well 
as the edge cases I've thought of thus far:
https://gist.github.com/stroxler/4760cbc5e49df2295cd0b524328b1c73

I'm undecided about whether the edge cases are an indication that this idea 
isn't worth considering.
It's worth noting that most of the edge cases involve PEP 612 / 646 generics 
which are pretty rare.

## Why did I start thinking about this?

In discussions of PEP 677 [2], a few folks suggested using `inspect.Signature` 
as inspiration for the runtime API (which we did).

This got me thinking that it might be nice for code that uses runtime types, 
regardless of what we decide about PEP 677, to have an API that makes accessing 
signature information from a type easier.

I don't personally have much need for this, but
- when I chatted with Carl Meyer from the static python team at Meta he thought 
it could be handy
- I could imagine it being useful for tools like ML frameworks, which I've 
worked on in the past, that interpret type annotations to auto-generate logic

--

[0] PEP 362 Function Signatures https://www.python.org/dev/peps/pep-0362/
[1] Callback protocols 
https://mypy.readthedocs.io/en/stable/protocols.html#callback-protocols
[2] PEP 677 Callable Type Syntax  https://www.python.org/dev/peps/pep-0677/
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/47NLKQZYYQL6LKA7BQWGFT4UZJOIAR4M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: How about using modern C++ in development of CPython ?

2022-01-20 Thread Dan Stromberg 
On Fri, Apr 16, 2021 at 11:13 AM Christian Heimes 
wrote:

> On 16/04/2021 19.14, [email protected] wrote:
> > My personal stop of contributing in CPython is that it is written in
> pure C !!
> > I wrote code in both: pure C and C++, but I like writing code in C++,
> because it simplifies things without losing perfomance
>
> There are plenty of Open Source projects that could use more capable C++
> developers. :)
>
> I'm not a fan of C++. It has its use cases, e.g. in UI. Python core
> isn't the best fit. AFAIK most core devs are not fluent in C++. Despite
> it's name, C++ is really a different language than C. It has a different
> ABI and stdlib than C, too. In my personal opinion C++ won't give us any
> net benefits. I'd much rather go for Rust than C++ to gain memory safety.
>
Agreed.

Rust would be much better than C++.  Rust actually brings something new and
interesting to the discussion.  C++ is "almost Java", but not as good.  The
Linux kernel tried C++, but backed away from it. But now it's adding Rust.

I've had the experience, in the past, of writing code in C++ only to find
that its intended users refused to use it /because/ it was in C++.  In
retrospect, I'm not entirely disappointed that they did - it steered me
toward sticking with bash and C, and getting more into Python.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/QJA7LHDJZSHYAPI6H6CQXD6GZ5HYIZF6/
Code of Conduct: http://python.org/psf/codeofconduct/