[Python-Dev] AUTO: Jon K Peck is out of the office (returning 10/27/2011)
I am out of the office until 10/27/2011. I am out of the office attending the IBM IOD conference. I will be back in the office on Friday, 10/28. My email responses will be delayed during that period. Note: This is an automated response to your message "Python-Dev Digest, Vol 99, Issue 45" sent on 10/23/11 4:00:03. This is the only notification you will receive while this person is away.___ 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 (2.7): Whoops, PyException_GetTraceback() is not documented on 2.7
On 10/23/11 20:54, petri.lehtinen wrote: > http://hg.python.org/cpython/rev/5c4781a237ef > changeset: 73073:5c4781a237ef > branch: 2.7 > parent: 73071:11da12600f5b > user:Petri Lehtinen > date:Sun Oct 23 21:52:10 2011 +0300 > summary: > Whoops, PyException_GetTraceback() is not documented on 2.7 If it exists there, why not document it instead? :) 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] Modules of plat-* directories
> Given the issues you are mentioning, and given they were never > reported in years before, it seems unlikely anybody is using these > files. > > +1 to remove them, as they don't seem documented either. -1. If they were broken, and somebody used them, a bug would be reported. That no bug is being reported means that they either work fine, or nobody uses them. In the former case, removing them will break somebody's code. In the latter case, nothing is gained by either keeping or removing them. So why remove them? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Modules of plat-* directories
> I don't understand why we kept modules of the plat-* directories (e.g. > Lib/plat-linux/CDROM.py). Because they are useful. There is no reasonable other way at getting at the information in the modules for a Python program that may need them. > These modules are not regenerated when Python is compiled, so I don't > understand how values can be correct. They must be correct. On a specific system, these constants are not just part of the API - they are part of the ABI. So a system vendor cannot just change their values. Once defined, they must stay fixed forever. That's why it's not necessary to regenerate the files. > For example, IN.INT_MAX is 2147483647, > whereas it should be 9223372036854775807 on my 64-bit Linux. These values > don't look reliable. In general, this system can't deal well with conditional defines. People using them will know that. > These modules contain non-working functions: > > def __STRING(x): return #x > > def __constant_le32_to_cpu(x): return ((__u32)(__le32)(x)) So what? The whole point of h2py is that it is automatically generated. If the output is bogus, users just won't use the fragments that are bogus. Other fragments work just fine, and can be used. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] memcmp performance
> I am still rooting for -fno-builtin-memcmp in both Python 2.7 and 3.3 ... > (after we put memcmp in unicode_compare) -1. We shouldn't do anything about this. Python has the tradition of not working around platform bugs, except if the work-arounds are necessary to make something work at all - i.e. in particular not for performance issues. If this is a serious problem, then platform vendors need to look into it (CPU vendor, compiler vendor, OS vendor). If they don't act, it's probably not a serious problem. In the specific case, I don't think it's a problem at all. It's not that memcmp is slow with the builtin version - it's just not as fast as it could be. Adding a compiler option would put a maintenance burden on Python - we already have way too many compiler options in configure.in, and there is no good procedure to ever take them out should they not be needed anymore. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Modules of plat-* directories
> -1. If they were broken, and somebody used them, a bug would be > reported. That no bug is being reported means that they either > work fine, or nobody uses them. > > In the former case, removing them will break somebody's code. > In the latter case, nothing is gained by either keeping or removing > them. > > So why remove them? Not worrying whether we should maintain these files or not would be a reason. Not worrying whether we should document them (or provide a better way to access these facilities) is another. Given the messages on the bug tracker issue, it seems that (almost) nobody uses them *and* they are buggy ;) 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] Modules of plat-* directories
>> So why remove them? > > Not worrying whether we should maintain these files or not would be a > reason. Not worrying whether we should document them (or provide a > better way to access these facilities) is another. Don't worry whether, I tell you :-) Yes, we maintain them, and no, we make no changes to them unless a user actually requests a change, and no, we don't need to document them. I think there is a section on undocumented modules somewhere; if you worry too much, just add them there. There is little point in documenting them, since what they contain will vary from system to system. People should read the manual of their operating system to find out what all the constants mean (or perhaps the source code of their operating system in case the constants are undocumented even by the system vendor - which many of them are). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP397 no command line options to python?
On 23/10/2011 12:27 AM, Paul Moore wrote: (Sorry, should have gone to the list...) On 22 October 2011 13:15, Vinay Sajip wrote: Nick Coghlan gmail.com> writes: As a simpler alternative, I suggest the launcher just gain a "--which" long option that displays the full path to the interpreter it found. So: C:\> py -2 --which C:\Python27\python.exe C:\> py -3 --which C:\Python32\python.exe No significant complexity in the launcher, and if you want to add additional arguments like -m, -c, or -i you can do it by running '--which' and switching to invoking that interpreter directly. Perhaps even simpler would be for the -h option to print the interpreter paths which would be returned for -2 and -3, on separate lines, even without the --which, e.g. Currently configured: -2: c:\Python27\python.exe -3: c:\Python32\python.exe --which is nice for people who can use Unix-style $() or Powershell& to directly execute the output as a command. & (py -3 --which) How about abusing the existing flags for this purpose - eg: % py -3? % py -2.7? etc. 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] PEP397 no command line options to python?
On Mon, Oct 24, 2011 at 8:15 AM, Mark Hammond wrote: > How about abusing the existing flags for this purpose - eg: > > % py -3? > % py -2.7? What does using the magic symbol offer over an explicit separate flag? 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] PEP397 no command line options to python?
On 24/10/2011 10:36 AM, Nick Coghlan wrote: On Mon, Oct 24, 2011 at 8:15 AM, Mark Hammond wrote: How about abusing the existing flags for this purpose - eg: % py -3? % py -2.7? What does using the magic symbol offer over an explicit separate flag? * The "magic" symbol is somewhat self-documenting - it implies a question. Using --which adds another special case that people would need to understand isn't passed to Python. IOW, I like that there is only 1 special option and that one special option can be expressed in the form of a question. * Simplicity - does "py -2.3 --which" work the same as "py --which -2.3"? If not, that's not at all intuitive. If so, it adds complexity to the launcher and the PEP text. * Extensibility - While I've resisted, I predict that due to popular demand, we will wind up supporting additional arguments which are passed directly to Python (eg, "py -2.3 -W scriptName"). If we did, how would we treat --which when it is specified with additional options? So to turn the question back around - why introduce a new special option when the existing single special option can be leveraged? Are we opening the door to further special options? I guess the key downside to this suggestion is that it doesn't allow you ask where the default Python is without using "-2?" (or maybe just -?) 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] PEP397 no command line options to python?
On Mon, Oct 24, 2011 at 10:00 AM, Mark Hammond wrote: > * The "magic" symbol is somewhat self-documenting - it implies a question. > Using --which adds another special case that people would need to > understand isn't passed to Python. IOW, I like that there is only 1 special > option and that one special option can be expressed in the form of a > question. This may be a difference in what we're used to. To me, the "-?" is strongly associated with "-h" and "--help", whereas "--which" maps directly to the *nix "which" command: $ which python /usr/bin/python As far as simplicity and extensibility go, I would treat "--which" the way most programs treat "--help" and "--version" - they can appear anywhere on the command line and completely change the expected output of the command: $ python -Ei --version -c "This is never evaluated" Python 2.7.1 So I don't actually see any particularly *new* design decisions to be made in relation to a "--which" option - it's just a workaround for the lack of a native 'which' equivalent on Windows, and it behaves like Python's own "--version" option. 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] PEP397 no command line options to python?
On 24/10/2011 11:46 AM, Nick Coghlan wrote: On Mon, Oct 24, 2011 at 10:00 AM, Mark Hammond wrote: * The "magic" symbol is somewhat self-documenting - it implies a question. Using --which adds another special case that people would need to understand isn't passed to Python. IOW, I like that there is only 1 special option and that one special option can be expressed in the form of a question. This may be a difference in what we're used to. To me, the "-?" is strongly associated with "-h" and "--help" Fair enough - and I admit to thinking -? didn't work for Python - but it does! , whereas "--which" maps directly to the *nix "which" command: Sure, but this isn't for *nix, so I'm not sure it is safe to assume the users of the launcher will make that association. So I don't actually see any particularly *new* design decisions to be made in relation to a "--which" option - it's just a workaround for the lack of a native 'which' equivalent on Windows, Actually I don't think that is true - even with a 'which' on Windows you can't get this information from it. Indeed, this functionality is quite distinct from that offered by which. TBH I'm not that bothered - I just have a slight uneasiness to this new special option which really just helps describe what a different special option does. So - in an effort to talk myself out of my idea... :) one advantage --which would have is that it could work without any version qualifiers at all - eg: % py --which path/to/script.py could also tell you what version of Python would be used to execute the named script, taking into account the current defaults, environment variables and shebang line found in the script. 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] PEP397 no command line options to python?
On Mon, Oct 24, 2011 at 11:15 AM, Mark Hammond wrote: >> So I don't actually see any particularly *new* design decisions to be >> made in relation to a "--which" option - it's just a workaround for >> the lack of a native 'which' equivalent on Windows, > > Actually I don't think that is true - even with a 'which' on Windows you > can't get this information from it. Indeed, this functionality is quite > distinct from that offered by which. True, that comparison was a bad one - the launcher takes into account more than just path entries the way the *nix equivalent does. Still, it's a tool in the same spirit, even if the mechanics differs. > TBH I'm not that bothered - I just have a slight uneasiness to this new > special option which really just helps describe what a different special > option does. > > So - in an effort to talk myself out of my idea... :) one advantage --which > would have is that it could work without any version qualifiers at all - eg: > > % py --which path/to/script.py > > could also tell you what version of Python would be used to execute the > named script, taking into account the current defaults, environment > variables and shebang line found in the script. I was actually just thinking of the simple "py --which" use case, but you're right, it could be extended to shebang line checking as well. 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] PEP397 no command line options to python?
On Sun, Oct 23, 2011 at 17:15, Mark Hammond wrote: > How about abusing the existing flags for this purpose - eg: > > % py -3? > % py -2.7? I would have expected that to launch an interactive python shell of the appropriate version. Does it do something else today? Michael ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP397 no command line options to python?
On 24/10/2011 12:56 PM, Michael Urman wrote: On Sun, Oct 23, 2011 at 17:15, Mark Hammond wrote: How about abusing the existing flags for this purpose - eg: % py -3? % py -2.7? I would have expected that to launch an interactive python shell of the appropriate version. Does it do something else today? That is what it does today without the trailing '?' character. My idea was to allow the trailing '?' to behave like the proposed --which. 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] PEP397 no command line options to python?
On Sun, Oct 23, 2011 at 20:58, Mark Hammond wrote: > On 24/10/2011 12:56 PM, Michael Urman wrote: >> >> On Sun, Oct 23, 2011 at 17:15, Mark Hammond >> wrote: >>> >>> How about abusing the existing flags for this purpose - eg: >>> >>> % py -3? >>> % py -2.7? >> >> I would have expected that to launch an interactive python shell of >> the appropriate version. Does it do something else today? > > That is what it does today without the trailing '?' character. My idea was > to allow the trailing '?' to behave like the proposed --which. Oh, I read right over question mark without seeing it. I wonder if that's a notch against it from a documentation standpoint or just my own personal quirk. (I'm not used to thinking of it as a command line flag, partly due to my unix years.) Thanks for explaining! ___ 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 (2.7): Whoops, PyException_GetTraceback() is not documented on 2.7
Georg Brandl wrote: > On 10/23/11 20:54, petri.lehtinen wrote: > > http://hg.python.org/cpython/rev/5c4781a237ef > > changeset: 73073:5c4781a237ef > > branch: 2.7 > > parent: 73071:11da12600f5b > > user:Petri Lehtinen > > date:Sun Oct 23 21:52:10 2011 +0300 > > summary: > > Whoops, PyException_GetTraceback() is not documented on 2.7 > > If it exists there, why not document it instead? :) Hmm, an interesting idea. I'll see what I can do :) Petri ___ 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 (2.7): Whoops, PyException_GetTraceback() is not documented on 2.7
Petri Lehtinen wrote: > Georg Brandl wrote: > > On 10/23/11 20:54, petri.lehtinen wrote: > > > http://hg.python.org/cpython/rev/5c4781a237ef > > > changeset: 73073:5c4781a237ef > > > branch: 2.7 > > > parent: 73071:11da12600f5b > > > user:Petri Lehtinen > > > date:Sun Oct 23 21:52:10 2011 +0300 > > > summary: > > > Whoops, PyException_GetTraceback() is not documented on 2.7 > > > > If it exists there, why not document it instead? :) > > Hmm, an interesting idea. I'll see what I can do :) It seems it doesn't exist on 2.7 after all. I just failed with my hg-fu and thought it was there. Petri ___ 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
