Antoine Pitrou wrote:
> Barry Warsaw python.org> writes:
>>> exarkun boson:~$ python -m timeit -s 'from os import getcwd' 'getcwd()'
>>> 100 loops, best of 3: 1.02 usec per loop
> [...]
>> I'd like to see the effect on command line scripts that are run often and
>> then
>> exit, e.g. Bazaar
Nick Coghlan gmail.com> writes:
>
> The problem is that having '' as the first entry in sys.path currently
> means "do the import relative to the current directory". Unless we want
> to change the language semantics so we stick os.getcwd() at the front
> instead of '', then __file__ is still goin
Ron Adam wrote:
> To tell the truth in most cases I hardly notice the extra time the first
> run takes compared to later runs with the precompiled byte code. Yes it
> may be a few seconds at start up, but after that it's usually not a big
> part of the execution time. Hmmm, I wonder if there's a
Antoine Pitrou wrote:
> Nick Coghlan gmail.com> writes:
>> The problem is that having '' as the first entry in sys.path currently
>> means "do the import relative to the current directory". Unless we want
>> to change the language semantics so we stick os.getcwd() at the front
>> instead of '', th
On Mon, Feb 08, 2010 at 12:51:22PM +, Antoine Pitrou wrote:
> Do some people actually rely on the fact that changing the current directory
> will also change the import path?
On the interactive prompt, yes. But I guess that's a habit that could
be easily un-learnt.
Regards
Floris
--
Debi
On 2/8/2010 7:54 AM, Nick Coghlan wrote:
Ron Adam wrote:
To tell the truth in most cases I hardly notice the extra time the first
run takes compared to later runs with the precompiled byte code. Yes it
may be a few seconds at start up, but after that it's usually not a big
part of the execution
On Sun, Feb 7, 2010 at 22:51, Benjamin Peterson wrote:
> How about a week after, so we have more time to adjust release procedures?
Sounds fine to me.
> Will you do test conversions of the sandbox projects, too?
Got any particular projects in mind?
> Also I think we should have some document (
On Sun, Feb 7, 2010 at 22:58, Mark Hammond wrote:
> Isn't setting a date premature while outstanding issues remain without a
> timetable for their resolution?
If we set a date, that would imply a timetable for their resolution.
> See http://mercurial.selenic.com/wiki/EOLTranslationPlan#TODO - of
2010/2/8 Dirkjan Ochtman :
> On Sun, Feb 7, 2010 at 22:51, Benjamin Peterson wrote:
>> Will you do test conversions of the sandbox projects, too?
>
> Got any particular projects in mind?
2to3.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-
Hi Craig,
On Tue, Feb 2, 2010 at 4:42 PM, Craig Citro wrote:
>> Done. The diff is at
>> http://codereview.appspot.com/186247/diff2/5014:8003/7002. I listed
>> Cython, Shedskin and a bunch of other alternatives to pure CPython.
>> Some of that information is based on conversations I've had with th
Benjamin Peterson wrote:
> 2010/2/8 Dirkjan Ochtman :
>> On Sun, Feb 7, 2010 at 22:51, Benjamin Peterson wrote:
>>> Will you do test conversions of the sandbox projects, too?
>> Got any particular projects in mind?
>
> 2to3.
Does Mercurial even support merge tracking the way we are doing it for
2010/2/8 "Martin v. Löwis" :
> Benjamin Peterson wrote:
>> 2010/2/8 Dirkjan Ochtman :
>>> On Sun, Feb 7, 2010 at 22:51, Benjamin Peterson wrote:
Will you do test conversions of the sandbox projects, too?
>>> Got any particular projects in mind?
>>
>> 2to3.
>
> Does Mercurial even support merg
12 matches
Mail list logo
