Re: [Python-Dev] PEP 397 (Python launcher for Windows) reference implementation
On 2/07/2011 5:16 PM, I wrote: Given [the C implementation] is now ahead of the Python reference impl, I wonder if we should just drop all wording about that reference impl and just treat the C impl as canonical? I'm looking to update the PEP based on this discussion - does anyone object to the above? Or to put it another way, does anyone believe dropping the Python reference implementation is to the detriment of the PEP? Thanks, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 397 (Python launcher for Windows) reference implementation
Nick Coghlan gmail.com> writes: > I've installed other WIndows apps that create multiple add/remove > programs entries from a single installer. I believe people are > suggesting a similar thing here (i.e. have the launcher installed > automatically when installing python, but create a separate add/remove > entry so uninstallation leaves it behind unless removal is explicitly > requested) Were those other Windows apps packaged as .msi, or .exe? AFAICT, although you can embed an MSI inside another one, the practice of concurrent/nested installations is strongly discouraged by Microsoft - see http://goo.gl/FJx1S (Rule 20). Also, IIUC, each entry in Add/Remove programs would correspond to a specific MSI (since you can e.g. repair that specific entry, it would imply its own installer database). So you could package Python and the launcher as separate MSIs (this would make sense so that you could restore associations to the launcher just by repairing its installation), but since nested MSIs are a no-no, that means installing via a bootstrapping .exe. This is a bigger change to our Windows packaging than some people might be comfortable with ... Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 397 (Python launcher for Windows) reference implementation
On 5 July 2011 03:26, Nick Coghlan wrote: > On Tue, Jul 5, 2011 at 12:12 PM, Mark Hammond > wrote: >> If the launcher is such that we can unconditionally recommend its use, IMO >> we should just install it with Python. I'll go with the consensus though... > > I've installed other WIndows apps that create multiple add/remove > programs entries from a single installer. I believe people are > suggesting a similar thing here (i.e. have the launcher installed > automatically when installing python, but create a separate add/remove > entry so uninstallation leaves it behind unless removal is explicitly > requested) That's certainly what I was meaning. I'm 100% in favour of Python 3.3 and later containing the installer as part of the core Python installer. One download, one install. (And two add/remove entries). I'd like to see a standalone installer for users of Python 2.7/3.2 and earlier. It's too useful a feature to not make it available for people who haven't installed 3.3 yet. And I'd prefer it if that standalone installer was hosted on python.org for visibility, rather than on PyPI. I'm not enough of an MSI expert to know if this can be implemented by having a standalone MSI, and then "embedding" it in the Python 3.3 MSI. That was what I'd thought of, but Vinay's later email suggests it might not be advisable: > AFAICT, although you can embed an MSI inside another one, the practice > of concurrent/nested installations is strongly discouraged by Microsoft - > see http://goo.gl/FJx1S (Rule 20). [...] > So you could package Python and the launcher as separate MSIs (this would > make sense so that you could restore associations to the launcher just by > repairing its installation), but since nested MSIs are a no-no, that means > installing via a bootstrapping .exe. This is a bigger change to our Windows > packaging than some people might be comfortable with ... Paul. ___ Python-Dev mailing list Python-Dev@python.org 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] cpython: Remove mention of medical condition from the test suite.
On Tue, 05 Jul 2011 15:27:00 +0900 "Stephen J. Turnbull" wrote: > > One could also use the somewhat euphemistic "unprofessional language". > That points to why such changes are justified despite an author's > right to have her mode of expression respected -- the Python project > aims at professionalism, and offensive language detracts from it. I sincerely hope we don't start using the word "professional" to denote "careful" or "good quality". Most professional work is crap, and that's why we have open source. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.2): Issue #12497: Install test/data to prevent failures of the various codecmaps
On Tue, 05 Jul 2011 04:11:45 +0200 ned.deily wrote: > LIBSUBDIRS= tkinter tkinter/test tkinter/test/test_tkinter \ > tkinter/test/test_ttk site-packages test \ > - test/capath \ > + test/capath test/data \ > test/cjkencodings test/decimaltestdata test/xmltestdata > test/subprocessdata \ > test/tracedmodules test/encoded_modules \ > concurrent concurrent/futures encodings \ Shouldn't we have something less dumb than a hardcoded list of directories? :) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.2): Issue #12497: Install test/data to prevent failures of the various codecmaps
Le mardi 05 juillet 2011 11:49:03, Antoine Pitrou a écrit : > On Tue, 05 Jul 2011 04:11:45 +0200 > > ned.deily wrote: > > LIBSUBDIRS=tkinter tkinter/test tkinter/test/test_tkinter \ > > > > tkinter/test/test_ttk site-packages test \ > > > > - test/capath \ > > + test/capath test/data \ > > > > test/cjkencodings test/decimaltestdata test/xmltestdata > > test/subprocessdata \ test/tracedmodules test/encoded_modules \ > > concurrent concurrent/futures encodings \ > > Shouldn't we have something less dumb than a hardcoded list of > directories? :) Yes we should, especially because Makefile is not the only file that should be fixed: Tools/msi/msi.py I recently added Lib/test/cjkencodings directory, see issue #12057: R. David Murray: "Haypo, since you've created a new directory there are makefile (and PC build file, I think) updates that will need to be made. (This should be documented in the dev guide if it isn't already.)" Terry J. Reedy: "I presume and hope David meant the process, as I would have no idea how to add a directory. And David did not seem completely sure." Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 397 (Python launcher for Windows) reference implementation
Mark Hammond gmail.com> writes: > Or an MSI installer may be able to offer a "repair" feature without too > much pain. A few more observations to do with installation: 1. It's been mentioned that a standalone version should be available for use with earlier Python versions. This could be done with a merge module which can be used either with a standalone installer or the Python .msi. 2. For the standalone MSI, we will most likely need separate 32-bit and 64-bit MSIs, because the MSI system will look at the MSI type to determine whether registry stuff goes in the main registry or the Wow6432Node used for 32-bit applications. Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 397 (Python launcher for Windows) reference implementation
On Tue, Jul 5, 2011 at 03:01, Vinay Sajip wrote: > Were those other Windows apps packaged as .msi, or .exe? AFAICT, although you > can embed an MSI inside another one, the practice of concurrent/nested > installations is strongly discouraged by Microsoft - see http://goo.gl/FJx1S > (Rule 20). Right, you cannot sanely embed one .msi inside another .msi; the support for "nested" or "concurrent" installations referred to in that link is indeed something to avoid. > So you could package Python and the launcher as separate MSIs (this would make > sense so that you could restore associations to the launcher just by repairing > its installation), but since nested MSIs are a no-no, that means installing > via > a bootstrapping .exe. This is a bigger change to our Windows packaging than > some > people might be comfortable with ... You can certainly jump through all these hoops, but the pieces here are much more suited towards a component definition that can be shared among multiple products. If the component always installs to the same place, has the same GUID, and otherwise only changes by versions the exe, this is a completely safe correct use of one. Last I knew, msi.py allocates random GUIDs, so may or may not be suitable for generating this. If there is only rare need to update this exe, and msi.py has support for merge modules, that could be one approach. My recommendation for distributing this: each .msi which wants to include it should have a component that includes the following. Note that each .exe (py, pyw) and each architecture (x86, x64) need their own component with their own static GUID. * Defined unchanging GUID * Defined target location (perhaps SystemFolder) * msidbComponentAttributesSharedDllRefCount (cooperate with non-MSI installers), msidbComponentAttributesShared (keep highest version), and possibly msidbComponentAttributesPermanent flags set on the component * Versioned .exe (using a Windows version block) * File association information Then these components can be included in the python 3.3 installer, future releases, and even a standalone installer, and reference count correctly. Again, these can optionally be made available as merge modules for other consumers, but there's likely no need. -- Michael Urman ___ Python-Dev mailing list Python-Dev@python.org 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] cpython: Remove mention of medical condition from the test suite.
On Tue, Jul 5, 2011 at 4:27 PM, Stephen J. Turnbull wrote: > That points to why such changes are justified despite an author's > right to have her mode of expression respected -- the Python project > aims at professionalism, and offensive language detracts from it. Given that the contents of many test strings are quite arbitrary, I personally consider a bit of inoffensive humour or cultural references to be a fine thing to include rather than yet another instance of "foobar" (which itself has humorous *and* offensive origins). Heck, stripping just the Monty Python quotes from the test suite would probably take a while :) Avoiding offensive text has nothing to do with a desire to appear "professional" (at least for me) - it's about demonstrating common courtesy to the potentially wide variety of people that will read the Python source code in the future. (In the specific case, I thought quoting the venerable pun was fine, but I also don't have any real problem with modifying it) Cheers, Nick. P.S. 'twas a sad day when copyright concerns cost us the old test audio file :( -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 397 (Python launcher for Windows) reference implementation
Michael Urman gmail.com> writes: > You can certainly jump through all these hoops, but the pieces here > are much more suited towards a component definition that can be shared > among multiple products. If the component always installs to the same > place, has the same GUID, and otherwise only changes by versions the > exe, this is a completely safe correct use of one. Last I knew, msi.py > allocates random GUIDs, so may or may not be suitable for generating > this. If there is only rare need to update this exe, and msi.py has > support for merge modules, that could be one approach. I'm currently experimenting with a merge module approach: launcher_module.msm -> launcher.msi, and x64 variants in separate .amd64.ms? files. > My recommendation for distributing this: each .msi which wants to > include it should have a component that includes the following. Note > that each .exe (py, pyw) and each architecture (x86, x64) need their > own component with their own static GUID. > * Defined unchanging GUID > * Defined target location (perhaps SystemFolder) I'm doing that. > * msidbComponentAttributesSharedDllRefCount (cooperate with non-MSI > installers), msidbComponentAttributesShared (keep highest version), > and possibly msidbComponentAttributesPermanent flags set on the > component Thanks, that's interesting information. I'll read up about these. I'm a Windows installer tyro :-) > * Versioned .exe (using a Windows version block) I'm doing that, too. > * File association information Currently I'm putting the file association information in the same component as the files, since the registry values cross reference those files. Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org 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] cpython: Remove mention of medical condition from the test suite.
Antoine Pitrou writes: > I sincerely hope we don't start using the word "professional" to denote > "careful" or "good quality". No, by "professional" I mean "of a profession," which is a service that is provided by experts to laymen, and therefore demands adherence to certain standards since the clients are not able to judge the product for themselves, but in general must trust the vendor. The care and good quality proceed from the commitment of the professional. > Most professional work is crap, and that's why we have open source. Open source is not a substitute for professionalism. ___ Python-Dev mailing list Python-Dev@python.org 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] cpython: Remove mention of medical condition from the test suite.
On Wed, 06 Jul 2011 01:23:55 +0900 "Stephen J. Turnbull" wrote: > Antoine Pitrou writes: > > > I sincerely hope we don't start using the word "professional" to denote > > "careful" or "good quality". > > No, by "professional" I mean "of a profession," which is a service > that is provided by experts to laymen, and therefore demands adherence > to certain standards since the clients are not able to judge the > product for themselves, but in general must trust the vendor. The > care and good quality proceed from the commitment of the professional. I see. But the "experts" are not necessarily vendors (we aren't), and our users aren't "clients". Besides, we are not merely providing a service, we are building a community where everyone can take part in the shared work, thereby blurring the barrier between "experts" and "laymen". Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org 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] cpython: Remove mention of medical condition from the test suite.
Antoine Pitrou writes: > On Wed, 06 Jul 2011 01:23:55 +0900 > "Stephen J. Turnbull" wrote: > > Antoine Pitrou writes: > > > > > I sincerely hope we don't start using the word "professional" to denote > > > "careful" or "good quality". > > > > No, by "professional" I mean "of a profession," > I see. But the "experts" are not necessarily vendors (we aren't), and > our users aren't "clients". Besides, we are not merely providing a > service, we are building a community where everyone can take part in > the shared work, thereby blurring the barrier between "experts" and > "laymen". *sigh* And another good word bites the dust. OK, I will reserve the adjective "professional" for those who appreciate it. Nick's "common courtesy" will do for the current purpose. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiling Python 3.2 on Cygwin fails
On Tue, Jul 5, 2011 at 7:25 AM, David Robinow wrote: > > Cygwin is not really a supported platform. ... > [Ultimately somebody with an > interest in cygwin will need to get active in python development. I've > been meaning to do this but life gets in the way.] > I was bitten by the lack of Cygwin support in 3.2 as well. IMO, python-dev needs continuous integration on a build farm that includes representative platforms. Most of the machines in the farm could be virtualboxes. I don't think the problem is so much that the right people haven't gotten involved, as that the currently-involved people don't know when they're breaking something for someone else due to the lack of continuous integration. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiling Python 3.2 on Cygwin fails
On Tue, Jul 5, 2011 at 14:12, Dan Stromberg wrote: > > On Tue, Jul 5, 2011 at 7:25 AM, David Robinow wrote: > >> >> Cygwin is not really a supported platform. > > ... > >> [Ultimately somebody with an >> interest in cygwin will need to get active in python development. I've >> been meaning to do this but life gets in the way.] >> > > I was bitten by the lack of Cygwin support in 3.2 as well. > > IMO, python-dev needs continuous integration on a build farm that > includes representative platforms. Most of the machines in the farm could > be virtualboxes. > > I don't think the problem is so much that the right people haven't gotten > involved, as that the currently-involved people don't know when they're > breaking something for someone else due to the lack of continuous > integration. > We've had that for some time now: http://www.python.org/dev/buildbot/ There are several issues on the bug tracker about cygwin build issues, but to my knowledge, none of them have included successful patches. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiling Python 3.2 on Cygwin fails
On Tue, Jul 5, 2011 at 12:18 PM, Brian Curtin wrote: > On Tue, Jul 5, 2011 at 14:12, Dan Stromberg wrote: > >> >> On Tue, Jul 5, 2011 at 7:25 AM, David Robinow wrote: >> >>> >>> Cygwin is not really a supported platform. >> >> ... >> >>> [Ultimately somebody with an >>> interest in cygwin will need to get active in python development. I've >>> been meaning to do this but life gets in the way.] >>> >> >> I was bitten by the lack of Cygwin support in 3.2 as well. >> >> IMO, python-dev needs continuous integration on a build farm that >> includes representative platforms. Most of the machines in the farm could >> be virtualboxes. >> >> I don't think the problem is so much that the right people haven't gotten >> involved, as that the currently-involved people don't know when they're >> breaking something for someone else due to the lack of continuous >> integration. >> > > We've had that for some time now: http://www.python.org/dev/buildbot/ > Good to know. Apologies for my incorrect assumption. Where do the e-mail notifications of build and/or test failures go? Shouldn't Cygwin be represented here? I don't see it in the list of builds. Some shops have a policy that nothing gets merged into trunk unless it's passing critical automated tests... Would that work here? There are several issues on the bug tracker about cygwin build issues, but > to my knowledge, none of them have included successful patches. > I think you'll find that most people using Cygwin would rather be working on some other OS, but are forced to use Windows for policy reasons. It's remains a rather significant need in many cases. How does the buildbot initiate builds? ssh? Happily Cygwin mostly allows sshd (as long as you don't need a CIFS share or something). Native Windows builds do appear to be represented. Is there any reason not to set up a buildbot for Cygwin on the same (virtual?) hardware? I'm inclined to believe that whoever rearranged the shared object stuff in CPython 3.x's build system would've been more careful if they'd had feedback about what it was doing to Cygwin. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiling Python 3.2 on Cygwin fails
On Tue, Jul 5, 2011 at 14:41, Dan Stromberg wrote: > > On Tue, Jul 5, 2011 at 12:18 PM, Brian Curtin wrote: > >> On Tue, Jul 5, 2011 at 14:12, Dan Stromberg wrote: >> >>> >>> On Tue, Jul 5, 2011 at 7:25 AM, David Robinow wrote: >>> Cygwin is not really a supported platform. >>> >>> ... >>> [Ultimately somebody with an interest in cygwin will need to get active in python development. I've been meaning to do this but life gets in the way.] >>> >>> I was bitten by the lack of Cygwin support in 3.2 as well. >>> >>> IMO, python-dev needs continuous integration on a build farm that >>> includes representative platforms. Most of the machines in the farm could >>> be virtualboxes. >>> >>> I don't think the problem is so much that the right people haven't gotten >>> involved, as that the currently-involved people don't know when they're >>> breaking something for someone else due to the lack of continuous >>> integration. >>> >> >> We've had that for some time now: http://www.python.org/dev/buildbot/ >> > > Good to know. Apologies for my incorrect assumption. Where do the e-mail > notifications of build and/or test failures go? > There might be an RSS feed or something, but I don't think there's any email notification. #python-dev on IRC receives live failure info. Other than that, you'd just have to look at one of the views of the fleet to see which build slaves are failing. > Shouldn't Cygwin be represented here? I don't see it in the list of > builds. > Probably, but it isn't represented because no one contributed a build slave for it. I know some of the other Windows build slave operators use Cygwin to some degree, but I'm not sure if anyone has looked into actually setting up a build slave for it. Some shops have a policy that nothing gets merged into trunk unless it's > passing critical automated tests... Would that work here? > We don't make much use of branching, but that would work if we did. If no one is actively contributing work on the Cygwin build then I don't see us holding up work in order to figure out any Cygwin-specific issues. There are several issues on the bug tracker about cygwin build issues, but >> to my knowledge, none of them have included successful patches. >> > > I think you'll find that most people using Cygwin would rather be working > on some other OS, but are forced to use Windows for policy reasons. It's > remains a rather significant need in many cases. > I don't disagree with that, but if there's no one contributing Cygwin patches then it will probably just die off and we'll have situations like the current one where it doesn't build. A great majority of the contributing developers are on UNIX-based systems with no access to Windows. A small handful, myself included, are Windows users, but I don't think any of us use Cygwin (I don't). Native Windows builds do appear to be represented. Is there any reason not > to set up a buildbot for Cygwin on the same (virtual?) hardware? > Besides the time and effort needed to set it up and occasionally look over it, no. We'd have to have a successfully compiling Cygwin build before we think about adding a build slave for it. I wouldn't be opposed to hosting this myself, but I need to steal some time and get my Windows 2008 build slave back to some form of a functional system - it has been up and down for a few months now. If someone else is interested, go ahead. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiling Python 3.2 on Cygwin fails
On Tue, Jul 5, 2011 at 1:00 PM, Brian Curtin wrote: > On Tue, Jul 5, 2011 at 14:41, Dan Stromberg wrote: > >> >> On Tue, Jul 5, 2011 at 12:18 PM, Brian Curtin wrote: >> >>> On Tue, Jul 5, 2011 at 14:12, Dan Stromberg wrote: >>> On Tue, Jul 5, 2011 at 7:25 AM, David Robinow wrote: > > Cygwin is not really a supported platform. ... > [Ultimately somebody with an > interest in cygwin will need to get active in python development. I've > been meaning to do this but life gets in the way.] > I was bitten by the lack of Cygwin support in 3.2 as well. IMO, python-dev needs continuous integration on a build farm that includes representative platforms. Most of the machines in the farm could be virtualboxes. I don't think the problem is so much that the right people haven't gotten involved, as that the currently-involved people don't know when they're breaking something for someone else due to the lack of continuous integration. >>> >>> We've had that for some time now: http://www.python.org/dev/buildbot/ >>> >> >> Good to know. Apologies for my incorrect assumption. Where do the e-mail >> notifications of build and/or test failures go? >> > > There might be an RSS feed or something, but I don't think there's any > email notification. #python-dev on IRC receives live failure info. Other > than that, you'd just have to look at one of the views of the fleet to see > which build slaves are failing. > Am I correct in assuming that "stable" buildbots are required to be reasonably functional before a release is tagged? > Shouldn't Cygwin be represented here? I don't see it in the list of >> builds. >> > > Probably, but it isn't represented because no one contributed a build slave > for it. I know some of the other Windows build slave operators use Cygwin to > some degree, but I'm not sure if anyone has looked into actually setting up > a build slave for it. > I see. > Some shops have a policy that nothing gets merged into trunk unless it's >> passing critical automated tests... Would that work here? >> > > We don't make much use of branching, but that would work if we did. If no > one is actively contributing work on the Cygwin build then I don't see us > holding up work in order to figure out any Cygwin-specific issues. > I might suggest that doing so (using branching, keeping trunk stable) might be of benefit, especially with a DVCS. > > There are several issues on the bug tracker about cygwin build issues, but >>> to my knowledge, none of them have included successful patches. >>> >> >> I think you'll find that most people using Cygwin would rather be working >> on some other OS, but are forced to use Windows for policy reasons. It's >> remains a rather significant need in many cases. >> > > I don't disagree with that, but if there's no one contributing Cygwin > patches then it will probably just die off and we'll have situations like > the current one where it doesn't build. A great majority of the contributing > developers are on UNIX-based systems with no access to Windows. A small > handful, myself included, are Windows users, but I don't think any of us use > Cygwin (I don't). > I see. Is there a python.org resource for setting up mailing lists - say, for a python-cygwin mailing list? > Native Windows builds do appear to be represented. Is there any reason not >> to set up a buildbot for Cygwin on the same (virtual?) hardware? >> > > Besides the time and effort needed to set it up and occasionally look over > it, no. We'd have to have a successfully compiling Cygwin build before we > think about adding a build slave for it. > That makes sense. > I wouldn't be opposed to hosting this myself, but I need to steal some time > and get my Windows 2008 build slave back to some form of a functional system > - it has been up and down for a few months now. If someone else is > interested, go ahead. > I might contribute some elbow grease if someone could get me VNC access to a suitable Windows server. BTW, is there someone available who is familiar with the meanings of the various shared object-related make symbols? I glanced at them and didn't find their naming astonishingly clear - seems like something to document, or... maybe it already is, and I just haven't seen where it is yet. ___ Python-Dev mailing list Python-Dev@python.org 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] cpython: Issue #12452: Plist and Dict are now deprecated
Le mardi 05 juillet 2011 à 07:59 -0400, Eric Smith a écrit : > On 7/4/2011 8:28 AM, victor.stinner wrote: > > http://hg.python.org/cpython/rev/4f14050a963f > > changeset: 71194:4f14050a963f > > user:Victor Stinner > > date:Mon Jul 04 14:28:45 2011 +0200 > > summary: > > Issue #12452: Plist and Dict are now deprecated > > > > Replace PendingDeprecationWarning warnings by DeprecationWarning. > > Shouldn't this be in MISC/News, be accompanied by documentation changes, > and have tests? Plist and Dict were never documented (in Doc/library/plistlib.rst). These classes have no test. You mean that I should add an entry to Misc/NEWS saying that these classe are now deprecated? Should I also mention the deprecation to the "What's new in Python 3.3?" document? Victor ___ Python-Dev mailing list Python-Dev@python.org 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] cpython: Issue #12452: Plist and Dict are now deprecated
> Plist and Dict were never documented (in Doc/library/plistlib.rst). > These classes have no test. Ouch! > You mean that I should add an entry to Misc/NEWS saying that these > classe are now deprecated? Should I also mention the deprecation to the > "What's new in Python 3.3?" document? Yes. I think this should make it into a "What's new" document, usually via Misc/NEWS. Thanks. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #12469: replace assertions by explicit if+raise
Exception is for catching, not raising. On Jul 4, 2011 11:57 AM, "Victor Stinner" wrote: > Le lundi 04 juillet 2011 à 18:23 +0200, Antoine Pitrou a écrit : >> On Mon, 04 Jul 2011 18:06:53 +0200 >> victor.stinner wrote: >> > http://hg.python.org/cpython/rev/7eef821ab20d >> > changeset: 71197:7eef821ab20d >> > user: Victor Stinner >> > date: Mon Jul 04 18:06:35 2011 +0200 >> > summary: >> > Issue #12469: replace assertions by explicit if+raise > > >> Instead of generic Exception, it would be better to use AssertionError. > > and > >> or in many cases given this was in unittests... use the self.assertFoo >> methods and avoid assert and if statements all together. > > The code is running in a subprocess (python -c ...), not in an > unittest.TestCase, so I cannot use self.assertFoo and it doesn't really > matter if the exception is an Exception or an AssertionError. > >> What is the reason for this change anyway -- as far as I can >> see this code is never run with -O. > > I'm not sure that the code will never be running using -O, so I prefer > to use an explicit if+raise. I don't like the assert statement because > it doesn't provide any information about the failure (content of the > variables) by default. > > Victor > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org ___ Python-Dev mailing list Python-Dev@python.org 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] cpython: Remove mention of medical condition from the test suite.
It's not a bug and shouldn't be "fixed". We leave lots of minor infractions
in the code because the code churn of fixing them all would be too
distracting.
On Jul 3, 2011 10:22 AM, "georg.brandl" wrote:
> http://hg.python.org/cpython/rev/76452b892838
> changeset: 71146:76452b892838
> parent: 71144:ce52310f61a0
> user: Georg Brandl
> date: Sun Jul 03 19:22:42 2011 +0200
> summary:
> Remove mention of medical condition from the test suite.
>
> files:
> Lib/test/test_csv.py | 8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
>
> diff --git a/Lib/test/test_csv.py b/Lib/test/test_csv.py
> --- a/Lib/test/test_csv.py
> +++ b/Lib/test/test_csv.py
> @@ -459,20 +459,20 @@
> '5', '6']])
>
> def test_quoted_quote(self):
> - self.readerAssertEqual('1,2,3,"""I see,"" said the blind man","as he
picked up his hammer and saw"',
> + self.readerAssertEqual('1,2,3,"""I see,"" said the happy man","as he
picked up his hammer and saw"',
> [['1', '2', '3',
> - '"I see," said the blind man',
> + '"I see," said the happy man',
> 'as he picked up his hammer and saw']])
>
> def test_quoted_nl(self):
> input = '''\
> 1,2,3,"""I see,""
> -said the blind man","as he picked up his
> +said the happy man","as he picked up his
> hammer and saw"
> 9,8,7,6'''
> self.readerAssertEqual(input,
> [['1', '2', '3',
> - '"I see,"\nsaid the blind man',
> + '"I see,"\nsaid the happy man',
> 'as he picked up his\nhammer and saw'],
> ['9','8','7','6']])
>
>
> --
> Repository URL: http://hg.python.org/cpython
___
Python-Dev mailing list
Python-Dev@python.org
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] cpython: Remove mention of medical condition from the test suite.
To clarify, now that I have access to an actual keyboard instead of
just a cellphone: I think it should be rolled back, since the proper
process for controversial changes was not followed. Our process (part
of our culture, if you will) for anything controversial is to discuss
the change first, then, if deemed necessary, fix the code. And from
the size of this thread it clearly is controversial. Georg, can you
please revert this change?
Note that another part of our process/culture is that we try not to
engage in battling commits, i.e. generally we don't unilaterally roll
back a change just to make the point that it is incorrect; we ask the
original committer to roll it back.
As to the controversy itself, if you want to make blind people fell
more at home in the Python community surely there are more useful
things to do than to remove puns involving blindness; e.g. improve
accessibility of python.org or some part of it. Or maybe find some
blind programmers and ask them what would help them.
--Guido
On Tue, Jul 5, 2011 at 3:50 PM, Guido van Rossum wrote:
> It's not a bug and shouldn't be "fixed". We leave lots of minor infractions
> in the code because the code churn of fixing them all would be too
> distracting.
>
> On Jul 3, 2011 10:22 AM, "georg.brandl" wrote:
>> http://hg.python.org/cpython/rev/76452b892838
>> changeset: 71146:76452b892838
>> parent: 71144:ce52310f61a0
>> user: Georg Brandl
>> date: Sun Jul 03 19:22:42 2011 +0200
>> summary:
>> Remove mention of medical condition from the test suite.
>>
>> files:
>> Lib/test/test_csv.py | 8
>> 1 files changed, 4 insertions(+), 4 deletions(-)
>>
>>
>> diff --git a/Lib/test/test_csv.py b/Lib/test/test_csv.py
>> --- a/Lib/test/test_csv.py
>> +++ b/Lib/test/test_csv.py
>> @@ -459,20 +459,20 @@
>> '5', '6']])
>>
>> def test_quoted_quote(self):
>> - self.readerAssertEqual('1,2,3,"""I see,"" said the blind man","as he
>> picked up his hammer and saw"',
>> + self.readerAssertEqual('1,2,3,"""I see,"" said the happy man","as he
>> picked up his hammer and saw"',
>> [['1', '2', '3',
>> - '"I see," said the blind man',
>> + '"I see," said the happy man',
>> 'as he picked up his hammer and saw']])
>>
>> def test_quoted_nl(self):
>> input = '''\
>> 1,2,3,"""I see,""
>> -said the blind man","as he picked up his
>> +said the happy man","as he picked up his
>> hammer and saw"
>> 9,8,7,6'''
>> self.readerAssertEqual(input,
>> [['1', '2', '3',
>> - '"I see,"\nsaid the blind man',
>> + '"I see,"\nsaid the happy man',
>> 'as he picked up his\nhammer and saw'],
>> ['9','8','7','6']])
>>
>>
>> --
>> Repository URL: http://hg.python.org/cpython
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiling Python 3.2 on Cygwin fails
On Tue, Jul 5, 2011 at 15:10, Dan Stromberg wrote: > > On Tue, Jul 5, 2011 at 1:00 PM, Brian Curtin wrote: > >> On Tue, Jul 5, 2011 at 14:41, Dan Stromberg wrote: >> >>> >>> On Tue, Jul 5, 2011 at 12:18 PM, Brian Curtin wrote: >>> On Tue, Jul 5, 2011 at 14:12, Dan Stromberg wrote: > > On Tue, Jul 5, 2011 at 7:25 AM, David Robinow wrote: > >> >> Cygwin is not really a supported platform. > > ... > >> [Ultimately somebody with an >> interest in cygwin will need to get active in python development. I've >> been meaning to do this but life gets in the way.] >> > > I was bitten by the lack of Cygwin support in 3.2 as well. > > IMO, python-dev needs continuous integration on a build farm that > includes representative platforms. Most of the machines in the farm could > be virtualboxes. > > I don't think the problem is so much that the right people haven't > gotten involved, as that the currently-involved people don't know when > they're breaking something for someone else due to the lack of continuous > integration. > We've had that for some time now: http://www.python.org/dev/buildbot/ >>> >>> Good to know. Apologies for my incorrect assumption. Where do the >>> e-mail notifications of build and/or test failures go? >>> >> >> There might be an RSS feed or something, but I don't think there's any >> email notification. #python-dev on IRC receives live failure info. Other >> than that, you'd just have to look at one of the views of the fleet to see >> which build slaves are failing. >> > > Am I correct in assuming that "stable" buildbots are required to be > reasonably functional before a release is tagged? > Yep - all green is the goal. > > >> Shouldn't Cygwin be represented here? I don't see it in the list of >>> builds. >>> >> >> Probably, but it isn't represented because no one contributed a build >> slave for it. I know some of the other Windows build slave operators use >> Cygwin to some degree, but I'm not sure if anyone has looked into actually >> setting up a build slave for it. >> > > I see. > > >> Some shops have a policy that nothing gets merged into trunk unless it's >>> passing critical automated tests... Would that work here? >>> >> >> We don't make much use of branching, but that would work if we did. If no >> one is actively contributing work on the Cygwin build then I don't see us >> holding up work in order to figure out any Cygwin-specific issues. >> > > I might suggest that doing so (using branching, keeping trunk stable) might > be of benefit, especially with a DVCS. > > >> >> There are several issues on the bug tracker about cygwin build issues, but to my knowledge, none of them have included successful patches. >>> >>> I think you'll find that most people using Cygwin would rather be working >>> on some other OS, but are forced to use Windows for policy reasons. It's >>> remains a rather significant need in many cases. >>> >> >> I don't disagree with that, but if there's no one contributing Cygwin >> patches then it will probably just die off and we'll have situations like >> the current one where it doesn't build. A great majority of the contributing >> developers are on UNIX-based systems with no access to Windows. A small >> handful, myself included, are Windows users, but I don't think any of us use >> Cygwin (I don't). >> > > I see. > > Is there a python.org resource for setting up mailing lists - say, for a > python-cygwin mailing list? > You might want to suggest something like cygwin-sig as a mailing list. Check out http://www.python.org/community/sigs/guidelines/ for more info. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiling Python 3.2 on Cygwin fails
On Wed, Jul 6, 2011 at 10:38 AM, Brian Curtin wrote: > On Tue, Jul 5, 2011 at 15:10, Dan Stromberg wrote: >> Am I correct in assuming that "stable" buildbots are required to be >> reasonably functional before a release is tagged? > > Yep - all green is the goal. Indeed, that's the main difference between the stable and unstable buildbots. stable = this should work. If it doesn't, somebody broke something and the relevant branch should be fixed unstable = someone cared enough to set up this buildbot, but due to problems with either the platform in general or the specific machine it spends a lot of its time red for reasons that aren't the fault of recent changes to Python A Cygwin buildbot would start in the latter category then potentially migrate to stable if it proved itself with green results over a period of time. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org 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] cpython: Remove mention of medical condition from the test suite.
On Wed, Jul 6, 2011 at 6:17 AM, Georg Brandl wrote: > For this test string, a) I'm not a native speaker and therefore don't know of > any special treatment this pun deserves It's not an especially *good* joke, just a very old one that plays on double meanings of both "see" (as in sight and understanding) and "saw" (as in sight and a tool). Still, I'd put it in the same category as the Monty Python quotes we have scattered around the test suite - if people came across them and didn't realise they were quotes they might be puzzled, but attempting to retain that Pythonesque sense of humour is itself part of what makes the Python community what it is. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Remove mention of medical condition from the test suite.
Georg Brandl, 06.07.2011 07:35: Well, it was stated that even non-joking use of such words can offend (the example given was "your argument is blind to (these facts)"). I consider use in jokes to be more serious, since it's careless use. Sorry if I overreacted here. There's a common saying that a disabled person can't be considered "normal" unless he/she can also be called an asshole from time to time. Personally, I do not consider the pun in question harmful, simply because it's so clearly just a play on words that doesn't make much sense, apart from having a double meaning. In general, however, I think it's important to make jokes with and about disabled people. That keeps them inside of our society, just like anyone else. Treating them as "untouchable" means to single them out. On that note, if anyone of you ever makes it to the beautiful village of Amersfoort (NL), don't miss the "Downey's" café. Nice and friendly place to be. Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
