On Thu, Dec 1, 2011 at 5:36 PM, Nick Coghlan wrote:
> On Thu, Dec 1, 2011 at 5:15 PM, Glyph wrote:
>> I think both of these documents point to a need for a recommended idiom for
>> discussing security, or at least common antipatterns, within the Python
>> documentation. I like the IETF's "securi
On Thu, Dec 1, 2011 at 5:15 PM, Glyph wrote:
> I think both of these documents point to a need for a recommended idiom for
> discussing security, or at least common antipatterns, within the Python
> documentation. I like the IETF's "security considerations" section, because
> it separates things
On Thu, Dec 1, 2011 at 4:10 PM, Raymond Hettinger
wrote:
> When updating the documentation, please don't go overboard with warnings.
> The docs need to be worded affirmatively -- say what a tool does and show
> how to use it correctly.
> See http://docs.python.org/documenting/style.html#affirmativ
On Dec 1, 2011, at 1:10 AM, Raymond Hettinger wrote:
> When updating the documentation, please don't go overboard with warnings.
> The docs need to be worded affirmatively -- say what a tool does and show how
> to use it correctly.
> See http://docs.python.org/documenting/style.html#affirmative-
On Nov 30, 2011, at 6:39 PM, Nick Coghlan wrote:
> On Thu, Dec 1, 2011 at 1:28 AM, PJ Eby wrote:
>> It doesn't help at all that I'm not really in a position to provide an
>> implementation, and the persons most likely to implement have been leaning
>> somewhat towards 382, or wanting to modify 4
When updating the documentation, please don't go overboard with warnings.
The docs need to be worded affirmatively -- say what a tool does and show how
to use it correctly.
See http://docs.python.org/documenting/style.html#affirmative-tone
The docs for the subprocess module currently have SEVEN w
I saw this, I believe it just exposes an STM primitive to user code.
It doesn't make use of STM for Python internals.
Explicit STM doesn't seem particularly useful for a language that
doesn't expose raw memory in its normal usage.
On Thu, Dec 1, 2011 at 4:41 PM, Nick Coghlan wrote:
> On Thu, Dec
On Thu, Dec 1, 2011 at 10:58 AM, Gregory P. Smith wrote:
> Azul has been using hardware transactional memory on their custom CPUs (and
> likely STM in their current x86 virtual machine based products) to great
> effect for their massively parallel Java VM (700+ cpu cores and gobs of ram)
> for ove
Azul has been using hardware transactional memory on their custom CPUs (and
likely STM in their current x86 virtual machine based products) to great
effect for their massively parallel Java VM (700+ cpu cores and gobs of
ram) for over 4 years. I'll leave it to the reader to do the relevant
searchi
On Thu, 1 Dec 2011 01:31:14 +1100
Matt Joiner wrote:
>
> However given advances in locking and garbage collection in the last
> decade, what attempts have been made recently to try these new ideas
> out? In particular, how unlikely is it that all the thread safe
> primitives, global contexts, and
I did see this, I'm not convinced it's only relevant to PyPy.
On Thu, Dec 1, 2011 at 2:25 AM, Benjamin Peterson wrote:
> 2011/11/30 Matt Joiner :
>> Given GCC's announcement that Intel's STM will be an extension for C
>> and C++ in GCC 4.7, what does this mean for Python, and the GIL?
>>
>> I've
On Thu, Dec 1, 2011 at 1:28 AM, PJ Eby wrote:
> It doesn't help at all that I'm not really in a position to provide an
> implementation, and the persons most likely to implement have been leaning
> somewhat towards 382, or wanting to modify 402 such that it uses .pyp
> directory extensions so that
> If this helps, I am +1, and I’m sure other devs will chime in. I think
> the feature is useful, and I prefer 402’s way to 382’s pyp directories.
If that's the obstacle to adopting PEP 382, it would be easy to revert
the PEP back to having file markers to indicate package-ness. I insist
on havin
Hi,
Thanks for the replies.
> At this point, though, before doing any more work on the PEP I'd
> like to have some idea of whether there's any chance of it being accepted.
> At this point, there seems to be a lot of passive, "Usenet nod syndrome"
> type support for it, but little active support.
> However given advances in locking and garbage collection in the last
> decade, what attempts have been made recently to try these new ideas
> out? In particular, how unlikely is it that all the thread safe
> primitives, global contexts, and reference counting functions be made
> __transaction_ato
On Sat, Nov 26, 2011 at 11:53 AM, Éric Araujo wrote:
> > Le 11/08/2011 20:30, P.J. Eby a écrit :
> >> At 04:39 PM 8/11/2011 +0200, Éric Araujo wrote:
> >>> I’ll just regret that it's not possible to provide a module docstring
> >>> to inform that this is a namespace package used for X and Y.
> >
2011/11/30 Matt Joiner :
> Given GCC's announcement that Intel's STM will be an extension for C
> and C++ in GCC 4.7, what does this mean for Python, and the GIL?
>
> I've seen efforts made to make STM available as a context, and for use
> in user code. I've also read about the "old attempts way ba
Given GCC's announcement that Intel's STM will be an extension for C
and C++ in GCC 4.7, what does this mean for Python, and the GIL?
I've seen efforts made to make STM available as a context, and for use
in user code. I've also read about the "old attempts way back" that
attempted to use finer gr
> Could be implemented as a command line command using "revsets"?.
> Propose a new revset to mercurial devels?
It *is* implemented as a command line command using "revsets".
The revset is
max(ancestors(branch("%s")))-outgoing("%s"))
where the first parameter is the branch that contains your chan
19 matches
Mail list logo
