[Python-Dev] C trace after start runtime

[Leandro Müller]

Hello.
I need to start C trace the thread after to start, its to reduce of the time of 
the process.
I had a lot performance changes sys.trace to C trace, but I need to reduce more 
time.

Are there any soluction to set trace during thead runtime?


Att.
Leandro Müller
___
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/G3IPGNHDQ2DNJY2CLAIAGN2GREDMGFCW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[senthil]

On Sun, Mar 22, 2020 at 05:00:10AM -, Dennis Sweeney wrote:
> I like "removeprefix" and "removesuffix". My only concern before had
> been length, but three more characters than "cut***fix" is a small
> price to pay for clarity.

I personally rely on auto-complete of my editor while writing. So,
thinking about these these methods in "correct" terms might be more
important to me that the length.

+1 for removeprefix and removesuffix.

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

[Python-Dev] Clean memory on C trace

[Leandro Müller]

Hi.

I need to clean memory on function on PyEval_SetTrace.
When the python code run a while test, the memory consumption goes up a lot 
(99% of the system).
exemple:
while 1 == 1:
 pass

My trace function is simple.

static map session_debug_user;
char *user_console;

int trace_trampoline(
PyObject *obj, PyFrameObject *frame, int event, PyObject *arg)
{
try
{
//check if user has debug session
if (session_debug_user.count(user_console) == 0)
{
return 0;
}
  return 0;
}

PyObject *sys_settrace(PyObject *mod, PyObject *obj)
{
user_console = get_variable_char(obj, 0);
PyEval_SetTrace(trace_trampoline, obj);
return Py_None;
}


[cid:607bbc5e-5dd8-4a8b-ad96-dc31dce274a9]


Att.

Leandro Müller
___
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/AZEYSU733IWYCPVID2BABY2K33QGUHFP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: sys.trace without alert or remove trace by C

[Leandro Müller]

Hello Victor.
Thank you.
The tips help me a lot.
I think the tip needs to stay inside on document to reduce time to seach 
soluction.
Thanks.

Att.
Leandro Müller

De: Victor Stinner 
Enviado: Thursday, March 26, 2020 7:08:42 PM
Para: Leandro Müller 
Cc: python-dev@python.org 
Assunto: Re: [Python-Dev] sys.trace without alert or remove trace by C

Hi,

I understand that you are looking for PyEval_SetTrace(NULL, NULL) to
unregister a trace function set previously.

Maybe the documentation should be enhanced to explain that. Do you
want to propose a PR to enhance the doc?

https://docs.python.org/dev/c-api/init.html?highlight=pyeval_settrace#c.PyEval_SetTrace

Victor

Le jeu. 26 mars 2020 à 22:47, Leandro Müller
 a écrit :
>
> Hello.
> I need to remove the trace on thread, but I tried to run sys.settrace(None) 
> and return alert on console.
> I didn't find any soluction to remove by C, example PyEval_SetTrace(Py_None, 
> obj), but it not works.
>
> Are there any soluction to remove without alert or by C?
> C is better for me.
>
> Thanks.
>
> Att.
>
> Leandro Müller
>
> ___
> 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/HJNC3UOXDBOYF6XJ3MFJX647WKCICK7P/
> Code of Conduct: http://python.org/psf/codeofconduct/



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

[Python-Dev] Re: The Python 2 death march

[Sumana Harihareswara]

Benjamin: now that PyCon 2020 has been cancelled, are you considering 
releasing 2.7.18 slightly earlier?

--
Sumana Harihareswara
Changeset Consulting
https://changeset.nyc
___
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/MXUUU5FBELEXNCTXLIDP633XTIRXG6W4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Steve Holden]

On Wed, Mar 25, 2020 at 5:42 PM Dennis Sweeney 
wrote:

> I'm removing the tuple feature from this PEP. So now, if I understand
> correctly, I don't think there's disagreement about behavior, just about
> how that behavior should be summarized in Python code.
> [...]
> return (the original object unchanged, or a copy of the object,
> depending on implementation details,
> but always make a copy when working with subclasses)
>
> is well-summarized by
>
>return self[:]
>
> especially if followed by the text
>
> Note that ``self[:]`` might not actually make a copy -- if the affix
> is empty or not found, and if ``type(self) is str``, then these methods

may, but are not required to, make the optimization of returning
> ``self``.
> However, when called on instances of subclasses of ``str``, these
> methods should return base ``str`` objects, not ``self``.
>
> Perhaps:

Note that ``self[:]`` might not actually make a copy of ``self``.
If the affix is empty or not found, and if ``type(self)`` is immutable,
then these methods may, but are not required to, make the
optimization of returning ``self``. ...

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

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2020-03-20 - 2020-03-27)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7357 ( -1)
  closed 44486 (+66)
  total  51843 (+65)

Open issues with patches: 2882 


Issues opened (43)
==

#20526: python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)
https://bugs.python.org/issue20526  reopened by vstinner

#36759: astimezone() fails on Windows for pre-epoch times
https://bugs.python.org/issue36759  reopened by SilentGhost

#40028: Math module method to find prime factors for non-negative int 
https://bugs.python.org/issue40028  opened by trrhodes

#40031: Python Configure IDLE 'Ok' and 'Apply' buttons do not seem to 
https://bugs.python.org/issue40031  opened by Vader27

#40034: cgi.parse() does not work with multipart POST requests.
https://bugs.python.org/issue40034  opened by sangh

#40038: pathlib: remove partial support for preserving accessor when m
https://bugs.python.org/issue40038  opened by barneygale

#40042: Enum Flag: psuedo-members have None for name attribute
https://bugs.python.org/issue40042  opened by ethan.furman

#40045: Make "dunder" method documentation easier to locate
https://bugs.python.org/issue40045  opened by aeros

#40048: _PyEval_EvalFrameDefault() doesn't reset tstate->frame if _PyC
https://bugs.python.org/issue40048  opened by vstinner

#40049: tarfile cannot extract from stdin
https://bugs.python.org/issue40049  opened by dtamuc

#40051: Dead link in help(lib2to3)
https://bugs.python.org/issue40051  opened by wyz23x2

#40052: Incorrect pointer alignment in _PyVectorcall_Function() of cpy
https://bugs.python.org/issue40052  opened by asn

#40055: test___all__ and test_distutils alters the enviroinment: pkg_r
https://bugs.python.org/issue40055  opened by vstinner

#40056: more user-friendly turtledemo
https://bugs.python.org/issue40056  opened by Evin Liang

#40057: Missing mention of some class attributes in socketserver docum
https://bugs.python.org/issue40057  opened by overmighty

#40058: Running test_datetime twice fails with: module 'datetime' has 
https://bugs.python.org/issue40058  opened by vstinner

#40059: Provide a toml module in the standard library
https://bugs.python.org/issue40059  opened by mgorny

#40060: socket.TCP_NOTSENT_LOWAT is missing in official macOS builds
https://bugs.python.org/issue40060  opened by Dima.Tisnek

#40061: Possible refleak in _asynciomodule.c future_add_done_callback(
https://bugs.python.org/issue40061  opened by aeros

#40064: py38: document xml.etree.cElementTree will be removed in 3.9
https://bugs.python.org/issue40064  opened by fdrake

#40065: py39: remove deprecation note for xml.etree.cElementTree
https://bugs.python.org/issue40065  opened by fdrake

#40066: Enum._convert should change __repr__ and/or __str__ to use mod
https://bugs.python.org/issue40066  opened by ethan.furman

#40068: test_threading: ThreadJoinOnShutdown.test_reinit_tls_after_for
https://bugs.python.org/issue40068  opened by vstinner

#40070: GCC crashed on AMD64 RHEL7 LTO + PGO 3.7 (compiler bug)
https://bugs.python.org/issue40070  opened by vstinner

#40071: test__xxsubinterpreters  leaked [1, 1, 1] references: test_ids
https://bugs.python.org/issue40071  opened by vstinner

#40072: Win7/Python3.8/asyncio IPv6 UDP Server raise OSError when recv
https://bugs.python.org/issue40072  opened by honglei.jiang

#40073: AIX: python3 points to "air"
https://bugs.python.org/issue40073  opened by Michael.Felt

#40074: pickle module dump and load: add support for string file names
https://bugs.python.org/issue40074  opened by Diego Palacios

#40075: _tkinter PythonCmd fails to acquire GIL
https://bugs.python.org/issue40075  opened by speleo3

#40077: Convert static types to PyType_FromSpec()
https://bugs.python.org/issue40077  opened by corona10

#40078: asyncio subprocesses allow pids to be reaped, different behavi
https://bugs.python.org/issue40078  opened by Justin.Lebar

#40079: NULL pointer deref on error path in _ssl debughelpers.c
https://bugs.python.org/issue40079  opened by Alexander Riccio

#40082: Assertion failure in trip_signal
https://bugs.python.org/issue40082  opened by Alexander Riccio

#40083: No run option available in python idle in version 3.8.2
https://bugs.python.org/issue40083  opened by Raj_110

#40084: HTTPStatus has incomplete dir() listing
https://bugs.python.org/issue40084  opened by rhettinger

#40085: Argument parsing option c should accept int between -128 to 25
https://bugs.python.org/issue40085  opened by tzickel

#40086: test_etree is skipped in test_typing due to cElementTree remov
https://bugs.python.org/issue40086  opened by xtreak

#40087: How to Uninstall Python3.7.3 using cmd?
https://bugs.python.org/issue40087  opened by deepaleedotkh...@gmail.com

#40088: list.reverse(): slow sublist reverse
https://bugs.python.org/issue40088  opened by Yury

#40089:

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Dennis Sweeney]

I appreciate the input and attention to detail!

Using the ``str()`` constructor was sort of what I had thought originally, and 
that's why I had gone overboard with "casting" in one iteration of the sample 
code. When I realized that this isn't quite "casting" and that ``__str__`` can 
be overridden, I went even more overboard and suggested that 
``str.__getitem__(self, ...)`` and ``str.__len__(self)`` could be written, 
which does have the behavior of effectively "casting", but looks nasty. Do you 
think that the following is a happy medium?

def removeprefix(self: str, prefix: str, /) -> str:
# coerce subclasses to str
self_str = str(self)
prefix_str = str(prefix)
if self_str.startswith(prefix_str):
return self_str[len(prefix_str):]
else:
return self_str

def removesuffix(self: str, suffix: str, /) -> str:
# coerce subclasses to str
self_str = str(self)
suffix_str = str(suffix)
if suffix_str and self_str.endswith(suffix_str):
return self_str[:-len(suffix_str)]
else:
return self_str

Followed by the text:

If ``type(self) is str`` (rather than a subclass) and if the given affix is 
empty or is not found, then these methods may, but are not required to, make 
the optimization of returning ``self``.
___
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/W6DMWMSF22HPKG6MYYCXQ6QE7QIWBNSI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Dennis Sweeney]

I was trying to start with the the intended behavior of the str class, then 
move on to generalizing to other classes, because I think completing a single 
example and *then* generalizing is an instructional style that's easier to 
digest, whereas intermixing all of the examples at once can get confused (can I 
call str.removeprefix(object(), 17)?). Is something missing that's not already 
there in the following sentence in the PEP?

Although the methods on the immutable ``str`` and ``bytes`` types may make the 
aforementioned optimization of returning the original object, 
``bytearray.removeprefix()`` and ``bytearray.removesuffix()`` should always 
return a copy, never the original object.

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

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Guido van Rossum]

How about just presenting pseudo code with the caveat that that's for the
base str and bytes classes only, and then stipulating that for subclasses
the return value is still a str/bytes/bytearray instance, and leaving it at
that? After all the point of the Python code is to show what the C code
should do in a way that's easy to grasp -- giving a Python implementation
is not meant to constrain the C implementation to have *exactly* the same
behavior in all corner cases (since that would lead to seriously contorted
C code).

On Fri, Mar 27, 2020 at 1:02 PM Dennis Sweeney 
wrote:

> I was trying to start with the the intended behavior of the str class,
> then move on to generalizing to other classes, because I think completing a
> single example and *then* generalizing is an instructional style that's
> easier to digest, whereas intermixing all of the examples at once can get
> confused (can I call str.removeprefix(object(), 17)?). Is something missing
> that's not already there in the following sentence in the PEP?
>
> Although the methods on the immutable ``str`` and ``bytes`` types may make
> the aforementioned optimization of returning the original object,
> ``bytearray.removeprefix()`` and ``bytearray.removesuffix()`` should always
> return a copy, never the original object.
>
> Best,
> Dennis
> ___
> 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/IO33NJUQTN27TU342NAJAAMR7YGEPQRE/
> 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/RTK46ZXQYPWVRJIWPAD3EXTJBSU27VKF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Dennis Sweeney]

I like how that would take the pressure off of the Python sample. How's 
something like this?

Specification
=

The builtin ``str`` class will gain two new methods which will behave
as follows when ``type(self) is str``::

def removeprefix(self: str, prefix: str, /) -> str:
if self.startswith(prefix):
return self[len(prefix):]
else:
return self

def removesuffix(self: str, suffix: str, /) -> str:
if suffix and self.endswith(suffix):
return self[:-len(suffix)]
else:
return self

These methods, even when called on ``str`` subclasses, should always
return base ``str`` objects.  One should not rely on the behavior
of ``self`` being returned (as in ``s.removesuffix('') is s``) -- this
optimization should be considered an implementation detail.  To test
whether any affixes were removed during the call, one may use the
constant-time behavior of comparing the lengths of the original and
new strings::

>>> string = 'Python String Input'
>>> new_string = string.removeprefix('Py')
>>> modified = (len(string) != len(new_string))
>>> modified
True

One may also continue using ``startswith()`` and ``endswith()``
methods for control flow instead of testing the lengths as above.

Note that without the check for the truthiness of ``suffix``,
``s.removesuffix('')`` would be mishandled and always return the empty
string due to the unintended evaluation of ``self[:-0]``.

Methods with the corresponding semantics will be added to the builtin
``bytes`` and ``bytearray`` objects.  If ``b`` is either a ``bytes``
or ``bytearray`` object, then ``b.removeprefix()`` and ``b.removesuffix()``
will accept any bytes-like object as an argument.  Although the methods
on the immutable ``str`` and ``bytes`` types may make the aforementioned
optimization of returning the original object, ``bytearray.removeprefix()``
and ``bytearray.removesuffix()`` should *always* return a copy, never the
original object.

The two methods will also be added to ``collections.UserString``, with
similar behavior.

My hesitation to write "return self" is resolved by saying that it should not 
be relied on, so I think this is a win.

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

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Guido van Rossum]

On Fri, Mar 27, 2020 at 1:55 PM Dennis Sweeney 
wrote:

> I like how that would take the pressure off of the Python sample. How's
> something like this?
>
> Specification
> =
>
> The builtin ``str`` class will gain two new methods which will behave
> as follows when ``type(self) is str``::
>
> def removeprefix(self: str, prefix: str, /) -> str:
> if self.startswith(prefix):
> return self[len(prefix):]
> else:
> return self
>
> def removesuffix(self: str, suffix: str, /) -> str:
> if suffix and self.endswith(suffix):
> return self[:-len(suffix)]
> else:
> return self
>
> These methods, even when called on ``str`` subclasses, should always
> return base ``str`` objects.  One should not rely on the behavior
> of ``self`` being returned (as in ``s.removesuffix('') is s``) -- this
> optimization should be considered an implementation detail.
>

I'd suggest to drop the last sentence ("One should ... detail.") and
instead write 'return self[:]' in the methods.


> To test
> whether any affixes were removed during the call, one may use the
> constant-time behavior of comparing the lengths of the original and
> new strings::
>
> >>> string = 'Python String Input'
> >>> new_string = string.removeprefix('Py')
> >>> modified = (len(string) != len(new_string))
> >>> modified
> True
>

If I saw that in a code review I'd flag it for non-obviousness. One should
use 'string != new_string' *unless* there is severe pressure to squeeze
every nanosecond out of this particular code (and it better be inside an
inner loop).


> One may also continue using ``startswith()`` and ``endswith()``
> methods for control flow instead of testing the lengths as above.
>

That's worse, in a sense, since "foofoobar".removeprefix("foo") returns
"foobar" which still starts with "foo".

Note that without the check for the truthiness of ``suffix``,
> ``s.removesuffix('')`` would be mishandled and always return the empty
> string due to the unintended evaluation of ``self[:-0]``.
>

That's a good one (I started suggesting dropping that when I read this :-)
but maybe it ought to go in a comment (and shorter -- at most one line).


> Methods with the corresponding semantics will be added to the builtin
> ``bytes`` and ``bytearray`` objects.  If ``b`` is either a ``bytes``
> or ``bytearray`` object, then ``b.removeprefix()`` and
> ``b.removesuffix()``
> will accept any bytes-like object as an argument.  Although the methods
> on the immutable ``str`` and ``bytes`` types may make the
> aforementioned
> optimization of returning the original object,
> ``bytearray.removeprefix()``
> and ``bytearray.removesuffix()`` should *always* return a copy, never
> the
> original object.
>

This could also be simplified by writing 'return self[:]'.


> The two methods will also be added to ``collections.UserString``, with
> similar behavior.
>
> My hesitation to write "return self" is resolved by saying that it should
> not be relied on, so I think this is a win.
>

Writing 'return self[:]' seems to say the same thing in fewer words though.
:-)

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

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Dennis Sweeney]

> > One may also continue using ``startswith()``
> > and ``endswith()``
> > methods for control flow instead of testing the lengths as above.
> > 
> > That's worse, in a sense, since "foofoobar".removeprefix("foo") returns
> "foobar" which still starts with "foo".

I meant that startswith might be called before removeprefix, as it was 
in the ``deccheck.py`` example.

> If I saw that in a code review I'd flag it for non-obviousness. One should
> use 'string != new_string' unless there is severe pressure to squeeze
> every nanosecond out of this particular code (and it better be inside an
> inner loop).

I thought that someone had suggested that such things go in the PEP, but 
since these are more stylistic considerations, I would be more than happy to
trim it down to just

The builtin ``str`` class will gain two new methods which will behave
as follows when ``type(self) is type(prefix) is str``::

def removeprefix(self: str, prefix: str, /) -> str:
if self.startswith(prefix):
return self[len(prefix):]
else:
return self[:]

def removesuffix(self: str, suffix: str, /) -> str:
# suffix='' should not call self[:-0].
if suffix and self.endswith(suffix):
return self[:-len(suffix)]
else:
return self[:]

These methods, even when called on ``str`` subclasses, should always
return base ``str`` objects.

Methods with the corresponding semantics will be added to the builtin
``bytes`` and ``bytearray`` objects.  If ``b`` is either a ``bytes``
or ``bytearray`` object, then ``b.removeprefix()`` and ``b.removesuffix()``
will accept any bytes-like object as an argument. The two methods will
also be added to ``collections.UserString``, with similar behavior.
___
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/HQRI26F6UPWL24LJOFFMKNAMYJSC2CAL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Guido van Rossum]

On Fri, Mar 27, 2020 at 3:29 PM Dennis Sweeney 
wrote:

> > > One may also continue using ``startswith()``
> > > and ``endswith()``
> > > methods for control flow instead of testing the lengths as above.
> > >
> > > That's worse, in a sense, since "foofoobar".removeprefix("foo") returns
> > "foobar" which still starts with "foo".
>
> I meant that startswith might be called before removeprefix, as it was
> in the ``deccheck.py`` example.
>

Not having read the full PEP, that wasn't clear to me. Sorry!


> > If I saw that in a code review I'd flag it for non-obviousness. One
> should
> > use 'string != new_string' unless there is severe pressure to squeeze
> > every nanosecond out of this particular code (and it better be inside an
> > inner loop).
>
> I thought that someone had suggested that such things go in the PEP,


I'm sure someone did. But not every bit of feedback is worth acting upon,
and sometimes a weird compromise is cooked up that addresses somebody's nit
while making things less understandable for everyone else. I think this is
one of those cases.


> but
> since these are more stylistic considerations, I would be more than happy
> to
> trim it down to just
>
> The builtin ``str`` class will gain two new methods which will behave
> as follows when ``type(self) is type(prefix) is str``::
>
> def removeprefix(self: str, prefix: str, /) -> str:
> if self.startswith(prefix):
> return self[len(prefix):]
> else:
> return self[:]
>
> def removesuffix(self: str, suffix: str, /) -> str:
> # suffix='' should not call self[:-0].
> if suffix and self.endswith(suffix):
> return self[:-len(suffix)]
> else:
> return self[:]
>
> These methods, even when called on ``str`` subclasses, should always
> return base ``str`` objects.
>
> Methods with the corresponding semantics will be added to the builtin
> ``bytes`` and ``bytearray`` objects.  If ``b`` is either a ``bytes``
> or ``bytearray`` object, then ``b.removeprefix()`` and
> ``b.removesuffix()``
> will accept any bytes-like object as an argument. The two methods will
> also be added to ``collections.UserString``, with similar behavior.
>

Excellent!

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

[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name

[Ivan Pozdeev via Python-Dev]

On 26.03.2020 19:24, Ethan Furman wrote:

On 03/25/2020 06:53 PM, Ivan Pozdeev via Python-Dev wrote:


A diagnostic is always done by the same algorithm:

1) Identify the exact place in code where the problem manifests itself
2) Examine the state of the program at that moment to find out which if the 
values are wrong
3) Track the wrong value back to its origin

Seeing an accurate repr() is required for step 2) -- to immediately detect if 
it's wrong or not.


Before Enum, the repr for socket.AF_UNIX was:

1

Not very useful for debugging.


On the contrary, it's perfect. I know everything I need: it's an integer 
constant, end of story.

When examining some live object, I would probably see that "1" and won't even 
need to look anything up to know what I'm dealing with.



If a repr() points to a reference rather than definition, I don't really know anything about the object that I'm looking at: that 
reference could as well be wrong, or could have been wrong at any moment in the past. I.e. such a repr() has negative informativity.


Whether it's

  

or

  

it has light-years more information than it used to  (okay, maybe only 
light-minutes  ;) )


More information is not better if that information is harmful rather than 
helpful.


Finding the definition, as opposed to merely a reference, is required for step 
3).


Before Enum, if you had tried to find AF_UNIX and did a full Lib/*.py search you would have found some comments and a couple lines of code 
-- never a definition.  And that's assuming you made the leap from 1 to AF_UNIX.


You should add searching for

  from ... import *

to your debugging list, because then you'll find:

  from _socket import *

To identify which code could have adversely affected the object's value, I must find both its implementation (for potential internal 
offenders) and references to it and objects of this type in general (for potential external offenders).


Finding the implementation might be a bit trickier with `socket.AF_UNIX', 
however:

$ grep AddressFamily.AF_UNIX *.py
...(crickets)...


I would rather search for "AddressFamily" (case-sensitive), and in the entire codebase, 
not just "*.py".
Long story short, this is a type name and looks like a very distinctive one. So that search is very likely going to readily find me anything 
directly related to that type, including its definition, with negligible noise -- however and wherever it's done.


I hope this serves as yet another demonstration why knowing the exact type is 
so crucial.


$ grep socket.AF_UNIX *.py
smtplib.py:    self.sock = socket.socket(socket.AF_UNIX, 
socket.SOCK_STREAM)
socketserver.py:    address_family = socket.AF_UNIX
socketserver.py:    address_family = socket.AF_UNIX
webbrowser.py:    s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)

Considering that stdlib Enums are almost all globally unique, and Enums created with _convert *are* globally unique, I think seeing the 
module instead of the class name is more helpful.

Speaking of which, adding help() to your debugging list would also be, um, 
helpful:

  --> help(socket.AF_UNIX)
  Help on AddressFamily in module socket object:

  class AddressFamily(enum.IntEnum)
   |  AddressFamily(value, names=None, *, module=None, qualname=None, 
type=None, start=1)
   |
   |  An enumeration.
   |
   |  ...


Examining repr() of a large number of objects (think dozens to hundreds) vs 
help() of each of them? I think we have a winner...
And help() doesn't even show the value!

You can't be serious suggesting me to do all this extra work (i.e. single-handedly increase diagnostic's labor intensity about 5x -- while 
problem diagnostic is a key activity during both development and ongoing use) just because someone wishes to playfully ignore an established 
standard specifically invented to make it unnecessary.


Pardon me if I misunderstood you, but I also find the offhand remarks: "adding this and that to your debugging list would also be, um, 
helpful" -- highly condescending and insulting and showing that you probably don't do much problem diagnostic and don't care at all about 
anyone who does -- i.e. about software developers and maintainers, your core audience.
All the while yourself being a Python core developer (if your StackOverflow profile is to be believed) -- a spokesperson for the dev team 
and a shining example of what every Python developer should strive to be.
If this is any representation of the prevalent attitude in the core team now, I'm probably wasting my time arguing here as well as 
supporting Python in general since our values clearly don't match anymore.




As a reminder, the change under discussion only affects enums created from 
globally unique constants using the Enum._convert helper utility.


I know. But it sets a precedent of screwing users over with poorly thought 
cosmetic changes done without thinking of them.
It becoming a pattern is the absolutely last thing that I want to see in Python sin

[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name

[Kyle Stanley]

Ivan Pozdeev wrote:
> More information is not better if that information is harmful rather than
helpful.

While that argument does apply in some cases, I'd have to very much
disagree that "" is harmful in comparison to just "1";
it clearly shows the value on the right side of the colon. As for the
source location for "socket.AF_UNIX" not being clear, that may be the case
the first time you encounter it or haven't seen it in a while, but it's
clear from a quick search of the help page.

IMO, the *full* location shouldn't have to appear every time you want to
see the repr; it would add unneeded noise. If you see the repr and it's not
clear, consult the help page and/or docs for more information. The repr
should be succinct.

> And help() doesn't even show the value!

Sorry, but this is simply untrue. If you scroll down on the help page, or
search via "/" for "AF_UNIX", you'll encounter the following:

|  AF_UNIX = 

(which is likely what Ethan was referring to)

If it wasn't clear, when you use "help(socket.AF_UNIX)", it brings up the
AddressFamily help page (as indicated in the title), not a dedicated page
for "socket.AF_UNIX". You can also find the information present in the
"help(socket)" page if you search for "AF_UNIX".

> Pardon me if I misunderstood you, but I also find the offhand remarks:
"adding this and that to your debugging list would also be, um,
> helpful" -- highly condescending and insulting and showing that you
probably don't do much problem diagnostic and don't care at all about
> anyone who does -- i.e. about software developers and maintainers, your
core audience.

>From my perspective, Ethan pointed out "help()" because it's very
frequently neglected, even by experienced devs; not at all to be
condescending towards you or insulting of your experience. However,
explicitly claiming that "you probably don't do much problem diagnostic and
don't care at all about anyone who does" is *directly* insulting and
doesn't add anything constructive to the discussion. Insulting the other
party, especially when they're responding to you voluntarily and not paid
to do so, makes them far less likely to consider your side or even respond
at all.

Rather than the extreme of "either you agree with me or don't have
experience with this", is it not possible that you simply disagree and have
different preferences in what makes more for more optimal debugging
information?

> All the while yourself being a Python core developer (if your
StackOverflow profile is to be believed) -- a spokesperson for the dev team
> and a shining example of what every Python developer should strive to be.

I'm not sure what the purpose of the "if your StackOverflow profile is to
be believed" part is, but the list of Python core developers can be found
here: https://devguide.python.org/developers/ (where "Ethan Furman" is
clearly listed).

> If this is any representation of the prevalent attitude in the core team
now, I'm probably wasting my time arguing here as well as
> supporting Python in general since our values clearly don't match anymore.

I'm sorry that you feel that way. But if you considered the discussion to
be a waste of time, then I don't think python-dev (or similar OSS dev
communities) will be a very productive experience for you. Also, just to be
clear: the opinion of one or a few core devs does not represent the
opinions or values of the entire core team. The core team is made up of
~100 current individuals with differing opinions, areas of expertise, and
perspectives.

On Fri, Mar 27, 2020 at 8:27 PM Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:

> On 26.03.2020 19:24, Ethan Furman wrote:
> > On 03/25/2020 06:53 PM, Ivan Pozdeev via Python-Dev wrote:
> >
> >> A diagnostic is always done by the same algorithm:
> >>
> >> 1) Identify the exact place in code where the problem manifests itself
> >> 2) Examine the state of the program at that moment to find out which if
> the values are wrong
> >> 3) Track the wrong value back to its origin
> >>
> >> Seeing an accurate repr() is required for step 2) -- to immediately
> detect if it's wrong or not.
> >
> > Before Enum, the repr for socket.AF_UNIX was:
> >
> > 1
> >
> > Not very useful for debugging.
>
> On the contrary, it's perfect. I know everything I need: it's an integer
> constant, end of story.
>
> When examining some live object, I would probably see that "1" and won't
> even need to look anything up to know what I'm dealing with.
>
> >
> >> If a repr() points to a reference rather than definition, I don't
> really know anything about the object that I'm looking at: that
> >> reference could as well be wrong, or could have been wrong at any
> moment in the past. I.e. such a repr() has negative informativity.
> >
> > Whether it's
> >
> >   
> >
> > or
> >
> >   
> >
> > it has light-years more information than it used to  (okay, maybe only
> light-minutes  ;) )
> >
> More information is not better if that information is harmful rather than
> helpful.

[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name

[Ethan Furman]

On 03/27/2020 05:21 PM, Ivan Pozdeev via Python-Dev wrote:

On 26.03.2020 19:24, Ethan Furman wrote:

On 03/25/2020 06:53 PM, Ivan Pozdeev via Python-Dev wrote:



A diagnostic is always done by the same algorithm:

1) Identify the exact place in code where the problem manifests itself
2) Examine the state of the program at that moment to find out which if the 
values are wrong
3) Track the wrong value back to its origin

Seeing an accurate repr() is required for step 2) -- to immediately detect if 
it's wrong or not.


Before Enum, the repr for socket.AF_UNIX was:

1

Not very useful for debugging.


On the contrary, it's perfect. I know everything I need: it's an integer 
constant, end of story.


So if it was a 3 you'd still be happy?  1 vs 3 gives you no information as to 
what the value should be, while blahblah.AF_UNIX vs blahblah.AF_AX25 could 
point out that that is the wrong value for the function you found it in.


When examining some live object, I would probably see that "1" and won't even 
need to look anything up to know what I'm dealing with.


If all you care about is the value, then blahblah.AF_UNIX isn't going to hurt you 
because the repr() displays it:  .  Hopefully that's 
immediately recognizable as an Enum, and a `type()` or `isinstance()` will tell you 
if it's also an `int`.

[...]


I would rather search for "AddressFamily" (case-sensitive), and in the entire codebase, 
not just "*.py".


Yeah, looks like I messed up that example -- I must have switched directories 
in between the two.  The actual results for my simple grep:

$ grep AddressFamily *.py
socket.py:   "has_dualstack_ipv6", "AddressFamily", "SocketKind"]
socket.py:'AddressFamily',
socket.py:return _intenum_converter(super().family, AddressFamily)
socket.py:addrlist.append((_intenum_converter(af, AddressFamily),

So, more useful for finding the source, still not useful for finding other uses.


Long story short, this is a type name and looks like a very distinctive one.


Yup, it's an Enum.


 So that search is very likely going to readily find me anything directly 
related to that type, including its definition, with negligible noise -- 
however and wherever it's done.


Well, there are less than two dozen lines using your search, but the definition 
location is non-obvious -- all you see is

  `AddressFamily`

Still, it's something.


I hope this serves as yet another demonstration why knowing the exact type is 
so crucial.


Not so much in this case -- if it says , then hopefully it's 
not a far stretch to look in the socket module.


  --> help(socket.AF_UNIX)
  Help on AddressFamily in module socket object:

  class AddressFamily(enum.IntEnum)
   |  AddressFamily(value, names=None, *, module=None, qualname=None, 
type=None, start=1)
   |
   |  An enumeration.
   |
   |  ...


Examining repr() of a large number of objects (think dozens to hundreds) vs 
help() of each of them? I think we have a winner...


Well, the repr in question, whether `socket.*` or `AddressFamily.*`, is still 
distinctive and still contains the value, the thing you are saying you want.


And help() doesn't even show the value!


I had snipped the output for brevity.  Here's the whole thing:

Help on AddressFamily in module socket object:

class AddressFamily(enum.IntEnum)
 |  AddressFamily(value, names=None, *, module=None, qualname=None, type=None, 
start=1)
 |
 |  An enumeration.
 |
 |  Method resolution order:
 |  AddressFamily
 |  enum.IntEnum
 |  builtins.int
 |  enum.Enum
 |  builtins.object
 |
 |  Data and other attributes defined here:
 |
 |  AF_ALG = 
 |
 |  AF_APPLETALK = 
 |
 |  AF_ASH = 
 |
 |  AF_ATMPVC = 
 |
 |  AF_ATMSVC = 
 |
 |  AF_AX25 = 
 |
 |  AF_BLUETOOTH = 
 |
 |  AF_BRIDGE = 
 |
 |  AF_CAN = 
 |
 |  AF_ECONET = 
 |
 |  AF_INET = 
 |
 |  AF_INET6 = 
 |
 |  AF_IPX = 
 |
 |  AF_IRDA = 
 |
 |  AF_KEY = 
 |
 |  AF_LLC = 
 |
 |  AF_NETBEUI = 
 |
 |  AF_NETLINK = 
 |
 |  AF_NETROM = 
 |
 |  AF_PACKET = 
 |
 |  AF_PPPOX = 
 |
 |  AF_QIPCRTR = 
 |
 |  AF_RDS = 
 |
 |  AF_ROSE = 
 |
 |  AF_SECURITY = 
 |
 |  AF_SNA = 
 |
 |  AF_TIPC = 
 |
 |  AF_UNIX = 
 |
 |  AF_UNSPEC = 
 |
 |  AF_VSOCK = 
 |
 |  AF_WANPIPE = 
 |
 |  AF_X25 = 
 |
 |  --
 |  Data descriptors inherited from enum.Enum:
 |
 |  name
 |  The name of the Enum member.
 |
 |  value
 |  The value of the Enum member.
 |
 |  --
 |  Readonly properties inherited from enum.EnumMeta:
 |
 |  __members__
 |  Returns a mapping of member name->value.
 |
 |  This mapping lists all enum members, including aliases. Note that this
 |  is a read-only view of the internal mapping.

You'll note that all the members, and their values, are listed.  (They say 
`socket`  instead of `AddressFamily` as I was testing the change.)


You can't be serious suggesting me to do all this extra wo

[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name

[Chris Angelico]

On Sat, Mar 28, 2020 at 11:28 AM Ivan Pozdeev via Python-Dev
 wrote:
>
> On 26.03.2020 19:24, Ethan Furman wrote:
> > Before Enum, the repr for socket.AF_UNIX was:
> >
> > 1
> >
> > Not very useful for debugging.
>
> On the contrary, it's perfect. I know everything I need: it's an integer 
> constant, end of story.
>
> When examining some live object, I would probably see that "1" and won't even 
> need to look anything up to know what I'm dealing with.

This is something I see *very* frequently from expert and novice
Python programmers: the belief/assumption that seeing the concrete
data is the most important thing. As an extreme expert in socket
programming, you probably DO interpret the integer 1 as "AF_UNIX", but
quite honestly, I wouldn't recognize it as such. But a repr that says
that it's socket.AF_UNIX is far far more helpful. Consider:

Suppose you have a call to socket.socket(socket.SOCK_STREAM,
socket.AF_INET, socket.IPPROTO_TCP) - only they're not literal values,
they're coming from elsewhere. Pre-enum, all you know is that it's
being passed the integers 1, 2, and 6, and how are you going to figure
out what they mean? Thanks to the enum, you get to see them with their
names (which may make the bug obvious). But either way, they are
"socket.AF_INET" etc, they are not "socket.AddressFamily.AF_INET" -
the class is a mere implementation detail.

In actual fact, the concrete integer value is just an implementation
detail, too. As long as passing socket.AF_INET results in an
internet-address-family socket, it doesn't really matter what the
actual integer is. For the sake of cross-language debugging, it's
helpful to be able to see it, but most Python programmers aren't going
to need it.

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

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Dennis Sweeney]

PEP 616 -- String methods to remove prefixes and suffixes
is available here: https://www.python.org/dev/peps/pep-0616/

Changes:
- Only accept single affixes, not tuples
- Make the specification more concise
- Make fewer stylistic prescriptions for usage
- Fix typos

A reference implementation GitHub PR is up to date here:
https://github.com/python/cpython/pull/18939

Are there any more comments for it before submission?
___
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/UJE3WCQXSZI76IW54D2SKKL6OFQ2VFMA/
Code of Conduct: http://python.org/psf/codeofconduct/