[Python-Dev] Re: Descriptions in unittest and avoiding confusion

[Coyot Linden (Glenn Glazer)]

I would like to point out another use case of triple quotes outside of 
docstrings. We do a lot of SQL here and so doing a parameterized query like:


"""SELECT foo
FROM bar
WHERE baz = %s"""

is a whole lot cleaner and more natural than

("SELECT foo" +
"FROM bar" +
"WHERE baz = %s")

For this toy example, one could just put it all on one line, but for 
rather more complicated SQL, it becomes a readability (and thus 
maintainability) factor to preserve SQL's one keyword per line 
formatting. So, yes, all of our SQL statements wind up in the parse tree 
and that's not optimal, but the suboptimality there is less for us than 
the suboptimality of the second form above.


I would welcome a multiline comment format that didn't involve docstrings.

Best,

coyot
___
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/6MKP4IR5STLNDPZKU6H5AVTZ7F3XAHYX/
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

[Petr Viktorin]

On 03. 02. 22 1:40, Guido van Rossum wrote:
[...]


I understand the CPython is stuck supporting the de-facto standard C API 
for a long time. But unless we pick a "north star" (as people call it 
nowadays) of what we want to support in say 5-10 years, the situation 
will never improve.


My point about "getting one chance to get it right in the next decade" 
is that we have to pick that north star, so we can tell users which 
horse to bet on. If the north star we pick is HPy, things will be clear. 
If it is evolving the C API things will also be clear. But I think we 
have to pick one, and stick to it so users (i.e., package 
maintainers/developers) have clarity.


A few months later, here's a draft of a “north star” document.
Is this close to what you had in mind?

https://docs.google.com/document/d/1lrvx-ujHOCuiuqH71L1-nBQFHreI8jsXC966AFu9Mqc/edit#


Please comment (here or there) as appropriate :)
___
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/DUWBMGLEYP6VFFT7OMMA6KJNJKTEY47R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Descriptions in unittest and avoiding confusion

[Coyot Linden (Glenn Glazer)]

I would welcome a multiline comment format that didn't involve docstrings.


Err, sorry, I meant multiline string format.

Best,

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

[Python-Dev] Re: Descriptions in unittest and avoiding confusion

[Paul Moore]

On Mon, 4 Apr 2022 at 17:22, Coyot Linden (Glenn Glazer)
 wrote:
> > I would welcome a multiline comment format that didn't involve docstrings.
>
> Err, sorry, I meant multiline string format.

I'm confused, what's wrong with """..."""? Triple quoted strings are
not exclusively for docstrings...
Paul
___
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/OZ267ZAGWAMCC5WVMQX7TH2DYKNZBTVT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Descriptions in unittest and avoiding confusion

[Coyot Linden (Glenn Glazer)]

On 4/4/22 09:25, Paul Moore wrote:

On Mon, 4 Apr 2022 at 17:22, Coyot Linden (Glenn Glazer)
 wrote:

I would welcome a multiline comment format that didn't involve docstrings.

Err, sorry, I meant multiline string format.

I'm confused, what's wrong with """..."""? Triple quoted strings are
not exclusively for docstrings...
Paul


That isn't my reading of PEP 257, I would be happy to be wrong about this.

Best,

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

[Python-Dev] Re: Descriptions in unittest and avoiding confusion

[Terry Reedy]

On 4/4/2022 11:07 AM, Coyot Linden (Glenn Glazer) wrote:
I would like to point out another use case of triple quotes outside of 
docstrings.


A docstring is *any* string literal, regardless of quotes, that is a 
statement in itself and is the *first* statement in the body of a 
module, class, or function.  Triple quotes are routinely used for 
multiline strings elsewhere.


We do a lot of SQL here and so doing a parameterized query 
like:



"""SELECT foo
FROM bar
WHERE baz = %s"""


Others do the same.  To be useful, you have to either bind the query 
string to something for use later


query = """query string"""

or immediately use it in an expression

cursor = """SELECT %s"" % 'abc'

In neither case will it be interpreted as a docstring.


I would welcome a multiline comment format that didn't involve docstrings.


Some people already use multiline strings for that, in positions where 
they do not become the docstring.  At least in CPython, comment strings, 
at least in functions, appear to be omitted from the code object.


def f():
'docstring'
'other string'

fc = f.__code__

fc.co_consts
# ('docstring', None)  # 'other string' absent.

import dis
dis.dis(f)  # 'other string not loaded from anywhere else.
#  1   0 RESUME   0
#
#  3   2 LOAD_CONST   1 (None)
#  4 RETURN_VALUE


--
Terry Jan Reedy

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

[Python-Dev] Re: Descriptions in unittest and avoiding confusion

[Steven D'Aprano]

On Mon, Apr 04, 2022 at 09:27:46AM -0700, Coyot Linden (Glenn Glazer) wrote:
> On 4/4/22 09:25, Paul Moore wrote:
> >On Mon, 4 Apr 2022 at 17:22, Coyot Linden (Glenn Glazer)
> > wrote:
> >>>I would welcome a multiline comment format that didn't involve 
> >>>docstrings.
> >>Err, sorry, I meant multiline string format.
> >I'm confused, what's wrong with """..."""? Triple quoted strings are
> >not exclusively for docstrings...
> >Paul
> 
> That isn't my reading of PEP 257, I would be happy to be wrong about this.

PEP 257 says that all docstrings should use triple quotes. It doesn't 
say that *only* docstrings should use triple quotes.


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

[Python-Dev] Re: Descriptions in unittest and avoiding confusion

[Guido van Rossum]

"Well, that escalated quickly." :-)

How did we get from a specific issue with docstrings and the unittest
package's test reporting to multi-line comments? If this was Discourse that
entire subdiscussion would have been flagged as off-topic and moved to its
own thread.

On Mon, Apr 4, 2022 at 10:12 AM Steven D'Aprano  wrote:

> On Mon, Apr 04, 2022 at 09:27:46AM -0700, Coyot Linden (Glenn Glazer)
> wrote:
> > On 4/4/22 09:25, Paul Moore wrote:
> > >On Mon, 4 Apr 2022 at 17:22, Coyot Linden (Glenn Glazer)
> > > wrote:
> > >>>I would welcome a multiline comment format that didn't involve
> > >>>docstrings.
> > >>Err, sorry, I meant multiline string format.
> > >I'm confused, what's wrong with """..."""? Triple quoted strings are
> > >not exclusively for docstrings...
> > >Paul
> >
> > That isn't my reading of PEP 257, I would be happy to be wrong about
> this.
>
> PEP 257 says that all docstrings should use triple quotes. It doesn't
> say that *only* docstrings should use triple quotes.
>
>
> --
> Steve
> ___
> 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/3ULX4QF5WF6WBFT3KIIPXS2UI7OZUKRF/
> 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/3BZHMFATRS432LE66XKBMUSRJTKYBTAS/
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

[Terry Reedy]

On 4/4/2022 11:19 AM, Petr Viktorin wrote:

On 03. 02. 22 1:40, Guido van Rossum wrote:
[...]


I understand the CPython is stuck supporting the de-facto standard C 
API for a long time. But unless we pick a "north star" (as people call 
it nowadays) of what we want to support in say 5-10 years, the 
situation will never improve.


My point about "getting one chance to get it right in the next decade" 
is that we have to pick that north star, so we can tell users which 
horse to bet on. If the north star we pick is HPy, things will be 
clear. If it is evolving the C API things will also be clear. But I 
think we have to pick one, and stick to it so users (i.e., package 
maintainers/developers) have clarity.


A few months later, here's a draft of a “north star” document.
Is this close to what you had in mind?

https://docs.google.com/document/d/1lrvx-ujHOCuiuqH71L1-nBQFHreI8jsXC966AFu9Mqc/edit# 


"[There is a proposal for an additional “unstable” ring for even deeper 
integration -- compilers/debuggers. I'm listing it here even though it's 
not status quo :)]


Private API -- internal use only (with specific exceptions)"

The Private API is the unstable ring, subject to change each bug-fix 
release.  The proposal is for a semi-stable ring, stable for each 
version.  I agree that 'Semi-public' would be a good name.


"(with specific exceptions)" seems like a rough edge.  Would most (all?) 
exceptions go in the Semi-public ring?


It seems to me that a big driver for this discussion is the current push 
to get Python-level results much faster, which most people agree is a 
good thing.  That requires eliminating duplication, doing some thing 
faster, and somethings not at all.  That in turn requires revising 
internal structures along with code paths.  And that in turn requires 
revision of external code deeply integrated with the core.  I think it 
worth making it clear that the resulting pain is needed for something 
that benefits most Python users.


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

[Python-Dev] Re: Descriptions in unittest and avoiding confusion

[Coyot Linden (Glenn Glazer)]

  
  

  "Well, that escalated quickly." :-)
  
  
  
  How did we get from a specific issue with docstrings and the
unittest package's test reporting to multi-line comments? If
this was Discourse that entire subdiscussion would have been
flagged as off-topic and moved to its own thread.


Apologies, as I said earlier, I meant to write multiline string,
not multiline comment and it wasn't my intention to derail
the thread but rather provide a different use case for multiline
strings which seems, TIL, to be the accepted usage. 

So I thank the community for that input and will refrain from
commenting further on this.

Best,

coyot
  

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

[Python-Dev] Re: Descriptions in unittest and avoiding confusion

[Ethan Furman]

On 4/4/22 10:52, Coyot Linden (Glenn Glazer) wrote:
> On 4/4/22 Guido wondered:

>> How did we get from a specific issue with docstrings and the unittest 
package's test
>> reporting to multi-line comments?
>
> Apologies, as I said earlier, I meant to write multiline /string/, not 
multiline /comment/
> and it wasn't my intention to derail the thread but rather provide a 
different use case for
> multiline strings which seems, TIL, to be the accepted usage.

Guido's point is that your concern is completely unrelated to the unittest docstring display issue, and should have been 
a new thread.


But, hey, we all make mistakes sometimes.  :-)

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

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

[Gregory P. Smith]

On Fri, Apr 1, 2022 at 2:06 AM Victor Stinner  wrote:

> Hi,
>
> Update on this issue: I merged my 2 PRs.
> https://bugs.python.org/issue46850
>
> The following APIs have been moved to the internal C API:
>
> - _PyFrameEvalFunction type
> - _PyInterpreterState_GetEvalFrameFunc()
> - _PyInterpreterState_SetEvalFrameFunc()
> - _PyEval_EvalFrameDefault()
>
> If you use any of these API in your debugger/profiler project, you
> have do add something like the code below to your project:
> ---
> #ifndef Py_BUILD_CORE_MODULE
> #  define Py_BUILD_CORE_MODULE
> #endif
> #include 
> #if PY_VERSION_HEX >= 0x030B00A7
> #  include  //
> _PyInterpreterState_SetEvalFrameFunc()
> #  include   // _PyEval_EvalFrameDefault()
> #endif
> ---
>
> Contact me if you need help to update your affected projects.
>
> IMO PEP 523 doesn't have to be updated since it already says that the
> APIs are private.
>

Thanks for bringing this up on python-dev, Victor. That was good. But the
point of the discussion should've been to continue working with people
based on the replies rather than proceeding to merge removals of the APIs
after people said they used them.  (echoing Steve and Petr here...)

We discussed this on the steering council today. These APIs were in a weird
state and despite past decisions at the time of PEP-523
 in 2016 they should be treated as
public-ish rather than entirely private. Because we published a document
saying "here they are, use them!" and multiple projects have done so to
good effect.

For 3.11 we'd like those PRs reverted.  We see the following as the better
way forward for these APIs:

Add a new #define that can be set before the #include  that
exposes non-limited but stable within a bugfix/patch releases APIs (ie:
Petr's earlier suggestion).
These would be the first to fall within. To do so we should give these,
behind that #define, non _-prefixed "public style" names as these are
quasi-public and cannot be changed as readily as other true internals.  We
still, per the PEP, reserve the right to turn these into no-op potentially
warning setting APIs in a future release (likely 3.12?) as they are at
least documented as being unstable/private in the PEP.

So in 3.11 these should continue to exist as in 3.6-3.10:
- _PyFrameEvalFunction type
- _PyInterpreterState_GetEvalFrameFunc()
- _PyInterpreterState_SetEvalFrameFunc()
- _PyEval_EvalFrameDefault()

AND in 3.11:
 - #define protected versions of those without the leading _ become
available.
 - (i'm intentionally not suggesting a #define name, y'all can pick
something)

In 3.12:
 - the _ prefixed versions can go away.  People using the APIs should've
updated their code to use the new #define and new names when building
against >=3.11 by then.
 - Whether the APIs continue to be as useful and act as originally claimed
in PEP 523 is up to the 3.12 implementors (out of scope for this thread).
They occupy a newly defined middle ground between the "forever" style
limited API and the "can break even on bugfix/patch release" internal API
that wasn't a concept for us in 2016 when PEP 523 was written.

Why? Being conservative with things in active use that weren't *really*
private, and similar to what Mark Shannon and Petr said, we *do not* want
people to #define Py_BUILD_CORE_MODULE and start poking at internals in
arbitrary ways. That exposes a whole pile of other things for (ab)use that
are even more unstable. Avoiding that helps avoid temptation to go wild and
helps us identify users.

-gps (steering council hat on)


> Since these APIs were added by PEP 523, I documented these changes in
> What's New in Python 3.11 > C API > Porting to Python 3.11,even if
> these APIs are private.
>
> Victor
> --
> 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/DNJC6U36CDA7S7ATEGAMUPABBSEIYHC4/
> 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/GFOMU7LP63JUVFMWNJNZJLUMZDRPTUYJ/
Code of Conduct: http://python.org/psf/codeofconduct/