Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
2008/11/17 Barry Warsaw <[EMAIL PROTECTED]>: > Martin suggests, and I agree, that we should release Python 3.0 final and > 2.6.1 at the same time. Makes sense to me. That would mean that Python > 2.6.1 should be ready on 03-Dec (well, if Python 3.0 is ready then!). 2.6.1 only two months after 2.6? Why so quickly? Anyway, I don't see any added value in the synchronization, so taking in consideration all the effort you're putting in these releases, I would just want to minimize your workload... which is easier to you? doing both at the same time or not? Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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
[Python-Dev] Issue 4195: Can't execute packages with -m in Python 2.6/3.0
I need a release manager call on whether or not the proposed resolution of this issue goes beyond what is acceptable for a bug fix in 2.6.1. Short version: - Python 2.5 allowed packages to be executed with -m, but in a broken way - I disabled the broken way for 2.6, but didn't provide a replacement - The patch attached to 4195 once again allows execution of packages with -m, but in a clean way similar to the way directories and zipfiles can now be executed - I would like to commit that patch for 3.0/2.6.1, but I'm concerned that it crosses the "no new features" line Long version: There was a bug in python 2.5 that allowed a package name to be passed to the -m switch or runpy.run_module() and it would mostly work. However, the 'mostly' was due to the fact that doing this put the internal import machinery into a slightly inconsistent state: the interpreter was running code from inside a package, but that package wasn't actually present in sys.modules. This could lead to assorted hard to trace import-related weirdness, similar to what you can get when executing a file from inside a package by name. You would often get away with it, but good luck figuring out what is happening if things go wrong (and you aren't already an expert on Python import mechanics). Since the ability to execute packages wasn't intentional, I added the missing check to block it explicitly in 2.6 (but left it alone for 2.5). It seemed like a really niche feature, so I didn't figure out a clean replacement for it at the time. Benjamin noticed this change earlier in the 2.6 release cycle, I pointed out it was a deliberate change, and that's the way it stayed until after 2.6 was released. After the release, Andi Vajda (from the JCC project [1]) contacted me, and together we worked out a better implementation of package support for the -m switch (and runpy.run_module) [2] by extending the __main__.py approach used to support direct execution of zipfiles and directories [3]. That's what I would like to add, since it nicely complements the ability to execute zipfiles and directories, while also restoring the ability to pass a package name to the -m switch (but in a way that keeps the import machinery in a consistent state). Cheers, Nick. [1] http://pypi.python.org/pypi/JCC [2] http://bugs.python.org/issue4195 (package execution with -m) [3] http://bugs.python.org/issue1739468 (zipfile execution) -- Nick Coghlan | [EMAIL PROTECTED] | 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-3000] 2.6.1 and 3.0
Facundo Batista wrote: > 2008/11/17 Barry Warsaw <[EMAIL PROTECTED]>: > >> Martin suggests, and I agree, that we should release Python 3.0 final and >> 2.6.1 at the same time. Makes sense to me. That would mean that Python >> 2.6.1 should be ready on 03-Dec (well, if Python 3.0 is ready then!). > > 2.6.1 only two months after 2.6? Why so quickly? > > Anyway, I don't see any added value in the synchronization, so taking > in consideration all the effort you're putting in these releases, I > would just want to minimize your workload... which is easier to you? > doing both at the same time or not? There have been several corrections made to the 2to3 conversion tool - it would be good to get those in developer's hands at the same time that 3.0 final becomes available. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | 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-3000] 2.6.1 and 3.0
Le Tuesday 18 November 2008 11:03:02 Facundo Batista, vous avez écrit : > 2008/11/17 Barry Warsaw <[EMAIL PROTECTED]>: > > Martin suggests, and I agree, that we should release Python 3.0 final and > > 2.6.1 at the same time. Makes sense to me. That would mean that Python > > 2.6.1 should be ready on 03-Dec (well, if Python 3.0 is ready then!). > > 2.6.1 only two months after 2.6? Why so quickly? Release Early, Release Often? I love release :-) I don't like waiting months to see the bugfixes applied everywhere. 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
[Python-Dev] PyPI Submission Failing
I haven't seen anyone mention it on this list, and there was one message on distutils-sig but it seems to have gone ignored [1]. Uploading packages to PyPI seems to be failing since at least Saturday. I saw a mention somewhere [2] that it would be under maintenance around this date, so whatever was done, it seems to have broken package uploads. [1] http://mail.python.org/pipermail/distutils-sig/2008-November/010491.html [2] http://mail.python.org/pipermail/catalog-sig/2008-November/001926.html -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 Skype zopedc ___ 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-3000] 2.6.1 and 3.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 18, 2008, at 5:03 AM, Facundo Batista wrote: 2008/11/17 Barry Warsaw <[EMAIL PROTECTED]>: Martin suggests, and I agree, that we should release Python 3.0 final and 2.6.1 at the same time. Makes sense to me. That would mean that Python 2.6.1 should be ready on 03-Dec (well, if Python 3.0 is ready then!). 2.6.1 only two months after 2.6? Why so quickly? Actually, I've wanted to do timed releases, though I think monthly is unrealistic. Maybe every two months is about the right time frame. Timed releases are nice because everybody then knows when a patch is due, from developers to downstream consumers. Anyway, I don't see any added value in the synchronization, so taking in consideration all the effort you're putting in these releases, I would just want to minimize your workload... which is easier to you? doing both at the same time or not? We're getting releases down to a science now! :) Actually the most painful part is updating the web site, so I plan adding some automation around that process too. OTOH, this is the first point release I'll be doing with the new script, so it'll be interesting to debug that process. As for synchronization, I think it's a good habit to get into, if my plan to do timed releases works out. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSSLShXEjvBPtnXfVAQL90QP/UfWRXr0esTim+DtQJs9Fd/+Lj9PpuBV6 UCB7pAwl8uf7qIAwjDkCsdg3VD/wxzmzuwDAB8T19PF5dNxsrKWdBEzhymVpLU8T cch0Vlaevm6Co/kDp8VhyoKlPs7LDhGkC2G04qDSOETo8Ci84rBOlWd7n1KvUrYZ 01Pn6eZHdqA= =k9FS -END PGP SIGNATURE- ___ 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-3000] 2.6.1 and 3.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 18, 2008, at 8:07 AM, Christian Heimes wrote: Barry Warsaw wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin suggests, and I agree, that we should release Python 3.0 final and 2.6.1 at the same time. Makes sense to me. That would mean that Python 2.6.1 should be ready on 03-Dec (well, if Python 3.0 is ready then!). Should we release 2.6.1rc1, too? Do we need rc's for point releases? - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSSLSyHEjvBPtnXfVAQJuMAP/cv59kjeFz5DxMk1hMrwXdNQvSs5Ge0lZ ICC4DeKmz0gXZ0+PoZc4Yi9HBAQ8g7ZfKptzIPnEUrg65wV8KS6OzcK5KX5aptvF Mqi+cmD3TPImsOEGoPnJUtlUZ7ZETrY2LSzdIIFqIE5yO1HBt3ohBcdM95+V2zQl zt0uV+F4fnw= =7N3R -END PGP SIGNATURE- ___ 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] 2.6.1 and 3.0
Barry Warsaw wrote: Actually, I've wanted to do timed releases, though I think monthly is unrealistic. Maybe every two months is about the right time frame. Timed releases are nice because everybody then knows when a patch is due, from developers to downstream consumers. From my point of view bi-monthly release are too much. For a ?.?.1 release two months are fine because several issues are found by 3rd party authors. But after that a release every quarter is sufficient. * .1 release two months after the .0 release * .2, .3, .4 and .5 release every quarter * about here the next minor release gets out * .6 and further releases after 6 months when necessary Christian ___ 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] Issue 4195: Can't execute packages with -m in Python 2.6/3.0
I think it crosses the line. On Tue, Nov 18, 2008 at 2:55 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > I need a release manager call on whether or not the proposed resolution > of this issue goes beyond what is acceptable for a bug fix in 2.6.1. > > Short version: > - Python 2.5 allowed packages to be executed with -m, but in a broken way > - I disabled the broken way for 2.6, but didn't provide a replacement > - The patch attached to 4195 once again allows execution of packages > with -m, but in a clean way similar to the way directories and zipfiles > can now be executed > - I would like to commit that patch for 3.0/2.6.1, but I'm concerned > that it crosses the "no new features" line > > Long version: > > There was a bug in python 2.5 that allowed a package name to be passed > to the -m switch or runpy.run_module() and it would mostly work. > > However, the 'mostly' was due to the fact that doing this put the > internal import machinery into a slightly inconsistent state: the > interpreter was running code from inside a package, but that package > wasn't actually present in sys.modules. This could lead to assorted hard > to trace import-related weirdness, similar to what you can get when > executing a file from inside a package by name. You would often get away > with it, but good luck figuring out what is happening if things go wrong > (and you aren't already an expert on Python import mechanics). > > Since the ability to execute packages wasn't intentional, I added the > missing check to block it explicitly in 2.6 (but left it alone for 2.5). > It seemed like a really niche feature, so I didn't figure out a clean > replacement for it at the time. > > Benjamin noticed this change earlier in the 2.6 release cycle, I pointed > out it was a deliberate change, and that's the way it stayed until after > 2.6 was released. > > After the release, Andi Vajda (from the JCC project [1]) contacted me, > and together we worked out a better implementation of package support > for the -m switch (and runpy.run_module) [2] by extending the > __main__.py approach used to support direct execution of zipfiles and > directories [3]. > > That's what I would like to add, since it nicely complements the ability > to execute zipfiles and directories, while also restoring the ability to > pass a package name to the -m switch (but in a way that keeps the import > machinery in a consistent state). > > Cheers, > Nick. > > [1] http://pypi.python.org/pypi/JCC > > [2] http://bugs.python.org/issue4195 (package execution with -m) > [3] http://bugs.python.org/issue1739468 (zipfile execution) > > -- > Nick Coghlan | [EMAIL PROTECTED] | 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/guido%40python.org > -- --Guido van Rossum (home page: http://www.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] PyPI Submission Failing
Sidnei> I haven't seen anyone mention it on this list, and there was one Sidnei> message on distutils-sig but it seems to have gone ignored [1]. I've passed your note along to the website maintainers. Thanks, -- Skip Montanaro - [EMAIL PROTECTED] - http://smontanaro.dyndns.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-3000] 2.6.1 and 3.0
Barry Warsaw schrieb: > On Nov 18, 2008, at 8:07 AM, Christian Heimes wrote: > >> Barry Warsaw wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> Martin suggests, and I agree, that we should release Python 3.0 >>> final and 2.6.1 at the same time. Makes sense to me. That would >>> mean that Python 2.6.1 should be ready on 03-Dec (well, if Python >>> 3.0 is ready then!). > >> Should we release 2.6.1rc1, too? > > Do we need rc's for point releases? I think we did them in the past. There probably never was a significant change between the rc and the final, but Murphy dictates that once you stop doing the rc, the final will be embarrassingly broken :) cheers, Georg ___ 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
[Python-Dev] bytearray methods returning self...
I've been implementing bytearray for IronPython and I noticed a couple of spots where the non-mutating methods of bytearray return self. In 2.6 but not in 3.0 RC2: x = bytearray(b'abc') y = x.replace(b'abc', b'bar', 0) id(x) == id(y) In 2.6 and in 3.0 RC2: t = bytearray() for i in range(256): t.append(i) x = bytearray(b'') y = x.translate(t) id(x) == id(y) Given that bytearray always returns a new instance on all of the other methods shouldn't it return a new instance here as well? I'm just thinking someone could be planning on mutating the result here and not expecting their original bytearray to be mutated. ___ 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] bytearray methods returning self...
Good catch, this is a bug IMO and we should fix it in 2.6.1 and 3.0rc3. Mind filing a bug so we can keep track of it? --Guido On Tue, Nov 18, 2008 at 1:01 PM, Dino Viehland <[EMAIL PROTECTED]> wrote: > I've been implementing bytearray for IronPython and I noticed a couple of > spots where the non-mutating methods of bytearray return self. > > In 2.6 but not in 3.0 RC2: > > x = bytearray(b'abc') > y = x.replace(b'abc', b'bar', 0) > id(x) == id(y) > > In 2.6 and in 3.0 RC2: > > t = bytearray() > for i in range(256): t.append(i) > > x = bytearray(b'') > y = x.translate(t) > id(x) == id(y) > > Given that bytearray always returns a new instance on all of the other > methods shouldn't it return a new instance here as well? I'm just thinking > someone could be planning on mutating the result here and not expecting their > original bytearray to be mutated. -- --Guido van Rossum (home page: http://www.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
[Python-Dev] SSH key for work
Can someone please add the attached SSH 2 DSA key for me? I want to be able to help out with the rc tomorrow while I am at work. -Brett id_dsa.pub Description: Binary data ___ 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] SSH key for work
On Tue, Nov 18, 2008 at 3:17 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > Can someone please add the attached SSH 2 DSA key for me? I want to be > able to help out with the rc tomorrow while I am at work. It's probably best to send this to [EMAIL PROTECTED] > -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner." ___ 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] bytearray methods returning self...
Sure, it's now bug 4348 - http://bugs.python.org/issue4348 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guido van Rossum Sent: Tuesday, November 18, 2008 1:14 PM To: Dino Viehland Cc: python-dev@python.org dev Subject: Re: [Python-Dev] bytearray methods returning self... Good catch, this is a bug IMO and we should fix it in 2.6.1 and 3.0rc3. Mind filing a bug so we can keep track of it? --Guido On Tue, Nov 18, 2008 at 1:01 PM, Dino Viehland <[EMAIL PROTECTED]> wrote: > I've been implementing bytearray for IronPython and I noticed a couple of > spots where the non-mutating methods of bytearray return self. > > In 2.6 but not in 3.0 RC2: > > x = bytearray(b'abc') > y = x.replace(b'abc', b'bar', 0) > id(x) == id(y) > > In 2.6 and in 3.0 RC2: > > t = bytearray() > for i in range(256): t.append(i) > > x = bytearray(b'') > y = x.translate(t) > id(x) == id(y) > > Given that bytearray always returns a new instance on all of the other > methods shouldn't it return a new instance here as well? I'm just thinking > someone could be planning on mutating the result here and not expecting their > original bytearray to be mutated. -- --Guido van Rossum (home page: http://www.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] bytearray methods returning self...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 18, 2008, at 4:14 PM, Guido van Rossum wrote: Good catch, this is a bug IMO and we should fix it in 2.6.1 and 3.0rc3. Ah, a /real/ test of the time machine! Though you can avoid the risk of a rip in the time-space continuum by trying to get the fix into 3.0rc4, planned for release tomorrow. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSSM1b3EjvBPtnXfVAQLrtQP+OEDfWftaUJjLqdKlbH9uSfXKueKUrbJT EZ3HPwSO1Ka5p1zKqNeSiON8MQLTMIzKW2at7YXk4nj0I7YOuho7QxatOVodZ+Er 0bA2w+pnhbJAAcRmhA0nskhXP4F7B8nOJiI6sYpiXxthBYgUu+jsGhad6kky6kwz Kf7PjLIEi3k= =NGqq -END PGP SIGNATURE- ___ 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] SSH key for work
On Tue, Nov 18, 2008 at 13:23, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > On Tue, Nov 18, 2008 at 3:17 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: >> Can someone please add the attached SSH 2 DSA key for me? I want to be >> able to help out with the rc tomorrow while I am at work. > > It's probably best to send this to [EMAIL PROTECTED] Well, chances are that Martin will add the key and he reads both, so I didn't worry about it. =) But I guess we should decide exactly which mailing list to send to and put that in the dev FAQ. -Brett ___ 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] SSH key for work
Brett Cannon wrote: On Tue, Nov 18, 2008 at 13:23, Benjamin Peterson <[EMAIL PROTECTED]> wrote: On Tue, Nov 18, 2008 at 3:17 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: Can someone please add the attached SSH 2 DSA key for me? I want to be able to help out with the rc tomorrow while I am at work. It's probably best to send this to [EMAIL PROTECTED] Well, chances are that Martin will add the key and he reads both, so I didn't worry about it. =) But I guess we should decide exactly which mailing list to send to and put that in the dev FAQ. The python-committers list? ___ 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] SSH key for work
On Tue, Nov 18, 2008 at 3:40 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > On Tue, Nov 18, 2008 at 13:23, Benjamin Peterson > <[EMAIL PROTECTED]> wrote: >> On Tue, Nov 18, 2008 at 3:17 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: >>> Can someone please add the attached SSH 2 DSA key for me? I want to be >>> able to help out with the rc tomorrow while I am at work. >> >> It's probably best to send this to [EMAIL PROTECTED] > > Well, chances are that Martin will add the key and he reads both, so I > didn't worry about it. =) > > But I guess we should decide exactly which mailing list to send to and > put that in the dev FAQ. Section 3.3 of that FAQ: Can I make check-ins from machines other than the one I generated the keys on? Yes, all you need is to make sure that the machine you want to check in code from has both the public and private keys in the standard place that ssh will look for them (i.e. ~/.ssh on Unix machines). Please note that although the key file ending in .pub contains your user name and machine name in it, that information is not used by the verification process, therefore these key files can be moved to a different computer and used for verification. Please guard your keys and never share your private key with anyone. If you lose the media on which your keys are stored or the machine on which your keys are stored, be sure to report this to [EMAIL PROTECTED] at the same time that you change your keys. > > -Brett > -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner." ___ 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] SSH key for work
On Tue, Nov 18, 2008 at 13:47, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > On Tue, Nov 18, 2008 at 3:40 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: >> On Tue, Nov 18, 2008 at 13:23, Benjamin Peterson >> <[EMAIL PROTECTED]> wrote: >>> On Tue, Nov 18, 2008 at 3:17 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: Can someone please add the attached SSH 2 DSA key for me? I want to be able to help out with the rc tomorrow while I am at work. >>> >>> It's probably best to send this to [EMAIL PROTECTED] >> >> Well, chances are that Martin will add the key and he reads both, so I >> didn't worry about it. =) >> >> But I guess we should decide exactly which mailing list to send to and >> put that in the dev FAQ. > > Section 3.3 of that FAQ: > > Can I make check-ins from machines other than the one I generated the keys on? > I know I can simply copy over my private SSH key and it is protected by password, but I would rather not expose my personal SSH key more than I need to and since I don't control my work machine and it's exposure level to others I would rather use another key. -Brett ___ 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-3000] 2.6.1 and 3.0
>> Should we release 2.6.1rc1, too? > > Do we need rc's for point releases? We have been doing them in the past, a week before the release. In this case, I could accept a waiver, given that the previous release acts very well as a release candidate for this release. Regards, Martin ___ 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] SSH key for work
Brett Cannon wrote: > On Tue, Nov 18, 2008 at 13:47, Benjamin Peterson > <[EMAIL PROTECTED]> wrote: >> On Tue, Nov 18, 2008 at 3:40 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: >>> On Tue, Nov 18, 2008 at 13:23, Benjamin Peterson >>> <[EMAIL PROTECTED]> wrote: On Tue, Nov 18, 2008 at 3:17 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > Can someone please add the attached SSH 2 DSA key for me? I want to be > able to help out with the rc tomorrow while I am at work. It's probably best to send this to [EMAIL PROTECTED] >>> Well, chances are that Martin will add the key and he reads both, so I >>> didn't worry about it. =) >>> >>> But I guess we should decide exactly which mailing list to send to and >>> put that in the dev FAQ. >> Section 3.3 of that FAQ: >> >> Can I make check-ins from machines other than the one I generated the keys >> on? >> > > I know I can simply copy over my private SSH key and it is protected > by password, but I would rather not expose my personal SSH key more > than I need to and since I don't control my work machine and it's > exposure level to others I would rather use another key. I think Benjamin was referring more to the last sentence: "If you lose the media on which your keys are stored or the machine on which your keys are stored, be sure to report this to [EMAIL PROTECTED] at the same time that you change your keys." Adding a second key is similar to changing the keys. That said, I don't think python-committers existed when that FAQ entry was written. It's really up to the folks that can add new SSH keys as to which list is most convenient for them though. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | 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-3000] 2.6.1 and 3.0
> From my point of view bi-monthly release are too much. For a ?.?.1 > release two months are fine because several issues are found by 3rd > party authors. But after that a release every quarter is sufficient. > > * .1 release two months after the .0 release > * .2, .3, .4 and .5 release every quarter > * about here the next minor release gets out > * .6 and further releases after 6 months when necessary In the past, we had been striving for releases every 6 month. This was already very difficult to achieve. While I'm happy that Barry has automated his part to a high degree, my part is, unfortunately, much less automated. I could personally automate the build process a bit more, but part of it is also testing of the installers, which is manual. Regards, Martin ___ 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] PyPI Submission Failing
Sidnei da Silva wrote: > I haven't seen anyone mention it on this list, and there was one > message on distutils-sig but it seems to have gone ignored [1]. Please report PyPI bugs to the PyPI bug tracker in the future, linked from each PyPI page. I personally don't read distutils-sig (but catalog-sig, which is the list for PyPI discussion). Regards, Martin ___ 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] SSH key for work
> Adding a second key is similar to changing the keys. That said, I don't > think python-committers existed when that FAQ entry was written. It's > really up to the folks that can add new SSH keys as to which list is > most convenient for them though. I had been trying to set up an email alias for the keychain ever since I set up that mechanism, but I failed doing so. In practice, sending it to pydotorg, python-dev, or me personally makes no difference most of the time (although Neal will sometimes also update python-dev keys, and Andrew will update pydotorg/www keys quite often). Regards, Martin ___ 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] SSH key for work
On Tue, Nov 18, 2008 at 15:40, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> Adding a second key is similar to changing the keys. That said, I don't >> think python-committers existed when that FAQ entry was written. It's >> really up to the folks that can add new SSH keys as to which list is >> most convenient for them though. > > I had been trying to set up an email alias for the keychain ever since > I set up that mechanism, but I failed doing so. In practice, sending > it to pydotorg, python-dev, or me personally makes no difference most > of the time (although Neal will sometimes also update python-dev keys, > and Andrew will update pydotorg/www keys quite often). > I will just say pydotorg in the FAQ for now then. -Brett ___ 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-3000] 2.6.1 and 3.0
"Martin v. Löwis" writes: > While I'm happy that Barry has automated his part to a high degree, > my part is, unfortunately, much less automated. I could personally > automate the build process a bit more, but part of it is also testing > of the installers, which is manual. Maybe you could delegate a lot of the testing to competent volunteers? That would be probably 2 times as much work the first couple of times, (you'd need to formalize your "script" for testing[1] and then check that the volunteers are understanding it correctly, etc) but if they are reliable you could turn that around a lot faster in the future. Footnotes: [1] Doesn't Windows have a way to send synthetic GUI events to a program? There ought to be a way to really script that, as the Python installer process presumbly doesn't change much from release to release. ___ 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-3000] 2.6.1 and 3.0
On Tue, Nov 18, 2008 at 11:55 PM, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote: > Footnotes: > [1] Doesn't Windows have a way to send synthetic GUI events to a > program? There ought to be a way to really script that, as the Python > installer process presumbly doesn't change much from release to release. There's at least PyWinAuto[1], Watsup[2] and winGuiAuto[3]. [1] http://pywinauto.seleniumhq.org/ [2] http://www.tizmoi.net/watsup/intro.html [3] http://www.brunningonline.net/simon/blog/archives/winGuiAuto.py.html -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 Skype zopedc ___ 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-3000] 2.6.1 and 3.0
> > While I'm happy that Barry has automated his part to a high degree, > > my part is, unfortunately, much less automated. I could personally > > automate the build process a bit more, but part of it is also testing > > of the installers, which is manual. > > Maybe you could delegate a lot of the testing to competent volunteers? That's not the issue - I don't mind spending that time. However, it means that several hours pass between starting the release process, and making the binaries available - during this time, users always complain why the Windows binaries are not released yet. With additional volunteers, availability of the binaries would lag even more behind the release announcement. > [1] Doesn't Windows have a way to send synthetic GUI events to a > program? There ought to be a way to really script that, as the Python > installer process presumbly doesn't change much from release to release. I also need to involve different machines, e.g. XP machines and Vista machines, and machines that have Visual Studio installed and machines that don't. Plus, I need to log into each machine in different ways: as admin user and non-admin user. The automated GUI testing only really works for a logged-in user. Regards, Martin ___ 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-3000] 2.6.1 and 3.0
"Martin v. Löwis" writes: > That's not the issue - I don't mind spending that time. However, it > means that several hours pass between starting the release process, > and making the binaries available - during this time, users always > complain why the Windows binaries are not released yet. For "several hours" delay? Shame on the complainers! Ubuntu and MacPorts users have to wait days or weeks for installers. Debian stable users, years! My understanding was that the biggest problem with keeping to a 6-month cycle has always been that it's still a long enough time frame that people will rush to get an 80%-done project into the release just before deadline, causing extra reviewing effort for the senior committers and effort and delays for everyone for bug fixing. One month is probably short enough that people will be willing to submit things at a more appropriate stage in development. Still, it's the review and polishing-up effort that is the bottleneck, it seems to me. Not the installers. ___ 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
