[Python-Dev] PEP 405 (Python Virtual Environments) and Windows script support
In the recent check-in I made of the PEP 405 functionality, there is a Windows executable. Antoine asked what this was in his comment on the checkin, but I couldn't respond via Gmane (my usual method) as for some reason his post doesn't appear there. PEP 397 (Python launcher for Windows) has not yet been accepted, so there still needs to be some way of natively launching scripts in Windows which is equivalent to /path/to/venv/bin/foo. The way setuptools (and hence Distribute) does this is to shadow each script with an executable: whereas a script foo would be simply placed in /path/to/venv/bin/ on POSIX, on Windows, the files foo.exe and foo-script.py (or foo-script.pyw) are placed in \path\to\venv\Scripts. The user can run \path\to\venv\Scripts\foo just as on POSIX. The foo.exe file is just a copy of a stock launcher executable which finds its name from the C argv[0], and based in that name (foo in this case), invokes foo-script.py or foo-script.pyw with the appropriate Python interpreter. There are two versions of the launcher - console and Windows - built from the same source. These append -script.py and -script.pyw respectively, hard-coded into the executable. The idea is for packaging to do the appropriate copying of stock-launcher.exe to foo.exe when installing scripts. AFAIK this is not yet in packaging, but I implemented it in the pythonv branch (that code was not part of the PEP 405 implementation - it just allowed me to explore how venvs would work with packaging on Windows). The setuptools versions of these scripts are compiled using MinGW. I don't know if we can use them as is, and as the functionality is fairly simple, I implemented it in a separate project using MSVC: https://bitbucket.org/vinay.sajip/simple_launcher We may not need any of this, if PEP 397 is accepted in time. However, if it isn't, I would expect that something like these launchers will be needed. In my packaging code in the pythonv branch, there are different variants - t32.exe, t64.exe, w32.exe, w64.exe - one of which is picked as the source for copying to the destination when installing a script. These .exes are UPX-compressed versions of the executables created by the Microsoft compiler and linker (using static linking). Comments welcome, especially on whether Windows users agree that something like this is needed in the absence of PEP 397 in Python 3.3. Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (Python Virtual Environments) and Windows script support
On Mon, 28 May 2012 17:25:10 + (UTC) Vinay Sajip wrote: > > The foo.exe file is just a copy of a stock launcher executable which finds its > name from the C argv[0], and based in that name (foo in this case), invokes > foo-script.py or foo-script.pyw with the appropriate Python interpreter. Regardless of what the executable is or does, its source code must be included somewhere in the Python source tree (and, preferably, there should be a simple procedure to build the binaries). Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (Python Virtual Environments) and Windows script support
Antoine Pitrou pitrou.net> writes: > Regardless of what the executable is or does, its source code must be > included somewhere in the Python source tree (and, preferably, there > should be a simple procedure to build the binaries). I understand that. Does it need to be checked in right now? It will need integrating with the existing VS2010 solution file, and at the moment I cannot do that integration because I haven't yet got a full VS2010 build environment, just a VS2008 one. Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (Python Virtual Environments) and Windows script support
On Mon, 28 May 2012 19:37:55 + (UTC) Vinay Sajip wrote: > Antoine Pitrou pitrou.net> writes: > > > Regardless of what the executable is or does, its source code must be > > included somewhere in the Python source tree (and, preferably, there > > should be a simple procedure to build the binaries). > > I understand that. Does it need to be checked in right now? Not necessarily, but OTOH, it is not really standard procedure to commit half-finished patches. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (Python Virtual Environments) and Windows script support
Antoine Pitrou pitrou.net> writes: > Not necessarily, but OTOH, it is not really standard procedure to > commit half-finished patches. I didn't want to miss the window for the upcoming alpha, and and I'm not sure exactly how things will pan out with respect to PEP 397 and packaging. If people generally feel strongly about this, I can delete the .exe and re-introduce it later if/when appropriate. It might have had a few rough edges, but I wouldn't have characterised the patch as "half-finished" - that seems a little harsh :-) Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (Python Virtual Environments) and Windows script support
On Mon, 28 May 2012 21:23:50 + (UTC) Vinay Sajip wrote: > Antoine Pitrou pitrou.net> writes: > > > Not necessarily, but OTOH, it is not really standard procedure to > > commit half-finished patches. > > I didn't want to miss the window for the upcoming alpha, and and I'm not sure > exactly how things will pan out with respect to PEP 397 and packaging. If > people > generally feel strongly about this, I can delete the .exe and re-introduce it > later if/when appropriate. It might have had a few rough edges, but I wouldn't > have characterised the patch as "half-finished" - that seems a little harsh > :-) Yes, I shouldn't have said that. "Unfinished" is more appropriate. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (Python Virtual Environments) and Windows script support
Comments welcome, especially on whether Windows users agree that something like this is needed in the absence of PEP 397 in Python 3.3. AFAICT, there is no need to check in the binary into revision control. Instead, the Windows build process should create, package, and deploy them, and venv should then just expect that they are there. So I request that this checkin is reverted, preferably before the alpha release. I also agree with the fundamental principle that an open source project should never ever include binaries for which it doesn't also provide source code. If you cannot release the sources right now, do not release the binaries either. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Missing command line documentation for new tools
The documentation does not currently provide end user guides for pysetup or pyvenv under http://docs.python.org/dev/using/index.html This needs to be fixed before 3.3 is released. I've created the following issues as deferred blockers (since they don't need to be addressed before the alpha this week): pysetup: http://bugs.python.org/issue14940 pyvenv: http://bugs.python.org/issue14939 As the standard library comes to include more directly executed tools, we really need to focus on keeping the Setup & Usage docs up to date. The fact we've been historically lax on that front is no excuse for perpetuating the problem for new additions. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (Python Virtual Environments) and Windows script support
On Tue, May 29, 2012 at 5:37 AM, Vinay Sajip wrote: > Antoine Pitrou pitrou.net> writes: > >> Regardless of what the executable is or does, its source code must be >> included somewhere in the Python source tree (and, preferably, there >> should be a simple procedure to build the binaries). > > I understand that. Does it need to be checked in right now? It will need > integrating with the existing VS2010 solution file, and at the moment I cannot > do that integration because I haven't yet got a full VS2010 build environment, > just a VS2008 one. It would have been better if the issue of script management on Windows had been raised in PEP 405 itself - I likely would have declared PEP 397 a dependency *before* accepting it (even if that meant the feature missed the alpha 4 deadline and first appeared in beta 1, or potentially even missed 3.3 altogether). However, I'm not going to withdraw the acceptance of the PEP over this - while I would have made a different decision at the time given the additional information (due to the general preference to treat Windows as a first class deployment target), I think reversing my decision now would make the situation worse rather than better. That means the important question is what needs to happen before beta 1 at the end of June. As I see it, we have two ways forward: 1. My preferred option: bring PEP 397 up to scratch as a specification for the behaviour of the Python launcher (perhaps with Vinay stepping up as a co-author to help Mark if need be), find a BDFL delegate (MvL? Brian Curtin?) and submit that PEP for acceptance within the next few weeks. The updated PEP 397 should include an explanation of exactly how it will help with the correct implementation of PEP 405 on Windows (this may involve making the launcher pyvenv aware). 2. The fallback option: remove the currently checked in build artifacts from source control and incorporate them into the normal Windows build processes (both the main VS 2010 process, and at least the now-legacy VS 2008 process) For alpha 4, I suggest going with MvL's suggestion - drop the binaries from Mercurial and accept that this aspect of PEP 405 simply won't work on Windows until the first beta. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (Python Virtual Environments) and Windows script support
Vinay originally wrote: PEP 397 (Python launcher for Windows) has not yet been accepted, so there still needs to be some way of natively launching scripts in Windows which is equivalent to /path/to/venv/bin/foo. The way setuptools (and hence Distribute) does this is to shadow each script with an executable: whereas a script foo would be simply placed in /path/to/venv/bin/ on POSIX, on Windows, the files foo.exe and foo-script.py (or foo-script.pyw) are placed in \path\to\venv\Scripts. The user can run \path\to\venv\Scripts\foo just as on POSIX. The foo.exe file is just a copy of a stock launcher executable which finds its name from the C argv[0], and based in that name (foo in this case), invokes foo-script.py or foo-script.pyw with the appropriate Python interpreter. I don't understand the relationship between this "stock launcher" and the PEP 397 launcher. They seem to have quite distinct requirements without much overlap. Specifically, I'm not aware that the current PEP 397 implementation could perform the same role as the "stock launcher" - IIUC, it has no special handling of the "-script" suffix or special logic based around its argv[0]. So unless I'm mistaken, even with PEP 397 accepted, either this "stock launcher" is still necessary anyway or the PEP398 launcher would need the addition of new features so it could replace the stock launcher. FWIW, Vinay and I exchanged some private mail recently about how to best integrate the PEP397 launcher with virtualenvs - and while we both agreed it would be nice, we couldn't come up with anything worthwhile. Having the launcher be aware of a virtualenv when invoked via file associations is problematic - for example, Windows Explorer is unlikely to have a virtualenv configured in its environment. Even when considering just command-line usage there are some edge-cases that make things problematic (eg, what if a script in a venv nominates a specific Python version via a shebang line? What if a venv is activated but the user/launcher attempts to execute a script outside the venv? etc.) On 29/05/2012 9:24 AM, Nick Coghlan wrote: ... It would have been better if the issue of script management on Windows had been raised in PEP 405 itself - I likely would have declared PEP 397 a dependency *before* accepting it (even if that meant the feature missed the alpha 4 deadline and first appeared in beta 1, or potentially even missed 3.3 altogether). However, I'm not going to withdraw the acceptance of the PEP over this - while I would have made a different decision at the time given the additional information (due to the general preference to treat Windows as a first class deployment target), I think reversing my decision now would make the situation worse rather than better. That means the important question is what needs to happen before beta 1 at the end of June. As I see it, we have two ways forward: 1. My preferred option: bring PEP 397 up to scratch as a specification for the behaviour of the Python launcher (perhaps with Vinay stepping up as a co-author to help Mark if need be), find a BDFL delegate (MvL? Brian Curtin?) and submit that PEP for acceptance within the next few weeks. The updated PEP 397 should include an explanation of exactly how it will help with the correct implementation of PEP 405 on Windows (this may involve making the launcher pyvenv aware). As above, it isn't clear to me how the additional complexity and list of caveats in real use make it worthwhile to have the PEP397 launcher pyvenv aware. 2. The fallback option: remove the currently checked in build artifacts from source control and incorporate them into the normal Windows build processes (both the main VS 2010 process, and at least the now-legacy VS 2008 process) For alpha 4, I suggest going with MvL's suggestion - drop the binaries from Mercurial and accept that this aspect of PEP 405 simply won't work on Windows until the first beta. Agreed - ISTM that this stock launcher is probably going to need to co-exist with the PEP397 launcher for the long term. Cheers, Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (Python Virtual Environments) and Windows script support
On 05/28/2012 04:24 PM, Nick Coghlan wrote: > It would have been better if the issue of script management on Windows > had been raised in PEP 405 itself - I likely would have declared PEP > 397 a dependency *before* accepting it (even if that meant the feature > missed the alpha 4 deadline and first appeared in beta 1, or > potentially even missed 3.3 altogether). > > However, I'm not going to withdraw the acceptance of the PEP over this > - while I would have made a different decision at the time given the > additional information (due to the general preference to treat Windows > as a first class deployment target), I think reversing my decision now > would make the situation worse rather than better. I think it's unfortunate that this issue (which is http://bugs.python.org/issue12394) has become entangled with PEP 405 at all, since AFAICT it is entirely orthogonal. This is a distutils2/packaging issue regarding how scripts are installed on Windows. It happens to be relevant when trying to install things into a PEP 405 venv on Windows, but it applies to a non-virtual Python installation on Windows every bit as much as it applies to a PEP 405 environment. In an earlier discussion with Vinay I thought we had agreed that it was an orthogonal issue and that this proposed patch for it would be removed from the PEP 405 reference implementation before it was merged to CPython trunk; I think that would have been preferable. This is why there is no mention of the issue in PEP 405 - it doesn't belong there, because it is not related. > That means the important question is what needs to happen before beta > 1 at the end of June. As I see it, we have two ways forward: > > 1. My preferred option: bring PEP 397 up to scratch as a specification > for the behaviour of the Python launcher (perhaps with Vinay stepping > up as a co-author to help Mark if need be), find a BDFL delegate (MvL? > Brian Curtin?) and submit that PEP for acceptance within the next few > weeks. The updated PEP 397 should include an explanation of exactly > how it will help with the correct implementation of PEP 405 on Windows > (this may involve making the launcher pyvenv aware). > > 2. The fallback option: remove the currently checked in build > artifacts from source control and incorporate them into the normal > Windows build processes (both the main VS 2010 process, and at least > the now-legacy VS 2008 process) > > For alpha 4, I suggest going with MvL's suggestion - drop the binaries > from Mercurial and accept that this aspect of PEP 405 simply won't > work on Windows until the first beta. Regardless, these sound like the right options moving forward, with the clarification that it is not any "aspect of PEP 405" that will not work until a fix is merged, it is simply an existing limitation of distutils2/packaging on Windows. And that if anything needs to be reverted, temporarily or permanently, it should not be all of the PEP 405 implementation, rather just this packaging fix. Carl signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (Python Virtual Environments) and Windows script support
On Tue, May 29, 2012 at 10:07 AM, Carl Meyer wrote: > On 05/28/2012 04:24 PM, Nick Coghlan wrote: >> It would have been better if the issue of script management on Windows >> had been raised in PEP 405 itself - I likely would have declared PEP >> 397 a dependency *before* accepting it (even if that meant the feature >> missed the alpha 4 deadline and first appeared in beta 1, or >> potentially even missed 3.3 altogether). >> >> However, I'm not going to withdraw the acceptance of the PEP over this >> - while I would have made a different decision at the time given the >> additional information (due to the general preference to treat Windows >> as a first class deployment target), I think reversing my decision now >> would make the situation worse rather than better. > > I think it's unfortunate that this issue (which is > http://bugs.python.org/issue12394) has become entangled with PEP 405 at > all, since AFAICT it is entirely orthogonal. This is a > distutils2/packaging issue regarding how scripts are installed on > Windows. It happens to be relevant when trying to install things into a > PEP 405 venv on Windows, but it applies to a non-virtual Python > installation on Windows every bit as much as it applies to a PEP 405 > environment. In an earlier discussion with Vinay I thought we had agreed > that it was an orthogonal issue and that this proposed patch for it > would be removed from the PEP 405 reference implementation before it was > merged to CPython trunk; I think that would have been preferable. > > This is why there is no mention of the issue in PEP 405 - it doesn't > belong there, because it is not related. Ah, thanks for the clarification. In that case: Vinay, please revert everything from the pyvenv commit that was actually related to issue #12394 rather than being part of the PEP 405 implementation. As Carl says, it's an unrelated change that needs to be discussed separately. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.2): Issue12510: Attempting to get invalid tooltip no longer closes Idle.
On 5/28/2012 2:53 AM, Georg Brandl wrote: Am 28.05.2012 03:55, schrieb terry.reedy: namespace.update(__main__.__dict__) try: return eval(name, namespace) -except (NameError, AttributeError): +# any exception is possible if evalfuncs True in open_calltip +# at least Syntax, Name, Attribute, Index, and Key E. if not Is something missing here? The comment text seems cut off. There should be a ; at the end of the first line, but I think I will rewrite the comment instead. +except: return None "except Exception" may be better here. Idle's Shell catches all exceptions. I think the attempt to provide an optional help (a function signature) should too. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.2): Issue12510: Attempting to get invalid tooltip no longer closes Idle.
On Mon, May 28, 2012 at 8:44 PM, Terry Reedy wrote: >>> + except: >>> return None >> >> >> "except Exception" may be better here. > > > Idle's Shell catches all exceptions. I think the attempt to provide an > optional help (a function signature) should too. Can you explain what this means? You should probably not have a bare except - I'm not sure what IDLE has to do with it. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue 14814: Add namespaces keyword arg to find(*) methods in _elementtree.
On Tue, May 29, 2012 at 1:03 PM, eli.bendersky wrote: > http://hg.python.org/cpython/rev/7d252dbfbee3 > changeset: 77217:7d252dbfbee3 > user: Eli Bendersky > date: Tue May 29 06:02:56 2012 +0300 > summary: > Issue 14814: Add namespaces keyword arg to find(*) methods in _elementtree. > Add attrib keyword to Element and SubElement in _elementtree. > Patch developed with Ezio Melotti. I'm not sure which issue you intended to reference here, but I'm fairly sure the PEP 3144 integration issue wasn't it :) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Missing command line documentation for new tools
On 5/28/2012 10:31 PM, Nick Coghlan wrote: Given an exchange on the tracker, I feel I should expand on this point. Historically, our Setup& Usage documentation has *only* covered the main Python executable, even though we actually install additional tools, including pydoc, idle, 2to3 and now pysetup and pyvenv, and provide additional documented and supported command line functionality via command line execution of certain modules. It is my view that this lack of centralised command line usage documentation is an *oversight*, not a deliberate policy that should be continued (hence the two new blocking issues for 3.3 as noted in my previous post). I've now created two more (lower priority) issues to cover the other officially supported command line interfaces that are currently missing from the setup& usage documentation: Existing scripts (pydoc, idle, 2to3): http://bugs.python.org/issue14944 I added a preliminary, rough outline for idle to the issue. Supported -m commands: http://bugs.python.org/issue14945 -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (Python Virtual Environments) and Windows script support
Am 29.05.2012 01:15, schrieb [email protected]: >> Comments welcome, especially on whether Windows users agree that >> something like this is needed in the absence of PEP 397 in Python 3.3. > > AFAICT, there is no need to check in the binary into revision control. > Instead, the Windows build process should create, package, and deploy > them, and venv should then just expect that they are there. > > So I request that this checkin is reverted, preferably before the alpha > release. > > I also agree with the fundamental principle that an open source project > should never ever include binaries for which it doesn't also provide > source code. If you cannot release the sources right now, do not release > the binaries either. Agreed. Vinay, please either let me know when this is rectified (see also Nick's request about reverting #12394 specific parts of the commit), or revert the whole PEP 405 implementation for now, if the time is too short: I don't want to delay the alpha much longer. There is still time until beta after all. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Missing command line documentation for new tools
On Tue, May 29, 2012 at 9:20 AM, Nick Coghlan wrote: > As the standard library comes to include more directly executed tools, > we really need to focus on keeping the Setup & Usage docs up to date. > The fact we've been historically lax on that front is no excuse for > perpetuating the problem for new additions. Given an exchange on the tracker, I feel I should expand on this point. Historically, our Setup & Usage documentation has *only* covered the main Python executable, even though we actually install additional tools, including pydoc, idle, 2to3 and now pysetup and pyvenv, and provide additional documented and supported command line functionality via command line execution of certain modules. It is my view that this lack of centralised command line usage documentation is an *oversight*, not a deliberate policy that should be continued (hence the two new blocking issues for 3.3 as noted in my previous post). I've now created two more (lower priority) issues to cover the other officially supported command line interfaces that are currently missing from the setup & usage documentation: Existing scripts (pydoc, idle, 2to3): http://bugs.python.org/issue14944 Supported -m commands: http://bugs.python.org/issue14945 Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Missing command line documentation for new tools
Le 28/05/2012 22:31, Nick Coghlan a écrit : > Historically, our Setup & Usage documentation has *only* covered the > main Python executable, even though we actually install additional > tools, including pydoc, idle, 2to3 and now pysetup and pyvenv, and > provide additional documented and supported command line functionality > via command line execution of certain modules. > > It is my view that this lack of centralised command line usage > documentation is an *oversight*, not a deliberate policy that should > be continued (hence the two new blocking issues for 3.3 as noted in my > previous post). This makes sense. Let’s expand the Setup and Usage docs! Cheers ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: simplify and rewrite the zipimport part of 702009f3c0b1 a bit
On Sat, May 26, 2012 at 2:07 AM, Larry Hastings wrote: > > On 05/25/2012 10:14 AM, Antoine Pitrou wrote: > > On Fri, 25 May 2012 18:57:57 +0200 > Georg Brandl wrote: > > This is probably minor, but wouldn't it make more sense to have those > constants uppercased? At least that's the general style we have in > the codebase for enum values. > > +1, this surprised me too. > > > FWIW I contributed the utime enum with the lowercase values. I don't > uppercase enum values as a rule. > > Uppercasing preprocessor macros is a good idea because they're not safe. > There are loads of ways they can produce unexpected behavior. So if > something funny is going on, and the code involves some preprocessor > slight-of-hand, those identifiers pop out at you and you know to > double-check them. But enum values are as safe as houses. I think of them > as equivalent to const ints, which I also don't uppercase. There's no need > to draw attention to them. > > There's nothing in PEP 7 either way about enum nomenclature. But Benjamin > has already uppercased these (and some other) enums, so I suppose the > community has spoken. I think the convention is that constants are uppercased -- enums are definitely constants. It helps the reader quickly to see what is variable and what is constant in an expression -- when I see x == 42, I know which is which, but when I see x == y, I don't. If I see x == Y, I know. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.2): Issue12510: Attempting to get invalid tooltip no longer closes Idle.
On 5/28/2012 9:48 PM, Brian Curtin wrote: > On Mon, May 28, 2012 at 8:44 PM, Terry Reedy wrote: snipped context: return eval(user_entered_expression, namespace) +except: return None >>> >>> >>> "except Exception" may be better here. >> >> >> Idle's Shell catches all exceptions. I think the attempt to provide an >> optional help (a function signature) should too. > > Can you explain what this means? What what means? I am not sure what you are asking. The issue might help http://bugs.python.org/issue12510 > You should probably not have a bare except Idle code already has many of them Some perhaps should not be, but I cannot tell with my current level of understanding of how Idle works. Would you prefer 'except BaseException:' ? > I'm not sure what IDLE has to do with it. This is a patch to Idle. tjr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
