[Python-Dev] devguide: Generate patches without code checkout (Was: devguide: Write a guide to committing a patch.)
On Tue, Jan 18, 2011 at 2:35 PM, Antoine Pitrou wrote: > On Tue, 18 Jan 2011 07:14:51 +0100 > Ezio Melotti wrote: >> > + >> > +Committing Patches >> > +== > [...] >> > + >> > + svnmerge.py merge -r 42 >> > + >> > +This will try to apply the patch to the current patch and generate a >> > commit > > Do we want to spend so much time explaining how to use SVN for core > developers while we're supposed to switch to Mercurial Real Soon Now? > (current core devs already know how to use it, and we don't get many > new ones every month) How about patches sent by users who track and fix bugs directly in codebase of their Python installation? Making and testing a patch from Python checkout requires compiling Python, which is not possible for Windows users. We should add less hardcore instructions how to use bundled diff.py for creating simple patches like docstring, comment fixes or generating new testcases. This will greatly reduce the barrier for starting with development. -- anatoly t. ___ 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] MSI: Remove dependency from win32com.client module (issue4080047)
> It is a surprise to find builtin msilib. Why isn't it used? Originally, because Python needs to be packaged with an older release (in particular one that isn't itself maintained anymore). Today, the problem is that the msilib package doesn't support merge modules (and if such support was added, we would have to wait until the version containing it isn't maintained anymore). I don't consider the dependency on win32com a serious issue at all; it's just a mild annoyance (much less than reliance on ctypes would be, or hard-coding of symbolic constants). 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] devguide: Generate patches without code checkout (Was: devguide: Write a guide to committing a patch.)
On Wed, Feb 2, 2011 at 6:33 PM, anatoly techtonik wrote: > Making and testing a patch from Python checkout requires compiling > Python, which is not possible for Windows users. That latter comment hasn't been true since Microsoft started releasing the Visual Studio Express editions. > We should add less > hardcore instructions how to use bundled diff.py for creating simple > patches like docstring, comment fixes or generating new testcases. > This will greatly reduce the barrier for starting with development. Given the length of Python's release cycles, diffs against released versions are far too likely to be out of date. We want diffs against the head of the relevant branch. People that can't check out and build their own version of Python are quite welcome to simply report issues without trying to fix them themselves. 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] MSI: Remove dependency from win32com.client module (issue4080047)
On Wed, Feb 2, 2011 at 10:36 AM, "Martin v. Löwis" wrote: > >> It is a surprise to find builtin msilib. Why isn't it used? > > Originally, because Python needs to be packaged with an older > release (in particular one that isn't itself maintained anymore). That doesn't answer the question why Python could not be packaged with a newer release of 'msilib' at that time? > Today, the problem is that the msilib package doesn't support > merge modules (and if such support was added, we would have to > wait until the version containing it isn't maintained anymore). I don't understand the phrase in (). What for do we need to wait after adding support for merge modules to builtin msilib? I imagine we've added support for merge modules to msilib, and then waiting until new msilib version with merge support isn't maintained anymore. And only then we can use it to create installer. Sounds like a nonsense. Anyways, is it possible to reuse builtin msilib to the max and add required 'merge modules' functionality inside msi.py or extension module? > I don't consider the dependency on win32com a serious issue at > all; it's just a mild annoyance (much less than reliance on ctypes > would be, or hard-coding of symbolic constants). There is nothing wrong with hardcoded symbolic constants - Microsoft specifically provides values for them in their MSDN materials to be used with scripting languages which doesn't have include files. They just need to be validated one time, and won't change in future. Why don't you like ctypes solution? I find it strange that Python build process avoids using its own modules. -- anatoly t. ___ 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] devguide: Add a document discussing the development cycle typically followed for
On Wed, Jan 26, 2011 at 23:20, brett.cannon wrote: > +The in-development branch is where new functionality and semantic changes new functionalities (dunno if it's plural in english or not)? > +occur. Currently this branch is known as the "py3k" branch. The next minor > +release of Python will come from this branch (major releases are once a > decade > +and so have no specific rules on how they are started). All changes land in > this > +branch and then trickle down to other branches. > + > +Once a Final_ release is made from the in-development branch, a branch is > made > +to represent the minor version of Python and it goes into maintenance mode. > +Typically a minor version of Python is under development for about 18 months. > + > + > +Maintenance > +--- > +The branch currently being maintained for bug fixes. > + > +The branch under maintenance is the last minor version of Python to be > released > +as Final_. This means that the latest release of Python was 3.1.2, then the if the latest release ? > +branch representing Python 3.1 is in maintenance mode. > + > +The only changes allowed to occur in a maintenance branch without debate are > bug > +fixes. > +Semantic changes **must** be carefully considered as code out in the world > will > +have already been developed that will rely on the released semantics. Changes > +related to semantics should be discussed on python-dev before being made. > + > +A branch stays in maintenance mode as long as a new minor release has not > been > +made. For example, this means that Python 2.6 stayed in maintenance mode > until > +Python 2.7.0 was released, at which point 2.7 went into maintenance mode and > +2.6 went into Security_ mode. As new minor releases occur on a (roughly) 18 > +month schedule, a branch stays in mainteance mode for the same amount of > time. s/mainteance/maintenance/ > + > +A micro release of a maintenance branch is made about every six months. > +Typically when a new minor release is made one more release of the new-old > +version of Python is made. > + > + > +Security > + > +A branch less than five years old but no longer in maintenance mode. > + > +The only changes made to a branch that is being maintained for security > +purposes are somewhat obviously those related to security, e.g., privilege > +escalation. Crashers and other behaviorial issues are **not** considered a s/Crashers/Crashes/ s/behaviorial/behavioral/ > +security risk and thus not backported to a branch being maintained for > +security. Any releases made for a branch under security maintenance is s/releases/release/ ? s/for/from/ > +source-only and done only when actual security patches have been applied to > the > +branch. > + > + > +Stages > +'' > + > +Based on what stage the in-development version of Python is in, the > +responsibilities of a core developer change in regards to commits to the VCS. > + > + > +Pre-alpha > +- > +This is the stage a branch is in from the last final release until the first > +alpha (a1). There are no special restrictions placed on commits beyond those > +imposed by the type of branch being worked on (e.g., in-development vs. > +maintenance). > + > + > +Alpha > +- > +Alphas typically serve as a reminder to core developers that they need to > start > +getting in changes that change semantics or add something to Python as such > +things should not be added during a Beta_. Otherwise no new restrictions are > in > +place while in alpha. > + > + > +Beta > + > +A branch in beta means that no new additions to Python are accepted. Bugfixes > +and the like are still fine. Being in beta can be viewed much like being in > RC_ > +but without the extra overhead of needing commit reviews. > + > + > +.. _RC: > + > +Release Candidate (RC) > +-- > +A branch preparing for an RC release can only have bugfixes applied that have > +been reviewed by other core developers. That reviewer should make a post to > the > +issue related to the change and be mentioned in the commit message. > + > +You **cannot** skip the peer review during an RC, no matter how small! Even > if > +it is a simple copy-and-paste change, **everything** requires peer review > from > +a core developer. > + > + > +Final > +- > +When a final release is being cut, only the release manager (RM) can make > +changes to the branch. > diff --git a/index.rst b/index.rst > --- a/index.rst > +++ b/index.rst > @@ -20,6 +20,7 @@ > coredev > developers > committing > + devcycle > > stdlibchanges > langchanges > @@ -64,6 +65,7 @@ > * :ref:`coredev` > * :ref:`developers` > * :ref:`committing` > + * :ref:`devcycle` > > > Proposing changes to Python itself > > -- > Repository URL: http://hg.python.org/devguide > ___ > Python-checkins mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-checkins > > -- Sandro Tosi (aka m
Re: [Python-Dev] [Python-checkins] devguide: Add a document discussing the development cycle typically followed for
On 02/02/2011 11:04, Sandro Tosi wrote: On Wed, Jan 26, 2011 at 23:20, brett.cannon wrote: +The in-development branch is where new functionality and semantic changes new functionalities (dunno if it's plural in english or not)? It's an odd one. Functionality can be implicitly plural (include several individual features that comprise new functionality) but can also be pluralised; several functionalities where each new functionality comprises plural features. I would say that Brett's wording reads correctly here. Michael +occur. Currently this branch is known as the "py3k" branch. The next minor +release of Python will come from this branch (major releases are once a decade +and so have no specific rules on how they are started). All changes land in this +branch and then trickle down to other branches. + +Once a Final_ release is made from the in-development branch, a branch is made +to represent the minor version of Python and it goes into maintenance mode. +Typically a minor version of Python is under development for about 18 months. + + +Maintenance +--- +The branch currently being maintained for bug fixes. + +The branch under maintenance is the last minor version of Python to be released +as Final_. This means that the latest release of Python was 3.1.2, then the if the latest release ? +branch representing Python 3.1 is in maintenance mode. + +The only changes allowed to occur in a maintenance branch without debate are bug +fixes. +Semantic changes **must** be carefully considered as code out in the world will +have already been developed that will rely on the released semantics. Changes +related to semantics should be discussed on python-dev before being made. + +A branch stays in maintenance mode as long as a new minor release has not been +made. For example, this means that Python 2.6 stayed in maintenance mode until +Python 2.7.0 was released, at which point 2.7 went into maintenance mode and +2.6 went into Security_ mode. As new minor releases occur on a (roughly) 18 +month schedule, a branch stays in mainteance mode for the same amount of time. s/mainteance/maintenance/ + +A micro release of a maintenance branch is made about every six months. +Typically when a new minor release is made one more release of the new-old +version of Python is made. + + +Security + +A branch less than five years old but no longer in maintenance mode. + +The only changes made to a branch that is being maintained for security +purposes are somewhat obviously those related to security, e.g., privilege +escalation. Crashers and other behaviorial issues are **not** considered a s/Crashers/Crashes/ s/behaviorial/behavioral/ +security risk and thus not backported to a branch being maintained for +security. Any releases made for a branch under security maintenance is s/releases/release/ ? s/for/from/ +source-only and done only when actual security patches have been applied to the +branch. + + +Stages +'' + +Based on what stage the in-development version of Python is in, the +responsibilities of a core developer change in regards to commits to the VCS. + + +Pre-alpha +- +This is the stage a branch is in from the last final release until the first +alpha (a1). There are no special restrictions placed on commits beyond those +imposed by the type of branch being worked on (e.g., in-development vs. +maintenance). + + +Alpha +- +Alphas typically serve as a reminder to core developers that they need to start +getting in changes that change semantics or add something to Python as such +things should not be added during a Beta_. Otherwise no new restrictions are in +place while in alpha. + + +Beta + +A branch in beta means that no new additions to Python are accepted. Bugfixes +and the like are still fine. Being in beta can be viewed much like being in RC_ +but without the extra overhead of needing commit reviews. + + +.. _RC: + +Release Candidate (RC) +-- +A branch preparing for an RC release can only have bugfixes applied that have +been reviewed by other core developers. That reviewer should make a post to the +issue related to the change and be mentioned in the commit message. + +You **cannot** skip the peer review during an RC, no matter how small! Even if +it is a simple copy-and-paste change, **everything** requires peer review from +a core developer. + + +Final +- +When a final release is being cut, only the release manager (RM) can make +changes to the branch. diff --git a/index.rst b/index.rst --- a/index.rst +++ b/index.rst @@ -20,6 +20,7 @@ coredev developers committing + devcycle stdlibchanges langchanges @@ -64,6 +65,7 @@ * :ref:`coredev` * :ref:`developers` * :ref:`committing` +* :ref:`devcycle` Proposing changes to Python itself -- Repository URL: http://hg.python.org/devguide ___ Python-checkins mailing list [email protected] http://ma
Re: [Python-Dev] devguide: Generate patches without code checkout (Was: devguide: Write a guide to committing a patch.)
On Wed, Feb 2, 2011 at 12:27 PM, Nick Coghlan wrote: > On Wed, Feb 2, 2011 at 6:33 PM, anatoly techtonik wrote: >> Making and testing a patch from Python checkout requires compiling >> Python, which is not possible for Windows users. > > That latter comment hasn't been true since Microsoft started releasing > the Visual Studio Express editions. "not possible" here means that practically only a very small percent of Python users will go through the hurdles of getting code checkout, downloading and installing Visual Studio, compiling project, switching their code to use compiled version and finally submitting a patch. BTW, what is the size of Mercurial clone right now? >> We should add less >> hardcore instructions how to use bundled diff.py for creating simple >> patches like docstring, comment fixes or generating new testcases. >> This will greatly reduce the barrier for starting with development. > > Given the length of Python's release cycles, diffs against released > versions are far too likely to be out of date. We want diffs against > the head of the relevant branch. I only see that you want the contribution entry barrier to stay at the height of core developer. > People that can't check out and build their own version of Python are > quite welcome to simply report issues without trying to fix them > themselves. But if they really want for an issue to be fixed, they will need to think about preparing a patch. The first time they ask about plans to fix the issue, they will be asked to send a patch anyway. This person will look into devguide how to send a patch. There will be instructions to download Visual Studio, clone repository, compile, etc. I doubt this person will have time to do this, but next time the person will think twice before reporting. ___ 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: Generate patches without code checkout (Was: devguide: Write a guide to committing a patch.)
On Wed, Feb 2, 2011 at 10:33 AM, anatoly techtonik wrote: > How about patches sent by users who track and fix bugs directly in > codebase of their Python installation? While I don't personally endorse the above approach, if you're going to develop inside your installed site-packages folder it seems like a good idea to at least version control that code by running "hg init" or similar in the site-packages folder. Then you can create diffs against older versions using "hg diff". If one is going to do something crazy one might as well go the whole hog I guess. :) Schiavo Simon ___ 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] devguide: Add a document discussing the development cycle typically followed for
On Wed, 2 Feb 2011 12:04:44 +0100 Sandro Tosi wrote: > > +Security > > + > > +A branch less than five years old but no longer in maintenance mode. > > + > > +The only changes made to a branch that is being maintained for security > > +purposes are somewhat obviously those related to security, e.g., privilege > > +escalation. Crashers and other behaviorial issues are **not** considered a > > s/Crashers/Crashes/ > s/behaviorial/behavioral/ > > > +security risk By the way, crashers *are* a security risk. See http://code.python.org/hg/branches/release2.6-maint/ 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] xmlrpclib and communication verbosity
In an attempt to record the xml exchange in an xmlrpclib.ServerProxy connection, I set its verbose flag to 1. This is the whole premise, and the rest of this message contains a bug report, and general complaints about the API. ServerProxy, or to be a bit more specific, the Transport class (which does all the actual printing), provides very little control over where the output goes. By very little, I mean it only outputs to stdout, which is limiting in a server environment where many a prints occur. That, however, turned out to be the least of my worries: xmlrpclib depends on httplib.HTTP to print the outgoing data, but prints its own incoming data, and they tend to collide, in what I permit myself to call a "race condition", though it's mostly just simple lack of management of a shared resource (stdout). The resulting output is mostly well-formed, with the occasional nonsense produced by an interjection of one string to the middle of the other. Also, there's the nasty business of Transport.request accepting a 'verbose' param, and then setting it as an instance attribute and using *that*, for no apparent reason except to cause yet another potential race condition. I suggest that httplib.HTTP's verbosity will be controlled by a separate flag, if controlled at all. The outgoing communication can easily be printed by transport, allowing for better control of synchrony. Also, ServerProxy should accept an optional output file (=a class with write,writelines methods), which will be the target of all prints. Would Python be interested in such a patch? Best Regards, Erez ___ 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] curtin-win2008-amd64 build slave down for a while
I'm having some power issues due to a major snow storm so my build slave is turned off. Don't worry, everyone's favorite OS will be back to work within the next few days. ___ 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] alternate fix for urllib2 bug #8797
Hello all, This is my first stab at contributing to this list. I'm writing to lobby for bug #8797's fix to be removed and for my fix to put in in its place. I'm probably doing this wrong, so please bear with me. I will embrace whatever scathing criticism I get. The ticket covers all the details (http://bugs.python.org/issue8797#) but I'll try to summarize here: In 2.6.5, urllib2 had a small regression that caused HTTP 401 errors to trigger an infinite recursion when the request handler had HTTP Auth credentials that the server was rejecting. Previously, urllib2 avoided this loop by checking the previous request's headers to see if it had already tried the credentials it was about to try. If it had, it would re-raise the exception instead of trying again. The current fix adds a "max retries" concept to urllib2's handling of HTTP 401 errors so that the code will only retry a certain number of times. To me, the original logic of only trying once for each set of credentials was sound, and it looks like the only reason this stopped working was that in 2.6.5 the auth header wasn't being stored in the same place as the code was expecting to find it. I think it makes sense to revisit this issue and swap out the existing fix for my fix because it's tidier and doesn't introduce this new "max retries" functionality. Please let me know what you think. Thanks, Sam Bull___ 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] alternate fix for urllib2 bug #8797
On Wed, Feb 2, 2011 at 10:55 AM, Sam Bull wrote: >.. I'm writing to lobby for bug #8797's fix to be removed and for my fix to >put in in its place. Please open a separate issue for your patch. Patches attached to closed issues will be lost. ___ 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] alternate fix for urllib2 bug #8797
Hi Sam On Wed, Feb 2, 2011 at 5:55 PM, Sam Bull wrote: > This is my first stab at contributing to this list. I'm writing to lobby for > bug #8797's fix to be removed and for my fix to put in in its place. For what it's worth, I was already about to include your patch as a workaround for the bug in 2.6. See Bitten issue http://bitten.edgewall.org/ticket/658. I also consider Sam's patch to be a cleaner patch than the one that ended up being applied in Python. See my comments in the Bitten mailing list thread: https://groups.google.com/forum/#!topic/bitten/niJENqEGuus. Schiavo Simon ___ 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 merge module
Is there or will there be support for python merge modules so we can include python in our installer? Also, the discussions I saw about windows installers not removing the path on uninstall is completely false as regards the installers that wix creates, at least. I've modified the path many times and explicitly tested that it was removed on uninstall. I can't speak for the msilib package and what it does - perhaps it's doing the wrong thing? But has there been thought towards migrating away from msilib and using platform standard tools such as wix (used by ms office, visual studio, etc.)? ___ 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: Generate patches without code checkout (Was: devguide: Write a guide to committing a patch.)
Am 02.02.2011 13:50, schrieb anatoly techtonik: >>> We should add less >>> hardcore instructions how to use bundled diff.py for creating simple >>> patches like docstring, comment fixes or generating new testcases. >>> This will greatly reduce the barrier for starting with development. >> >> Given the length of Python's release cycles, diffs against released >> versions are far too likely to be out of date. We want diffs against >> the head of the relevant branch. > > I only see that you want the contribution entry barrier to stay at the > height of core developer. Because only core developers are allowed to have a checkout of trunk? 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] Moving stuff out of Misc and over to the devguide
Le 19/01/2011 18:04, Georg Brandl a écrit : > Am 19.01.2011 16:25, schrieb Eric Smith: >>> Bonus question: if we remove maintainers.rst from py3k, what do we do in >>> 3.1 and 2.7? I’d favor removing them over keeping outdated versions. >> >> Is there not some advantage to knowing who was the maintainer (or expert) >> of a given module at the time of a release? > > I don't see much advantage. And if you need the version of maintainers.rst > in another repo, it's not hard to find the revision that corresponds to the > release date. Ping. Do we remove maintainers.rst or do we add a note advising people to look at the up-to-date version on docs.python.org/devguide? (And yes, by “we” I mean I’m volunteering to do either. :) 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: Generate patches without code checkout (Was: devguide: Write a guide to committing a patch.)
On Wed, Feb 2, 2011 at 06:50, anatoly techtonik wrote: > On Wed, Feb 2, 2011 at 12:27 PM, Nick Coghlan wrote: > > On Wed, Feb 2, 2011 at 6:33 PM, anatoly techtonik > wrote: > >> Making and testing a patch from Python checkout requires compiling > >> Python, which is not possible for Windows users. > > > > That latter comment hasn't been true since Microsoft started releasing > > the Visual Studio Express editions. > > "not possible" here means that practically only a very small percent > of Python users will go through the hurdles of getting code checkout, > downloading and installing Visual Studio, compiling project, switching > their code to use compiled version and finally submitting a patch. > In reality this doesn't seem to be the case. In all of the Windows-related Python issues I've looked at in a year and a half, only a small handful of the patches or analysis have been based on installed versions or from users who don't have the capability or interest in setting up the environment. Of course we welcome those users, but my experience shows them to be the minority. Installing Visual Studio is probably one of the more rare steps in the process, as many Windows-using software developers tend to use it for other things. > People that can't check out and build their own version of Python are > > quite welcome to simply report issues without trying to fix them > > themselves. > > But if they really want for an issue to be fixed, they will need to > think about preparing a patch. This is not true at all. It's perfectly acceptable to report an issue and do nothing further. It certainly helps the process to contribute more, but we're happy to just get valid bug reports. Someone even made it easy enough to email [email protected] so you don't even have to create an account. > The first time they ask about plans to > fix the issue, they will be asked to send a patch anyway. We don't want bugs to linger, but there's only so many developers and so little time. If you want to know when something will be fixed, a lot of people will say something like "I won't be able to get to this next week, unless you have a patch of your own". I don't see anything wrong with that. In fact, it's pretty common in open source. This person > will look into devguide how to send a patch. There will be > instructions to download Visual Studio, clone repository, compile, > etc. I doubt this person will have time to do this, but next time the > person will think twice before reporting. I've found quite the opposite to be true. The dev guide I wrote for PSF Sprints, most of which was absorbed into the recently created http://docs.python.org/devguide/, got many people happily setup to contribute and I expect the new one to do the same. In fact, I've heard comments from a number of people that the setup was much easier than they thought, especially compared to other projects. ___ 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] xmlrpclib and communication verbosity
On Wed, Feb 02, 2011 at 03:52:17PM +0200, Erez Sh wrote: > Also, ServerProxy should accept an optional output file (=a class with > write,writelines methods), which will be the target of all prints. Why not logging? Oleg. -- Oleg Broytmanhttp://phdru.name/[email protected] Programmers don't die, they just GOSUB without RETURN. ___ 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 merge module
Am 02.02.2011 20:01, schrieb Hoyt, David: > Is there or will there be support for python merge modules so we can > include python in our installer? I haven't planned any. Contributions are welcome. > But has there been thought towards migrating away from msilib and using > platform standard tools such as wix (used by ms office, visual studio, > etc.)? Are you sure visual studio uses wix? I wouldn't call it a "platform standard tool". The Installer COM object is the platform standard mechanism, and that's what msilib uses. I really see no need to move away from that - it can create arbitrary MSI files. 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] Python merge module
>> Is there or will there be support for python merge modules so we can >> include python in our installer? > >I haven't planned any. Contributions are welcome. > >> But has there been thought towards migrating away from msilib and using >> platform standard tools such as wix (used by ms office, visual studio, >> etc.)? > >Are you sure visual studio uses wix? The visual studio regularly contributes to the wix toolset. They and the .net framework team contributed a lot of the wix bootstrapper (burn) foundational code. > I wouldn't call it a "platform standard tool". It's becoming that as more and more projects are adopting it. It was considered to be shipped w/ VS 2010 but didn't make it due to management/time issues. > The Installer COM object is the platform standard mechanism, and that's what > msilib uses. Why maintain a lib when there's (better), free alternatives out there that are maintained by Microsoft itself? (okay, a group at Microsoft that works on their free time, but has significant contributions by many teams at Microsoft -- thus they have a vested interested in its success). > I really see no need to move away from that - it can create arbitrary MSI > files. Can it create merge modules? Transform files (e.g. localization)? Bootstrappers? There's a lot more to ms installers than the msi itself. Wouldn't it be easier to maintain an XML file than an entire lib dedicated to something that someone else has already solved? ___ 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] r88323 - in python/branches/release31-maint: Lib/configparser.py Misc/NEWS
Hello, > --- python/branches/release31-maint/Lib/configparser.py (original) > +++ python/branches/release31-maint/Lib/configparser.py Wed Feb 2 > 22:35:48 2011 > @@ -88,7 +88,7 @@ > """ > > try: > -from collections import OrderedDict as _default_dict > +from collections import Mapping, OrderedDict as _default_dict > except ImportError: > # fallback for setup.py which hasn't yet built _collections > _default_dict = dict Buildbots can’t compile after that change, because Mapping is not found. I suggest aliasing Mapping to dict in the except block (untested). 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] Python merge module
On Wed, Feb 2, 2011 at 15:27, Hoyt, David wrote: >> The Installer COM object is the platform standard mechanism, and that's what >> msilib uses. > > Why maintain a lib when there's (better), free alternatives out there that > are maintained by Microsoft itself? (okay, a group at Microsoft that works on > their free time, but has significant contributions by many teams at Microsoft > -- thus they have a vested interested in its success). > >> I really see no need to move away from that - it can create arbitrary MSI >> files. > > Can it create merge modules? Transform files (e.g. localization)? > Bootstrappers? There's a lot more to ms installers than the msi itself. > Wouldn't it be easier to maintain an XML file than an entire lib dedicated to > something that someone else has already solved? If Python was starting at ground zero, and the choices were to create a library or to use WiX, the answer might have been different. However with a mature enough library to suit all the needs that anyone has been willing to author, it's certainly more work to create the WiX install and maintain it than it is to merely maintain the existing scripts. As far as the possibility of distributing Python as a merge module? I'd recommend against it. Shared location merge modules are a maintenance nightmare, and private location merge modules may not offer the benefit you need. Better to just install the main Python msi as part of a suite with your installer, whether you build that installer in WiX and burn, or not. Michael ___ 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] alternate fix for urllib2 bug #8797
On Thu, Feb 3, 2011 at 2:13 AM, Alexander Belopolsky wrote: > On Wed, Feb 2, 2011 at 10:55 AM, Sam Bull wrote: >>.. I'm writing to lobby for bug #8797's fix to be removed and for my fix to >>put in in its place. > > Please open a separate issue for your patch. Patches attached to > closed issues will be lost. Antoine reopened it, so that shouldn't be an issue. 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 merge module
>> The Installer COM object is the platform standard mechanism, and >> that's what msilib uses. > > Why maintain a lib when there's (better), free alternatives out there > that are maintained by Microsoft itself? Using msilib is easier than using Wix. It's also more flexible. All you have to know is how the MSI schema works. >> I really see no need to move away from that - it can create >> arbitrary MSI files. > > Can it create merge modules? Transform files (e.g. localization)? It could easily be extended to do so, in a straight-forward manner. > Bootstrappers? Not sure what this is - if it is what I think it is, there is no need to (actually, there is no need to create the other two types of files, either, as it stands). > There's a lot more to ms installers than the msi > itself. Wouldn't it be easier to maintain an XML file than an entire > lib dedicated to something that someone else has already solved? Definitely not. Python is easier than XML. If you think otherwise, feel free to provide a proof in the form of a Wix installation generator for Python. 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] Moving stuff out of Misc and over to the devguide
On Wed, Feb 2, 2011 at 11:48, Éric Araujo wrote: > Le 19/01/2011 18:04, Georg Brandl a écrit : >> Am 19.01.2011 16:25, schrieb Eric Smith: Bonus question: if we remove maintainers.rst from py3k, what do we do in 3.1 and 2.7? I’d favor removing them over keeping outdated versions. >>> >>> Is there not some advantage to knowing who was the maintainer (or expert) >>> of a given module at the time of a release? >> >> I don't see much advantage. And if you need the version of maintainers.rst >> in another repo, it's not hard to find the revision that corresponds to the >> release date. > > Ping. Do we remove maintainers.rst or do we add a note advising people > to look at the up-to-date version on docs.python.org/devguide? > > (And yes, by “we” I mean I’m volunteering to do either. :) You're a little late, Eric; I already moved it. =) ___ 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] r88324 - in python/branches/release31-maint: Doc/library/trace.rst Lib/distutils/tests/__init__.py Lib/distutils/tests/test_archive_util.py Lib/distutils/tests/test_
On Thu, Feb 3, 2011 at 7:38 AM, eric.araujo wrote: > Author: eric.araujo > Date: Wed Feb 2 22:38:37 2011 > New Revision: 88324 > > Log: > Merged revisions 86236,86240,86332,86340,87271,87273,87447 via svnmerge from > svn+ssh://[email protected]/python/branches/py3k > > The missing NEWS entries correspond to changes that were made before 3.1.3, > but > I think it’s not usual to edit entries of released versions, so I put them at > the top. The only reason it isn't usual is because the change normally goes in at roughly the same time as the NEWS update, so it is very rare to have a change in a release without the corresponding NEWS entry. If NEWS entries get missed for the release, better to add them in the right place afterwards (it's easy enough to tell which entries were originally missing by comparing the NEWS file from source control with the one from the release). 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 merge module
Martin v. Löwis wrote: > The Installer COM object is the platform standard > mechanism, and that's what msilib uses. I really see no need to move > away from that - it can create arbitrary MSI files. I've used it to package UpLib for Windows -- see http://uplib.parc.com/hg/uplib/file/e29e36f751f7/win32/build-msi-installer.py. I've generalized some of Martin's code to create a Packager class which supports non-Python pre and post install scripts. I found it much easier to use than WiX, which I also tried. Bill ___ 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] r88324 - in python/branches/release31-maint: Doc/library/trace.rst Lib/distutils/tests/__init__.py Lib/distutils/tests/test_archive_util.py Lib/distutils/tests/test_
Thanks Nick, I moved the entries. Cheers ___ 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] devguide: Add a document discussing the development cycle typically followed for
all fixed On Wed, Feb 2, 2011 at 03:04, Sandro Tosi wrote: > On Wed, Jan 26, 2011 at 23:20, brett.cannon > wrote: >> +The in-development branch is where new functionality and semantic changes > > new functionalities (dunno if it's plural in english or not)? > >> +occur. Currently this branch is known as the "py3k" branch. The next minor >> +release of Python will come from this branch (major releases are once a >> decade >> +and so have no specific rules on how they are started). All changes land in >> this >> +branch and then trickle down to other branches. >> + >> +Once a Final_ release is made from the in-development branch, a branch is >> made >> +to represent the minor version of Python and it goes into maintenance mode. >> +Typically a minor version of Python is under development for about 18 >> months. >> + >> + >> +Maintenance >> +--- >> +The branch currently being maintained for bug fixes. >> + >> +The branch under maintenance is the last minor version of Python to be >> released >> +as Final_. This means that the latest release of Python was 3.1.2, then the > > if the latest release ? > >> +branch representing Python 3.1 is in maintenance mode. >> + >> +The only changes allowed to occur in a maintenance branch without debate >> are bug >> +fixes. >> +Semantic changes **must** be carefully considered as code out in the world >> will >> +have already been developed that will rely on the released semantics. >> Changes >> +related to semantics should be discussed on python-dev before being made. >> + >> +A branch stays in maintenance mode as long as a new minor release has not >> been >> +made. For example, this means that Python 2.6 stayed in maintenance mode >> until >> +Python 2.7.0 was released, at which point 2.7 went into maintenance mode and >> +2.6 went into Security_ mode. As new minor releases occur on a (roughly) 18 >> +month schedule, a branch stays in mainteance mode for the same amount of >> time. > > s/mainteance/maintenance/ > >> + >> +A micro release of a maintenance branch is made about every six months. >> +Typically when a new minor release is made one more release of the new-old >> +version of Python is made. >> + >> + >> +Security >> + >> +A branch less than five years old but no longer in maintenance mode. >> + >> +The only changes made to a branch that is being maintained for security >> +purposes are somewhat obviously those related to security, e.g., privilege >> +escalation. Crashers and other behaviorial issues are **not** considered a > > s/Crashers/Crashes/ > s/behaviorial/behavioral/ > >> +security risk and thus not backported to a branch being maintained for >> +security. Any releases made for a branch under security maintenance is > > s/releases/release/ ? > s/for/from/ > >> +source-only and done only when actual security patches have been applied to >> the >> +branch. >> + >> + >> +Stages >> +'' >> + >> +Based on what stage the in-development version of Python is in, the >> +responsibilities of a core developer change in regards to commits to the >> VCS. >> + >> + >> +Pre-alpha >> +- >> +This is the stage a branch is in from the last final release until the first >> +alpha (a1). There are no special restrictions placed on commits beyond those >> +imposed by the type of branch being worked on (e.g., in-development vs. >> +maintenance). >> + >> + >> +Alpha >> +- >> +Alphas typically serve as a reminder to core developers that they need to >> start >> +getting in changes that change semantics or add something to Python as such >> +things should not be added during a Beta_. Otherwise no new restrictions >> are in >> +place while in alpha. >> + >> + >> +Beta >> + >> +A branch in beta means that no new additions to Python are accepted. >> Bugfixes >> +and the like are still fine. Being in beta can be viewed much like being in >> RC_ >> +but without the extra overhead of needing commit reviews. >> + >> + >> +.. _RC: >> + >> +Release Candidate (RC) >> +-- >> +A branch preparing for an RC release can only have bugfixes applied that >> have >> +been reviewed by other core developers. That reviewer should make a post to >> the >> +issue related to the change and be mentioned in the commit message. >> + >> +You **cannot** skip the peer review during an RC, no matter how small! Even >> if >> +it is a simple copy-and-paste change, **everything** requires peer review >> from >> +a core developer. >> + >> + >> +Final >> +- >> +When a final release is being cut, only the release manager (RM) can make >> +changes to the branch. >> diff --git a/index.rst b/index.rst >> --- a/index.rst >> +++ b/index.rst >> @@ -20,6 +20,7 @@ >> coredev >> developers >> committing >> + devcycle >> >> stdlibchanges >> langchanges >> @@ -64,6 +65,7 @@ >> * :ref:`coredev` >> * :ref:`developers` >> * :ref:`committing` >> + * :ref:`devcycle` >> >> >> Proposing changes to Python itself >> >> -- >>
Re: [Python-Dev] Python merge module
> Using msilib is easier than using Wix. It's also more flexible. IMO, no. It's simply not. > All you have to know is how the MSI schema works. Same with WiX. > It could easily be extended to do so, in a straight-forward manner. Other packaging apps already have it - no work needed. > (actually, there is no need to create the other two types of files, either, > as it stands). Sure there is. Transform files + bootstrappers give you localizable installs in one flat file. > Definitely not. Python is easier than XML. I disagree. > If you think otherwise, feel free to provide a proof in the form of a Wix > installation generator for Python. If you think otherwise, why don't you provide proof and get the WiX guys to switch to Python and use your msilib package? The point is that your argument is nonsensical. I'm really not trying to start a flame war here (my original post only asked if there was "thought towards migrating away from msilib"). There's legitimate need/desire for a merge module to make it easier to package a specific Python version. I can (and am) including it in the bootstrapper, but it would make things much cleaner to simply have a merge module available. If the answer's "no and we don't ever intend to", then that's perfectly fine. (c: I really don't care to argue the merits or virtues of WiX vs. msilib and I apologize if I came across as doing that -- I simply was interested to know if there's any serious thought in the matter and it turns out that people are perfectly happy w/ msilib. ___ 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 merge module
> If Python was starting at ground zero, and the choices were to create > a library or to use WiX, the answer might have been different. > However with a mature enough library to suit all the needs that anyone > has been willing to author, it's certainly more work to create the WiX > install and maintain it than it is to merely maintain the existing > scripts. Sounds reasonable. > As far as the possibility of distributing Python as a merge module? > I'd recommend against it. Shared location merge modules are a > maintenance nightmare, and private location merge modules may not > offer the benefit you need. Better to just install the main Python msi > as part of a suite with your installer, whether you build that > installer in WiX and burn, or not. I'm not familiar w/ shared location merge modules vs. private location merge modules. Are you referring to the possibility of having multiple python apps trying to use their own python versions? How relocatable is python? The maintenance nightmare isn't on your end (in my case), it would be on me to provide patches/upgrades. I do agree that patches w/ merge modules are a pain/nightmare. But what about providing both a merge module and msi so developers have a choice? I work on open source projects myself, and we always provide both a merge module and a normal msi installer. It's very little extra work (in WiX at least) to create both. But I can tell from this discussion that it would require changes in msilib and since I don't have the time to work on it, it would most likely not happen. Perhaps I could generate enough fervor in the community for a merge module, though, to drive msilib development. :p At any rate, where could I find the script used to generate the msi package? Perhaps I can translate it into WiX if I thought it'd be used (but why bother if no one's interested?). ___ 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 merge module
> I found it much easier to use than WiX, which I also tried. I also used to use the Visual Studio installer projects until I needed something a lot more robust (e.g., customized UI + localizable strings). msilib does the job people need it to do and that's fine. I'm really not trying to argue the merits of WiX vs. msilib. Was just wondering if it had been considered... ___ 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 merge module
On Wed, 02 Feb 2011 17:30:43 -0800, "Hoyt, David" wrote: > > Definitely not. Python is easier than XML. > > I disagree. Just as an FYI, I believe that most people in the Python community find XML much more of a pain than Python. Many of us (especially those of us who are not web developers) avoid XML whenever possible, and when we do have to deal with it we tend to abstract it behind easier to work with Python code. The obvious exception to that would be web templating languages, but I personally prefer to avoid those, as well :) -- R. David Murray www.bitdance.com ___ 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 merge module
> I'm really not trying to start a flame war here (my original post > only asked if there was "thought towards migrating away from > msilib"). There's legitimate need/desire for a merge module to make > it easier to package a specific Python version. Please recognize that this question is entirely independent of the question whether Wix is used or not. I'm personally +0 on providing a merge module (although others are apparently opposed to that idea). As for msilib vs. Wix: yes, I did put thought into this (actually originally also when writing msilib, which slightly predates Wix in time). However, I don't see any need to switch, and I actually do believe that Wix couldn't provide a feature-by-feature full replacement of the current packaging code (but I might be wrong). 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] Python merge module
>> As far as the possibility of distributing Python as a merge >> module? I'd recommend against it. Shared location merge modules are >> a maintenance nightmare, and private location merge modules may >> not offer the benefit you need. Better to just install the main >> Python msi as part of a suite with your installer, whether you >> build that installer in WiX and burn, or not. > > I'm not familiar w/ shared location merge modules vs. private > location merge modules. Are you referring to the possibility of > having multiple python apps trying to use their own python versions? > How relocatable is python? Fairly relocatable. If there is was a merge module, I'd really prefer it to be shared. The challenge here is site-packages: different users of the merge module would need different copies of site-packages (or else installing additional packages might break existing software). Another challenge with shared location merge modules is upgrades: the Python installer currently doesn't use stable component IDs; I think this would cause problems for users of the merge module. Providing stable component IDs is a challenge since it's difficult to version the files on disk. Not sure why Michael thinks that a private location merge module would provide no benefits to the user of the merge module. > The maintenance nightmare isn't on your > end (in my case), it would be on me to provide patches/upgrades. I do > agree that patches w/ merge modules are a pain/nightmare. But what > about providing both a merge module and msi so developers have a > choice? I certainly wouldn't stop providing an MSI. The next question would be whether the MSI then also installs into the shared location, or whether it would have a private copy of Python. > I work on open source projects myself, and we always provide > both a merge module and a normal msi installer. It's very little > extra work (in WiX at least) to create both. But what's the quality of these? Ideally, I'd like to create a single merge module which, at the option of the user of the merge module, produces either a shared or a private installation. Is that still only little extra work in Wix? > At any rate, where could I find the script used to generate the msi > package? Perhaps I can translate it into WiX if I thought it'd be > used (but why bother if no one's interested?). It's in Tools/msi/msi.py. 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
