ay since 2003. PyPy
would not have gotten as far as it has without the coding, feedback
and general support from numerous people.
The PyPy release team,
Armin Rigo, Maciej Fijalkowski and Amaury Forgeot d'Arc
Together with
Antonio Cuni, Carl Friedrich Bolz, Holger Krekel and
Sa
Hi,
On Fri, Jun 25, 2010 at 05:27:52PM -0600, Maciej Fijalkowski wrote:
>python setup.py build
As corrected on the blog (http://morepypy.blogspot.com/), this line
should read:
pypy setup.py build
Armin.
___
Python-Dev mailing list
Python-Dev
Hi,
On Tue, Jul 04, 2006 at 04:49:13PM -0700, Neal Norwitz wrote:
> On 7/4/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > From actual users of
> > the language I get more complaints about the breakneck speed of
> > Python's evolution than about the brokenness of the current language.
I'
Hi Brett,
On Tue, Jul 11, 2006 at 06:05:21PM -0700, Brett Cannon wrote:
> It is the last point in the first paragraph on time.strftime() discussing
> what changed in Python 2.4 as to what the change was. It's also in
> Misc/NEWS . Basically the guy didn't read the release notes or the docs to
>
Hi Jeroen,
On Thu, Jul 13, 2006 at 02:02:22PM +0200, Jeroen Ruigrok van der Werven wrote:
> He doesn't specifically need the builtin types to be extendable. It's
> just nice to be able to define a single class in multiple modules.
There are various simple ways to do this; the one I'm using from t
Hi Bob,
On Thu, Jul 13, 2006 at 12:58:08AM -0700, Bob Ippolito wrote:
> > @main
> > def whatever():
> > ...
>
> It would probably need to be called something else, because main is
> often the name of the main function...
Ah, but there is theoretically no name clash here :-)
@main
Hi Brett,
On Wed, Jul 19, 2006 at 03:35:45PM -0700, Brett Cannon wrote:
> I also plan to rewrite the import machinery in pure Python.
http://codespeak.net/svn/pypy/dist/pypy/module/__builtin__/importing.py
A bientot,
Armin
___
Python-Dev mailing list
Hi,
On Sat, Jul 22, 2006 at 12:33:45PM +1000, Nick Coghlan wrote:
> Agreed, but there's more to doing that than just writing down the O() implied
> by the current CPython implementation - it's up to Guido to decide which of
> the constraints are part of the language definition, and which are
>
Re-hi,
On Wed, Jul 19, 2006 at 03:35:45PM -0700, Brett Cannon wrote:
> http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717&view=log.
I'm not sure I understand what you propose to fix holes like
constructors and __subclasses__: it seems that you want to remo
Hi Brett,
On Sat, Jul 22, 2006 at 10:33:19AM -0700, Brett Cannon wrote:
> Thanks for the link, Armin. Since you guys don't have the import
> restrictions the CPython version would have and just have different coding
> needs for RPython obviously I can't just do a blind copy. But I will
> definit
Hi David, hi Brett,
On Sun, Jul 23, 2006 at 02:18:48AM +0100, David Hopwood wrote:
> If I understand correctly, the proposal is that any incompatible changes
> to the language would apply only in "sandboxed" interpreters. So there is
> no reason why support for these couldn't go into the main bran
Hi Giovanni,
On Sun, Jul 23, 2006 at 03:30:50PM +0200, Giovanni Bajo wrote:
> I'm not sure big-O tells the whole truth. For instance, do we want to allow
> an implementation to use a hash table as underlying type for a list? It
> would match big-O requirements, but would still be slower than a pla
Hi,
On Thu, Jul 27, 2006 at 03:39:39AM -0400, Sylvain Fourmanoit wrote:
> Having JSON there would indeed be nice: In fact, I recall being initially
> surprised it was not supported by the standard library.
>
> But is there a need to choose? Why not have both? The miniconf approach
> has its adv
Hi Phillip,
On Wed, Jul 26, 2006 at 02:40:27PM -0400, Phillip J. Eby wrote:
> If we don't revert it, there are two ways to fix it. One is to just change
> PEP 302 so that the behavior is unbroken by definition. :) The other is
> to actually go ahead and fix it by adding PathImporter and NullI
Hi David,
Your proposal is too vague to be useful. In Python I would not feel
that any compiler-enforced restrictions are going to be too restrictive,
and so I believe that your approach is not viable, but I cannot give you
many concrete examples of why before you come up with a more concrete
spe
Hi Michael,
On Thu, Jul 27, 2006 at 12:46:04PM +0100, Michael Foord wrote:
> > leaves for a safe and cross-version dumper/loader for simple objects
> > using the Python syntax. In the same spirit, maybe it could be slightly
> > re-oriented towards a dumper/loader for more than config files; for
>
Hi,
There is an oversight in the design of __index__() that only just
surfaced :-( It is responsible for the following behavior, on a 32-bit
machine with >= 2GB of RAM:
>>> s = 'x' * (2**100) # works!
>>> len(s)
2147483647
This is because PySequence_Repeat(v, w) works by apply
Hi Guido,
On Fri, Jul 28, 2006 at 11:31:09AM -0700, Guido van Rossum wrote:
> No time to look through the code here, but IMO it's acceptable (at
> least for 2.5) if (2**100).__index__() raises OverflowError, as long
> as x[:2**100] silently clips. __index__() is primarily meant to return
> a value
Hi,
On Thu, Aug 03, 2006 at 07:53:11PM +0200, M.-A. Lemburg wrote:
> > I though I'd heard (from Guido here or on the py3k list) that it was only
> > 1 < u'abc' that would raise an exception, and that 1 == u'abc' would still
> > evaluate to False. Did I misunderstand?
>
> Could be that I'm wron
Hi all,
The 2.5 change of id() to return positive ints-or-longs is likely to
cause quite some breakage in user programs that erroneously implemented
custom __hash__() functions returning a value based on an id(). This
was discussed a few times already but it showed up again as a bug report
(#1536
Hi Martin,
On Tue, Aug 08, 2006 at 11:14:56PM +0200, "Martin v. L?wis" wrote:
> - h = PyInt_AsLong(res);
> + if (PyLong_Check(res))
> + h = res->ob_type->tp_hash(res);
This bug will keep showing up forever :-) It's unsafe against a user
subclassi
Hi,
On Thu, Aug 10, 2006 at 09:11:42PM +0200, "Martin v. L?wis" wrote:
> I'm in favour of having this __eq__ just return False. I don't think
> the warning is necessary, (...)
+1
Armin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
Hi,
On Thu, Aug 10, 2006 at 02:36:16PM -0700, Guido van Rossum wrote:
> > On Thu, Aug 10, 2006 at 09:11:42PM +0200, "Martin v. L?wis" wrote:
> > > I'm in favour of having this __eq__ just return False. I don't think
> > > the warning is necessary, (...)
> >
> > +1
>
> Can you explain why you beli
Hi Neal,
On Wed, Aug 16, 2006 at 10:26:09PM -0700, Neal Norwitz wrote:
> @@ -2367,7 +2374,9 @@
> compiler_use_next_block(c, end);
> if (!compiler_push_fblock(c, FINALLY_END, end))
> return 0;
> + c->c_in_finally = 1;
> VISIT_SEQ(c, stmt, s->v.TryFinally.finalbod
Hi Tim,
On Sat, Aug 26, 2006 at 08:37:46PM -0400, Tim Peters wrote:
> [Thomas Wouters]
> > Why not just "... && x == LONG_MIN"?
> it's better (when possible) not to tie the code to that `x` was
> specifically declared as type "long" (e.g., just more stuff that will
> break if Python decides to ma
Hi all,
There are more cases of signed integer overflows in the CPython source
code base...
That's on a 64-bits machine:
[GCC 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)] on linux2
abs(-sys.maxint-1) == -sys.maxint-1
I'd expect the same breakage everywhere when GCC 4.2 is used. Note t
Hi Fabio,
On Sun, Sep 17, 2006 at 03:38:42PM -0300, Fabio Zadrozny wrote:
> I've been playing with the new features and there's one thing about
> the new relative import that I find a little strange and I'm not sure
> this was intended...
My (limited) understanding of the motivation for relative
Hi Anthony,
On Thu, Sep 21, 2006 at 09:12:03PM +1000, Anthony Baxter wrote:
> Thanks to everyone for helping make 2.5 happen. It's been a long slog there,
> but I think we can all be proud of the result.
Thanks for the hassle! I've got another bit of it for you, though. The
freezed 2.5 documen
Hi Guido,
On Thu, Sep 21, 2006 at 07:22:04AM -0700, Guido van Rossum wrote:
> sys.path exists to stitch together the toplevel module/package
> namespace from diverse sources.
>
> Import hooks and sys.path hackery exist so that module/package sources
> don't have to be restricted to the filesystem
Hi Brett,
On Wed, Sep 27, 2006 at 02:11:30PM -0700, Brett Cannon wrote:
> is so bad that it is worth trying to re-implement the import semantics in
> pure Python or if in the name of time to just work with the C code.
In the name of time, sanity and usefulness, rewriting the expected
semantics in
Hi Raymond,
On Fri, Oct 06, 2006 at 08:48:15AM -0700, Raymond Hettinger wrote:
> No need to backport. Py_TPFLAGS_DEFAULT implies
> Py_TPFLAGS_HAVE_WEAKREFS.
>
>
> The change was for clarity -- most things that have the weakref slots
> filled-in will also make the flag explicit -- that makes it
Hi Fredrik,
On Wed, Oct 11, 2006 at 12:35:23PM +0200, Fredrik Lundh wrote:
> NoddyType = PyType_Setup("noddy.Noddy", sizeof(Noddy));
It doesn't address the problem Martin explained (you can put neither
NULLs nor stubs in tp_xxx fields that are beyond the C extension
module's sizeof(Nobby)).
Hi Fredrik,
On Fri, Oct 13, 2006 at 11:22:09AM +0200, Fredrik Lundh wrote:
> > > static PyTypeObject NoddyType;
> > static PyTypeObject *NoddyType;
>
> yeah, that's a silly typo.
Ah, then ignore my previous remark.
Armin
___
Python-Dev maili
Hi Travis,
On Fri, Oct 27, 2006 at 02:05:31PM -0600, Travis E. Oliphant wrote:
> This PEP proposes adapting the data-type objects from NumPy for
> inclusion in standard Python, to provide a consistent and standard
> way to discuss the format of binary data.
How does this compare with
Hi Martin,
On Sat, Nov 04, 2006 at 04:47:37PM +0100, "Martin v. L?wis" wrote:
> Patch #1346572 proposes to also search for .pyc when OptimizeFlag
> is set, and for .pyo when it is not set. The author argues this is
> for consistency, as the zipimporter already does that.
My strong opinion on the
Hi Steven,
On Wed, Nov 22, 2006 at 11:48:44PM -0700, Steven Bethard wrote:
> (... pyc files ...)
> For people wanting to ship just bytecode, the cached
> .pyc files could be renamed to .py files and then those could be
> shipped and imported.
Yuk! Not renamed to .py files. Distributing .py file
Hi Anthony,
On Wed, Nov 29, 2006 at 12:53:14AM +1100, Anthony Baxter wrote:
> > python2.4 distutils is excluded by default.
>
> I still have no idea why this was one - I was also one of the people
> who jumped up and down asking Debian/Ubuntu to fix this idiotic
> decision.
I could not agree m
Hi,
On Wed, Nov 29, 2006 at 07:39:25AM -0800, Guido van Rossum wrote:
> This seems a bug. In revision 36714 by Raymond Hettinger, the
> restriction that locals be a dict was relaxed to allow any mapping.
Mea culpa, I thought I reviewed this patch at the time.
Fixed in r52862-52863.
A bientot,
Hi Andrew,
On Fri, Dec 01, 2006 at 03:27:09PM +1100, Andrew Bennetts wrote:
> In both the current Debian and Ubuntu releases, the "python2.4" binary package
> includes distutils.
Ah, good. This must be a relatively recent change. I'm not a Debian
user, but merely a user that happens to have to
Hi Andrew,
On Fri, Dec 01, 2006 at 03:27:09PM +1100, Andrew Bennetts wrote:
> In both the current Debian and Ubuntu releases, the "python2.4" binary package
> includes distutils.
Ah, distutils are distributed in the base package now, but not the
'config' subdirectory of a standard library's norma
Hi Martin,
On Sun, Dec 03, 2006 at 07:56:34PM +0100, "Martin v. L?wis" wrote:
> People use distutils for other purposes today as well, and these
> purposes might be supported now.
OK, makes some kind of sense. I suppose (as you point out in another
thread) that the issue is that distros generall
Hi all,
=
PyPy Leysin Winter Sports Sprint (8-14th January 2007)
=
.. image:: http://www.ermina.ch/002.JPG
The next PyPy spr
Hi Walter,
On Wed, Dec 13, 2006 at 05:57:16PM +0100, Walter D?rwald wrote:
> I tried to reimplement weakref.WeakValueDictionary as a subclass of
> dict. The test passes except for one problem: To compare results
> test_weakref.py converts a weakdict to a real dict via dict(weakdict).
> This no lon
Hi Paul,
On Wed, Jan 10, 2007 at 11:10:10PM +, Paul Moore wrote:
> How many other projects/packages anticipate *not* migrating to Py3K, I wonder?
FWIW: Psyco.
Armin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
Hi Tim,
On Fri, Jan 19, 2007 at 08:33:23PM -0500, Tim Peters wrote:
> >>> decimal.Decimal(-1) % decimal.Decimal("1e100")
> Decimal("-1")
BTW - isn't that case in contradiction with the general Python rule that
if b > 0, then a % b should return a number between 0 included and b
excluded? We try
Hi Tim,
On Sun, Jan 21, 2007 at 09:08:18PM -0500, Tim Peters wrote:
> >BTW - isn't that case in contradiction with the general Python rule that
> >if b > 0, then a % b should return a number between 0 included and b
> >excluded?
>
> Sure.
You're not addressing my point, though, so I was probably
Hi Tim,
On Tue, Jan 23, 2007 at 05:14:29PM -0500, Tim Peters wrote:
> For some reason `decimal` implemented __mod__ as the proposed
> standard's "remainder" operation. That's the immediate source of your
> surprise. IMO `decimal` should not have implemented __mod__ at all,
> as Python's number-t
Hi Martin,
On Sun, Feb 11, 2007 at 07:09:29PM +0100, "Martin v. L?wis" wrote:
> > hacks into the core were complicated and he didn't even think
> > integration was worth it.
>
> With emphasis on the latter. Christian never proposed (to my knowledge)
> that Stackless should be integrated. Of cours
Hi,
On Mon, Feb 12, 2007 at 12:38:27AM -0700, Neil Toronto wrote:
>obj.*str_expression
x = *('variable%d' % n)
f(a, b, *('keyword%d' % n) = c)
class *('33strangename'):
pass
def *(funcname)(x, y, *(argname), *args, **kwds):
pass
import *modname as mymo
Hi Michael,
On Tue, Feb 13, 2007 at 11:55:46PM +, Michael Foord wrote:
> > x = *('variable%d' % n)
> > f(a, b, *('keyword%d' % n) = c)
> > class *('33strangename'):
> > pass
> > def *(funcname)(x, y, *(argname), *args, **kwds):
> > pass
> > import *modname a
Hi Adam,
On Thu, Feb 15, 2007 at 06:17:03AM -0700, Adam Olsen wrote:
> > E.g. have a wait(events = [], timeout = -1) method would be sufficient
> > for most cases, where an event would specify
>
> I agree with everything except this. A simple function call would
> have O(n) cost, thus being unac
Hi Jeremy,
On Tue, Feb 27, 2007 at 07:29:50PM +0100, jeremy.hylton wrote:
> Removed:
>python/trunk/Lib/test/crashers/modify_dict_attr.py
> Modified:
>python/trunk/Lib/test/test_descr.py
>python/trunk/Objects/typeobject.c
> Log:
> Add checking for a number of metaclass error conditions.
Hi Collin,
On Wed, Mar 07, 2007 at 11:53:45PM -0600, Collin Winter wrote:
> bool() and abs() aren't syntax, so I would never look in operator.
abs() is not syntax but bool() is part of every syntactic construction
that takes a truth value argument (if, while, and, ...)
A bientot,
Armin
___
Hi Collin,
On Mon, Mar 12, 2007 at 11:19:26AM -0500, Collin Winter wrote:
> iter() is part of every syntactic construction that takes an iterator
> argument (for, listcomps, gencomps, ...). Should it go in operator as
> well?
Historically, things that have a slot go in 'operator'. So that would
Hi Martin,
On Mon, Mar 12, 2007 at 11:50:17PM +0100, "Martin v. L?wis" wrote:
> Does distutils support this kind of setup? Modules/Setup?
distutils does, and I can find many projects which require a combination
of C and Python modules being organized as a single package with the
extension modules
Hi Martin,
On Wed, Mar 14, 2007 at 10:54:41PM +0100, "Martin v. L?wis" wrote:
> So this is a bug fix, even though the old test
> case explicitly tested for the presence of the bug
FWIW, when developing PyPy we found quite a number of tests in CPython
that were checking not just obscure implementa
stage of development - now more than ever depending on your
feedback and contributions - and we hope you appreciate PyPy 1.0 as an
interesting basis for greater things to come, as much as we do
ourselves!
have fun,
the PyPy release team,
Samuele Pedroni, Armin Rigo, Holger Krekel, Mich
Hi Jean-Paul,
On Mon, Apr 16, 2007 at 06:53:20PM -0400, Jean-Paul Calderone wrote:
> I just noticed r53997 (from some unit tests it broke), which disallowed things
> like this:
>
> class X(object):
> def __repr__(self):
> return "blah"
>
> class Y(X, type):
>
Hi Calvin,
On Sat, Apr 28, 2007 at 10:43:04PM -0400, Calvin Spealman wrote:
> The proposal adds a dynamic attribute lookup to the super type, which will
> automatically determine the proper class and instance parameters.
Can you describe how you intend the dynamic attribute lookup to find the
pro
Hi Calvin,
On Sun, Apr 29, 2007 at 02:53:58PM -0400, Calvin Spealman wrote:
> Yes, it is highly dependent on the new __super__ attribute. See the
> reference implementation for the how.
Ah, there is a reference implementation. There is no link to it in the
PEP you posted, hence my confusion. Wh
Hi Calvin,
On Mon, Apr 30, 2007 at 08:34:56AM -0400, Calvin Spealman wrote:
> If you want, you can also grab the reference
> implementation from my blog: http://ironfroggy-code.blogspot.com/
This reference implementation is broken. It doesn't pass the following
test, for example:
class A(o
Hi Kristján,
On Thu, May 03, 2007 at 03:57:26PM +, Kristján Valur Jónsson wrote:
> if (nb->nb_long != 0) {
> io = (PyIntObject*) (*nb->nb_long) (op);
> } else {
> io = (PyIntObject*) (*nb->nb_int) (op);
> }
> Now, how to fix this? Should the code in
Hi Kristján,
On Thu, May 03, 2007 at 07:38:04PM +0200, ?iga Seilnacht wrote:
> Those tests should be fixed to use test.test_support.MAX_Py_ssize_t instead
> of sys.maxint.
See also the bigmemtest() and bigaddrspacetest() decorators in test_support.
A bientot,
Armin.
__
Hi Anthony,
On Tue, May 08, 2007 at 09:14:02AM +1000, Anthony Baxter wrote:
> I'd like to suggest that we remove all (or nearly all) uses of
> xrange from the stdlib. A quick scan shows that most of the usage
> of it is unnecessary. With it going away in 3.0, and it being
> informally deprecate
Hi Alan,
On Mon, May 21, 2007 at 08:17:02PM -0400, Alan McIntyre wrote:
> Adding a step C1.5 which removes only objects that return true for
> PyInstance_Check seems to prevent the problem exhibited by this bug (I
> tried it out locally on the trunk and it doesn't cause any problems
> with the reg
Hi Eyal,
On Sun, Jun 10, 2007 at 04:13:38AM +0300, Eyal Lotem wrote:
> I must be missing something, as I really see no reason to keep the
> existing semantics other than backwards compatibility (which can be
> achieved by introducing a __fastattr__ or such).
>
> Can you explain under which situat
Hi,
On Tue, Jun 12, 2007 at 08:10:26PM +1200, Greg Ewing wrote:
> Rather than spend time tinkering with the lookup order,
> it might be more productive to look into implementing
> a cache for attribute lookups.
See patch #1700288.
Armin
___
Python-Dev
Vilnius/Post EuroPython PyPy Sprint 12-14th of July
The PyPy team is sprinting at EuroPython again and we invite
you to participate in our 3 day long sprint at the conference hotel
- R
Hi Martin,
On Fri, Sep 28, 2007 at 11:09:54PM +0200, "Martin v. Löwis" wrote:
> What's wrong with
>
> static const char *kwlist[] = {"x", "base", 0};
The following goes wrong if we try again to walk this path:
http://mail.python.org/pipermail/python-dev/2006-February/060689.html
Armin
Hi Neil,
On Fri, Nov 30, 2007 at 09:14:04AM -0700, Neil Toronto wrote:
> >> whether 64 bits is necessary. It takes an hour of concerted effort -
> >> nothing but "module.d = 1; del module.d" for an hour straight - to
> >> overflow a 32-bit version number. Is anybody going to actually get close
Hi all,
The next PyPy sprint will be held in Leysin, Switzerland, for
the fifth time. The overall idea of the sprint is to continue
working on making PyPy ready for general use.
The proposed topics are: ctypes, JIT, testing, LLVM. This is
a fully public sprint, so newcomers and other topics are
Hi,
On Sat, Jan 12, 2008 at 07:33:38PM -0500, Alexandre Vassalotti wrote:
> Well, in Python 3K, inst_persistent_id() won't be usable, since
> PyInstance_Type was removed.
Looking at the code, inst_persistent_id() is just a confusing name. It
has got nothing to do with PyInstance_Type; it's calle
Hi Raymond,
On Thu, Jan 24, 2008 at 01:36:14PM -0500, Raymond Hettinger wrote:
> Also, it seems that ABC is starting to evolve from an optional
> tool into something embedded in the language in a way that you
> can't escape it.
>
> I would prefer that it not be on the list of concepts that a
> b
Hi all,
In Python 2.5, I made an attempt to make equality consistent for the
various built-in and user-defined method types. I failed, though, as
explained in http://bugs.python.org/issue1617161. The outcome of this
discussion is that, first of all, we need to decide which behavior is
"correct":
Hi Phillip,
On Sun, Mar 09, 2008 at 07:05:12PM -0400, Phillip J. Eby wrote:
> I did not, however, need the equality of bound methods to be based on
> object value equality, just value identity.
>
> ...at least until recently, anyway. I do have one library that wants
> to have equality-based co
Hi Greg,
On Wed, Apr 16, 2008 at 03:34:44PM +1200, Greg Ewing wrote:
> > That's why I proposed <0, 1, ..., 9> for repr(range(10)).
>
> My worry is that this will lead a newcomer into thinking
> this is some kind of valid expression syntax.
What about the less confusing and more readily generaliz
Hi all,
Our next PyPy sprint will take place in
Berlin, 17-22nd May 2008.
More precisely, the sprint will be in the crashed c-base space station,
Berlin, Germany, Earth, Solar System. This is a fully public sprint:
newcomers (from all planets) and topics other than those proposed in the
ann
Hi Martin,
On Tue, May 20, 2008 at 10:22:37AM +0200, "Martin v. Löwis" wrote:
> In particular, setting this environment variable would also disable
> the detection of whether stdout is a terminal.
In this case, it seems to me that existing programs that start python as
a non-interactive subproces
Hi,
On Wed, Jun 11, 2008 at 10:44:17PM -0400, Scott Dial wrote:
> The only reason the test used locals() was
> because it was the only way to insert a non-string key into the class
> namespace.
This discussion is mistakenly focused on locals(). There is a direct
way to have arbitrary keys in the
Hi all,
Here is a first step towards classifying the Python test suite into
"real language tests" and "implementation details":
http://bugs.python.org/issue4242
If the general approach seems acceptable to people, I would be willing
to port more of PyPy's test suite patches. The net result w
Hi all,
There is a pending patch issue at http://bugs.python.org/issue4242 which
proposes to tag, in the CPython test suite, which tests are general
language tests (the vast majority) and which ones are specific to
CPython. The patch would add a couple of helpful functions to
test_support.py (htt
Hi all,
About multithreading models: I recently made an observation which
might be obvious to some, but not to me, and as far as I know not to
most of us either. I think that it's worth being pointed out :-)
http://mail.python.org/pipermail/pypy-dev/2011-August/008153.html
A bientôt,
Armin.
_
Hi Nick,
On Sat, Aug 27, 2011 at 2:40 PM, Nick Coghlan wrote:
> 1. How does the patch interact with C code that explicitly releases
> the GIL? (e.g. IO commands inside a "with atomic:" block)
As implemented, any code in a "with atomic" is prevented from
explicitly releasing and reacquiring the G
Hi Antoine,
> You then risk deadlocks. Say:
> (...)
Yes, it is indeed not a solution that co-operates transparently and
deadlock-freely with regular locks. You risk the same kind of
deadlocks as you would when using only locks. The reason is similar
to threads that try to acquire two locks in s
Hi Guido,
On Sun, Aug 28, 2011 at 6:43 PM, Guido van Rossum wrote:
> This sounds like a very interesting idea to pursue, even if it's late,
> and even if it's experimental, and even if it's possible to cause
> deadlocks (no news there). I propose that we offer a C API in Python
> 3.3 as well as a
Hi Charles-François,
2011/8/27 Charles-François Natali :
> The problem is that many locks are actually acquired implicitely.
> For example, `print` to a buffered stream will acquire the fileobject's mutex.
Indeed. After looking more at the kind of locks used throughout the
stdlib, I notice that
Re-hi,
2011/8/29 Armin Rigo :
>> The problem is that many locks are actually acquired implicitely.
>> For example, `print` to a buffered stream will acquire the fileobject's
>> mutex.
>
> Indeed.
> (...)
> I suspect that I need to do a more thorough review of t
Hi,
On Tue, Aug 30, 2011 at 11:33 PM, Yury Selivanov
wrote:
> Maybe it'd be better to put 'atomic' in the threading module?
'threading' is pure Python. But anyway the consensus is to not have
'atomic' at all in the stdlib, which means it is in its own 3rd-party
extension module.
Armin
___
Hi,
On Thu, Dec 1, 2011 at 07:06, Matt Joiner wrote:
> I saw this, I believe it just exposes an STM primitive to user code.
> It doesn't make use of STM for Python internals.
That's correct.
> Explicit STM doesn't seem particularly useful for a language that
> doesn't expose raw memory in its n
Hi,
Actually, not even one month ago, Intel announced that its processors
will offer Hardware Transactional Memory in 2013:
http://www.h-online.com/newsticker/news/item/Processor-Whispers-About-Haskell-and-Haswell-1389507.html
So yes, obviously, it's going to happen.
A bientôt,
Armin.
___
Hi,
On Tue, Dec 13, 2011 at 11:37, Amaury Forgeot d'Arc wrote:
>> "When sorting a list using the sort() method, attempting to inspect or
>> mutate the content of the list will result in undefined behaviour."
>
> (...)
> So behaviour is not undefined at all...
No, the behavior _is_ undefined. Th
Hi Victor,
On Thu, Mar 1, 2012 at 22:59, Victor Stinner wrote:
>> I challenge anymore to break pysandbox! I would be happy if anyone
>> breaks it because it would make it more stronger.
I tried to run the files from Lib/test/crashers and --- kind of
obviously --- I found at least two of them tha
Hi all,
On Sun, Mar 4, 2012 at 03:51, Guido van Rossum wrote:
> Could we put asserts in the places where segfaults may happen?
No. I checked Lib/test/crashers/*.py and none of them would be safe
with just a failing assert. If they were, we'd have written the
assert long ago :-( "mutation_insi
Hi Mark,
On Sun, Mar 4, 2012 at 18:34, Mark Shannon wrote:
> I don't think it is as hard as all that.
> All the crashers can be fixed, and with minimal effect on performance.
I will assume that you don't mean just to fix the files in
Lib/test/crashers, but to fix the general issues that each is
Hi Greg,
On Sun, Mar 4, 2012 at 22:44, Greg Ewing wrote:
>> Segfaults (most of them) can generally be made into arbitrary code
>> execution,
>
> Can you give an example of how this can be done?
You should find tons of documented examples of various attacks. It's
not easy, but it's possible. Fo
Hi Mark,
On Sun, Mar 4, 2012 at 18:34, Mark Shannon wrote:
> You can't solve the too much time, without solving the halting problem,
Not sure what you mean by that. It seems to me that it's particularly
easy to do in a roughly portable way, with alarm() for example on all
UNIXes.
A bientôt,
Hi Stefan,
Stefan Behnel wrote:
> could you please stop bashing CPython for no good reason, especially on
> python-dev? Specifically, to call it broken beyond repair is a rather
> offensive claim, especially when made in public.
Sorry if you were offended. I am just trying to point out that
CPyt
Hi Stefan,
On Wed, Mar 7, 2012 at 23:16, Stefan Behnel wrote:
> Well, there's a bug tracker that lists some of them, which is not *that*
> hard to find. Does your claim about "a significantly harder endeavour"
> refer to finding a crash or to finding a fix for it?
Are you talking about the vario
Hi all,
This is an update on the (so far PyPy-only) project of adding "Automatic
Mutual Exclusion" to Python, via STM (Software Transactional Memory).
For the motivation, see here:
http://morepypy.blogspot.com/2012/03/call-for-donations-for-software.html
"""The point is that [with STM/AME] your p
Hi Stefan,
On Wed, Apr 11, 2012 at 14:29, Stefan Behnel wrote:
>> Moreover the performance hit is well below 2x, more like 20%.
>
> Hmm, those 20% refer to STM, right? Without hardware support? Then hardware
> support could be expected to drop that even further?
Yes, that's using STM on my regul
101 - 200 of 341 matches
Mail list logo
