Re: [Python-Dev] PEP 397 (Python launcher for Windows) reference implementation
On 30/06/2011 05:23, Mark Hammond wrote: On 30/06/2011 3:00 AM, Vinay Sajip wrote: PEP 397 (Python launcher for Windows) has a reference implementation in Python. Does anyone know of a C implementation, or is planning/working on one? I realise this is the final objective, so such implementation might be premature, but perhaps someone has been experimenting ... Not yet - my last update of the PEP has made the existing reference implementation out-of-date, so I want to work on that before starting on the C version. However, seeing as my note about the most recent PEP update attracted zero comments.. Sorry, didn't realise you couldn't see me silently nodding my head from the other side of the world ;) I really must work on those communication skills... TJG ___ 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: store the current scope on the stack right away
On Thu, Jun 30, 2011 at 1:53 PM, benjamin.peterson wrote: > http://hg.python.org/cpython/rev/151142c0c5b1 > changeset: 71087:151142c0c5b1 > parent: 71084:9aa3fcab76f0 > user: Benjamin Peterson > date: Wed Jun 29 22:52:39 2011 -0500 > summary: > store the current scope on the stack right away Heh, I was going to comment that the spate of refleaks after your previous commit looked mighty suspicious :) End result is simpler, cleaner code overall, though. 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] PEP 397 (Python launcher for Windows) reference implementation
On 30/06/2011 08:34, Tim Golden wrote: On 30/06/2011 05:23, Mark Hammond wrote: On 30/06/2011 3:00 AM, Vinay Sajip wrote: PEP 397 (Python launcher for Windows) has a reference implementation in Python. Does anyone know of a C implementation, or is planning/working on one? I realise this is the final objective, so such implementation might be premature, but perhaps someone has been experimenting ... Not yet - my last update of the PEP has made the existing reference implementation out-of-date, so I want to work on that before starting on the C version. However, seeing as my note about the most recent PEP update attracted zero comments.. Sorry, didn't realise you couldn't see me silently nodding my head from the other side of the world ;) I really must work on those communication skills... I have that email (the update one from Mark not the silent nodding from Tim) still sitting in my inbox waiting for me to properly read through and comment on... Sorry for being useless, I'll try and move it up the priority list. I really like the PEP and think it will be a *huge* step forward for Windows users - so it's purely the details that need thrashing out (heh). In the latest update Mark also addressed my main concern, making the launcher configurable so it can also be used by alternative implementations (particularly IronPython for Windows). I've copied Jeff Hardy and Dino (IronPython maintainers) in on this, in the hope that they might take a look at the latest version of the PEP too... All the best, Michael TJG ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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: > Not yet - my last update of the PEP has made the existing reference > implementation out-of-date, so I want to work on that before starting on > the C version. However, seeing as my note about the most recent PEP > update attracted zero comments, I admit I lost any sense of urgency on > actually doing this... I'll make an effort to update that reference > impl in the next week or so (but obviously anyone else is free to help ;) Sorry, I just recently came across the PEP when Tim Golden pointed it out to me, when I asked a question about executable script support in packaging. I think I was probably not so focused on Windows at the time of the original announcement ... There's a lot to like in the PEP, and I have some questions relating to the latest version: 1. In the section on shebang line parsing, it says "If the command starts with the definition of a customized command followed by a space character, the customized command will be used." Sorry if I'm being dense, but what's the significance of the trailing space character? In fact, your vpython example in the customeised comments section doesn't show a trailing space - you've used '#! vpython' as the shebang line. 2. The section on .ini files says that "Commands specified in the [.ini file in the] "application directory" [APPDATA] will have precedence over the one next to the [launcher] executable." What's the benefit of this? If you have only one launcher executable of one type (say console, 32-bit) on a system, then there's no point in having two locations for .ini files. If you have multiple copies of the launcher and multiple .ini files next to them, then with this precedence order, you can't specialise the behaviour of anything in a specific launcher .ini that's also specified in the APPDATA .ini. Doesn't it make more sense to look for a setting in any file next to the launcher, and if not found there, look in the APPDATA? That way common things can be defined in the APPDATA .ini and overridden for special cases in the launcher-adjacent .ini. Or have I got completely the wrong end of the stick? By the way, I've already converted the existing Python reference implementation to C (I did it before I saw your response to my post). It basically works in that it does what the Python version does, but doesn't include any handling of -32 suffixes or .ini files. I can post this on BitBucket if anyone's interested, but it's a work in progress. I'm working on some simple tests. 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 30 June 2011 12:13, Michael Foord wrote: > I have that email (the update one from Mark not the silent nodding from Tim) > still sitting in my inbox waiting for me to properly read through and > comment on... Sorry for being useless, I'll try and move it up the priority > list. > > I really like the PEP and think it will be a *huge* step forward for Windows > users - so it's purely the details that need thrashing out (heh). That's my situation, too. I'll try to look through it properly in the next day or two. 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] svn.python.org confusion
Adding a THIS_REPOSITORY_HAS_MOVED file to recent branches looks good. Regards ___ 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] svn.python.org confusion
On Jun 30, 2011, at 04:17 PM, Éric Araujo wrote: >Adding a THIS_REPOSITORY_HAS_MOVED file to recent branches looks good. I'm not against adding this to svn, but please be sure these files don't leak into the tarballs should we need to cut another 2.5 or 2.6 release. I think that just means tweaking sandbox/release/release.py. Cheers, -Barry signature.asc Description: 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] svn.python.org confusion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/30/2011 10:32 AM, Barry Warsaw wrote: > On Jun 30, 2011, at 04:17 PM, Éric Araujo wrote: > >> Adding a THIS_REPOSITORY_HAS_MOVED file to recent branches looks good. > > I'm not against adding this to svn, but please be sure these files don't leak > into the tarballs should we need to cut another 2.5 or 2.6 release. I think > that just means tweaking sandbox/release/release.py. The fact that releases might / will still be made from those branches argues against including the file on them at all: they are in fact the "canonical" repository locations, even if most of the work is done in hg and patched into them. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4MmO4ACgkQ+gerLs4ltQ7ybwCgqIkXCdYWIdPM9dHFDa658nLe RYkAnRccCcuCjxQvYSn/jseLJU/ZTmcQ =+fEZ -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] PEP 397 (Python launcher for Windows) reference implementation
On Thu, Jun 30, 2011 at 4:13 AM, Michael Foord wrote: > In the latest update Mark also addressed my main concern, making the > launcher configurable so it can also be used by alternative implementations > (particularly IronPython for Windows). I've copied Jeff Hardy and Dino > (IronPython maintainers) in on this, in the hope that they might take a look > at the latest version of the PEP too... I skimmed it a while back but haven't had the time to give an in-depth study. On the surface it seems fine, but the devil is in the details... - Jeff ___ 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] time.sleep(-1) behaviour
Hi! This is a request for clarification for the thread "how to call a function for evry 10 seconds" from the user mailinglist/newsgroup. The gist is this: 1. On Linux/Python 2.6, time.sleep(-1.0) raises an IOError. 2. On MS Windows/Python 2.5 or 2.7 this sleeps forever. It seems that converting this to a 32-bit integer for Sleep() causes an underflow. Questions: 1. Is the IOError somehow explainable? 2. Is the IOError acceptable or a bug? 3. Is the behaviour under MS Windows acceptable or a bug? 4. Since time.sleep() is documented to possibly sleep a bit longer than specified, someone suggested that the overall sleep time could also be truncated to a minimum of zero, i.e. treating negative values as zero. Greetings! Uli ** Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ** Visit our website at http://www.dominolaser.com ** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich. ** ___ 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] time.sleep(-1) behaviour
On Thu, 30 Jun 2011 21:13:46 +0200, Ulrich Eckhardt wrote: > 1. Is the IOError somehow explainable? > 2. Is the IOError acceptable or a bug? > 3. Is the behaviour under MS Windows acceptable or a bug? > 4. Since time.sleep() is documented to possibly sleep a bit longer than > specified, someone suggested that the overall sleep time could also be > truncated to a minimum of zero, i.e. treating negative values as zero. Please file a bug report at bugs.python.org. -- R. David Murray http://www.bitdance.com ___ 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] time.sleep(-1) behaviour
Le jeudi 30 juin 2011 à 21:13 +0200, Ulrich Eckhardt a écrit : > Hi! > > This is a request for clarification for the thread "how to call a function > for > evry 10 seconds" from the user mailinglist/newsgroup. > > > The gist is this: > 1. On Linux/Python 2.6, time.sleep(-1.0) raises an IOError. > 2. On MS Windows/Python 2.5 or 2.7 this sleeps forever. It seems that > converting this to a 32-bit integer for Sleep() causes an underflow. select.select() was changed recently to raise an exception if the timeout is negative to get the same behaviour on all platforms. signal.sigtimedwait() (recently added function) raises also an exception if the timeout is negative. If it's an overflow, Python should raise an OverflowError, or raise another error, but not sleep for 2^32-1 (or 2^64-1 ?) seconds. 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] svn.python.org confusion
On Fri, Jul 1, 2011 at 1:40 AM, Tres Seaver wrote: > On 06/30/2011 10:32 AM, Barry Warsaw wrote: >> I'm not against adding this to svn, but please be sure these files don't leak >> into the tarballs should we need to cut another 2.5 or 2.6 release. I think >> that just means tweaking sandbox/release/release.py. > > The fact that releases might / will still be made from those branches > argues against including the file on them at all: they are in fact the > "canonical" repository locations, even if most of the work is done in hg > and patched into them. Indeed, 2.5 and 2.6 should be left alone. +1 on adding such a file to the more recent branches that are handled in hg, though. 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] PEP 397 (Python launcher for Windows) reference implementation
On 30/06/2011 10:09 PM, Vinay Sajip wrote: There's a lot to like in the PEP, and I have some questions relating to the latest version: 1. In the section on shebang line parsing, it says "If the command starts with the definition of a customized command followed by a space character, the customized command will be used." Sorry if I'm being dense, but what's the significance of the trailing space character? In fact, your vpython example in the customeised comments section doesn't show a trailing space - you've used '#! vpython' as the shebang line. This is just clumsy wording on my part - what I'm trying to say is simply that 'vpython3' will not match a customized command 'vpython'. 2. The section on .ini files says that "Commands specified in the [.ini file in the] "application directory" [APPDATA] will have precedence over the one next to the [launcher] executable." What's the benefit of this? The idea is that a user without admin permissions can customize the behaviour - so the admin can add a .ini file, but the user can override any commands in that file with their own definitions. If you have only one launcher executable of one type (say console, 32-bit) on a system, then there's no point in having two locations for .ini files. The idea is that some users will not have permission to edit the one next to the launcher. I'd be open to considering this yagni if others agree. > If you have multiple copies of the launcher and multiple .ini files next to them, then with this precedence order, you can't specialise the behaviour of anything in a specific launcher .ini that's also specified in the APPDATA .ini. The intention is that there only be a single launcher, as only one app can be associated with .py files. OTOH though, file associations can be configured per-user IIRC, and assuming that is the case, we could avoid my multiple-ini-file usecase above by just allowing a different launcher to be registered for a specific user. This is sounding difficult from the UI perspective though (ie, does the installer then need to ask that question, will there be a post-install technique for per-user registration, etc?) Doesn't it make more sense to look for a setting in any file next to the launcher, and if not found there, look in the APPDATA? That way common things can be defined in the APPDATA .ini and overridden for special cases in the launcher-adjacent .ini. Or have I got completely the wrong end of the stick? I came at this from the other angle under the assumption there will only be one launcher installed - so common things can be stored in the launcher-adjacent file and per-user special cases can be in the per-user APPDATA dir. If the expectation was multiple launchers be installed, then I'd probably then prefer to KISS and only have the launcher-adjacent file supported at all. By the way, I've already converted the existing Python reference implementation to C (I did it before I saw your response to my post). It basically works in that it does what the Python version does, but doesn't include any handling of -32 suffixes or .ini files. I can post this on BitBucket if anyone's interested, but it's a work in progress. I'm working on some simple tests. Sure, that would be awesome! I think that will mean your impl is fairly close to the first draft of the PEP I checked into HG, which is nice and still quite useful to use :) 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] commant
and thanks!! lederbill ___ 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] time.sleep(-1) behaviour
On Thursday 30 June 2011, R. David Murray wrote: > Please file a bug report at bugs.python.org. Filed as bug #12459. Uli ** Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ** Visit our website at http://www.dominolaser.com ** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich. ** ___ 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
