Fair enough. Pull request created:
https://github.com/python/cpython/pull/16347
Regards,
Vinay Sajip
___
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
On Wed, Sep 18, 2019, at 19:23, Kyle Stanley wrote:
> Benjamin, what are you thoughts on usage of the "needs backport to 2.7"
> label? For most of the PRs I've reviewed I tend to avoid adding it
> myself, but I've seen it used periodically. It seems to be used rather
> infrequently
> (https:
On Fri, Sep 13, 2019, at 18:18, Sumana Harihareswara wrote:
> Hi. I've joined python-dev to participate in this thread (I don't have
> email delivery turned on; I'll be checking back via the web).
sorry :)
>
> Benjamin, I am sorry that I didn't check in with you, and assumed that
> January
> How easy would it be to search the sources and the docs for the ones
that are currently public but not documented?
Comparing the docs and .c files for functions that are not documented
would be fairly trivial, but it's very difficult to define something as
being
public if it's not documented, si
On Mon, Sep 23, 2019 at 1:30 PM Vinay Sajip via Python-Dev
wrote:
>
> OK - but that's just one I picked at random. There are others like it - what
> would be the process for deciding which ones need to be made private and
> moved? Should an issue be raised to track this?
There are really two is
On 2019-09-23 21:22, Vinay Sajip via Python-Dev wrote:
OK - but that's just one I picked at random. There are others like it - what
would be the process for deciding which ones need to be made private and moved?
Should an issue be raised to track this?
It's not really a question of which ones
OK - but that's just one I picked at random. There are others like it - what
would be the process for deciding which ones need to be made private and moved?
Should an issue be raised to track this?
Regards,
Vinay Sajip
___
Python-Dev mailing list -- p
Le lun. 23 sept. 2019 à 21:36, Vinay Sajip via Python-Dev
a écrit :
> Nathaniel Smith wrote:
> > Windows already has working symbol visibility handling, and PyAPI_FUNC is
> > what controls it. So adding symbol visibility handling to Linux/macOS is
> > just about making all the platforms consistent
Ah - I checked, and it's there OK ... (head scratch)
Regards,
Vinay Sajip
___
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/
Mess
Nathaniel Smith wrote:
> Windows already has working symbol visibility handling, and PyAPI_FUNC is
> what controls it. So adding symbol visibility handling to Linux/macOS is
> just about making all the platforms consistent. There might be some weird
> choices being made, but I don't think you need
Thanks for the pointer. According to that information, everything in
Include/fileutils.h should be the portable public C API. But there are
definitions in there which start with _Py - and the information relating to
Include/cpython/*.h suggests that API prefixed with _Py is conventionally
priva
On Mon, Sep 23, 2019, 08:28 Vinay Sajip via Python-Dev <
python-dev@python.org> wrote:
> > requires some newer tools like -fvisibility=hidden that work
> > differently across different platforms, and so far no-one's done the
> > work to sort out the details.
>
> I've started looking at this, but q
https://github.com/python/bedevere/issues/192
It should get fixed sometime today or at worst tomorrow. Until then, if someone
edits a title after creating a PR to add an issue number, just add the `skip
issue` label and then remove it again and it will run the check.
https://github.com/python/bedevere/issues/192
It should get fixed sometime today or at worst tomorrow. Until then, if someone
edits a title after creating a PR to add an issue number, just add the `skip
issue` label and then remove it again and it will run the check.
Vinay Sajip wrote:
> > Right, I'm
> > pretty sure that right now Python doesn't have any way to
> > share symbols between .c files without also exposing them in the C
> > API.
> > On other C projects I've worked on, the public API is expressed in one set
> of header files, and internal APIs that ne
Stefan Behnel wrote:
> Ned Batchelder schrieb am 10.09.19 um 16:54:
> > this seems confusing to me
> > What does the "official EOL date" mean if there's a release in April?
It means we should all consider Python 2.7 EOL'ed come January 1 and Benjamin
will make a release when it's convenient, and
> requires some newer tools like -fvisibility=hidden that work
> differently across different platforms, and so far no-one's done the
> work to sort out the details.
I've started looking at this, but quite apart from the specifics of applying
-fvisibility=hidden, there are some things that aren't
> Moving some of the especially common identifier references into the
> interpreter state struct may make sense.
> Adding more process globals wouldn't be desirable though, as they're one of
> the more common ways of breaking encapsulation between subinterpreters
> (hence Eric's efforts to eliminat
On Sat., 21 Sep. 2019, 5:28 am Vinay Sajip via Python-Dev, <
python-dev@python.org> wrote:
> I just ran an analysis of static variable definitions in CPython code,
> using clang, on Ubuntu and Windows. The results should be available here:
>
> https://cpython.red-dove.com/
>
> As I understand it,
19 matches
Mail list logo
