[Python-Dev] Re: PEP 467 feedback from the Steering Council
On 2021-09-09 00:29, Rob Cliffe via Python-Dev wrote: On 08/09/2021 21:21, Christopher Barker wrote: [snip] NOTE: my objection to “bchr”, whether as a builtin or not is not the functionality, it’s the name. [snip] Why not byte() ? I happened to need to convert an integer to a byte recently and I settled on bytes((i,)) I don't know if I missed a more elegant solution (suggestions welcome), but if I could write byte(i) that would feel more Pythonic to me. Well, I tend to see a byte as a value like an int. If you slice a bytestring, you'd expect to get a bytestring, and you do. If you subscript a bytestring, you expect to get a byte. You get an int, and that suggests that a byte is an int. (In Python 2 you got a bytestring, in Python 3 you get an int.) The name could be misleading as byte(i) would return a bytestring, not a byte/int. ___ 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/UU2QW6KV36H5RRFL6UG2REOFRWWXKCUK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On 08/09/2021 21:21, Christopher Barker wrote: [snip] NOTE: my objection to “bchr”, whether as a builtin or not is not the functionality, it’s the name. [snip] Why not byte() ? I happened to need to convert an integer to a byte recently and I settled on bytes((i,)) I don't know if I missed a more elegant solution (suggestions welcome), but if I could write byte(i) that would feel more Pythonic to me. Best wishes Rob Cliffe ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YTR5XL5FR66KLXRVATZIZPNXPZRP7CLU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Discrepancy between what aiter() and `async for` requires on purpose?
On Wed, Sep 8, 2021 at 12:49 PM Yury Selivanov wrote: > We have already merged it, the fix is part of the rc2. > Thanks! (If we were on Discourse I would have left a ♥ instead ) > > yury > > > On Wed, Sep 8 2021 at 12:48 PM, Brett Cannon wrote: > >> On Thu, Sep 2, 2021 at 7:43 PM Yury Selivanov >> wrote: >> >>> Comments inlined: >>> >>> On Thu, Sep 2, 2021 at 6:23 PM Guido van Rossum >>> wrote: >>> First of all, we should ping Yury, who implemented `async for` about 6 years ago (see PEP 492), and Joshua Bronson, who implemented aiter() and anext() about 5 months ago (see https://bugs.python.org/issue31861). I've CC'ed them here. >>> >>> Looks like PyAiter_Check was added along with the aiter/anext builtins. >>> I agree it's unnecessary to check for __aiter__ in it, so I let's just fix >>> it. >>> >>> >>> My own view: A. iter() doesn't check that the thing returned implements __next__, because it's not needed -- iterators having an __iter__ methor is a convention, not a requirement. >>> >>> Yeah. >>> >>> You shouldn't implement __iter__ returning something that doesn't implement __iter__ itself, because then "for x in iter(a)" would fail even though "for x in a" works. But you get an error, and anyone who implements something like that (or uses it) deserves what they get. People know about this convention and the ABC enforces it, so in practice it will be very rare that someone gets bitten by this. B. aiter() shouldn't need to check either, for exactly the same reason. I *suspect* (but do not know) that the extra check for the presence of __iter__ is simply an attempt by the implementer to enforce the convention. There is no *need* other than ensuring that "async for x in aiter(a)" works when "async for x in a" works. >>> >>> I agree. >>> >> >> [SNIP] >> >> >> >>> Bottom line: let's fix PyAiter_Check to only look for __anext__. It's a >>> new function so we can still fix it to reflect PyIter_Check and not worry >>> about anything. >>> >> >> I don't know if Pablo wants such a change in 3.10 since we are at rc2 at >> this point, so this might have to wait for 3.11 (although there's no >> deprecation here since it's a loosening of requirements so it could go in >> straight away). >> > ___ 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/3ZNA6R65UG26OHB5CNVRWN7YBJYMXV7U/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On 9/8/21 1:21 PM, Christopher Barker wrote: > NOTE: my objection to “bchr”, whether as a builtin or not is not the functionality, it’s the > name. Equating a byte with a character is a legacy of C ( and Python 2” — in Python 3, they > are completely distinct concepts. No, they aren't. If you are working in a domain that uses ascii encoding (such as many network protocols), then those bytes represent characters -- this is why, for example, %-interpolation was added back to bytes. -- ~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/4BG2BXAE3RGKQEGBHYW4IRLHEB3G6XNR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
What am I missing? The integers between 0 and 255 map directly to a particular byte value. But any other integer could be expressed as a wide variety of multiple byte combinations. The proposal here covers byte-order, but what about 16 vs 32 vs 64 bits? Unsigned vs signed? I thought that’s what the struct module is for. There is the byte representation of Python’s bignum, but is that consistent across platforms and implementations? (Micropytjon, PyPy, IronPython, Jython) And even if so, is it useful? NOTE: my objection to “bchr”, whether as a builtin or not is not the functionality, it’s the name. Equating a byte with a character is a legacy of C ( and Python 2” — in Python 3, they are completely distinct concepts. Yes, that is serious bike-shedding :-) -CHB On Wed, Sep 8, 2021 at 10:16 AM Barry Scott wrote: > > On 8 Sep 2021, at 06:39, Steven D'Aprano wrote: > > > On Tue, Sep 07, 2021 at 08:09:33PM -0700, Barry Warsaw wrote: > > I think Nick is on board with bytes.fromint() and no bchr(), and my > sense of the sentiment here is that this would be an acceptable > resolution for most folks. Ethan, can you reconsider? > > > I haven't been completely keeping up with the entire thread, so > apologies if this has already been covered. I assume that the idea is > that bytes.fromint should return a single byte, equivalent to chr() > returning a single character. > > To me, it sounds like should be the opposite of int.from_bytes. > > int.from_bytes(b'Hello world', 'little') > >121404708502361365413651784 > > bytes.from_int(121404708502361365413651784, 'little') > ># should return b'Hello world' > > > :>>> int.from_bytes(b'\x00\x00\x00\x01', byteorder='big') > 1 > :>>> bytes.from_int(1) > would return b'\x01'? Without a length it cannot return > b'\x00\x00\x00\x01' > > Barry > > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/TTFJ4VP5PCR557VHEH5LPSWAPNPE4QQU/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email 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/PANHM75VNG2SX4FUZNKHELKVSDFNFNCT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Discrepancy between what aiter() and `async for` requires on purpose?
We have already merged it, the fix is part of the rc2. yury On Wed, Sep 8 2021 at 12:48 PM, Brett Cannon wrote: > On Thu, Sep 2, 2021 at 7:43 PM Yury Selivanov > wrote: > >> Comments inlined: >> >> On Thu, Sep 2, 2021 at 6:23 PM Guido van Rossum wrote: >> >>> First of all, we should ping Yury, who implemented `async for` about 6 >>> years ago (see PEP 492), and Joshua Bronson, who implemented aiter() and >>> anext() about 5 months ago (see https://bugs.python.org/issue31861). >>> I've CC'ed them here. >>> >> >> Looks like PyAiter_Check was added along with the aiter/anext builtins. >> I agree it's unnecessary to check for __aiter__ in it, so I let's just fix >> it. >> >> >> >>> >>> My own view: >>> >>> A. iter() doesn't check that the thing returned implements __next__, >>> because it's not needed -- iterators having an __iter__ methor is a >>> convention, not a requirement. >>> >> >> Yeah. >> >> >>> You shouldn't implement __iter__ returning something that doesn't >>> implement __iter__ itself, because then "for x in iter(a)" would fail even >>> though "for x in a" works. But you get an error, and anyone who implements >>> something like that (or uses it) deserves what they get. People know about >>> this convention and the ABC enforces it, so in practice it will be very >>> rare that someone gets bitten by this. >>> >>> B. aiter() shouldn't need to check either, for exactly the same reason. >>> I *suspect* (but do not know) that the extra check for the presence of >>> __iter__ is simply an attempt by the implementer to enforce the convention. >>> There is no *need* other than ensuring that "async for x in aiter(a)" works >>> when "async for x in a" works. >>> >> >> I agree. >> > > [SNIP] > > > >> Bottom line: let's fix PyAiter_Check to only look for __anext__. It's a >> new function so we can still fix it to reflect PyIter_Check and not worry >> about anything. >> > > I don't know if Pablo wants such a change in 3.10 since we are at rc2 at > this point, so this might have to wait for 3.11 (although there's no > deprecation here since it's a loosening of requirements so it could go in > straight away). > ___ 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/BT4NCXAD7PLRYST7OOWYDCPOIG4OU6A6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Discrepancy between what aiter() and `async for` requires on purpose?
On Thu, Sep 2, 2021 at 7:43 PM Yury Selivanov wrote: > Comments inlined: > > On Thu, Sep 2, 2021 at 6:23 PM Guido van Rossum wrote: > >> First of all, we should ping Yury, who implemented `async for` about 6 >> years ago (see PEP 492), and Joshua Bronson, who implemented aiter() and >> anext() about 5 months ago (see https://bugs.python.org/issue31861). >> I've CC'ed them here. >> > > Looks like PyAiter_Check was added along with the aiter/anext builtins. I > agree it's unnecessary to check for __aiter__ in it, so I let's just fix it. > > > >> >> My own view: >> >> A. iter() doesn't check that the thing returned implements __next__, >> because it's not needed -- iterators having an __iter__ methor is a >> convention, not a requirement. >> > > Yeah. > > >> You shouldn't implement __iter__ returning something that doesn't >> implement __iter__ itself, because then "for x in iter(a)" would fail even >> though "for x in a" works. But you get an error, and anyone who implements >> something like that (or uses it) deserves what they get. People know about >> this convention and the ABC enforces it, so in practice it will be very >> rare that someone gets bitten by this. >> >> B. aiter() shouldn't need to check either, for exactly the same reason. I >> *suspect* (but do not know) that the extra check for the presence of >> __iter__ is simply an attempt by the implementer to enforce the convention. >> There is no *need* other than ensuring that "async for x in aiter(a)" works >> when "async for x in a" works. >> > > I agree. > [SNIP] > Bottom line: let's fix PyAiter_Check to only look for __anext__. It's a > new function so we can still fix it to reflect PyIter_Check and not worry > about anything. > I don't know if Pablo wants such a change in 3.10 since we are at rc2 at this point, so this might have to wait for 3.11 (although there's no deprecation here since it's a loosening of requirements so it could go in straight away). ___ 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/VLPPCXB3T2AP65VGUTRPYDOKGHEGZUUN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
> On 8 Sep 2021, at 06:39, Steven D'Aprano wrote: > > On Tue, Sep 07, 2021 at 08:09:33PM -0700, Barry Warsaw wrote: > >> I think Nick is on board with bytes.fromint() and no bchr(), and my >> sense of the sentiment here is that this would be an acceptable >> resolution for most folks. Ethan, can you reconsider? > > I haven't been completely keeping up with the entire thread, so > apologies if this has already been covered. I assume that the idea is > that bytes.fromint should return a single byte, equivalent to chr() > returning a single character. > > To me, it sounds like should be the opposite of int.from_bytes. > int.from_bytes(b'Hello world', 'little') >121404708502361365413651784 bytes.from_int(121404708502361365413651784, 'little') ># should return b'Hello world' :>>> int.from_bytes(b'\x00\x00\x00\x01', byteorder='big') 1 :>>> bytes.from_int(1) would return b'\x01'? Without a length it cannot return b'\x00\x00\x00\x01' Barry ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TTFJ4VP5PCR557VHEH5LPSWAPNPE4QQU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
Steven D'Aprano wrote: > To me, it sounds like should be the opposite of int.from_bytes. > >>> int.from_bytes(b'Hello world', 'little') > 121404708502361365413651784 > >>> bytes.from_int(121404708502361365413651784, 'little') > # should return b'Hello world' > If that's not the API being suggested, that's going to be confusing. I'm a bit lost here... why are we convinced at all that we need a new way to do this? Hasn't this functionality already existed for years? >>> x = int.from_bytes(b"*", "little") >>> x 42 >>> x.to_bytes(1, "little") b'*' Brandt ___ 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/FMG5K4BOX5GSUR2KU3G5ZLBBUIC3EQKD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On 2021-09-08 13:37, Victor Stinner wrote:
On Wed, Sep 8, 2021 at 7:46 AM Steven D'Aprano wrote:
>>> bytes.from_int(121404708502361365413651784, 'little')
# should return b'Hello world'
Really? I don't know anyone serializing strings as a "bigint" number.
Did you already see such code pattern in the wild? Usually, bytes are
serialized as... bytes, no? Sometimes, bytes are serialized as base64
or hexadecimal to go through into an ASCII ("7-bit") bytestream. But I
don' recall any file format serializing bytes as a single large
decimal number.
Well, we already have int.from_bytes. What's that used for?
Adding the opposite conversion does make sense to me. If the number is
0..255, and maybe the byteorder can be omitted in that case, then it
seems like a reasonable solution to me.
___
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/MZGIU5ECYSAPVA47475ZEI4QQCQQJCYA/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On 9/7/21 10:39 PM, Steven D'Aprano wrote: > On Tue, Sep 07, 2021 at 08:09:33PM -0700, Barry Warsaw wrote: > >> I think Nick is on board with bytes.fromint() and no bchr(), and my >> sense of the sentiment here is that this would be an acceptable >> resolution for most folks. Ethan, can you reconsider? > > I haven't been completely keeping up with the entire thread, so > apologies if this has already been covered. I assume that the idea is > that bytes.fromint should return a single byte, equivalent to chr() > returning a single character. > > To me, it sounds like should be the opposite of int.from_bytes. > > >>> int.from_bytes(b'Hello world', 'little') > 121404708502361365413651784 > >>> bytes.from_int(121404708502361365413651784, 'little') > # should return b'Hello world' That certainly makes sense to me. At this point, the only reason that would not work is an arbitrary limit of 255 on the input, and the only reason that limit is there is to have `bchr` be the inverse of `ord`. Since `bchr` isn't going to happen, I see no reason to have the 255 limit. `byteorder` can default to None with a requirement of being set when the integer is over 255. -- ~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/44O4B2YOQGHCYUARRGVZ6WL6GRD4PZ5J/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [Python-ideas] Re: open functions in dbm submodule need to support path-like object
Thanks Serhiy,
I've made the few additional changes you noted in the PR. I took out my
attempt with path_t. However, here is why I think argument clinic (or
something else?!) is actually intercepting the attempted call:
With my temporary debugging, I have this function in Modules/_gdbmmodule.c:
[clinic start generated code]*/
static PyObject *
dbmopen_impl(PyObject *module, PyObject *filename, const char *flags,
int mode)
/*[clinic end generated code: output=9527750f5df90764
input=812b7d74399ceb0e]*/
{
PyObject_Print(filename, stdout, 0);
printf(" from _gdbmmodule.c (XXX)\n");
/* ... rest of function ...*/
And I have a very simplified test script:
import _gdbm
import sys
from pathlib import Path
print(sys.version)
path = '/tmp/tmp.db'
db = _gdbm.open(path, 'c')
print("Opened with string path")
db.close()
db = _gdbm.open(Path(path), 'c')
print("Opened with path-like")
db.close()
The output of running this is:
3.11.0a0 (heads/bpo-45133-dirty:0376feb030, Sep 8 2021, 00:39:39) [GCC
10.3.0]
'/tmp/tmp.db' from _gdbmmodule.c (XXX)
Opened with string path
Traceback (most recent call last):
File "/home/dmertz/tmp/pathlike-dbm.py", line 12, in
db = _gdbm.open(Path(path), 'c')
^^^
TypeError: open() argument 1 must be str, not PosixPath
So before I get to the first line of the _gdbm.open() function, the
TypeError is already occurring when passed a PosixPath.
On Wed, Sep 8, 2021 at 3:49 AM Serhiy Storchaka wrote:
> 08.09.21 08:19, David Mertz, Ph.D. пише:
> > I attempted to do this today, as my first actual contribution to CPython
> > itself. I think the prior attempt went down a wrong path, which is why
> > neither PR could actually pass tests.
> >
> > I've been looking at `posixmodule.c` for comparison, specifically.
>
> The code in posixmodule.c is a bad example, because it is too general
> and supports many options. It gives the patch as char* and wchat_t* (on
> Windows), supports file descriptors and None, and format error messages
> for functions supporting multiple types. But if you only need a path as
> char*, you can just use PyUnicode_FSConverter().
>
> There is an existing PR for this issue. It looks correct in general, but
> I left some comments.
>
> ___
> 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/LQGU6DM5ZSDPCAXKLEII6YIF4HQI52NG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons. Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
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/4K5MDPKTF6D3UFC3S6GRL7TESSXFLCN2/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On Wed, Sep 8, 2021 at 10:42 PM Victor Stinner wrote:
>
> On Wed, Sep 8, 2021 at 7:46 AM Steven D'Aprano wrote:
> > >>> bytes.from_int(121404708502361365413651784, 'little')
> > # should return b'Hello world'
>
> Really? I don't know anyone serializing strings as a "bigint" number.
> Did you already see such code pattern in the wild? Usually, bytes are
> serialized as... bytes, no? Sometimes, bytes are serialized as base64
> or hexadecimal to go through into an ASCII ("7-bit") bytestream. But I
> don' recall any file format serializing bytes as a single large
> decimal number.
>
I've seen it, in various places. There are certain protocols in which
the distinction between a number and a byte sequence is immaterial
(for instance, the FOURCC identifier in an IFF family file such as a
.wav - the signature 'WAVE' is identically considered to be the number
0x57415645). Being able to convert between the numeric and character
forms of the same identifier is convenient.
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/G7AA7NYUUIAEYEZSETNMQBFAEAC4XYTP/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On Wed, Sep 8, 2021 at 7:46 AM Steven D'Aprano wrote:
> >>> bytes.from_int(121404708502361365413651784, 'little')
> # should return b'Hello world'
Really? I don't know anyone serializing strings as a "bigint" number.
Did you already see such code pattern in the wild? Usually, bytes are
serialized as... bytes, no? Sometimes, bytes are serialized as base64
or hexadecimal to go through into an ASCII ("7-bit") bytestream. But I
don' recall any file format serializing bytes as a single large
decimal number.
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/65FBFRCWV4V5SAP44EQG3XKHW6Q7C3QL/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: deprecated-removed
Hi Serhiy, For me, "deprecated" should be used if the removal is *not* planned: the feature is too popular, and removing it would break too much 3rd party code. "deprecated-removal" should be used if the feature removal *is* planned. IMO it's ok if we forget to remove the feature and keep it longer than expected. But it should help users to raise their awareness that the removal *will* happen. Having a release version gives a deadline. Victor On Wed, Sep 8, 2021 at 12:37 PM Serhiy Storchaka wrote: > > I always thought that the "deprecated" directive is used if the term of > removing the deprecated feature is not set yet, and the > "deprecated-removed" directive is used if it is set. After removing the > feature both directives are replaced with the "versionchanged" directive > which only specifies the version of removing, not version of deprecation. > > But after reading the devguide [1] I am no longer so confident. The > devguide clearly describes it as specifying version at which the feature > "is" removed, not "will be" removed. Maybe I always used this directive > incorrectly? Or its meaning was changed with time? Or I incorrectly > understand the devguide wording? Or devguide is incorrect? > > Before 3.8 I only seen "deprecated-removed" with future removing > version. The first use "deprecated-removed" for feature which is already > deleted happened in 3.8 (maybe the directive was just not updated), and > there are now many uses for features removed in asyncio in 3.10. > > What was the initial meaning of "deprecated-removed", how it should be > used now, and is the devguide correct? > > [1] > https://devguide.python.org/documenting/?highlight=deprecated-removed#paragraph-level-markup > > > ___ > 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/SWBM2N4EFPVQFP4TX6Q33L5OK2WPBFRU/ > 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/STQ6JSRYODHMNIEYTYSCM3AZH3MSMRWC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] deprecated-removed
I always thought that the "deprecated" directive is used if the term of removing the deprecated feature is not set yet, and the "deprecated-removed" directive is used if it is set. After removing the feature both directives are replaced with the "versionchanged" directive which only specifies the version of removing, not version of deprecation. But after reading the devguide [1] I am no longer so confident. The devguide clearly describes it as specifying version at which the feature "is" removed, not "will be" removed. Maybe I always used this directive incorrectly? Or its meaning was changed with time? Or I incorrectly understand the devguide wording? Or devguide is incorrect? Before 3.8 I only seen "deprecated-removed" with future removing version. The first use "deprecated-removed" for feature which is already deleted happened in 3.8 (maybe the directive was just not updated), and there are now many uses for features removed in asyncio in 3.10. What was the initial meaning of "deprecated-removed", how it should be used now, and is the devguide correct? [1] https://devguide.python.org/documenting/?highlight=deprecated-removed#paragraph-level-markup ___ 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/SWBM2N4EFPVQFP4TX6Q33L5OK2WPBFRU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [Python-ideas] Re: open functions in dbm submodule need to support path-like object
08.09.21 08:19, David Mertz, Ph.D. пише: > I attempted to do this today, as my first actual contribution to CPython > itself. I think the prior attempt went down a wrong path, which is why > neither PR could actually pass tests. > > I've been looking at `posixmodule.c` for comparison, specifically. The code in posixmodule.c is a bad example, because it is too general and supports many options. It gives the patch as char* and wchat_t* (on Windows), supports file descriptors and None, and format error messages for functions supporting multiple types. But if you only need a path as char*, you can just use PyUnicode_FSConverter(). There is an existing PR for this issue. It looks correct in general, but I left some comments. ___ 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/LQGU6DM5ZSDPCAXKLEII6YIF4HQI52NG/ Code of Conduct: http://python.org/psf/codeofconduct/
