[Python-Dev] Implementing async enumerate

[Filipe Alves Caixeta]

Hello,

Python 3.10 comes with the built-in *anext()* but I think we may be missing
some other equivalent built-in functions like *list* and *enumerate*.
I didn't discuss the idea of creating a PEP for this but I would like to
get some help with the implementation.

The equivalent Python code would be





*async def aenumerate(sequence, start=0):n = startasync for elem in
sequence:yield n, elemn += 1*

The code for enumerate if here
https://github.com/python/cpython/blob/2f3a87856c7033227577b9ed0c77ed75311430b7/Objects/enumobject.c#L42

The *next* function creates a tuple and return with (n, elem)




*result = PyTuple_New(2);PyTuple_SET_ITEM(result, 0,
next_index);PyTuple_SET_ITEM(result, 1, next_item);return result;*

For the async implementation I would have to instead return an
*async_generator_asend* object
and that would resolve to the tuple. Calling *tp_as_async->am_anext* and
getting the value doesn't seem like the solution because I should not get
the result at this stage yet.

I would like to have a hint on how to implement this =D
___
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/7ZRSZAOM5NPF3DOMPS2XNS64L7XP5SBN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: IMPORTANT: Python 3.10b2 release blockers

[Pablo Galindo Salgado]

Small correction:

https://bugs.python.org/issue40222: "Zero cost" exception handling

and the segfaults on these buildbots:

https://buildbot.python.org/all/#/builders/582/builds/165/steps/5/logs/stdio
https://buildbot.python.org/all/#/builders/543/builds/190

are 3-11 (main branch) only, but they are also quite important to get fixed
as soon as possible,
so the buildbot failures don't pile up.

On the other hand, seems that there is a nasty race condition on
test_asyncio and many of the refleak
builders for 3.10 hang, rendering them not usefull:

https://buildbot.python.org/all/#/builders/693/builds/21
https://buildbot.python.org/all/#/builders/677/builds/22
https://buildbot.python.org/all/#/builders/669/builds/22
...

You can access the release dashboard for the buildbots here:

https://buildbot.python.org/all/#/release_status

On Mon, 24 May 2021 at 23:45, Pablo Galindo Salgado 
wrote:

> Hi,
>
> Tomorrow is the scheduled release of Python 3.10 beta 2 but unfortunately
> we have several release blockers:
>
> https://bugs.python.org/issue41282: Deprecate and remove distutils
> https://bugs.python.org/issue40222: "Zero cost" exception handling
> https://bugs.python.org/issue42972: [C API] Heap types (PyType_FromSpec)
> must fully implement the GC protocol
> https://bugs.python.org/issue44043: 3.10 b1 armhf Bus Error in hashlib
> test: test_gil
>
> We also have the address sanitizer buildbot failing :
>
>
> https://buildbot.python.org/all/#/builders/582/builds/165/steps/5/logs/stdio
>
> and some segmentation faults on the fedora stable buildbot:
>
> https://buildbot.python.org/all/#/builders/543/builds/190
>
> Some of these issues have PRs but some of them have not. Please, if you
> are involved or you maintain one of the
> areas involved in these issues, take a look at them and act with one of
> the following:
>
> * Fix the issue making a PR
> * Review an existing PR and / or merge it
> * If you intend to mark it as a deferred blocker, please provide a
> rationale and contact me first by pinging me in the issue.
>
> Until these issues are fixed or deferred, the release team will not be
> able to make a new beta release.
>
> Thanks for your help,
>
> Regards from stormy 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/GBD57CUUU4K5NMQDTEZXNCX76YISEIGQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] IMPORTANT: Python 3.10b2 release blockers

[Pablo Galindo Salgado]

Hi,

Tomorrow is the scheduled release of Python 3.10 beta 2 but unfortunately
we have several release blockers:

https://bugs.python.org/issue41282: Deprecate and remove distutils
https://bugs.python.org/issue40222: "Zero cost" exception handling
https://bugs.python.org/issue42972: [C API] Heap types (PyType_FromSpec)
must fully implement the GC protocol
https://bugs.python.org/issue44043: 3.10 b1 armhf Bus Error in hashlib
test: test_gil

We also have the address sanitizer buildbot failing :

https://buildbot.python.org/all/#/builders/582/builds/165/steps/5/logs/stdio

and some segmentation faults on the fedora stable buildbot:

https://buildbot.python.org/all/#/builders/543/builds/190

Some of these issues have PRs but some of them have not. Please, if you are
involved or you maintain one of the
areas involved in these issues, take a look at them and act with one of the
following:

* Fix the issue making a PR
* Review an existing PR and / or merge it
* If you intend to mark it as a deferred blocker, please provide a
rationale and contact me first by pinging me in the issue.

Until these issues are fixed or deferred, the release team will not be able
to make a new beta release.

Thanks for your help,

Regards from stormy 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/FHFI7QKWNHAVWVFTCHJGTYD3ZFVEUXDD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: GDB not breaking at the right place

[Guido van Rossum]

To the contrary, I think if you want the CI jobs to be faster you should
add the CFLAGS to the configure call used to run the CI jobs.

On Mon, May 24, 2021 at 1:30 PM Victor Stinner  wrote:

> --with-pydebug default compiler flags is a trade-off between "runtime
> checks for debug" and performance. -O0 makes Python slower. For
> example, we want to Python CI to run as fast as possible.
>
> I don't want to fight for https://bugs.python.org/issue38350 I simply
> learnt to type: ./configure --with-pydebug CFLAGS="-O0" (I have a
> shell alias for that).
>
> Victor
>
> On Mon, May 24, 2021 at 5:54 PM Guido van Rossum  wrote:
> >
> > I'm confused. I've always assumed that --with-pydebug was intended for
> the situation where you're modifying the C code, so obviously you might
> have to debug C code. (I know that was the case when we introduced it,
> decades ago.) If that's not the goal, then what is --py-debug used for?
> >
> > On Mon, May 24, 2021 at 3:35 AM Victor Stinner 
> wrote:
> >>
> >> "Debugging" means many things. Python is built with -Og because it
> >> makes Python faster than -O0, and most developers debug Python code,
> >> not C code (in gdb).
> >>
> >> If you don't need to go up to the gdb/lldb level, -Og is fine.
> >>
> >> It would even make sense to build Python with -O3 in debug mode if you
> >> don't debug C code at all, only pure Python code.
> >>
> >> My proposition to switch to -00 by default was rejected:
> >> https://bugs.python.org/issue38350
> >>
> >> I also love -O0 when I modify C code because it makes the build faster
> ;-)
> >>
> >> Fedora Python debug builds are now built with -O0 which makes gdb a
> >> way more pleasant experience, not more strange behavior with inlined
> >> code or "" local variables or function arguments.
> >>
> >> Victor
> >>
> >> On Sun, May 23, 2021 at 3:57 PM Skip Montanaro <
> skip.montan...@gmail.com> wrote:
> >> >
> >> > > I strongly suggest to only build Python with -O0 when using gdb. -Og
> >> > > enables too many optimizations which makes gdb less usable.
> >> >
> >> > Thanks, Victor. It never made sense to me that you would want any
> >> > optimizations enabled when truly debugging code (as opposed to wanting
> >> > debug symbols and a sane traceback in production code).
> >> >
> >> > I'm getting more convinced that the problem I'm seeing is a GCC/GDB
> >> > thing, particularly because I can move the erroneous stopping point by
> >> > changing the GCC optimization level. I'll probably open a bugzilla
> >> > report just so it's on that team's radar screen. In the meantime, to
> >> > get going again I wrote a crude script which maps the
> >> > file:function:label form to file:linenumber form. That way I can
> >> > save/restore breakpoints across GDB sessions and still avoid problems
> >> > when the offsets to specific instructions change.
> >> >
> >> > Skip
> >> >
> >> > Skip
> >>
> >>
> >>
> >> --
> >> Night gathers, and now my watch begins. It shall not end until my death.
> >> ___
> >> 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/FPWJHHV55JPF6ZQVI2OGMYSIPYN3AXH2/
> >> Code of Conduct: http://python.org/psf/codeofconduct/
> >
> >
> >
> > --
> > --Guido van Rossum (python.org/~guido)
> > Pronouns: he/him (why is my pronoun here?)
>
>
>
> --
> Night gathers, and now my watch begins. It shall not end until my death.
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun 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/FRTN734KSWC66A67BUHKVFNV7WFSNNIS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: GDB not breaking at the right place

[Victor Stinner]

--with-pydebug default compiler flags is a trade-off between "runtime
checks for debug" and performance. -O0 makes Python slower. For
example, we want to Python CI to run as fast as possible.

I don't want to fight for https://bugs.python.org/issue38350 I simply
learnt to type: ./configure --with-pydebug CFLAGS="-O0" (I have a
shell alias for that).

Victor

On Mon, May 24, 2021 at 5:54 PM Guido van Rossum  wrote:
>
> I'm confused. I've always assumed that --with-pydebug was intended for the 
> situation where you're modifying the C code, so obviously you might have to 
> debug C code. (I know that was the case when we introduced it, decades ago.) 
> If that's not the goal, then what is --py-debug used for?
>
> On Mon, May 24, 2021 at 3:35 AM Victor Stinner  wrote:
>>
>> "Debugging" means many things. Python is built with -Og because it
>> makes Python faster than -O0, and most developers debug Python code,
>> not C code (in gdb).
>>
>> If you don't need to go up to the gdb/lldb level, -Og is fine.
>>
>> It would even make sense to build Python with -O3 in debug mode if you
>> don't debug C code at all, only pure Python code.
>>
>> My proposition to switch to -00 by default was rejected:
>> https://bugs.python.org/issue38350
>>
>> I also love -O0 when I modify C code because it makes the build faster ;-)
>>
>> Fedora Python debug builds are now built with -O0 which makes gdb a
>> way more pleasant experience, not more strange behavior with inlined
>> code or "" local variables or function arguments.
>>
>> Victor
>>
>> On Sun, May 23, 2021 at 3:57 PM Skip Montanaro  
>> wrote:
>> >
>> > > I strongly suggest to only build Python with -O0 when using gdb. -Og
>> > > enables too many optimizations which makes gdb less usable.
>> >
>> > Thanks, Victor. It never made sense to me that you would want any
>> > optimizations enabled when truly debugging code (as opposed to wanting
>> > debug symbols and a sane traceback in production code).
>> >
>> > I'm getting more convinced that the problem I'm seeing is a GCC/GDB
>> > thing, particularly because I can move the erroneous stopping point by
>> > changing the GCC optimization level. I'll probably open a bugzilla
>> > report just so it's on that team's radar screen. In the meantime, to
>> > get going again I wrote a crude script which maps the
>> > file:function:label form to file:linenumber form. That way I can
>> > save/restore breakpoints across GDB sessions and still avoid problems
>> > when the offsets to specific instructions change.
>> >
>> > Skip
>> >
>> > Skip
>>
>>
>>
>> --
>> Night gathers, and now my watch begins. It shall not end until my death.
>> ___
>> 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/FPWJHHV55JPF6ZQVI2OGMYSIPYN3AXH2/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> Pronouns: he/him (why is my pronoun here?)



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/G7EFOMH7DXC3TUCR3R6UJ7Q2KTT5UN22/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Luciano Ramalho]

On Mon, May 24, 2021 at 11:44 AM Tal Einat  wrote:
> > But frankly Luciano's idea of a base class that can be subclassed seems the 
> > most startightford to me.
>
> Yes, and it's what I originally suggested near the beginning of this thread :)

I am sorry to have missed your previous e-mail with a base class for
sentinels, @Tal. I support that idea.

In fact, if we have a SentinelMeta metaclass, and a Sentinel base
class built from SentinelMeta, the Sentinel class can be used directly
as a sentinel without the need for subclassing—if the application does
not require a custom sentinel. If it does, then the user can subclass
Sentinel.

The SentinelMeta could be private, to discourage misuse.

This is my implementation, after learning from @Tal's code:

https://github.com/fluentpython/example-code-2e/blob/master/25-class-metaprog/sentinel/sentinel.py

Since having a Sentinel base class is desirable for ease of use, I
think it is simpler to code the __new__ method in it, instead of
coding metaclass logic to inject __new__ in the class namespace.

Best,

Luciano



-- 
Luciano Ramalho
|  Author of Fluent Python (O'Reilly, 2015)
| http://shop.oreilly.com/product/0636920032519.do
|  Technical Principal at ThoughtWorks
|  Twitter: @ramalhoorg
___
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/UUXUKG3UZLTWKXPV6IZAE5KOMEJHMUS5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Question for potential python development contributions on Windows

[Steve Dower]

When you're installing Visual Studio the C++ tools version is listed 
under the selected components as "v14x".


However, at this stage, the *only* version in circulation is 14.x - mine 
shows v142. Until the 14 changes to a "15", it will be binary compatible 
and so you can use any version at all to build CPython and/or extension 
modules.


Our official releases are always using relatively up-to-date compilers, 
but provided the compatibility is maintained on Microsoft's side, 
there's no need to worry about the specific versions.


Cheers,
Steve

On 5/24/2021 4:49 PM, Guido van Rossum wrote:

How do you check that the C++ tools are v14.x?

On Mon, May 24, 2021 at 1:43 AM Łukasz Langa > wrote:




On 20 May 2021, at 07:03, pjfarl...@earthlink.net
 wrote:

The Python Developers Guide specifically states to get VS2017 for
developing or enhancing python on a Windows system.
__ __
Is it still correct to specifically use VS2017 , or is VS2019 also
acceptable?


We have to update the devguide. VS 2019 is supported, probably even
recommended, as long as the C++ tools are v14.x.

Cheers,
Łukasz

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

[Python-Dev] Re: GDB not breaking at the right place

[Guido van Rossum]

I'm confused. I've always assumed that --with-pydebug was intended for the
situation where you're modifying the C code, so obviously you might have to
debug C code. (I know that was the case when we introduced it, decades
ago.) If that's not the goal, then what is --py-debug used for?

On Mon, May 24, 2021 at 3:35 AM Victor Stinner  wrote:

> "Debugging" means many things. Python is built with -Og because it
> makes Python faster than -O0, and most developers debug Python code,
> not C code (in gdb).
>
> If you don't need to go up to the gdb/lldb level, -Og is fine.
>
> It would even make sense to build Python with -O3 in debug mode if you
> don't debug C code at all, only pure Python code.
>
> My proposition to switch to -00 by default was rejected:
> https://bugs.python.org/issue38350
>
> I also love -O0 when I modify C code because it makes the build faster ;-)
>
> Fedora Python debug builds are now built with -O0 which makes gdb a
> way more pleasant experience, not more strange behavior with inlined
> code or "" local variables or function arguments.
>
> Victor
>
> On Sun, May 23, 2021 at 3:57 PM Skip Montanaro 
> wrote:
> >
> > > I strongly suggest to only build Python with -O0 when using gdb. -Og
> > > enables too many optimizations which makes gdb less usable.
> >
> > Thanks, Victor. It never made sense to me that you would want any
> > optimizations enabled when truly debugging code (as opposed to wanting
> > debug symbols and a sane traceback in production code).
> >
> > I'm getting more convinced that the problem I'm seeing is a GCC/GDB
> > thing, particularly because I can move the erroneous stopping point by
> > changing the GCC optimization level. I'll probably open a bugzilla
> > report just so it's on that team's radar screen. In the meantime, to
> > get going again I wrote a crude script which maps the
> > file:function:label form to file:linenumber form. That way I can
> > save/restore breakpoints across GDB sessions and still avoid problems
> > when the offsets to specific instructions change.
> >
> > Skip
> >
> > Skip
>
>
>
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> 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/FPWJHHV55JPF6ZQVI2OGMYSIPYN3AXH2/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun 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/7HIR4SA33OVP2OKZ43SJ6K42E2ZNOGTY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Question for potential python development contributions on Windows

[Guido van Rossum]

How do you check that the C++ tools are v14.x?

On Mon, May 24, 2021 at 1:43 AM Łukasz Langa  wrote:

>
> On 20 May 2021, at 07:03, pjfarl...@earthlink.net wrote:
>
> The Python Developers Guide specifically states to get VS2017 for
> developing or enhancing python on a Windows system.
>
> Is it still correct to specifically use VS2017 , or is VS2019 also
> acceptable?
>
>
> We have to update the devguide. VS 2019 is supported, probably even
> recommended, as long as the C++ tools are v14.x.
>
> Cheers,
> Łukasz
> ___
> 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/UCSCYMMJA4UBBUZLUHSEOE2POEBNTKLF/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun 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/NNIVE6WXBQ5YS7TTS6I3BVTLPE24XLCL/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Tal Einat]

On Mon, May 24, 2021 at 6:04 AM Christopher Barker  wrote:
>
> 1) “Add a single new sentinel value, e.g. MISSING or Sentinel” (under 
> rejected)
>
> I was one of the proponent of that -- but not as an alternative to having a 
> stadardars way to create unique sentinels, but as an addition. That's kind of 
> orthogonal to the PEP, but it would still be nice to have it at the same time.
>
> Why? There was a fair bit of discussion as to why you would not want to 
> require everyone to use  MISSING (dataclasses, in particular), but I still 
> think better for the readability of everyone's code for the common case(s?) 
> to use the same singleton, if they can.

The way I see it, there are several clear motivations to implement one
of these and make that the recommended way of defining sentinels. The
further benefit of having both is less clear to me.

Also, there's this in the Zen of Python: "There should be one-- and
preferably only one --obvious way to do it." This strengthens my
feeling that having two recommended ways of defining sentinel values,
in addition to the existing None, would be undesirable.

> 2) couldn't a factory function simply return a sentinel subclass? Maybe I'm 
> missing something, but I can't see why that would require stack frame 
> inspection.

It seems better for each sentinel to have its own class, which makes
it possible to write strict type signatures and allows better static
code analysis. It also makes handling copying and unpickling simple.

> But frankly Luciano's idea of a base class that can be subclassed seems the 
> most startightford to me.

Yes, and it's what I originally suggested near the beginning of this thread :)

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

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

[Tal Einat]

On Mon, May 24, 2021 at 4:10 AM MRAB  wrote:
>
> On 2021-05-24 01:37, Luciano Ramalho wrote:
> > Now I can use NotGiven as the sentinel, and its default repr is .
> >
> The repr of other singletons are the names of those singletons, eg.
> "None", so why "" instead of "NotGiven"?

Yea, that's up in the air. The common suggestions are either
"NotGiven", "" or "mymodule.NotGiven".

The first makes sense for builtins like None and Ellipses, but I'm not
sure a function signature like foo(bar=NotGiven) is very clear.

With the factory function pattern there's no need for a default, so
this may become a non-issue, and I may remove the recommendation for
which form to use.

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

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

[Tal Einat]

On Mon, May 24, 2021 at 3:30 AM Luciano Ramalho  wrote:
>
> On Sun, May 23, 2021 at 3:37 AM Tal Einat  wrote:
> > I put up an early draft of a PEP on a branch in the PEPs repo:
> > https://github.com/python/peps/blob/sentinels/pep-.rst
>
> Thanks for that PEP, Tal. Good ideas and recap there.
>
> I think repr= should have a default: the name of the class within <>:
> .
>
> Sentinels don't have state or any other data besides a name, so I
> would prefer not to force users to create a class just so they can
> instantiate it.
>
> Why not just this?
>
> NotGiven = sentinel('')

I'm seriously considering that now. The issues I ran into with this
approach are perhaps not actually problematic.

> On the other hand, if the user must create a class, the class itself
> should be the sentinel. Class objects are already singletons, so that
> makes sense.
>
> Here is a possible class-based API:
>
> class NotGiven(Sentinel):
> pass
>
> That's it. Now I can use NotGiven as the sentinel, and its default
> repr is .
>
> Behind the scenes we can have a SentinelMeta metaclass with all the
> magic that could be required--including the default __repr__ method.
>
> What do you think?

One issue with that is that such sentinels don't have their own class,
so you can't write a strict type signature, such as `Union[str,
NotGivenType]`.

Another issue is that having these objects be classes, rather than
normal instances of classes, could be surprising and confusing.

For those two reasons, for now, I think generating a unique object
with its own unique class is preferable.

> Sorry about my detour into the rejected idea of a factory function.

Please don't apologize! I put those ideas in the "Rejected Ideas"
section mostly to have them written down with a summary of the
considerations related to them. They shouldn't be considered finally
rejected unless and until the PEP is finished and accepted.

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

[Python-Dev] Re: Question for potential python development contributions on Windows

[pjfarley3]

> From: Łukasz Langa  
> Sent: Monday, May 24, 2021 4:37 AM
> To: pjfarl...@earthlink.net
> Cc: python-dev@python.org
> Subject: Re: [Python-Dev] Question for potential python development 
> contributions on Windows
>
> > On 20 May 2021, at 07:03, mailto:pjfarl...@earthlink.net wrote:
> > 
> > The Python Developers Guide specifically states to get VS2017 for 
> > developing or enhancing python on a Windows system.
> >  
> > Is it still correct to specifically use VS2017 , or is VS2019 also 
> > acceptable?
>
> We have to update the devguide. VS 2019 is supported, probably even 
> recommended, as long as the C++ tools are v14.x.

Thank you Łukasz, I was hoping that would be the answer.

How does one verify whether the C++ tools are 14.x, or is that just the usual 
for recent versions of VS2019?

Peter

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

[Python-Dev] Re: GDB not breaking at the right place

[Victor Stinner]

"Debugging" means many things. Python is built with -Og because it
makes Python faster than -O0, and most developers debug Python code,
not C code (in gdb).

If you don't need to go up to the gdb/lldb level, -Og is fine.

It would even make sense to build Python with -O3 in debug mode if you
don't debug C code at all, only pure Python code.

My proposition to switch to -00 by default was rejected:
https://bugs.python.org/issue38350

I also love -O0 when I modify C code because it makes the build faster ;-)

Fedora Python debug builds are now built with -O0 which makes gdb a
way more pleasant experience, not more strange behavior with inlined
code or "" local variables or function arguments.

Victor

On Sun, May 23, 2021 at 3:57 PM Skip Montanaro  wrote:
>
> > I strongly suggest to only build Python with -O0 when using gdb. -Og
> > enables too many optimizations which makes gdb less usable.
>
> Thanks, Victor. It never made sense to me that you would want any
> optimizations enabled when truly debugging code (as opposed to wanting
> debug symbols and a sane traceback in production code).
>
> I'm getting more convinced that the problem I'm seeing is a GCC/GDB
> thing, particularly because I can move the erroneous stopping point by
> changing the GCC optimization level. I'll probably open a bugzilla
> report just so it's on that team's radar screen. In the meantime, to
> get going again I wrote a crude script which maps the
> file:function:label form to file:linenumber form. That way I can
> save/restore breakpoints across GDB sessions and still avoid problems
> when the offsets to specific instructions change.
>
> Skip
>
> Skip



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/FPWJHHV55JPF6ZQVI2OGMYSIPYN3AXH2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Question for potential python development contributions on Windows

[Chris Angelico]

On Mon, May 24, 2021 at 6:40 PM Łukasz Langa  wrote:
>
>
> On 20 May 2021, at 07:03, pjfarl...@earthlink.net wrote:
>
> The Python Developers Guide specifically states to get VS2017 for developing 
> or enhancing python on a Windows system.
>
> Is it still correct to specifically use VS2017 , or is VS2019 also acceptable?
>
>
> We have to update the devguide. VS 2019 is supported, probably even 
> recommended, as long as the C++ tools are v14.x.
>

Also of note is this page:

https://wiki.python.org/moin/WindowsCompilers

It lists Visual Studio versions for different Python versions (for
compiling extensions), but it stops at 3.8.

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

[Python-Dev] Re: Question for potential python development contributions on Windows

[Łukasz Langa]

> On 20 May 2021, at 07:03, pjfarl...@earthlink.net wrote:
> 
> The Python Developers Guide specifically states to get VS2017 for developing 
> or enhancing python on a Windows system.
> 
> Is it still correct to specifically use VS2017 , or is VS2019 also acceptable?

We have to update the devguide. VS 2019 is supported, probably even 
recommended, as long as the C++ tools are v14.x.

Cheers,
Łukasz


signature.asc
Description: Message signed with OpenPGP
___
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/UCSCYMMJA4UBBUZLUHSEOE2POEBNTKLF/
Code of Conduct: http://python.org/psf/codeofconduct/