Julian Taylor schrieb am 02.08.2014 um 12:11:
> On 02.08.2014 08:35, Terry Reedy wrote:
>> On 8/2/2014 1:57 AM, Allen Li wrote:
>>> On Fri, Aug 01, 2014 at 02:51:54PM -0700, Guido van Rossum wrote:
No. We just can't put all possible use cases in the docstring. :-)
On Fri, Aug 1,
Alexander Belopolsky schrieb am 02.08.2014 um 16:52:
> On Sat, Aug 2, 2014 at 3:39 AM, Steven D'Aprano wrote:
>
>> String concatenation with + is an attractive
>> nuisance for many people, including some who actually know better but
>> nevertheless do it. Also, for reasons I don't understand, many
Steven D'Aprano schrieb am 04.08.2014 um 20:10:
> On Mon, Aug 04, 2014 at 09:25:12AM -0700, Chris Barker wrote:
>
>> Good point -- I was trying to make the point about .join() vs + for strings
>> in an intro python class last year, and made the mistake of having the
>> students test the performanc
Jeremy Sanders schrieb am 26.09.2014 um 09:28:
> Antoine Pitrou wrote:
>
>> Fortunately, Python's subprocess has its `shell` argument default to
>> False. However, `os.system` invokes the shell implicitly and is
>> therefore a possible attack vector.
>
> Of course anything called by subprocess wi
Serhiy Storchaka schrieb am 21.02.2015 um 16:35:
> I'm going to change standard messages in PyArg_Parse*
> and common converting functions (as PyLong_AsLong and PyObject_GetBuffer)
> to make them uniform.
*sigh* - and along came another heap of doctest adaptations...
Stefan
Antoine Pitrou schrieb am 07.04.2015 um 14:26:
> On Tue, 07 Apr 2015 03:11:30 +0100
> Rob Cliffe wrote:
>>
>> On 07/04/2015 02:08, Guido van Rossum wrote:
>>> I've taken the liberty of adding the following old but good rule to
>>> PEP 8 (I was surprised to find it wasn't already there since I've
Guido van Rossum schrieb am 17.04.2015 um 23:58:
> The ``typing`` module defines the ``Generator`` type for return values
> of generator functions. It is a subtype of ``Iterable`` and it has
> additional type variables for the type accepted by the ``send()``
> method and the return type of the gene
Petr Viktorin schrieb am 17.04.2015 um 15:52:
> As a background, the PyModuleDef structure [1] is currently:
>
> struct PyModuleDef{
> PyModuleDef_Base m_base;
> const char* m_name;
> const char* m_doc;
> Py_ssize_t m_size;
> PyMethodDef *m_methods;
> inquir
Guido van Rossum schrieb am 18.04.2015 um 18:38:
> That's a good question. We *could* make it so that you can subclass
> Generator and instantiate the instances; or we could even make it do some
> structural type checking. (Please file a pull request or issue for this at
> github.com/ambv/typehinti
Stefan Behnel schrieb am 18.04.2015 um 19:39:
> Guido van Rossum schrieb am 18.04.2015 um 18:38:
>> That's a good question. We *could* make it so that you can subclass
>> Generator and instantiate the instances; or we could even make it do some
>> structural type che
Yury Selivanov schrieb am 28.04.2015 um 05:07:
> e) Should we add a coroutine ABC (for cython etc)?
Sounds like the right thing to do, yes. IIUC, a Coroutine would be a new
stand-alone ABC with send, throw and close methods.
Should a Generator then inherit from both Iterator and Coroutine, or wou
Mark Shannon schrieb am 27.04.2015 um 09:48:
> On 27/04/15 00:13, Guido van Rossum wrote:
>> Currently this means looking for yield [from]; PEP 492 just adds looking
>> for await and async [for|with]. Making await() a function defeats the
>> purpose because now aliasing can hide its presence, and w
Yury Selivanov schrieb am 30.04.2015 um 03:30:
> Asynchronous Iterators and "async for"
> --
>
> An *asynchronous iterable* is able to call asynchronous code in its
> *iter* implementation, and *asynchronous iterator* can call
> asynchronous code in its *next* m
Yury Selivanov schrieb am 30.04.2015 um 03:30:
> 1. Terminology:
> - *native coroutine* term is used for "async def" functions.
When I read "native", I think of native (binary) code. So "native
coroutine" sounds like it's implemented in some compiled low-level
language. That might be the case (cer
Guido van Rossum schrieb am 01.05.2015 um 17:28:
> On Fri, May 1, 2015 at 5:39 AM, Stefan Behnel wrote:
>
>> Yury Selivanov schrieb am 30.04.2015 um 03:30:
>>> Asynchronous Iterators and "async for"
>>> --
>>&g
Yury Selivanov schrieb am 01.05.2015 um 20:52:
> I don't like the idea of combining __next__ and __anext__.
> In this case explicit is better than implicit. __next__
> returning coroutines is a perfectly normal thing for a
> normal 'for' loop (it wouldn't to anything with them),
> whereas 'async f
Yury Selivanov schrieb am 01.05.2015 um 20:52:
> I don't like the idea of combining __next__ and __anext__.
Ok, fair enough. So, how would you use this new protocol manually then?
Say, I already know that I won't need to await the next item that the
iterator will return. For normal iterators, I co
Stefan Behnel schrieb am 02.05.2015 um 06:54:
> Yury Selivanov schrieb am 01.05.2015 um 20:52:
>> I don't like the idea of combining __next__ and __anext__.
>
> Ok, fair enough. So, how would you use this new protocol manually then?
> Say, I already know that I won't
Serhiy Storchaka schrieb am 09.05.2015 um 21:01:
> Here is a statistic for most called PyObject_INIT or PyObject_INIT_VAR for
> types (collected during running Python tests on 32-bit Linux).
I'm aware that this includes lots of tests for the Python code in the
stdlib, so these numbers are most lik
INADA Naoki schrieb am 03.10.2017 um 05:29:
> Before deferring re.compile, can we make it faster?
I tried cythonizing both sre_compile.py and sre_parse.py, which gave me a
speedup of a bit more than 2x. There is definitely space left for further
improvements since I didn't know much about the code
Stephen J. Turnbull schrieb am 23.02.2018 um 03:31:
> Barry Warsaw writes:
> > rather than having to pause to reason about what that 1-element
> > list-like syntax actually means, and 2) will this encourage even
> > more complicated comprehensions that are less readable than just
> > expanding
Chris Barker schrieb am 23.02.2018 um 20:23:
> BTW, would it be even a tiny bit more efficient to use a tuple in the inner
> loop?
>
> [g(y) for x in range(5) for y in (f(x),)]
Serhiy's optimisation does not use a loop at all anymore and folds it into
a direct assignment "y=f(x)" instead.
But in
Serhiy Storchaka schrieb am 28.03.2018 um 17:27:
> There is a subtle semantic difference between str.format() and "equivalent"
> f-string.
>
> '{}{}'.format(a, b)
> f'{a}{b}'
>
> In the former case b is evaluated before formatting a. This is equivalent to
>
> t1 = a
> t2 = b
>
Serhiy Storchaka schrieb am 28.03.2018 um 17:27:
> There is a subtle semantic difference between str.format() and "equivalent"
> f-string.
>
> '{}{}'.format(a, b)
> f'{a}{b}'
>
> In the former case b is evaluated before formatting a. This is equivalent to
>
> t1 = a
> t2 = b
>
Hi,
let me start by saying that I'm much in favour of this change. It cleans up
a lot of the function implementation and makes it much easier to integrate
efficiently with external wrapper tools.
Guido van Rossum schrieb am 14.04.2018 um 23:14:
> On Sat, Apr 14, 2018 at 2:17 AM, Jeroen Demeyer w
Petr Viktorin schrieb am 15.05.2018 um 18:36:
> On 05/15/18 05:15, Jeroen Demeyer wrote:
>> An important note is that it was never my goal to create a minimal PEP. I
>> did not aim for changing as little as possible. I was thinking: we are
>> changing functions, what would be the best way to implem
mark schrieb am 19.05.2018 um 11:15:
> At the language summit this year, there was some discussion of PEP 575.
> I wanted to simplify the PEP, but rather than modify that PEP, Nick Coghlan
> encouraged me to write an alternative PEP instead.
>
> PEP 576 aims to fulfill the same goals as PEP 575, b
Antoine Pitrou schrieb am 25.05.2018 um 23:11:
> On Fri, 25 May 2018 14:50:57 -0600
> Neil Schemenauer wrote:
>> On 2018-05-25, Antoine Pitrou wrote:
>>> Do you have something specific in mind?
>>
>> I think compressed by default is a good idea. My quick proposal:
>>
>> - Use fast compression li
Ronald Oussoren schrieb am 17.06.2018 um 14:50:
> Why did you add a tp_ccalloffset slot to the type with the actual information
> in instances instead of storing the information in a slot?
If the configuration of the callable was in the type, you would need a
separate type for each kind of calla
Victor Stinner schrieb am 18.06.2018 um 15:09:
> I tried two options to add support for FASTCALL on calling an object:
> add a flag in tp_flags and reuse tp_call, or add a new tp_fastcall
> slot. I failed to implement correctly any of these two options.
>
> There are multiple issues with tp_fastca
Victor Stinner schrieb am 19.06.2018 um 16:59:
> 2018-06-19 13:58 GMT+02:00 Jeroen Demeyer :
>> Personally, I think that you are exaggerating these issues.
>
> I'm not trying to convince you to abandon the idea. I would be happy
> to be able to use FASTCALL in more cases! I just tried to explain w
Serhiy Storchaka schrieb am 20.06.2018 um 18:56:
> 20.06.18 18:42, INADA Naoki пише:
>> I don't have any idea about changing METH_FASTCALL more.
>> If Victor and Serhiy think so, and PyPy maintainers like it too, I want
>> to make it public as soon as possible.
>
> I don't have objections against
Nick Coghlan schrieb am 28.05.2015 um 05:02:
> On 28 May 2015 at 12:51, Ned Batchelder wrote:
>> This issue has been fixed, but a day or two late for 3.5b1.
>
> Aye, we only found out about the missing test case via feedback *on*
> the beta. We had never needed to worry about it before, but it tur
Barry Warsaw schrieb am 01.06.2015 um 20:07:
> On May 30, 2015, at 10:09 AM, Serhiy Storchaka wrote:
>> Isn't it a time to assign release manager for 3.6-3.7?
>
> Indeed! Please welcome Ned Deily as RM for 3.6:
>
> https://www.python.org/dev/peps/pep-0494/
Does he know already?
Stefan
__
Victor Stinner schrieb am 20.06.2015 um 09:30:
> Are you ok to chain exceptions at C level by default?
I agree that it can be a bit non-obvious where exceptions are chained and
when they are not and my guess is that most C code simply doesn't take care
of chaining exceptions at all. If only becaus
Arc Riley schrieb am 25.06.2015 um 04:36:
> A type slot for tp_as_async has already been added (which is good!) but we
> do not currently seem to have protocol functions for awaitable types.
>
> I would expect to find an Awaitable Protocol listed under Abstract Objects
> Layer, with functions like
Andrew Steinberg via Python-Dev schrieb am 23.07.2015 um 21:04:
> Hello everybody, I am using Python 2.7 as a backbone for some
> mathematical simulations. I recently discovered a tool called AutoFDO
> and I tried compiling my own Python version, but I did not manage to get
> it working. My questio
Carl Meyer schrieb am 31.07.2015 um 06:07:
> So based on my experience with the transition to having a DSF-paid
> Fellow on the Django core team, and having watched important python-dev
> work (e.g. the core workflow stuff) linger due to lack of available
> volunteer time, I'd recommend that python
Eric V. Smith schrieb am 08.08.2015 um 03:39:
> Following a long discussion on python-ideas, I've posted my draft of
> PEP-498. It describes the "f-string" approach that was the subject of
> the "Briefer string format" thread. I'm open to a better title than
> "Literal String Formatting".
>
> I ne
Stefan Behnel schrieb am 09.08.2015 um 10:06:
> Eric V. Smith schrieb am 08.08.2015 um 03:39:
>> Following a long discussion on python-ideas, I've posted my draft of
>> PEP-498. It describes the "f-string" approach that was the subject of
>> the "Briefer st
ISAAC J SCHWABACHER schrieb am 11.08.2015 um 01:05:
> I don't know about you, but I sure like this better than what you have:
>
> code.putlines(f"""
> static char {entry.doc_cname}[] = "{
> split_string_literal(escape_bytestring(docstr))}";
>
> { # nested!
> f"""
> #if CYTHON_COMPILING_IN_CPY
Guido van Rossum schrieb am 22.08.2015 um 18:55:
> Regarding the training set, I agree that regrtest sounds to be better than
> pybench. If we make this an opt-in change, we can experiment with different
> training sets easily. (Also, I haven't seen the patch yet, but I presume
> it's easy to use a
Stefan Behnel schrieb am 22.08.2015 um 19:25:
> Guido van Rossum schrieb am 22.08.2015 um 18:55:
>> Regarding the training set, I agree that regrtest sounds to be better than
>> pybench. If we make this an opt-in change, we can experiment with different
>> training sets eas
Chris Angelico schrieb am 02.09.2015 um 23:54:
> On Thu, Sep 3, 2015 at 6:57 AM, Linda Ryan wrote:
>> I am an IT/Project Management recruiter looking to increase the available
>> pool of talent for available job placements.
>> Currently I have an opening for a python programmer/developer. Could I
Yury Selivanov schrieb am 27.01.2016 um 19:25:
> tl;dr The summary is that I have a patch that improves CPython performance
> up to 5-10% on macro benchmarks. Benchmarks results on Macbook Pro/Mac OS
> X, desktop CPU/Linux, server CPU/Linux are available at [1]. There are no
> slowdowns that I co
M.-A. Lemburg schrieb am 04.02.2016 um 13:54:
> On 04.02.2016 13:29, Victor Stinner wrote:
>> But, why not PyObject_Malloc() & PObject_Free() were not used in the
>> first place?
>
> Good question. I guess developers simply thought of PyObject_Malloc()
> being for PyObjects, not arbitrary memory b
+1 from me, too. I'm sure we can make some use of this in Cython.
Stefan
Victor Stinner schrieb am 14.04.2016 um 17:19:
> PEP: 509
> Title: Add a private version to dict
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailma
Victor Stinner schrieb am 14.04.2016 um 21:56:
> Which kind of usage do you see in Cython?
Mainly caching, I guess. We could avoid global/module name lookups in some
cases, especially inside of loops.
> Off-topic (PEP 510):
>
> I really want to experiment automatic generation of Cython code fro
Victor Stinner schrieb am 15.04.2016 um 00:33:
> 2016-04-15 0:22 GMT+02:00 Brett Cannon:
>> And even if it was GIL-free you do run the risk of two dicts ending up at
>> the same version # by simply mutating the same number of times if the
>> counters were per-dict instead of process-wide.
>
> For
Victor Stinner schrieb am 15.04.2016 um 10:20:
> Le vendredi 15 avril 2016, Stefan Behnel a écrit :
>
>> How can that be achieved? If the tag is just a sequentially growing number,
>> creating two dicts and applying one operation to the first one should give
>> both the
Larry Hastings, 04.11.2013 23:47:
> When Clinic generates a function, it knows what kind of callable it
> represents, and it names the first argument (the "PyObject *") accordingly:
>
> * module-level function ("self"),
> * method ("self"),
> * class method ("cls"), or
> * class static ("null"
Nick Coghlan, 13.11.2013 17:25:
> Note that the specific problem with just annotating the exception
> rather than a specific frame is that you lose the stack context for
> where the annotation occurred. The current chaining workaround doesn't
> just change the exception message, it also breaks the
Stefan Krah, 04.01.2014 21:00:
> Probably Rietveld did not send mail, so I mention my review comments again:
>
> larry.hastings wrote:
>> +#ifdef __GNUC__
>> +#define Py_UNUSED(name) _unused_ ## name __attribute__((unused))
>> +#else
>> +#define Py_UNUSED(name) _unused_ ## name
>> +#endif
>> +
>
Victor Stinner, 06.01.2014 14:24:
> ``struct.pack()`` is incomplete. For example, a number cannot be
> formatted as decimal and it does not support padding bytes string.
Then what about extending the struct module in a way that makes it cover
more use cases like these?
Stefan
__
Victor Stinner, 07.01.2014 19:14:
> 2014/1/7 Stefan Behnel:
>> Victor Stinner, 06.01.2014 14:24:
>>> ``struct.pack()`` is incomplete. For example, a number cannot be
>>> formatted as decimal and it does not support padding bytes string.
>>
>> Then what abo
Victor Stinner, 06.01.2014 14:24:
> Abstract
>
> Add ``bytes % args`` operator and ``bytes.format(args)`` method to
> Python 3.5.
Here is a counterproposal. Let someone who needs this feature write a
library that does byte string formatting. That properly handles it, a full
featured tool
Steven D'Aprano, 18.01.2014 02:27:
> On Fri, Jan 17, 2014 at 08:49:21AM -0800, Ethan Furman wrote:
>> %s is restricted in what it will accept::
>>
>> - input type supports Py_buffer?
>> use it to collect the necessary bytes
>
> Can you give some examples of what types support Py_buffer? Pres
Nick Coghlan, 25.01.2014 10:20:
> On 25 January 2014 17:44, Nick Coghlan wrote:
>> On 25 January 2014 01:07, Larry Hastings wrote:
>>> c) Functions that accept an 'int' when they mean 'boolean' (aka the
>>>"ints instead of bools" problem)
>>>
>>>Solution:
>>> 1) Use "bool".
>>> 2)
Hi,
for two days now, the signature embedding tests in Cython have been failing
with this (doctest) error:
"""
Expected:
f_D(long double D) -> long double
Got:
f_DNone
f_D(long double D) -> long double
"""
https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests/1869/ARCH=
> On Wed, Jan 29, 2014 at 10:25 PM, Stefan Behnel wrote:
>> for two days now, the signature embedding tests in Cython have been failing
>> with this (doctest) error:
>>
>> """
>> Expected:
>> f_D(long double D) -> long double
>>
Larry Hastings, 30.01.2014 08:14:
> On 01/29/2014 10:25 PM, Stefan Behnel wrote:
>> for two days now, the signature embedding tests in Cython have been failing
>> with this (doctest) error:
>>
>> """
>> Expected:
>> f_D(long double D) -
Jeff Allen, 16.02.2014 11:23:
> I spend a *lot* of time working with the Python test suite on behalf of
> Jython, so I appreciate the care CPython puts into its testing. To a large
> extent, tests written for CPython drive Jython development: I suspect I
> work with a lot more failing tests than an
Chris Angelico, 21.02.2014 04:15:
> Just as PEP 308 introduced a means of value-based conditions in an
> expression, this system allows exception-based conditions to be used
> as part of an expression.
> [...]
> This currently works::
>
> lst = [1, 2, None, 3]
> value = lst[2] or "No value
Stefan Behnel, 23.02.2014 19:51:
> Cython has typed
> assignments, so a straight forward idea would be to handle TypeErrors in
> assignments like this:
>
> cdef str s
> s = x except TypeError: str(x)
Similar code in Python would be this:
from array import arra
Guido van Rossum, 10.04.2014 03:08:
> - Jukka Lehtosalo gave a talk and answered questions about mypy, his design
> and implementation of pragmatic type annotations (no new syntax required,
> uses Python 3 function annotations).
FWIW, signature type annotations aren't enough for a static compiler
Stefan Behnel, 12.04.2014 19:11:
> Guido van Rossum, 10.04.2014 03:08:
>> - Jukka Lehtosalo gave a talk and answered questions about mypy, his design
>> and implementation of pragmatic type annotations (no new syntax required,
>> uses Python 3 function annotations).
>
Brett Cannon, 14.04.2014 23:51:
> It was realized during PyCon that since we are freezing importlib we could
> now consider freezing all the modules to cut out having to stat or read
> them from disk. So for day 1 of the sprints I I decided to hack up a
> proof-of-concept to see what kind of perfor
Nick Coghlan, 11.05.2014 01:01:
> As you point out, most language development teams do very little to try to
> educate their users about security issues. The consequences of that are
> clearly visible in the world around us: when security is treated as an
> optional afterthought, you get widespread
Steven D'Aprano, 01.06.2014 10:11:
> Briefly, I have a choice of algorithm for the median function in the
> statistics module. If I target CPython, I will use a naive but simple
> O(N log N) implementation based on sorting the list and returning the
> middle item. (That's what the module current
Maciej Fijalkowski, 02.06.2014 10:48:
> On Mon, Jun 2, 2014 at 10:43 AM, Victor Stinner wrote:
>> 2014-06-01 10:11 GMT+02:00 Steven D'Aprano :
>>> My feeling is that the CPython standard library should be written for
>>> CPython,
>>
>> Right. PyPy, Jython and IronPython already have their "own" sta
Sturla Molden, 03.06.2014 17:13:
> Stefan Behnel wrote:
>
>> Thus my proposal to compile the modules in CPython with Cython, rather than
>> duplicating their code or making/keeping them CPython specific. I think
>> reducing the urge to reimplement something in C i
Sturla Molden, 03.06.2014 22:51:
> Stefan Behnel wrote:
>> So the
>> argument in favour is mostly a pragmatic one. If you can have 2-5x faster
>> code essentially for free, why not just go for it?
>
> I would be easier if the GIL or Cython's use of it was redesig
Jeroen Demeyer schrieb am 05.07.2018 um 16:53:
> The only case when this handling of keywords is suboptimal is when using
> **kwargs. In that case, a dict must be converted to a tuple. It looks hard
> to me to support efficiently both the case of fixed keyword arguments
> (f(foo=x)) and a keyword d
INADA Naoki schrieb am 07.07.2018 um 06:10:
> How often "custom method type" are used?
>
> I thought Cython use it by default.
> But when I read code generated by Cython, I can't find it.
> It uses normal PyMethodDef and tp_methods.
>
> I found CyFunction in Cython repository, but I can't find
>
INADA Naoki schrieb am 07.07.2018 um 10:08:
> Thank you. Do you plan to make it default when PEP 580 is accepted
> and implemented?
It will become the default at some point, I'm sure. Note that we will still
have to support older Python versions, though, currently 2.6+, which would
not have the i
Hi Serhiy!
Serhiy Storchaka schrieb am 07.07.2018 um 10:55:
> There is my idea. Split every of keyword argument parsing functions on two
> parts. The first part linearize keyword arguments, it converts positional
> and keyword arguments (in whatever form they were presented) into a linear
> array
Nick Coghlan schrieb am 07.07.2018 um 16:14:
> when the new calling
> convention is tied to a protocol that any type can implement (as PEP
> 580 proposes), the concern doesn't even arise.
Nick, +1 to all of what you said in your reply, and I also really like the
fact that this proposal is creating
INADA Naoki schrieb am 07.07.2018 um 17:16:
>> 2. The new API should be used internally so that 3rd party extensions
>> are not second class citizens in term of call performance.
>
> These PEPs proposes new public protocol which can be implemented
> by 3rd party extensions, especially Cython.
> In
Jeroen Demeyer schrieb am 08.07.2018 um 09:07:
> On 2018-07-07 10:55, Serhiy Storchaka wrote:
>> The first part of
>> handling arguments can be made outside of the C function, by the calling
>> API.
>
> Sure, it could be done but I don't see the advantage. I don't think you
> will gain performance
INADA Naoki schrieb am 11.07.2018 um 02:12:
> On Tue, Jul 10, 2018 at 10:20 PM Antoine Pitrou wrote:
>> On Tue, 10 Jul 2018 21:59:28 +0900
>> INADA Naoki wrote:
>>>
>>> Then, the function is called from another C extension like this:
>>>
>>> PyObject_CallFunction(func, "n", 42);
>>>
>>> Currently,
INADA Naoki schrieb am 11.07.2018 um 02:01:
> On Wed, Jul 11, 2018 at 7:47 AM Victor Stinner wrote:
>> I proposed something simpler, but nobody tried to implement it.
>> Instead of calling the long and complex PyArg_Parse...() functions,
>> why not generating C code to parse arguments instead? The
Guido van Rossum schrieb am 21.07.2018 um 22:46:
> Given the cost of a mistake here I recommend a higher standard.
May I ask what you think the "cost of a mistake" is here?
Jeroen has already implemented most of this, and is willing to provide
essentially a shrink-wrapped implementation. He has s
Guido van Rossum schrieb am 22.07.2018 um 01:14:
> The cost would be if we were to end up maintaining all that code and it
> wouldn’t make much difference.
Well, this is exactly my point. Someone has to maintain the *existing* code
base and help newcomers to get into it and understand it. This is
Jeroen Demeyer schrieb am 22.07.2018 um 22:54:
> On 2018-07-22 22:32, Antoine Pitrou wrote:
>> - more importantly, issue26110 is entirely internal changes, while you
>> are proposing to add a new protocol (which is like a new API)
>
> Just to make sure I understand you: your point is that it's
Jeroen Demeyer schrieb am 30.07.2018 um 16:40:
> On 2018-07-30 15:35, INADA Naoki wrote:
>> As repeatedly said, PEP 580 is very complicated protocol
>> when just implementing callable object.
>
> Can you be more concrete what you find complicated? Maybe I can improve the
> PEP to explain it more.
Antoine Pitrou schrieb am 31.07.2018 um 09:45:
> On Tue, 31 Jul 2018 09:27:03 +0200
> Jeroen Demeyer wrote:
>> On 2018-07-31 08:58, Antoine Pitrou wrote:
>>> I think Stefan is right that we
>>> should push people towards Cython and alternatives, rather than direct
>>> use of the C API (which peopl
Jeroen Demeyer schrieb am 31.07.2018 um 14:01:
> On 2018-07-31 12:56, Victor Stinner wrote:
>> I would be nice to be able to use something to "generate" C
>> extensions, maybe even from pure Python code.
>
> Cython has a "pure Python mode" which does exactly that. There are several
> ways to inclu
Brett Cannon schrieb am 01.08.2018 um 18:17:
> On Tue, 31 Jul 2018 at 13:42 Stefan Behnel wrote:
>> Antoine Pitrou schrieb am 31.07.2018 um 09:45:
>>> Also, a C extension can be built-in (linked statically into the
>>> interpreter), which I think would be hard to do
Antoine Pitrou schrieb am 04.08.2018 um 15:57:
> Le 04/08/2018 à 15:13, Nick Coghlan a écrit :
>>
>> It'd be *really* nice to at least be able to write some of the C API
>> tests directly in Cython rather than having to fiddle about with
>> splitting the test between the regrtest parts that actuall
Ronald Oussoren via Python-Dev schrieb am 06.08.2018 um 15:25:
>> On 5 Aug 2018, at 18:14, Nick Coghlan wrote:
>> On 5 August 2018 at 18:06, Ronald Oussoren wrote:
>>> I’m not sure if I understand this, ctypes and cffi are used to access C APIs
>>> without writing C code including the CPython API (
Hi,
this is getting a bit out of scope for this list. I propose to move further
questions about general Cython usage to he cython-users mailing list.
Matěj Cepl schrieb am 08.08.2018 um 12:44:
> On 2018-08-06, 15:13 GMT, Stefan Behnel wrote:
>> Not sure I understand this correctly, bu
Hi,
coming back to PEP 489 [1], the multi-phase extension module
initialization. We originally designed it as an "all or nothing" feature,
but as it turns out, the "all" part is so difficult to achieve that most
potential users end up with "nothing". So, my question is: could we split
it up so tha
Petr Viktorin schrieb am 10.08.2018 um 11:51:
> On 08/10/18 11:21, Stefan Behnel wrote:
>> coming back to PEP 489 [1], the multi-phase extension module
>> initialization. We originally designed it as an "all or nothing" feature,
>> but as it turns out, the "
Antoine Pitrou schrieb am 11.08.2018 um 15:19:
> On Fri, 10 Aug 2018 19:15:11 +0200 Armin Rigo wrote:
>> Currently, the C API only allows Psyco-style JITting (much slower than
>> PyPy). All three other points might not be possible at all without a
>> seriously modified C API. Why? I have no proo
Petr Viktorin schrieb am 10.08.2018 um 13:48:
> Would this be better than a flag + raising an error on init?
Ok, I've implemented this in Cython for now, to finally move the PEP-489
support forward. The somewhat annoying drawback is that module reloading
previously *seemed* to work, simply because
Antoine Pitrou schrieb am 23.08.2018 um 09:04:
> On Thu, 23 Aug 2018 08:07:08 +0200
> Jeroen Demeyer wrote:
>>> - the maintenance problem (how do ensure we can change small things in
>>>the C API, especially semi-private ones, without having to submit PRs
>>>to Cython as well)
>>
>> Why d
Greg Ewing schrieb am 23.08.2018 um 03:34:
> Neil Schemenauer wrote:
>> Perhaps a "argument clinic on steroids" would be the proper
>> approach. So, extensions would mostly be written in C. However, we
>> would have a pre-processor that does some "magic" to make using the
>> Python API cleaner.
>
Yury,
given that people are starting to quote enthusiastically the comments you
made below, let me set a couple of things straight.
Yury Selivanov schrieb am 07.08.2018 um 19:34:
> On Mon, Aug 6, 2018 at 11:49 AM Ronald Oussoren via Python-Dev wrote:
>
>> I have no strong opinion on using Cython
Yury Selivanov schrieb am 04.09.2018 um 18:19:
> On Sat, Sep 1, 2018 at 6:12 PM Stefan Behnel wrote:
>> Yury Selivanov schrieb am 07.08.2018 um 19:34:
>>> The first goal is to compile mypy with it to make it faster, so I hope
>>> that the project will be completed.
>&
Carl Shapiro schrieb am 18.09.2018 um 22:44:
> How might people feel about using the linker to bundle a list of pre-loaded
> modules into a single-file executable?
One way to do that would be to compile Python modules with Cython and link
them in statically, instead of compiling them to .pyc files
1 - 100 of 633 matches
Mail list logo
