from:"Eric V. Smith"

[Python-Dev] Re: Retiring this mailing list ?

2023-11-14 Thread Eric V. Smith via Python-Dev


On 11/14/2023 1:21 PM, Steve Holden wrote:

On Mon, 13 Nov 2023 at 10:18, Marc-Andre Lemburg  wrote:

[...]

Question: Should we retire and archive this mailing list ?
(I'm asking as one of the maintainers of the ML)

[...]

Hi Marc-Andre,

Maybe just require senders to be members of the python.org 
 domain, and retain the release announcements?


I think the python-announce list serves that purpose. Any time there's 
an announcement here, I also see a separate copy of it on 
python-announce (where I'm a moderator).


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

[Python-Dev] Re: Annotating pure functions to improve inline caching/optimization

2022-09-14 Thread Eric V. Smith via Python-Dev

You should bring this up on discuss.python.org. It's not going to see 
much if any discussion here.


Eric

On 9/14/2022 10:05 AM, Philipp Burch wrote:

Hello everyone,

the docs on the upcoming 3.11 release state

> This [specializing adaptive interpreter] also brings in another 
concept called inline caching, where Python caches the results of 
expensive operations directly in the bytecode.


I wonder how this caching works, given that the dynamic nature means 
that virtually every operation could have side effects, causing wrong 
behaviour when cached. The only mitigation for this that I can imagine 
is that caching just occurs for basic operations defined in the 
standard library, where it is known that they are free of side effects 
or "pure".


A web search did reveal some discussions[1,2] and a module related to 
dealing with pure functions, but, as far as I see, not related to 
optimization.


As an example, consider a code like this:

```py
@pure
def rot_factor(angle_deg: float) -> complex:
    # This could also be a much more expensive calculation.
    return cmath.exp(angle_deg / 180 * cmath.pi * 1j)

# ...

res: List[Tuple(complex, complex, complex, float)] = []
for x in many:
    res.append((
    x * rot_factor(90),
    x * rot_factor(45),
    x * rot_factor(-45),
    x * math.sin(math.pi/8),
    ))
```

The problem with this code is obvious, every loop iteration calls 
`rot_factor()` with 90, 45 and -45 and will get exactly the same set 
of results. The last factor might already be inline cached by the 
interpreter, since it probably knows that `math.pi` is a constant and 
`math.sin()` is a pure function. Optimizing this by hand (not 
considering a list comprehension or other more sophisticated 
improvements) is easy, but not very pretty:


```py
f_p90 = rot_factor(90)
f_p45 = rot_factor(45)
f_m45 = rot_factor(-45)
f_sin = math.sin(math.pi / 8)
res: List[Tuple(complex, complex, complex, float)] = []
for x in many:
    res.append((
    x * f_p90,
    x * f_p45,
    x * f_m45,
    x * f_sin,
    ))
```

I actually find myself often factoring such data out of loops in 
Python, whereas in C I would just leave that to the optimizer/compiler.


An available option would be to use `@lru_cache` for `rot_factor()`, 
but this will still cause the same dictionary lookups in every 
iteration and it may not work at all in case the function argument(s) 
is/are not hashable.


Now, if the interpreter understood the `@pure` decorator for 
`rot_factor()` indicated above would give it the same opportunity to 
cache the three results throughout the loop, basically creating the 
manually-optimized code above. For these completely static values, it 
could even precompute the results and integrate them into the bytecode.



Has anything like this been considered already, or is the interpreter 
itself capable to perform such optimizations?



Thanks and best regards,
Philipp



[1] 'pure' type annotation for mypy: 
https://github.com/python/mypy/issues/4468


[2] pure-func module: https://pypi.org/project/pure-func/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XDYZRC6L7LBPE3T6RO6S5IVY3J6IMRSJ/

Code of Conduct: http://python.org/psf/codeofconduct/

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

[Python-Dev] Re: Is it possible to view tokenizer output?

2022-05-29 Thread Eric V. Smith


python -m tokenize < file-to-parse.py

See the comment at the top of tokenize.py. IIRC, it re-implements the 
tokenizer, it does not call the one used for python code.


Eric

On 5/29/2022 6:59 PM, Jack wrote:
Hi, I'm just getting into the CPython codebase just for fun, and I've 
just started messing around with the tokenizer and the grammar. I was 
wondering, is there a way to just print out the results of the 
tokenizer (as in just the stream of tokens it generates) in a human 
readable format? It would be really helpful for debugging. Hope the 
question's not too basic.


Cheers.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2ZTZBAN5H2ET2IB7EXTKD27R5T6QVHZB/

Code of Conduct: http://python.org/psf/codeofconduct/

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

[Python-Dev] Re: Raw strings ending with a backslash

2022-05-28 Thread Eric V. Smith

On 5/28/2022 7:57 AM, Damian Shaw wrote:

That PR seems to make \' and \" not special in general right?

I think this is a more limited proposal, to only change the behavior 
when \ is at the end of a string, so the only behavior difference 
would never receiving the error "SyntaxError: EOL while scanning 
string literal"

How would you know where the end of a string is? I think this is one of 
those things that's easy to look at for a human and figure out the 
intent, but not so easy for the lexer, without some heuristics and 
backtracking. If the trailing single quote is removed below, it changes 
from "backslash in the middle of a string" to "backslash at the end of a 
string, followed by an arbitrary expression.

r'\' + "foo"'

Eric

In which case there should be no backwards compatibility issue.

Damian

On Sat, May 28, 2022 at 12:20 PM Serhiy Storchaka 
 wrote:

28.05.22 12:22, Steven D'Aprano пише:
> Now that we have a new parser for CPython, can we fix the old gotcha
> that raw strings cannot end in a backslash?
>
> Its an FAQ and has come up again on the bug tracker.
>
> https://docs.python.org/3/faq/design.html#id26
>
> https://github.com/python/cpython/issues/93314

I do not think that we can allow this, and it is not related to
parser.

Few years ago I experimented with such change:
https://github.com/python/cpython/pull/15217

You can see that it breaks even some stdlib code, and it will
definitely
break many third-party packages and examples. Technically we can do
this, but the benefit is small in comparison with the cost.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at

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

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

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

2022-04-26 Thread Eric V. Smith



> On Apr 26, 2022, at 3:05 PM, Thomas Kehrenberg  wrote:
> 
> 
> Apr 26, 2022 20:32:55 Eric V. Smith :
> 
>> How would runtime consumers of annotations use this?
>> 
>> --
>> Eric
>> 
>>>> On Apr 26, 2022, at 12:05 PM, Thomas Kehrenberg  wrote:
>>> 
>>> If the problem is mostly type annotations, then another potential
>>> solution would be to make use of .pyi files, which are not hamstrung by
>>> circular definitions.  The idea would be that type checkers would merge
>>> the annotations from .pyi files into the annotations in the
>>> corresponding .py file.
>>> 
>>> So:
>>> 
>>> a.py:
>>> 
>>>from b import B
>>> 
>>>class A:
>>>value: B
>>> 
>>> b.py:
>>> 
>>>class B:
>>>value = None
>>> 
>>> b.pyi:
>>> 
>>>from typing import Optional
>>>from a import A
>>> 
>>>class B:
>>>value: Optional[A] = ...
>>> 
>>> The pyi files would kind of act like header files that are used in other
>>> languages.  It would mean that type checkers need to check the .pyi
>>> files against the code in the .py files to verify that they're
>>> consistent with one another.
>>> 
>>> -thomas
>>> ___
>>> Python-Dev mailing list -- python-dev@python.org
>>> To unsubscribe send an email to python-dev-le...@python.org
>>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>>> Message archived at 
>>> https://mail.python.org/archives/list/python-dev@python.org/message/VWPWN5KWTRPP6VS4PEHJA4SRVMUDU5WR/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
> They wouldn't. But I thought PEP 649 solves the runtime problems,
> and that the remaining problems are with static typing
> of circular definitions.

If the class needs access to its own type annotations at runtime (for example, 
if it’s a dataclass), then the circular reference problem still exists with PEP 
649. That’s among the cases we’re trying to resolve. 

Eric


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

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

2022-04-26 Thread Eric V. Smith

How would runtime consumers of annotations use this?

--
Eric

> On Apr 26, 2022, at 12:05 PM, Thomas Kehrenberg  wrote:
> 
> If the problem is mostly type annotations, then another potential
> solution would be to make use of .pyi files, which are not hamstrung by
> circular definitions.  The idea would be that type checkers would merge
> the annotations from .pyi files into the annotations in the
> corresponding .py file.
> 
> So:
> 
> a.py:
> 
>from b import B
> 
>class A:
>value: B
> 
> b.py:
> 
>class B:
>value = None
> 
> b.pyi:
> 
>from typing import Optional
>from a import A
> 
>class B:
>value: Optional[A] = ...
> 
> The pyi files would kind of act like header files that are used in other
> languages.  It would mean that type checkers need to check the .pyi
> files against the code in the .py files to verify that they're
> consistent with one another.
> 
> -thomas
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/VWPWN5KWTRPP6VS4PEHJA4SRVMUDU5WR/
> Code of Conduct: http://python.org/psf/codeofconduct/

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

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

2022-04-25 Thread Eric V. Smith


On 4/25/2022 9:13 PM, Mehdi2277 wrote:

We could have forward part include all of method signatures/attributes which is 
what a type checker needs. In theory we could do,

forward class Foo:
   x: int
   y: list[str]
   
   def __init__(self, ...)


   def process(self, data: list[float]) -> float: ...

and then later do continue class. If we're willing to write a full header 
equivalent of c++ then I think static typing side will work. It'll be a lot 
more verbose then normal that I'd probably pick other solutions, but I it 
should make it tractable for a type checker.


How would this address the use case presented in the original post?

class A:
    value: B

class B:
    value: A

Eric

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

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

2022-04-25 Thread Eric V. Smith


On 4/25/2022 1:10 PM, Jim J. Jewett wrote:

(That said, my personal opinion is that this is pretty heavyweight for very 
little gain; why not just create a placeholder class that static analysis tools 
are supposed to recognize as  likely-to-be-replaced later?  And why not just 
use strings giving the expected eventual class name?  It isn't as though the 
analysis can verify whether something actually meets the full intended contract 
before they've also parsed the continuation.)


The experience with PEP 563 shows that string annotations make things 
much more difficult for dataclasses and other users of runtime type 
annotations. The point of PEP 649 and the forward declaration of classes 
is to make it possible to remove string annotations entirely.


Eric

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

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

2022-04-24 Thread Eric V. Smith


On 4/24/2022 5:42 AM, Stephen J. Turnbull wrote:

What's the use case for arbitrary expressions vs. a (possibly
qualified) name?  A class factory that produces forward declarations?
Do you have a use case in mind?


It's:

x.py:

--8<
forward class A()
--8<

x_impl.py

--8<
import X

continue class X.A:
    # class body here
--8<

It needs to be an expression because it's not defining a name, it 
referring to an existing name. You could use "from X import A" here and 
avoid a dotted expression, but it still needs to be an expression 
referring to an existing "forward class". Even if you restrict it to not 
having dots, it's logically an expression, not a name binding.


Eric


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

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

2022-04-23 Thread Eric V. Smith


On 4/23/2022 9:55 AM, Jelle Zijlstra wrote:


However, it doesn't solve the problem for base classes. For example, 
str is conceptually defined as `class str(Sequence["str"]):`. A 
forward reference can't make `str` defined when the bases are 
evaluated, because bases are resolved at the `forward class` stage.


Larry's second email "Proto-PEP part 2: Alternate implementation 
proposal for "forward class" using a proxy object" discusses a 
possibility to move the bases and metaclasses to the "continue class" 
stage. It also has the advantage of not changing the behavior of 
__new__, and I think is in general easier to reason about. He and I have 
discussed this approach, but neither of have looked at in enough detail 
to know if the implementation is possible. Some of the concerns are 
noted in that email.


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

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

2022-04-23 Thread Eric V. Smith


On 4/23/2022 3:28 AM, Tobias HT wrote:



On the other hand, there's something I've been seeing around. I don't 
know if it was introduced by Mypy or something, but its the use of 
declaration files. I think they are saved as pyi files. They just have 
the declaration of a python object, be it class or variable. What if 
we just found a way of reusing that instead?


As they currently exist, stub files (.pyi files) don't contain enough 
information. In particular, they don't have the metaclass information. 
This could be changed, but at that point you basically have the 
"forward" declaration, but it's hidden away where the interpreter can't 
see it.


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

[Python-Dev] Re: Updating inspect APIs

2022-04-17 Thread Eric V. Smith

Things like os.stat_result use PyStructSequence_NewType, which is the C
equivalent of a namedtuple. But a Struct Sequence has the extension of
being able to have more named fields than the tuple length. It was
designed, so I understand, just for cases like this. I don't know if it
would be possible for you to use it from pure Python code, or maybe
you'd need a C module to expose it.

There was idle talk many years ago of either extending namedtuple or
creating some new type factory that could do the same from pure Python
code, but no one ever got serious about it. I'm not sure it would be
accepted in any event. Buy maybe if you have a concrete use case
something like that could be done.

Eric

On 4/17/2022 1:20 PM, Pablo Galindo Salgado wrote:

Hi,

We are currently debating in gh-88116
(https://github.com/python/cpython/issues/88116)
what's the best way forward to update the APIs in the inspect module
to include the new position information.

These APIs are inspect.getframeinfo, inspect.getouterframes,
inspect.getinnerframes, inspect.stack and inspect.trace.

The problem is that these APIs return a named tuple that now needs to
include several new attributes (or one 4 tuple for
the positions). Being named tuples, if we add a new attribute,
existing unpackings of the tuple will now fail because there
are more elements or the elements are in different positions. Also, it
will be quite weird to add the new attributes at the

end but leave the line number at the beginning.

What's the best way to proceed here? The suggested way is to create a
namedtuple subclass that adds the extra attributes
but doesn't allow indexed access to it (there is a precedent to this
in how we handled updating os.stat_result). I personally
find this quite confusing but it certainly works. There may be other
options.

What do you think?

Cheers from sunny London,
Pablo Galindo Salgado

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

[Python-Dev] Re: Importing a submodule doesn't always set an attribute on its parent

2022-04-09 Thread Eric V. Smith


On 4/9/2022 4:28 PM, Terry Reedy wrote:

On 4/9/2022 5:09 AM, Arfrever Frehtes Taifersar Arahesis wrote:


Not only deletion, but also random assignments:


Ok.  Change "Manual deletion of entries from sys.modules" to "Direct 
manipulation of sys.modules"


I'm not sure it's worth the hassle to document this. There are no doubt 
hundreds of ways to break things. We can't enumerate all of them.


Eric


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

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

2022-03-29 Thread Eric V. Smith




On 3/29/2022 4:55 PM, Skip Montanaro wrote:

I was trying to think through how a "remote" stdlib might work. In the
process, I got to wondering if there are known "specialists" for
various current modules. Every now and then I still get assigned (or
at least made nosy) about something to do with the csv module. Is
there an official module-by-module list of maintainers?
There's the CODEOWNERS file: 
https://github.com/python/cpython/blob/main/.github/CODEOWNERS


Eric

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

[Python-Dev] Re: Changing unittest verbose output.

2022-03-27 Thread Eric V. Smith


> On Mar 27, 2022, at 11:20 AM, Eric V. Smith  wrote:
> 
> 
> On 3/27/2022 10:51 AM, Jelle Zijlstra wrote:
>> 
>> 
>> El sáb, 26 mar 2022 a las 17:51, Itay Yeshaya () 
>> escribió:
>>> 
>>> Any thoughts on the mentioned solutions?
>> 
>> This is a bit more out there, but can anyone explain why we show the 
>> docstring at all? As far as I can tell it causes a bunch of confusion and 
>> helps little. If there's a failing test, I want the test name so I can 
>> quickly find it in the code; I don't want the docstring which may not even 
>> be unique.
>>  
> I think this is a good idea. The target audience for a docstring isn't the 
> people trying to track down failing tests.
> 
I’m wrong about the docstrings having a different audience. So I’m going to 
retract my support here. 

Eric

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

[Python-Dev] Re: Changing unittest verbose output.

2022-03-27 Thread Eric V. Smith


On 3/27/2022 10:51 AM, Jelle Zijlstra wrote:



El sáb, 26 mar 2022 a las 17:51, Itay Yeshaya 
() escribió:



Any thoughts on the mentioned solutions?


This is a bit more out there, but can anyone explain why we show the 
docstring at all? As far as I can tell it causes a bunch of confusion 
and helps little. If there's a failing test, I want the test name so I 
can quickly find it in the code; I don't want the docstring which may 
not even be unique.


I think this is a good idea. The target audience for a docstring isn't 
the people trying to track down failing tests.


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

[Python-Dev] Re: Restrict the type of slots

2022-03-18 Thread Eric V. Smith

On 3/18/2022 4:58 PM, Guido van Rossum wrote:

On Fri, Mar 18, 2022 at 9:40 AM Paul Bryan wrote:

On Fri, 2022-03-18 at 09:35 -0700, Guido van Rossum wrote:

The motivation has been explained already.

In this thread?

Yes, Eric's message.

What on earth did your test do that got a speedup by using sets?
Was it repeatedly checking whether a variable was in a slot? The
other thing this does is rearrange the order in which slots
appear from run to run (since set order is affected by hash
randomization) and you might have gotten lucky with a popular
attribute being moved to the front, where it's more likely to be
in the memory cache already (cache lines being 64 bytes and
pointers being 8 bytes nowadays).

I created objects in a tight loop, populating attributes, noting
the elapsed time.

It does not make sense that that is correlated to the type of
__slots__, since __slots__ is not used for instance creation at all
(it is only used to create the class). I stick to my likely explanation.

Regarding Serhiy's proposal, I'm +0 on disallowing strings, and +0 on
disallowing things that can't be reiterated (but it's not a problem in
practice). Given other responses the status quo is likely best.

The PR for the issue I mentioned (https://bugs.python.org/issue46382)
allows strings and iterables (but not iterators). And it uses a match
statement, no less! I think that's good enough for dataclasses.

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

[Python-Dev] Re: Restrict the type of slots

2022-03-18 Thread Eric V. Smith


On 3/18/2022 10:01 AM, Ronald Oussoren via Python-Dev wrote:




On 18 Mar 2022, at 14:37, Joao S. O. Bueno  wrote:

IMO this is a purism that have little, if any place in language 
restrictions.
I see that not allowing. "run once" iterables could indeed void 
attempts to write
"deliberatly non cooperative code" - but can it even be reliably 
detected?


The other changes seem just to break backwards compatibility for 
little or no gain at all.
There a practical need for these changes. See 
https://bugs.python.org/issue46382 for a case where dataclasses needs 
__slots__ to be iterated over after the class has been created. And it 
would be good if __slots__ accurately reflected the slots that were 
actually created.


It may not be worth the trouble to fix this, but Serhiy’s proposal 
does try to fix a ward.


It may be better to rely on linter’s here, but one way to do this with 
few backward compatibility concerns:


- if __slots__ is a dict keep it as is
- Otherwise use tuple(__slots__) while constructing the class and 
store that value in the __slots__ attribute of the class


That way the value of the attribute reflects the slots that were 
created while not breaking code that uses __slots__ and doesn’t change 
the value after class creation.


I like this approach, too.

Eric



Ronald





On Fri, Mar 18, 2022 at 6:57 AM Ronald Oussoren via Python-Dev 
 wrote:





On 18 Mar 2022, at 10:29, Serhiy Storchaka 
wrote:

Currently __slots__ can be either string or an iterable of strings.

1. If it is a string, it is a name of a single slot. Third-party
code which iterates __slots__ will be confused.

2. If it is an iterable, it should emit names of slots. Note
that non-reiterable iterators are accepted too, but it causes
weird bugs if __slots__ is iterated more than once. For example
it breaks default pickling and copying.

I propose to restrict the type of __slots__. Require it always
been a tuple of strings. Most __slots__ in real code are tuples.
It is rarely we need only single slot and set __slots__ as a string.

It will break some code (there are 2 occurrences in the stdlib
an 1 in scripts), but that code can be easily fixed.


Pydoc supports __slots__ that is a dict, and will use the values
in the dict als documentation for the slots.   I’ve also seen
code using ``__slots__ =  “field1 field2”.split()``. I don’t
particularly like this code pattern, but your proposal would
break this.

Also note that __slots__ only has a side effect during class
definition, changing it afterwards is possible but has no effect
(“class Foo: pass; Foo.__slots__ = 42”). This surprised my
recently and I have no idea if this feature is ever used.

Ronald



___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at

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


—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at

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



—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/


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

[Python-Dev] Re: New PEP website is horrible to read on mobile device

2022-03-16 Thread Eric V. Smith


On 3/16/2022 11:23 AM, Skip Montanaro wrote:

Dang auto-correct... I meant "anti-tracking," in case it wasn't obvious.


It wasn't obvious! I was wondering what nefarious entity had created an 
anti-teaching VPN, and just what that would involve. Thanks for clarifying!


Eric


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

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

2022-02-03 Thread Eric V. Smith


On 2/3/2022 12:15 PM, Victor Stinner wrote:

I'm working bottom-to-top: prepare PyObject and PyVarObject to become
opaque, *and* top-to-bottom: prepare subclasses (structures
"inheriting" from PyObject and PyVarObject) to become opaque like
PyFrameObject.

IMO if PyObject* becomes a handle, the migration to the HPy API should
be much easier.


It seems to me that moving PyObject* to be a handle leaves you in a 
place very similar to HPy. So why not just focus on making HPy suitable 
for developing C extensions, leave the existing C API alone, and 
eventually abandon the existing C API?


Eric


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

[Python-Dev] Re: Minor inconvenience: f-string not recognized as docstring

2022-01-11 Thread Eric V. Smith


On 1/11/2022 3:44 PM, Brett Cannon wrote:



On Tue, Jan 11, 2022 at 10:40 AM Gregory P. Smith  wrote:


On Tue, Jan 11, 2022 at 10:29 AM Guido van Rossum
 wrote:

I personally think F-strings should not be usable as
docstrings. If you want a dynamically calculated docstring you
should assign it dynamically, not smuggle it in using a
string-like expression. We don't allow "blah {x}
blah".format(x=1) as a docstring either, not "foo %s bar" % x.


Agreed.  If we wanted to remove the wart of constant f-strings
happening to work as an implementation detail in this context,
that /could/ be made into a warning.  But that kind of check may
be best left to a linter for /all/ of these dynamic situations
that don't wind up populating __doc__.


Agreed on not supporting it and linters catching such a mistake.


Just to be clear, we don't support this.

>>> class C: 'foo'
...
>>> C.__doc__ == 'foo'
True

>>> class C: f'foo'
...
>>> C.__doc__ == 'foo'
False
>>> C.__doc__ is None
True

And there's a test to make sure constant f-strings are not doc strings: 
https://github.com/python/cpython/blob/dce642f24418c58e67fa31a686575c980c31dd37/Lib/test/test_fstring.py#L406


Eric



-Brett


-gps


On Tue, Jan 11, 2022 at 8:12 AM Antoine Pitrou
 wrote:

    On Tue, 11 Jan 2022 10:58:03 -0500
"Eric V. Smith"  wrote:
> Constant f-strings (those without substitutions) as doc
strings used to
> work, since the compiler turns them into normal strings.
>
> I can't find exactly where it was removed, but there was
definitely
> discussion about it. See
https://bugs.python.org/issue28739 for at least
> part of the discussion.

Ah, sorry for the misunderstanding.  While the example I
showed doesn't
have any substitutions, I'm interested in the non-trivial
(non-constant)
case actually :-)

Regards

Antoine.


>
> Eric
>
> On 1/11/2022 8:41 AM, Antoine Pitrou wrote:
> > Hello,
> >
> > Currently, a f-string is not recognized as a docstring:
> >
> >>>> class C: f"foo"
> >>>> C.__doc__
> >>>>
> > This means you need to use a (admittedly easy) workaround:
> >
> >>>> class C: __doc__ = f"foo"
> >>>> C.__doc__
> > 'foo'
> >
> > Shouldn't the former be allowed for convenience?
> >
> > Regards
> >
> > Antoine.
> >
> >
> > ___
> > Python-Dev mailing list -- python-dev@python.org
> > To unsubscribe send an email to
python-dev-le...@python.org
> >
https://mail.python.org/mailman3/lists/python-dev.python.org/
> > Message archived at

https://mail.python.org/archives/list/python-dev@python.org/message/UALMEMQ4QW7W4HE2PIBARWYBKFWJZFB4/
> > Code of Conduct: http://python.org/psf/codeofconduct/



___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at

https://mail.python.org/archives/list/python-dev@python.org/message/37YAHCREZYZFSV4BRDKUEQAX4ZF4JTI6/
Code of Conduct: http://python.org/psf/codeofconduct/



-- 
--Guido van Rossum (python.org/~guido <http://python.org/~guido>)

/Pronouns: he/him //(why is my pronoun here?)/

<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at

https://mail.python.org/archives/list/python-dev@python.org/message/35R3DCNPIQJ7ZCHTLP64IP2XZCK7QSLJ/
Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to p

[Python-Dev] Re: Minor inconvenience: f-string not recognized as docstring

2022-01-11 Thread Eric V. Smith

Constant f-strings (those without substitutions) as doc strings used to 
work, since the compiler turns them into normal strings.


I can't find exactly where it was removed, but there was definitely 
discussion about it. See https://bugs.python.org/issue28739 for at least 
part of the discussion.


Eric

On 1/11/2022 8:41 AM, Antoine Pitrou wrote:

Hello,

Currently, a f-string is not recognized as a docstring:


class C: f"foo"
C.__doc__


This means you need to use a (admittedly easy) workaround:


class C: __doc__ = f"foo"
C.__doc__

'foo'

Shouldn't the former be allowed for convenience?

Regards

Antoine.


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

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

[Python-Dev] Re: About vulnerabilities in Cpython native code

2022-01-06 Thread Eric V. Smith

This is also at https://bugs.python.org/issue46280. Please direct
comments there.

Eric

On 1/6/2022 8:22 AM, lxr1210--- via Python-Dev wrote:

Hi all,

I am currently doing some research on the security of CPython. I used
the open source vulnerability analysis engine,
Infer(https://fbinfer.com/), to scan the native code of CPython 3.10.0.

The scan results show that there are still a number of vulnerabilities
in the CPython native code, such as Null dereference, Uninitialized
variable, Resource/Memory leak, etc. Moreover, I found that some of
the vulnerabilities are related to Python/C API. I enclose the
vulnerability report for your reference.

Based on the research of the result, I tried to design a tool to
automatically detect and repair vulnerabilities in CPython and make
this tool available. See:

https://github.com/PVMPATCH/PVMPatch

Python is my favourite programming language. I sincerely hope that I
can help Python become stronger and safer. I hope this discovery can
be useful for you to develop Python in the future.

Thank you for your time and consideration!

Lin

[Python-Dev] Re: issues-test-2 spam?

2021-12-27 Thread Eric V. Smith


On 12/27/2021 12:43 PM, Zachary Ware wrote:

On Mon, Dec 27, 2021 at 11:29 AM Matti Picus  wrote:

You may want to try the experiments in a private repo under your username 
rather than under the python organization. I think this will prevent anyone 
except you from getting notified. You could even go further and set up a dummy 
bpo-migrator github user, then no one should get notifications. Thanks for 
doing the work.


Frankly, with as many other emails as constantly come in from GitHub,
these are a trivially ignorable drop in the bucket and not worth
derailing Ezio's work to avoid.  If you receive them and they bother
you, filter them out in your client.


I completely agree. And I'm sure that testing in an official python repo 
is a better test than using a private repo. I don't see the harm in an 
occasional message.


Thanks for your work, Ezio.

Eric

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

[Python-Dev] Re: Should dataclasses addset (and possibly get ) descriptors ?

2021-12-13 Thread Eric V. Smith


On 12/13/2021 1:43 AM, Vioshim wrote:

Hello good morning.

I've decided to open a discussion of a topic that I consider should be part of 
dataclasses, but not sure how suggestions work and many threads recommend to 
check python dev first so-.

Anyways, at the moment that I write this message in python3.10.1, It happens 
that when making a class with the dataclasses module, this class can't actually 
be used in Multiple inheritance for Enum purposes, this is mostly to avoid code 
repetition by having to write the methods over again.

Here's an example

from dataclasses import dataclass
from enum import Enum

@dataclass
class Foo:
 a: int = 0

class Entries(Foo, Enum):
 ENTRY1 = Foo(1)
 ENTRY2 = Foo(2)
 ENTRY3 = Foo(3)


assert Entries.ENTRY1.a == 1

This raises AssertionError, due to the values not being defined at that point, 
as the class is currently just using the default paremeters. This is why I 
think it'd be essential to implement __set__ in the module.


I don't understand what you're trying to achieve.

Entries.ENTRY1.a is Foo object. Why would you expect it to be 1? And I 
don't understand why you're inheriting from Foo. What are you trying to 
accomplish with that?


Could you explain in more detail why you're using this pattern?

Eric



Currently there's a workaround to have this work, which is defining a __set__ 
but doing this, in more complex cases, can get to be very tedious and 
repetitive coding wise

from dataclasses import dataclass
from enum import Enum

@dataclass
class Foo:
 a: int = 0

 def __set__(self, instance, value: int):
 instance.a = value


class Entries(Foo, Enum):
 ENTRY1 = Foo(1)
 ENTRY2 = Foo(2)
 ENTRY3 = Foo(3)


assert Entries.ENTRY1.a == 1


Have a great day, and hopefully this post enables a good discussion.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/U2YDIU5T67GFV4PAOHBMOGURG6TYUHP7/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Python-Dev] Re: The current state of typing PEPs

2021-11-29 Thread Eric V. Smith

Here's a use case for runtime type annotations: dataclasses use 
annotations to define fields. With the exception of ClassVar, the actual 
type is ignored. There's code in dataclasses.py to deal with stringized 
annotations, specifically just looking for ClassVar. I'd like to see 
this special case go away, assuming 649 is accepted.


And while dataclasses itself doesn't care about the types, apparently 
users do, and want to be able to call get_type_hints on the annotations. 
Many people actually want dataclasses to call this for them, but I've 
resisted. See https://bugs.python.org/issue36643


There are plenty of bugs around this issue, some of which have been 
fixed. But there are also at least a couple that haven't been fixed, and 
I'm not sure they will be. I'm hoping that 649 gets accepted and I don't 
have to worry about the problem at all. Here's an example of an open bug 
around get_type_hints with dataclasses: https://bugs.python.org/issue45524


Eric

On 11/29/2021 6:00 PM, Barry Warsaw wrote:

On Nov 26, 2021, at 01:13, Paul Moore  wrote:


I'd therefore interpret Barry's plea as being for *anyone* with a use
for annotations to provide their feedback (at least, anyone who
accepts that annotations are types), with particular emphasis on
people who want to use the types declared in annotations to affect
runtime behaviour, as that's the most under-represented group at the
moment (and it's not clear whether it's under-represented because
there aren't many such uses, or because the users aren't being heard
from).

Spot on.

-Barry


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

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

[Python-Dev] Re: Optimizing literal comparisons and contains

2021-11-28 Thread Eric V. Smith


On 11/28/2021 7:52 PM, Christopher Barker wrote:
I will frequently do simple computation with literals to make my code 
more clear:


t = 2 * 3600  # 2 hours in seconds


That is optimized as you'd hope. Tested in 3.8:

>>> dis.dis("t = 2 * 3600")
  1   0 LOAD_CONST   0 (7200)
  2 STORE_NAME   0 (t)
  4 LOAD_CONST   1 (None)
  6 RETURN_VALUE

Eric



But I see no need to optimize this kind of thing -- it would never be 
in a tight loop.


-CHB


On Sun, Nov 28, 2021 at 3:06 PM Rob Cliffe via Python-Dev 
 wrote:


I am slightly surprised that it seems to be *easier* to fold selected
constant expressions than to have more generic code to fold them all.
Or at least, all those that don't contain containers, such as
 1 in [0,1,2]
Rob Cliffe

On 28/11/2021 21:10, Eric V. Smith wrote:
>> On Nov 28, 2021, at 3:03 PM, Serhiy Storchaka
 wrote:
>>
>> 28.11.21 17:13, Skip Montanaro пише:
>>>> That is not entirely true:
https://github.com/python/cpython/pull/29639#issuecomment-974146979
>>> The only places I've seen "if 0:" or "if False:" in live code
was for
>>> debugging. Optimizing that hardly seems necessary. In any
case, the
>>> original comment was about comparisons of two constants. I suppose
>>> sweeping up all of that into a constant expression
folding/elimination
>>> step performed on the AST and/or during peephole optimization
would
>>> cover both cases.
>> "if 0:" and "if False:" is already optimized by the compiler.
The OP
>> proposes to optimize "2 < 1", and I cannot imagine any use case
for this.
> I agree. I suggest we don’t add this optimization.
>
> Eric
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at

https://mail.python.org/archives/list/python-dev@python.org/message/JP6FF2RHDQSIOS6ZAI45S7X6UXWGPBKR/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at

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

[Python-Dev] Re: Optimizing literal comparisons and contains

2021-11-28 Thread Eric V. Smith


> On Nov 28, 2021, at 3:03 PM, Serhiy Storchaka  wrote:
> 
> 28.11.21 17:13, Skip Montanaro пише:
>>> That is not entirely true: 
>>> https://github.com/python/cpython/pull/29639#issuecomment-974146979
>> 
>> The only places I've seen "if 0:" or "if False:" in live code was for
>> debugging. Optimizing that hardly seems necessary. In any case, the
>> original comment was about comparisons of two constants. I suppose
>> sweeping up all of that into a constant expression folding/elimination
>> step performed on the AST and/or during peephole optimization would
>> cover both cases.
> 
> "if 0:" and "if False:" is already optimized by the compiler. The OP
> proposes to optimize "2 < 1", and I cannot imagine any use case for this.

I agree. I suggest we don’t add this optimization. 

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

[Python-Dev] Re: Do we need to remove everything that's deprecated?

2021-11-14 Thread Eric V. Smith


On 11/14/2021 11:39 AM, Eric V. Smith wrote:


For things that really are removed (and I won't get in to the reasons 
for why something must be removed), I think a useful stance is "we 
won't remove anything that would make it hard to support a single code 
base across all supported python versions". We'd need to define 
"hard", maybe "no hasattr calls" would be part of it.


On second thought, I guess the existing policy already does this. Maybe 
we should make it more than 2 versions for deprecations? I've written 
libraries where I support 4 or 5 released versions. Although maybe I 
should just trim that back.


Eric

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

[Python-Dev] Re: Do we need to remove everything that's deprecated?

2021-11-14 Thread Eric V. Smith

On 11/12/2021 5:55 AM, Petr Viktorin wrote:

If deprecation now means "we've come up with a new way to do things,
and you have two years to switch", can we have something else that
means "there's now a better way to do things; the old way is a bit
worse but continues to work as before"?

I think optparse is a good example of this (not that I love argparse).

For things that really are removed (and I won't get in to the reasons
for why something must be removed), I think a useful stance is "we won't
remove anything that would make it hard to support a single code base
across all supported python versions". We'd need to define "hard", maybe
"no hasattr calls" would be part of it.

Reliable tools to make the migration between versions would help, too.

I could live with this, although I write systems that support old
versions of python. We just moved to 3.7, for example.

Eric

PS: Someone else said that my estimate of tens of thousands of dollars
to deal with deprecations is too high. If anything, I think it's too
low. For all of the testing and signoffs we do for a single release,
I've calculated that it costs us $5k just to release code to prod, even
if there are no actual code changes. Could that be improved? Sure. Will
it? Unlikely. Maybe I'm an outlier, but I doubt it.

[Python-Dev] Re: Having Sorted Containers in stdlib?

2021-11-12 Thread Eric V. Smith


On 11/12/2021 11:31 AM, Chris Angelico wrote:


I think that proves the value of download counts: very little. The
highest on the list is a thing called botocore, which I've never heard
of. What is it? It's a dependency of a number of Amazon web services.
My guess is that it's a dependency of popular tools - or maybe of
automatically-installed tools, even - while not itself being well
known. Actually, quite a few of the most popular packages on that list
are Amazon-related, so quite possibly they're all being installed as a
set in response to one single *actual* dependency.


botocore and boto3 are the Amazon-provided low- and high-level 
interfaces, respectively, to AWS. They're extremely import and well 
known in that environment.


Eric

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

[Python-Dev] Re: The Default for python -X frozen_modules.

2021-09-28 Thread Eric V. Smith

On 9/28/2021 9:17 AM, Antoine Pitrou wrote:

On Tue, 28 Sep 2021 09:14:38 -0400
"Eric V. Smith" wrote:

On 9/28/2021 9:10 AM, Antoine Pitrou wrote:

On Tue, 28 Sep 2021 08:55:05 -0400
"Eric V. Smith" wrote:

So I prefer to teach everybody how to use "-X frozen_modules=off" if
they want to hack the stdlib for their greatest pleasure. I prefer
that such special use case requires an opt-in option, the special use
case is not special enough to be the default.

I agree with Victor here: I'd rather have #1.

As a compromise, how about go with #1, but print a warning if python
detects that it's not built with optimizations or is run from a source
tree (the conditions in #2 and #3)? The warning could suggest running
with "-X frozen_modules=off". I realize that it will probably be ignored
over time, but maybe it will provide enough of a reminder if someone is
debugging and sees the warning.

What would be the point of printing a warning instead of doing just
what the user is expecting?

To me, the point would be to get the same behavior no matter which
python executable I run, and without regard to where I run it from.

But why do you care about this? What does it change *concretely*?

It reduces the number of things I have to remember which are different
based on where I'm running python (or which executable I'm running).

Eric

[Python-Dev] Re: The Default for python -X frozen_modules.

2021-09-28 Thread Eric V. Smith

On 9/28/2021 9:10 AM, Antoine Pitrou wrote:

On Tue, 28 Sep 2021 08:55:05 -0400
"Eric V. Smith" wrote:

I agree with Victor here: I'd rather have #1.

What would be the point of printing a warning instead of doing just
what the user is expecting?

To me, the point would be to get the same behavior no matter which
python executable I run, and without regard to where I run it from.

Eric

Freezing the stdlib is a startup performance optimization. It doesn't
need to be turned on when hacking on the Python source code... And
having to type "-X frozen_modules=off" is much more of a nuisance than
losing 10 ms in startup time (which you won't even notice in most
cases).

Regards

Antoine.

[Python-Dev] Re: The Default for python -X frozen_modules.

2021-09-28 Thread Eric V. Smith

On 9/28/2021 8:36 AM, Victor Stinner wrote:

On Mon, Sep 27, 2021 at 6:58 PM Eric Snow wrote:

We've frozen most of the stdlib modules imported during "python -c
pass" [1][2], to make startup a bit faster. Import of those modules
is controlled by "-X frozen_modules=[on|off]". Currently it defaults
to "off" but we'd like to default to "on". The blocker is the impact
on contributors. I expect many will make changes to a stdlib module
and then puzzle over why those changes aren't getting used. That's an
annoyance we can avoid, which is the point of this thread.

Possible solutions:

1. always default to "on" (the annoyance for contributors isn't big enough?)
2. default to "on" if it's a PGO build (and "off" otherwise)
3. default to "on" unless running from the source tree

Thoughts?

Honestly, for me, #1: always on, is the most reasonable choice.

I dislike when Python behaves differently depending on subtle things
like "was it built with optimizations" or "is Python started from its
source tree"?

When I built Python without optimization and/or from its source tree,
I do that to debug an issue. If the bug goes away in this case, it can
waste my time.

I agree with Victor here: I'd rather have #1.

Eric

[Python-Dev] Re: Changing exception text in micro releases

2021-09-24 Thread Eric V. Smith

On 9/24/2021 4:53 PM, Guido van Rossum wrote:

In this case I am inclined not to backport.

I agree. I decided not to backport it.
In general we should look at existing usage before making changes. 
Somebody’s code might break — but does it matter? That depends on a 
lot of factors. E.g. if parsing an error message has become a common 
way to get useful info out of the error that is not easily available 
otherwise, we have to tread lightly.

In this case I don't think anyone could be parsing it, because the 
existing version doesn't contain any information, it's always the string 
"Invalid format specifier". But I agree we should be cautious, so this 
will wait until 3.11. The original bug was reported 7.5 years ago, so 
it's not like we're in any rush.

Thanks for the input.

Eric

—Guido

On Fri, Sep 24, 2021 at 09:59 Terry Reedy <mailto:tjre...@udel.edu>> wrote:

On 9/24/2021 10:46 AM, Eric V. Smith wrote:
> On 9/24/2021 10:39 AM, Ethan Furman wrote:
>> On 9/24/21 6:51 AM, Eric V. Smith wrote:
>>
>>
>> > This is clearly an improvement. My question is: is it okay to
>> backport this to 3.9 and 3.10? I
>> > think we have a rule that it's okay to change the exception
text,
>> but I'm not sure how that
>> > applies to micro releases (3.9.x, 3.10.1).
>>
>> "better" != "bug fix", so I wouldn't change it in a micro release.
>
> Yeah, as much as I'd love to see this included, you're right.
Thanks for
> the "adult" take on it.

Exception messages are subject to change in each new version, without
deprecating the old version.  Changes are sometimes backported
when the
existing message is sufficiently erroneous. 'Sufficiently' means
something like 'harm of error outweighs harm of changing'. I don't
think a simple, easily recognized, typo or grammar error qualifies.
Among active developers, I believe Guido has the most continuity of
experience with such discussions and decisions.  Perhaps something
could
usefully be added to the devguide, but I am not sure.

-- 
Terry Jan Reedy

___
Python-Dev mailing list -- python-dev@python.org
<mailto:python-dev@python.org>
To unsubscribe send an email to python-dev-le...@python.org
<mailto:python-dev-le...@python.org>
https://mail.python.org/mailman3/lists/python-dev.python.org/
<https://mail.python.org/mailman3/lists/python-dev.python.org/>
Message archived at

https://mail.python.org/archives/list/python-dev@python.org/message/KKZVPESKEAIL4DYEIGSTPLKE34KH7XTQ/

<https://mail.python.org/archives/list/python-dev@python.org/message/KKZVPESKEAIL4DYEIGSTPLKE34KH7XTQ/>
Code of Conduct: http://python.org/psf/codeofconduct/
<http://python.org/psf/codeofconduct/>

--
--Guido (mobile)

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

[Python-Dev] Re: Changing exception text in micro releases

2021-09-24 Thread Eric V. Smith


On 9/24/2021 10:39 AM, Ethan Furman wrote:

On 9/24/21 6:51 AM, Eric V. Smith wrote:


> This is clearly an improvement. My question is: is it okay to 
backport this to 3.9 and 3.10? I
> think we have a rule that it's okay to change the exception text, 
but I'm not sure how that

> applies to micro releases (3.9.x, 3.10.1).

"better" != "bug fix", so I wouldn't change it in a micro release.


Yeah, as much as I'd love to see this included, you're right. Thanks for 
the "adult" take on it.


Eric


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

[Python-Dev] Changing exception text in micro releases

2021-09-24 Thread Eric V. Smith

This PR https://github.com/python/cpython/pull/28310 changes the message 
for some exceptions.


Currently:

>>> format('', '%M')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: Invalid format specifier

With the proposed change:
>>> format('', '%M')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: Invalid format specifier '%M' for object of type 'str'

This also applies to str.format() and f-strings.

This is clearly an improvement. My question is: is it okay to backport 
this to 3.9 and 3.10? I think we have a rule that it's okay to change 
the exception text, but I'm not sure how that applies to micro releases 
(3.9.x, 3.10.1).


Eric

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

[Python-Dev] Re: f-strings in the grammar

2021-09-21 Thread Eric V. Smith

On 9/21/2021 7:15 PM, Guido van Rossum wrote:
On Tue, Sep 21, 2021 at 4:08 PM Steve Dower <mailto:steve.do...@python.org>> wrote:

On 9/21/2021 7:42 PM, Eric V. Smith wrote:
> I don't recall exactly why, but I disallowed backslashes inside
> expressions at the last minute before 3.6 was released. It might
have
> been because I was interpreting them in a way that didn't make
sense if
> a "real" parser were inspecting f-strings. The idea, even back
then, was
> to re-allow them when/if we moved f-string parsing into the parser
> itself. I think it's time.

Yeah, we were still trying to figure out whether escapes like "\\n"
would be evaluated as "\\n" or "\n" in the expression, and decided to
decide later. If we can clearly articulate which it is now, then
let's
go ahead and enable it.

That would seem easy enough, right?

f"spam {'xyz'.replace('y', '\\n')} spam"

should be equal to

"spam x\\ny spam"

and print as

spam x\ny spam

(i.e. a literal backslash followed by 'n', not a newline).

Yes, I think that's the desired behavior. Before I removed this in 3.6 
(during the betas, IIRC), it would have produced an actual newline, 
because of where the f-string 'parser' was able to insert itself into 
the process. I/we didn't like that behavior, and it was too late to 
change it.

We could add this now in the bespoke f-string parser, although I don't 
know off the top of my head how much work it would be. But if we're 
going to switch to Pablo's parser then I don't think there's any point.

You shouldn't have to double the \ in the interpolated expression just 
because it's in an f-string.

Right.
I presume it was trickier at the time because we were coming from 
"{xxx}".format(...), where the parser doesn't know that the string is 
a format string.

Yes, that was part of it.

Eric

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

[Python-Dev] Re: f-strings in the grammar

2021-09-21 Thread Eric V. Smith

To bring this back on track, I'll try and answer the questions from your 
original email.


On 9/20/2021 7:18 AM, Pablo Galindo Salgado wrote:
I have started a project to move the parsing off-strings to the parser 
and the grammar. Appart
from some maintenance improvements (we can drop a considerable 
amount of hand-written code),
there are some interesting things we **could** (emphasis on could) get 
out of this and I wanted

to discuss what people think about them.


I think this is all awesome.

My position is that if we make zero syntactic changes to f-strings, and 
leave the functionality exactly as it is today, I think we should still 
move the logic into the parser and grammar, as you suggested. As you 
say, this would eliminate a lot of code, and in addition likely get us 
better error messages. As for the things we could possibly add:


* The parser will likely have "\n" characters and backslashes in 
f-strings expressions, which currently is impossible:


>>> f"blah blah {'\n'} blah"
  File "", line 1
    f"blah blah {'\n'} blah"
                            ^
SyntaxError: f-string expression part cannot include a backslash


I think supporting backslashes in strings inside of f-string expression 
(the part inside {}) would be a big win, and should be the first thing 
we allow. I often have to do this:


nl = '\n'
x = f"blah {nl if condition else ' '}"

Being able to write this more naturally would be a big win.

I don't recall exactly why, but I disallowed backslashes inside 
expressions at the last minute before 3.6 was released. It might have 
been because I was interpreting them in a way that didn't make sense if 
a "real" parser were inspecting f-strings. The idea, even back then, was 
to re-allow them when/if we moved f-string parsing into the parser 
itself. I think it's time.


* The parser will allow nesting quote characters. This means that we 
**could** allow reusing the same quote type in nested expressions

like this:

f"some text { my_dict["string1"] } more text"
I'm okay with this, with the caveat that I raised in another email: the 
effect on non-Python tools and alternate Python implementations. To 
restate that here: as long as we survey some (most?) of the affected 
parties and they're okay with it (or at least it doesn't cause them a 
gigantic amount of work), then I'm okay with it. This will of course be 
subjective. My big concern is tools that today use regex's (or similar) 
to recognize f-strings, and then completely ignore what's inside them. 
They just want to "skip over" f-strings in the source code, maybe 
because they're doing some sort of source-to-source transpiling, and 
they're just going to output the f-strings as-is. It seems to me we're 
creating a lot of work for such tools. Are there a lot of such tools? I 
don't know: maybe there are none.
* The parser will naturally allow more control over error messages and 
AST positions.

This would be a good win.
* The **grammar** of the f-string will be fully specified without 
ambiguity. Currently, the "grammar" that we have in the docs
(https://docs.python.org/3/reference/lexical_analysis.html#formatted-string-literals 
) 
is not really formal grammar because
not only is mixing lexing details with grammar details (the definition 
of "literal_char") but also is not compatible with the current python
lexing schema (for instance, it recognizes "{{" as its own token, 
which the language doesn't allow because something like "{{a:b}:c}"
is tokenized as "{", "{", "a" ... not as "{{", "a". Adding a formal 
grammar could help syntax highlighters, IDEs, parsers and other tools

to make sure they properly recognize everything that there is.

Also a big win.

There may be some other advantages that we have not explored still.

The work is at a point where the main idea works (all the grammar is 
already there and working), but we need to make sure that all existing
errors and specifics are properly ported to the new code, which is a 
considerable amount of work still so I wanted to make sure we are on the
same page before we decide to invest more time on this (Batuhan is 
helping me with this and Lyssandros will likely join us). We are doing
this work in this branch: 
https://github.com/we-like-parsers/cpython/blob/fstring-grammar 



Tell me what you think.

P.S. If you are interested to help with this project, please reach out 
to me. If we decide to go ahead we can use your help! :)


I'm interested in helping.

Thanks for your work on this.

Eric

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at

[Python-Dev] Re: f-strings in the grammar

2021-09-20 Thread Eric V. Smith

On 9/20/2021 11:19 AM, Terry Reedy wrote:

On 9/20/2021 7:18 AM, Pablo Galindo Salgado wrote:

there are some interesting things we **could** (emphasis on could)
get out of this and I wanted

to discuss what people think about them.

* The parser will allow nesting quote characters. This means that we
**could** allow reusing the same quote type in nested expressions

like this:

f"some text { my_dict["string1"] } more text"

I believe that this will disable regex-based processing, such as
syntax highlighters, as in IDLE. I also think that it will be
sometimes confusing to human readers.

When I initially wrote f-strings, it was an explicit design goal to be
just like existing strings, but with a new prefix. That's why there are
all of the machinations in the parser for scanning within f-strings: the
parser had already done its duty, so there needed to be a separate stage
to decode inside the f-strings. Since they look just like regular
strings, most tools could add the lowest possible level of support just
by adding 'f' to existing prefixes they support: 'r', 'b', 'u'. The
upside is that if you don't care about what's inside an f-string, your
work is done.

I definitely share your concern about making f-strings more complicated
to parse for tool vendors: basically all editors, alternative
implementations, etc.: really anyone who parses python source code. But
maybe we've already crossed this bridge with the PEG parser. Although I
realize there's a difference between lexing and parsing. While the PEG
parser just makes parsing more complicated, this change would make what
was lexing into a more sophisticated parsing problem.

In 2018 or 2019 at PyCon in Cleveland I talked to several tool vendors.
It's been so long ago that I don't remember who, but I'm pretty sure it
was PyCharm and 2 or 3 other editors. All of them supported making this
change, even understanding the complications it would cause them. I
don't recall if I talked to anyone who maintains an alternative
implementation, but we should probably discuss it with MicroPython,
Cython, PyPy, etc., and understand where they stand on it.

In general I'm supportive of this change, because as Pablo points out
there are definite benefits. But I think if we do accept it we should
understand what sort of burden we're putting on tool and implementation
authors. It would probably be a good idea to discuss it at the upcoming
dev sprints.

Eric

[Python-Dev] Re: f-strings in the grammar

2021-09-20 Thread Eric V. Smith


On 9/20/2021 11:21 AM, Terry Reedy wrote:

On 9/20/2021 8:46 AM, Serhiy Storchaka wrote:

20.09.21 14:18, Pablo Galindo Salgado пише:

* The parser will likely have "\n" characters and backslashes in
f-strings expressions, which currently is impossible:


What about characters "\x7b", "\x7d", "\x5c", etc?

What about newlines in single quotes? Currently this works:

f'''{1 +
2}'''

But this does not:

f'{1 +
2}'


The later is an error with or without the 'f' prefix and I think that 
this should continue to be the case.


The thought is that anything that's within braces {} and is a valid 
expression should be allowed. Basically, the opening brace puts you in 
"parse expression" mode. Personally, I'd be okay with this particular 
change.


Eric

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

[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

2021-08-25 Thread Eric V. Smith

I think we’re better off removing them. 2.7 is completely unsupported by us. 

Why do you think they should still be kept?

--
Eric

> On Aug 25, 2021, at 1:32 PM, Mike Miller  wrote:
> 
> 
> How about moving Python 2 notes into a section at the bottom?
> 
> 
> -Mike
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/76JIO4AF7WMJ5475FTIHTK6GR2O52OOF/
> Code of Conduct: http://python.org/psf/codeofconduct/

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

[Python-Dev] Re: Should we try to get a complete draft of What's New by b1?

2021-08-11 Thread Eric V. Smith

Yes, I think we should get it done by b1. For some reason it never
occurred to me to add this to What's New. Someone just reported this on
bpo this week. I'll try and get a PR together this week.

Eric (who doesn't feel picked on!)

On 8/11/2021 2:35 PM, Brett Cannon wrote:
Not to specifically pick on Eric V. Smith, but yesterday a co-worker
came to me asking about `KW_ONLY` for dataclasses and wanting to
provide feedback
(https://docs.python.org/3.10/library/dataclasses.html#dataclasses.KW_ONLY
<https://docs.python.org/3.10/library/dataclasses.html#dataclasses.KW_ONLY>).
I said we had reached RC and so it was pretty much too late; the
alphas and betas are when one should provide feedback.

But then I realized you wouldn't even know about this new feature
unless you read What's New ... and that's when I found out this new
feature isn't mentioned (yet). As of right now the only dataclass
feature documented in the What's New is something about slots
(https://docs.python.org/3.10/whatsnew/3.10.html#dataclasses
<https://docs.python.org/3.10/whatsnew/3.10.html#dataclasses>).

So my question is whether we want to push to be more diligent about
updating What's New by b1 so people can provide feedback during the
betas beyond just reporting breaking changes?

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

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

2021-08-11 Thread Eric V. Smith


On 8/11/2021 11:07 AM, Jukka Lehtosalo wrote:
On Wed, Aug 11, 2021 at 2:56 PM Thomas Grainger > wrote:


Would:
```
@dataclass
class Node:
    global_node: __class__ | None
```

"Just work" with co_annotations?


This feels too specialized to me.

It would be great to also handle forward references to other classes 
and cyclic references, which are also somewhat common:


@dataclass
class NodeA:
component: NodeB | None

@dataclass
class NodeB:
component: NodeA | None


Note that for dataclasses itself, you can just use:

@dataclass
class NodeA:
component: "NodeB | None"

@dataclass
class NodeB:
component: "NodeA | None"

It's only looking for typing.ClassVar or dataclasses.InitVar. Anything 
else, including a string, just means "this is a normal field". This will 
result in dataclasses.fields(NodeA)[0].type being the string "NodeB | 
None". But that's okay with dataclasses.


However, there are a number of open bpo issues where people want 
dataclasses to resolve the .type value to be the actual type object 
instead of a string, especially if using 'from __future__ import 
annotations'. I guess dataclasses.fields() could assist there, optionally.


Eric



Another, slightly more complex example would be cyclic references 
within two modules in an import cycle. For example, NodeA and NodeB 
could be defined in different modules. The common thing is that the 
dependency cycle can only be fully resolved after we have created both 
type objects. The import cycle case is probably less common but I've 
seen it in real-world code.


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

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

2021-08-10 Thread Eric V. Smith

On 8/9/2021 11:25 PM, Inada Naoki wrote:

On Tue, Aug 10, 2021 at 12:30 AM Eric V. Smith wrote:

Personally, I'd like to see PEP 649 accepted. There are a number of
issues on bpo where people expect dataclass's field.type to be an actual
Python object representing a type, and not a string. This field is
copied directly from __annotations__. If we stick with PEP 563's string
annotations, I'll probably just close these issues as "won't fix", and
tell the caller they need to convert the strings to Python objects
themselves. If 649 is accepted, then they'll all get their wish, and in
addition I can remove some ugly logic from dataclasses.

I don't think there is much difference.

PEP 563 is not default.
But the intent is/was to make it the default. That was the case in 3.10,
up until right before the release of beta 1.

And PEP 563 is not the only source of
stringified annotation.
So Accepting PEP 649 doesn't mean "they'll all get their wish". We
need to say "won't fix" anyway.

If 649 is accepted, there will be few places where stringified
annotations will be needed. For example, forward references that are
defined before __annotations__ is examined will not need to be specified
as strings. From the PEP: "Actually, annotations would become much
easier to use, as they would now also handle forward references.

Do we need to do anything here to move forward on this issue? I've
chatted with Larry and Mark Shannon, who have some additional thoughts
and I'm sure will chime in.

Currently, reference implementation of PEP 649 has been suspended.
We need to revive it and measure performance/memory impact.

Agreed.

--
Eric

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

2021-08-09 Thread Eric V. Smith

Some prior discussions:

"PEP 563 in light of PEP 649":
https://mail.python.org/archives/list/python-dev@python.org/message/ZBJ7MD6CSGM6LZAOTET7GXAVBZB7O77O/

"In support of PEP 649":
https://mail.python.org/archives/list/python-dev@python.org/message/7VMJWFGHVXDSRQFHMXVJKDDOVT47B54T/

"PEP 563 and 649: The Great Compromise":
https://mail.python.org/archives/list/python-dev@python.org/message/WUZGTGE43T7XV3EUGT6AN2N52OD3U7AE/

I'm sure there are other threads I missed.

--
Eric

On 8/9/2021 11:27 AM, Eric V. Smith wrote:
I'd like to revive the discussion of PEP 649
[https://www.python.org/dev/peps/pep-0649/] that started shortly
before development of 3.10 features was closed. This is Larry's PEP to
defer evaluation of __annotations__ until it's actually accessed.
During the discussion the decision was made to back out the change
that made "from __future__ import annotations" (PEP 563
[https://www.python.org/dev/peps/pep-0563/]) the default behavior for
3.10.

My understanding is that PEP 649 is currently in front of the SC. But
do we need to have any additional discussion here? My recollection is
that we backed out the PEP 563 change because we didn't feel we had
enough time to come to a good decision one way or the other before 3.10.

Personally, I'd like to see PEP 649 accepted. There are a number of
issues on bpo where people expect dataclass's field.type to be an
actual Python object representing a type, and not a string. This field
is copied directly from __annotations__. If we stick with PEP 563's
string annotations, I'll probably just close these issues as "won't
fix", and tell the caller they need to convert the strings to Python
objects themselves. If 649 is accepted, then they'll all get their
wish, and in addition I can remove some ugly logic from dataclasses.

Do we need to do anything here to move forward on this issue? I've
chatted with Larry and Mark Shannon, who have some additional thoughts
and I'm sure will chime in.

--
Eric V. Smith

[Python-Dev] PEP 649: Deferred Evaluation Of Annotations

2021-08-09 Thread Eric V. Smith

I'd like to revive the discussion of PEP 649
[https://www.python.org/dev/peps/pep-0649/] that started shortly before
development of 3.10 features was closed. This is Larry's PEP to defer
evaluation of __annotations__ until it's actually accessed. During the
discussion the decision was made to back out the change that made "from
__future__ import annotations" (PEP 563
[https://www.python.org/dev/peps/pep-0563/]) the default behavior for 3.10.

My understanding is that PEP 649 is currently in front of the SC. But do
we need to have any additional discussion here? My recollection is that
we backed out the PEP 563 change because we didn't feel we had enough
time to come to a good decision one way or the other before 3.10.

Do we need to do anything here to move forward on this issue? I've
chatted with Larry and Mark Shannon, who have some additional thoughts
and I'm sure will chime in.

--
Eric

[Python-Dev] Re: Devguide document on PEG parser

2021-08-05 Thread Eric V. Smith

I’ve only just started to read this, but thanks so much for writing it, Pablo. 
It will be a great help.

--
Eric

> On Aug 4, 2021, at 5:05 PM, Pablo Galindo Salgado  wrote:
> 
> 
> Hi,
> 
> After some effort, I just finished a new extensive document in the devguide 
> regarding how
> to use the new PEG parser and the PEG grammar:
> 
> https://devguide.python.org/parser/
> 
> The document contains descriptions, backgrounds, references, guides, and 
> tips. Ideally,
> this will make it a bit easier for everyone that wants to deal with the 
> grammar or the parser.
> 
> Hope that you find it useful :)
> 
> P.S. Thanks to everyone that helped with the review!
> 
> Regards from cloudy London,
> Pablo Galindo Salgado
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/WNPUUAPUZEQ6UY3DEJE2JAYT2FZZXWE3/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5CAQ6SX354SYP2QLWKXG6TYSMA4XQZ7I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is the Python review process flawed?

2021-07-01 Thread Eric V. Smith


On 7/1/2021 7:39 PM, esmeraldagar...@byom.de wrote:

"Merging something is also a responsibility to whoever does it" - And it's also 
a responsibility to fix bugs, no? I don't get why you're so afraid of (maybe!) 
introducing a new bug when there already (certainly!) is a bug.


Because the new bug you introduce might be much, much worse than the bug 
you're fixing.


Eric

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

[Python-Dev] Re: Delayed evaluation of f-strings?

2021-06-25 Thread Eric V. Smith

On 6/24/2021 11:28 PM, Guido van Rossum wrote:
On Thu, Jun 24, 2021 at 10:34 AM micro codery > wrote:

As pointed out already, f-strings and format are subtly different
(not counting that one can eval and the other cannot). Besides
quoting, the f-sting mini language has diverged from format's
>>> spam="Spam"
>>> f"{spam=}"
"spam='Spam'"
>>> "{spam=}".format(spam=spam)
Traceback (most recent call last):
  File "", line 1, in 
KeyError: 'spam='

Eric, what would you think of adding this feature to format()? It 
seems doable (at least for keyword args -- for positional args I don't 
think it makes sense).

The only problem is that it already has a meaning, as unlikely as it is 
that someone would use it:

>>> d = {'x = ': 42}
>>> "{x = }".format(**d)
'42'

Plus there's the issue of whitespace being treated differently with 
f-strings and str.format().

Honestly, the rest of the discussion belongs on python-ideas.

I totally agree.

Eric

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

[Python-Dev] Re: Delayed evaluation of f-strings?

2021-06-24 Thread Eric V. Smith

What part are you trying to delay, the expression evaluations, or the 
string building part?


There was a recent discussion on python-ideas starting at 
https://mail.python.org/archives/list/python-id...@python.org/message/LYAC7JC5253QISKDLRMUCN27GZVIUWZC/ 
that might interest you.


Eric

On 6/24/2021 5:37 AM, Eric Nieuwland wrote:
In a recent discussion with a colleague we wondered if it would be 
possible to postpone the evaluation of an f-string so we could use it 
like a regular string and .format() or ‘%’.


I found 
https://stackoverflow.com/questions/42497625/how-to-postpone-defer-the-evaluation-of-f-strings 
<https://stackoverflow.com/questions/42497625/how-to-postpone-defer-the-evaluation-of-f-strings> 
and tweaked it a bit to:


import inspect

class DelayedFString(str):
    def __str__(self):
        vars = inspect.currentframe().f_back.f_globals.copy()
vars.update(inspect.currentframe().f_back.f_locals)
        return self.format(**vars)

delayed_fstring = DelayedFString("The current name is {name}")

# use it inside a function to demonstrate it gets the scoping right
def new_scope():
    names = ["foo", "bar"]
    for name in names:
        print(delayed_fstring)

new_scope()


While this does what it should it is very slow.
So I wondered whether it would be an idea to introduce d-strings 
(delayed f-strings) and make f-strings syntactic sugar for


f"The current name is {name}" = str(d"The current name is {name}")


And perhaps access to the variables and conversions specified in the 
d-string.



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


--
Eric V. Smith

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

[Python-Dev] Re: The repr of a sentinel

2021-05-20 Thread Eric V. Smith

On 5/20/2021 3:24 PM, Ronald Oussoren via Python-Dev wrote:

On 20 May 2021, at 19:10, Luciano Ramalho > wrote:

I'd like to learn about use cases where `...` (a.k.a. `Ellipsis`) is
not a good sentinel. It's a pickable singleton testable with `is`,
readily available, and extremely unlikely to appear in a data stream.
Its repr is "Ellipsis".

If you don't like the name for this purpose, you can always define a
constant (that won't fix the `repr`, obviously, but helps with source
code readability).

SENTINEL = ...

I can't think of any case where I'd rather have my own custom
sentinel, or need a special API for sentinels. Probably my fault, of
course. Please enlighten me!

One use case for a sentinel that is not a predefined (builtin)
singleton is APIs where an arbitrary user specified value can be used.

One example of this is the definition of dataclasses.field:

|dataclasses.||field|(/*/, /default=MISSING/,
/default_factory=MISSING/, /repr=True/, /hash=None/, /init=True/,
/compare=True/, /metadata=None/)

Here the “default” and “default_factory” can be an arbitrary value,
and any builtin singleton could be used. Hence the use of a custom
module-private sentinel that cannot clash with values used by users of
the module (unless those users poke at private details of the module,
but then all bets are off anyway).

That’s why I don’t particularly like the proposal of using Ellipsis as
the sanctioned sentinel value. It would be weird at best that the
default for a dataclass field can be any value, except for the builtin
Ellipsis value.

Completely agree. I'm opposed to Ellipsis as a sentinel for this reason,
at least for dataclasses. I can easily see wanting to store an Ellipsis
in a field of a dataclass that's describing a function's parameters. And
I can even see it being the default= value. Not so much
default_factory=, but they may as well be the same.

Eric

[Python-Dev] Re: The repr of a sentinel

2021-05-13 Thread Eric V. Smith




On 5/13/2021 1:39 PM, Tal Einat wrote:

On Thu, May 13, 2021 at 7:44 PM Ethan Furman  wrote:

Consider me complaining.  ;-)

+1


An actual Sentinel class would be helpful:

  >>> class Sentinel:
  ... def __init__(self, repr):
  ... self.repr = repr
  ... def __repr__(self):
  ... return self.repr
  ...

  >>> MISSING = Sentinel('MISSING')
  >>> MISSING
  MISSING

  >>> implicit = Sentinel('')
  >>> implicit
  

Here is my suggestion (also posted on the related bpo-44123), which is
also simple, ensures a single instance is used, even considering
multi-threading and pickling, and has a better repr:

class Sentinel:
 def __new__(cls, *args, **kwargs):
 raise TypeError(f'{cls.__qualname__} cannot be instantiated')

class MISSING(Sentinel):
 pass


>>> MISSING


I think a repr of just "MISSING", or maybe "dataclasses.MISSING" would 
be better.


Eric

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

[Python-Dev] Re: The repr of a sentinel

2021-05-13 Thread Eric V. Smith

On 5/13/2021 12:41 PM, Ethan Furman wrote:

On 5/13/21 2:15 AM, Irit Katriel via Python-Dev wrote:

 >>> help(traceback.print_exception)
 Help on function print_exception in module traceback:

 print_exception(exc, /, value=0x02825DF09650>, tb= at 0x02825DF09650>, limit=None, file=None, 
chain=True)

On 5/13/21 5:37 AM, Eric V. Smith wrote:

The help looks like:

 field(*, default=0x6fe46610>,
   default_factory=0x6fe46610>,

   init=True, repr=True, hash=None, compare=True, metadata=None)

None of this is particularly awesome, but no one has complained about 
it yet.

Consider me complaining.  ;-)

Your complaint is hereby noted!

Looks to me like the default repr for the sentinels is making those 
helps much less helpful by showing totally irrelevant information and 
cluttering up the screen making it harder to see the actually useful 
bits.

An actual Sentinel class would be helpful:

   >>> class Sentinel:
   ... def __init__(self, repr):
   ... self.repr = repr
   ... def __repr__(self):
   ... return self.repr
   ...

   >>> MISSING = Sentinel('MISSING')
   >>> MISSING
   MISSING

dataclasses.py actually has similar code, but for some reason I guess it 
got missed for MISSING (ha!).

Naturally, since sentinels are symbolic names, I think it should go 
into the enum module.  ;-)  Although I will concede that we could just 
put those five lines into the modules that need it. 

Yeah, it's probably not worth dataclasses importing enum just to get 
that functionality.

Eric

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

[Python-Dev] Re: The repr of a sentinel

2021-05-13 Thread Eric V. Smith


On 5/13/2021 10:02 AM, Tal Einat wrote:

On Thu, May 13, 2021 at 4:31 PM Eric V. Smith  wrote:

I do think a python-wide standard for this would be helpful, but I don't
see how to change existing code given backward compatibility constraints.

While we're on the subject, these sentinels also don't compare
properly using `is` after pickling and unpickling.

I think it's worth considering making the sentinels in the stdlib all
have good reprs and support pickling+unpickling.

What would be the potential backwards-compatibility issues with
changing the implementation of these existing sentinel values?


I don't think there would be a problem changing the implementation. I 
was commenting on changing the name of the sentinel objects so that we 
could document the functions with the sentinel's real name. We couldn't 
change them to all be some appropriate module-level value named 
"MISSING", for example.


Eric

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

[Python-Dev] Re: The repr of a sentinel

2021-05-13 Thread Eric V. Smith


On 5/13/2021 7:48 AM, Petr Viktorin wrote:

On 13. 05. 21 11:45, Antoine Pitrou wrote:


Le 13/05/2021 à 11:40, Irit Katriel a écrit :



On Thu, May 13, 2021 at 10:28 AM Antoine Pitrou > wrote:



  I agree that  is a reasonable spelling.


I initially suggested , but now I'm not sure because it 
doesn't indicate what happens when you don't provide it (as in, what 
is the default value).  So now I'm with  or .


"" makes think of a derived class, and leaves me confused. 
"" is a bit better, but doesn't clearly say what the 
default value is, either.  So in all cases I have to read the 
docstring in addition to the function signature.




Is  the term you're looking for? 


In the dataclasses docs 
https://docs.python.org/3/library/dataclasses.html I document the 
module-level sentinel MISSING, then I document the function as:


dataclasses.field(*, default=MISSING, default_factory=MISSING, 
repr=True, hash=None, init=True, compare=True, metadata=None)


And I explain what MISSING means.

The help looks like:

field(*, default=, 
default_factory=, 
init=True, repr=True, hash=None, compare=True, metadata=None)


None of this is particularly awesome, but no one has complained about it 
yet.


I think it's important to state an actual value for the default value, 
instead of just using something like "". Unless you know the 
actual default value, you can't write a wrapper.


Say I wanted to write something that calls dataclasses.field, but 
doesn't allow the user to specify repr, hash, init, compare, and 
metadata. I could write it as:


def myfield_func(*, default=MISSING, default_factory=MISSING):
    ...

If the real default values for "default" and "default_factory" weren't 
documented, there wouldn't be any easy way to write this.


I do think a python-wide standard for this would be helpful, but I don't 
see how to change existing code given backward compatibility constraints.


Eric

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

[Python-Dev] Re: Existing asyncio features scheduled for removal in Python 3.9 and 3.10

2021-05-02 Thread Eric V. Smith


> On May 2, 2021, at 4:25 PM, Illia Volochii  wrote:
> 
> 
>> 
>> I would prefer to wait for 3.11 to remove more deprecated features,
>> these ones can survive a little bit longer.
>> 
>> If possible, I suggest to remove functions at the beginning of a new
>> Python development cycle, rather than just before the feature freeze.
>> So projects tested with the development branch of Python can detect
>> issues early and we can more time to either fix these projects, or to
>> consider reverting the removals to give more time for updating these
>> projects.
> 
> Fair enough, Victor :)
> 
>> It's common that we forget to remove deprecated functions and so that
>> documentation is not accurate. IMO it's not a big deal ;-)
> 
> Do you think it is worth updating the documentation and warnings
> related to the asyncio features to state that they will be removed in
> Python 3.11 instead of 3.9 or 3.10?

I think that’s a good idea. 

Eric


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

[Python-Dev] Re: str() vs format(): trivia question

2021-04-20 Thread Eric V. Smith

On 4/20/2021 11:13 AM, Eric V. Smith wrote:

On 4/20/2021 10:56 AM, Ethan Furman wrote:
urllib.urlencode currently uses `str()` on its non-bytes objects
before encoding the result. This causes a compatibility break when
integer module constants are converted to IntEnum, as
`str(IntEnum.MEMBER)` no longer returns the integer representation;
however, `format()` does still return the integer representation.

The fix is to add a separate branch to check if the argument is an
Enum, and use the value if so -- but it got me wondering: in general,
are there differences between calling str() vs calling format() on
Python objects?

If there's no format string, then object___format___impl() just calls
PyObject_Str(). So unless the object overrides __format__, they're the
same.

I should mention that if you're going to implement __format__ and you
don't care about the format specifier, then I'd do what
object.__format__ does and raise an error for any non-empty format
specifier. That way you can add a format specifier in the future and not
worry that people are relying on passing in arbitrary format specs,
which is a backward compatibility problem. That's why the error case was
added to object.__format__: see https://bugs.python.org/issue7994 .

Eric

int does override __format__, in _PyLong_FormatAdvancedWriter(). It
has a comment that says:

/* check for the special case of zero length format spec, make
it equivalent to str(obj) */

So even in the case of it, str(obj) should be the same as format(obj).

I thoughtPEP 3101 specifies this behavior, but I don't see it there.
It's hopelessly out of date, anyway. The docs for format() say these
weasel words: "The default /format_spec/ is an empty string which
usually gives the same effect as calling |str(value)|
<https://docs.python.org/3/library/stdtypes.html#str>.". They're vague
because a user defined type could do anything in __format__, including
ignore this advice. But I think all of the built-in types conform to it.

Eric

--
Eric V. Smith

[Python-Dev] Re: str() vs format(): trivia question

2021-04-20 Thread Eric V. Smith


On 4/20/2021 10:56 AM, Ethan Furman wrote:
urllib.urlencode currently uses `str()` on its non-bytes objects 
before encoding the result.  This causes a compatibility break when 
integer module constants are converted to IntEnum, as 
`str(IntEnum.MEMBER)` no longer returns the integer representation; 
however, `format()` does still return the integer representation.


The fix is to add a separate branch to check if the argument is an 
Enum, and use the value if so -- but it got me wondering: in general, 
are there differences between calling str() vs calling format() on 
Python objects? 


If there's no format string, then object___format___impl() just calls 
PyObject_Str(). So unless the object overrides __format__, they're the same.


int does override __format__, in _PyLong_FormatAdvancedWriter(). It has 
a comment that says:


    /* check for the special case of zero length format spec, make
   it equivalent to str(obj) */

So even in the case of it, str(obj) should be the same as format(obj).

I thoughtPEP 3101 specifies this behavior, but I don't see it there. 
It's hopelessly out of date, anyway. The docs for format() say these 
weasel words: "The default /format_spec/ is an empty string which 
usually gives the same effect as calling |str(value)| 
.". They're vague 
because a user defined type could do anything in __format__, including 
ignore this advice. But I think all of the built-in types conform to it.


Eric


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

[Python-Dev] Re: In support of PEP 649

2021-04-17 Thread Eric V. Smith

On 4/17/2021 6:44 PM, Christopher Barker wrote:
On Sat, Apr 17, 2021 at 6:12 AM Eric V. Smith <mailto:e...@trueblade.com>> wrote:

I wonder if anyone has considered the impact of PEP 563 on
dataclasses ?

I have!

Thanks Eric.

In retrospect, that field probably should have been named
"annotation". Regardless, the intent was always "store what's in
__annotations__[field_name]", or what the user specified in
field(..., type=whatever, ...).

intent is all well and good, but what was the intent of
__annotations__ In the first place. Static typing was certainly one of
the intents, but as it DID store a value, not a string from the
beginning, we can only assume that there was some intent that the
value might be used.
Yes, but wouldn't that say that PEP 563 could never be implemented then,
since it would break that intent? We already knew it broke all code that
was expecting a type object in __annotations__. I'm just saying my
expectation is 563 will break any code expecting a type object in
__annotations__, or anything that's derived from __annotations__
(specifically in my case, dataclass users looking at Field.type). My
probably unarticulated intent was that Field.type agree with
__annotations__[field_name].

As for dataclasses -- why store it at all? It seems that dataclasses
use the fact that a class attribute has an annotation to determine
what to add to the field -- which is a nifty use of teh syntax. But
presumably the intent of storing the annotation in the Field object,
and providing a public attribute for it, was so that it could be used.

I didn't want to predict what someone was using dataclasses for.
Especially someone using field(..., metadata=something) might want
access to any of the field() values, including .type. I supposed I could
have said "for defaults, default_factory, repr, etc., look at the Field
object, but for the type look at __annotations__[field_name]", but I
decided it would be easier if everything about a field would be in the
Field object. Not that it makes much difference: I believe that
Field.type always agrees with __annotations__[field_name].

This allows someone to say (where some_dataclass_field_object is a Field):

process_field(some_dataclass_field_object)

instead of this, if the .type field weren't present:

process_field(some_dataclass_field_object,
SomeDataclass.__annotations__[some_dataclass_field_object.name])

I suppose your point is that the type attribute stored the annotation,
and PEP 653 changes what the annotation will be so there's nothing
specific at all about dataclasses here. Which is true. But users of
dataclasses may have been less aware of all the implications as they
didn't write that annotation etrating code themselves. I know I wasn't.

In any event, all of this mess is one reason I'd like to see PEP
649 get accepted:

Indeed -- that is the title of this thread, after all :-)

Well, not everyone is not in support of the subject!

Eric

And see others' notes, there seems to be two other places in the
stdlib that will be affected.

-CHB

--
Christopher Barker, PhD (Chris)

Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython

--
Eric V. Smith

[Python-Dev] Re: In support of PEP 649

2021-04-17 Thread Eric V. Smith


On 4/17/2021 12:28 AM, Christopher Barker wrote:

I wonder if anyone has considered the impact of PEP 563 on dataclasses ?

I have!


I did find this SO post:

https://stackoverflow.com/questions/52171982/new-annotations-break-inspection-of-dataclasses 



which is related, but not quite the same -- THAT issue was fixed.

My issue does show up in this BPO:

https://bugs.python.org/issue39442 

Somewhere in the middle of that thread, Eric wrote: "At this point, 
this seems more like fodder for python-ideas."


Then there's a bit more to the thread, which peters out without 
resolution.


On to the issue:

dataclasses may be the only part of the stdlib that uses annotations.

dataclasses store the annotations in Field objects type attribute, in 
the __dataclass_fields__ attribute.


We can see that with this code:

@dataclass
class Simple:
    x : int
    y : float
    name : str

s = Simple(3, 4.0, "fred")

print("The field types:")
for f in s.__dataclass_fields__.values():
    print(f"name: {f.name }, type: {f.type}, type of 
type: {type(f.type)}")


Which results in:

The field types:
name: x, type: , type of type: 
name: y, type: , type of type: 
name: name, type: , type of type: 

with:

from __future__ import annotations

The result is:

The field types:
name: x, type: int, type of type: 
name: y, type: float, type of type: 
name: name, type: str, type of type: 

This of course is completely as expected.

I have no idea how dataclasses uses the Field type attribute -- as far 
as I can tell, for nothing at all. However, it is there, and it is 
called "type", rather than say, "annotation".
In retrospect, that field probably should have been named "annotation". 
Regardless, the intent was always "store what's in 
__annotations__[field_name]", or what the user specified in field(..., 
type=whatever, ...).


And I have a whole pile of code that fully expects the Fields' type 
attribute to be an actual type object that I can call to crate an 
instance of that type (or call a method on it, which is what I am 
actually doing)


So my code will very much break with this change.
True, unfortunately. To be clear to everyone not paying close attention, 
"this change" is PEP 563.


I fully understand that the __dataclass_fields__ attribute was 
probably never intended to be part of the public API, so I get what I 
deserve.


However, the Field object is documented, as such:

"""
class dataclasses.Field

Field objects describe each defined field. These objects are created 
internally, and are returned by the fields() module-level method (see 
below). Users should never instantiate a Field object directly. Its 
documented attributes are:


name: The name of the field.
type: The type of the field.
default, default_factory, init, repr, hash, compare, and metadata have 
the identical meaning and values as they do in the field() declaration.


Other attributes may exist, but they are private and must not be 
inspected or relied on.

"""

That last sentence implies that the type attribute CAN be inspected 
and relied upon, which is what I am doing.
Yes, Field.type is very much part of the public dataclasses API as 
available through dataclasses.fields(), not through 
cls.__dataclass_fields__.


And I haven't tried to solve this problem in my use case, but I'm not 
sure it can be done -- when I get around to inspecting the type of the 
Field objects, I have no idea what namespace they are in -- so I can't 
reconstruct them from the string. I really need the type object itself.
@dataclass pretty much has the same problem with respect to calling 
typing.get_type_hints().


So I'll probably need to re-write much of the dataclasses decorator, 
to call eval() early -- though even then I'm not sure I'll have access 
to the proper namespace.


Anyway -- one more data point:  PEP 563 changes the (semi-public?) API 
of dataclasses.


Though *maybe* that could be addressed with a dataclasses update -- 
again, I've only started to think about it -- there was some 
discussion of that in the BPO, though Eric didn't seem particularly 
interested.


I still think it's working as intended: it uses what's in 
__annotations__ (or passed in to field()). As everyone who has tried to 
call typing.get_type_hints() knows, it's hard to get right, if it's even 
possible, because, as you say "when I get around to inspecting the type 
of the Field objects, I have no idea what namespace they are in". My 
opinion is that the person who wants a real type object probably has a 
better idea of that namespace than @dataclass does, but there's a very 
good chance they don't know, either.


@dataclass goes out of its way to not call typing.get_type_hints(). The 
original reason for this is not wanting to force typing to be imported, 
if it wasn't already being used. That may have been addressed with PEP 
560, but

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

2021-04-14 Thread Eric V. Smith


On 4/14/2021 12:38 PM, Christopher Barker wrote:



Anyway, the question now for me is whether this is worth any more of 
my time.


So:
- Is there someone willing to sponsor?
- Do folks generally think there's a chance of it being accepted 
without a huge debate and expansion of scope.


I think that before these can be answered, you need to decide why this 
needs to be standardized. I don't see any reason to standardize it 
unless there's some programmatic use for these version strings. If it's 
just the user poking around on the REPL, then I think the status quo is 
fine. I've read the PEP, and the User Stories section talks about user 
convenience, not programmatic access.


I also think the distribution version is more useful than any 
__version__ information in each module/package. I realize this 
information might not be available, depending on how the code was 
installed (say, just by copying some files into the right place).


Eric

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

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

2021-04-12 Thread Eric V. Smith

I'm a big fan of this PEP, for many reasons. But the fact that it 
addresses some of the issues with get_type_hints() is very important. 
dataclasses avoids calling get_type_hints() for performance reasons and 
because it doesn't always succeed, see 
https://github.com/python/typing/issues/508. I believe this issue is 
fixed by PEP 649.


On 4/12/2021 2:34 AM, Larry Hastings wrote:



On 4/11/21 7:55 PM, Paul Bryan wrote:
I recognize the point you make later about its impact on static type 
checkers. Setting that aside, I'm wondering about caes where 
annotations can be dynamically generated, such as 
dataclasses.make_dataclass(...). And, I could see reasons for 
overwriting values in __annotations__, especially in the case where 
it may be stored as a string and one wants to later affix its 
evaluated value. These are considerations specific to runtime 
(dynamic) type checking.
It's fine to modify the __annotations__ dict after the creation of the 
class or module.  It's code that modifies "__annotations__" from 
within the class or module that is disallowed here. Similarly for 
dataclasses; once it creates a class object, it can explicitly set and 
/ or modify the annotations dict on that class.


There won't be any direct impact to make_dataclass(). It doesn't do 
anything tricky here: it just builds up the annotations dictionary and 
passes it as __annotations__ to the class namespace in 
types.new_class(). After creating the class, it just applies the normal 
dataclass() decorator.


Eric

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

[Python-Dev] Re: NamedTemporaryFile and context managers

2021-04-08 Thread Eric V. Smith


On 4/8/2021 4:43 PM, Antoine Pitrou wrote:

On Thu, 8 Apr 2021 13:31:26 -0700
Ethan Furman  wrote:

```python
from tempfile import NamedTemporaryFile

with NamedTemporaryFile() as fp:
  fp.write(b'some data')
  fp.close()  # Windows workaround
  fp.open()
  data = fp.read()

assert data == 'some_data'
```

The problem is that, even though `fp.open()` is still inside the context 
manager, the `close()` call deletes the file
[2].  To handle this scenario, my proposal is two-fold:

1) stop using the TEMPFILE OS attribute so the OS doesn't delete the file on 
close
2) add `.open()` to NamedTemporaryFile

Instead, you could add a dedicated `.reopen()`?


I think capturing the intent is important, rather than just putting 
.close() followed by .open(). Maybe a name that embodies "reopen for 
reading without deleting" would make the intent clear? Maybe .reopen() 
already captures that. Anyway, +1 for a method that combines the close/open.


Eric

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

[Python-Dev] Re: Merge Request Review Reminder

2021-03-22 Thread Eric V. Smith

 email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/LPCY3R4WINI5XCMWGPDA3EI52HMCPJTS/
Code of Conduct: http://python.org/psf/codeofconduct/


--
Eric V. Smith

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

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

2021-02-10 Thread Eric V. Smith


On 2/10/2021 10:29 AM, Paul Moore wrote:

On Wed, 10 Feb 2021 at 14:33, Anders Munch  wrote:


The idea is to make is so that working code only needs to change once, even 
when supporting multiple Python versions.
That one change is to add either an explicit encoding=None (for 
backwards-compatibility) or an explicit encoding='utf-8' (because that was 
intended all along).  No twice about it, one change.

But then people who added an explicit utf-8 encoding need to remove
the encoding argument again once the default value changes. Your
proposal leads to a situation where no-one leaves the encoding
argument to default. If we're going to permanently discourage omitting
the encoding argument, we should just make it mandatory (a change that
I'll argue against, but no-one is currently proposing it, luckily).


Except that all code written after the default has changed (and all 
python versions without that default are no longer supported) won't need 
to specify utf-8. And presumably there's more code to be written in the 
future than already exists.


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

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

2021-01-11 Thread Eric V. Smith


On 1/11/2021 1:10 PM, Larry Hastings wrote:



Certainly.  I'm just another victim in the copy-and-paste wars.

I actually have write access to the PEPs repo (I'm a former release 
manager) so I'd be happy to check it in myself once it gets a number, 
however that happens.  Before I do so I'll study PEP 12 as if it was 
gonna be on tomorrow's midterms.


It gets a number by you renaming your file to the next available number 
and checking it in. There's a race condition, so act fast!


Eric



//arry/

On 1/11/21 9:59 AM, Chris Angelico wrote:

On Tue, Jan 12, 2021 at 4:22 AM Larry Hastings  wrote:

I've written a new PEP.  Please find it below.  Happy reading!


Can this get added to the PEPs repo and assigned a number and such?

BTW, the currently preferred wording for the copyright blurb is
slightly different. If you're the sole author of this text, can you
please consider the license terms shown in PEP 12?

ChrisA
PEP editor - if you need a hand, I'm here to help


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

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

2020-11-23 Thread Eric V. Smith

On 11/23/2020 4:49 PM, David Mertz wrote:

On Mon, Nov 23, 2020, 4:32 PM Eric V. Smith

I just commented on Steve's post over on Discourse. The problem
with this is that the called function (m.case, here) needs to have
access to the caller's namespace in order to resolve the
expressions, such as StringNode and PairNone. This is one of the
reasons f-strings weren't implemented as a function, and is also
the source of many headaches with string type annotations.

Is this really true though? Yes, it would require magic of the sort 
zero-argument `super()` does. But can't the Matcher constructor 
capture the locals one step up the stack on instance creation? That's 
largely why my strawman version is slightly different from Steve's 
strawman.

Beyond the issue of stack access being frowned on, there are some 
practical problems. One that's given in PEP 498 is closures accessing 
variables that aren't otherwise referenced:

def outer(x):

... def inner():
... return 'x={x}'.format_map(locals())
... return inner
...

outer(42)()

Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in inner
KeyError: 'x'

Whereas an f-string in that scenario does work:

>>> def outer(x):
... def inner():
... return f'x={x}'
... return inner
...
>>> outer(42)()
'x=42'

I'd put the question this way: assuming Matcher can be written (with a 
bit of stack magic), and assuming that the strings inside m.case() 
calls are exactly the same mini-languague PEP 634 proposes, would you 
want a syntax change?

No, I wouldn't!

Something that gets brought up every now and again is: what if there 
were a way to pass an AST to a function, such that it received the AST 
instead of the evaluated value for a parameter. Let's say that backticks 
(`) meant "compute the AST of the enclosed expression", and that was 
passed it to the function. (I always choose backticks for this example 
because we all know it isn't going to happen.)

Then you write your original example using backticks instead of quotes, 
and m.case would get an AST it could inspect. It would probably still 
need some help in evaluating the AST nodes in the caller's context, but 
at least it would be theoretically possible to do so with the compiler's 
assistance.

Another option would be the function itself saying "give me an AST 
instead of evaluating a particular parameter". But that's all but 
impossible, since the compiler couldn't look at the called function to 
know it wants to do that.

I think we're in python-ideas land now.

Eric

That's not rhetorical, I'm of mixed feeling myself.

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

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

2020-11-23 Thread Eric V. Smith



On 11/23/2020 3:44 PM, David Mertz wrote:
I have a little bit of skepticism about the pattern matching syntax, 
for similar reasons to those Larry expresses, and that Steve Dower 
mentioned on Discourse.


Basically, I agree matching/destructuring is a powerful idea.  But I 
also wonder how much genuinely better it is than a library that does 
not require a language change.  For example, I could create a library 
to allow this:


m = Matcher(arbitrary_expression)
if m.case("StringNode(s)"):
process_string(m.val)
elif m.case("[a, 5, 6, b]"):
process_two_free_vars(*m.values)
elif m.case("PairNone(a, b)"):
    a, b = m.values
    process_pair(a, b)
elif m.case("DictNode"):
    foo = {key, process_node(child_node) for key, child_node in 
m.values.items()}


I don't disagree that the pattern mini-language looks nice as syntax.  
But there's nothing about that mini-language that couldn't be put in a 
library (with the caveat that patterns would need to be quoted in some 
way).


I just commented on Steve's post over on Discourse. The problem with 
this is that the called function (m.case, here) needs to have access to 
the caller's namespace in order to resolve the expressions, such as 
StringNode and PairNone. This is one of the reasons f-strings weren't 
implemented as a function, and is also the source of many headaches with 
string type annotations.


My conclusion is that if you want something that operates on DSLs 
(especially ones that can't be evaluated as expressions), the compiler 
is going to need to know about it somehow so it can help you with it. I 
wish there were a general-purpose mechanism for this. Maybe it's PEP 
638, although I haven't really investigated it much, and pattern 
matching might be a bad fit for it.


Eric


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

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

2020-11-23 Thread Eric V. Smith


On 11/23/2020 5:44 PM, David Mertz wrote:



I'd put the question this way: assuming Matcher can be written
(with a bit of stack magic), and assuming that the strings inside
m.case() calls are exactly the same mini-languague PEP 634
proposes, would you want a syntax change?


No, I wouldn't!

Is one of us mixing up negations? Are you saying you do NOT support 
PEP 634 (i.e. syntax change)?


A reasonable enough opinion that several core developers hold. Just 
trying to understand.


Sorry I wasn't clear. I wouldn't want a syntax change specific to 
matching if it could be done with a library. I just don't think it can 
be done with a library without other language changes. But I think those 
other language changes could be used in ways outside of just matching.


Eric

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

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

2020-11-02 Thread Eric V. Smith

On 11/2/2020 9:31 AM, Thomas Wouters wrote:

On Sat, Oct 31, 2020 at 12:25 PM Steven D'Aprano > wrote:

I really don't get why so many people are hung up over this minuscule
issue of giving `_` special meaning inside match statements. IMO,
consistency with other languages' pattern matching is more useful
than
the ability to capture using `_` as a variable name.

Allow me to explain, then: structured pattern matching is (even by
admission of PEPs 634-363) an extension of iterable unpacking. The use
of '_' as a wildcard pattern is a sharp break in that extension. In
the structured pattern matching proposal, '_' is special syntax (and
not in any way less so than '?') but *only* in cases in match
statements, not in iterable unpacking. It *already* isn't consistent
with '_' in other languages, and we can't fix that without breaking
uses of _ for gettext, not to mention other situations existing code
uses '_' as something other than an assign-only variable.

Using '_' in structured pattern matching means any use of '_' becomes
an extra burden -- you have to know whether it's a name or not based
on the surrounding context. It makes all uses of '_' harder to parse,
and it makes it easier to mistake one situation for another. Perhaps
not terribly easy, but since there is _no_ confusion now, it's by
definition *easier*. The use of something else, like '?', leaves
existing uses of '_' unambiguous, and allows structured pattern
matching and iterable unpacking to be thought of the same. It reduces
the complexity of the language because it no longer uses the same
syntax for disparate things.

All good points.

What I don't understand is why '_' is treated any differently than any
named capture pattern. It seems to me that using:

case x: # a capture_pattern

is the same as:

case _: # the wildcard_pattern

They both always match (I'm ignoring the binding thing here, it's coming
up). I realize PEP 635 gives the rational for separating this so that it
can enforce that "case x, x:" can be made invalid, likening it to
duplicate function parameters. The PEP focuses on the differences
between that and tuple unpacking. But I think that if the semantics were
the same as tuple unpacking (allowed duplicates, and binding to the last
one) then the whole "_ as wildcard" arguments would just go away, and
"_" would be treated just as it is elsewhere in Python. For me, this
would address Thomas' point above and reduce the cognitive load of
having a special rule.

But I'm probably missing some other nuance to the whole discussion,
which will no doubt now be pointed out to me.

Eric

[Python-Dev] Re: os.scandir bug in Windows?

2020-10-18 Thread Eric V. Smith


On 10/18/2020 12:25 PM, Rob Cliffe via Python-Dev wrote:
How do I do that, please?  I can't see an obvious create option on 
that web page.  Do I need to log in?


Yes, you need to log in before you can open an issue. You might need to 
create an account first if you don't have one: it's called "Register" on 
bpo. After you've logged in, there's a Create New button.


Eric



Thanks
Rob Cliffe

On 18/10/2020 05:31, Gregory P. Smith wrote:
Could you please file this as an issue on bugs.python.org 
?


Thanks!
-Greg


On Sat, Oct 17, 2020 at 7:25 PM Rob Cliffe via Python-Dev 
mailto:python-dev@python.org>> wrote:



TLDR: In os.scandir directory entries, atime is always a copy of
mtime
rather than the actual access time.

Demo program: Windows 10, Python 3.8.3:

# osscandirtest.py
import time, os
with open('Test', 'w') as f: f.write('Anything\n') # Write to a file
time.sleep(10)
with open('Test', 'r') as f: f.readline() # Read the file
print(os.stat('Test'))
for DirEntry in os.scandir('.'):
 if DirEntry.name == 'Test':
 stat = DirEntry.stat()
 print(f'scandir DirEntry {stat.st_ctime=} {stat.st_mtime=}
{stat.st_atime=}')

Sample output:

os.stat_result(st_mode=33206, st_ino=8162774324687317,
st_dev=2230120362, st_nlink=1, st_uid=0,
st_gid=0, st_size=10, st_atime=1600631381, st_mtime=1600631371,
st_ctime=1600631262)
scandir DirEntry stat.st_ctime=1600631262.951019
stat.st_mtime=1600631371.7062848 stat.st_atime=1600631371.7062848

For os.stat, atime is 10 seconds more than mtime, as would be
expected.
But for os.scandir, atime is a copy of mtime.
ISTM that this is a bug, and in fact recently it stopped me from
using
os.scandir in a program where I needed the access timestamp. No big
deal, but ...
If it is a feature for some reason, presumably it should be
documented.

Best wishes
Rob Cliffe
___
Python-Dev mailing list -- python-dev@python.org

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

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

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




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

[Python-Dev] Re: Shutting down Import-SIG mailing list?

2020-10-13 Thread Eric V. Smith


Okay, I've sent in the request. Thanks!

Eric

On 10/13/2020 5:50 PM, Brett Cannon wrote:

Shut it down! 

On Tue, Oct 13, 2020 at 9:46 AM Barry Warsaw <mailto:ba...@python.org>> wrote:


Seems fine to me.  It’s an easy process; just ask postmaster@ and
they can shut the list down, retaining the archives read-only for
posterity.

-Barry

> On Oct 13, 2020, at 09:26, Eric V. Smith mailto:e...@trueblade.com>> wrote:
>
> Would anyone care if Import-SIG was shut down? It gets a few
spam emails per day that need to be cleaned up. It hasn't had any
real messages for a couple of years. I think if the discussions
were moved to python-dev it wouldn't be a noticeable increase in
traffic.
>
> We'd want to keep it around for the archives, but not for new
postings. I don't know what's involved in that from a technical
perspective.
>
> Eric
>
> ___
> Python-Dev mailing list -- python-dev@python.org
<mailto:python-dev@python.org>
> To unsubscribe send an email to python-dev-le...@python.org
<mailto:python-dev-le...@python.org>
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at

https://mail.python.org/archives/list/python-dev@python.org/message/BDFNTHCKXOV7FQUKUCWUPZ22EV6D7QTC/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-Dev mailing list -- python-dev@python.org
<mailto:python-dev@python.org>
To unsubscribe send an email to python-dev-le...@python.org
<mailto:python-dev-le...@python.org>
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at

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


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

[Python-Dev] Shutting down Import-SIG mailing list?

2020-10-13 Thread Eric V. Smith

Would anyone care if Import-SIG was shut down? It gets a few spam emails 
per day that need to be cleaned up. It hasn't had any real messages for 
a couple of years. I think if the discussions were moved to python-dev 
it wouldn't be a noticeable increase in traffic.


We'd want to keep it around for the archives, but not for new postings. 
I don't know what's involved in that from a technical perspective.


Eric

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

[Python-Dev] Re: Farewell, Python 3.5

2020-10-01 Thread Eric V. Smith

Thanks for all of your work, Larry. I really think it was the stability 
of these releases that helped push 3.x into dominance over 2.7.


3  version control systems. Insane!

Eric

On 10/1/2020 1:49 PM, Larry Hastings wrote:



At last!  Python 3.5 has now officially reached its end-of-life.  
Since there have been no checkins or PRs since I tagged 3.5.10, 3.5.10 
will stand as the final release in the 3.5 series.


As with a similar announcement I wrote about eighteen months ago, I 
know we can all look back fondly on Python 3.5.  3.5 added many new 
asynchronous I/O programming features, the "typing" module, and even a 
new operator ("@").  Plus many and varied quality-of-life improvements 
for the Python programmer, in both the language, the library, the core 
implementation, and even the installers.  Python 3.5.0 was the best 
version of the best language at the time, and since then it's gotten 
even better!


My thanks to all the members of the Python 3.5 release team. In 
alphabetical order:


Georg Brandl

Julian Palard

Ned Deily

Steve Dower

Terry Reedy

My thanks also to the Python infrastructure team.


The end of Python 3.5 support also ends my tenure as a Python Release 
Manager.  Congratulations, you survived me and my frequent mistakes!  
(Special shouts out to Ned and Benjamin for running around behind the 
scenes quietly cleaning up my messes--and not even telling me most of 
the time.)  Rest assured that I leave you in /much/ better hands with 
the current crop of RMs: Ned, Łukasz, and Pablo.


One amusing note.  During my tenure as a Python release manager, I had 
to deal with /three/ different revision control systems.  Although 
we'd switched CPython itself to Mercurial  by the time 3.4 alpha 0 was 
released, there were still many supporting repositories still on 
Subversion.  (I remember having to do Subversion branch merges as part 
of my 3.4 release work... what a pain.)  And of course these days 
we're on Git (-hub).  This straddling of three different workflows 
certainly complicated the lives of us Release Managers.  So, my 
friends, please... make up your minds!  ;-)



It's been my honor to serve you,


//arry/

p.s. As of today, every supported version of Python supports 
f-strings.  The only remaining excuse for "we can't use f-strings" is 
no longer viable!



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

[Python-Dev] Re: Deferred, coalescing, and other very recent reference counting optimization

2020-09-02 Thread Eric V. Smith




On 9/2/2020 1:23 PM, Raihan Rasheed Apurbo wrote:

Thank you, sir. Guido already mentioned it so I was going to search google 
about it. Thanks for your direct link as well. I really appreciate it. I will 
surely look into that. :)


No problem. It would also help if you included a little context when you 
replied to messages. It's not clear who you're responding to here 
(although I think it's me).


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

[Python-Dev] Re: Deferred, coalescing, and other very recent reference counting optimization

2020-09-01 Thread Eric V. Smith

Search for “Larry Hastings gilectomy”. For example, there’s this: 
https://speakerdeck.com/pycon2017/larry-hastings-the-gilectomy-hows-it-going

--
Eric V. Smith
(301) 502-0945 cell

> On Sep 1, 2020, at 12:21 PM, Raihan Rasheed Apurbo  wrote:
> 
> Before experimenting can't I ask someone whether relevant experiments were 
> made or not?  if I am not supposed to do that then I totally agree with you, 
> sir. 
> 
> I tried asking in python-ideas and one of the replies was "I gather there 
> have been some experiments along these lines as part
> of efforts to remove the GIL. You might like to research them to find out how 
> much success they've had." 
> 
> What I can interpret from this reply is there are some experiments regarding 
> this topic but I don't know where they are.  Then I asked him where could I 
> find them but didn't get any answer to that. 
> 
> Then how have I got my answers? 
> 
> I am so sorry if I am asking any inappropriate question here.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/2IC27QRCFB6CSVMMYR3NTVU34TI5J6XN/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ULP7CU2OQPBCY7FGVTOFC6LKXNSCFTIW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Resurrecting PEP-472

2020-08-27 Thread Eric V. Smith

Leaving out the complication of needing a new sponsor, I would think the
best course of action would be to create a new PEP. I think keeping the
original rejected PEP is a net positive, and especially so if one of the
original authors isn't available. At the very least, you'd want to
remove their name from any updated version, and at that point it's
really a new PEP anyway (IMO).

As to the sponsor, I think there should be a new sponsor in either case:
a brand new PEP or resurrecting a rejected PEP. Basically the sponsor
acts as a hurdle to get things in front of the steering council, and
that hurdle shouldn't be bypassed just by resurrecting an old PEP.

Eric

On 8/27/2020 4:50 AM, Steven D'Aprano wrote:

Hi all,

On the Python-Ideas mailing list, there has been a long debate about
resurrecting PEP 472, "Support for indexing with keyword arguments".

https://www.python.org/dev/peps/pep-0472/

One of the existing authors, Stefano Borini, is interested in updating
the PEP with a new strategy that has some support (but not a consensus)
on Python-Ideas, and removing from contention the previous strategies.

The new strategy is to pass keyword arguments directly to keyword
parameters in the `__getitem__` etc methods, as other functions and
methods do. The previous, rejected, strategies involved various hacks
such as overloading the single index parameter with a dict or a
namedtuple, etc.

Two complications:

- the PEP is rejected, not deferred.

- one of the previous co-authors, Joseph Martinot-Lagarde, seems to have
dropped out of contact.

Does Stefano need to get a sponsor and create a new PEP, or can he
prepare a PR and ask for it to be re-opened?

[Python-Dev] Re: PR stuck in Travis

2020-08-21 Thread Eric V. Smith


Hi, Facundo.

You could try closing the PR and then re-opening it.

Eric

On 8/21/2020 2:18 PM, Facundo Batista wrote:

Hello!

I want to land this PR:

   https://github.com/python/cpython/pull/21466

It's doc only, so it only run the docs part in GH actions. All fine,
except Travis, which is "required", but didn't finish. I'm not finding
a way to restart that job.

- from Github: I don't find any restart/resend job or similar (and in
the line corresponding to Travis in the checks list, I don't have a
"details").

- from Travis: I can not make that PR to appear in
https://travis-ci.com/github/python/cpython/pull_requests , even if I
click on "show me more" a lot (a *lot*). I don't know if there's a
specific way to show the job "by PR", and not "by build" (which I
don't know).

- from git: I could tell the author to push an empty commit, that
probably would do it, but I'd consider this a last resource.

Did you suffer from this before? Which is the recommended course of action?

Thanks!


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

[Python-Dev] Re: Problems with python and Geany?

2020-07-16 Thread Eric V. Smith

This list is for the development of Python the language. For end-user 
help, you're better off using python-list, whose details are here: 
https://mail.python.org/mailman/listinfo/python-list


Eric

On 7/16/2020 8:00 AM, arajg...@sevenmentor.com wrote:

So I have recently purchased a rapsberry pi in hope that it will ease me in to 
programming and learn a bit more about computing. I was reading an article in 
pc pro about creating a game using python so thought I would give it a shot. 
However, when I try to execute on Geany I keep getting the same message :
"09:13:05: Failed to execute "C:\Python27\python "raspberry.py"" (start-script could 
not be created: Failed to create file: Permission denied)"
I've been searching google and forums for answers as I cannot see why this is 
not working Any ideas? Anyone?!

https://www.sevenmentor.com/best-python-classes-in-pune.php
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JGADR2R4ULSORZ6XU25KNC5ARBVT2IMK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-07-12 Thread Eric V. Smith


On 7/11/2020 7:54 PM, Greg Ewing wrote:


I can see that being a reasonable choice if you're using 8-space
indents, but I don't see that done much in Python.

Also, directly translating this into Python leads to something that
looks like a mistake:

    match x:
    case 1:
    ...
    case 2:
    ...

and as has been pointed out, the alternative of putting x on the
next line is unprecedented in Python.


If the 2 levels of indenting are really offensive, surely we could teach 
editors, black, ourselves, etc. to indent the match statement as:


match pt:
  case (x, y):    # <-- indent by two spaces
    return Point3d(x, y, 0)   # <-- indent by 2 more spaces, for a 
total of 4


if x:
    return x  # <-- normally indent by 4 spaces

I used to do something similar with C switch statements.

I guess you couldn't use this trick if you were using tabs. Another 
reason to not use them!


Eric

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

[Python-Dev] Re: ML help

2020-07-06 Thread Eric V. Smith

This list if for developing the next version of Python, not for 
providing help with using Python. I suggest you use a Sift-specific 
mailing list for help with Sift.


Eric

On 7/6/2020 4:54 AM, hamza naeem wrote:
Hi , I am making a classifier which basically scans the historical 
places and detects them .I am using SIFT for taking features of images 
and then passing them to the neural network . Features are 128 
dimensional and model is trained with 97% accuracy but when i am using 
Single image prediction it is giving error :
*    ValueError: Input 0 of layer sequential_9 is incompatible with 
the layer: expected axis -1 of input shape to have value 128 but 
received input with shape [32, 1]*
It's shape is already 128 , but I don't know why it is giving an error 
. Kindly help me i got stucked in it for several days


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

[Python-Dev] Re: Re Re: Recent PEP-8 change (Ivan Pozdeev)

2020-07-02 Thread Eric V. Smith

On 7/2/2020 6:49 PM, Rémi Lapeyre wrote:

Le 3 juil. 2020 à 00:32, Ivan Pozdeev via Python-Dev
mailto:python-dev@python.org>> a écrit :

Athttps://git-scm.com/book/en/v2/Git-Branching-Rebasing#_rebase_vs_merge,
they say that the argument of whether to allow overwriting history in
VCSes stems from two opposing views on what a project's history
should be. One is that is shall be a raw, unedited record of events
as they happened; the other is that is should be a (polished and
adapted for future reading) story of how the project was made.

That's for how to add the commit on the master branch, once it’s there
you can’t update it without breaking every fork and PR.

For all purposes, the history is immutable for example if you look at
the v3.9.0b3 tag, it is signed so you know that this is the code that
went into the release according to the person that signed the commit.
If you changed any parent commit, it would change all childs and the
signature would then be invalid which would be an issue.

But this commit was to the peps repo, which has far fewer commits, one
branch, no tags, and only 10 PRs. So while it's still an issue, it's not
as big a deal as if we were talking about the cpython repo.

I don't know how many forks have been made since the commit in question.

Eric

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

2020-07-02 Thread Eric V. Smith

On 7/2/2020 11:36 AM, Stefan Behnel wrote:

Victor Stinner schrieb am 02.07.20 um 00:07:

Le mer. 1 juil. 2020 à 23:43, Eric V. Smith a écrit :

On 7/1/2020 3:43 PM, Stefan Behnel wrote:

Petr Viktorin schrieb am 30.06.20 um 14:51:

For example, could we only deprecate the bad parts, but not remove them
until the experiments actually show that they are preventing a beneficial
change?

Big nod on this one.

At one of the core sprints (maybe at Microsoft?) there was talk of
adding a new API without changing the existing one.

There is the https://github.com/pyhandle/hpy project which is
implemented on top of the existing C API.

But this project doesn't solve problems listed in PEP 620, since
CPython must continue to support existing C extensions.

Maybe I'm missing something here, but how is "removing parts of the C-API"
the same as "supporting existing C extensions" ? It seems to me that both
are straight opposites.

Agreed. I thought the discussion was "in CPython, leave the existing
C-API alone, but experiment with new APIs, and then maybe someday
deprecate the existing C-API". I could see conditionally disabling the
existing C-API if doing so was needed to do something like experimenting
with remove reference counting. But for the foreseeable future, we'd
ship with the existing C-API until we'd determined a significant benefit
to dropping it.

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

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

2020-07-01 Thread Eric V. Smith


On 7/1/2020 3:43 PM, Stefan Behnel wrote:

Petr Viktorin schrieb am 30.06.20 um 14:51:

For example, could we only deprecate the bad parts, but not remove them
until the experiments actually show that they are preventing a beneficial
change?

Big nod on this one.


At one of the core sprints (maybe at Microsoft?) there was talk of 
adding a new API without changing the existing one.


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

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

2020-06-17 Thread Eric V. Smith

On 6/17/2020 6:03 PM, Jeff Allen wrote:

On 17/06/2020 19:28, Eric V. Smith wrote:

On 6/17/2020 12:07 PM, Jeff Allen wrote:
If (1) interpreters manage the life-cycle of objects, and (2) a race
condition arises when the life-cycle or state of an object is
accessed by the interpreter that did not create it, and (3) an
object will sometimes be passed to an interpreter that did not
create it, and (4) an interpreter with a reference to an object will
sometimes access its life-cycle or state, then (5) a race condition
will sometimes arise. This seems to be true (as a deduction) if all
the premises hold.
I'm assuming that passing an object between interpreters would not be
supported. It would require that the object somehow be marshalled
between interpreters, so that no object would be operated on outside
the interpreter that created it. So 2-5 couldn't happen in valid code.

The Python level doesn't support it, prevents it I think, and perhaps
the implementation doesn't support it, but nothing can stop C actually
doing it. I would agree that with sufficient discipline in the code it
should be possible to prevent the worlds from colliding. But it is
difficult, so I think that is why Mark is arguing for a separate
address space. Marshalling the value across is supported, but that's
just the value, not a shared object.

Yes, it's difficult to have the discipline in C, just as multi-threaded
is difficult in C. I agree separate address spaces makes isolation much
easier, but I think there are use cases that don't align with separate
address spaces, and we should support those.

Sorry for being loose with terms. If I want to create an interpreter
and execute it, then I'd allocate and initialize an interpreter state
object, then call it, passing the interpreter state object in to
whatever Python functions I want to call. They would in turn pass
that pointer to whatever they call, or access the state through it
directly. That pointer is the "current interpreter".

I think that can work if you have disciplined separation, which you
are assuming. I think you would pass the function to the interpreter,
not the other way around. I'm assuming this is described from the
perspective of some C code and your Python functions are PyFunction
objects, not just text? What, however, prevents you creating that
function in one interpreter and giving it to another? The function,
and any closure or defaults are owned by the creating interpreter.

In the C API (which is what I think we're discussing), I think it would
be passing the interpreter state to the function. And nothing would
prevent you from getting it wrong.

There's a lot of state per interpreter, including the module state.
See "struct _is" in Include/internal/pycore_interp.h.

So much more than when I last looked! Look back in time and
interpreter state mostly contains the module context (in a broad sense
that includes shortcuts to sys, builtins, codec state, importlib). Ok,
there's some stuff about exit handling and debugging too. The recent
huge growth is to shelter previously singleton object allocation
mechanisms, a consequence of the implementation choice that gives the
interpreter object that responsibility too. I'm not saying this is
wrong, just that it's not a concept in Python-the-language, while the
module state is.

I think most of these changes are Victor's, and I think they're a step
in the right direction. Since Python globals are really module state, it
makes sense that that's the part that's visible to Python.

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

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

2020-06-17 Thread Eric V. Smith


On 6/17/2020 12:07 PM, Jeff Allen wrote:

On 12/06/2020 12:55, Eric V. Smith wrote:

On 6/11/2020 6:59 AM, Mark Shannon wrote:
Different interpreters need to operate in their own isolated address 
space, or there will be horrible race conditions.

Regardless of whether that separation is done in software or hardware,
it has to be done.


I realize this is true now, but why must it always be true? Can't we 
fix this? At least one solution has been proposed: passing around a 
pointer to the current interpreter. I realize there issues here, like 
callbacks and signals that will need to be worked out. But I don't 
think it's axiomatically true that we'll always have race conditions 
with multiple interpreters in the same address space.


Eric


Axiomatically? No, but let me rise to the challenge.

If (1) interpreters manage the life-cycle of objects, and (2) a race 
condition arises when the life-cycle or state of an object is accessed 
by the interpreter that did not create it, and (3) an object will 
sometimes be passed to an interpreter that did not create it, and (4) 
an interpreter with a reference to an object will sometimes access its 
life-cycle or state, then (5) a race condition will sometimes arise. 
This seems to be true (as a deduction) if all the premises hold.


(1) and (2) are true in CPython as we know it. (3) is prevented 
(completely?) by the Python API, but not at all by the C API. (4) is 
implicit in an interpreter having access to an object, the way CPython 
and its extensions are written, so (5) follows in the case that the C 
API is used. You could change (1) and/or (2), maybe (4).


I'm assuming that passing an object between interpreters would not be 
supported. It would require that the object somehow be marshalled 
between interpreters, so that no object would be operated on outside the 
interpreter that created it. So 2-5 couldn't happen in valid code.


"Passing around a pointer to the current interpreter" sounds like an 
attempt to break (2) or maybe (4). But I don't understand "current". 
What you need at any time is the interpreter (state and life-cycle 
manager) for the object you're about to handle, so that the receiving 
interpreter can delegate the action, instead of crashing ahead itself. 
This suggests a reference to the interpreter must be embedded in each 
object, but it could be implicit in the memory address.


Sorry for being loose with terms. If I want to create an interpreter and 
execute it, then I'd allocate and initialize an interpreter state 
object, then call it, passing the interpreter state object in to 
whatever Python functions I want to call. They would in turn pass that 
pointer to whatever they call, or access the state through it directly. 
That pointer is the "current interpreter".


There is then still an issue that the owning interpreter has to be 
thread-safe (if there are threads) in the sense that it can serialise 
access to object state or life-cycle. If serialisation is by a GIL, 
the receiving interpreter must take the GIL of the owning interpreter, 
and we are somewhat back where we started. Note that the "current 
interpreter" is not a function of the current thread (or vice-versa). 
The current thread is running in both interpreters, and by hypothesis, 
so are the competing threads.


Agreed that an interpreter shouldn't belong to a thread, but since an 
interpreter couldn't access objects of another interpreter, there'd be 
no need for cross-intepreter locking. There would be a GIL per 
interpreter, protecting access to that interpreter's state.


Can I just point out that, while most of this argument concerns a 
particular implementation, we have a reason in Python (the language) 
for an interpreter construct: it holds the current module context, so 
that whenever code is executing, we can give definite meaning to the 
'import' statement. Here "current interpreter" does have a meaning, 
and I suggest it needs to be made a property of every function object 
as it is defined, and picked up when the execution frame is created. 
This *may* help with the other, internal, use of interpreter, for 
life-cycle and state management, because it provides a recognisable 
point (function call) where one may police object ownership, but that 
isn't why you need it.


There's a lot of state per interpreter, including the module state. See 
"struct _is" in Include/internal/pycore_interp.h.


Eric


Jeff Allen



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

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

2020-06-12 Thread Eric V. Smith

On 6/11/2020 6:59 AM, Mark Shannon wrote:

Hi Riccardo,

On 10/06/2020 5:51 pm, Riccardo Ghetta wrote:

Hi,
as an user, the "lua use case" is right what I need at work.
I realize that for python this is a niche case, and most users don't
need any of this, but I hope it will useful to understand why having
multiple independent interpreters in a single process can be an
essential feature.
The company I work for develop and sells a big C++ financial system
with python embedded, providing critical flexibility to our customers.
Python is used as a scripting language, with most cases having C++
calling a python script itself calling other C++ functions.
Most of the times those scripts are in workloads I/O bound or where
the time spent in python is negligible. > But some workloads are
really cpu bound and those tend to become
GIL-bound, even with massive use of C++ helpers; some to the point
that GIL-contention makes up over 80% of running time, instead of 1-5%.
And every time our customers upgrade their server, they buy machines
with more cores and the contention problem worsens.

Different interpreters need to operate in their own isolated address
space, or there will be horrible race conditions.

Regardless of whether that separation is done in software or hardware,
it has to be done.

I realize this is true now, but why must it always be true? Can't we fix
this? At least one solution has been proposed: passing around a pointer
to the current interpreter. I realize there issues here, like callbacks
and signals that will need to be worked out. But I don't think it's
axiomatically true that we'll always have race conditions with multiple
interpreters in the same address space.

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

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

2020-06-10 Thread Eric V. Smith

On 6/10/2020 8:33 AM, Mark Shannon wrote:

Hi Petr,

On 09/06/2020 2:24 pm, Petr Viktorin wrote:

On 2020-06-05 16:32, Mark Shannon wrote:

Whether Python interpreters run sequentially or in parallel, having
them work will enable a use case I would like to see: allowing me to
call Python code from wherever I want, without thinking about global
state. Think calling Python from an utility library that doesn't care
about the rest of the application it's used in. I personally call
this "the Lua use case", because light-weight, worry-free embedding
is an area where Python loses to Lua. (And JS as well—that's a
relatively recent development, but much more worrying.)

This seems like a worthwhile goal. However I don't see why this
requires having multiple Python interpreters in a single O/S process.

I assume it would be so that my code could link with library A, which
embeds Python, and library B, which also embeds Python. A and B have no
knowledge of each other.

The part I have been involved in is moving away from process-global
state. Process-global state can be made to work, but it is much safer
to always default to module-local state (roughly what
Python-language's `global` means), and treat process-global state as
exceptions one has to think through. The API introduced in PEPs 384,
489, 573 (and future planned ones) aims to make module-local state
possible to use, then later easy to use, and the natural default.

I don't agree. Process level state is *much* safer than module-local
state.

Suppose two interpreters, have both imported the same module.
By using O/S processes to keep the interpreters separate, the hardware
prevents the two copies of the module from interfering with each other.
By sharing an address space the separation is maintained by trust and
hoping that third party modules don't have too many bugs.

I don't see how you can claim the later case if safer.

I've always assumed that per-module state meant per-module,
per-interpreter. Maybe I've misunderstood, in which case I agree with
Mark. If per-module state isn't isolated per interpreter, that sort of
kills the multiple interpreter model, in my mind.

Eric

[Python-Dev] Re: Should we be making so many changes in pursuit of PEP 554?

2020-06-05 Thread Eric V. Smith


On 6/5/2020 11:11 AM, Edwin Zimmerman wrote:

Advantages of the one-to-one model
--

1. It's less bug prone. It is much easier to reason about code working
in a single address space. Most code assumes

I'm curious where reasoning about address spaces comes into writing Python 
code?  I can't say that address space has ever been a
concern to me when coding in Python.


I don't know enough about Python code with subinterpreters to comment 
there. But for the C code that makes up much of CPython: it's very 
difficult to inspect code and know you aren't accidentally sharing 
objects between interpreters.


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

[Python-Dev] Re: Map errno==ETIME to TimeoutError

2020-05-25 Thread Eric V. Smith


Thanks, Giampaolo. Could you leave a comment on the issue?

Erci

On 5/25/2020 10:32 AM, Giampaolo Rodola' wrote:
I'm -1 because the concept of "timeout" is generic enough to be often 
implemented as a custom exception, which poses questions re. 
backward/forward compatibilty. E.g. in psutil I have "TimeoutExpired", 
also providing a "seconds" attribute. Also I've probably never seen 
ETIME / ETIMEDOUT happening, whereas AFAIU the point PEP 3151 was to 
create mappings for the most common errnos.


On Sun, May 24, 2020 at 6:48 PM Eric V. Smith <mailto:e...@trueblade.com>> wrote:


Does anyone have an opinion on https://bugs.python.org/issue39673?
It maps ETIME to TimeoutError, in addition to the already existing
ETIMEDOUT.

http://man7.org/linux/man-pages/man3/errno.3.html says:

*ETIME *Timer expired (POSIX.1 (XSI STREAMS option)).

(POSIX.1 says "STREAMioctl(2)  
<http://man7.org/linux/man-pages/man2/ioctl.2.html>  timeout".)

*ETIMEDOUT *Connection timed out (POSIX.1-2001).
  


It seems like a reasonable change to me, but I'm not a subject
matter expert on STREAMS, or what other affect this might have.

And if added to 3.10, should it be backported? I'd tend to say
"no", because of unknown impacts on existing code.

Eric

___
Python-Dev mailing list -- python-dev@python.org
<mailto:python-dev@python.org>
To unsubscribe send an email to python-dev-le...@python.org
<mailto:python-dev-le...@python.org>
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at

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



--
Giampaolo - http://grodola.blogspot.com

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

[Python-Dev] Re: Map errno==ETIME to TimeoutError

2020-05-25 Thread Eric V. Smith



On 5/25/2020 4:25 AM, Serhiy Storchaka wrote:

24.05.20 17:48, Eric V. Smith пише:
Does anyone have an opinion on https://bugs.python.org/issue39673? It 
maps ETIME to TimeoutError, in addition to the already existing 
ETIMEDOUT.


http://man7.org/linux/man-pages/man3/errno.3.html says:

    *ETIME *Timer expired (POSIX.1 (XSI STREAMS option)).

    (POSIX.1 says "STREAMioctl(2) 
<http://man7.org/linux/man-pages/man2/ioctl.2.html> timeout".)


    *ETIMEDOUT *Connection timed out (POSIX.1-2001).

It seems like a reasonable change to me, but I'm not a subject matter 
expert on STREAMS, or what other affect this might have.


Why it was not mapped at first place? Was there any discussion?


Good question. Perhaps Antoine can answer.

I don't see any mention of ETIME in PEP 3151. I'm assuming it was just 
an oversight. I couldn't find any reference to ETIME on python-ideas or 
python-dev (other than this discussion), either.


Eric

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

[Python-Dev] Re: Map errno==ETIME to TimeoutError

2020-05-24 Thread Eric V. Smith


On 5/24/2020 9:31 PM, Cameron Simpson wrote:

What's the class hierachy here?


TimeoutError is derived from OSError.

So if you're catching OSError and looking for errno == ETIME, you're 
good. If you're catching both OSError and TimoutError, an ETIME which 
used to be an OSError would now be a TimeoutError.


Eric



I for one have some code (not specificly timeouts) of the form:

   try:
   os.something(...)
   except OSError as e:
   if e.errno == errno.EPERM:
   suitable action
   else:
   raise

in various permutations. I have the vague feeling that one of these 
broke for me recently because a call was not raisingeturning an 
OSError but one of the fine grained os-flavoured exceptions, like 
FileNotFoundError or the like. It may have involved something "high 
level" like open() instead of a direct os.something() call.


Anyway, I'd like to know how this might affect try/except setups, 
particularly ones like the above which expect to catch a class of 
error and differentiate amongst them.


I am not against the issue suggest though.

Cheers,
Cameron Simpson 

On 24May2020 14:59, Gregory P. Smith  wrote:

Sounds like a natural fit, I'd just do it for 3.10.

On Sun, May 24, 2020, 9:45 AM Eric V. Smith  wrote:


Does anyone have an opinion on https://bugs.python.org/issue39673? It
maps ETIME to TimeoutError, in addition to the already existing 
ETIMEDOUT.


http://man7.org/linux/man-pages/man3/errno.3.html says:

   *ETIME   *Timer expired (POSIX.1 (XSI STREAMS option)).

   (POSIX.1 says "STREAM ioctl(2) 
<http://man7.org/linux/man-pages/man2/ioctl.2.html> timeout".)


   *ETIMEDOUT   *Connection timed out (POSIX.1-2001).


It seems like a reasonable change to me, but I'm not a subject matter
expert on STREAMS, or what other affect this might have.

And if added to 3.10, should it be backported? I'd tend to say "no",
because of unknown impacts on existing code.

Eric

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

[Python-Dev] Map errno==ETIME to TimeoutError

2020-05-24 Thread Eric V. Smith

Does anyone have an opinion on https://bugs.python.org/issue39673? It 
maps ETIME to TimeoutError, in addition to the already existing ETIMEDOUT.


http://man7.org/linux/man-pages/man3/errno.3.html says:

   *ETIME *Timer expired (POSIX.1 (XSI STREAMS option)).

   (POSIX.1 says "STREAMioctl(2)  
  timeout".)

   *ETIMEDOUT *Connection timed out (POSIX.1-2001).
 

It seems like a reasonable change to me, but I'm not a subject matter 
expert on STREAMS, or what other affect this might have.


And if added to 3.10, should it be backported? I'd tend to say "no", 
because of unknown impacts on existing code.


Eric

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

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

2020-05-15 Thread Eric V. Smith

I fear that my comment on some text in the PEP was lost amidst the 
voting, so I'm repeating it here. This will probably screw up some 
threading, but this is the oldest message I have to reply to.


The PEP says "At most one additional item may be consumed from one of 
the iterators when compared to normal zip usage." I think this should be 
prefaced with "If ValueError is raised ...". Also, why does it say "at 
most one additional item". How could it ever be less than one?


And I'm not sure I'd say "normal zip usage", maybe "the existing builtin 
zip function".


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

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

2020-05-15 Thread Eric V. Smith


On 5/15/2020 11:56 AM, Chris Angelico wrote:

On Sat, May 16, 2020 at 1:54 AM Antoine Pitrou  wrote:

On Fri, 15 May 2020 10:46:25 -0400
David Mertz  wrote:

1. +1 itertools.zip_strict function
2. +1 zip.strict(*args)
3. +1 zip(*args, mode='strict')  # mode='shortest' by default
4. +0 zip(*args, strict=True)


Mostly I agree with Steven on relative preference:

itertools.zip_strict() +1
zip.strict() +0.5
zip(mode='strict') +0
zip(strict=True) -0.5

For me:

* zip(strict=True)   +1
* zip(mode='strict') -0
* itertools.zip_strict() -0.5
* zip.strict()   -1  (but really, I'd like to make this -1e10)


Since we're posting:

itertools.zip_strict() +1
zip.strict() +0.1
zip(strict=True) -0.5
zip(mode='strict') -1


itertools.zip_strict() +1
zip.strict() +0
zip(strict=True) -0
zip(mode='strict') -1

I don't particularly care for "strict", though. It doesn't seem specific enough, and doesn't say 
"they iterators must return the same number of items" to me. I sort of liked "equal" 
better, but not so much to make a big stink about it.

Also: The PEP says "At most one additional item may be consumed from one of the iterators when compared 
to normalzip  usage." I think this should be prefaced with "If ValueError is raised ...". 
Also, why does it say "at most one additional item". How could it ever be less than one?

Eric

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

[Python-Dev] Re: [RELEASE] Python 3.9.0a6 is now available for testing

2020-04-29 Thread Eric V. Smith


Hi, ro...@reportlab.com.

That looks like a real error. Thanks for the detailed report. Can you 
open a ticket on bugs.python.org?


Eric

On 4/29/2020 10:34 AM, ro...@reportlab.com wrote:

While testing 3.9a6 in the reportlab package I see this difference from 3.8.2; 
I built from source using the standard configure make dance. Is this a real 
change?

robin@minikat:~/devel/reportlab/REPOS/reportlab/tests
$ python
Python 3.8.2 (default, Apr  8 2020, 14:31:25)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

norm=lambda m: m+(m and(m[-1]!='\n'and'\n'or'')or'\n')


robin@minikat:~/devel/reportlab/REPOS/reportlab/tests
$ python39
Python 3.9.0a6 (default, Apr 29 2020, 07:46:29)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

norm=lambda m: m+(m and(m[-1]!='\n'and'\n'or'')or'\n')

   File "", line 1
 norm=lambda m: m+(m and(m[-1]!='\n'and'\n'or'')or'\n')
  ^
SyntaxError: invalid string prefix
robin@minikat:~/devel/reportlab/REPOS/reportlab/tests
$ python39 -X oldparser
Python 3.9.0a6 (default, Apr 29 2020, 07:46:29)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

norm=lambda m: m+(m and(m[-1]!='\n'and'\n'or'')or'\n')

   File "", line 1
 norm=lambda m: m+(m and(m[-1]!='\n'and'\n'or'')or'\n')
^
SyntaxError: invalid string prefix
robin@minikat:~/devel/reportlab/REPOS/reportlab/tests
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PCQD2REYQ7GT6GVY2FLYEASVKRS756HO/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Python-Dev] Re: Adding a "call_once" decorator to functools

2020-04-29 Thread Eric V. Smith


On 4/29/2020 3:55 AM, Tom Forbes wrote:

Hey Raymond,
Thanks for your input here! A new method wouldn’t be worth adding purely for 
performance reasons then, but there is still an issue around semantics and 
locking.


One thing I don't understand about the proposed @call_once (or whatever 
it's called): why is locking a concern here any more than it's a concern 
for @lru_cache? Is there something special about it? Or, if locking is a 
requirement for @call_once (maybe optionally), then wouldn't adding the 
same support to @lru_cache make sense?


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

[Python-Dev] Re: PEP 616 "String methods to remove prefixes and suffixes" accepted

2020-04-20 Thread Eric V. Smith


Congratulations, Dennis!

Not 10 minutes ago I was writing code that could have used this 
functionality. And I got it wrong on my first attempt! I'm looking 
forward to it in 3.9.


Eric

On 4/20/2020 2:26 PM, Victor Stinner wrote:

Hi,

The Python Steering Council accepts the PEP 616 "String methods to
remove prefixes and suffixes":
https://www.python.org/dev/peps/pep-0616/

Congrats Dennis Sweeney!

We just have one last request: we expect the documentation to explain
well the difference between removeprefix()/removesuffix() and
lstrip()/strip()/rstrip(), since it is the rationale of the PEP ;-)

You can find the WIP implementation at:

* https://github.com/python/cpython/pull/18939
* https://bugs.python.org/issue39939

Victor

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

[Python-Dev] Re: Providing fix for modulefinder.py regression on Windows

2020-04-12 Thread Eric V. Smith


On 4/12/2020 4:08 PM, Barry Scott wrote:


On 11 Apr 2020, at 16:28, Barry Scott > wrote:


modulefinder.py does not open source files in "rb" which
prevents compile() from applying the encoding rules.


snip

*I have created the bpo, the pr and have the checks passing except 
that I need a NEWS.d entry*
*to make bedevere/news happy. I see the files have a special filename 
is that from an automatic*

*process of a tool I need to run?*
*
*
*Barry*

The tool is blurb (or the online blurb-it): 
https://devguide.python.org/committing/#what-s-new-and-news-entries


Eric

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

1 2 3 4 5 6 >

1 - 100 of 534 matches

Mail list logo