[issue33888] Use CPython instead of Python when talking about implementation details

Change by miss-islington : -- pull_requests: +7737 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33888] Use CPython instead of Python when talking about implementation details

Change by miss-islington : -- pull_requests: +7735 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33888] Use CPython instead of Python when talking about implementation details

Change by Serhiy Storchaka : -- nosy: +gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33888] Use CPython instead of Python when talking about implementation details

Change by Andrés Delfino : -- keywords: +patch pull_requests: +7375 stage: -> patch review ___ Python tracker ___ ___

[issue33888] Use CPython instead of Python when talking about implementation details

New submission from Andrés Delfino : The FAQ talks about list and dictionary implementation details using "Python". I believe this should be changed to CPython. -- assignee: docs@python components: Documentation messages: 319825 nosy: adelfino, docs@python priority: norma

[issue32384] Generator tests is broken in non-CPython implementation

Berker Peksag added the comment: Thanks! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue32384] Generator tests is broken in non-CPython implementation

Berker Peksag <berker.pek...@gmail.com> added the comment: New changeset 5e8c52680450b67a116d3d555db8416c40576fdb by Berker Peksag (Miss Islington (bot)) in branch '3.6': bpo-32384: Skip test when _testcapi isn't available (GH-4940) https://github.com/python/cpython/

[issue32384] Generator tests is broken in non-CPython implementation

Berker Peksag <berker.pek...@gmail.com> added the comment: New changeset 4af6110f77e141779492995fd168d4f027fcf3cf by Berker Peksag (Miss Islington (bot)) in branch '3.7': bpo-32384: Skip test when _testcapi isn't available (GH-4940) https://github.com/python/cpython/

[issue32384] Generator tests is broken in non-CPython implementation

Change by miss-islington : -- pull_requests: +6565 ___ Python tracker ___

[issue32384] Generator tests is broken in non-CPython implementation

Change by miss-islington : -- pull_requests: +6564 ___ Python tracker ___

[issue32384] Generator tests is broken in non-CPython implementation

Berker Peksag <berker.pek...@gmail.com> added the comment: New changeset 4cc3eb48e1e8289df5153db1c701cae263a1ef86 by Berker Peksag (Isaiah Peng) in branch 'master': bpo-32384: Skip test when _testcapi isn't available (GH-4940) https://github.com/python/cpython/

[issue32384] Generator tests is broken in non-CPython implementation

Change by Berker Peksag : -- versions: +Python 3.7, Python 3.8 ___ Python tracker ___

[issue33253] xxsubtype.bench does not function correctly on CPython 3+

Serhiy Storchaka added the comment: 3.4 and 3.5 are at security bug fixes only stage. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.4, Python 3.5 ___ Python tracker

[issue33253] xxsubtype.bench does not function correctly on CPython 3+

miss-islington <mariatta.wijaya+miss-isling...@gmail.com> added the comment: New changeset 910d71b839755baa31258bcc083be9191563819e by Miss Islington (bot) in branch '3.6': bpo-33253: Fix xxsubtype.bench() to accept correct str signature. (GH-6439) https://github.com/python/cpython/

[issue33253] xxsubtype.bench does not function correctly on CPython 3+

miss-islington <mariatta.wijaya+miss-isling...@gmail.com> added the comment: New changeset 9bb8cebdce99db7e7a94f15141a8e0514b51aa72 by Miss Islington (bot) in branch '3.7': bpo-33253: Fix xxsubtype.bench() to accept correct str signature. (GH-6439) https://github.com/python/cpython/

[issue33253] xxsubtype.bench does not function correctly on CPython 3+

Change by miss-islington : -- pull_requests: +6137 ___ Python tracker ___

[issue33253] xxsubtype.bench does not function correctly on CPython 3+

Change by miss-islington : -- pull_requests: +6136 ___ Python tracker ___

[issue33253] xxsubtype.bench does not function correctly on CPython 3+

Serhiy Storchaka <storchaka+cpyt...@gmail.com> added the comment: New changeset f178028f37c9dafb72608b719eb03e5a70af4ff5 by Serhiy Storchaka (Devon R) in branch 'master': bpo-33253: Fix xxsubtype.bench() to accept correct str signature. (GH-6439) https://github.com/python/cpython/

[issue33253] xxsubtype.bench does not function correctly on CPython 3+

Change by Gorialis : -- keywords: +patch pull_requests: +6135 stage: -> patch review ___ Python tracker ___

[issue33253] xxsubtype.bench does not function correctly on CPython 3+

New submission from Gorialis <sansgorialis+...@gmail.com>: Due to the `OS|i` signature of `xxsubtype.bench`, it accepts `bytes` as its second argument in CPython 3+, however, it does a call `PyObject_GetAttr` which only accepts `PyString`. This means that if you give the function

[issue25782] CPython hangs on error __context__ set to the error itself

Gregory P. Smith added the comment: I believe the original issue is fixed, the original problem and the one Jack followed up with no longer work in modern Python 3. But there is discussion about possibly doing something better, if anyone is interested in doing that I suggest

[issue25782] CPython hangs on error __context__ set to the error itself

Serhiy Storchaka added the comment: What should we do with this issue? Does it need opening a topic on Python-Dev? -- ___ Python tracker

[issue32783] ln(2) isn't accurate in _math.c in cpython

Mark Dickinson added the comment: Closing. There's no actual bug here. -- resolution: -> not a bug stage: needs patch -> resolved status: open -> closed ___ Python tracker

[issue32783] ln(2) isn't accurate in _math.c in cpython

Mark Dickinson added the comment: > I'm inclined to just close this as "not a bug". Sounds good to me. The ideal would probably be to use a hex literal here. They're part of C99 (see section 6.4.4.2), but last time I checked Visual Studio didn't support them. I don't

[issue32783] ln(2) isn't accurate in _math.c in cpython

Tim Peters added the comment: As I mentioned on StackOverflow, the literal in question appears to have been crafted to convert to the best possible 53-bit binary approximation to log(2) regardless of whether a compiler converts it to double precision (53 bits of precision)

[issue32783] ln(2) isn't accurate in _math.c in cpython

Steven D'Aprano added the comment: Thanks for the link to the Stackoverflow discussion. Currently there are three answers: two (correctly) answer that the constant as given is the most accurate value for IEEE-754 floats. Tim Peters has answered that:

[issue32783] ln(2) isn't accurate in _math.c in cpython

Christian Heimes added the comment: Welcome to the astounding world of IEEE 754 floating point operations. Python's float type is based on C's 64bit double precision float. The value in _math.c is as precise as a double is able to contain: >>>

[issue32783] ln(2) isn't accurate in _math.c in cpython

Change by R. David Murray : -- nosy: +mark.dickinson ___ Python tracker ___ ___

[issue32783] ln(2) isn't accurate in _math.c in cpython

New submission from Matanya Stroh <matanya.st...@gmail.com>: In cpython/Modules/_math.c there is definition of as const ln2 the value that in that const isn't correct (at least not accurate) This is value that in the file: ln2 = 0.693147180559945286227 (cpython) but when calculating the

Re: PyPy support breaking CPython compatibility?

://bitbucket.org/tkadm30/libschevo/commits/745d1aeab5c6ee0d336790cf13d16f327e10c2f8 https://bitbucket.org/tkadm30/libdurus/commits/875636e9b6caa840fd50ca87d69217d87fc06f43 In short, it seems PyPy automagically adds a __weakref__ attribute to __slots__, causing the CPython interpreter to raise

[issue20984] 'Add/Remove Programs' dialog missing entries for 32-bit CPython 'current user only' installations on 64-bit Windows

Change by Steve Dower : -- resolution: -> out of date stage: test needed -> resolved status: open -> closed ___ Python tracker

[issue20984] 'Add/Remove Programs' dialog missing entries for 32-bit CPython 'current user only' installations on 64-bit Windows

Cheryl Sabella added the comment: Based on Steve's last comment on this issue, should this be closed as 'Out of Date'? -- nosy: +csabella ___ Python tracker

Re: PyPy support breaking CPython compatibility?

/745d1aeab5c6ee0d336790cf13d16f327e10c2f8 https://bitbucket.org/tkadm30/libdurus/commits/875636e9b6caa840fd50ca87d69217d87fc06f43 In short, it seems PyPy automagically adds a __weakref__ attribute to __slots__, causing the CPython interpreter to raise a TypeError... PyPy and CPython are separate

Re: PyPy support breaking CPython compatibility?

On Wed, Jan 31, 2018 at 8:15 PM, Etienne Robillard wrote: > > > Le 2018-01-30 à 16:38, Ned Batchelder a écrit : >>> >>> I'm confused by this: >>> >>> -if os.environ.get('SCHEVO_OPTIMIZE', '1') == '1': >>> +if os.environ.get('SCHEVO_OPTIMIZE', '1') == True: >>> >> I was also

Re: PyPy support breaking CPython compatibility?

Le 2018-01-30 à 16:38, Ned Batchelder a écrit : I'm confused by this: -if os.environ.get('SCHEVO_OPTIMIZE', '1') == '1': +if os.environ.get('SCHEVO_OPTIMIZE', '1') == True: I was also curious about this: when does os.environ.get return anything but a string? I was probably high when I

Re: PyPy support breaking CPython compatibility?

a look at the changesets: https://bitbucket.org/tkadm30/libschevo/commits/745d1aeab5c6ee0d336790cf13d16f327e10c2f8 https://bitbucket.org/tkadm30/libdurus/commits/875636e9b6caa840fd50ca87d69217d87fc06f43 In short, it seems PyPy automagically adds a __weakref__ attribute to __slots__, causing the C

Re: PyPy support breaking CPython compatibility?

gt; > Please take a look at the changesets: > > https://bitbucket.org/tkadm30/libschevo/commits/745d1aeab5c6ee0d336790cf13d16f327e10c2f8 > https://bitbucket.org/tkadm30/libdurus/commits/875636e9b6caa840fd50ca87d69217d87fc06f43 > > In short, it seems PyPy automagically adds a __weakref

Re: PyPy support breaking CPython compatibility?

://bitbucket.org/tkadm30/libdurus/commits/875636e9b6caa840fd50ca87d69217d87fc06f43 In short, it seems PyPy automagically adds a __weakref__ attribute to __slots__, causing the CPython interpreter to raise a TypeError... Cheers, Etienne -- Etienne Robillard tkad...@yandex.com https

Re: PyPy support breaking CPython compatibility?

On 1/30/18 2:35 PM, Etienne Robillard wrote: Hi, I managed to patch Schevo and Durus to run under PyPy 5.9. However, I'm afraid the changes is breaking Python 2.7 compatibility. I'm curious what you had to change for PyPy? (Unless it's a Py2/Py3 thing as Chris mentions.) I'm not sure how

Re: PyPy support breaking CPython compatibility?

Hi Chris, Le 2018-01-30 à 14:53, Chris Angelico a écrit : If you're supporting Python 3, I don't think there's any problem with saying "Python 2.7 support ceases as of Schevo v4.0, so if you need Py 2.7 use Schevo 3.x". (It's not as if the old versions will suddenly cease working or anything.)

Re: PyPy support breaking CPython compatibility?

s will suddenly cease working or anything.) On the other hand, if you're looking at two different Python 2.7 interpreters, you'll be narrowing your potential userbase significantly by dropping CPython support. Maybe that's not an issue for you (hey, I've "released" code that depe

PyPy support breaking CPython compatibility?

Hi, I managed to patch Schevo and Durus to run under PyPy 5.9. However, I'm afraid the changes is breaking Python 2.7 compatibility. I'm not sure how I should distribute my changes to the respective projects. Since I decided to use more PyPy in my Django projects, should I drop Python 2.7

Re: Tips or strategies to understanding how CPython works under the hood

Robert O'Shea wrote: I wrote a little bytecode interpreter in C (maybe should have upgrade to C++ but not yet) Don't feel bad about that -- IMO, C is perfectly fine for tnis kind of thing, and "upgrading" to C++ would gain you nothing while introducing extra headaches. -- Greg --

Re: Tips or strategies to understanding how CPython works under the hood

On Fri, Jan 12, 2018 at 9:52 AM, Skip Montanaro <skip.montan...@gmail.com> wrote: >> So besides just grabbing a chunk of CPython source code and digesting it, I >> was wondering if those of you have read and understood the source code, do >> you have any tips

Re: Tips or strategies to understanding how CPython works under the hood

> So besides just grabbing a chunk of CPython source code and digesting it, I > was wondering if those of you have read and understood the source code, do > you have any tips or good starting points? Not mentioned yet, but maybe worth considering, might be to dip into the way bac

Re: Tips or strategies to understanding how CPython works under the hood

internals. On Wed 10 Jan 2018, 12:13 bartc, <b...@freeuk.com> wrote: > On 09/01/2018 20:12, Alain Ketterlin wrote: > > ElChino <elch...@cnn.cn> writes: > > > >> Chris Angelico wrote: > >> > >>> CPython is a stack-based interpreter, which means

Re: Tips or strategies to understanding how CPython works under the hood (Posting On Python-List Prohibited)

-based Lua, but can also be trivially accelerated to be several times faster, while still executing sequential byte-code. Not as fast as LuaJIT, but what goes on in that is beyond the methods discussed here for CPython and such.) -- bartc -- https://mail.python.org/mailman/listinfo/python-list

Re: Tips or strategies to understanding how CPython works under the hood

On 09/01/2018 20:12, Alain Ketterlin wrote: ElChino <elch...@cnn.cn> writes: Chris Angelico wrote: CPython is a stack-based interpreter, which means it loads values onto an (invisible) internal stack, processes values at the top of the stack, and removes them when it'

Re: Tips or strategies to understanding how CPython works under the hood

http://aosabook.org/en/500L/a-python-interpreter-written-in-python.html -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list

Re: Tips or strategies to understanding how CPython works under the hood

On Tuesday, January 9, 2018 at 3:22:30 PM UTC, Robert O'Shea wrote: > Hey all, > > Been subscribed to this thread for a while but haven't contributed much. > One of my ultimate goals this year is to get under the hood of CPython and > get a decent understanding of mechanics Gui

Re: Tips or strategies to understanding how CPython works under the hood

On 09-Jan 15:21, Robert O'Shea wrote: > > Been subscribed to this thread for a while but haven't contributed much. +1. I'm a lurker too. > So besides just grabbing a chunk of CPython source code and digesting it, I > was wondering if those of you have read and understood the sou

Re: Tips or strategies to understanding how CPython works under the hood

ElChino <elch...@cnn.cn> writes: > Chris Angelico wrote: > >> CPython is a stack-based interpreter, which means it loads values onto >> an (invisible) internal stack, processes values at the top of the >> stack, and removes them when it's done. > > Is

Re: Tips or strategies to understanding how CPython works under the hood

On Wed, Jan 10, 2018 at 6:20 AM, ElChino <elch...@cnn.cn> wrote: > Chris Angelico wrote: > >> CPython is a stack-based interpreter, which means it loads values onto >> an (invisible) internal stack, processes values at the top of the >> stack, and removes them when it

Re: Tips or strategies to understanding how CPython works under the hood

Chris Angelico wrote: CPython is a stack-based interpreter, which means it loads values onto an (invisible) internal stack, processes values at the top of the stack, and removes them when it's done. Is this similar to how Lua operates too? -- https://mail.python.org/mailman/listinfo/python

Re: Tips or strategies to understanding how CPython works under the hood

e of my ultimate goals this year is to get under the hood of CPython and >> get a decent understanding of mechanics Guido and the rest of you wonderful >> people have designed and implemented. >> >> I've been programming in python for nearly 10 years now and while I can >>

Re: Tips or strategies to understanding how CPython works under the hood

On Wed, Jan 10, 2018 at 2:21 AM, Robert O'Shea <robertoshea2...@gmail.com> wrote: > Hey all, > > Been subscribed to this thread for a while but haven't contributed much. > One of my ultimate goals this year is to get under the hood of CPython and > get a decent understandi

Tips or strategies to understanding how CPython works under the hood

Hey all, Been subscribed to this thread for a while but haven't contributed much. One of my ultimate goals this year is to get under the hood of CPython and get a decent understanding of mechanics Guido and the rest of you wonderful people have designed and implemented. I've been programming

[issue32384] Generator tests is broken in non-CPython implementation

Change by Srinivas Reddy T : -- pull_requests: +4894 ___ Python tracker ___

[issue32384] Generator tests is broken in non-CPython implementation

Change by R. David Murray : -- nosy: +yselivanov type: enhancement -> behavior ___ Python tracker ___

[issue32384] Generator tests is broken in non-CPython implementation

Change by Isaiah Peng : -- keywords: +patch pull_requests: +4831 stage: -> patch review ___ Python tracker ___

[issue32384] Generator tests is broken in non-CPython implementation

saiahp priority: normal severity: normal status: open title: Generator tests is broken in non-CPython implementation type: enhancement versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue31810] Travis CI, buildbots: run "make smelly" to check if CPython leaks symbols

Yury Selivanov <yseliva...@gmail.com> added the comment: New changeset bf9d317626eebcf79bd0756b4dd43df82d5cc186 by Yury Selivanov (Tom Floyer) in branch 'master': bpo-31810: added missing keywords to docs. (#4140) https://github.com/python/cpython/

[issue31810] Travis CI, buildbots: run "make smelly" to check if CPython leaks symbols

Change by Tom Floyer : -- pull_requests: +4300 ___ Python tracker ___ ___

[issue31810] Travis CI, buildbots: run "make smelly" to check if CPython leaks symbols

Change by STINNER Victor : -- pull_requests: -4299 ___ Python tracker ___ ___

[issue31810] Travis CI, buildbots: run "make smelly" to check if CPython leaks symbols

Change by Tom Floyer : -- pull_requests: +4299 ___ Python tracker ___ ___

Re: Coding style in CPython implementation

On 28/10/17 19:42, Στέφανος Σωφρονίου wrote: Greetings everyone. I have noticed that in many if conditions the following syntax is used: a) if (variable == NULL) { ... } b) if (variable == -1) { ... } c) if (variable != NULL) { ... } What I wanted to ask is, is there a particular reason for

Re: Coding style in CPython implementation

On Monday, October 30, 2017 at 2:35:13 AM UTC+2, ROGER GRAYDON CHRISTMAN wrote: > NOTE: The case in question was never comparing to True; it was comparing to > NULL. > > There is no "No: if x == None" below, because None is not Boolean. > Similarly comparing a pointer to NULL is not the same

Re: Coding style in CPython implementation

NOTE: The case in question was never comparing to True; it was comparing to NULL. There is no "No: if x == None" below, because None is not Boolean. Similarly comparing a pointer to NULL is not the same as comparing it to a Boolean. So I would favor the "Explicit is better than Implicit" in

Re: Coding style in CPython implementation

On Mon, Oct 30, 2017 at 12:47 AM, Stefan Ram wrote: > =?UTF-8?B?zqPPhM6tz4bOsc69zr/PgiDOo8+Jz4bPgc6/zr3Or86/z4U=?= > writes: >>I guess the following parts from "Zen of Python" apply to this case: > > If we would agree to apply Python

Re: Coding style in CPython implementation

On Sunday, October 29, 2017 at 4:00:59 AM UTC-5, Στέφανος Σωφρονίου wrote: [...] > I guess the following parts from "Zen of Python" apply to this case: > > - Beautiful is better than ugly. > - Explicit is better than implicit. > - Simple is better than complex. > - Readability counts. Now go

Re: Coding style in CPython implementation

On Sunday, October 29, 2017 at 4:18:38 AM UTC+2, Dan Sommers wrote: > On Sat, 28 Oct 2017 16:20:54 -0700, Στέφανος Σωφρονίου wrote: > > > I do believe though that if (!d) is a lot clearer than if (d == NULL) > > as it is safer than falsely assigning NULL in d, by pure mistake. > > Having made my

Re: Coding style in CPython implementation

On Sat, 28 Oct 2017 16:20:54 -0700, Στέφανος Σωφρονίου wrote: > I do believe though that if (!d) is a lot clearer than if (d == NULL) > as it is safer than falsely assigning NULL in d, by pure mistake. Having made my living writing C code for a very long time, I always found if (!d) *harder* to

Re: Coding style in CPython implementation

On Saturday, October 28, 2017 at 9:54:30 PM UTC+3, bartc wrote: > On 28/10/2017 19:42, Στέφανος Σωφρονίου wrote: > > Greetings everyone. > > > > I have noticed that in many if conditions the following syntax is used: > > > > a) if (variable == NULL) { ... } > > b) if (variable == -1) { ... } > >

Re: Coding style in CPython implementation

On 10/28/17 4:26 PM, Stefan Ram wrote: Ned Batchelder writes: On 10/28/17 3:00 PM, Stefan Ram wrote: =?UTF-8?B?zqPPhM6tz4bOsc69zr/PgiDOo8+Jz4bPgc6/zr3Or86/z4U=?= writes: What I wanted to ask is, is there a particular reason for not

Re: Coding style in CPython implementation

On 10/28/17 3:00 PM, Stefan Ram wrote: =?UTF-8?B?zqPPhM6tz4bOsc69zr/PgiDOo8+Jz4bPgc6/zr3Or86/z4U=?= <stefanossofroniou...@gmail.com> writes: What I wanted to ask is, is there a particular reason for not choosing I am not a CPython developer, but here are my 2 cents

Re: Coding style in CPython implementation

lar reason for using this specific coding style? Have you read PEP 7? https://www.python.org/dev/peps/pep-0007/ PEP 7 and PEP 8 are a pair of style guides that govern the CPython source code - PEP 7 for the C code, and PEP 8 for the Python code in the standard library. Unfortunately, many peo

Re: Coding style in CPython implementation

On 28/10/2017 19:42, Στέφανος Σωφρονίου wrote: Greetings everyone. I have noticed that in many if conditions the following syntax is used: a) if (variable == NULL) { ... } b) if (variable == -1) { ... } c) if (variable != NULL) { ... } What I wanted to ask is, is there a particular reason for

Coding style in CPython implementation

Greetings everyone. I have noticed that in many if conditions the following syntax is used: a) if (variable == NULL) { ... } b) if (variable == -1) { ... } c) if (variable != NULL) { ... } What I wanted to ask is, is there a particular reason for not choosing a) if (!variable) { ... } in place

[issue31810] Travis CI, buildbots: run "make smelly" to check if CPython leaks symbols

Change by Zachary Ware : -- pull_requests: -4103 ___ Python tracker ___ ___

[issue31810] Travis CI, buildbots: run "make smelly" to check if CPython leaks symbols

Change by Tom Floyer : -- pull_requests: +4103 ___ Python tracker ___ ___

[issue31810] Travis CI, buildbots: run "make smelly" to check if CPython leaks symbols

STINNER Victor added the comment: "make smelly" is now run on Travis CI. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue31810] Travis CI, buildbots: run "make smelly" to check if CPython leaks symbols

STINNER Victor <victor.stin...@gmail.com> added the comment: New changeset 87d332dcdbffe8ff60d99f74b1ad241c0967b055 by Victor Stinner in branch 'master': bpo-31810: Add smelly.py to check exported symbols (#4057) https://github.com/python/cpython/commit/87d332dcdbffe8ff60d99f74b1ad241c09

[issue31810] Travis CI, buildbots: run "make smelly" to check if CPython leaks symbols

Change by Ned Deily : -- nosy: +ned.deily ___ Python tracker ___ ___ Python-bugs-list

[issue31810] Travis CI, buildbots: run "make smelly" to check if CPython leaks symbols

Change by STINNER Victor : -- pull_requests: +4026 ___ Python tracker ___ ___

[issue31810] Travis CI, buildbots: run "make smelly" to check if CPython leaks symbols

Change by Tal Einat : -- nosy: +taleinat ___ Python tracker ___ ___ Python-bugs-list

[issue31810] Travis CI, buildbots: run "make smelly" to check if CPython leaks symbols

Change by Sanyam Khurana : -- keywords: +patch pull_requests: +4023 stage: -> patch review ___ Python tracker ___

[issue31810] Travis CI, buildbots: run "make smelly" to check if CPython leaks symbols

STINNER Victor added the comment: Sanyam: please first try to write a change for Travis CI: modify .travis.yml, create a PR and check if it works. -- ___ Python tracker

[issue31810] Travis CI, buildbots: run "make smelly" to check if CPython leaks symbols

Sanyam Khurana added the comment: Hi Haypo, I'd like to work on a patch for this issue. Can you please guide me how the tests are configured for buildbots? -- nosy: +CuriousLearner ___ Python tracker

[issue31810] Travis CI, buildbots: run "make smelly" to check if CPython leaks symbols

rity: normal severity: normal status: open title: Travis CI, buildbots: run "make smelly" to check if CPython leaks symbols versions: Python 3.7 ___ Python tracker <rep...@bug

Re: How does CPython build it's NEWS or changelog?

Stefan Behnel writes: > https://docs.python.org/devguide/committing.html#what-s-new-and-news-entries > > https://github.com/larryhastings/blurb Also of interest is the more general-use Town Crier tool: towncrier is a utility to produce useful, summarised news files for

Re: How does CPython build it's NEWS or changelog?

Hartmut Goebel schrieb am 21.09.2017 um 10:59: > I just discovered that CPython now uses Misc/NEWS.d/next to collect > changes an there are a lot of Misc/NEWS/*.rst files for the respective > released version. I'm investigating whether to adopt this for PyInstaller. > > What

Re: How does CPython build it's NEWS or changelog?

On 21 September 2017 at 09:59, Hartmut Goebel <h.goe...@crazy-compilers.com> wrote: > Hello, > > I just discovered that CPython now uses Misc/NEWS.d/next to collect > changes an there are a lot of Misc/NEWS/*.rst files for the respective > released version. I'm investiga

Re: How does CPython build it's NEWS or changelog?

> I just discovered that CPython now uses Misc/NEWS.d/next to collect > changes an there are a lot of Misc/NEWS/*.rst files for the respective > released version. I'm investigating whether to adopt this for PyInstaller. > > What is the tooling for this? Is there some docum

How does CPython build it's NEWS or changelog?

Hello, I just discovered that CPython now uses Misc/NEWS.d/next to collect changes an there are a lot of Misc/NEWS/*.rst files for the respective released version. I'm investigating whether to adopt this for PyInstaller. What is the tooling for this? Is there some documentation, maybe

[issue31358] Pull zlib out to cpython-source-deps

Changes by Zachary Ware : -- resolution: -> fixed stage: commit review -> resolved status: open -> closed ___ Python tracker ___

[issue31358] Pull zlib out to cpython-source-deps

Zachary Ware added the comment: New changeset d01db1c2a2a71455163a1d3b214cc8dc27201303 by Zachary Ware in branch 'master': bpo-31358: Pull zlib out of the repository (GH-3375) https://github.com/python/cpython/commit/d01db1c2a2a71455163a1d3b214cc8dc27201303

[issue31358] Pull zlib out to cpython-source-deps

Matthias Klose added the comment: +1, if that's ok with the Windows maintainers. -- ___ Python tracker ___

[issue31358] Pull zlib out to cpython-source-deps

Changes by Zachary Ware : -- pull_requests: +3386 ___ Python tracker ___ ___

[issue31358] Pull zlib out to cpython-source-deps

New submission from Zachary Ware: We currently bundle zlib in our source at Modules/zlib, but it is only used on Windows. The soon-to-be-attached PR instead pulls it from https://github.com/python/cpython-source-deps There is one failure in test_venv only when zlib is not built at all, which

Re: cpython version

On Sun, Aug 13, 2017 at 10:59 PM, Gilmeh Serda wrote: > On Sat, 12 Aug 2017 10:24:06 -0400, Larry Martell wrote: > >> now I have prospective client that refuses to run linux, even in a VM. >> So I am tying to get my app running on Windows Server 2016, piece by

<    5   6   7   8   9   10   11   12   13   14   >