[issue34762] Change contextvars C API to use PyObject

Stefan Behnel added the comment: > because Py_buffer isn't a PyObject at all :) It owns a PyObject reference to the buffer owner, though. -- nosy: +scoder ___ Python tracker <https://bugs.python.org

Re: [Cython] Preparing the language level change - Re: [cython-users] Cython 0.29 beta 1 released

Jeroen Demeyer schrieb am 20.09.2018 um 10:59: > On 2018-09-20 10:15, Jeroen Demeyer wrote: >> On 2018-09-20 07:55, Stefan Behnel wrote: >>> I can see that this would be helpful. It's unfortunate, though, that this >>> would introduce a temporary option that

Re: [Python-Dev] Store startup modules as C structures for 20%+ startup speed improvement?

Larry Hastings schrieb am 14.09.2018 um 23:27: > What the patch does: it takes all the Python modules that are loaded as > part of interpreter startup and deserializes the marshalled .pyc file into > precreated objects stored as static C data. What about the small integers cache? The C serialisati

Re: [Python-Dev] Store startup modules as C structures for 20%+ startup speed improvement?

Carl Shapiro schrieb am 20.09.2018 um 20:21: > On Wed, Sep 19, 2018 at 12:32 AM, Stefan Behnel wrote: > >> Also, one thing that would be interesting to find out is whether constant >> Python data structures can actually be pre-allocated in the data segment >> (and I m

[Cython] Preparing the language level change - Re: [cython-users] Cython 0.29 beta 1 released

Jeroen Demeyer schrieb am 18.09.2018 um 10:23: > On 2018-09-16 17:48, Stefan Behnel wrote: >> * Cython now emits a warning when no ``language_level`` (2 or 3) is set >>    explicitly > > Currently, language_level=3 breaks a lot of code due to unicode_literals. > As I m

[issue34739] Get rid of tp_getattro in xml.etree.ElementTree.XMLParser

Stefan Behnel added the comment: Nice. Looks good to me. -- ___ Python tracker <https://bugs.python.org/issue34739> ___ ___ Python-bugs-list mailing list Unsub

Re: [Cython] Safer exception handling

Robert Bradshaw schrieb am 17.09.2018 um 15:44: > One of the pain points in Cython is that one must explicitly annotate > non-object returning functions with except clauses. Would it be worth > trying to change the default here, making exception-suppressing opt-in > rather than opt-out? > > There

Re: [Python-Dev] Store startup modules as C structures for 20%+ startup speed improvement?

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

Re: [Cython] Safer exception handling

Robert Bradshaw schrieb am 17.09.2018 um 15:44: > One of the pain points in Cython is that one must explicitly annotate > non-object returning functions with except clauses. Would it be worth > trying to change the default here, making exception-suppressing opt-in > rather than opt-out? > > There

[Cython] Cython 0.29 beta 1 released

Hi all, after half a year of development, many community pull requests and a lot of feedback and good ideas in online discussions and at conferences, I'm proud to release the first beta of Cython 0.29. This is a major feature release that comes with many great improvements and several important bu

Re: [Cython] Cython 3.0 and "unicode_literals"

Jeroen Demeyer schrieb am 22.08.2018 um 13:10: > On 2018-08-19 08:26, Stefan Behnel wrote: >> Should we make that a new directive rather than a language level? Like >> "py2_str=str"? That would allow its use together with language_level=3 >> already in the ne

[issue34600] python3 regression ElementTree.iterparse() unable to capture comments

Stefan Behnel added the comment: lxml supports "comment" and "pi" as event types in iterparse (or, more specifically, in the XMLPullParser). If someone wants to implement this for (c)ElementTree, I'd be happy to review the PR. https://lxml.de/api/lxml.etree

[issue34600] python3 regression ElementTree.iterparse() unable to capture comments

Stefan Behnel added the comment: There are dedicated handler methods that you can implement: "def comment(self, comment)" and "def pi(self, target, data)". Both (c)ElementTree and lxml support those. I think the "target" argument to the parser is a bit unde

Re: [Cython] Hooking tp_clear()

Jeroen Demeyer schrieb am 07.09.2018 um 10:14: > On 2018-09-07 06:35, Stefan Behnel wrote: >> Maybe you actually want "tp_finalize"? >> >> https://www.python.org/dev/peps/pep-0442/ >> >> Cython moves "__del__" methods there in Py3.4+. > >

Re: [Cython] Hooking tp_clear()

Jeroen Demeyer schrieb am 06.09.2018 um 22:54: > Cython's __dealloc__ special method is meant to deal with cleaning up > instances of cdef classes. However, this hooks tp_dealloc() and does not > have meaningful access to Python attributes, since those might have been > cleared by tp_clear(). > >

Re: [Python-Dev] Use of 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. >&

[issue34570] Segmentation fault in _PyType_Lookup

Stefan Behnel added the comment: Thanks for the report. Is the place where it crashes always the same? Could it be that your system is running out of resources, e.g. RAM? -- nosy: +scoder ___ Python tracker <https://bugs.python.org/issue34

Re: [Python-Dev] Use of Cython

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

Re: [Python-ideas] Why shouldn't Python be better at implementing Domain Specific Languages?

Matthew Einhorn schrieb am 31.08.2018 um 20:57: > with model: > with Dense(): > units = 64 > activation = 'relu' > input_dim = 100 > > with Dense(): > units = 10 > activation = 'softmax' This looks like it could use 'class' instead of 'with'. Stefa

Re: Calling an unbound method in C using the Public API

Matthieu Dartiailh schrieb am 29.08.2018 um 16:33: > I am one of the maintainer of the atom library > (https://github.com/nucleic/atom ). This > library provides low-memory footprint Python objects, descriptors and > containers enforcing type validation, implemen

[issue32973] Importing the same extension module under multiple names breaks non-reinitialisable extension modules

Stefan Behnel added the comment: FYI, I've updated Cython's module import checks to include an interpreter check. This (multi-file) test shows the new behaviour, which is to raise an ImportError on module creation when it detects a different interpreter than during the init

[issue32973] Importing the same extension module under multiple names breaks non-reinitialisable extension modules

Stefan Behnel added the comment: Well, first of all, it's better than a crash. :) Secondly, I'm sure NumPy doesn't currently support subinterpreters, just like most other extension modules. If I'm not mistaken, an interpreter switch can be detected through the interpre

[issue32973] Importing the same extension module under multiple names breaks non-reinitialisable extension modules

Stefan Behnel added the comment: I think the best work-around for now is to implement a bit of PEP 489, including a module create function that always returns the same static module reference instead of creating a new one after the first call, and a module exec function that simply returns

[issue34461] Availability of parsers in etree initializer

Stefan Behnel added the comment: The normal way to use ElementTree is to import the ElementTree module from the xml.etree package. Why do you think that needs to change? And why do you want to enforce an import of all modules before you even know which of them the users actually wants

[issue33187] Document ElementInclude (XInclude) support in ElementTree

Change by Stefan Behnel : -- versions: +Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue33187> ___ ___ Python-bug

Re: [Python-Dev] Let's change to C API!

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. >

Re: [Python-Dev] Let's change to C API!

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

Re: [Cython] Cython 0.29 – or 29.0 ?

Am 18. August 2018 21:11:14 MESZ schrieb Jeroen Demeyer: >>> Basically I am asking for >>> >>> type("foo") is str >>> >>> both on Python 2 and Python 3. >> >> That's another breaking change > >I'm not following here... what I'm asking is how Cython behaves >currently (with language_level=2). But

Re: [Cython] Cython 0.29 – or 29.0 ?

Am 18. August 2018 12:06:15 MESZ schrieb Jeroen Demeyer: >On 2018-08-18 10:52, Robert Bradshaw wrote: >> Do the existing c_string_type and c_string_encoding directives not >> cover this usecase? > >Those seem to refer to C strings, I am talking about the Python type of >string literals. > >> I supp

[Cython] Preparing Cython 3.0 with breaking changes

Hi all, following the versioning discussion, I created a milestone to collect (breaking) changes that should go into the future Cython 3.0 release. https://github.com/cython/cython/milestone/58 While a major version change is a good time to fix things that, in retrospect, have led us too far in

[issue14465] xml.etree.ElementTree: add feature to prettify XML output

Stefan Behnel added the comment: > Serialization of ElementTree in the stdlib is much slower than in lxml (see > issue25881). Perhaps it should be implemented in C. But it should be kept > simple for this. Should I say it? That's a first class use case for Cython. > Prett

[issue14886] json C vs pure-python implementation difference

Stefan Behnel added the comment: FWIW, the C implementation of the sequence encoder uses PySequence_Fast(), so adding a lower priority instance check that calls the same encoding function would solve this. https://github.com/python/cpython/blob/cfa797c0681b7fef47cf93955fd06b54ddd09a7f

Re: [Cython] Cython 0.29 – or 29.0 ?

Yury V. Zaytsev schrieb am 17.08.2018 um 10:59: > On Fri, 17 Aug 2018, James C. McPherson wrote: >> 1.0 runs the risk of hitting "never install a 1.0 release" habits. > > How about 2.9.0 ;-) ? Sold! :) Proposal: we'll release a 2.9.0 next, which gives a warning that users should explicitly enabl

Re: [Cython] Cython 0.29 – or 29.0 ?

Robert Bradshaw schrieb am 16.08.2018 um 00:48: > If we're going to ditch the 0.x, I'd go for 1.0 as well. I'm a huge fan of > semantic versioning. I'm ok with it, just fear that it might become excessive for Cython (ok, I'm the one who proposed jumping to 29.0, but...). Basically, any time we add

Re: lxml namespace as an attribute

Skip Montanaro schrieb am 15.08.2018 um 23:25: > Much of XML makes no sense to me. Namespaces are one thing. If I'm > parsing a document where namespaces are defined at the top level, then > adding namespaces=root.nsmap works when calling the xpath method. I > more-or-less get that. > > What I don

[Cython] Cython 0.29 – or 29.0 ?

Hello everyone, I had a request during my talk at EuroPython this year to help the aspiring Cython users out there convince their managers to accept Cython in their tech stack. Cython has been around for more than a decade now, has been in heavy production use pretty much all of that time, has pr

Re: [Python-ideas] Does jargon make learning more difficult?

Michael Selik schrieb am 14.08.2018 um 21:42: > This is supported by education research. Some light Googling found a > study on the topic [0] that is consistent with my own observations. OTx2, and no offence, but … this is supported by research as well. People tend to search just long enough to fi

Re: [Python-ideas] Syntactic sugar to declare partial functions

Michel Desmoulin schrieb am 09.08.2018 um 18:59: > I'd rather have functools.partial() to be added as a new method on > function objects. > >> from functools import partial >> >> def add(x:int,y:int)->int: >> returnx +y >> >> add_2 = partial(add,2) > > Would become: > > add_2 = add.partial(2

[issue24076] sum() several times slower on Python 3 64-bit

Stefan Behnel added the comment: FWIW, a PGO build of Py3.7 is now about 20% *faster* here than my Ubuntu 16/04 system Python 2.7, and for some (probably unrelated) reason, the system Python 3.5 is another 2% faster on my side. IMHO, the only other thing that seems obvious to try would be

[issue34376] Improve accuracy of math.hypot() and math.dist()

Stefan Behnel added the comment: Could we maybe make an educated guess based on absmin and absmax whether scaling is needed or not? -- nosy: +scoder ___ Python tracker <https://bugs.python.org/issue34

Re: [Python-Dev] Can we split PEP 489 (extension module init) ?

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

Re: [Python-Dev] Let's change to C API!

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

Re: [Python-Dev] Can we split PEP 489 (extension module init) ?

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 "

[Python-Dev] Can we split PEP 489 (extension module init) ?

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

Re: [Python-Dev] Use of Cython

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

Re: [Python-Dev] Use of Cython

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 (

[issue32797] Tracebacks from Cython modules no longer work

Stefan Behnel added the comment: Or, define a new "get_sourcemap()" method that could return additional metadata, e.g. a line number mapping. -- ___ Python tracker <https://bugs.python.o

[issue32797] Tracebacks from Cython modules no longer work

Stefan Behnel added the comment: > SageMath is the only project that I know which actually installs .pyx sources. Ah, right. I wrongly remembered that they are automatically included in binary packages, but that only applies to .py source of Cython compiled Python modules (which

[issue32797] Tracebacks from Cython modules no longer work

Stefan Behnel added the comment: FWIW, I can see that Cython is a special case because it can control the source line mapping and reporting through the C-API. Other code generators might not be able to do that, e.g. for a DSL or template language that gets translated to Python code, for

Re: [Python-Dev] Use of Cython

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

[issue34309] Trouble when reloading extension modules.

Stefan Behnel added the comment: a) Probably not something to fix in released versions any more, so increasing version from 3.5 to 3.8. b) Regarding shared library unloading and the problems mentioned, I'm also not sure if there is a way to safely unload transitively imported libraries

[issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles

Change by Stefan Behnel : -- nosy: +scoder ___ Python tracker <https://bugs.python.org/issue34309> ___ ___ Python-bugs-list mailing list Unsubscribe:

Re: [Python-Dev] Using Cython for the stdlib (was: Let's change to C API!)

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

Re: [Python-Dev] Let's change to C API!

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

Re: [Python-Dev] Let's change to C API!

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

[issue34280] METH_NOARGS: no longer require that second arg is NULL

Stefan Behnel added the comment: Agree with Raymond. If the goal is to pass something else, then functions that want to make use of that "something else" have to be modified anyway, in which case also changing the call type wouldn't hurt (assuming the new value still fit

Re: [Python-Dev] [PEP 576/580] Reserve one type slot for Cython

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.

[issue33089] Add multi-dimensional Euclidean distance function to the math module

Stefan Behnel added the comment: >> Commutativity guarantees can be delivered by sorting arguments before >> summation. > No thanks -- that's too expensive for such a small payoff. Since I don't really see people use this on vectors with hundreds of dimensions, l

Re: Tracking a memory leak in C extension - interpreting the output of PYTHONMALLOCSTATS

Bartosz Golaszewski schrieb am 24.07.2018 um 13:05: > Ok I've found the problem and it's my fault. From tp_dealloc's documentation: > > --- > The destructor function should free all references which the instance > owns, free all memory buffers owned by the instance (using the freeing > function co

Re: [Python-ideas] A better (simpler) approach to PEP 505

David Mertz schrieb am 23.07.2018 um 16:12: > The need addressed by PEP 505 is real; it's also MUCH more niche and > uncommon than something that would merit new syntax. Moreover, the actual > legitimate purpose served by the PEP 505 syntax is easily served by > existing Python simply by using a w

Re: [Python-ideas] slice[] to get more complex slices

Stephan Hoyer schrieb am 23.07.2018 um 18:01: > On Mon, Jul 23, 2018 at 4:24 AM Paul Moore wrote: > >> I thought the reason the proposal got nowhere was because it's pretty >> simple to define it yourself: >> >> >>> class SliceHelper: >> ... def __getitem__(self, slice): >> ... return

Re: [Python-Dev] Benchmarks why we need PEP 576/579/580

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

Re: [Python-ideas] slice[] to get more complex slices

Todd schrieb am 22.07.2018 um 21:03: > For basic slices, the normal "slice(start, stop, step)" syntax works well. > But it becomes much more verbose to create more complicated slices that you > want to re-use for multiple multidimensional data structures, like numpy, > pandas, xarray, etc. > > One

Re: [Python-Dev] Benchmarks why we need PEP 576/579/580

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

Re: [Python-Dev] Benchmarks why we need PEP 576/579/580

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

Re: [Python-ideas] Performance improvements via static typing

Michael Hall schrieb am 19.07.2018 um 15:51: > While I am aware of projects like Cython and mypy, it seems to make sense > for CPython to allow optional enforcement of type hints, with compiler > optimizations related to it to be used. While this would not receive the > same level of performance be

[issue34160] ElementTree not preserving attribute order

Stefan Behnel added the comment: At least for lxml, attributes were never specified to have a sorted order (although attribute dicts are sorted on *input*, to give a *predictable* order as in ET), and the tutorial says: "Attributes are just unordered name-value pairs". Howeve

[issue34151] use malloc() for better performance of some list operations

Stefan Behnel added the comment: Nice! Patch looks good to me, minus the usual naming nit-pick. -- nosy: +scoder versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issue34

Re: [Python-Dev] Micro-benchmarks for PEP 580

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

Re: [Python-Dev] Micro-benchmarks for PEP 580

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,

Re: [Python-Dev] On the METH_FASTCALL calling convention

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

[issue34068] Assertion failure in _PyType_Lookup

Stefan Behnel added the comment: I added this assertion exactly for the purpose of finding this kind of bug. It means that some code tried to look up an attribute with a live exception set, which previously could swallow the exception in certain situations, and even if not, it is always the

Re: [Python-Dev] PEP 575, 576, 579 and 580

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

Re: [Python-Dev] PEP 575, 576, 579 and 580

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

Re: Thread-safe way to add a key to a dict only if it isn't already there?

Marko Rauhamaa schrieb am 07.07.2018 um 15:41: > Steven D'Aprano : >> On Sat, 07 Jul 2018 02:51:41 +0900, INADA Naoki wrote: >>> D.setdefault('c', None) >> >> Oh that's clever! > > Is that guaranteed to be thread-safe? The documentation ( s://docs.python.org/3/library/stdtypes.html#dict.setdefault

Re: [Python-Dev] On the METH_FASTCALL calling convention

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

Re: [Python-Dev] PEP 579 and PEP 580: refactoring C functions and methods

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

Re: Looking for a recent quote about dynamic typing, possibly on this list

Ben Finney schrieb am 07.07.2018 um 03:38: > Steven D'Aprano writes: > >> Somebody gave a quote about dynamic typing, along the lines of >> >> "Just because a language allows a lot of dynamic features, doesn't mean >> people's code uses a lot of dynamism." > > You did refer us to http://lambda-

Re: [Python-Dev] PEP 579 and PEP 580: refactoring C functions and methods

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 >

Re: [Python-Dev] On the METH_FASTCALL calling convention

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

[Cython] Cython compilation speed vs. installed binary module sizes

Hi all, when building Cython, it compiles a couple of its own modules. I was interested in what this brings for the separate parts of the compiler, so I used the compilation of Cython's compiled modules as benchmark and compiled the separate parts incrementally, using the latest CPython 3.7.0. Ba

Re: [Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579

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

[Python-Dev] C-level calling (was: PEP 575 (Unifying function/method classes) update)

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

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

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

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

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

[issue33815] List a = []*19 doesn't create a list with index length of 19

Stefan Behnel added the comment: You misunderstood what the code is doing, and the response that you got indicates that the bug tracker is not the right place to discuss this misunderstanding. If you want to discuss this further, please ask on the Python mailing list (python-l...@python.org

[issue33671] Efficient zero-copy for shutil.copy* functions (Linux, OSX and Win)

Stefan Behnel added the comment: Regarding the benchmarks, just to be sure, did you try reversing the run order to make sure you don't get unfair caching effects for the later runs? -- ___ Python tracker <https://bugs.python.org/is

[issue33671] Efficient zero-copy for shutil.copy* functions (Linux, OSX and Win)

Stefan Behnel added the comment: Nice, I really like this. Apart from the usual bit of minor style issues, I couldn't see anything inherently wrong with the PR, but I'll leave the detailed reviews to those who'd have to maintain the code in the future. :) -

[Cython] Should we start requiring "language_level=2" for .pyx files?

Hi, Python 3 is clearly taking over the world these days, so it starts feeling arcane to require Py2 syntax in .pyx files. Increasingly, it means that people cannot just rename .py files anymore to start optimising them, because the .py file has a high chance of being written in Py3 syntax. Event

Re: [Python-Dev] PEP 574 (pickle 5) implementation and backport available

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

Re: List replication operator

Peter Otten schrieb am 25.05.2018 um 09:28: > Steven D'Aprano wrote: > >> But what do people think about proposing a new list replication with copy >> operator? >> >> [[]]**5 >> >> would return a new list consisting of five shallow copies of the inner >> list. > > Yet another arcanum to learn

Re: List replication operator

Steven D'Aprano schrieb am 25.05.2018 um 04:25: > On Thu, 24 May 2018 15:12:09 -0400, Ned Batchelder wrote: > >> On 5/24/18 2:17 PM, Steven D'Aprano wrote: > [...] >>> But what do people think about proposing a new list replication with >>> copy operator? >>> >>> [[]]**5 >>> >>> would return

Re: Getting Unicode decode error using lxml.iterparse

digi...@gmail.com schrieb am 23.05.2018 um 00:56: > I'm trying to read my iTunes library in Python using iterparse. My current > stub is: > > Snip > > import sys > import datetime > import xml.etree.ElementTree as ET > import argparse > import re > > class Library: > > unmars

Re: Getting Unicode decode error using lxml.iterparse

dieter schrieb am 23.05.2018 um 08:25: > If the encoding is not specified, "lxml" will try to determine it > and finally defaults to "utf-8" (which seems to be the correct encoding > for your case). Being an XML parser, it does not do that. XML parsers are designed to reject non-wellformed content

Re: [Python-Dev] PEP: 576 Title: Rationalize Built-in function classes

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

[issue19251] bitwise ops for bytes of equal length

Stefan Behnel added the comment: I'd second the proposal of considering the "array.array" type for this, instead of the bytes/bytearray types. Why? Because it is somewhat of a niche case after all, and the bytes type seems too exposed for it. Also, array.array supports more di

Re: [Cython] Contribution

Hi Patrick! Patrick Kunzmann schrieb am 18.05.2018 um 10:50: > I would like to contribute to the Cython project but it is difficult for me > to find an angle to understand the code base. Is there some kind of > developers' tutorial or another resource to start with? Welcome, looks like you found

Re: [Python-ideas] OT: slowing rotation [was: High Precision datetime]

Greg Ewing schrieb am 18.05.2018 um 10:05: > Ethan Furman wrote: >> How long before the earth stops rotating?  > > Apparently about 1.9 trillion years. So, does that mean we now need to hold our breath for 1.9 british trillion years or 1.9 american trillion years? Assuming you were referring to

[issue33561] Add .tostring() method to xml.etree.ElementTree.Element

Stefan Behnel added the comment: Sorry, but you are proposing an API extension here that provides no benefits but duplicates existing functionality in a less versatile place. This is not going to happen. The second proposal (str(xml)) is actually not very helpful as it does not allow any

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

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

<    3   4   5   6   7   8   9   10   11   12   >