Re: [Python-Dev] Packaging and binary distributions for Python 3.3
Paul Moore gmail.com> writes:
> Interesting. That's not a use case that I have encountered, but I can
> see it could be an issue. I have been working on the basis that a
> bdist_simple format that matches the functionality of bdist_wininst is
> at least good enough for those projects that currently use
> bdist_wininst. The only potential issue right now is with postinstall
> scripts, which bdist_simple doesn't support. It would be easy enough
> to add, and indeed it may be possible to use existing packaging
> functionality already (I haven't looked into this area).
The packaging machinery contains a reasonably good set of hooks which a
setup.cfg can plug into, which is IMO more flexible than just a post-
installation script (e.g. sometimes you need your code to run before
installation, to determine where to install things).
> I don't disagree, but I'm struggling to see how that would be done.
See example below.
> Can you give an example of a setup.cfg, that would work like this?
> Suppose I have two files, foo.py and bar.pyd, which are a pure-python
> module and a compiled C extension. How would I write a setup.cfg and
> lay out the directory structure to allow pysetup install to do the
> right thing? I tried to do this myself, but couldn't get it to work
> the way I expected. It may be I was just hitting bugs, but it felt to
> me like I was going at the problem the wrong way.
It may not work for you, because in the default branch, packaging is currently
missing some functionality or has bugs (I've raised about a dozen issues since
trying to get packaging working with virtual environments).
In the pythonv branch (which is pretty up to date with default), I've added the
missing functionality/fixed some of the issues. Here's an example: I've created
an empty virtual environment. Here are the contents of it at the moment:
C:\TEMP\VENV
│ env.cfg
│
├───Include
├───Lib
│ └───site-packages
└───Scripts
activate.bat
deactivate.bat
pysetup3-script.py
pysetup3.exe
[various stock Python binaries omitted]
Here's an example setup.cfg:
[global]
setup_hooks = hooks.setup
[install_data]
pre-hook.win32 = hooks.pre_install_data
[metadata]
name = dory
version = 0.1
requires_python = >= 3.3
[other metadata omitted]
[files]
modules = dory
packages = apackage
apackage.asubpackage
scripts = dory
extra_files =
hooks.py
resources =
data/data.bin = {data}
compiled/ spam.pyd = {compiled}
#[extension: spam]
#language = c
#sources = spammodule.c
The extension section is commented out because we're not building the extension
at installation time. This setup.cfg works hand-in-hand with some hooks, in
file hooks.py below:
def setup(config):
# Can do various checks here. For example, platform
# compatibility checks, or set up different binaries
# to install for x86 vs. x64, etc.
# Do this by setting up config['files']['resources']
# appropriately based on installation time environment.
pass
def pre_install_data(cmd):
# assumes os.name == 'nt' for simplicity of this example
cmd.categories['compiled'] = '%s/Lib/site-packages' % cmd.install_dir
Notice how in setup.cfg, file 'spam.pyd' in 'compiled' is expected to be copied
to category 'compiled', whose path is set in hooks.pre_install_data.
Here's the project directory:
C:\USERS\VINAY\PROJECTS\DORY
│ dory
│ dory.py
│ hooks.py
│ setup.cfg
│
├───apackage
│ │ __init__.py
│ │
│ └───asubpackage
│ __init__.py
│
├───compiled
│ spam.pyd
│
└───data
data.bin
At the moment, the "spam" module is of course not installed:
(venv) c:\Users\Vinay\Projects\dory>python -c "import spam"
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named 'spam'
Now, we install the project:
(venv) c:\Users\Vinay\Projects\dory>pysetup3 install .
Installing from source directory: c:\Users\Vinay\Projects\dory
running install_dist
running build
running build_py
running build_scripts
copying and adjusting dory -> build\scripts-3.3
running install_lib
creating C:\temp\venv\Lib\site-packages\apackage
byte-compiling C:\temp\venv\Lib\site-packages\apackage\__init__.py to __init__.c
python-33.pyc
byte-compiling C:\temp\venv\Lib\site-packages\dory.py to dory.cpython-33.pyc
running install_scripts
running pre_hook hooks.pre_install_data for command install_data
running install_data
running install_distinfo
creating C:\temp\venv\Lib\site-packages\dory-0.1.dist-info
creating C:\temp\venv\Lib\site-packages\dory-0.1.dist-info\METADATA
creating C:\temp\venv\Lib\site-packages\dory-0.1.dist-info\INSTALLER
creating C:\temp\venv\Lib\site-packages\dory-0.1.dist-info\REQUESTED
creating C:\temp\venv\Lib\site-packages\dory-0.1.dist-info\RESOURCES
creating C:\temp\venv\Lib\site-packages\dory-0.1.dist-info\RECORD
Now, the virtualenv looks like this:
C:\TEMP\VENV
│ env.cfg
│
├───data
│ data.bin
│
├───Include
├───Lib
│ └───site-packages
│
[Python-Dev] PEP397 no command line options to python?
Hello all, I was surprised to see that the excellent pylauncher doesn't do the magic shebang processing if you give it any python command line options. e.g. Given #!/usr/bin/env python2.6 import sys print(sys.executable) C:\>py test.py C:\Python26\python.exe C:\>py -utt test.py C:\Python27\python.exe It is spelled out that it shouldn't do so in the pep : "Only the first command-line argument will be checked for a shebang line and only if that argument does not start with a '-'." But I can't really see why that should be the case. What is the rational behind this? It is very surprising to the user that adding a simple option like -tt should change the way the launcher behaves. The PEP also states that the launcher should show the python help if '-h' is specified : "If the only command-line argument is "-h" or "--help", the launcher will print a small banner and command-line usage, then pass the argument to the default Python. This will cause help for the launcher being printed followed by help for Python itself. The output from the launcher will clearly indicate the extended help information is coming from the launcher and not Python." To me that would suggest to end users that they can use any of the command line options with the launcher, and they should behave as if you had called python directly. I am directing this to python-dev because this pylauncher is merely implementing the PEP as it currently stands, so the PEP would ideally need to be modified before the launcher. I would change the that first paragraph of the PEP to read something like : " The first command-line argument not beginning with a '-' will be checked for a shebang line, but only if : * That command-line argument is not preceded by a '-c' or '-m', and providing * There is no explicit version specifier, e.g. -2.7 as documumented later in this PEP. " Incidentally whilst implementing this I also noticed a bug in the pylauncher whereby the py launcher would incorrectly treat "py t3" as a request for python version as if '-3' had been specified. I have a small patch that fixes this and implements the above for pylauncher with extra tests if there is interest. Sam PS I have been lurking for a while, hello everyone. ___ 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] Packaging and binary distributions for Python 3.3
On 17 October 2011 10:15, Vinay Sajip wrote: > It may not work for you, because in the default branch, packaging is currently > missing some functionality or has bugs (I've raised about a dozen issues since > trying to get packaging working with virtual environments). Ah. That might be part of the issue I've been having. I do recall hitting some bugs. The other part is that I wasn't trying anything nearly as sophisticated as this :-) > In the pythonv branch (which is pretty up to date with default), I've added > the > missing functionality/fixed some of the issues. Here's an example: [...] Nice! I see what you are getting at now. >> I'd like to see a bdist_xxx command to do the build step >> as you describe, if only to make it trivially simple for developers to >> produce binary distributions. Having to package stuff up manually is >> bound to put at least some developers off. If you can give me the >> example I mentioned above, I could work on modifying the bdist_simple >> code I posted to the tracker today to produce that format rather than >> my custom format based on bdist_wininst. > > Example as above, though you may need to use the pythonv branch to actually > get > it working. I can zip up the directory and send it to you, but at the moment > there's missing functionality in pythonv in terms of the link step when > building the extension. (I overcame this by linking manually .) If you want, I > can zip all the project files up and send them to you. No need, you've given me enough to investigate myself. But thanks for the offer. > In the more general case, one might want an arrangement with a directory > structure like compiled/x86/..., compiled/x64/... in the built zip, with the > hooks.py code setting up the resources appropriately based on the target > environment as determined at installation time. Correct me if I'm wrong, but if we standardised on a particular structure, the hooks.py contents could actually be integrated into the core, if we wanted? People could still write hooks for more complex cases, but the basic binary build case could work out of the box that way. >> Agreed. Personally, as I've said, I'm happy not to use Add/Remove even >> for system installations - pysetup list and pysetup remove do what I >> need without slowing down the Add/Remove list. But I accept that's not >> likely to be the view of many Windows users. Anyone using virtual >> envs, though, is probably by definition comfortable enough with >> command line tools to be willing to use pysetup3. > > A fair subset of those who must have ARP integration will probably also want > to > install using MSI, so that would be taken care of by having a good > bdist_simple > -> bdist_msi conversion. Yes, that would be good. 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] PEP397 no command line options to python?
On 17/10/2011 9:10 PM, Sam Partington wrote: Hello all, I was surprised to see that the excellent pylauncher doesn't do the magic shebang processing if you give it any python command line options. e.g. Given #!/usr/bin/env python2.6 import sys print(sys.executable) C:\>py test.py C:\Python26\python.exe C:\>py -utt test.py C:\Python27\python.exe It is spelled out that it shouldn't do so in the pep : "Only the first command-line argument will be checked for a shebang line and only if that argument does not start with a '-'." But I can't really see why that should be the case. What is the rational behind this? It really is a combination of 2 things: * The key use-case for the launcher is to be executed implicitly - ie, the user types just "foo.py". In that scenario there is no opportunity for the user to specify any args between the name of the executable and of the script. IOW, the expectation is that people will not type "py foo.py", but instead just type "foo.py". * A desire to avoid command-line parsing in the launcher or to make some options "more equal" then others. Eg, you mention later that -c and -m should be special, but what about -w or -Q? What about new options in future versions? It is very surprising to the user that adding a simple option like -tt should change the way the launcher behaves. The PEP also states that the launcher should show the python help if '-h' is specified : "If the only command-line argument is "-h" or "--help", the launcher will print a small banner and command-line usage, then pass the argument to the default Python. This will cause help for the launcher being printed followed by help for Python itself. The output from the launcher will clearly indicate the extended help information is coming from the launcher and not Python." To me that would suggest to end users that they can use any of the command line options with the launcher, and they should behave as if you had called python directly. I think the language is fairly clear - only the help options are special and no other options will work. ... Incidentally whilst implementing this I also noticed a bug in the pylauncher whereby the py launcher would incorrectly treat "py t3" as a request for python version as if '-3' had been specified. I have a small patch that fixes this and implements the above for pylauncher with extra tests if there is interest. That certainly sounds like a bug and a patch sent to https://bitbucket.org/vinay.sajip/pylauncher will be appreciated! PS I have been lurking for a while, hello everyone. Hi and cheers! :) 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] PEP397 no command line options to python?
On 17 October 2011 13:23, Mark Hammond wrote: > On 17/10/2011 9:10 PM, Sam Partington wrote: >> >> "Only the first command-line argument will be checked for a shebang line >> and only if that argument does not start with a '-'." >> >> But I can't really see why that should be the case. What is the >> rational behind this? > > It really is a combination of 2 things: > > * The key use-case for the launcher is to be executed implicitly - ie, the > user types just "foo.py". In that scenario there is no opportunity for the > user to specify any args between the name of the executable and of the > script. IOW, the expectation is that people will not type "py foo.py", but > instead just type "foo.py". That sounds like an explanation of why it hasn't been implemented before, not an explanation of why it should continue that way. In any case, I think that expectation is not complete. In my case it was my editor that inserted the '-u' on my behalf. Or why might I not set the default action for .py files to be "py -tt %1", or "py -3 %1". Why deny any of the arguments to a pylauncher user? > * A desire to avoid command-line parsing in the launcher or to make some > options "more equal" then others. Eg, you mention later that -c and -m > should be special, but what about -w or -Q? What about new options in > future versions? Yes it is a bit annoying to have to treat those specially, but other than -c/-m it does not need to understand pythons args, just check that the arg is not an explicit version specifier. -q/-Q etc have no impact on how to treat the file. In fact there's no real need to treat -c differently as it's extremely unlikely that there is a file that might match. But for -m you can come up with a situation where if you it gets it wrong. e.g. 'module' and 'module.py' in the cwd. I would suggest that it is also unlikely that there will be any future options would need any special consideration. >> It is very surprising to the user that adding a >> simple option like -tt should change the way the launcher behaves. >> The PEP also states that the launcher should show the python help if >> '-h' is specified : >> >> "If the only command-line argument is "-h" or "--help", the launcher >> will >> print a small banner and command-line usage, then pass the argument to >> the default Python. This will cause help for the launcher being >> printed >> followed by help for Python itself. The output from the launcher will >> clearly indicate the extended help information is coming from the >> launcher and not Python." >> >> To me that would suggest to end users that they can use any of the >> command line options with the launcher, and they should behave as if >> you had called python directly. > > I think the language is fairly clear - only the help options are special and > no other options will work. The PEP is clear yes, but the the help output for the launcher displays all of the python switches, so I expected them to be available in the a py.exe call. >> Incidentally whilst implementing this I also noticed a bug in the >> pylauncher whereby the py launcher would incorrectly treat "py t3" as >> a request for python version as if '-3' had been specified. I have a >> small patch that fixes this and implements the above for pylauncher >> with extra tests if there is interest. > > That certainly sounds like a bug and a patch sent to > https://bitbucket.org/vinay.sajip/pylauncher will be appreciated! The patch does both the bug fix and the arg skipping at present, but I'll happily separate them if needs be. Sam ___ 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] Fwd: Issue with the link to python modules documentation
Hey folks, The title of the "Global Module Index" for 3.2 documentation is "Python 3.1.3 documentation". http://docs.python.org/py3k/modindex.html See the report below (attached screenshot removed). All the best, Michael Foord Original Message Subject:Issue with the link to python modules documentation Date: Sun, 16 Oct 2011 22:44:52 +0200 From: Carl Chenet Reply-To: cha...@ohmytux.com To: webmas...@python.org Hi, Browsing http://www.python.org/doc/ , I click on the link to Python 3.x Module Index linking to http://docs.python.org/3.2/modindex.html and I'm redirected to http://docs.python.org/py3k/modindex.html to the Python module list documentation but for the version 3.1.3. I'm using Chromium 12. I tried several times and cleared the cache before retrying but the issue remains. I'm joining a screenshot showing the finale page with the url http://docs.python.org/py3k/modindex.html which should be the Python Module list for current 3.x version, which is I guess 3.2. Bye, Carl Chenet ___ 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] Packaging and binary distributions for Python 3.3
Paul Moore gmail.com> writes: > Correct me if I'm wrong, but if we standardised on a particular > structure, the hooks.py contents could actually be integrated into the > core, if we wanted? People could still write hooks for more complex > cases, but the basic binary build case could work out of the box that > way. Well, the hooks.py is there to allow user-defined setups which are outside the scope of what should be provided in the stdlib - for instance, my earlier example about PowerShell scripts is IMO out-of-scope for the stdlib itself, but perfectly fine for the documentation, say in a set of example recipes in a packaging HOWTO. The hooks aren't needed at all for conventional deployments - only when you need something out of the ordinary. We could certainly extend the setup.cfg scheme to have specific support for pre-compiled binaries, which are currently "out of the ordinary" (which of course is why this thread is here :-)). Life could be made easier for distribution authors by initially having well documented examples or recipes, and later, if the ubiquity of certain patterns is established, better support might be provided in the stdlib for those patterns. But there are other changes we could make now - for example, the list of categories does not include a library location (necessitating my use of a "compiled" category), but perhaps a "lib" category could be built in now. 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] PEP397 no command line options to python?
Sam Partington gmail.com> writes: > That sounds like an explanation of why it hasn't been implemented > before, not an explanation of why it should continue that way. From a desire to keep the launcher as simple as possible, and to minimise the need to synchronise the launcher with command line parameter changes in future versions of Python. > In any case, I think that expectation is not complete. In my case it > was my editor that inserted the '-u' on my behalf. > > Or why might I not set the default action for .py files to be "py -tt > %1", or "py -3 %1". > > Why deny any of the arguments to a pylauncher user? Don't forget that customised commands allow Python to be invoked from shebang lines with fair flexibility. > >> Incidentally whilst implementing this I also noticed a bug in the > >> pylauncher whereby the py launcher would incorrectly treat "py t3" as > >> a request for python version as if '-3' had been specified. I have a > >> small patch that fixes this and implements the above for pylauncher > >> with extra tests if there is interest. > > > > That certainly sounds like a bug and a patch sent to > > https://bitbucket.org/vinay.sajip/pylauncher will be appreciated! > > The patch does both the bug fix and the arg skipping at present, but > I'll happily separate them if needs be. Don't worry about separating them for now, assuming that it's fairly easy to figure out which bit is which :-) Thanks & 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] PEP397 no command line options to python?
On Mon, Oct 17, 2011 at 8:55 AM, Sam Partington wrote: > Yes it is a bit annoying to have to treat those specially, but other > than -c/-m it does not need to understand pythons args, just check > that the arg is not an explicit version specifier. -q/-Q etc have no > impact on how to treat the file. > > In fact there's no real need to treat -c differently as it's extremely > unlikely that there is a file that might match. But for -m you can > come up with a situation where if you it gets it wrong. e.g. 'module' > and 'module.py' in the cwd. > > I would suggest that it is also unlikely that there will be any future > options would need any special consideration. > What about -S (no site.py) and -E (no environment)? These are needed for secure setuid scripts on *nix; I don't know how often they'd be used in practice on Windows. (Basically, they let you isolate a script's effective sys.path; there may be some use case overlap with virtual envs. ___ 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] Packaging and binary distributions for Python 3.3
> Hmm, clicking the link in the email works here. but just to be safe: > > http://goo.gl/pC48e > Thanks - looks nice! What is the license which applies to the code? Is it available in a public repository? 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] Fwd: Issue with the link to python modules documentation
On 10/17/2011 9:16 AM, Michael Foord wrote: Hey folks, The title of the "Global Module Index" for 3.2 documentation is "Python 3.1.3 documentation". http://docs.python.org/py3k/modindex.html Verified. Clicking [index] in upper right goes to http://docs.python.org/py3k/genindex.html 3.2.2 version. -- Terry Jan Reedy ___ 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] Fwd: Issue with the link to python modules documentation
It's just an outdated link; fixed now. Georg Am 17.10.2011 15:16, schrieb Michael Foord: > Hey folks, > > The title of the "Global Module Index" for 3.2 documentation is "Python 3.1.3 > documentation". > > http://docs.python.org/py3k/modindex.html > > See the report below (attached screenshot removed). > > All the best, > > Michael Foord > > Original Message > Subject: Issue with the link to python modules documentation > Date: Sun, 16 Oct 2011 22:44:52 +0200 > From: Carl Chenet > Reply-To: cha...@ohmytux.com > To: webmas...@python.org > > > > Hi, > > Browsing http://www.python.org/doc/ , I click on the link to Python 3.x > Module Index linking to http://docs.python.org/3.2/modindex.html and I'm > redirected to http://docs.python.org/py3k/modindex.html to the Python > module list documentation but for the version 3.1.3. > > I'm using Chromium 12. I tried several times and cleared the cache > before retrying but the issue remains. > > I'm joining a screenshot showing the finale page with the url > http://docs.python.org/py3k/modindex.html which should be the Python > Module list for current 3.x version, which is I guess 3.2. > > Bye, > Carl Chenet > > > > ___ 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] Modules of plat-* directories
On Mon, 17 Oct 2011 02:04:38 +0200 Victor Stinner wrote: > Le lundi 17 octobre 2011 01:16:36, Victor Stinner a écrit : > > For example, IN.INT_MAX is 2147483647, whereas it should > > be 9223372036854775807 on my 64-bit Linux. > > Oops, wrong example: INT_MAX is also 2147483647 on 64 bits. I mean > IN.LONG_MAX. > > IN.LONG_MAX is always 9223372036854775807 on Linux, on 32 and 64 bits systems. 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. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP397 no command line options to python?
On 17 October 2011 17:24, PJ Eby wrote: > What about -S (no site.py) and -E (no environment)? These are needed for > secure setuid scripts on *nix; I don't know how often they'd be used in > practice on Windows. (Basically, they let you isolate a script's effective > sys.path; there may be some use case overlap with virtual envs. At the moment py -S test.py would mean that test.py would not be scanned for a shebang, and would be executed with the latest python. The change that I am suggesting would mean that it would be scanned for a shebang to select the python, and then that python would be called with -S. Do you think it would be necessary to have -S disable reading of the .ini files (in the users application data dir and in \windows)? Sam PS Sorry, I initially replied off-list by accident. ___ 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] PEP397 no command line options to python?
On 18/10/2011 3:24 AM, PJ Eby wrote: On Mon, Oct 17, 2011 at 8:55 AM, Sam Partington mailto:sam.parting...@gmail.com>> wrote: Yes it is a bit annoying to have to treat those specially, but other than -c/-m it does not need to understand pythons args, just check that the arg is not an explicit version specifier. -q/-Q etc have no impact on how to treat the file. In fact there's no real need to treat -c differently as it's extremely unlikely that there is a file that might match. But for -m you can come up with a situation where if you it gets it wrong. e.g. 'module' and 'module.py' in the cwd. I would suggest that it is also unlikely that there will be any future options would need any special consideration. What about -S (no site.py) and -E (no environment)? These are needed for secure setuid scripts on *nix; I don't know how often they'd be used in practice on Windows. (Basically, they let you isolate a script's effective sys.path; there may be some use case overlap with virtual envs. It is worth pointing out that options can be specified directly in the shebang line - eg, a line like "#! /usr/bin/python -S" in a foo.py works as expected. What doesn't work is explicitly using a command like: % py -E foo.py Using the foo.py above as an example, that would need to result in spawning Python with both -E and -S options. For my money, that doesn't seem worthwhile - eg, someone else may have the expectation that specifying the args to py.exe should override the args on the shebang line. Then someone else will have different expectations about the specific order of the args that should be used (eg, compare using "python -m somemodule -v" versus "python -v -m somemodule". etc. For these reasons I'm still advocating we don't support such command-lines, but as usual I'll go with the consensus :) Cheers, 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] Modules of plat-* directories
Le lundi 17 octobre 2011 23:27:09, Antoine Pitrou a écrit : > On Mon, 17 Oct 2011 02:04:38 +0200 > > Victor Stinner wrote: > > Le lundi 17 octobre 2011 01:16:36, Victor Stinner a écrit : > > > For example, IN.INT_MAX is 2147483647, whereas it should > > > be 9223372036854775807 on my 64-bit Linux. > > > > Oops, wrong example: INT_MAX is also 2147483647 on 64 bits. I mean > > IN.LONG_MAX. > > > > IN.LONG_MAX is always 9223372036854775807 on Linux, on 32 and 64 bits > > systems. > > 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. Oh, there are other (new?) problems listed in last comments of the issue #12619. The Mac OS X issue is funny. Extracts: "What do you do for platforms like OS X where we support one set of binary files that contain multi-architecture C-files that can run as Intel-64, Intel-32 or PPC-32 on the same machine at user option at run time? (...) The static IN.py currently shipped in plat-darwin is misleading at best." "-1 on auto-building. The header needed may not be available on the build platform, (...)" "There is no reason to keep plat-xxx files if cannot be managed properly." 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] PEP397 no command line options to python?
On Mon, Oct 17, 2011 at 8:00 PM, Mark Hammond wrote: > On 18/10/2011 3:24 AM, PJ Eby wrote: > >> What about -S (no site.py) and -E (no environment)? These are needed >> for secure setuid scripts on *nix; I don't know how often they'd be used >> in practice on Windows. (Basically, they let you isolate a script's >> effective sys.path; there may be some use case overlap with virtual envs. >> > > It is worth pointing out that options can be specified directly in the > shebang line - eg, a line like "#! /usr/bin/python -S" in a foo.py works as > expected. Ah, ok. Never mind, then. ___ 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] PEP397 no command line options to python?
On 17 October 2011 15:20, Vinay Sajip wrote: > Sam Partington gmail.com> writes: > >> That sounds like an explanation of why it hasn't been implemented >> before, not an explanation of why it should continue that way. > > From a desire to keep the launcher as simple as possible, and to minimise the > need to synchronise the launcher with command line parameter changes in future > versions of Python. As simple as possible yes... but no simpler. I think having pylauncher behave so differently in the two cases of : py -u test.py py test.py Is very unexpected. And to do so silently, without warning will cause real headaches_ for users, *especially* since py -h lists -u as one of the options, it does not say 'here are the python options but you must call PythonXX/python.exe to use them'. [headaches : it did for me as I ended up with a broken build of my app due to different parts of my app built for different pythons.] To fix this the launcher doesn't need to track all python command line options, only those that take two args. I don't really see that it will be such a maintenance burden to have the launcher track any new ones. Python has only two such options after 20 years of development. As for complexity it's less than 10 lines of C. >> In any case, I think that expectation is not complete. In my case it >> was my editor that inserted the '-u' on my behalf. >> >> Or why might I not set the default action for .py files to be "py -tt >> %1", or "py -3 %1". >> >> Why deny any of the arguments to a pylauncher user? > > Don't forget that customised commands allow Python to be invoked from shebang > lines with fair flexibility. That's a cool feature which I'd not really read up on, but that requires a global configuration file change, it's not doable on a per usage basis. > Don't worry about separating them for now, assuming that it's fairly easy to > figure out which bit is which :-) It wasn't hard to do and I see you've applied the patch already, thanks for the fast turn around! Sam PS Sorry, I replied off-list again! ___ 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
