Le dimanche 07 février 2010 à 09:54 +0100, Pascal Chambon a écrit :
> > Actually, TextIOWrapper is simply not thread-safe for most of its
> > operations. I
> > think we did the work for simple writing, though, since it's better for
> > multi-threaded use of print().
>
> Argh, I had the impression
On Feb 06, 2010, at 02:20 PM, Guido van Rossum wrote:
>> Upon further reflection, I agree. __file__ also points to the source in
>> Python 2.7.
>
>Not in the 2.7 svn repo I have access to. It still points to the .pyc
>file if it was used.
Ah, I was fooled by a missing pyc file. Run it a second
On Feb 04, 2010, at 03:00 PM, Glenn Linderman wrote:
>When a PEP 3147 (if modified by my suggestion) version of Python runs,
>and the directory doesn't exist, and it wants to create a .pyc, it would
>create the directory, and put the .pyc there. Sort of just like how it
>creates .pyc files, no
On Jan 31, 2010, at 01:06 PM, Ron Adam wrote:
>With a single cache directory, we could have an option to force writing
>bytecode to a desired location. That might be useful on it's own for
>creating runtime bytecode only installations for installers.
One important reason for wanting to keep th
On 07/02/2010 17:48, Barry Warsaw wrote:
[snip...]
And I propose not to disturb this in 2.7, at least not by default. I'm
fine though with a flag or distro-overridable config setting to change
this behavior.
Cool. I'm not sure this is absolutely necessary for Debian/Ubuntu, so I'll
call
On Jan 31, 2010, at 08:10 PM, Silke von Bargen wrote:
>Martin v. Löwis schrieb:
>> There is also the issue of race conditions with multiple simultaneous
>> accesses. The original format for the PEP had race conditions for
>> multiple simultaneous writers; ZIP will also have race conditions for
>>
On Jan 31, 2010, at 11:34 PM, Nick Coghlan wrote:
>I must admit I quite like the __pyr__ directory approach as well. Since
>the interpreter knows the suffix it is looking for, names shouldn't
>conflict. Using a single directory allows the name to be less cryptic,
>too (e.g. __pycache__).
Somethin
On Feb 01, 2010, at 08:26 AM, Tim Delaney wrote:
>The pyc/pyo files are just an optimisation detail, and are essentially
>temporary. Given that, if they were to live in a single directory, to me it
>seems obvious that the default location for that should be in the system
>temporary directory. I an
On Feb 06, 2010, at 04:02 PM, Guido van Rossum wrote:
>On Sat, Feb 6, 2010 at 3:28 PM, Barry Warsaw wrote:
>> On Feb 01, 2010, at 02:04 PM, Paul Du Bois wrote:
>>
>>>It's an interesting challenge to write the file in such a way that
>>>it's safe for a reader and writer to co-exist. Like Brett, I
On Feb 06, 2010, at 04:39 PM, Guido van Rossum wrote:
>The conflict is purely that PEP 3147 proposes the new behavior to be
>optional, and adds a flag (-R) and an environment variable
>($PYTHONPYR) to change it. I presume Barry is proposing this out of
>fear that the new behavior might upset someb
On Feb 07, 2010, at 05:59 PM, Michael Foord wrote:
>On 07/02/2010 17:48, Barry Warsaw wrote:
>> [snip...]
>>> And I propose not to disturb this in 2.7, at least not by default. I'm
>>> fine though with a flag or distro-overridable config setting to change
>>> this behavior.
>>>
>> Cool. I'm
On Feb 06, 2010, at 11:22 PM, exar...@twistedmatrix.com wrote:
>>I haven't tried to repro this particular example, but the reason is
>>that we don't want to have to call getpwd() on every import nor do we
>>want to have some kind of in-process variable to cache the current
>>directory. (getpwd() i
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 or Mercurial. Start up time
Barry Warsaw wrote:
> On Feb 03, 2010, at 11:59 AM, M.-A. Lemburg wrote:
>
>> How about using an optionally relative cache dir setting to let
>> the user decide ?
>
> Why do we need that level of flexibility?
It's very easy to implement (see the code I posted) and gives
you a lot of control with
On Sun, Feb 7, 2010 at 10:17 AM, Barry Warsaw wrote:
> On Jan 31, 2010, at 11:34 PM, Nick Coghlan wrote:
>
>>I must admit I quite like the __pyr__ directory approach as well. Since
>>the interpreter knows the suffix it is looking for, names shouldn't
>>conflict. Using a single directory allows the
On Sun, Feb 7, 2010 at 10:44, Barry Warsaw wrote:
> On Feb 06, 2010, at 04:39 PM, Guido van Rossum wrote:
>
>>The conflict is purely that PEP 3147 proposes the new behavior to be
>>optional, and adds a flag (-R) and an environment variable
>>($PYTHONPYR) to change it. I presume Barry is proposing
It's been a long time!
So for the past few weeks, Mercurial crew member Patrick Mezard has
been hunting for the ugly bug in hgsubversion that I'd previously been
looking at, and it finally got fixed. A new bug popped up, but then we
managed to fix that, too (thanks to the PSF for partially funding
2010/2/7 Dirkjan Ochtman :
> It's been a long time!
Thank you very much for staying on this task! I'm still excited.
>
> In fact, a few weeks ago I talked to Brett and we figured that we
> should probably pin down a deadline. We discussed aiming at May 1, and
> at this time I think that should be
Hi Dirkjan,
On 8/02/2010 8:35 AM, Dirkjan Ochtman wrote:
...
In fact, a few weeks ago I talked to Brett and we figured that we
should probably pin down a deadline. We discussed aiming at May 1, and
at this time I think that should be feasible. That also seems to
coincide with the release of 2.7
On Sun, Feb 7, 2010 at 12:23 PM, Brett Cannon wrote:
> On Sun, Feb 7, 2010 at 10:44, Barry Warsaw wrote:
>> On Feb 06, 2010, at 04:39 PM, Guido van Rossum wrote:
>>
>>>The conflict is purely that PEP 3147 proposes the new behavior to be
>>>optional, and adds a flag (-R) and an environment variabl
Barry Warsaw wrote:
On Jan 31, 2010, at 01:06 PM, Ron Adam wrote:
With a single cache directory, we could have an option to force writing
bytecode to a desired location. That might be useful on it's own for
creating runtime bytecode only installations for installers.
One important reason
21 matches
Mail list logo
