Re: [Python-Dev] Breaking undocumented API
On 17/11/2010 21:16, Éric Araujo wrote: Excluding a builtin name from __all__ sounds like a perfectly sensible idea, so even if it wasn't deliberate, I'd say it qualifies as fortuitous :) But then, a tool that looks into __all__ to find for example what objects to document will miss open. I’d put open in __all__. "import *" would then override the builtin open. A good reason not to use "import *" I guess, but also a good reason not to create names that shadow builtins. All the best, Michael Regards ___ 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 17/11/2010 21:22, Georg Brandl wrote:
Am 17.11.2010 22:16, schrieb Éric Araujo:
Excluding a builtin name from __all__ sounds like a perfectly sensible
idea, so even if it wasn't deliberate, I'd say it qualifies as
fortuitous :)
But then, a tool that looks into __all__ to find for example what
objects to document will miss open. I’d put open in __all__.
So it comes down again to what we'd like __all__ to mean foremost:
public API, or just a list for "import *"?
Well, as noted earlier in this discussion - the language reference
*states* that __all__ defines the module level public API.
From:
http://docs.python.org/reference/simple_stmts.html#grammar-token-import_stmt
"If the list of identifiers is replaced by a star ('*'), all public
names defined in the module are bound in the local namespace of the
import statement."
...
"The public names defined by a module are determined by checking
the module’s namespace for a variable named __all__"
If we decide that __all__ is purely for "import *" we should refine the
use of the word public on this page.
All the best,
Michael Foord
Georg
___
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 17/11/2010 21:57, Steven D'Aprano wrote: Nick Coghlan wrote: The policy we're aiming to clarify here is what we should do when we come across standard library APIs that land in the grey area, with there being two appropriate ways to deal with them: 1. Document them and make them officially public 2. Deprecate the public names and make them officially private (with the public names later removed in accordance with normal deprecation procedures) You missed at least two other options: 3. Treat "documented" and "public" as orthogonal, not synonymous: undocumented public API is not an oxymoron, and neither is documented private API. Along with the others +1 I think how we handle the deprecations (legacy modules with unclear or clearly wrong naming policies) is the least interesting part of this discussion. For deprecating existing names we have *no choice* but to proceed on a case-by-case basis evaluating how likely the deprecation is to break other code, whether or not the name was originally intended to be public or not. (At least that is how we *should* proceed and part of our standard deprecation policy - it is why we aren't removing unittest.TestCase.assertEquals and assert_ even though they are deprecated. They are just too widely used.) What is more important is that we have a clearly stated policy for new modules and adding names to existing modules so that we don't have to repeat this debate in five years time. My suggestion, which fits in with the use of __all__ by the language and also the convention widely in use by the community already boils down to: * If __all__ exists it is definitive * Imported names are never part of the public API of a module unless in __all__ or documented to be part of the API * Names with leading underscores are private unless in __all__ (and if you want to export leading underscore names as part of a public API you should define __all__ or "import *" won't export them) * Leading underscore convention extends to packages and class members; no members of a package or class whose name begins with a leading underscore are public It is still good practise that public APIs *should* be documented (and *should* have docstrings). There is however no corollary that private APIs should not be documented (and they may have docstrings). All the best, Michael Foord 4. Do nothing. Inertia wins. Is this problem we're trying to solve so serious that we need to solve it now except on a case-by-case basis? The approach that gives us the most flexibility is #3. Clearly one would not need to document private APIs for the use of the general public, but adding docstrings to private functions and classes for in-house use is a sensible thing to do. This applies equally to the standard library as to any other major project. Likewise, one might introduce a public function into some module, but for whatever reason, choose not to document it. (Perhaps it's a lack of hours in the day, perhaps it is a deliberate decision.) In this case, the mere lack of documentation shouldn't relieve us of the responsibility of treating the function as public. For emphasis: I strongly believe that public/private and documented/undocumented are orthogonal qualities, and should not be treated as, or forced to be, identical. The use of imported modules is possibly an exception. If a user is writing something like (say) getopt.os.getcwd() instead of importing os directly, then they're on shaky ground. We shouldn't expect module authors to write "import os as _os" just to avoid making os a part of their public API. I'd be prepared to make an exception to the rule "no leading underscore means public": imported modules are implementation details unless explicitly documented otherwise. E.g. the os module explicitly makes path part of its public API, but os.sys is an implementation detail. -- 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 Thu, Nov 18, 2010 at 7:22 AM, Georg Brandl wrote: > Am 17.11.2010 22:16, schrieb Éric Araujo: >>> Excluding a builtin name from __all__ sounds like a perfectly sensible >>> idea, so even if it wasn't deliberate, I'd say it qualifies as >>> fortuitous :) >> >> But then, a tool that looks into __all__ to find for example what >> objects to document will miss open. I’d put open in __all__. > > So it comes down again to what we'd like __all__ to mean foremost: > public API, or just a list for "import *"? It's the list for star imports. This intended use case is borne out by the description of the feature when it was first added to the language back in 2.1: http://docs.python.org/dev/whatsnew/2.1.html?highlight=__all__#other-changes-and-fixes The public API (for documentation and introspection purposes) is any name that doesn't start with an underscore and isn't an imported module. If a tool is attempting to use __all__ as more than just the list of names for star imports, I would call the tool buggy. The use of the term "public names" in the language reference when describing the semantics of __all__ is an unfortunate choice, but it is used specifically in the context of talking about star imports and clarifying which names they bring in without making any reference to standards for documentation or deprecation policies. 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] Breaking undocumented API
Am 18.11.2010 11:47, schrieb Michael Foord: > On 17/11/2010 21:16, Éric Araujo wrote: >>> Excluding a builtin name from __all__ sounds like a perfectly sensible >>> idea, so even if it wasn't deliberate, I'd say it qualifies as >>> fortuitous :) >> But then, a tool that looks into __all__ to find for example what >> objects to document will miss open. I’d put open in __all__. >> > > "import *" would then override the builtin open. A good reason not to > use "import *" I guess, but also a good reason not to create names that > shadow builtins. Heh. Instead have fun with io.ioopen(), gzip.gzipopen(), webbrowser.webbrowseropen(), etc.? We do have namespace support for a reason. 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] Breaking undocumented API
On 18/11/2010 12:37, Georg Brandl wrote: Am 18.11.2010 11:47, schrieb Michael Foord: On 17/11/2010 21:16, Éric Araujo wrote: Excluding a builtin name from __all__ sounds like a perfectly sensible idea, so even if it wasn't deliberate, I'd say it qualifies as fortuitous :) But then, a tool that looks into __all__ to find for example what objects to document will miss open. I’d put open in __all__. "import *" would then override the builtin open. A good reason not to use "import *" I guess, but also a good reason not to create names that shadow builtins. Heh. Instead have fun with io.ioopen(), gzip.gzipopen(), webbrowser.webbrowseropen(), etc.? We do have namespace support for a reason. Or urllib2.urlopen, oh wait - that's real... If I was importing from those namespaces I probably *would* import and rename to have unambiguous names (and you would *have* to if there was any possibility of you using the builtin open). io.open is arguably an exception to this as it does the same as the builtin open... Using meaningful names is *good*. This is a reason I dislike modules that just call their base exception class "Error". You *have* to use it from the namespace (or import with import as and give it a good name) for it to have any meaning. Michael Georg ___ 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
Am 18.11.2010 13:48, schrieb Michael Foord: On 18/11/2010 12:37, Georg Brandl wrote: Am 18.11.2010 11:47, schrieb Michael Foord: On 17/11/2010 21:16, Éric Araujo wrote: Excluding a builtin name from __all__ sounds like a perfectly sensible idea, so even if it wasn't deliberate, I'd say it qualifies as fortuitous :) But then, a tool that looks into __all__ to find for example what objects to document will miss open. I’d put open in __all__. "import *" would then override the builtin open. A good reason not to use "import *" I guess, but also a good reason not to create names that shadow builtins. Heh. Instead have fun with io.ioopen(), gzip.gzipopen(), webbrowser.webbrowseropen(), etc.? We do have namespace support for a reason. Or urllib2.urlopen, oh wait - that's real... If I was importing from those namespaces I probably *would* import and rename to have unambiguous names (and you would *have* to if there was any possibility of you using the builtin open). io.open is arguably an exception to this as it does the same as the builtin open... Using meaningful names is *good*. This is a reason I dislike modules that just call their base exception class "Error". You *have* to use it from the namespace (or import with import as and give it a good name) for it to have any meaning. Guys, I may agree or disagree with these statements but we are drifting towards "opinion" versus "solid, well understood practice". Let's focus on the subject. For the matter, "import *" is a discouraged mechanism anyway, let alone the rare exceptions where its usage is valid. If you use star-imports and you don't know what you're doing, you might just as well hurt yourself in other ways than just by "open". Maybe we should just sum up the discussion somewhere already. Keeping up with a thread reaching a megabyte in size is starting to be painful. Best regards, Łukasz ___ 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 Thu, Nov 18, 2010 at 6:41 AM, Michael Foord wrote: > Along with the others +1 I agree with keeping these distinct and orthogonal as well. > What is more important is that we have a clearly stated policy for new > modules and adding names to existing modules so that we don't have to repeat > this debate in five years time. Agreed again. > My suggestion, which fits in with the use of __all__ by the language and > also the convention widely in use by the community already boils down to: > > * If __all__ exists it is definitive I think this is overly vague. :-) Specifically, if something is mentioned in __all__, it's public. Non-inclusion in __all__ doesn't imply privateness. > * Names with leading underscores are private unless in __all__ (and if you > want to export leading underscore names as part of a public API you should > define __all__ or "import *" won't export them) We shouldn't confuse non-export via "import *" with non-public, however. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] r86514 - in python/branches/py3k/Lib: test/test_xmlrpc.py xmlrpc/client.py
On Thu, 18 Nov 2010 16:00:53 +0100 (CET)
senthil.kumaran wrote:
> Author: senthil.kumaran
> Date: Thu Nov 18 16:00:53 2010
> New Revision: 86514
>
> Log:
> Fix Issue 9991: xmlrpc client ssl check faulty
>
[...]
>
> +def test_ssl_presence(self):
> +#Check for ssl support
> +have_ssl = False
> +if hasattr(socket, 'ssl'):
> +have_ssl = True
This is not the right way to check for ssl. socket.ssl is deprecated in
2.x and doesn't exist in 3.x. "import ssl" is enough.
> +try:
> +
> xmlrpc.client.ServerProxy('https://localhost:').bad_function()
> +except:
> +exc = sys.exc_info()
> +if exc[0] == socket.error:
This is a rather clumsy way to check for exception types. Why
don't you just write "except socket.error"?
> -if not hasattr(socket, "ssl"):
> +if not hasattr(http.client, "ssl"):
That isn't better. "http.client.ssl" is not a public API. You should
check for http.client.HTTPSConnection instead.
cheers
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] r86514 - in python/branches/py3k/Lib: test/test_xmlrpc.py xmlrpc/client.py
On Thu, Nov 18, 2010 at 11:18 PM, Antoine Pitrou wrote: >> Log: >> Fix Issue 9991: xmlrpc client ssl check faulty >> > [...] >> >> + def test_ssl_presence(self): >> + #Check for ssl support >> + have_ssl = False >> + if hasattr(socket, 'ssl'): >> + have_ssl = True > > This is not the right way to check for ssl. socket.ssl is deprecated in > 2.x and doesn't exist in 3.x. "import ssl" is enough. The history of the bug report showed that it was closed earlier with comments such as "Python should be complied with SSL" which had resulted in some confusion, so after some thought, I let those earlier verifications remain (Just for readability/understanding the context of the tests). Thinking again, I see that it is not required. Agree to your comments on code changes. Shall change it. -- Senthil ___ 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] Mercurial Schedule
Am 17.11.2010 08:18, schrieb Georg Brandl: > Am 16.11.2010 19:38, schrieb Jesus Cea: >> Is there any updated mercurial schedule?. >> >> Any impact related with the new 3.2 schedule (three weeks offset)? > > I've been trying to contact Dirkjan and ask; generally, I don't > see much connection to the 3.2 schedule (with the exception that > the final migration day should not be a release day.) Please reconsider. When Python migrates to Mercurial, new features will be added to Python, most notably a new way of identifying versions, perhaps new variables in the sys module. So far, the policy has been that no new features can be added after beta 1. So consequentially, migrating 3.2 to Mercurial would violate that policy if done after b1. Consequentially, we would need to release 3.2 from Subversion, which in turn means that the Mercurial migration should be delayed until after 3.2 is released. Alternatively, b1 should be postponed until after the Mercurial migration is done. Regards, 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] Breaking undocumented API
On Thu, Nov 18, 2010 at 4:16 AM, Nick Coghlan wrote: > On Thu, Nov 18, 2010 at 7:22 AM, Georg Brandl wrote: >> So it comes down again to what we'd like __all__ to mean foremost: >> public API, or just a list for "import *"? > > It's the list for star imports. This intended use case is borne out by > the description of the feature when it was first added to the language > back in 2.1: > http://docs.python.org/dev/whatsnew/2.1.html?highlight=__all__#other-changes-and-fixes > > The public API (for documentation and introspection purposes) is any > name that doesn't start with an underscore and isn't an imported > module. If a tool is attempting to use __all__ as more than just the > list of names for star imports, I would call the tool buggy. Not so fast. The feature's meaning has clearly evolved. > The use of the term "public names" in the language reference when > describing the semantics of __all__ is an unfortunate choice, but it > is used specifically in the context of talking about star imports and > clarifying which names they bring in without making any reference to > standards for documentation or deprecation policies. Let's live with a little ambiguity. There are more shades of gray here than you can imagine. I like gray. -- --Guido van Rossum (python.org/~guido) ___ 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] Mercurial Schedule
On Thu, Nov 18, 2010 at 8:25 AM, "Martin v. Löwis" wrote: > Am 17.11.2010 08:18, schrieb Georg Brandl: >> Am 16.11.2010 19:38, schrieb Jesus Cea: >>> Is there any updated mercurial schedule?. >>> >>> Any impact related with the new 3.2 schedule (three weeks offset)? >> >> I've been trying to contact Dirkjan and ask; generally, I don't >> see much connection to the 3.2 schedule (with the exception that >> the final migration day should not be a release day.) > > Please reconsider. When Python migrates to Mercurial, new features > will be added to Python, most notably a new way of identifying versions, > perhaps new variables in the sys module. So far, the policy has been > that no new features can be added after beta 1. So consequentially, > migrating 3.2 to Mercurial would violate that policy if done after b1. > Consequentially, we would need to release 3.2 from Subversion, which > in turn means that the Mercurial migration should be delayed until > after 3.2 is released. > > Alternatively, b1 should be postponed until after the Mercurial > migration is done. I think this "new feature" is not so shocking that it can be used as an argument to hold up the migration. If you have another reason to stop the migration please say so; personally I can't wait for it to happen. -- --Guido van Rossum (python.org/~guido) ___ 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] Mercurial Schedule
Am 18.11.2010 17:25, schrieb "Martin v. Löwis": > Am 17.11.2010 08:18, schrieb Georg Brandl: >> Am 16.11.2010 19:38, schrieb Jesus Cea: >>> Is there any updated mercurial schedule?. >>> >>> Any impact related with the new 3.2 schedule (three weeks offset)? >> >> I've been trying to contact Dirkjan and ask; generally, I don't >> see much connection to the 3.2 schedule (with the exception that >> the final migration day should not be a release day.) > > Please reconsider. When Python migrates to Mercurial, new features > will be added to Python, most notably a new way of identifying versions, > perhaps new variables in the sys module. So far, the policy has been > that no new features can be added after beta 1. So consequentially, > migrating 3.2 to Mercurial would violate that policy if done after b1. > Consequentially, we would need to release 3.2 from Subversion, which > in turn means that the Mercurial migration should be delayed until > after 3.2 is released. I'm with Guido here. Plus, if you like it can be seen as a bug fix: the SVN build identification stops working, and we neeed to fix it. 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] Mercurial Schedule
>> Alternatively, b1 should be postponed until after the Mercurial >> migration is done. > > I think this "new feature" is not so shocking that it can be used as > an argument to hold up the migration. If you have another reason to > stop the migration please say so; personally I can't wait for it to > happen. I can't point out any other specific concern, just a general feeling that *when* the migration happens, it will be rushed, and we will have to deal for a long time with the aftermath. For example, I expect that it will take me several days until I get the Windows build process to work correctly, and, if the migration gets as rushed as it appears to, that the migration will happen without everything being worked out beforehand. Therefore, I'm concerned that I will have to work out all the details on my own, just so that I can produce the b2 binaries (says); this is not something I look forward to. I'm not asking that the migration be stopped - I'm asking that it be accelerated, so that there is plenty of time to identify all the problems. But I'm also not willing to put time into it. Failing the acceleration, I ask that appropriate consequences for the 3.2 release are drawn: either it is postponed, or done using Subversion until the final release (I think something can be worked out then to get the 3.2.1 release from Mercurial - with only slight incompatibilities). In general, I'm *also* concerned about the lack of volunteers that are interested in working on the infrastructure. I wish some of the people who stated that they can't wait for the migration to happen would work on solving some of the remaining problems. Regards, 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] Mercurial Schedule
Am 18.11.2010 18:32, schrieb "Martin v. Löwis": >>> Alternatively, b1 should be postponed until after the Mercurial >>> migration is done. >> >> I think this "new feature" is not so shocking that it can be used as >> an argument to hold up the migration. If you have another reason to >> stop the migration please say so; personally I can't wait for it to >> happen. > > I can't point out any other specific concern, just a general feeling > that *when* the migration happens, it will be rushed, and we will have > to deal for a long time with the aftermath. For example, I expect that > it will take me several days until I get the Windows build process to > work correctly, and, if the migration gets as rushed as it appears to, > that the migration will happen without everything being worked out > beforehand. > > Therefore, I'm concerned that I will have to work out all the details > on my own, just so that I can produce the b2 binaries (says); this is > not something I look forward to. How much does the binary build process really depend on version control? I.e., what would be stopping you from making a binary from an archive made with e.g. "svn export"? (I'm really asking because I don't know.) Concerning the SVN external/ subdir, that is quite orthogonal to the main development repo, and doesn't need to be migrated in lockstep (if it is migrated to Mercurial at all in its current shape. > I'm not asking that the migration be stopped - I'm asking that it be > accelerated, so that there is plenty of time to identify all the > problems. But I'm also not willing to put time into it. I think we have anticipated what we could. Of course there will still be problems, but I think not of the sort that causes big disruptions everywhere, preventing our developers from committing or breaking the issue tracker, etc. > Failing the acceleration, I ask that appropriate consequences for > the 3.2 release are drawn: either it is postponed, or done using > Subversion until the final release (I think something can be worked > out then to get the 3.2.1 release from Mercurial - with only slight > incompatibilities). > > In general, I'm *also* concerned about the lack of volunteers that > are interested in working on the infrastructure. I wish some of the > people who stated that they can't wait for the migration to happen > would work on solving some of the remaining problems. Well, put some butter to the fish: how many volunteers would you deem sufficient, and which specific tasks are uncared for in the infrastructure? I can only speak for myself, but I am prepared to put in my time. 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] Mercurial Schedule
>> Therefore, I'm concerned that I will have to work out all the details >> on my own, just so that I can produce the b2 binaries (says); this is >> not something I look forward to. > > How much does the binary build process really depend on version control? > I.e., what would be stopping you from making a binary from an archive made > with e.g. "svn export"? (I'm really asking because I don't know.) The build process currently compiles a program (make_buildinfo), which in turn finds the subversion installation, and runs subwcrev if found. If no .svn folder is found, it falls back to the version information in the export. I would have to try out what exactly will happen when I try to build the current hg conversion result on Windows, but chances are that the resulting interpreter will crash because the string manipulation fails to find the right substrings. > Well, put some butter to the fish: how many volunteers would you deem > sufficient, and which specific tasks are uncared for in the infrastructure? > I can only speak for myself, but I am prepared to put in my time. As a starting point, I'd like to see a complete, current conversion result, using as many repositories as planned, and including as many branches into each repository as planned (rather than the giant cpython repository which we have now - unless the plan now is that there will be a single giant repository). Then the existing patches to the build identification should be applied, and the repositories should be opened for (test) commits. Then people could start identifying problems. As a parallel activity, I'd also ask that the PEP is finished, or atleast put into a form where the authors consider it complete (again so that people could start identifying issues, and determine where the PEP differs from reality - currently most obviously in the branching approach). Regards, 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] Mercurial Schedule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/11/10 18:32, "Martin v. Löwis" wrote: > In general, I'm *also* concerned about the lack of volunteers that > are interested in working on the infrastructure. I wish some of the > people who stated that they can't wait for the migration to happen > would work on solving some of the remaining problems. Do we have a exhaustive list of mercurial "to do" things?. I thought the plan was to keep a read only SVN mirror fedded from mercurial. The 3.2 build could come from the mirror, I guess. - -- 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/ iQCVAwUBTOXdUplgi5GaxT1NAQIL3AP/WRq9IwRZXEuFkKRAqBm0cOi4CkTbcV5X Ix+JZvimKEiq1DkUsJJb6q5/ViQ3z15ai9idY+AOmv4EdMK9hbgYZIQXGig9TLvA LFvqTqnl9ZuZCVFEYh2QdnXU576edgn2AaBpBDpoC88IXcu6Y3kcmzFIHWRTh2MF SEkUAzETSrc= =cOVM -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] Mercurial Schedule
2010/11/18 Jesus Cea : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 18/11/10 18:32, "Martin v. Löwis" wrote: >> In general, I'm *also* concerned about the lack of volunteers that >> are interested in working on the infrastructure. I wish some of the >> people who stated that they can't wait for the migration to happen >> would work on solving some of the remaining problems. > > Do we have a exhaustive list of mercurial "to do" things?. http://hg.python.org/pymigr/file/1576eb34ec9f/tasks.txt -- 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] Mercurial Schedule
Am 19.11.2010 03:23, schrieb Benjamin Peterson: > 2010/11/18 Jesus Cea : >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 18/11/10 18:32, "Martin v. Löwis" wrote: >>> In general, I'm *also* concerned about the lack of volunteers that >>> are interested in working on the infrastructure. I wish some of the >>> people who stated that they can't wait for the migration to happen >>> would work on solving some of the remaining problems. >> >> Do we have a exhaustive list of mercurial "to do" things?. > > http://hg.python.org/pymigr/file/1576eb34ec9f/tasks.txt Uh, that's the list of things to do *at* the migration. The todo list is http://hg.python.org/pymigr/file/1576eb34ec9f/todo.txt 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
