[Python-Dev] API bloat
At sometime between versions 3.1 and the current version, 3.1.3, the API grew considerably. See http://docs.python.org/release/3.1/c-api/exceptions.html#exception-handling and http://docs.python.org/py3k/c-api/exceptions.html#exception-handling The Unicode Exception Objects section is new and seemingly redundant: http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects Should this be in the public API? Is there any kind of review system (like PEPs) for modifying the C API? Are bug-fix updates really the place to modify the API? Could the API be reverted to the 3.1 version plus any *necessary* changes in time for the 3.2 release? Remember the C API is a promise to support these functions for years to come and a burden on other implementations, including future CPythons. So could the CPython internal APIs be kept out of the public API? Please. Cheers, Mark. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API bloat
Am 09.02.2011 10:09, schrieb Mark Shannon: > At sometime between versions 3.1 and the current version, 3.1.3, > the API grew considerably. > See > http://docs.python.org/release/3.1/c-api/exceptions.html#exception-handling > and > http://docs.python.org/py3k/c-api/exceptions.html#exception-handling > > The Unicode Exception Objects section is new and seemingly redundant: Why redundant? > http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects > Should this be in the public API? While this question is valid, it *should* have been asked 8 years ago, when the functions were actually added. They are new in the docs because they weren't documented before. Otherwise they would have a "New in version 3.2" tag. > Is there any kind of review system (like PEPs) for modifying the C API? No, but python-dev is involved by either a thread here or an issue that is then OK'd by several developers. > Are bug-fix updates really the place to modify the API? No, but that's not relevant here. > Could the API be reverted to the 3.1 version plus any *necessary* > changes in time for the 3.2 release? Any changes in API are definitely forbidden before 3.2. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API bloat
Georg Brandl wrote: Am 09.02.2011 10:09, schrieb Mark Shannon: At sometime between versions 3.1 and the current version, 3.1.3, the API grew considerably. See http://docs.python.org/release/3.1/c-api/exceptions.html#exception-handling and http://docs.python.org/py3k/c-api/exceptions.html#exception-handling The Unicode Exception Objects section is new and seemingly redundant: Why redundant? Because they are all attribute getter and setters. For example: PyUnicodeDecodeError_GetStart(exc, x) <=> PyObject_GetAttr(exc, "start", x) This sort of redundancy seems sensible for list, tuple and such. It just seems like bloat for classes like UnicodeDecodeError. http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects Should this be in the public API? While this question is valid, it *should* have been asked 8 years ago, when the functions were actually added. The functions may have been add to CPython 8 years ago, but they were added to the API when they appeared in the docs, between 3.1 and 3.1.3. How is the API defined, if not by the documentation? The header files do not specify what is API and what is implementation specific. They are new in the docs because they weren't documented before. Otherwise they would have a "New in version 3.2" tag. Is there any kind of review system (like PEPs) for modifying the C API? No, but python-dev is involved by either a thread here or an issue that is then OK'd by several developers. Are bug-fix updates really the place to modify the API? No, but that's not relevant here. Could the API be reverted to the 3.1 version plus any *necessary* changes in time for the 3.2 release? Any changes in API are definitely forbidden before 3.2. If that is the case then the API, as defined by http://docs.python.org/py3k/c-api/index.html should be same for 3.2 as for 3.1, plus a few functions, that are explicitly marked as "New in version 3.2". Unfortunately, that is not currently the case. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/marks%40dcs.gla.ac.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API bloat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (Not sure if your message went to python-dev too.) Am 09.02.2011 11:04, schrieb Mark Shannon: > Georg Brandl wrote: >> Am 09.02.2011 10:09, schrieb Mark Shannon: >>> At sometime between versions 3.1 and the current version, 3.1.3, >>> the API grew considerably. >>> See >>> http://docs.python.org/release/3.1/c-api/exceptions.html#exception-handling >>> and >>> http://docs.python.org/py3k/c-api/exceptions.html#exception-handling >>> >>> The Unicode Exception Objects section is new and seemingly redundant: >> >> Why redundant? > > Because they are all attribute getter and setters. For example: > > PyUnicodeDecodeError_GetStart(exc, x) <=> > PyObject_GetAttr(exc, "start", x) > > This sort of redundancy seems sensible for list, tuple and such. > It just seems like bloat for classes like UnicodeDecodeError. Have you looked at the implementation? They do some more, e.g. make sure the returned value is within the boundaries of the offending string. (Yes, that probably should be in the docs too.) >>> http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects >>> Should this be in the public API? >> >> While this question is valid, it *should* have been asked 8 years ago, when >> the functions were actually added. > > The functions may have been add to CPython 8 years ago, but they were > added to the API when they appeared in the docs, between 3.1 and 3.1.3. > > How is the API defined, if not by the documentation? > The header files do not specify what is API and what is implementation > specific. The API is defined by all functions (and macros, and types) defined by the headers starting with a "Py" prefix. Implementation specific functions have a "_Py" prefix. - From 3.2, we also have a "Limited API" (see PEP 384) that defines a set of API that will not change, and is guaranteed to have a consistent ABI between Python minor versions. >>> Could the API be reverted to the 3.1 version plus any *necessary* >>> changes in time for the 3.2 release? >> >> Any changes in API are definitely forbidden before 3.2. > > If that is the case then the API, as defined by > http://docs.python.org/py3k/c-api/index.html > should be same for 3.2 as for 3.1, plus a few functions, > that are explicitly marked as "New in version 3.2". > > Unfortunately, that is not currently the case. In any case, these are doc bugs. In the past, many additions to the C API were made without proper documentation changes, and we are still working to clean this up. So, yes: modulo doc bugs, any function that newly appears in the 3.2 docs either has a "New in version 3.2" tag, or has been present in 3.1 already. Georg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk1ScT4ACgkQN9GcIYhpnLDEjwCggMLnpWoeL7Vpg3SiZlfJvJ0H 2isAn0hhBmbUelr4Of+kAqPopWc5s5ro =xYhv -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API bloat
On Wed, 09 Feb 2011 10:37:11 + Mark Shannon wrote: > > > > Why redundant? > > Because they are all attribute getter and setters. For example: > > PyUnicodeDecodeError_GetStart(exc, x) <=> > PyObject_GetAttr(exc, "start", x) > > This sort of redundancy seems sensible for list, tuple and such. > It just seems like bloat for classes like UnicodeDecodeError. It's not exactly the same thing, still. PyObject_GetAttr() will do a full blown attribute access, while I guess (I didn't check) PyUnicodeDecodeError_GetStart() accesses the C struct member directly. Also, the latter gives you a Py_ssize_t object, which relieves you from having to do a conversion explicitly. I do agree that it doesn't seem widely used, according to Google Code Search :) > >> http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects > >> Should this be in the public API? > > > > While this question is valid, it *should* have been asked 8 years ago, when > > the functions were actually added. > > The functions may have been add to CPython 8 years ago, but they were > added to the API when they appeared in the docs, between 3.1 and 3.1.3. > > How is the API defined, if not by the documentation? > The header files do not specify what is API and what is implementation > specific. True. But if they were added to the documentation, it's certainly because they were *intended* to be part of the API from the start. (after all, core CPython code can just access the C struct fields directly rather than go through a function call) Take it as acknowledging that it has *always* been part of the intended API. These days, we try to follow a stricter naming convention: when we want an API to remain explicitly private, we often prefix it with an underscore. But that has not been the case in the past, I admit. > > Any changes in API are definitely forbidden before 3.2. > > If that is the case then the API, as defined by > http://docs.python.org/py3k/c-api/index.html > should be same for 3.2 as for 3.1, plus a few functions, > that are explicitly marked as "New in version 3.2". > > Unfortunately, that is not currently the case. How so? Can you give an example? Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API bloat
Mark Shannon wrote: > The Unicode Exception Objects section is new and seemingly redundant: > http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects > Should this be in the public API? Those function have been in the public API since we introduced Unicode callbak error handlers. It was an oversight that these were not documented in the Python documentation. They have been documented part of the unicodeobject.h ever since they were introduced. Note that these APIs are needed by codecs supporting the callback error handlers, and since performance matters a lot for codecs, the C APIs were introduced. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 09 2011) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API bloat
M.-A. Lemburg wrote: Mark Shannon wrote: The Unicode Exception Objects section is new and seemingly redundant: http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects Should this be in the public API? Those function have been in the public API since we introduced Unicode callbak error handlers. It was an oversight that these were not documented in the Python documentation. They have been documented part of the unicodeobject.h ever since they were introduced. Note that these APIs are needed by codecs supporting the callback error handlers, and since performance matters a lot for codecs, the C APIs were introduced. OK, so UnicodeError_xxx is important for codecs, but surely this sort of argument could be made for lots of things. Don't forget that for each function added to the API, all other implementations have to support it forever. Unfortunately, UnicodeError_xxx are not the only new functions. Various others have been added: int Py_EnterRecursiveCall(char *where) void Py_LeaveRecursiveCall() int Py_ReprEnter(PyObject *object) void Py_ReprLeave(PyObject *object) HotPyModule_GetFilenameObject HotPy_CompileStringExFlags and a few others. Individual functions are not the problem, I'm sure all of these can be justified, its lack of process and review that bothers me. Mark. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API bloat
On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon wrote: > OK, so UnicodeError_xxx is important for codecs, but surely this sort of > argument could be made for lots of things. > Don't forget that for each function added to the API, > all other implementations have to support it forever. Other implementations that want to support CPython extensions should focus their efforts on the limited API defined in PEP 384. That will not only be a lot easier, it will also be less of a moving target. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API bloat
On 12:43 pm, [email protected] wrote: On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon wrote: OK, so UnicodeError_xxx is important for codecs, but surely this sort of argument could be made for lots of things. Don't forget that for each function added to the API, all other implementations have to support it forever. Other implementations that want to support CPython extensions should focus their efforts on the limited API defined in PEP 384. That will not only be a lot easier, it will also be less of a moving target. And will produce what kind of results? How many extension libraries work with this subset? Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API bloat
2011/2/9 : > On 12:43 pm, [email protected] wrote: >> >> On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon wrote: >>> >>> OK, so UnicodeError_xxx is important for codecs, but surely this sort of >>> argument could be made for lots of things. >>> Don't forget that for each function added to the API, >>> all other implementations have to support it forever. >> >> Other implementations that want to support CPython extensions should >> focus their efforts on the limited API defined in PEP 384. That will >> not only be a lot easier, it will also be less of a moving target. > > And will produce what kind of results? How many extension libraries work > with this subset? Probably none because it hasn't been released. That's the goal. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API bloat
On Wed, Feb 9, 2011 at 11:03 PM, wrote: > On 12:43 pm, [email protected] wrote: >> >> On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon wrote: >>> >>> OK, so UnicodeError_xxx is important for codecs, but surely this sort of >>> argument could be made for lots of things. >>> Don't forget that for each function added to the API, >>> all other implementations have to support it forever. >> >> Other implementations that want to support CPython extensions should >> focus their efforts on the limited API defined in PEP 384. That will >> not only be a lot easier, it will also be less of a moving target. > > And will produce what kind of results? How many extension libraries work > with this subset? Right now? Very few, given the changes to the way types need to be created. But prioritising it will speed convergence over time as more extension modules cut over to it for the stable ABI benefits. And, since the C API has never been anywhere near as tightly controlled as the language definition, alternative implementations are going to garner more sympathy if they restrict their concerns to the growth of the stable ABI rather than worrying about an implementation detail of CPython. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API bloat
2011/2/9 Mark Shannon : > OK, so UnicodeError_xxx is important for codecs, but surely this sort of > argument could be made for lots of things. > Don't forget that for each function added to the API, > all other implementations have to support it forever. The C-API is about the biggest implementation detail of CPython, so no, they don't have to. > > Unfortunately, UnicodeError_xxx are not the only new functions. > > Various others have been added: > > int Py_EnterRecursiveCall(char *where) > void Py_LeaveRecursiveCall() > int Py_ReprEnter(PyObject *object) > void Py_ReprLeave(PyObject *object) > > HotPyModule_GetFilenameObject > HotPy_CompileStringExFlags > > and a few others. > > Individual functions are not the problem, > I'm sure all of these can be justified, > its lack of process and review that bothers me. If they can be justified, what is the process lacking? -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API bloat
On 09/02/2011 14:00, Benjamin Peterson wrote: 2011/2/9 Mark Shannon: OK, so UnicodeError_xxx is important for codecs, but surely this sort of argument could be made for lots of things. Don't forget that for each function added to the API, all other implementations have to support it forever. The C-API is about the biggest implementation detail of CPython, so no, they don't have to. Alternative implementations that want C extensions to work (like Ironclad for IronPython and cpyext for pypy) do implement the parts of the C API that are most widely used though. Of course they don't *have to*, but c extension compatibility is one of the biggest problems for users of alternative implementations. Hopefully the stable ABI will improve this situation for the future, but realistically its going to be a few years before it has an appreciable effect. Michael Unfortunately, UnicodeError_xxx are not the only new functions. Various others have been added: int Py_EnterRecursiveCall(char *where) void Py_LeaveRecursiveCall() int Py_ReprEnter(PyObject *object) void Py_ReprLeave(PyObject *object) HotPyModule_GetFilenameObject HotPy_CompileStringExFlags and a few others. Individual functions are not the problem, I'm sure all of these can be justified, its lack of process and review that bothers me. If they can be justified, what is the process lacking? -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API bloat
On 09/02/2011 13:59, Nick Coghlan wrote: [snip...] And, since the C API has never been anywhere near as tightly controlled as the language definition, alternative implementations are going to garner more sympathy if they restrict their concerns to the growth of the stable ABI rather than worrying about an implementation detail of CPython. Actually the opposite. Users tend to be very unsympathetic when extensions they depend on don't work with alternative implementations (I speak from experience). Michael Cheers, Nick. -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API bloat
On 01:59 pm, [email protected] wrote: On Wed, Feb 9, 2011 at 11:03 PM, wrote: On 12:43 pm, [email protected] wrote: On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon wrote: OK, so UnicodeError_xxx is important for codecs, but surely this sort of argument could be made for lots of things. Don't forget that for each function added to the API, all other implementations have to support it forever. Other implementations that want to support CPython extensions should focus their efforts on the limited API defined in PEP 384. That will not only be a lot easier, it will also be less of a moving target. And will produce what kind of results? How many extension libraries work with this subset? Right now? Very few, given the changes to the way types need to be created. But prioritising it will speed convergence over time as more extension modules cut over to it for the stable ABI benefits. And, since the C API has never been anywhere near as tightly controlled as the language definition, alternative implementations are going to garner more sympathy if they restrict their concerns to the growth of the stable ABI rather than worrying about an implementation detail of CPython. Sympathy, perhaps. But that doesn't mean people will drop everything and rewrite their extension modules. Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API bloat
On Wed, 09 Feb 2011 12:11:43 + Mark Shannon wrote: > Various others have been added: > > int Py_EnterRecursiveCall(char *where) > void Py_LeaveRecursiveCall() > int Py_ReprEnter(PyObject *object) > void Py_ReprLeave(PyObject *object) Again, they haven't been "added". They have been there for a long time; it's just that they weren't documented before (either because it was overlooked or out of laziness, I don't know). And these 4 functions are definitely useful for extension modules. > HotPyModule_GetFilenameObject > HotPy_CompileStringExFlags Judging by the "HotPy" prefix, these aren't CPython functions ;) > I'm sure all of these can be justified, > its lack of process and review that bothers me. Process and review of new APIs usually go through the issue tracker. We also have a ton of new stdlib APIs in 3.2: http://docs.python.org/dev/whatsnew/3.2.html If each of these new APIs went through a python-dev discussion, this mailing-list would become a huge mess. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API bloat
On Wed, 09 Feb 2011 14:13:11 - [email protected] wrote: > >And, since the C API has never been anywhere near as tightly > >controlled as the language definition, alternative implementations are > >going to garner more sympathy if they restrict their concerns to the > >growth of the stable ABI rather than worrying about an implementation > >detail of CPython. > > Sympathy, perhaps. But that doesn't mean people will drop everything > and rewrite their extension modules. Using the stable ABI should have maintenance advantages, since you don't have to compile a separate package for each Python version. How far distutils goes to support version-independent binary distributions I don't know, though. But at least the stable ABI is a step in that direction. And of course you don't need to "rewrite your extension modules". Apparently type definitions have to be adapted, and you have to make sure you aren't using functions that are not in the limited API, but otherwise things should work fine. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] python 3.2 (fwd)
Passing this along from webmaster. S --- Begin Message --- Not sure who to address this question to. Would you please forward it as you feel is appropriate? The python 3.2 release notes say that it compiles against sqlite "2.6". Does that mean it includes the pysqlite 2.6 module which links against sqlite 3.x ? I can't imagine that the new version really uses an sqlite that is so old, but taken literally, that's what the release notes say. Not trying to be picky; just want to make sure I understand what I'm about to get. (Can you let me know what version of *sqlite* will be incorporated (3.7.5?)?) Very excited about the improvements in 3.2 esp the GIL! Thanks, Mayur --- End Message --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3.2 (fwd)
On 2/9/2011 12:32 PM, [email protected] wrote: Passing this along from webmaster. It is hard to reply to an attachment rather than inline forwarded message. However, with rc1 >>> import sqlite3 >>> sqlite3.version '2.6.0' >>> sqlite3.sqlite_version '3.7.4' I added 'pysqlite' to the "What's new" entry. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API bloat
> The functions may have been add to CPython 8 years ago, but they were > added to the API when they appeared in the docs, between 3.1 and 3.1.3. > > How is the API defined, if not by the documentation? Just to stress and support Georg's explanation: the API is *not* defined through the documentation, but instead primarily through the header files. All functions declared as PyAPI_FUNC and not starting with _Py are public API. There used to be a lot of undocumented API (up to 1.4, there was no API documentation at all, only the extension module tutorial); these days, more and more API gets documented. HTH, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] devguide: More clarifications: use the term 'working copy' and mention 'hg update'.
On Wed, 09 Feb 2011 21:17:51 +0100 brett.cannon wrote: > > > -One should always work from a checkout of the CPython source code. While it > may > +One should always work from a working copy of the CPython source code. > +While it may > be tempting to work from the downloaded copy you already have installed on > your The difference between "downloaded copy" and "working copy" isn't very clear. The important difference here is between "official stable version" and "latest development sources". > -To get a read-only checkout of CPython's source, you need to checkout the > source > -code. To get a read-only checkout of > +To get a read-only checkout of CPython's source, you need a working copy the > +source code. To get a read-only checkout of Why talk about "checkout" at all? It's an SVN/CVS/RCS term, if I'm not mistaken (even though it may occasionally be used with hg, it's a synonym of "working copy" there). Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] devguide: More clarifications: use the term 'working copy' and mention 'hg update'.
On Wed, Feb 9, 2011 at 12:29, Antoine Pitrou wrote: > On Wed, 09 Feb 2011 21:17:51 +0100 > brett.cannon wrote: >> >> >> -One should always work from a checkout of the CPython source code. While it >> may >> +One should always work from a working copy of the CPython source code. >> +While it may >> be tempting to work from the downloaded copy you already have installed on >> your > > The difference between "downloaded copy" and "working copy" isn't very > clear. The important difference here is between "official stable > version" and "latest development sources". I'll clarify. > >> -To get a read-only checkout of CPython's source, you need to checkout the >> source >> -code. To get a read-only checkout of >> +To get a read-only checkout of CPython's source, you need a working copy the >> +source code. To get a read-only checkout of > > Why talk about "checkout" at all? It's an SVN/CVS/RCS term, if I'm not > mistaken (even though it may occasionally be used with hg, it's a > synonym of "working copy" there). Since it's a synonym I didn't worry about it. I honestly just thought it flowed better. -Brett > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] devguide: More clarifications: use the term 'working copy' and mention 'hg update'.
> > > >> -To get a read-only checkout of CPython's source, you need to checkout the > >> source > >> -code. To get a read-only checkout of > >> +To get a read-only checkout of CPython's source, you need a working copy > >> the > >> +source code. To get a read-only checkout of > > > > Why talk about "checkout" at all? It's an SVN/CVS/RCS term, if I'm not > > mistaken (even though it may occasionally be used with hg, it's a > > synonym of "working copy" there). > > Since it's a synonym I didn't worry about it. I honestly just thought > it flowed better. What I meant is that "To get a read-only checkout, you need a working copy" is kind of tautologic then. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] devguide: More clarifications: use the term 'working copy' and mention 'hg update'.
Le 09/02/2011 23:49, Brett Cannon a écrit : > On Wed, Feb 9, 2011 at 12:29, Antoine Pitrou wrote: >>> -To get a read-only checkout of CPython's source, you need to checkout the >>> source >>> -code. To get a read-only checkout of >>> +To get a read-only checkout of CPython's source, you need a working copy >>> the >>> +source code. To get a read-only checkout of “you need a working copy the source code” → “you need to clone the source code repository” (see below for more) >> Why talk about "checkout" at all? It's an SVN/CVS/RCS term, if I'm not >> mistaken (even though it may occasionally be used with hg, it's a >> synonym of "working copy" there). > Since it's a synonym I didn't worry about it. I honestly just thought > it flowed better. Agreed. The problem is that the terms do not map 1:1 from Subversion. When Subversion docs talk about getting a checkout, Mercurial tells to make a clone (which includes the working copy); in other cases, a strict distinction between repository and working copy is needed. I see no problems in using checkout when it flows better than working copy (especially as a verb). Sincerely hoping I don’t make things more confusing, Regards ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] devguide: Fix a silly statement.
Am 09.02.2011 23:58, schrieb brett.cannon: > brett.cannon pushed 7101df1bd817 to devguide: > > http://hg.python.org/devguide/rev/7101df1bd817 > changeset: 291:7101df1bd817 > branch: hg_transition > tag: tip > user:Brett Cannon > date:Wed Feb 09 14:58:17 2011 -0800 > summary: > Fix a silly statement. > > files: > setup.rst > > diff --git a/setup.rst b/setup.rst > --- a/setup.rst > +++ b/setup.rst > @@ -34,8 +34,7 @@ > :abbr:`VCS`. It also means you will have better tool > support through the VCS as it will provide a diff tool, etc. > > -To get a read-only checkout of CPython's source, you need a working copy the > -source code. To get a read-only checkout of > +To get a read-only checkout of > the :ref:`in-development ` branch of Python, run:: > > hg clone http://hg.python.org/cpython This statement is still somewhat silly, as a) you get a clone, not a checkout and b) it is not read only in any way: you can commit just fine. The only difference will be the entry in .hg/hgrc pointing the default repo to something you can't push to. Skimming through, the whole section "Checking out the code" is still way too SVN-point of viewy (e.g. you always get all branches anyway). Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] devguide: More clarifications: use the term 'working copy' and mention 'hg update'.
On 2/9/2011 3:29 PM, Antoine Pitrou wrote: Why talk about "checkout" at all? It's an SVN/CVS/RCS term, if I'm not mistaken (even though it may occasionally be used with hg, it's a synonym of "working copy" there). I believe it harkens back to early source code control systems where one person literally 'checked out' a file and got a write lock on it, similar to checking out a particular volume from the library )except that others could still read, unlike with the library). yes. good riddance (already done). -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
