Re: [Python-Dev] Breaking undocumented API
On Wed, Nov 10, 2010 at 10:23 PM, Michael Foord wrote: > On 09/11/2010 22:09, Nick Coghlan wrote: >> The new unittest package in 2.7 and 3.2 also uses it in the module >> __init__ to present the old "flat" namespace despite become a package >> under the hood. > > Look again. :-) > > Benjamin did the refactoring into a package and he obviously dislikes > "import *" as much as me. If he had used "import *" I would have changed it > anyway, but he didn't. > > We also define a __all__ to make the exported names explicit. Fair cop :) (and in that particular case, the maintenance burden in being explicit is minimal, since new top-level names in unittest are going to be significantly more rare than new methods on existing unittest classes) Even some of the acceleration modules (such as _hashlib) use approaches that are more explicit than using "import *". The point at least stands for the cases where the pure Python version is largely agnostic as to exactly which names the acceleration module overrides. It's a very, very niche use case though, so the default position of "if you use a star import anywhere other than at the interactive prompt, you're most like wrong to do so" is still a reasonable stance to take :) 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] [Python-checkins] r86355 - python/branches/py3k/Modules/_pickle.c
On Tuesday 09 November 2010 17:23:23 Alexander Belopolsky wrote: > On Tue, Nov 9, 2010 at 4:39 AM, victor.stinner > wrote: > .. > > > Log: > > Issue #10359: Remove useless comma, invalid in ISO C > > C99 allows it. Which compiler is giving you trouble? I don't know, but the commit is trivial and cheap. If it improves the support on uncommon compiler, I agree to commit such change. Victor ___ 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] Breaking undocumented API
On 10 November 2010 04:12, Stephen J. Turnbull wrote: > Nick Coghlan writes: > > > > Module writers who compound the error by expecting to be imported > > > this way, thereby bogarting the global namespace for their own > > > purposes, should be fish-slapped. ;) > > > > Be prepared to fish-slap all of python-dev then - we use precisely > > this technique to support optional acceleration modules. The pure > > Python versions of pairs like profile/_profile and heapq/_heapq > > include a try/except block at the end that does the equivalent of: > > > > try: > > from _accelerated import * # Allow accelerated overrides > > except ImportError: > > pass # Use pure Python versions > > But these identifiers will appear at the module level, not global, no? > Otherwise this technique couldn't be used. I don't really understand > what Tres is talking about when he writes "modules that expect to be > imported this way". The *imported* module shouldn't care, no? This > is an issue for the *importing* code to deal with. I can't think of stdlib examples, but for 3rd party packages I'd say storm.locals and fabric.api are examples of packages designed with "from foo import * " in mind. So this does happen. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.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] Breaking undocumented API
On 11/10/2010 05:12 AM, Stephen J. Turnbull wrote: But these identifiers will appear at the module level, not global, no? Otherwise this technique couldn't be used. I don't really understand what Tres is talking about when he writes "modules that expect to be imported this way". The *imported* module shouldn't care, no? I think he's referring to the choice of identifiers, and the usage examples given in the documentation and tutorials. For example, in the original PyGTK, all identifiers included "Gtk" in the name, so it made sense to write from pygtk import * so you could spell GtkWindow as GtkWindow rather than the redundant pygtk.GtkWindow. In that sense the module writer "expected" to be imported this way, although you are right that it doesn't the least bit matter for the correct operation of the module itself. For GTK 2 PyGTK switch to "gtk.Window", which effectively removes the temptation to import * from the module. There are other examples of that school, most notably ctypes, but also Tkinter and the python2 threading module. Fortunately it has become much less popular in the last ~5 years of Python history. ___ 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] bugs.python.org migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/11/10 22:17, "Martin v. Löwis" wrote: > bugs.python.org is moving to a new hardware; this also involves a new IP > address. The migration will happen on Thursday, likely around 8:00 UTC. > If all goes well, outage should be very short. Seems to be offline now. I get timeouts. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [email protected] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[email protected] _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTNqDV5lgi5GaxT1NAQLrSQP+KsvV9ZUWWPmLQT7cavH6IiuEDIwq+qDS eoQIa149Qv2G7W8rRkQLK1KcpCyyF50vPdTLuTksZXjm3aHikIuTVkIWSoQUhTUy 4Un1rNF9KC2mEtBuEUDyREoAEgpC4tMxXucYUGl37IM9HUqVCd9MWrG9Paf6EAs8 d1yfY7PNGvE= =jTk0 -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] Breaking undocumented API
On Nov 10, 2010, at 5:47 AM, Michael Foord wrote: > > So it is obvious that we don't have a clearly stated policy for what defines > the public API of standard library modules. > > How about making this explicit (either pep 8 or our developer docs): I believe the point of Guido's email was that it is a situation dependent judgment call and not readily boiled down to a set of rules for PEP 8. Raymond ___ 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] Breaking undocumented API
On 09/11/2010 22:09, Nick Coghlan wrote: On Wed, Nov 10, 2010 at 4:49 AM, Tres Seaver wrote: Outside an interactive prompt, anyone using "from foo import *" has set themselves and their users up to lose anyway. That syntax is the single worst misfeature in all of Python. It impairs readability and discoverability for *no* benefit beyond one-time typing convenience. Module writers who compound the error by expecting to be imported this way, thereby bogarting the global namespace for their own purposes, should be fish-slapped. ;) Be prepared to fish-slap all of python-dev then - we use precisely this technique to support optional acceleration modules. The pure Python versions of pairs like profile/_profile and heapq/_heapq include a try/except block at the end that does the equivalent of: try: from _accelerated import * # Allow accelerated overrides except ImportError: pass # Use pure Python versions This allows each implementation to make its own decisions about exactly which parts to accelerate without needing to change the pure Python version. In CPython itself, different *builds* may vary based on which components are available during the build process. There are utility functions provided in test.support that allow us to make sure that these modules are tested both with and without their accelerated components. The new unittest package in 2.7 and 3.2 also uses it in the module __init__ to present the old "flat" namespace despite become a package under the hood. Look again. :-) Benjamin did the refactoring into a package and he obviously dislikes "import *" as much as me. If he had used "import *" I would have changed it anyway, but he didn't. We also define a __all__ to make the exported names explicit. All the best, Michael Star imports are certainly open to abuse, but there are legitimate use cases when you want to lie about where particular APIs live in the module heirarchy. Those use cases generally involve being imported by one *specific* other module, such that anyone else importing the module directly *at all* is already doing the wrong thing. Cheers, Nick. -- http://www.voidspace.org.uk/ READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] Breaking undocumented API
On 08/11/2010 22:07, Raymond Hettinger wrote: On Nov 8, 2010, at 11:58 AM, Brett Cannon wrote: I think we need to, as a group, decide how to handle undocumented APIs that don't have a leading underscore: they get treated just the same as the documented APIs, or are they private regardless and thus we can change them at our whim? To start with, it doesn't hurt for a maintainer to add an __all__ entry and to only document the parts of the API we think need to be exposed. That way, we can at least declare the parts that are intended to be public on a go-forward basis. For the most part, the non-underscored parts of the API shouldn't be changed "at our whim". Some sense needs to be applied to the decision. Google's code search is great for showing how people actually have used a module in real world code. If that shows that people are accessing and/or changing an attribute, it probably needs to remain exposed. In the absence of a code search, good guesses can be made about what someone might reasonably and usefully be accessing (i.e. glob0 isn't likely). The goal is to improve the standard library while minimizing breakage, and that will involve trade-offs depending on what is being changed. IIRC, we've been trying to get away from deprecations because they're so disruptive. For example, when the pprint rewrite is finally ready, if there is an incompatible API change, I expect that a new clean class will be offered, but that the old will be left in-place so that tons of existing code won't break). Likewise, with the unittest clean-ups, I'm expecting that Michael will introduce aliases when fixing-up mis-named methods, rather than break code that uses the existing names. So it is obvious that we don't have a clearly stated policy for what defines the public API of standard library modules. How about making this explicit (either pep 8 or our developer docs): If a module or package defines __all__ that authoritatively defines the public interface. Modules with __all__ SHOULD still respect the naming conventions (leading underscore for private members) to avoid confusing users. Modules SHOULD NOT export private members in __all__. Names imported into a module a never considered part of its public API unless documented to be so or included in __all__. Methods / functions / classes and module attributes whose names begin with a leading underscore are private. If a class name begins with a leading underscore none of its members are public, whether or not they begin with a leading underscore. If a module name in a package begins with a leading underscore none of its members are public, whether or not they begin with a leading underscore. If a module or package doesn't define __all__ then all names that don't start with a leading underscore are public. All public members MUST be documented. Public functions, methods and classes SHOULD have docstrings. Private members may have docstrings. Where in the standard library this means that a module exports stuff that isn't helpful or shouldn't be part of the public API we need to migrate to private names and follow our deprecation process for the public names. All the best, Michael Foord my-two-cents, Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] Breaking undocumented API
On Wed, 10 Nov 2010 13:12:09 +0900, "Stephen J. Turnbull" wrote: > Nick Coghlan writes: > > > > Module writers who compound the error by expecting to be imported > > > this way, thereby bogarting the global namespace for their own > > > purposes, should be fish-slapped. ;) > > > > Be prepared to fish-slap all of python-dev then - we use precisely > > this technique to support optional acceleration modules. The pure > > Python versions of pairs like profile/_profile and heapq/_heapq > > include a try/except block at the end that does the equivalent of: > > > > try: > > from _accelerated import * # Allow accelerated overrides > > except ImportError: > > pass # Use pure Python versions > > But these identifiers will appear at the module level, not global, no? > Otherwise this technique couldn't be used. I don't really understand > what Tres is talking about when he writes "modules that expect to be > imported this way". The *imported* module shouldn't care, no? This > is an issue for the *importing* code to deal with. I think Tres was referring to certain packages (which shall remain nameless since I don't feel like googling to find one) whose documentation recommends the 'from import *' methodology. At least that's how I read "Module writers who..." (that is, he's not saying the *module* expects to be imported that way). [*] -- R. David Murray www.bitdance.com [*] although reading that sentence literally, the thought of such a module writer themselves being imported that way (a la Tron) has a certain charm ___ 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] Breaking undocumented API
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/09/2010 11:12 PM, Stephen J. Turnbull wrote: > Nick Coghlan writes: > > > > Module writers who compound the error by expecting to be imported > > > this way, thereby bogarting the global namespace for their own > > > purposes, should be fish-slapped. ;) > > > > Be prepared to fish-slap all of python-dev then - we use precisely > > this technique to support optional acceleration modules. The pure > > Python versions of pairs like profile/_profile and heapq/_heapq > > include a try/except block at the end that does the equivalent of: > > > > try: > > from _accelerated import * # Allow accelerated overrides > > except ImportError: > > pass # Use pure Python versions > > But these identifiers will appear at the module level, not global, no? > Otherwise this technique couldn't be used. I don't really understand > what Tres is talking about when he writes "modules that expect to be > imported this way". The *imported* module shouldn't care, no? This > is an issue for the *importing* code to deal with. Right -- "private" star imports aren't the issue for me, because the same user who creates them is responsible for the other end fo the stick. I was ranting about library authors who document star imports as the expected usage pattern for their external users. Note that I still wouldn't use star imports in the "private acceleration" case myself. I would prefer a pattern like: - --- $< - # spam.py # Pure python API implementation def foo(spat, blarg): ... def bar(qux): ... # Replace with accelearated C implemenataion try: import _spam except ImportError: pass # accelerated version not available else: foo = _spam.foo bar = _spam.bar - --- $< - This explicit name remapping catches unintentional erros (e.g., _spam renames a method) better than the star import. Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzazykACgkQ+gerLs4ltQ5BHACfaAh2lVLZ8C+mdV/88UJ0JXTo sqQAn2b2J9cZSQuz2xrwZX/JrvY3AaMh =EIDa -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] Breaking undocumented API
Stephen J. Turnbull wrote: I don't really understand what Tres is talking about when he writes "modules that expect to be imported this way". The *imported* module shouldn't care, no? This is an issue for the *importing* code to deal with. I think he's talking about modules that add a prefix to all of their exported names, such as Tkinter starting everything with "Tk", on the expectation that import * will be the normal way of using the module. For very well-known modules with very well-known prefixes, this probably doesn't do too much harm, since it's usually fairly obvious where a given name is coming from. However, it's probably best not encouraged, as it could lead people who don't know better into bad habits. There's also the downside that people who choose *not* to use import *, and instead import the module itself and use qualified references, end up with everything being prefixed twice, e.g. 'import Tkinter as tk' leads to 'tk.TkWhatever' everywhere. On the other hand, when wrapping a C library there's a desire to keep the Python names as close as possible to the C ones, which usually come with prefixes to manage C's totally-global namespace. So there's a bit of a double bind there. -- Greg ___ 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] Breaking undocumented API
On Wed, Nov 10, 2010 at 05:47, Michael Foord wrote: > On 08/11/2010 22:07, Raymond Hettinger wrote: >> >> On Nov 8, 2010, at 11:58 AM, Brett Cannon wrote: >> >>> I think we need to, as a group, decide how to handle undocumented APIs >>> that don't have a leading underscore: they get treated just the same >>> as the documented APIs, or are they private regardless and thus we can >>> change them at our whim? >> >> To start with, it doesn't hurt for a maintainer to add an __all__ entry >> and to only document the parts of the API we think need to be exposed. That >> way, we can at least declare the parts that are intended to be public on a >> go-forward basis. >> >> For the most part, the non-underscored parts of the API shouldn't be >> changed "at our whim". Some sense needs to be applied to the decision. >> Google's code search is great for showing how people actually have used a >> module in real world code. If that shows that people are accessing and/or >> changing an attribute, it probably needs to remain exposed. In the absence >> of a code search, good guesses can be made about what someone might >> reasonably and usefully be accessing (i.e. glob0 isn't likely). The goal >> is to improve the standard library while minimizing breakage, and that will >> involve trade-offs depending on what is being changed. >> >> IIRC, we've been trying to get away from deprecations because they're so >> disruptive. For example, when the pprint rewrite is finally ready, if there >> is an incompatible API change, I expect that a new clean class will be >> offered, but that the old will be left in-place so that tons of existing >> code won't break). Likewise, with the unittest clean-ups, I'm expecting >> that Michael will introduce aliases when fixing-up mis-named methods, rather >> than break code that uses the existing names. >> > > So it is obvious that we don't have a clearly stated policy for what defines > the public API of standard library modules. > > How about making this explicit (either pep 8 or our developer docs): > > If a module or package defines __all__ that authoritatively defines the > public interface. Modules with __all__ SHOULD still respect the naming > conventions (leading underscore for private members) to avoid confusing > users. Modules SHOULD NOT export private members in __all__. > > Names imported into a module a never considered part of its public API > unless documented to be so or included in __all__. > > Methods / functions / classes and module attributes whose names begin with a > leading underscore are private. > > If a class name begins with a leading underscore none of its members are > public, whether or not they begin with a leading underscore. > > If a module name in a package begins with a leading underscore none of its > members are public, whether or not they begin with a leading underscore. > > If a module or package doesn't define __all__ then all names that don't > start with a leading underscore are public. > > All public members MUST be documented. Public functions, methods and classes > SHOULD have docstrings. Private members may have docstrings. > > > Where in the standard library this means that a module exports stuff that > isn't helpful or shouldn't be part of the public API we need to migrate to > private names and follow our deprecation process for the public names. All sounds reasonable to me and what common practice out in the community is. -Brett > > All the best, > > > Michael Foord >> >> my-two-cents, >> >> >> Raymond >> >> >> >> >> ___ >> Python-Dev mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > > > -- > > http://www.voidspace.org.uk/ > > READ CAREFULLY. By accepting and reading this email you agree, > on behalf of your employer, to release me from all obligations > and waivers arising from any and all NON-NEGOTIATED agreements, > licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, > confidentiality, non-disclosure, non-compete and acceptable use > policies (”BOGUS AGREEMENTS”) that I have entered into with your > employer, its partners, licensors, agents and assigns, in > perpetuity, without prejudice to my ongoing rights and privileges. > You further represent that you have the authority to release me > from any BOGUS AGREEMENTS on behalf of your employer. > > ___ 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-checkins] r86355 - python/branches/py3k/Modules/_pickle.c
On Wed, Nov 10, 2010 at 7:28 AM, Victor Stinner
wrote:
..
> I don't know, but the commit is trivial and cheap. If it improves the support
> on uncommon compiler, I agree to commit such change.
>
But it does it at the cost of invalidating the "svn blame" for the
last enum entry now and for future additions. The problem is that
when you change from
enum {
..
X
}
to
enum {
..
X,
Y
}
you modify the X line while you are not responsible for adding the X
entry. Someone who will then add Z, will be blamed for Y as well.
___
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] bugs.python.org migration
On Nov 10, 2010, at 12:34 PM, Jesus Cea wrote: >On 09/11/10 22:17, "Martin v. Löwis" wrote: >> bugs.python.org is moving to a new hardware; this also involves a new IP >> address. The migration will happen on Thursday, likely around 8:00 UTC. >> If all goes well, outage should be very short. > >Seems to be offline now. I get timeouts. I just had no problems updating issue 9807. -Barry signature.asc Description: 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
[Python-Dev] issue 9807 - abiflags in paths and symlinks (updated patch)
I finally found a chance to address all the outstanding technical issues mentioned in bug 9807: http://bugs.python.org/issue9807 I've uploaded a new patch which contains the rest of the changes I'm proposing. I think we still need consensus about whether these changes are good to commit. With 3.2b1 coming soon, now's the time to do that. If there are any remaining concerns about the details of the patch, please add them to the tracker issue. If you have any remaining objections to the change, please let me know or follow up here. Cheers, -Barry signature.asc Description: 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] Breaking undocumented API
On Nov 10, 2010, at 8:47 AM, Michael Foord wrote: > How about making this explicit (either pep 8 or our developer docs): > > If a module or package defines __all__ that authoritatively defines the > public interface. Modules with __all__ SHOULD still respect the naming > conventions (leading underscore for private members) to avoid confusing > users. Modules SHOULD NOT export private members in __all__. I don't like the idea of the authoritative definition of a public interface being defined based on __all__, because that provides users almost no warning that they're using a private API: the __all__ attribute doesn't do anything if you aren't using import *. If there was some proposal to make it so that accessing an attribute not in __all__ did prevent or somehow warn users that they're doing something dangerous, that'd be different, but there isn't such a proposal, and I don't even know what such a proposal would look like... On the other hand, if you make the primary mechanism to indicate privateness be a leading underscore, that's obvious to everyone. James ___ 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] Breaking undocumented API
On 11/10/2010 01:33 PM, Raymond Hettinger wrote: On Nov 10, 2010, at 5:47 AM, Michael Foord wrote: So it is obvious that we don't have a clearly stated policy for what defines the public API of standard library modules. How about making this explicit (either pep 8 or our developer docs): I believe the point of Guido's email was that it is a situation dependent judgment call and not readily boiled down to a set of rules for PEP 8. The way I read Guido's email is that it is a situation dependent judgment call for those cases that aren't clear. I think what Micheal is trying to say is for us to agree on some things so we can go forward with a little more clarity. Cheers, Ron ___ 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] bugs.python.org migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/11/10 22:19, Barry Warsaw wrote: > On Nov 10, 2010, at 12:34 PM, Jesus Cea wrote: >> Seems to be offline now. I get timeouts. > > I just had no problems updating issue 9807. That was 10 hours after my message :-). - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [email protected] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[email protected] _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTNs2wJlgi5GaxT1NAQKTlAP/dI29cbxfsHCj4pjATuR0yIryAEsZyKml M4+EXxohASAaOG3prdEKwE8bbyZDaX4+nvcm+2X7S9aoTgVlLJWavGraH8ApE/AU SShTsvzLHtNgB6MNNzT+58kv9z2pdCHJcrEY6d98Qh0buJp0Qz7AKcBw6mEb/bG4 v2bF7MyolOE= =oG9l -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] Breaking undocumented API
On Nov 10, 2010, at 2:21 PM, James Y Knight wrote: > On the other hand, if you make the primary mechanism to indicate privateness > be a leading underscore, that's obvious to everyone. +1. One of the best features of Python is the ability to make a conscious decision to break the interface of a library and just get on with your work, even if your use-case is not really supported, because nothing can stop you calling its private functionality. But, IMHO the worst problem with Python is the fact that you can do this _without realizing it_ and pay a steep maintenance price later when an upgrade of something springs the trap that you had unwittingly set for yourself. The leading-underscore convention is the only thing I've found that even mitigates this problem. ___ 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-checkins] r86355 - python/branches/py3k/Modules/_pickle.c
Alexander Belopolsky writes:
> On Wed, Nov 10, 2010 at 7:28 AM, Victor Stinner
> wrote:
> ..
> > I don't know, but the commit is trivial and cheap. If it improves the
> > support
> > on uncommon compiler, I agree to commit such change.
> >
>
> But it does it at the cost of invalidating the "svn blame" for the
> last enum entry now and for future additions. The problem is that
> when you change from
>
> enum {
> ..
> X
> }
>
> to
>
> enum {
> ..
> X,
> Y
> }
If that bothers you, you can write
enum {
A
, B
/* etc */
, X
}
or
enum {
A,
B,
/* etc */
X,
enum_bound_otherwise_unused
}
I prefer the last; it's a compiler (and debugger) space burden, but
shouldn't affect the running python. On the original question, I
think it's preferable to keep compilers happy unless you're willing to
*require* C99.
___
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-checkins] r86355 - python/branches/py3k/Modules/_pickle.c
On Wed, Nov 10, 2010 at 10:04 PM, Stephen J. Turnbull wrote: > ... On the original question, I > think it's preferable to keep compilers happy unless you're willing to > *require* C99. Hmm, maybe I should take another look at http://bugs.python.org/issue4805 . Note that issue #10359 was not about any real compiler - it was about compiling with gcc -pedantic. If we *require* pedantic c89 compliance - we should add -pedantic -std=c89 to the standard build flags. Otherwise no-compliant code will accumulate between "ISO C cleanups" and such cleanups will continue to pollute VC logs. ___ 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] Breaking undocumented API
On Wed, Nov 10, 2010 at 6:10 PM, Ron Adam wrote:
..
>> On Nov 10, 2010, at 5:47 AM, Michael Foord wrote:
>>>
>>> So it is obvious that we don't have a clearly stated policy for what
>>> defines the public API of standard library modules.
>>>
>>> How about making this explicit (either pep 8 or our developer docs):
>> ..
> The way I read Guido's email is that it is a situation dependent judgment
> call for those cases that aren't clear.
>
> I think what Micheal is trying to say is for us to agree on some things so
> we can go forward with a little more clarity.
I don't understand why everyone seem to have accepted Michael's
premise that "we don't have a clearly stated policy for what defines
the public API of standard library modules." We do have such a policy
and it is well known (while the location in the reference manual may
not be):
"""
The public names defined by a module are determined by checking the
module’s namespace for a variable named __all__; if defined, it must
be a sequence of strings which are names defined or imported by that
module. The names given in __all__ are all considered public and are
required to exist. If __all__ is not defined, the set of public names
includes all names found in the module’s namespace which do not begin
with an underscore character ('_'). __all__ should contain the entire
public API. It is intended to avoid accidentally exporting items that
are not part of the API (such as library modules which were imported
and used within the module).
""" --
The question that I had when I started this thread was not about a
definition of "public API." It was about a policy with respect to
modules that precede the introduction of __all__ and the modern
definition of public names. (See r18692 "Two changes to
from...import", and r23920 ' adding a definition of "public names"'.)
Is it OK to add __all__ to such modules that does not include all
names not starting with an underscore? Is it OK to then remove names
that clearly were not intended to be public?
Case in point: trace.rx_blank. See also .
___
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-checkins] r86355 - python/branches/py3k/Modules/_pickle.c
Alexander Belopolsky writes: > On Wed, Nov 10, 2010 at 10:04 PM, Stephen J. Turnbull > wrote: > > ... On the original question, I > > think it's preferable to keep compilers happy unless you're willing to > > *require* C99. > > Hmm, maybe I should take another look at http://bugs.python.org/issue4805 . > > Note that issue #10359 was not about any real compiler True, but a real compiler has been mentioned in the thread, and I know that every time XEmacs lets a non-C89 feature slip through (most commonly, "//" comments and declarations following non-declarations, the latter being a killer feature in C-like languages IMO, but our current coding standard says "C89") we get build breakage reports. ___ 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
