It's likely that the additions are going to break someone's code; the
question seems to be do we care, since the constructors are undocumented?
But shouldn't we just document the signatures, so that in the future we're
not going to make the same mistake?
I also wonder if some judicious use of key
pyclbr is the stdlib module browser (once just class browser, hence the
name). The doc
https://docs.python.org/3/library/pyclbr.html#module-pyclbr, which I
revised in 2017, documents readline and readline_ex as the public call
interface. The functions return a hierarchical structure that inclu
Unfortunately the public headers act as de-facto documentation.
On Wed, Jan 27, 2021 at 8:10 AM Mark Shannon wrote:
> Hi everyone,
>
> Are C structs part of the C-API if the struct is only included in a
> header, but not documented?
>
> I have always assumed not, but it isn't clear.
>
> This que
Hi everyone,
Are C structs part of the C-API if the struct is only included in a
header, but not documented?
I have always assumed not, but it isn't clear.
This question arose in https://github.com/python/cpython/pull/24298
Obviously, any structs listed in
https://docs.python.org/3/c-api/st
On Tue, 26 Jan 2021 at 01:05, Mark Shannon wrote:
> The PEP mentions "tracing mode" and changes behavior according to
> whether a program is in "tracing mode" or not. I'd like to remove this
> distinction.
OK, I've checked the status of things from an actual computer rather
than my phone, and it
Hmm, I need to review the state of my PEP PRs, as what's in the main repo
definitely isn't up to date. The tracing mode distinction should be long
gone, but is still mentioned in the text on python.org.
Cheers,
Nick.
On Wed, 27 Jan 2021, 10:03 pm Nick Coghlan, wrote:
> Note that PEP 558 already
Note that PEP 558 already doesn't change behaviour in tracing mode any more
though - that idea didn't survive the first round of review.
Cheers,
Nick.
On Wed, 27 Jan 2021, 9:58 pm Nick Coghlan, wrote:
> As far as I'm aware, the design is in a potentially acceptable state, I
> just stalled out c
As far as I'm aware, the design is in a potentially acceptable state, I
just stalled out completely on the boring bits of finishing the
implementation of the write-through proxy:
* implement & test the rest of the mutable mapping methods
* refactor to properly share code with the odict implementat
On Wed, Jan 27, 2021 at 1:16 AM Steven D'Aprano wrote:
> Right. This is (I think) Steve's point: the list is inaccurate, because
> the existence of 'winsound' in the stdlib_module_names doesn't mean that
> the module 'winsound' exists.
This point is addressed by the definition of the list:
sys.st
Hi Steven,
That makes sense to me: I wrote
https://github.com/python/cpython/pull/24353 to exclude sub-package.
The change removes 12 sub-packages from sys.stdlib_module_names and
len(sys.stdlib_module_names) becomes 300 :-)
-"concurrent.futures",
-"ctypes.macholib",
-"distutils.command",
-"emai
On Wed, Jan 27, 2021 at 10:44:00AM +0100, Antoine Pitrou wrote:
> Ok, then "stdlib_package_names"? :-)
Heh :-)
I see your smiley, and I'm not going to argue about the name any
further. I have my preference, but if the consensus is
stdlib_module_names, so be it.
But I think the inconsistency b
On Wed, 27 Jan 2021 11:05:28 +1100
Steven D'Aprano wrote:
> On Tue, Jan 26, 2021 at 12:08:03PM -0800, Brett Cannon wrote:
> > On Tue, Jan 26, 2021 at 1:26 AM Antoine Pitrou wrote:
>
> [...]
> > > Disagreed. This is niche enough that it warrants a long but explicit
> > > name, rather than some
12 matches
Mail list logo
