[IronPython] Re: Nice speed
Travis Watkins wrote: > Never trust the program you're running to give you accurate time. Use > 'time python foo.py' instead. so you can make sure that the thing you're measuring is hidden by all the irrelevant stuff that's going on when a process starts, and, if the thing you're measuring is small enough, your results will be completely meaningless. hello? ___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Re: Nice speed
On 4/27/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Travis Watkins wrote: > > > Never trust the program you're running to give you accurate time. Use > > 'time python foo.py' instead. > > so you can make sure that the thing you're measuring is hidden by all the > irrelevant > stuff that's going on when a process starts, and, if the thing you're > measuring is small > enough, your results will be completely meaningless. hello? > > > > > ___ > users-ironpython.com mailing list > users-ironpython.com@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > Garth already explained how to account for that. -- Travis Watkins http://www.realistanew.com ___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Re: Re: Nice speed
Travis Watkins wrote: > Garth already explained how to account for that. there's no Garth in this thread, at least not on my server. what are you referring to? (and my criticism still stands: "time python" is an extremely lousy way to benchmark Python processes, no matter what "Garth" says). ___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
RE: [IronPython] Questions for FAQ or User Guide
I don't know what's happened with Starkiller development, but a quick reading of the first page suggests that Boo is using many of the same ideas. At 08:22 PM 4/20/2005, Keith J. Farmer wrote >I just came across Starkiller: >http://www.python.org/pycon/dc2004/papers/1/paper.pdf J. Merrill / Analytical Software Corp ___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
RE: [IronPython] Saving sys.path
Title: [IronPython] Saving sys.path There are, as far as I can see, three different ways to help in this case and I am looking into implementing all of them very soon, definitely for the next release. CPython uses environment variables PYTHONSTARTUP and PYTHONPATH to drive the initialization of the interpreter Also, on initialization, the interpreter executes statement “import site” which is the third way to hook into the initialization process. As for the environment variables go, there is a question of naming. One possibility is to use the well-known names (PYTHONSTARTUP, PYTHONPATH) and another is to use our own: IRONPYTHONSTARTUP and IRONPYTHONPATH. We prefer the latter (names prefixed with IRON) to avoid conflicts for those of us who use CPython and IronPython on the same machine. Unless there is strong reason to use the standard names, we will go forward with the IRONPYTHON… ones. If you feel one way or another, please let us know. For the purpose of the environment variable naming, we are not considering other naming schemes so the choice is either standard names, or IRONPYTHON* ones. Keith, I think this should provide you with the tools you need for your work, correct? We will try to get this update out even sooner than usual. Martin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Keith J. Farmer Sent: Tuesday, April 26, 2005 4:02 PM To: Discussion of IronPython Subject: RE: [IronPython] Saving sys.path Perhaps (to at least keep the .NET way) a .config file instead of an environment variable? That file *could* specify one or more startup files, to maintain the Python mystique. From: [EMAIL PROTECTED] on behalf of Michael Spencer Sent: Tue 4/26/2005 3:52 PM To: users-ironpython.com@lists.ironpython.com Subject: [IronPython] Saving sys.path Second feature request of the week: I would like to save sys.path settings between interpreter sessions. Is there a way to do this today? If not, could there be an OS environment variable for this or, a startup.py file loaded each time the interpreter starts? ___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Re: Saving sys.path
Martin Maly wrote: If you feel one way or another, please let us know. For the purpose of the environment variable naming, we are not considering other naming schemes so the choice is either standard names, or IRONPYTHON* ones. I agree that any environment variables should be different from CPython's Also, a temporary solution that might change in future versions would be fine. Michael ___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
RE: [IronPython] Saving sys.path
Actually, it was Michael who brought it up originally, so maybe ask him? I just butted in. But... There is a reason I'm not overly fond of environment variables -- they tend to get onerous to manage, and they don't necessarily propagate to user accounts after the admin sets them, as I discovered last night. I've switched to using a normal user account on my machine, and discovered I couldn't change the global IRONPYTHON_HOME variable I'd created (my path includes %IRONPYTHON_HOME% as a convenience thing)? So I switched to admin, changed it there, and switched back to my user. My user still used the old home for 0.7.2. I had to go back to admin, open up the PATH variable, not change a thing, and re-close it before my user switched to 0.7.3. Bug in XP? Almost certainly, IMHO (and I love XP). Ignorable for managing IronPython installations? Probably not. I think a better administrative experience would involve minimizing the dependency on environment variables, and given the built-in mechanisms in .NET In the case of configuring the interpreter, one need not copy the way CPython does it, if it can be argued that IronPython could do it better, by configuring the application rather than the shell. It'd allow configuration specific to even a version, if needed, and a richer configuration at that. I'd at least like to see that as an option. I propose IronPython use .config, and override with Environment Variables From: [EMAIL PROTECTED] on behalf of Martin Maly Sent: Wed 4/27/2005 10:20 AM To: Discussion of IronPython Subject: RE: [IronPython] Saving sys.path There are, as far as I can see, three different ways to help in this case and I am looking into implementing all of them very soon, definitely for the next release. CPython uses environment variables PYTHONSTARTUP and PYTHONPATH to drive the initialization of the interpreter Also, on initialization, the interpreter executes statement "import site" which is the third way to hook into the initialization process. As for the environment variables go, there is a question of naming. One possibility is to use the well-known names (PYTHONSTARTUP, PYTHONPATH) and another is to use our own: IRONPYTHONSTARTUP and IRONPYTHONPATH. We prefer the latter (names prefixed with IRON) to avoid conflicts for those of us who use CPython and IronPython on the same machine. Unless there is strong reason to use the standard names, we will go forward with the IRONPYTHON... ones. If you feel one way or another, please let us know. For the purpose of the environment variable naming, we are not considering other naming schemes so the choice is either standard names, or IRONPYTHON* ones. Keith, I think this should provide you with the tools you need for your work, correct? We will try to get this update out even sooner than usual. <>___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Re: Re: Nice speed
Okay, I've switched my subscription to my posting address so my messages don't get queued. :) What I said was: given that we're comparing different environments, [using 'time' is] only a good idea if you also run zero-loop tests so you can subtract the startup and shutdown costs. I get where Travis is trying to head on measuring CPU time rather than wall-clock time. To be *really* careful, of course, one should run a number of tests at different orders of magnitude to see whether you have algorithmic scalability problems. Also, it's probably not going to matter whether you try and measure CPU time or wall time in Python or out of it as long as you publish your tests and raw data and gathering and publish any comments pointing out problems, variations on other platforms, etc. Regards, Garth. ___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Saving sys.path
On 27/04/05, Keith J. Farmer <[EMAIL PROTECTED]> wrote: > I've switched to using a normal user account on my machine, and discovered I > couldn't change the global IRONPYTHON_HOME variable I'd created (my path > includes %IRONPYTHON_HOME% as a convenience thing)? So I switched to admin, > changed it there, and switched back to my user. Windows 2000/XP allow you to set both user and system level environment variables. For my PYTHONPATH environment setting, I use a user level environment variable and this seems to work fine when I need it. Maybe the same would work for you? (you may have to delete the system level variable first. >In the case of configuring the interpreter, one need not copy the way CPython does it, if it can be argued that IronPython could do it better, by configuring the application rather than the shell. It'd allow configuration specific to even a version, if needed, and a richer configuration at that. I'd at least like to see that as an option. CPython also allows some other options, such as using .pth files in your site-packages folder. This allows configuration of the application rather than the shell. >From my perspective as a regular CPython user on windows, .pth files have generally worked well for me, and I use them instead of environment variables for the most part. Take care, -Brian ___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Nice speed
> Never trust the program you're running to give you accurate time. Use > 'time python foo.py' instead. Given that we're comparing different environments, that's only a good idea if you also run zero-loop tests so you can subtract the startup and shutdown costs. Regards, Garth. ___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
RE: [IronPython] Saving sys.path
I'd set a user-level environment variable as well, checking that out, but it seemed a kludge at best. In a multi-user environment it'd be a hassle. For deployment to multiple machines, it'd be annoying at best. With respect, I'll maintain my stance of using .config files as the mechanism supported by .NET. I'd prefer unifying under that, rather than trying to grandfather in a variety of -isms from CPython. I should point out that nothing prevents IronPython from having the capability to support both -- one as standard, the other as override, if grandfather it must. In fact, I think it'd make much more sense to support .config. Consider the possibility of embedding IronPython in a C# app, or an ASP.NET app, or of producing IronPython modules for use in the rest of .NET -- in any of these cases, the consuming developers are going to expect .config files rather than environment variables, and rightly so. We shouldn't have to special case the configuration mechanism, just to make it work with peers under the same runtime. Apps using the CLR use .config files, and I think IronPython should take that into consideration. (Python was my favorite language until C# came along. Maybe with IronPython-omega with generics...) From: [EMAIL PROTECTED] on behalf of Brian Dorsey Sent: Wed 4/27/2005 1:23 PM To: Discussion of IronPython Subject: Re: [IronPython] Saving sys.path <>___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Saving sys.path
On 27/04/05, Keith J. Farmer <[EMAIL PROTECTED]> wrote: > I'd set a user-level environment variable as well, checking that out, but it > seemed a kludge at best. In a multi-user environment it'd be a hassle. For > deployment to multiple machines, it'd be annoying at best. Indeed. In that scenario I'd install directly into site-packages or add a .pth file into site-packages. Or, like I usually do for windows deployments, package it up with py2exe and an installer. :) (however, as you can see, I'm firmly in CPython land... what does 'site-packages' even mean in a DotNet assembly? :) > With respect, I'll maintain my stance of using .config files as the mechanism > supported by .NET. I'd prefer unifying under that, rather than trying to > grandfather in a variety of -isms from CPython. I should point out that > nothing prevents IronPython from having the capability to support both -- one > as standard, the other as override, if grandfather it must. If both are needed (and your scenario below is pretty convincing) then supporting both would work for me. I guess the principle I'm hoping for is that for the most part a CPython person should be able to just start using IronPythonConsole.exe (or whatever) instead of python.exe, at least for simple apps. The only difference being that suddenly the CLR is available. > In fact, I think it'd make much more sense to support .config. Consider the > possibility of embedding IronPython in a C# app, or an ASP.NET app, or of > producing IronPython modules for use in the rest of .NET -- in any of these > cases, the consuming developers are going to expect .config files rather than > environment variables, and rightly so. We shouldn't have to special case the > configuration mechanism, just to make it work with peers under the same > runtime. Apps using the CLR use .config files, and I think IronPython should > take that into consideration. Yes indeed. I suppose there are a lot of questions there, which I hadn't even considered. Would all of your modules be 'frozen' into the assembly? Anyway, I've passed far beyond my experience here, so I'm going to stop. I just wanted to make the point that people coming from CPython are going to expect to be able to use environment variables and .pth files. Take care, -Brian ___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
RE: [IronPython] Saving sys.path
I agree that the env vars and the .pth present a migration path -- and that's a good thing I don't intend to disagree with. Freezing of modules: funny you should mention that. I recall a somewhat undermentioned feature of assemblies being composable from several seperate files, referred to as modules. That's beyond my experience, as well, and I imagine depends greatly on how Jim and Martin construct the assembly to begin with. Site-Packages: Global Assembly Cache, I think. When you install J#, it installs J# framework assemblies in such a way that they're accessible from C#. The same I think should be done here. I can see a tool being created to convert a stock Python package into IL and importing it into the GAC. It's a difference in installation, that makes it appropriate for the new platform. Anyway, I'm supposed to be head-down in some gruesome Java, which is neither Python nor .NET, so I should shut up for a while and let the sub-Guidos speak. <>___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
