> 3. In each top level directory on sys.path, shadow file heirarchy
> Major Pro: trivial to separate out all cached files
> Major Con: ??? (I got nuthin')
The major con of this option (and option 2) is an ambiguity of where to
look for in case of packages. In particular for namespace packages
> Any help you could provide would be appreciated.
Please use unified diffs in the future.
I'm -0 on this patch; it still has the negative, cautionary-patronizing
tone ("Do not", "can be tricky", "be mindful"), as if readers are unable
to grasp the description that they just read (and indeed, in
Hanno Schlichting wrote:
>+1 for a single strategy that is used in all cases. The current
>solution could be phased out across multiple releases, but in the end
>there should be a single approach and no flag. Otherwise some code and
>tools will only support one of the approaches, especially if thi
> Would you still be a -1 on making it the new scheme the default if it
> used a single cache directory instead? That would actually be cleaner
> than the current solution rather than messier.
Well, I guess no, although additional directories are always more
intrusive than additional files (visua
On Fri, Jan 29, 2010 at 08:02:58PM -0500, P.J. Eby wrote:
> At 01:24 AM 1/30/2010 +0100, Ludvig Ericson wrote:
>
>> On 28 jan 2010, at 22:47, P.J. Eby wrote:
>>
>> > At 07:47 PM 1/28/2010 +0100, Benjamin Schweizer wrote:
>> >>
>> >> I like the idea of configuring the list of variables with using a
Raymond Hettinger wrote:
>
> On Jan 30, 2010, at 4:00 PM, Barry Warsaw wrote:
>> Abstract
>>
>>
>> This PEP describes an extension to Python's import mechanism which
>> improves sharing of Python source code files among multiple installed
>> different versions of the Python interpreter.
>
M.-A. Lemburg wrote:
> Collin Winter wrote:
>> I added startup benchmarks for Mercurial and Bazaar yesterday
>> (http://code.google.com/p/unladen-swallow/source/detail?r=1019) so we
>> can use them as more macro-ish benchmarks, rather than merely starting
>> the CPython binary over and over again.
Hey MA,
On Mon, Feb 1, 2010 at 9:58 AM, M.-A. Lemburg wrote:
> BTW: Some years ago we discussed the idea of pluggable VMs for
> Python. Wouldn't U-S be a good motivation to revisit this idea ?
>
> We could then have a VM based on byte code using a stack
> machines, one based on word code using a
On Sun, Jan 31, 2010 at 11:16, Guido van Rossum wrote:
> Whoa. This thread already exploded. I'm picking this message to
> respond to because it reflects my own view after reading the PEP.
>
> On Sun, Jan 31, 2010 at 4:13 AM, Hanno Schlichting wrote:
>> On Sun, Jan 31, 2010 at 1:03 PM, Simon Cros
Collin Winter wrote:
> Hey MA,
>
> On Mon, Feb 1, 2010 at 9:58 AM, M.-A. Lemburg wrote:
>> BTW: Some years ago we discussed the idea of pluggable VMs for
>> Python. Wouldn't U-S be a good motivation to revisit this idea ?
>>
>> We could then have a VM based on byte code using a stack
>> machines,
On Sun, Jan 31, 2010 at 11:04, Raymond Hettinger
wrote:
>
> On Jan 30, 2010, at 4:00 PM, Barry Warsaw wrote:
>> Abstract
>>
>>
>> This PEP describes an extension to Python's import mechanism which
>> improves sharing of Python source code files among multiple installed
>> different versio
On Mon, Feb 1, 2010 at 11:17 AM, M.-A. Lemburg wrote:
> Collin Winter wrote:
>> I think this idea underestimates a) how deeply the current CPython VM
>> is intertwined with the rest of the implementation, and b) the nature
>> of the changes required by these separate VMs. For example, Unladen
>> S
Le Mon, 01 Feb 2010 11:35:19 -0800, Brett Cannon a écrit :
>
> As others have said, an uncompressed zip file could work here. Or even a
> file format where the first 4 bytes is the timestamp and then after that
> are chunks of length-of-bytecode|magic|bytecode. That allows for opening
> a file in
So, if a patch was proposed for the multiprocessing, allowing an unified
"spawnl", thread-safe, semantic, do you think something could prevent
its integration ?
We may ignore the subprocess module, since fork+exec shouldn't be
bothered by the (potentially disastrous) state of child process d
On 2/1/2010 1:32 PM, Collin Winter wrote:
Hey MA,
On Mon, Feb 1, 2010 at 9:58 AM, M.-A. Lemburg wrote:
BTW: Some years ago we discussed the idea of pluggable VMs for
Python. Wouldn't U-S be a good motivation to revisit this idea ?
We could then have a VM based on byte code using a stack
machi
> And I disagree this would be difficult as the PEP suggests given the
> proper file format. For zip files zipimport already has the read code
> in C; it just would require the code to write to a zip file. And as
> for the format I mentioned above, that's dead-simple to implement.
How do you write
On Mon, Feb 1, 2010 at 3:09 PM, Pascal Chambon wrote:
>
> So, if a patch was proposed for the multiprocessing, allowing an unified
> "spawnl", thread-safe, semantic, do you think something could prevent its
> integration ?
>
> We may ignore the subprocess module, since fork+exec shouldn't be bothe
On Mon, Feb 1, 2010 at 13:19, "Martin v. Löwis" wrote:
>> And I disagree this would be difficult as the PEP suggests given the
>> proper file format. For zip files zipimport already has the read code
>> in C; it just would require the code to write to a zip file. And as
>> for the format I mention
Jesse Noller gmail.com> writes:
>
> I don't see the need for the change from fork as of yet (for
> multiprocessing) and I am leery to change the internal implementation
> and semantics right now, or anytime soon. I'd be interested in seeing
> the patch, but if the concern is that global threading
On Mon, Feb 1, 2010 at 4:32 PM, Antoine Pitrou wrote:
> Jesse Noller gmail.com> writes:
>>
>> I don't see the need for the change from fork as of yet (for
>> multiprocessing) and I am leery to change the internal implementation
>> and semantics right now, or anytime soon. I'd be interested in see
> On Mon, Feb 1, 2010 at 13:19, "Martin v. Löwis" wrote:
>> How do you write to a zipfile while others are reading it?
On Mon, Feb 1, 2010 at 1:23 PM, Brett Cannon wrote:
> By hating concurrency (i.e. I don't have an answer which kills my idea).
The python I use (win32 2.6.2) does not complain
Jesse Noller gmail.com> writes:
>
> I don't see spawnl as a viable alternative to fork. I imagine that I,
> and others successfully mix threads and multiprocessing on non-win32
> platforms just fine, knowing of course that fork() can cause heartburn
> if you have global locks code within the fork
On Mon, Feb 1, 2010 at 5:08 PM, Antoine Pitrou wrote:
>> I don't see spawnl as a viable alternative to fork. I imagine that I,
>> and others successfully mix threads and multiprocessing on non-win32
>> platforms just fine, knowing of course that fork() can cause heartburn
>> if you have global lo
Antoine Pitrou wrote:
> Jesse Noller gmail.com> writes:
>> I don't see the need for the change from fork as of yet (for
>> multiprocessing) and I am leery to change the internal implementation
>> and semantics right now, or anytime soon. I'd be interested in seeing
>> the patch, but if the concern
On Mon, Feb 1, 2010 at 5:20 PM, "Martin v. Löwis" wrote:
> Antoine Pitrou wrote:
>> Jesse Noller gmail.com> writes:
>>> I don't see the need for the change from fork as of yet (for
>>> multiprocessing) and I am leery to change the internal implementation
>>> and semantics right now, or anytime so
> The python I use (win32 2.6.2) does not complain if it cannot read
> from or write to a .pyc; and thus it handles multiple python processes
> trying to create .pyc files at the same time. Is the .zip case really
> any different? Since .pyc files are an optimization, it seems natural
> and correct
Le lundi 01 février 2010 à 23:20 +0100, "Martin v. Löwis" a écrit :
>
> I don't know what spawnl is supposed to do, but it really sounds like
> the wrong solution.
As far as I understand, I think the idea is to use the same mechanism as
under Windows: spawn a new Python interpreter (in a separate
On Mon, Feb 1, 2010 at 5:18 PM, Jesse Noller wrote:
> I don't disagree there; but then again, I haven't seen this issue
> arise (in my own code)/no bug reports/no test cases that show this to
> be a consistent issue. I'm perfectly OK with being wrong, I'm just
> leery to tearing out the internals
On Feb 1, 2010, at 5:35 PM, Reid Kleckner wrote:
On Mon, Feb 1, 2010 at 5:18 PM, Jesse Noller
wrote:
I don't disagree there; but then again, I haven't seen this issue
arise (in my own code)/no bug reports/no test cases that show this to
be a consistent issue. I'm perfectly OK with being wr
>> Instead, we should aim to make Python fork-safe. If the primary concern
>> is that locks get inherited, we should change the Python locks so that
>> they get auto-released on fork (unless otherwise specified on lock
>> creation). This may sound like an uphill battle, but if there was a
>> smart
On Mon, Feb 1, 2010 at 5:20 PM, "Martin v. Löwis" wrote:
> Instead, we should aim to make Python fork-safe. If the primary concern
> is that locks get inherited, we should change the Python locks so that
> they get auto-released on fork (unless otherwise specified on lock
> creation). This may sou
> We must distinguish between locks owned by the thread which survived the
> fork(), and locks owned by other threads. I guess it's possible if we
> keep track of the thread id which acquired the lock, and if we give
> _whatever_after_fork() the thread id of the thread which initiated the
> fork()
On Mon, Feb 1, 2010 at 5:48 PM, Jesse Noller wrote:
> Your reasonable argument is making it difficult for me to be irrational
> about this.
No problem. :)
> This begs the question - assuming a patch that clones the behavior of win32
> for multiprocessing, would the default continue to be forkin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reid Kleckner wrote:
> On Mon, Feb 1, 2010 at 5:18 PM, Jesse Noller wrote:
>> I don't disagree there; but then again, I haven't seen this issue
>> arise (in my own code)/no bug reports/no test cases that show this to
>> be a consistent issue. I'm perf
Le lundi 01 février 2010 à 23:58 +0100, "Martin v. Löwis" a écrit :
>
> Interestingly, the POSIX pthread_atfork documentation defines how you
> are supposed to do that: create an atfork handler set, and acquire all
> mutexes in the prepare handler. Then fork, and have the parent and child
> handle
On 01/02/2010 23:03, Reid Kleckner wrote:
On Mon, Feb 1, 2010 at 5:48 PM, Jesse Noller wrote:
Your reasonable argument is making it difficult for me to be irrational
about this.
No problem. :)
This begs the question - assuming a patch that clones the behavior of win32
for mult
Tres Seaver palladion.com> writes:
>
> Yup, but that's true for *any* POSIXy envirnnment, not just Python. The
> only sane non-exec mixture is to have a single-thread parent fork, and
> restrict spawning threads to the children.
The problem is that we're advocating multiprocessing as the soluti
On Feb 1, 2010, at 6:25 PM, Michael Foord
wrote:
On 01/02/2010 23:03, Reid Kleckner wrote:
On Mon, Feb 1, 2010 at 5:48 PM, Jesse Noller
wrote:
Your reasonable argument is making it difficult for me to be
irrational
about this.
No problem. :)
This begs the question - assuming a
>> The python I use (win32 2.6.2) does not complain if it cannot read
>> from or write to a .pyc; and thus it handles multiple python processes
>> trying to create .pyc files at the same time. Is the .zip case really
>> any different?
[ snip discussion of difficulty of writing a sharing-safe updat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Antoine Pitrou wrote:
> Tres Seaver palladion.com> writes:
>> Yup, but that's true for *any* POSIXy envirnnment, not just Python. The
>> only sane non-exec mixture is to have a single-thread parent fork, and
>> restrict spawning threads to the childr
On Mon, Feb 1, 2010 at 11:56 PM, Pablo Mouzo wrote:
> On Mon, Feb 1, 2010 at 10:23 PM, Paul Du Bois wrote:
> [...]
>> Sorry, I'm guilty of having assumed that the POSIX API has an
>> operation analogous to win32 CreateFile(GENERIC_WRITE, 0 /* ie,
>> "FILE_SHARE_NONE"*/).
>>
>> If shared-reader/si
2010/2/1 Collin Winter
> I believe these VMs would have little overlap. I cannot imagine that
> Unladen Swallow's needs have much in common with Stackless's, or with
> those of a hypothetical register machine to replace the current stack
> machine.
>
> Let's consider that last example in more det
On Mon, Feb 1, 2010 at 12:14 AM, "Martin v. Löwis" wrote:
>> Any help you could provide would be appreciated.
>
> Please use unified diffs in the future.
Duly noted.
> I'm -0 on this patch; it still has the negative, cautionary-patronizing
> tone ("Do not", "can be tricky", "be mindful"),
Thank
43 matches
Mail list logo
