Hi Pau,
Also, the Cython documentation warns against doing this kind of things
(here, accessing the Python object stored in ``foo``). From
https://cython.readthedocs.io/en/latest/src/userguide/special_methods.html:
You need to be careful what you do in a __dealloc__() method.
By the time
el__() is
> called a second time when a resurrected object is about to be destroyed; the
> current CPython implementation only calls it once.
"...in most cases."
Armin Rigo
___
Python-Dev mailing list -- python-dev@python.org
To unsubscrib
Hi,
On Fri, 25 Oct 2019 at 04:13, Jonathan Goble wrote:
>> Has anyone already done this that people know of? (Searching the Internetz
>> didn't turn anything up) Failing that, to what extent is it reasonable to
>> either consider assemble() as some kind of sane API point into compile.c
PyPy co
Hi,
On Wed, 29 May 2019 at 08:07, Greg Ewing wrote:
> Nick Coghlan wrote:
> > Having a single locals() call de-optimize an entire function would be
> > far from ideal.
>
> I don't see what would be so bad about that. The vast majority
> of functions have no need for locals().
You have the occasi
Hi,
On Thu, 23 May 2019 at 17:28, Steve Dower wrote:
> On 23May2019 0636, Nick Coghlan wrote:
> > However, I think the PR does show that the proposed technique can be
> > implemented without too much additional code complexity, and will
> > hopefully be adaptable for all implementations that emul
Hi Neil,
On Wed, 24 Apr 2019 at 21:17, Neil Schemenauer wrote:
> Regarding the Py_TRACE_REFS fields, I think we can't do them without
> breaking the ABI because of the following. For GC objects, they are
> always allocated by _PyObject_GC_New/_PyObject_GC_NewVar. So, we
> can allocate the extra
Hi,
On Tue, 19 Feb 2019 at 13:12, Victor Stinner wrote:
> Please don't use &PyTuple_GET_ITEM() or _PyTuple_ITEMS(). It prevents
> to use a more efficient storage for tuple. Something like:
> https://pythoncapi.readthedocs.io/optimization_ideas.html#specialized-list-for-small-integers
>
> PyPy alr
Hi Steve,
On 30/11/2018, Steve Dower wrote:
> On 29Nov2018 2206, Armin Rigo wrote:
>> On Thu, 29 Nov 2018 at 18:19, Steve Dower wrote:
>>> quo. We continue to not be able to change CPython internals at all,
>>> since that will break people using option B.
>>
&
Hi,
On Thu, 29 Nov 2018 at 18:19, Steve Dower wrote:
> quo. We continue to not be able to change CPython internals at all,
> since that will break people using option B.
No? That will only break users if they only have an option-B
``foo.cpython-318m-x86_64-linux-gnu.so``, no option-A .so and no
Hi Steve,
On Tue, 27 Nov 2018 at 19:14, Steve Dower wrote:
> On 27Nov2018 0609, Victor Stinner wrote:
> > Note: Again, in my plan, the new C API would be an opt-in API. The old
> > C API would remain unchanged and fully supported. So there is no
> > impact on performance if you consider to use th
Hi,
On Sun, 25 Nov 2018 at 10:15, Stefan Behnel wrote:
> Overall, this seems like something that PyPy could try out as an
> experiment, by just taking a simple extension module and replacing all
> increfs with newref assignments. And obviously implementing the whole thing
> for the C-API
Just to
Hi Stefan,
On Sat, 24 Nov 2018 at 22:17, Stefan Behnel wrote:
> Couldn't this also be achieved via reference counting? Count only in C
> space, and delete the "open object" when the refcount goes to 0?
The point is to remove the need to return the same handle to C code if
the object is the same
Hi Hugo, hi all,
On Sun, 18 Nov 2018 at 22:53, Hugh Fisher wrote:
> I suggest that for the language reference, use the license plate
> or registration analogy to introduce "handle" and after that use
> handle throughout. It's short, distinctive, and either will match
> up with what the programmer
Hi,
On Sat, 27 Oct 2018 at 01:50, Steven D'Aprano wrote:
> [...]
> > So I was wondering if it would be possible to keep that context around
> > if you are in the debugger and rewind the execution point to before
> > the statement was triggered.
>
> I think what you are looking for is a reverse de
Hi Antoine,
On 11 August 2018 at 15:19, Antoine Pitrou wrote:
> Jython and IronPython never got significant manpower AFAIK, so even
> without being hindered by the C API, chances are they would never have
> gotten very far. Both do not even seem to have stable releases
> implementing the Python
Hi,
On 31 July 2018 at 13:55, Antoine Pitrou wrote:
> It's just that I disagree that removing the C API will make CPython 2x
> faster.
>
> Actually, important modern optimizations for dynamic languages (such as
> inlining, type specialization, inline caches, object unboxing) don't
> seem to depen
Hi,
On 30 July 2018 at 22:19, Chris Barker via Python-Dev
wrote:
> Oh well. This is a serious usability issue -- but what can you do?
I think that argument clinic knows if the built-in function is
supposed to be a method or a function. It doesn't look too hard to
add a new flag METH_IS_METHOD o
Hi,
On 23 June 2018 at 10:54, Serhiy Storchaka wrote:
> +1 too. But I think the right solution should be opposite: reverting
> issue1350060 changes and making all methods equality be based on the
> identity of __self__.
The arguments in this thread are the kind of discussion I was looking
for wh
Hi Inada,
On 27 May 2018 at 09:12, INADA Naoki wrote:
> When focusing to CPython, PyPy and MicroPython, no problem for adding
> __reverse__ in 3.8 seems OK.
Fwiw, the functionality that is present in OrderedDict but still
absent from 'dict' is: ``__reverse__``, discussed above, and
``move_to_end
Hi,
On 26 April 2018 at 07:50, Raymond Hettinger
wrote:
>> [Raymond Hettinger ]
>>> After re-reading all the proposed code samples, I believe that
>>> adopting the PEP will make the language harder to teach to people
>>> who are not already software engineers.
>
> (...)
>
> Python is special, in
Hi,
On 27 February 2018 at 15:32, Serhiy Storchaka wrote:
> 1. CPython and PyPy set different position for multiline strings. PyPy sets
> the position of the start of string, but CPython sets the position of the
> end of the string. A program that utilizes the docstring position needs to
> handle
Hi,
On 14 November 2017 at 14:55, Jan Claeys wrote:
> Sounds like https://www.iso.org/standard/71094.html
> which is updating https://www.iso.org/standard/61457.html
> (which you can download from there if you search a bit; clearly either
> ISO doesn't have a UI/UX "standard" or they aren't follo
Hi Antoine,
On 8 November 2017 at 10:28, Antoine Pitrou wrote:
> Yet, PyPy has no reference counting, and it doesn't seem to be a cause
> of concern. Broken code is fixed along the way, when people notice.
It is a major cause of concern. This is the main blocker for
pure-Python code compatibil
Hi all,
On 20 March 2017 at 22:28, Nathaniel Smith wrote:
> Modern CPython, and all extant versions of PyPy and Jython, guarantee that
> __del__ is called at most once.
Just a note, if someone actually depends on this: it is not true in
all cases. For example, in CPython 3.5.3:
>>> class X:
..
Hi Matthieu,
On 20 February 2017 at 19:44, Matthieu Dartiailh wrote:
> What do you think ? Should I open an issue on https://bugs.python.org/ ?
Possibly related: http://bugs.python.org/issue24340
A bientôt,
Armin.
___
Python-Dev mailing list
Python-
Hi Freddy,
On 16 February 2017 at 18:03, Freddy Rietdijk wrote:
> As I mentioned, it seems only sets cause unreproducible
> bytecode. Sets have no order. But when generating the bytecode, I would
> expect there would still be an order since the code isn't actually executed,
> right?
No, the sets
Hi Sven,
On 26 January 2017 at 22:13, Sven R. Kunze wrote:
> I recently refreshed regular expressions theoretical basics *indulging in
> reminiscences* So, I read https://swtch.com/~rsc/regexp/regexp1.html
Theoretical regular expressions and what Python/Perl/etc. call regular
expressions are a b
Hi,
Sorry to reply in this old thread. We just noticed this on #pypy:
On 22 October 2016 at 05:32, Nick Coghlan wrote:
> The weakref-before-__del__ ordering change in
> https://www.python.org/dev/peps/pep-0442/#disposal-of-cyclic-isolates
> only applies to cyclic garbage collection,so for norma
Hi Hans-Peter,
On 6 January 2017 at 00:28, Hans-Peter Jansen wrote:
> Leaves the question, how stable this "interface" is?
Another way to jump through hoops:
c_raw = ctypes.PYFUNCTYPE(ctypes.c_void_p, ctypes.c_void_p)(lambda p: p)
addr = c_raw(ctypes.pointer(T.from_buffer(m)))
b =
Hi Serhiy,
On 21 December 2016 at 15:51, Serhiy Storchaka wrote:
> The code
>
> if (PySlice_GetIndicesEx(item, length,
> &start, &stop, &step, &slicelength) < 0)
> return -1;
>
> should be replaced with
>
> if (foo(item, &start, &stop, &step) < 0)
> return -1;
Hi Nick,
On 5 December 2016 at 13:22, Nick Coghlan wrote:
> I think 3 omnibus issues would be a reasonable way to go, with the
> discussion on those issues then splitting things out to either new
> issue reports, or entries in
> https://hg.python.org/cpython/file/default/Lib/test/crashers/ (if an
Hi Raymond,
On 6 December 2016 at 05:59, Raymond Hettinger
wrote:
> Also, we use {...} instead of OrderedDict(...).
No, at least CPython 3.5.2 uses ``...`` for OrderedDict, and not
``{...}``. Following that example, deques should also use ``...``
instead of ``[...]``. But I bow to your choice
ues without actual examples and patches, then
that's fine with me too and I will simply continue to expand my
cpython-crashers.rst file.
Thank you for your attention,
Armin Rigo
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.o
Hi Inada,
On 10 August 2016 at 18:52, INADA Naoki wrote:
> a. dict has one additional word and support ring internally.
> b. OrderedDict reimplements many APIs (iterating, resizing, etc...) to
> support ring.
There is a solution "c." which might be simpler. Let's think first
about what occurs
Hi,
On 24 June 2016 at 23:52, Eric Snow wrote:
> Pending feedback, the impact on Python implementations is expected to
> be minimal. If a Python implementation cannot support switching to
> `OrderedDict``-by-default then it can always set ``__definition_order__``
> to ``None``.
That's wishful t
Hi Lukasz,
On 10 May 2016 at 04:13, Łukasz Langa wrote:
> However, because of PyGC_Collect() called in Py_Finalize(), during
> interpreter shutdown the collection is done anyway, Linux does CoW and the
> memory usage spikes. Which is ironic on process shutdown.
Try to call os._exit() to avoid do
Hi Victor,
On 14 April 2016 at 17:19, Victor Stinner wrote:
> Each time a dictionary is created, the global
> version is incremented and the dictionary version is initialized to the
> global version.
A detail, but why not set the version tag of new empty dictionaries to
zero, always? Same afte
Hi,
On 3 April 2016 at 15:29, MRAB wrote:
>> Should we rename Py_SETREF to Py_XSETREF and introduce new Py_SETREF
>> that uses Py_DECREF?
>
> Checking for NULL is convenient (and safer), but, on the other hand, it
> _would_ be consistent with the others.
My 2 cents would be to call the new macro
Hi,
On 20 March 2016 at 18:10, Brett Cannon wrote:
> And if we didn't keep its count accurately it would eventually hit
> zero and constantly have its dealloc function checked for.
I think the idea is really consistency. If we wanted to avoid all
"Py_INCREF(Py_None);", it would be possible: we
Hi all,
On Tue, Dec 1, 2015 at 8:13 PM, Laura Creighton wrote:
> Python 3.5 is not supported on windows XP. Upgrade your OS or
> stick with 3.4
Maybe this information should be written down somewhere more official?
I can't find it in any of these pages:
https://www.python.org/downloads/window
Hi all,
Spending an hour with "hg bisect" is a good way to figure out some of
the worst speed regressions that occurred in the early days of 2.7
(which are still not fixed now). Here's my favorite's pick:
* be4bec689de3 made bm_mako 15% slower, and spitfire_cstringio even much more
* ad030571e
Hi Gary,
On Tue, Sep 8, 2015 at 4:12 PM, Gary Robinson wrote:
> 1) More the reference counts away from data structures, so copy-on-write
> isn’t an issue.
A general note about PyPy --- sorry, it probably doesn't help your use
case because SciPy is not supported right now...
Right now, PyPy hit
Hi Valentine,
On Thu, Sep 3, 2015 at 9:15 PM, Valentine Sinitsyn
wrote:
>> That does not make it ok to have del called several time, does it?
>
> That's a tricky question.
If the Python documentation now says something like ``the __del__
method is never called more than once on the same instance
Hi Valentine,
On 25 August 2015 at 09:56, Valentine Sinitsyn
wrote:
>> Yes, I think so. There is a *highly obscure* corner case: __del__
>> will still be called several times if you declare your class with
>> "__slots__=()".
>
> Even on "post-PEP-0442" Python 3.4+? Could you share a link please?
Hi Valentine,
On 24 August 2015 at 20:43, Valentine Sinitsyn
wrote:
> So you mean that this was to keep things backwards compatible for
> third-party extensions? I haven't thought about it this way, but this makes
> sense. However, the behavior of Python code using objects with __del__ has
> chan
Hi Valentine,
On 19 August 2015 at 09:53, Valentine Sinitsyn
wrote:
> why it wasn't possible to
> implement proposed CI disposal scheme on top of tp_del?
I'm replying here as best as I understand the situation, which might
be incomplete or wrong.
From the point of view of someone writing a C ex
Hi Larry,
On 31 May 2015 at 01:20, Larry Hastings wrote:
> p.s. Supporting this patch also helps cut into PyPy's reported performance
> lead--that is, if they ever upgrade speed.pypy.org from comparing against
> Python *2.7.2*.
Right, we should do this upgrade when 2.7.11 is out.
There is some
Hi Nick,
On 16 May 2015 at 10:31, Nick Coghlan wrote:
> Oh, that's rather annoying that the PyPy team implemented bug-for-bug
> compatibility there, and didn't follow up on the operand precedence
> bug report to say that they had done so.
It's sadly not the only place, by far, where a behavior o
Hi Brett,
On 6 March 2015 at 19:11, Brett Cannon wrote:
> I disagree with your premise that .pyo files don't have a noticeable effect
> on performance. If you don't use asserts a lot then there is no effect, but
> if you use them heavily or have them perform expensive calculations then
> there is
Hi Tim,
On 10 March 2015 at 18:22, Tim Peters wrote:
> 1. Merge "2 at a time" instead of just 1. That is, first "sort" the
> next 2 elements to be merged (1 compare and a possible swap). Then
> binary search to find where the smaller belongs, and a shorter binary
> search to find where the larg
Hi,
On 6 February 2015 at 08:24, Maciej Fijalkowski wrote:
> I don't think it's safe to assume f_code is properly filled by the
> time you might read it, depending a bit where you find the frame
> object. Are you sure it's not full of garbage?
Yes, before discussing how to do the utf8 decoding,
Hi all,
On 24 January 2015 at 11:50, Maciej Fijalkowski wrote:
> I would like to point out that we implemented rhettingers idea in PyPy
> that makes all the dicts ordered by default and we don't have any
> adverse performance effects (in fact, there is quite significant
> memory saving coming fro
Hi all,
On 1 January 2015 at 14:52, Maciej Fijalkowski wrote:
> PS. I wonder who came up with the idea first, PHP or rhettinger and
> who implemented it first (I'm pretty sure it was used in hippy before
> it was used in Zend PHP)
We'd need to look more in detail to that question, but a quick lo
Hi Stefan,
On 26 October 2014 02:50, Stefan Richthofer wrote:
> It appears weakrefs are only cleared if this is done by gc (where no
> resurrection can happen anyway). If a resurrection-performing-__del__ is
> just called by ref-count-drop-to-0, weakrefs persist -
How do you reach this conclusio
Hi,
On 18 August 2014 22:30, Oleg Broytman wrote:
>Aha, I see now -- the signing certificate is CAcert, which I've
> installed manually.
I don't suppose anyone is particularly annoyed by this fact? I know
for sure two classes of people that will never click "Ignore". The
first one is peopl
Hi,
On 12 August 2014 01:08, Allen Li wrote:
> with (open('foo') as foo,
> open('bar') as bar,
> open('baz') as baz,
> open('spam') as spam,
> open('eggs') as eggs):
> pass
+1. It's exactly the same grammar extension as for "from import"
state
Hi all,
The core of the matter is that if we repeatedly __add__ strings from a
long list, we get O(n**2) behavior. For one point of view, the
reason is that the additions proceed in left-to-right order. Indeed,
sum() could proceed in a more balanced tree-like order: from [x0, x1,
x2, x3, ...], r
Hi Larry,
On 10 August 2014 08:11, Larry Hastings wrote:
>> A small tip from my bzr days - cd into the directory before scanning it
>
> I doubt that's permissible for a library function like os.scandir().
Indeed, chdir() is notably not compatible with multithreading. There
would be a non-portab
Hi Nick,
On 21 April 2014 07:39, Nick Coghlan wrote:
> Notably, I recommend that hybrid code avoid calling mapping iteration
> methods directly, and instead rely on builtin functions where possible,
> and some additional helper functions for cases that would be a simple
> combination of a builtin
Hi Jim,
On 18 April 2014 23:46, Jim J. Jewett wrote:
> (2) Is "the item will be hashed at least once" a language guarantee?
I think that a reasonable implementation needs to hash at least once
all keys that are added to the dictionary. Otherwise we end up, as
you said, with a dictionary that c
Hi,
On 11 April 2014 19:55, Maciej Fijalkowski wrote:
>> Thanks, that clarification helps a lot. Does this mean that "API-mode"
>> CFFI is competing with things like swig (which is not used much these
>> days, as far as I know) and Cython (which is used a lot in the numeric
>> community)? ("ABI-m
Hi,
On 10 April 2014 22:12, Paul Moore wrote:
> I agree. I'd like to see a clear explanation of what advantages (and
> disadvantages!) CFFI gives over ctypes, as well as the plan for
> inclusion and how the inevitable confusion over whether to use ctypes
> or cffi will be handled. (...)
I can't
Hi,
On 25 January 2014 17:26, Georg Brandl wrote:
> Yep, and the URLs without version never served Python 3 docs as far as I can
> remember, so I don't know where Google has these s from.
My guess would be that it's the title of the page that we (now) get
from the url http://docs.python.org/ .
Hi Vajrasky,
On 28 January 2014 03:05, Vajrasky Kok wrote:
> I get your point. But strangely enough, I can still recover from
> list(repeat('a', 2**29)). It only slows down my computer. I can ^Z the
> application then kill it later. But with list(repeat('a', times=-1)),
> rebooting the machine is
Hi Serhiy,
On Fri, Jan 3, 2014 at 8:59 AM, Serhiy Storchaka wrote:
>> +if (!PyArg_ParseTuple(args, "(kl):_acquire_restore", &count, &owner))
>
> Please don't use "(...)" in PyArg_ParseTuple, it is dangerous (see issue6083
I think that in this case it is fine, because the "k" and "l" are
retu
Hi,
On Thu, Nov 28, 2013 at 7:14 AM, V S, Nagendra (Nonstop Filesystems Team)
> on NonStop "uuid.py" falls throw to random.range() call to generate the
> random number
And indeed, the random module gets identical results in both parent
and child after a fork(). This seems to mean that the rand
Hi again,
I figured that even using the traceback.py module and getting
"Exception: \u1234\u1235\u5321" is rather useless if you tried to
raise an exception with a message in Thai. I believe this to also be
a bug, so I opened https://bugs.pypy.org/issue1634 . According to
this thread, however, p
Hi,
FWIW, the pure Python traceback.py module has a slightly different
(and saner) behavior:
>>> e = Exception(u"xx\u1234yy")
>>> traceback.print_exception(Exception, e, None)
Exception: xx\u1234yy
I'd suggest that the behavior of the two should be unified anyway.
The traceback module uses value
Hi Victor,
On Wed, Nov 13, 2013 at 12:58 AM, Victor Stinner
wrote:
> I now gave up on sandboxing Python. I just would like to warn other
> core developers that trying to put a sandbox in Python is not a good
> idea :-)
I cannot thank you enough for writing this mail :-) It is a great
place to p
Hi Nick,
On Sat, Oct 19, 2013 at 1:41 PM, Nick Coghlan wrote:
> recreating the *exact* exception subclass check from
> Python is actually difficult these days.
Can't it be done roughly like that?
def __exit__(self, typ, val, tb):
try:
raise typ, val
except self.ex
Hi Guido,
On Thu, Oct 3, 2013 at 10:47 PM, Guido van Rossum wrote:
> Sounds a bit like some security researchers drumming up business. If you can
> run the binary, presumably you can also recover the seed by looking in
> /proc, right? Or use ctypes or something. This demonstration seems of
> acad
Hi Nick,
On Thu, Sep 26, 2013 at 6:59 AM, Nick Coghlan wrote:
>> I'm strongly in favour of Georg's one ("Exception in __del__ caught and not
>> propagated").
>
> Such a change is highly unlikely to happen, as it would require
> changing every location where we call PyErr_WriteUnraisable.
Er, wh
Hi Richard,
On Tue, Sep 10, 2013 at 3:42 PM, Richard Oudkerk wrote:
> I guess another example is creating an "identity dict" (see
> http://code.activestate.com/lists/python-ideas/7161/) by doing
>
> d = transformdict(id)
This is bogus, because only the id will be stored, and the original
key
Hi Mark,
On Mon, Sep 9, 2013 at 11:18 PM, Mark Shannon wrote:
> 5. Other implementations. What do the Jython/IronPython/PyPy developers
> think?
Thanks for asking :-) I'm fine with staying out of language design
issues like this one, and I believe it's the general concensus in
PyPy. Whatever g
Hi Ethan,
Are you suggesting that inspect.get_mro(A) would return (A, object,
type)? That seems very wrong to me.
If the goal is to fix `inspect.classify_class_attrs()`, then this
function only needs a specific fix, along the lines of looking in
`get_mro(A) + get_mro(type(A))`. (A more minor is
Hi Tim,
On Tue, Aug 20, 2013 at 5:12 PM, Tim Peters wrote:
> Try running "hg verify -v" - these warnings only appear when verify is
> run in verbose mode.
Indeed. Ignore what I said then about a broken copy of the
repository: any copy will show these three warnings, and they can be
safely ignor
Hi Tim,
On Tue, Aug 20, 2013 at 1:48 AM, Tim Peters wrote:
>>> warning: copy source of 'Modules/_threadmodule.c' not in parents of
>>> 60ad83716733
>>> warning: copy source of 'Objects/bytesobject.c' not in parents of
>>> 64bb1d258322
>>> warning: copy source of 'Objects/stringobject.c' not in
Hi,
On Sat, Aug 17, 2013 at 8:42 PM, Antoine Pitrou wrote:
>> summary:
>> Use a known unique object for the dummy entry.
Another issue with this change: the dummy object should be of a dummy
subclass of 'object', rather than of 'object' itself. When it is
'object' itself, a custom __eq__() me
Hi Arnaud,
On Mon, Aug 12, 2013 at 9:39 AM, Arnaud Fontaine
wrote:
> Thread 1 is trying to import a module 'foo.bar' (where 'foo' is a
> package containing dynamic modules) handled by Import Hooks I
> implemented, so import lock is acquired before even running the hooks
> (Python/import.c
Hi Larry,
On Mon, Aug 5, 2013 at 10:48 AM, Larry Hastings wrote:
> Question 4: Return converters returning success/failure?
The option generally used elsewhere is: if we throw an exception, we
return some special value; but the special value doesn't necessarily
mean by itself that an exception w
Hi,
On Fri, Jun 21, 2013 at 9:20 PM, Steven D'Aprano wrote:
process. Personally, I don't see the value in it; other implementations
will need to do *something* special to use it anyway.
>
> That's not correct. Other implementations can do exactly what CPython 3.3
> does, namely just use
Hi,
On Thu, May 23, 2013 at 12:33 AM, Łukasz Langa wrote:
> Alternative approaches
> ==
You could also mention "pairtype", used in PyPy:
https://bitbucket.org/pypy/pypy/raw/default/rpython/tool/pairtype.py
(very short code). It's originally about adding double-dispatch, but
Hi all,
On Sun, May 19, 2013 at 4:59 PM, Maciej Fijalkowski wrote:
> Note that raymonds proposal would make dicts and ordereddicts almost
> exactly the same speed.
Just checking: in view of Raymond's proposal, is there a good reason
against having all dicts be systematically ordered? It would
Hi Antoine,
On Sat, May 18, 2013 at 3:45 PM, Antoine Pitrou wrote:
>> How is this done? I don't see a clear way to determine it by looking
>> only at the objects in the CI, given that arbitrary modifications of
>> the object graph may have occurred.
>
> The same way a generation is traversed, bu
Hi Antoine,
On Sat, May 18, 2013 at 10:59 AM, Antoine Pitrou wrote:
> Cyclic isolate (CI)
> A reference cycle in which no object is referenced from outside the
> cycle *and* whose objects are still in a usable, non-broken state:
> they can access each other from their respective final
Hi all,
How about using the shared-or-exclusive advisory file locks (with
flock() or fcntl())? It may only work on Posix though.
A bientôt,
Armin.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Un
Hi Antoine,
On Tue, May 7, 2013 at 8:25 AM, Antoine Pitrou wrote:
> For me, a patch that mandated general-purpose containers (list, dict,
> etc.) respect object identity would be ok.
Thanks, that's also my opinion.
In PyPy's approach, in trying to emulate CPython vs. trying to
convince users th
Hi all,
In the context PyPy, we've recently seen again the issue of "x is y"
not being well-defined on immutable constants. I've tried to
summarize the issues and possible solutions in a mail to pypy-dev [1]
and got some answers already. Having been convinced that the core is
a language design i
Hi Matej,
On Thu, Mar 7, 2013 at 11:08 AM, Matej Cepl wrote:
> if c is not ' ' and c is not ' ':
> if c != ' ' and c != ' ':
Sorry for the delay in answering, but I just noticed what is wrong in
this "fix": it compares c with the same single-character ' ' twice,
whereas the
Hi Jeff,
On Mon, Apr 29, 2013 at 11:58 PM, Jeff Allen <"ja...py"@farowl.co.uk> wrote:
> In Jython, (...)
Thanks Jeff for pointing this out. Jython thus uses a custom
mechanism similar to PyPy's, which is also similar to atexit's. It
should not be too hard to implement it in CPython 3 as well, i
Hi Nikolaus,
On Sat, Apr 27, 2013 at 4:39 AM, Nikolaus Rath wrote:
> It's indeed very informative, but it doesn't fully address the question
> because of the _pyio module which certainly can't use any custom C code.
> Does that mean that when I'm using x = _pyio.BufferedWriter(), I could loose
>
Hi Antoine,
On Sat, Mar 30, 2013 at 10:37 PM, Antoine Pitrou wrote:
> On Sat, 30 Mar 2013 17:31:26 -0400
> Micha Gorelick wrote:
>> I was taking a look at dictobject.c and realized that the logic
>> controlling whether a resizedict will occur in
>> dict_set_item_by_hash_or_entry disallows for th
Hi Stefan,
On Sat, Mar 2, 2013 at 10:10 AM, Stefan Behnel wrote:
> You say that "the API is fairly stable". What about the implementation?
> Will users want to install a new version next to the stdlib one in a couple
> of months,
I think that the implementation is fairly stable as well. The onl
Hi Gregory,
On Sat, Mar 2, 2013 at 8:40 AM, Gregory P. Smith wrote:
>
> On Wed, Feb 27, 2013 at 7:57 AM, Eli Bendersky wrote:
>> So would you say that the main use of the API level is provide an
>> alternative for writing C API code to interface to C libraries. IOW, it's in
>> competition with S
Hi Paul,
On Thu, Feb 28, 2013 at 9:27 AM, Paul Moore wrote:
> Presumably ffi.NULL isn't needed and I can use 0? (After all, 0 and NULL are
> equivalent in C, so that's
> not a correctness issue).
Indeed. I created
https://bitbucket.org/cffi/cffi/issue/61/convert-0-to-a-null-pointer.
In C, NULL
Hi Neil,
On Thu, Feb 28, 2013 at 12:34 AM, Neil Hodgson wrote:
>Wouldn't it be better to understand the SAL annotations like _In_opt so
> that spurious NULLs (for example) produce a good exception from cffi instead
> of failing inside the system call?
Maybe. Feel like adding an issue to
h
Hi Paul,
On Wed, Feb 27, 2013 at 9:31 PM, Paul Moore wrote:
> from ctypes import windll
> MessageBox = windll.User32.MessageBoxW
> MessageBox(0, "Hello, world!", "Title", 0)
You are right that it's a bit cumbersome in cffi up to and including
0.5, but in the cffi trunk all standard Windows types
Hi Paul,
On Wed, Feb 27, 2013 at 7:24 PM, Paul Moore wrote:
> On 27 February 2013 11:53, Maciej Fijalkowski wrote:
>> I think it means you can't use the ABI version and specify the calling
>> convention. It's a reasonable bug report (the calling convention on
>> API version works though)
>
> Tha
Hi Guido,
On Tue, Feb 26, 2013 at 8:24 PM, Guido van Rossum wrote:
> From a software engineering perspective, 10 years is indistinguishable
> from infinity, so I don't care what happens 10 years from now -- as
> long as you don't blame me. :-)
I can't resist: around today it is the 10th annivers
Hi,
On Tue, Feb 26, 2013 at 5:38 PM, Maciej Fijalkowski wrote:
>> Do you intend to actually maintain it inside the CPython repository?
>
> Once we put it in, yes, of course. Me Armin and Alex.
Yes, I confirm. :-)
Armin
___
Python-Dev mailing list
Pyth
1 - 100 of 341 matches
Mail list logo
