On Mon, Feb 21, 2022 at 10:56 AM wrote:
> For what it's worth Cython does this for string concatenation to concatenate
> in place if possible (this optimization was copied from CPython). It could be
> disabled relatively easily if it became a problem (it's already CPython only
> and version che
On Mon, Feb 21, 2022 at 4:56 PM Terry Reedy wrote:
> We could say that the only refcounts with any meaning are 0, 1, and > 1.
Yeah, that should work.
-eric
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-
On Sat, Feb 19, 2022 at 12:46 AM Eric Snow wrote:
> Performance
> ---
>
> A naive implementation shows `a 4% slowdown`_.
> Several promising mitigation strategies will be pursued in the effort
> to bring it closer to performance-neutral. See the `mitigation`_
> secti
On Tue, Feb 22, 2022, 20:26 Larry Hastings wrote:
> Are these optimizations specifically for the PR, or are these
> optimizations we could apply without taking the immortal objects? Kind of
> like how Sam tried to offset the nogil slowdown by adding optimizations
> that we went ahead and added a
Responses inline below.
-eric
On Tue, Feb 22, 2022 at 7:22 PM Inada Naoki wrote:
> > For a recent example, see
> > https://mail.python.org/archives/list/python-dev@python.org/message/B77BQQFDSTPY4KA4HMHYXJEV3MOU7W3X/.
>
> It is not proven example, but just a hope at the moment. So option is
> fi
On Wed, Feb 23, 2022 at 9:16 AM Petr Viktorin wrote:
>>> But tp_dict is also public C-API. How will that be handled?
>>> Perhaps naively, I thought static types' dicts could be treated as
>>> (deeply) immutable, and shared?
>>
>> They are immutable from Python code but not from C (due to tp_dict).
On Wed, Feb 23, 2022 at 4:21 PM Antonio Cuni wrote:
> When refcheck=True (the default), numpy raises an error if you try to resize
> an array inplace whose refcnt > 2 (although I don't understand why > 2 and
> not > 1, and the docs aren't very clear about this).
>
> That said, relying on the exa
stable ABI extensions. All other changes are smaller.
Given the last round of discussion, I'm hoping this will be the last
round before we go to the steering council.
-eric
PEP: 683
Title: Immortal Objects, Using a Fixed Refcount
Author: Eric Snow , Eddie Elizondo
Discus
gh at the expense of cutting corners. Hence, we'll see how it goes.
The PEP text is included inline below. Thanks!
-eric
===
PEP: 684
Title: A Per-Interpreter GIL
Author: Eric Snow
Discussions-To: python-dev@python.org
Status: Draft
Type: Sta
On Mon, Feb 28, 2022 at 6:01 PM Eric Snow wrote:
> The updated PEP text is included below. The largest changes involve
> either the focus of the PEP (internal mechanism to mark objects
> immortal) or the possible ways that things can break on older 32-bit
> stable ABI extensions
Thanks for the feedback, Petr! Responses inline below.
-eric
On Wed, Mar 9, 2022 at 10:58 AM Petr Viktorin wrote:
> This PEP definitely makes per-interpreter GIL sound possible :)
Oh good. :)
> > PEP: 684
> > Title: A Per-Interpreter GIL
> > Author: Eric Snow
> >
On Wed, Mar 9, 2022 at 7:37 PM Carl Meyer wrote:
> > Note that Instagram isn't exactly using Cinder.
>
> This sounds like a misunderstanding somewhere. Instagram server is
> "exactly using Cinder" :)
:)
Thanks for clarifying, Carl.
> > I'll have to check if Cinder uses the pre-fork model.
>
>
responses inline
-eric
On Wed, Mar 9, 2022 at 8:23 AM Petr Viktorin wrote:
> "periodically reset the refcount for immortal objects (only enable this
> if a stable ABI extension is imported?)" -- that sounds quite expensive,
> both at runtime and maintenance-wise.
Are you talking just about "(on
On Fri, Jul 15, 2022 at 12:15 PM Barry Warsaw wrote:
> I agree that the experiment has proven successful enough that there’s more
> value at this point in consolidating discussions.
We've only been running this experiment since 2017(?) so maybe it's
too soon to say it's a success?
-eric
_
On Fri, Jul 15, 2022 at 5:21 AM Petr Viktorin wrote:
> The Steering Council would like to switch from python-dev to
> discuss.python.org.
This seems like a net win for the community so +1 from me. (For me
personally it amounts to disruption with little advantage, so I'd
probably be -0). However
On Mon, Jul 18, 2022 at 11:48 AM wrote:
> LLVM did the same recently (though they imported all previous messages from
> the mailinglist, thus making them searchable in discourse) [2 - announcement;
> 3 - retro], and by and large, I think it was a success.
>
> One of the comments in the retro was
On Thu, Jul 21, 2022 at 12:19 AM Stefan Behnel wrote:
> I'm actually reading python-dev, c.l.py etc. through Gmane, and have done
> that ever since I joined. Simply because it's a mailing list of which I
> don't need a local (content) copy, and wouldn't want one. Gmane seems to
> have a complete a
On Mon, Nov 28, 2022 at 6:45 PM Steven D'Aprano wrote:
> On Tue, Nov 29, 2022 at 01:34:54PM +1300, Greg Ewing wrote:
> > I got the impression that there were some internal language reasons
> > to want stable dicts, e.g. so that the class dict passed to __prepare__
> > preserves the order in which
On Tue, Nov 12, 2019 at 3:11 PM Victor Stinner wrote:
> Are you ok to modify internal C functions to pass explicitly tstate?
I'm also in favor (strongly)! (no surprises there)
The only concerns I've heard is that on some platforms there is a
measurable overhead once you hit a threshold of a spe
I agree with Mark on "for now I propose that we do absolutely
nothing". (I'll wait on a PEP for the rest of his points.) The
capability of PEP 523 (swapping in a different PyEval_EvalFrame()
impl.) is deep in the CPython runtime functionality. It is low-level,
highly impactful, and there-be-drag
On Sun, Apr 12, 2020 at 8:36 AM Hai Shi wrote:
> I notice some modules not in modules directory(for example: _warnings、marshal
> in python directory). Do we need port those modules to modules directory?
FWIW, this is something I've been meaning to look at for a while and
is relatively high on my
On Wed, Apr 15, 2020 at 2:12 AM Serhiy Storchaka wrote:
> Then it obviously should be different class than SimpleNamespace. There
> are too much differences between them, and they are used in different
> circumstances.
+1
Keep in mind that I added SimpleNamespace when implementing PEP 421,
to us
Hi all,
It was nice to speak with many of you at the online language summit
this week. It was the next best thing to seeing you all in person! :)
With the 3.9 feature freeze coming up I'm considering options for PEP
554. I'm hopeful to have a pronouncement from Antoine in the near
future. If t
On Fri, Apr 17, 2020 at 1:38 PM Brett Cannon wrote:
> Eric Snow wrote:
> > 1. merge PEP 554 into 3.9 even if per-interpreter GIL doesn't get into 3.9
> > (they get parallelism for free in 3.10)
> > 2. like 1, but mark the module as provisional until per-interpreter GI
On Fri, Apr 17, 2020 at 1:39 PM Victor Stinner wrote:
> I have concerns about shared data.
>
> The current implementation of CPython and subinterpreters still shares
> singletons. Moreover, I understand that the PEP proposes to first
> directly share PyObject between subinterpreters, like bytes ob
On Fri, Apr 17, 2020 at 1:39 PM Victor Stinner wrote:
> Sharing directly singletons like None can become a performance kill
> once subinterpreters will run in parallel:
> https://bugs.python.org/issue39511
>
> Mark Shannon summarized: "Having two CPUs write to the same cache line
> is a well known
On Fri, Apr 17, 2020 at 1:54 PM Victor Stinner wrote:
> Honestly, I don't think that we are far from being able to move the
> GIL lock per interpreter. But this change alone is useless, since we
> still have too many C extensions which are not ready for that:
Agreed. This is a big part of why I
On Fri, Apr 17, 2020 at 2:59 PM Nathaniel Smith wrote:
> I think some perspective might be useful here :-).
>
> The last time we merged a new concurrency model in the stdlib, it was asyncio.
>
> [snip]
>
> OTOH, AFAICT the new concurrency model in PEP 554 has never actually
> been used, and it isn
On Sat, Apr 18, 2020, 01:16 Antoine Pitrou wrote:
> On Fri, 17 Apr 2020 13:59:46 -0600
> Eric Snow wrote:
> > > For bytes or buffer objects, I understand that you propose to share
> > > the exact same PyObject objects between interpreters, at least in the
&g
On Sat, Apr 18, 2020 at 11:16 AM Antoine Pitrou wrote:
> * I do think a minimal synchronization primitive would be nice.
> Either a Lock (in the Python sense) or a Semaphore: both should be
> relatively easy to provide, by wrapping an OS-level synchronization
> primitive. Then you can recre
Thanks for the feedback, Antoine. I've responded inline below and
will be making appropriate changes to the PEP. One point I'd like to
reinforce before my comments is the PEP's emphasis on minimalism.
>From PEP 554:
This proposal is focused on enabling the fundamental capability of
mult
On Sat, Apr 18, 2020 at 6:50 PM Greg Ewing wrote:
> On 19/04/20 5:02 am, Antoine Pitrou wrote:
> > * How hard would it be, in the current implementation, to add buffering
> >to channels?
> >
> > * In the same vein, I think channels should allow adding readiness
> >callbacks
>
> Of these, I
On Mon, Apr 20, 2020 at 2:22 PM Eric Snow wrote:
> On Sat, Apr 18, 2020 at 11:16 AM Antoine Pitrou wrote:
> > * The "association" timing seems quirky and potentially annoying: an
> > interpreter only becomes associated with a channel the first time it
> > cal
On Mon, Apr 20, 2020 at 4:19 PM Greg Ewing wrote:
>
> On 21/04/20 8:29 am, Eric Snow wrote:
> > * Would a low-level channel implementation based on callbacks or locks
> > be better (simpler, faster, etc.) than one based on buffering?
>
> Depends on what you mean by &quo
On Mon, Apr 20, 2020 at 4:23 PM Eric Snow wrote:
> As I've gone to update the PEP for this I'm feeling less comfortable
> with changing it.
Also, the resulting text of the PEP makes it a little harder to follow
when an interpreter gets associated. However, this is partly an
frustrated, which is only
more frustrating because I respect you a lot and feel like your
feedback should be more helpful. I'm trying to moderate my responses,
but I expect some of my emotion may slip through. :/
On Mon, Apr 20, 2020 at 4:30 PM Nathaniel Smith wrote:
> On Fri, Apr 17, 20
On Tue, Apr 21, 2020 at 2:09 AM Antoine Pitrou wrote:
>
> On Mon, 20 Apr 2020 15:30:37 -0700
> Nathaniel Smith wrote:
> >
> > tl;dr: accepting PEP 554 is effectively a C API break, and will force
> > many thousands of people worldwide to spend many hours wrangling with
> > subinterpreter support.
Thanks for explaining that, Ronald. It sounds like a lot of the
effort would relate to making classes work. I have some comments
in-line below.
-eric
On Tue, Apr 21, 2020 at 2:34 AM Ronald Oussoren wrote:
> > On 21 Apr 2020, at 03:21, Eric Snow wrote:
> > Honest question
On Tue, Apr 21, 2020 at 3:10 AM Antoine Pitrou wrote:
> On Mon, 20 Apr 2020 19:21:21 -0600
> Eric Snow wrote:
> > Honest question: how many C extensions have process-global state that
> > will cause problems under subinterpreters? In other words, how many
> > already
On Tue, Apr 21, 2020 at 4:11 AM Greg Ewing wrote:
> On 21/04/20 8:34 pm, Ronald Oussoren via Python-Dev wrote:
> > As far as I understand proper support for subinterpreters also requires
> > moving away from static type definition to avoid sharing objects > between
> > interpreters (that is, use
On Tue, Apr 21, 2020 at 8:54 AM Paul Moore wrote:
>
> On Tue, 21 Apr 2020 at 15:31, Eric Snow wrote:
> > Here are the options for handling non-compliant extension modules:
> >
> > 1. do nothing (extensions may break in ways that are hard for users to
> > deal with)
On Tue, Apr 21, 2020 at 2:18 AM Antoine Pitrou wrote:
> On Tue, 21 Apr 2020 18:27:41 +1200
> Greg Ewing wrote:
> > On 21/04/20 10:23 am, Eric Snow wrote:
> > > with the current spec channels get automatically closed
> > > sooner, effectively as soon as all wr
On Tue, Apr 21, 2020 at 1:39 AM Greg Ewing wrote:
> I don't get this whole business of channels being associated
> with interpreters, or why there needs to be a distinction
> between release() and close().
>
> To my mind, a channel reference should be like a file
> descriptor for a pipe. When you'
On Tue, Apr 21, 2020 at 7:25 AM Victor Stinner wrote:
> Would it make sense to start by adding the module as a private
> "_subinterpreters" module but document it? The "_" prefix would be a
> reminder that "hey! it's experimental, there is a no backward
> compatibility warranty there".
I would ex
On Tue, Apr 21, 2020 at 10:33 AM Antoine Pitrou wrote:
> On Tue, 21 Apr 2020 09:36:22 -0600
> Eric Snow wrote:
> > Yeah, I had that same realization yesterday and it didn't change after
> > sleeping on it. I suppose the only question I have left is if there
> >
FYI, I'm not ignoring you. :) Life intervened. I'll respond in the
next day or two.
-eric
On Tue, Apr 21, 2020 at 10:42 AM Mark Shannon wrote:
>
> Hi,
>
> I'm generally in favour of PEP 554, but I don't think it is ready to be
> accepted in its current form.
>
> My main objection is that witho
On Tue, Apr 21, 2020 at 11:31 PM Greg Ewing wrote:
> To put it another way, the moment you start using subinterpreters,
> the set of extension modules you are able to use will shrink
> *enormously*.
Very true but we have to start somewhere.
> And if I understand correctly, you won't get any nice
On Tue, Apr 21, 2020 at 10:24 AM Sebastian Berg
wrote:
> On Tue, 2020-04-21 at 16:21 +0200, Victor Stinner wrote:
> > I fail to follow your logic. When the asyncio PEP was approved, I
> > don't recall that suddenly the whole Python community started to
> > rewrite all projects to use coroutines ev
On Tue, Apr 21, 2020 at 11:17 AM Sebastian Berg
wrote:
> Maybe one of the frustrating points about this criticism is that it
> does not belong in this PEP. And that is actually true! I
> wholeheartedly agree that it doesn't really belong in this PEP itself.
>
> *But* the existence of a document de
On Wed, Apr 22, 2020 at 2:43 AM Ronald Oussoren wrote:
> My mail left out some important information, sorry about that.
No worries. :)
> PyObjC is a two-way bridge between Python and Objective-C. One half of this
> is that is bridging Objective-C classes (and instances) to Python. This is
> fa
On Sun, Apr 26, 2020 at 2:21 PM Carl Shapiro wrote:
> While this PEP may not create a maintenance burden for CPython, it
> does have the effect of raising the complexity bar for an alternative
> Python implementation.
FWIW, I did reach out to the various major Python implementation about
this and
On Wed, Apr 22, 2020 at 2:13 AM Kyle Stanley wrote:
> If you'd like an example format for marking a section of the docs as
> provisional w/ reST, something like this at the top should suffice
> (with perhaps something more specific to the subinterpreters module):
>
>
> .. note::
> This section
On Tue, Apr 21, 2020 at 11:21 PM Greg Ewing wrote:
> What I'm suggesting is that close() should do what the
> PEP defines release() as doing, and release() shouldn't
> exist.
>
> I don't see why an interpreter needs the ability to close
> a channel for any *other* interpreter. There is no such
> a
On Tue, Apr 21, 2020 at 10:42 AM Mark Shannon wrote:
> I'm generally in favour of PEP 554, but I don't think it is ready to be
> accepted in its current form.
Yay(ish)! :)
> My main objection is that without per-subinterpeter GILs (SILs?) PEP 554
> provides no value over threading or multi-proce
On Wed, Apr 22, 2020 at 7:40 PM Kyle Stanley wrote:
> If there's not an implementation detail that makes this impractical,
> I'd like to give my +1 on the `Interpreter.run()` method returning
> values. From a usability perspective, it seems incredibly convenient
> to have the ability to call a fun
Thanks, Mark. Responses are in-line below.
-eric
On Wed, Apr 29, 2020 at 6:08 AM Mark Shannon wrote:
> You can already do CSP with multiprocessing, plus you get true parallelism.
> The question the PEP needs to answer is "what do sub-interpreters offer
> that other forms of concurrency don't of
On Wed, Apr 29, 2020 at 1:52 AM Paul Moore wrote:
> One thing that isn't at all clear to me here is that when you say
> "Subinterpreters run all Python code", do you *just* mean the core
> language? Or the core language plus all builtins? Or the core
> language, builtins and the standard library?
On Wed, Apr 29, 2020 at 6:27 AM Julien Salort wrote:
> If your proposal leads to an intelligible actual error, and a clear
> warning in the documentation, instead of a silent crash, this sounds
> like progress, even for those packages which won't work on
> subinterpreters anytime soon...
That's h
Thanks for the great insights into PyObjC!
On Wed, Apr 29, 2020 at 9:02 AM Ronald Oussoren wrote:
> I don’t know how much the move of global state to per-interpreter state
> affects extensions, other than references to singletons and static types.
That's the million dollar question. :)
FYI, on
Thanks for the thoughtful post! I'm going to address some of your
comments here and some in a separate discussion in the next few days.
On Wed, Apr 29, 2020 at 10:36 AM Sebastian Berg
wrote:
> While I still think it is probably not part of PEP 554 as such, I guess
> it needs a full blown PEP on
On Wed, Apr 29, 2020, 22:05 Greg Ewing wrote:
> > Furthermore, IMHO "release" is better at communicating the
> > per-interpreter nature than "close".
>
> Channels are a similar enough concept to pipes that I think
> it would be confusing to have "close" mean "close for all
> interpreters". Everyo
the PR is ready (or
very close to ready) for pronouncement. Thanks again to all.
-eric
--
PEP: 554
Title: Multiple Interpreters in the Stdlib
Author: Eric Snow
BDFL-Delegate: Antoine Pitrou
Status: Draft
Type: Standards Track
Content-Type: text
On Mon, May 4, 2020 at 11:30 AM Eric Snow wrote:
> Further feedback is welcome, though I feel like the PR is ready (or
> very close to ready) for pronouncement. Thanks again to all.
oops
s/the PR is ready/the PEP is ready/
-eric
___
Pyth
On Mon, May 4, 2020 at 1:22 PM Paul Moore wrote:
> One thing I would like to see is a comment confirming that as part of
> the implementation, all stdlib modules will be made
> subinterpreter-safe.
Yeah, I'd meant to put a note. I'll add one. Thanks!
-eric
_
On Mon, May 4, 2020 at 11:30 AM Eric Snow wrote:
> Further feedback is welcome, though I feel like the PR is ready (or
> very close to ready) for pronouncement. Thanks again to all.
FYI, after consulting with the steering council I've decided to change
the target release to 3.10, whe
On Wed, May 6, 2020 at 2:25 PM Jeff Allen wrote:
> Many thanks for working on this so carefully for so long. I'm happy to see
> the per-interpreter GIL will now be studied fully before final commitment to
> subinterpreters in the stdlib. I would have chipped in in those terms to the
> review, b
On Thu, May 7, 2020 at 2:50 AM Emily Bowman wrote:
> While large object copies are fairly fast -- I wouldn't say trivial, a
> gigabyte copy will introduce noticeable lag when processing enough of them --
> the flip side of having large objects is that you want to avoid having so
> many copies t
On Fri, May 29, 2020 at 12:16 PM Python tracker wrote:
> ACTIVITY SUMMARY (2020-05-22 - 2020-05-29)
> Python tracker at https://bugs.python.org/
>
> To view or respond to any of the issues listed below, click on the issue.
> Do NOT respond to this message.
>
> Issues counts and deltas:
> open
On Wed, Jun 3, 2020 at 7:12 AM Mark Shannon wrote:
> The size of the C API, as measured by `git grep PyAPI_FUNC | wc -l` has
> been steadily increasing over the last few releases.
>
> 3.5 1237
> 3.6 1304
> 3.7 1408
> 3.8 1478
> 3.9 1518
>
>
> For reference the 2.7 branch has "o
On Fri, Jun 12, 2020 at 2:49 AM Mark Shannon wrote:
> The overhead largely comes from what you do with the process. The
> additional cost of starting a new interpreter is the same regardless of
> whether it is in the same process or not.
FWIW, there's more to it than that:
* there is some overhe
On Wed, Jun 17, 2020 at 11:42 AM Emily Bowman wrote:
> So most likely there wouldn't be any way to share something like a bytearray
> or another
> buffer interface-compatible type for some time. That's too bad, I was hoping
> to have
> shared arrays that I could put a memoryview on in each threa
On Fri, Jul 3, 2020, 09:18 Antoine Pitrou wrote:
> I think what you describe as "the usual procedure" isn't as usual as
> you think.
>
+1
Also, keep in mind that PEPs are a tool for the decision maker (i.e. BDFL
delegate). Effectively, everything else is convention. The process
usually invol
On Fri, Jul 3, 2020, 12:40 Eric Snow wrote:
> Also, keep in mind that PEPs are a tool for the decision maker (i.e.
> BDFL delegate). Effectively, everything else is convention. The process
> usually involves community feedback, but has never been community-driven.
> All this has
First appeared in docs for 2.6 (October 02, 2008). Not sure if that is when it
first because constrained this way.
http://docs.python.org/library/constants.html?highlight=__debug__#__debug__
-eric
-Original Message-
From: python-dev-bounces+esnow=verio@python.org
[mailto:python-de
Actually, what is the problem with having all decorators add a __decorated__ to
the function that ultimately gets returned, pointing to the function they
decorated? I guess I never saw that discussion. Perhaps set it to None when
the decorator is the same as the decorated (no wrapping involved
13, 2010 10:07 AM
To: Eric Snow
Cc: python-dev@python.org
Subject: Re: [Python-Dev] Proposed tweaks to functools.wraps
On Sat, Aug 14, 2010 at 1:01 AM, Eric Snow wrote:
> Actually, what is the problem with having all decorators add a __decorated__
> to the function that ultimately gets re
I see your point, but doesn't python-list already fill the role you indicate
may be diminished? Seems like the new list is meant to fill a different
need. Perhaps one concern would be over-use of the mentoring list when
someone would be fine with python-list. I just don't see people turning
away
ing text editors,
> syntax highlighters, etc; insert usual Alan Perlis quote about syntactic
> sugar causing cancer of the semicolon)
>
> Also, insert usual comments about the need to think about how
> non-CPython implementations of Python would go about implementing such
> idea
On Sat, Apr 16, 2011 at 3:54 PM, Antoine Pitrou wrote:
>
> Hmm, what's the difference between "the Python stdlib" and "CPython's
> stdlib"?
>
> I'm also not sure how you would enforce that anyway. If it means
> using ctypes to interface with system C libraries, I'm -10 on it :)
>
>
Sounds like Br
On May 9, 2011 6:59 AM, "Eli Bendersky" wrote:
>
> Hi all,
>
> It's a known Python gotcha (*) that the following code:
>
> x = 5
> def foo():
> print(x)
> x = 1
> print(x)
> foo()
>
> Will throw:
>
>UnboundLocalError: local variable 'x' referenced before assignment
>
> On the u
On Mon, Jun 27, 2011 at 8:11 PM, Ben Finney wrote:
> Rob Cliffe writes:
>
>> 'function attributes' ? 'def attributes' ?
>
> -1. They don't have to be functions, and hence don't have to be created
> by 'def'.
>
>> Or just stick with method attributes' ?
>
> "callable attributes" describes exactly
On Tue, Jun 28, 2011 at 5:35 AM, Michael Foord
wrote:
>
> Well, they're *usually* implemented as methods and backed by a real instance
> attribute. Usually (but not always) it makes more sense (IME) to group them
> with methods. The fact that they're *accessed* as an attribute is the
> uninteresti
On Tue, Jun 28, 2011 at 7:20 AM, Steven D'Aprano wrote:
> Michael Foord wrote:
>
>> What do you mean by "instances can have methods as instance attributes"?
>> Once you attach a bound method directly to an instance it becomes a slightly
>> different beast I think. (On top of which that is pretty r
On Wed, Jun 29, 2011 at 10:05 PM, Jesse Noller wrote:
> I've posted a more expansive entry on my blog:
> http://jessenoller.com/2011/06/29/announcing-the-new-speed-python-org-machine/
>
> But the short version, that as discussed at the VM and language
> summit, we now have a hosted machine dedicat
On Wed, Jul 20, 2011 at 12:03 PM, Kerrick Staley wrote:
> On Wed, Jul 20, 2011 at 3:28 AM, Nick Coghlan wrote:
>> Done: http://www.python.org/dev/peps/pep-0394/
>
> Quick question: When I do "svn up", it doesn't show any changes. Has
> it been switched over to Mercurial recently?
http://hg.pytho
On Wed, Jul 20, 2011 at 11:04 AM, P.J. Eby wrote:
> Hm. Here's another variant that might be easier to implement (even in C),
> and could offer some other advantages as well.
>
> Suppose we replace the sys.virtual_packages set() with a sys.virtual_paths
> dict(): a dictionary that maps from modul
On Wed, Jul 20, 2011 at 2:44 PM, P.J. Eby wrote:
> At 01:35 PM 7/20/2011 -0600, Eric Snow wrote:
>>
>> This is a really nice solution. So a virtual package is not imported
>> until a submodule of the virtual package is successfully imported
>
> Correct...
>
>&g
On Wed, Jul 20, 2011 at 7:52 PM, Nick Coghlan wrote:
> Even better would be for these (and sys.path) to be list subclasses
> that did the right thing under the hood as Glenn suggested. Code that
> *replaces* rather than modifies these attributes would still
> potentially break virtual packages, bu
The documentation[1] doesn't say, but the implementation of the imp
module makes me wonder if sys.modules was not meant to be replaceable.
No doubt this has to do with its tie to the interpreter's modules
dict. I ran into this doing "sys.modules = sys.modules.copy()" to
protect the actual sys.mod
On Sat, Jul 23, 2011 at 10:55 PM, Benjamin Peterson wrote:
> 2011/7/23 Eric Snow :
>> The documentation[1] doesn't say, but the implementation of the imp
>> module makes me wonder if sys.modules was not meant to be replaceable.
>> No doubt this has to do with its tie to
On Sun, Jul 24, 2011 at 12:54 AM, Nick Coghlan wrote:
> On Sun, Jul 24, 2011 at 3:05 PM, Eric Snow
> wrote:
>> Are there other objects in the interpreter state that are exposed in
>> sys that would have the same problem?
>
> Rebinding (rather than mutating) any globa
On Wed, Aug 10, 2011 at 10:19 AM, Brian Curtin wrote:
> On Wed, Aug 10, 2011 at 11:14, Vlad Riscutia wrote:
>>
>> Removing GIL is interesting work and probably multiple people are willing
>> to contribute. Threading and synchronization is a deep topic and it might be
>> that if just one person to
On Tue, Sep 27, 2011 at 12:20 PM, Ethan Furman wrote:
> Good points. So how about:
>
> some_name_here(start, stop, *, step=None, count=None)
>
> ? I personally would use the step value far more often than the count
> value.
Let's call it xrange() or maybe range_ex().But seriously,
here's an
On Fri, Oct 7, 2011 at 4:18 AM, Glyph wrote:
> On Oct 7, 2011, at 5:10 AM, Stephen J. Turnbull wrote:
>
> The principle here is "ran as root" without further explanation is a
> litmus test for "not bothering about security", even today. It's
> worth asking for explanation, or at least a comment t
Guido posted this on Google+:
> IEEE/ISO are working on a draft document about Python vulunerabilities:
> http://grouper.ieee.org/groups/plv/DocLog/300-399/360-thru-379/22-WG23-N-0372/n0372.pdf
> (in the context of a larger effort to classify vulnerabilities in all
> languages: ISO/IEC TR 24772
re-sending with subject :)
On Mon, Dec 12, 2011 at 2:44 PM, Eric Snow wrote:
> Guido posted this on Google+:
>
>> IEEE/ISO are working on a draft document about Python vulunerabilities:
>> http://grouper.ieee.org/groups/plv/DocLog/300-399/360-thru-379/22-WG23-N-0372/n03
On Wed, Dec 28, 2011 at 6:28 PM, Michael Foord
wrote:
> Hello all,
>
> A paper (well, presentation) has been published highlighting security
> problems with the hashing algorithm (exploiting collisions) in many
> programming languages Python included:
>
>
> http://events.ccc.de/congress
On Wed, Jan 4, 2012 at 12:59 AM, Maciej Fijalkowski wrote:
> On Wed, Jan 4, 2012 at 12:02 AM, Bill Janssen wrote:
>> Christian Heimes wrote:
>>
>>> Am 29.12.2011 12:13, schrieb Mark Shannon:
>>> > The attack relies on being able to predict the hash value for a given
>>> > string. Randomising the
2012/1/5 Charles-François Natali :
> Hi,
>
> Issue #13697 (http://bugs.python.org/issue13697) deals with a problem
> with the Python version of threading.RLock (a signal handler which
> tries to acquire the same RLock is called right at the wrong time)
> which doesn't affect the C version.
> Whethe
On Tue, Jan 10, 2012 at 6:09 PM, "Martin v. Löwis" wrote:
> IOW, I think it is all fine the way it is. Typically, somebody answers
> quickly. In this case, *two* people answered the same, which
> a) really gets the message through, and
> b) suggests that people are not too tired in actually typing
401 - 500 of 572 matches
Mail list logo
