Re: [Python-Dev] #! magic
-On [20080120 23:36], Oleg Broytmann ([EMAIL PROTECTED]) wrote: PS. My python doesn't understand -s, so I tested a different options, but the result is the same. There are Unix variants that understand many options (I believe FreeBSD allows them) but most allow no more than one parameter in #!. FreeBSD 6.3-STABLE: % ./test.py Unknown option: - usage: /usr/local/bin/python [option] ... [-c cmd | -m mod | file | -] [arg] ... Try `python -h' for more information. Contracting to -Es works, aside from -s being unknown to my Python. And also, /usr/bin won't work, FreeBSD uses /usr/local/bin since Python is installed through ports and is not a system binary. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ Every revolution was first a thought in one man's mind... ___ 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] #! magic
-On [20080120 18:38], Oleg Broytmann ([EMAIL PROTECTED]) wrote: A shell has nothing to do with it as it is the OS (exec system call) that upon reading the magic of the file sees #! and executes the program (up to the first space) and pass to the program the first (and the only) parameter. Yes, you are right. *sigh* It's been too long since I dug around the kernel on a daily basis. I had totally forgotten about imgact_shell.c's parsing of the hashbang. As execve(2) documents on FreeBSD: An interpreter file begins with a line of the form: #! interpreter [arg] When an interpreter file is execve'd, the system actually execve's the specified interpreter. If the optional arg is specified, it becomes the first argument to the interpreter, and the name of the originally execve'd file becomes the second argument; otherwise, the name of the originally execve'd file becomes the first argument. The original argu- ments are shifted over to become the subsequent arguments. The zeroth argument is set to the specified interpreter. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ The greatness of a nation and its moral progress can be judged by the way its animals are treated. ___ 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: per user site-packages directory
-On [20080120 19:34], Christian Heimes ([EMAIL PROTECTED]) wrote: Most Python developers should the meaning of ~. Should I replace ~ with $HOME for those who don't have as much experience with Unix as we? The problem is that ~ is an expansion character. It expands the contents of $HOME. If HOME is set to /usr/local, using ~ will expand to /usr/local. This behaviour is undefined by POSIX, if HOME is null/empty than expanding ~ is undefined. If it is just ~ then it will expand to the contents of HOME, if ~ is followed by a string then it will do a getpwnam() call on the string and expand that to the initial working directory of said login name string. HOME is POSIX-mandated to be '[t]he pathname of the user's home directory'. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ Hope is the last refuge for mad men and dreamers... ___ 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] Rational approximation methods
On 21/01/2008, Tim Peters [EMAIL PROTECTED] wrote: What would be useful is a method that generates (i.e., a generator in the Python sense) the (continued fraction) convergents to a rational. People wanting specific constraints on a rational approximation (including, but not limited to, the two you identified) can easily build them on top of such a generator. Interesting. I thought of suggesting something like this, but my potential use cases are so rare that I couldn't justify it. But as you say, it's one general building block from which any other desired functionality can be produced. By useful I don't mean lots of people will use it ;-) I mean /some/ people will use it -- a way to generate the sequence of convergents is a fundamental tool that can be used for all sorts of stuff, by those with advanced applications. Good point. Fundamental tools belong in the library. +1 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] #! magic
Jeroen Ruigrok van der Werven wrote: % ./test.py Unknown option: - usage: /usr/local/bin/python [option] ... [-c cmd | -m mod | file | -] [arg] ... Try `python -h' for more information. Contracting to -Es works, aside from -s being unknown to my Python. And also, /usr/bin won't work, FreeBSD uses /usr/local/bin since Python is installed through ports and is not a system binary. The -s option is part of my PEP and is not available in the trunk yet. The arg -Es may work because Python's arg parser doesn't recognize it as two args -E -s but as the arg -E. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #! magic
On Mon, Jan 21, 2008 at 12:01:29PM +0100, Christian Heimes wrote: The arg -Es may work because Python's arg parser doesn't recognize it as two args -E -s but as the arg -E. Thank goodness python is better than that: $ python -Es Unknown option: -s usage: python [option] ... [-c cmd | -m mod | file | -] [arg] ... Try `python -h' for more information. $ python -E -s Unknown option: -s usage: python [option] ... [-c cmd | -m mod | file | -] [arg] ... Try `python -h' for more information. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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: per user site-packages directory
-On [20080116 07:15], Martin v. Löwis ([EMAIL PROTECTED]) wrote: I don't understand why they *have* to do that. I can believe they do that as they don't know better - but why can't they use the Python interpreter already available on the system, and just install additional packages in their home directory? Good question. I guess there just isn't a clear and precise document available to point them at. I'll be glad to (help) write such an article. For that, I think the requirements need to be much more explicit. Yeah, sorry, have not had the time available to verify all cases Christian reported versus what I can think of. Impending surgery tends to distract the mind a bit. ;) -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ Where does the world end if the enternal optimist loses faith..? ___ 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: per user site-packages directory
Martin v. Löwis wrote: Right now Python faces a lot of problems in the webhosting world because it's tedious to set up and maintain for the webhosting user since they often have to compile and install their own Python in their home directory. I don't understand why they *have* to do that. I can believe they do that as they don't know better - but why can't they use the Python interpreter already available on the system, and just install additional packages in their home directory? One possible reason is that the hosting vendor doesn't provide a sufficiently up-to-date Python release for certain site requirements. I think this is extremely important due to the proliferation of Python now more and more as a choice for webapp development. For that, I think the requirements need to be much more explicit. True. But IMHO Python is still seen as a difficult language to package. We haven't reached CPAN levels of ease-of-use ye. Yes, I *do* know that CPAN isn't perfect, and I think easy_install is a great boon to Python users, but CPAN does a great job 98% of the time. Maybe once we get easy_install as a part of the core (so there's no need to find and run ez_setup.py to start with) things will start to improve. This is an issue the whole developer community needs to take seriously if we are interested in increasing take-up. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.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] PEP: per user site-packages directory
Steve Holden wrote: Maybe once we get easy_install as a part of the core (so there's no need to find and run ez_setup.py to start with) things will start to improve. This is an issue the whole developer community needs to take seriously if we are interested in increasing take-up. setuptools and easy_install won't be included in Python 2.6 and 3.0: http://www.python.org/dev/peps/pep-0365/ Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug Day outcome
On Sun, Jan 20, 2008 at 10:13:44PM +0100, Georg Brandl wrote: Since this bug day was a relative success, I suggest to introduce a more-or-less regular schedule. Feb 23 would make a nice second bug day in 2008, wouldn't it? That works for me. I've updated the wiki page to give Feb. 23 as the date, and will update pydotorg this evening. --amk ___ 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] Re: PEP: per user site-packages directory
Christian Heimes wrote: Steve Holden wrote: Maybe once we get easy_install as a part of the core (so there's no need to find and run ez_setup.py to start with) things will start to improve. This is an issue the whole developer community needs to take seriously if we are interested in increasing take-up. setuptools and easy_install won't be included in Python 2.6 and 3.0: http://www.python.org/dev/peps/pep-0365/ Which is a shame. I agree with Steve on this - although I realise that Phillip is basically the only person able to do the work. Michael Foord Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk ___ 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: per user site-packages directory
Christian Heimes wrote: Steve Holden wrote: Maybe once we get easy_install as a part of the core (so there's no need to find and run ez_setup.py to start with) things will start to improve. This is an issue the whole developer community needs to take seriously if we are interested in increasing take-up. setuptools and easy_install won't be included in Python 2.6 and 3.0: http://www.python.org/dev/peps/pep-0365/ Yes, and yet another release (two releases) will go out without easy access to the functionality in Pypi. PEP 365 is a good start, but Pypi loses much of its point until new Python users get access to it out of the box. I also appreciate that resource limitations are standing in the way of setuptools' inclusion (is there something I can do about that?) Just to hammer the point home, however ... The easy_install utility from setuptools is probably the biggest potential recruiter for Python. It makes the language accessible to the majority of users who are interested only in acquiring new functionality, and not at all in which language that functionality is implemented in. Installation of the latest/most appropriate version of something then becomes a simple recipe without command switches regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.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] PEP: per user site-packages directory
Steve Holden wrote: Christian Heimes wrote: Steve Holden wrote: Maybe once we get easy_install as a part of the core (so there's no need to find and run ez_setup.py to start with) things will start to improve. This is an issue the whole developer community needs to take seriously if we are interested in increasing take-up. setuptools and easy_install won't be included in Python 2.6 and 3.0: http://www.python.org/dev/peps/pep-0365/ Yes, and yet another release (two releases) will go out without easy access to the functionality in Pypi. PEP 365 is a good start, but Pypi loses much of its point until new Python users get access to it out of the box. I also appreciate that resource limitations are standing in the way of setuptools' inclusion (is there something I can do about that?) Just to hammer the point home, however ... Have another look at the rationale given in PEP 365 - it isn't the resourcing to do the work that's a problem, but the relatively slow release cycle of the core. By including pkg_resources in the core (with the addition of access to pure Python modules and packages on PyPI), we would get a simple, stable base for Python packaging to work from, and put users a single standard command away from the more advanced (but also more volatile) features of easy_install and friends. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 365 (was Re: PEP: per user site-packages directory)
At 01:06 AM 1/22/2008 +1000, Nick Coghlan wrote: Steve Holden wrote: Christian Heimes wrote: Steve Holden wrote: Maybe once we get easy_install as a part of the core (so there's no need to find and run ez_setup.py to start with) things will start to improve. This is an issue the whole developer community needs to take seriously if we are interested in increasing take-up. setuptools and easy_install won't be included in Python 2.6 and 3.0: http://www.python.org/dev/peps/pep-0365/ Yes, and yet another release (two releases) will go out without easy access to the functionality in Pypi. PEP 365 is a good start, but Pypi loses much of its point until new Python users get access to it out of the box. I also appreciate that resource limitations are standing in the way of setuptools' inclusion (is there something I can do about that?) Just to hammer the point home, however ... Have another look at the rationale given in PEP 365 - it isn't the resourcing to do the work that's a problem, but the relatively slow release cycle of the core. By including pkg_resources in the core (with the addition of access to pure Python modules and packages on PyPI), we would get a simple, stable base for Python packaging to work from, and put users a single standard command away from the more advanced (but also more volatile) features of easy_install and friends. By the way, if we're actually going to get that into 2.6, it would be good for the PEP to actually be approved before then. :) With respect to Steve's comments about out-of-the-box usability, it should be noted that when you bootstrap a package with pkg_resources, it should be possible to include other command-line arguments after the package specifier. So for example: python -m pkg_resources setuptools SomePackage==1.2 would download and install setuptools, and run its bootstrap script with SomePackage==1.2 as a command-line argument. And setuptools' bootstrap script is basically easy_install with some extra code to make sure the setuptools egg gets installed too. In other words, with PEP 365 in place, python -m pkg_resources setuptools is basically a way to say easy_install without needing setuptools installed. (Heck, if what you really want is to have easy_install support in 2.6, we could just as easily bundle an easy_install.py that asks for an install of setuptools if it's not already present.) ___ 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 365 (was Re: PEP: per user site-packages directory)
Phillip J. Eby wrote: At 01:06 AM 1/22/2008 +1000, Nick Coghlan wrote: Steve Holden wrote: Christian Heimes wrote: Steve Holden wrote: Maybe once we get easy_install as a part of the core (so there's no need to find and run ez_setup.py to start with) things will start to improve. This is an issue the whole developer community needs to take seriously if we are interested in increasing take-up. setuptools and easy_install won't be included in Python 2.6 and 3.0: http://www.python.org/dev/peps/pep-0365/ Yes, and yet another release (two releases) will go out without easy access to the functionality in Pypi. PEP 365 is a good start, but Pypi loses much of its point until new Python users get access to it out of the box. I also appreciate that resource limitations are standing in the way of setuptools' inclusion (is there something I can do about that?) Just to hammer the point home, however ... Have another look at the rationale given in PEP 365 - it isn't the resourcing to do the work that's a problem, but the relatively slow release cycle of the core. By including pkg_resources in the core (with the addition of access to pure Python modules and packages on PyPI), we would get a simple, stable base for Python packaging to work from, and put users a single standard command away from the more advanced (but also more volatile) features of easy_install and friends. By the way, if we're actually going to get that into 2.6, it would be good for the PEP to actually be approved before then. :) Yes, I noticed it wasn't yet approved and wondered whether this was simply an oversight or whether there is still work to do before it can be approved. With respect to Steve's comments about out-of-the-box usability, it should be noted that when you bootstrap a package with pkg_resources, it should be possible to include other command-line arguments after the package specifier. So for example: python -m pkg_resources setuptools SomePackage==1.2 would download and install setuptools, and run its bootstrap script with SomePackage==1.2 as a command-line argument. And setuptools' bootstrap script is basically easy_install with some extra code to make sure the setuptools egg gets installed too. In other words, with PEP 365 in place, python -m pkg_resources setuptools is basically a way to say easy_install without needing setuptools installed. Well that's probably a simple enough recipe to include in the distribution, wouldn't you say? (Heck, if what you really want is to have easy_install support in 2.6, we could just as easily bundle an easy_install.py that asks for an install of setuptools if it's not already present.) Would the easiest way to do this be to insert a default dependency on setuptools? regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.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] Rational approximation methods
On Jan 21, 2008 3:44 AM, Paul Moore [EMAIL PROTECTED] wrote: On 21/01/2008, Tim Peters [EMAIL PROTECTED] wrote: By useful I don't mean lots of people will use it ;-) I mean /some/ people will use it -- a way to generate the sequence of convergents is a fundamental tool that can be used for all sorts of stuff, by those with advanced applications. Good point. Fundamental tools belong in the library. +1 How about a generator for the convergents in the rational module together with an example in the documentation showing how to use the convergents to implement something like trim? ___ 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 365 (was Re: PEP: per user site-packages directory)
At 10:48 AM 1/21/2008 -0500, Steve Holden wrote: Phillip J. Eby wrote: (Heck, if what you really want is to have easy_install support in 2.6, we could just as easily bundle an easy_install.py that asks for an install of setuptools if it's not already present.) Would the easiest way to do this be to insert a default dependency on setuptools? Sorry, I don't understand the question. What do you mean by default dependency and to what are you proposing it be inserted? :) What I meant was that we could include an easy_install.py whose sole function is to ensure that setuptools is installed and then invoke the real easy_install. Thus, the first time you ran easy_install, a current version would be downloaded, and thereafter the real one would be runnable. ___ 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] Re: PEP: per user site-packages directory
Which is a shame. I agree with Steve on this - although I realise that Phillip is basically the only person able to do the work. Not the only one able - the only one willing to. People shouldn't complain about the state of things if they aren't willing to do anything about it (except complaining). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 365 (was Re: PEP: per user site-packages directory)
What I meant was that we could include an easy_install.py whose sole function is to ensure that setuptools is installed and then invoke the real easy_install. Thus, the first time you ran easy_install, a current version would be downloaded, and thereafter the real one would be runnable. Despite my (well-known) objections to setuptools as the foundation for the .egg format (and everything that comes with it), I think that would be a desirable and easy thing to do. Including a setuptools bootstrapper into the distribution still leaves the choice of actually using setuptools to the end user. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 365 (was Re: PEP: per user site-packages directory)
On Jan 21, 2008 1:46 PM, Martin v. Löwis [EMAIL PROTECTED] wrote: What I meant was that we could include an easy_install.py whose sole function is to ensure that setuptools is installed and then invoke the real easy_install. Thus, the first time you ran easy_install, a current version would be downloaded, and thereafter the real one would be runnable. Despite my (well-known) objections to setuptools as the foundation for the .egg format (and everything that comes with it), I think that would be a desirable and easy thing to do. Including a setuptools bootstrapper into the distribution still leaves the choice of actually using setuptools to the end user. What Martin said, almost verbatim. =) -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
