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 a
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 scena
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
sup
> 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.
_
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,
> chang
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 Travi
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 disco
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
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 initializ
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 / An
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).
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 goi
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 s
13 matches
Mail list logo
