[Python-Dev] attributes of Python code objects
In PR 218 [1], INADA Naoki wrote: > I think attributes of Python's code object is implementation detail, even > though PyPy follows. > But it's not big problem until there are some Python implementation > having different code implementation. Python's code object attributes are described in the Data Model [2] section of the documentation. 1) Is this description normative (to be followed by all the implementations of the Python language)? 2) Is the description of co_lnotab in [3] normative ? Xavier [1] https://github.com/python/cpython/pull/218 [2] https://docs.python.org/3/reference/datamodel.html [3] https://github.com/python/cpython/blob/master/Objects/lnotab_notes.txt ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] attributes of Python code objects
On Sun, 26 Feb 2017 at 02:20 Xavier de Gaye wrote: > In PR 218 [1], INADA Naoki wrote: > > I think attributes of Python's code object is implementation detail, > even > > though PyPy follows. > > But it's not big problem until there are some Python implementation > > having different code implementation. > > Python's code object attributes are described in the Data Model [2] > section of > the documentation. 1) Is this description normative (to be followed by > all the > implementations of the Python language)? 2) Is the description of > co_lnotab > in [3] normative ? > That's a good question. "Code objects represent byte-compiled executable Python code, or bytecode" which would suggest that if an implementation didn't have a compiled code then code objects wouldn't make sense. Then again the object contains details about the function that can be useful and are relied upon by parts of the stdlib (e.g. inspect.signature() can't function without the code object). Due to that last point I would say the attributes on code objects are not an implementation detail, but it's acceptable for things like co_code to be set to None when it doesn't make sense. -Brett > > Xavier > > [1] https://github.com/python/cpython/pull/218 > [2] https://docs.python.org/3/reference/datamodel.html > [3] https://github.com/python/cpython/blob/master/Objects/lnotab_notes.txt > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Translated Python documentation
On Sat, 25 Feb 2017 at 11:59 INADA Naoki wrote: > Yes, right place to discussion is one of important things what I want. > I haven't know about i18n-sig. Is it better than docs-sig? > Probably not (I honestly forgot about docs-sig). > > > Another thing I want is agreement to use project name looks like > (semi)official project. > > We used "python-doc-jp" name on Transifex at first. But since some people > other than Japanese ask me to allow other languages, I renamed it to > "python-doc". > As Nick suggested, "python-docs" is probably a better name to be consistent. -Brett > And I reserved "python-docs" organization at Github. > > While it's better name for working together with other Language > translators, > I don't like that unofficial project use such name. > > > Hosting at docs.python.org is desirable too, but it can be discussed > later. > > Regards, > > On Sun, Feb 26, 2017 at 4:08 AM, Ned Deily wrote: > > On Feb 25, 2017, at 13:19, Brett Cannon wrote: > >> It's getting a little hard to tease out what exactly is being asked at > this point. Perhaps it's time to move the discussion over to a translation > SIG (which probably needs to be created unless the old > https://mail.python.org/mailman/listinfo/i18n-sig makes sense)? That way > active translators can figure out exactly what they want to ask of > python-dev in terms of support and we can have a more focused discussion. > > > > I agree. We would need a more concrete and detailed proposal to really > make any thoughtful decision. That may also include getting approval from > the PSF Board as they are ultimately responsible for the contents of > python.org. Without more detail, I don't have an opinion myself other > than to note that, if we do something, it needs to be careful to not > complicate or restrict the Python release process. > > > > -- > > Ned Deily > > n...@python.org -- [] > > > > ___ > > Python-Dev mailing list > > Python-Dev@python.org > > https://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] IMPORTANT: Python 3.6.1 RC delayed 4 days, now 2017-03-03
I had previously announced tomorrow as the date for the release candidate of our first 3.6 maintenance release. But, with the switchover to the new GitHub-based development process, there are a number of changes needed behind the scenes to our release production process and I think the release team (read "Ned") needs a few more days to get ready to produce the release. So, reluctantly, I'm delaying the cutoff and production of 3.6.1rc1 for 4 days, that is, until Friday 2017-03-03 UTC. As a plus, it gives us all a few more days to tackle the release-blocker, deferred-blocker, and critical issues still open against 3.6 and also to keep working though the new development process. For now, I'm not changing the date for 3.6.1 final (2017-03-13) until we see how rc1 goes. My apologies for the delay! --Ned Begin forwarded message: > From: Ned Deily > Subject: IMPORTANT: Python 3.6.1 Maintenance Release Release Candidate in 7 > days (2017-02-27) > Date: February 20, 2017 at 15:12:47 EST > To: python-committers > Cc: Python Dev > > It seems like last year already since the release of 3.6.0. I guess that's > because it was last year, 2016-12-22 to be exact! Now we're approaching the > end of the first quarter and, according to PEP 494, it's time to start > producing the first maintenance release for the 3.6 series. The schedule > calls for the release candidate to be produced on Monday 2017-02-27 UTC. As > was the case with the 3.6.0 release cycle, the plan is for the release > candidate to be the same as the final release, that is, no additional changes > go in after the release candidate except for any showstopper critical > problems that might be discovered with rc1. So please plan to get any > security fixes, bug fixes, and documentation changes you think should be in > 3.6.1 merged in before 2017-02-27. I will send out another reminder a couple > of days before. The 3.6.1 final is planned for two weeks following rc1, that > is, on 2017-03-13. I expect the next 3.6 maintenance release (3.6.2) will > follow about 3 months lat er, so most likely in 2017-06 after PyCon US. > > 3.6.1 will be the first release using our new GitHub-based development > process (thanks, Brett and team!). If you are planning to push something for > 3.6.1 and haven't yet tried out the new workflow or are not yet familiar with > GitHub pull requests, you should probably give yourself some extra time. As > always, the Developer's Guide is the primary reference for the development > workflow; not surprisingly, with such a major change, there are likely still > some parts of the guide that could use further changes and clarifications. > You can help by reviewing the devguide's open issues and pull requests in its > repository and adding to them as you work through issues. If you have > comments on or improvement suggestions for the new workflow, the place to > discuss them is on the core-workflow mailing list. > > Thanks again for all of your efforts in bringing 3.6.0 into the world and for > helping now to make it even better! > > https://www.python.org/dev/peps/pep-0494/ > http://cpython-devguide.readthedocs.io > https://mail.python.org/mailman/listinfo/core-workflow -- Ned Deily n...@python.org -- [] ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Translated Python documentation
On 24/02/2017 12:20, Berker Peksağ wrote: On Thu, Feb 23, 2017 at 12:01 AM, Victor Stinner wrote: 2017-02-22 19:04 GMT+01:00 Serhiy Storchaka : What percent of lines is changed between bugfix releases? Feature releases? My largest apprehension is that the documentation can be outdated and quickly become degraded if main contributors left it. If the original text (english) changes, untranslated text is displayed, not outdated text. I think that's much worse than showing the outdated text. I don't see any point on showing half English and half French text if the reader can't understand the other half of it. Fair point (especially if you substitute a language totally unrelated to English (e.g. Turkish, Finnish, Urdu, Japanese) for "French"). But it can be turned around: Popular demand would encourage whoever is maintaining the translated versions to catch up within a reasonable time when changes are made. It would nudge non-English readers to look at the untranslated English text and begin/develop their knowledge of English. Best wishes, Rob Cliffe ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Translated Python documentation
Could we have side-by-side English and whatever translated language? Then also use some sort of typographic indicator like color to show when the translation is out of date? On Feb 26, 2017 6:39 PM, "Rob Cliffe" wrote: > > > On 24/02/2017 12:20, Berker Peksağ wrote: > >> On Thu, Feb 23, 2017 at 12:01 AM, Victor Stinner >> wrote: >> >>> 2017-02-22 19:04 GMT+01:00 Serhiy Storchaka : >>> What percent of lines is changed between bugfix releases? Feature releases? My largest apprehension is that the documentation can be outdated and quickly become degraded if main contributors left it. >>> If the original text (english) changes, untranslated text is >>> displayed, not outdated text. >>> >> I think that's much worse than showing the outdated text. I don't see >> any point on showing half English and half French text if the reader >> can't understand the other half of it. >> >> Fair point (especially if you substitute a language totally unrelated to > English (e.g. Turkish, Finnish, Urdu, Japanese) for "French"). But it can > be turned around: > Popular demand would encourage whoever is maintaining the translated > versions to catch up within a reasonable time when changes are made. > It would nudge non-English readers to look at the untranslated English > text and begin/develop their knowledge of English. > Best wishes, > Rob Cliffe > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/mertz% > 40gnosis.cx > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] attributes of Python code objects
On 27 February 2017 at 06:44, Brett Cannon wrote: > > > On Sun, 26 Feb 2017 at 02:20 Xavier de Gaye wrote: > >> In PR 218 [1], INADA Naoki wrote: >> > I think attributes of Python's code object is implementation detail, >> even >> > though PyPy follows. >> > But it's not big problem until there are some Python implementation >> > having different code implementation. >> >> Python's code object attributes are described in the Data Model [2] >> section of >> the documentation. 1) Is this description normative (to be followed by >> all the >> implementations of the Python language)? 2) Is the description of >> co_lnotab >> in [3] normative ? >> > > That's a good question. "Code objects represent byte-compiled executable > Python code, or bytecode" which would suggest that if an implementation > didn't have a compiled code then code objects wouldn't make sense. Then > again the object contains details about the function that can be useful and > are relied upon by parts of the stdlib (e.g. inspect.signature() can't > function without the code object). > > Due to that last point I would say the attributes on code objects are not > an implementation detail, but it's acceptable for things like co_code to be > set to None when it doesn't make sense. > Right, we should probably try to be more explicit about this, as there are certainly aspects of the code object structure that other implementations will need to emulate if they want to re-use modules like inspect without modification. However, there are also aspects that we explicitly call out as implementation details, like the internal structure of co_code and co_lnotab, where they may change arbitrarily between CPython feature releases. The generator and coroutine ABCs were also specifically added so they could be replaced with objects that don't have __code__.co_flags attributes (e.g. by Cython) without breaking asyncio. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Translated Python documentation
On 27 February 2017 at 14:03, David Mertz wrote: > Could we have side-by-side English and whatever translated language? Then > also use some sort of typographic indicator like color to show when the > translation is out of date? > This kind of interface is what services like Transifex and Zanata offer translators (they also have things like phrase dictionaries, showing how particular terms have been translated elsewhere in the project). For the actual documentation, showing partial translations is the standard practice, as the assumption is that many readers will have *some* ability to read English, they just prefer to read their native language. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
