Re: [Python-Dev] Pre-PEP: Redesigning extension modules

Eric Snow, 08.09.2013 00:22: > On Mon, Sep 2, 2013 at 7:02 AM, Nick Coghlan wrote: > >> The hook API I currently have in mind is a two step initialisation: >> >> PyImport_PrepareNAME (optional) >> PyImport_ExecNAME >> > > Should we also look at an API change for the initfunc() of PyImport

Re: [Python-Dev] [RELEASED] Python 3.4.0a2

Ned Deily, 09.09.2013 21:29: > 3.4.0a2 also contains a new batteries-included feature for OS X > users. The python.org 64-bit/32-bit installer now includes its own > private version of Tcl/Tk 8.5.14 so it is finally no longer necessary to > install a third-party version of Tcl/Tk 8.5 to workaro

Re: [Python-Dev] dict.setdefault(object, object) instead of "sys.intern()" (was Re: sys.intern should work on bytes)

Jesus Cea, 20.09.2013 15:46: > On 20/09/13 15:33, Benjamin Peterson wrote: >> Well, the pickler should memoize bytes objects if you have lots of >> the same one in a pickle... > > Only if they are the very same object. Not diferent bytes objects with > the same value. Pickle doesn't do "a==b" but

[Python-Dev] project culture: take responsibility for your commits

Hi, I'm looking back on a rather unpleasant experience that I recently had in this developer community. Actually, twice by now. Here's what I take from it: You should take responsibility for your commits. Sounds like a simple thing - in theory. People make mistakes, that's normal. You can't alwa

Re: [Python-Dev] project culture: take responsibility for your commits

Stephen, thank you for your very thoughtful answer. Stephen J. Turnbull, 03.10.2013 04:23: > Stefan Behnel writes: > > > Hi, I'm looking back on a rather unpleasant experience that I > > recently had in this developer community. Actually, twice by > > now. He

Re: [Python-Dev] PEP 451: ModuleSpec

Eric Snow, 05.10.2013 07:18: > After a few rounds on import-sig PEP 451 is really for general > consumption. I also have a patch up now. > > HTML: http://www.python.org/dev/peps/pep-0451/ > implementation: http://bugs.python.org/issue18864 Thanks, I'm happy that this is moving forward. > Your

Re: [Python-Dev] project culture: take responsibility for your commits

Ethan, I take your three points and apologise for not making it a pleasant experience for any of us. Regarding the rest: Ethan Furman, 04.10.2013 16:30: > starting a trouble ticket with accusations ... and, in fact, I didn't. > that something was snuck in and done behind peoples' backs Sorry

Re: [Python-Dev] Reduce memory footprint of Python

Benjamin Peterson, 06.10.2013 17:41: > 2013/10/6 Victor Stinner: >> unittest doesn't look to release memory (the TestCase class) after the >> execution of a test. > > Is it important to optimize unittests for memory usage? Maybe "optimise" isn't the best word, but test suites can sometimes be hug

Re: [Python-Dev] Change PEP 399 import recommendation

Stefan Krah, 12.10.2013 15:41: > Nick Coghlan wrote: >> On 12 Oct 2013 05:49, "Eric Snow" wrote: >>> On Fri, Oct 11, 2013 at 1:41 PM, Stefan Krah wrote: Antoine Pitrou wrote: > Just create a _pydecimal module (like _pyio). That's very fast indeed. There's one minor problem: For b

Re: [Python-Dev] Change PEP 399 import recommendation

Antoine Pitrou, 12.10.2013 23:40: > On Sat, 12 Oct 2013 23:35:23 +0200 > Christian Heimes wrote: >> A directory with pure Python modules is less cumbersome than a couple >> of facade modules or intended code in try/except ImportError blocks. > > I don't find it cumbersome to be explicit here. It m

Re: [Python-Dev] Change PEP 399 import recommendation

Oscar Benjamin, 13.10.2013 18:35: > CPython preferentially imports extension modules over .py modules with > the same name. This is what happens when you use Cython in "pure" > mode: You have a pure mod.py file and an "augmenting" mod.pxd that > contains the annotations relevant to Cython. The resu

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

Nick Coghlan schrieb am 31.08.2016 um 06:30: > On 31 August 2016 at 04:55, Serhiy Storchaka wrote: >> On 30.08.16 21:20, Antoine Pitrou wrote: >>> But the performance overhead of iterating over a 1-element list >>> is small enough (it's just an array access after a pointer dereference) >>> that it

Re: [Python-Dev] PEP 7 and braces { .... } on if

Serhiy Storchaka schrieb am 03.06.2017 um 18:25: > Yet about braces. PEP 7 implicitly forbids breaking the line before an > opening brace. An opening brace should stay at the end the line of the > outer compound statement. > > if (mro != NULL) { > ... > } > else { > ...

Re: [Python-Dev] Python startup time

Ivan Levkivskyi schrieb am 20.07.2017 um 13:24: > I agree the start-up time is important. There is something that is related. > ABCMeta is currently implemented in Python. > This makes it slow, creation of an ABC is 2x slower than creation of a > normal class. > However, ABCs are used by many mediu

[Python-Dev] Cython compiled stdlib modules - Re: Python startup time

Nick Coghlan schrieb am 21.07.2017 um 08:23: > I'll also note that in these cases where the import overhead is > proportionally significant for always-imported modules, we may want to look > at the benefits of freezing them (if they otherwise remain as pure Python > modules), or compiling them as b

Re: [Python-Dev] PEP 550 v4

Hi, I'm aware that the current implementation is not final, but I already adapted the coroutine changes for Cython to allow for some initial integration testing with real external (i.e. non-Python coroutine) targets. I haven't adapted the tests yet, so the changes are currently unused and mostly u

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

Christian Heimes schrieb am 01.02.22 um 16:42: On 01/02/2022 16.08, Victor Stinner wrote: I would prefer to introduce C API incompatible changes differently: first fix Cython, and *then* introduce the change. - (1) Propose a Cython PR and get it merged - (2) Wait until a new Cython version is r

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

Greg Ewing schrieb am 01.02.22 um 23:33: On 2/02/22 8:48 am, Guido van Rossum wrote: It seems to me that a big part of the problem is that Cython feels entitled to use arbitrary CPython internals. I think the reason for this is that Cython is trying to be two things at once: (1) an interface b

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

Hi Irit, Irit Katriel via Python-Dev schrieb am 01.02.22 um 23:04: There two separate issues here. One is the timing of committing changes into cython, and the other is the process by which the cython devs learn about cpython development. On the first issue, you wrote: I'm reluctant to working

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

Guido van Rossum schrieb am 02.02.22 um 00:21: On Tue, Feb 1, 2022 at 3:07 David wrote: Greg Ewing wrote: To address this there could be an option to choose between "compatible code" and "fast code", with the former restricting itself to the stable API. To some extent, that exists at the mome

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

Thomas Caswell schrieb am 01.02.22 um 23:15: I think it would be better to discourage projects from including the output of cython in their sdists. They should either have cython as a build-time requirement or provide built wheels (which are specific a platform and CPython version). The middle

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

be broken. On Tue, Feb 1, 2022 at 4:14 PM Stefan Behnel wrote: I'd rather make it more obvious to users what their intentions are. And there is already a way to do that – the Limited API. (and similarly, HPy) Your grammar confuses me. Do you want users to be clearer in expressing t

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

Victor Stinner schrieb am 02.02.22 um 11:35: I wish that there would be a 3rd option: ship C code generated by Cython *but* run Cython if this C code "looks" outdated, for example if building the C code fails with a compiler error. So, one thing I did yesterday was to make sure that .c files ge

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

Petr Viktorin schrieb am 02.02.22 um 10:22: Moving off the internal (unstable) API would be great, but I don't think Cython needs to move all the way to the limited API. There are three "levels" in the C API: - limited API, with long-term ABI compatibility guarantees That's what "-DCYTHON_LIM

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

Ronald Oussoren via Python-Dev schrieb am 02.02.22 um 16:44: On 2 Feb 2022, at 11:50, Stefan Behnel wrote: Petr Viktorin schrieb am 02.02.22 um 10:22: - "normal" public API, covered by the backwards compatibility policy (users need to recompile for every minor release, and

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

Victor Stinner schrieb am 02.02.22 um 23:23: On Wed, Feb 2, 2022 at 3:54 PM Stefan Behnel wrote: So people using stable Python versions like Python 3.10 would not need Cython, but people testing the "next Python" (Python 3.11) would not have to manually removed generated C code. T

[Python-Dev] Re: Moving away from _Py_IDENTIFIER().

Victor Stinner schrieb am 03.02.22 um 22:46: Oh right, Cython seems to be a false positive. A code search found 3 references to __Pyx_PyObject_LookupSpecial(): PYPI-2022-01-26-TOP-5000/Cython-0.29.26.tar.gz: Cython-0.29.26/Cython/Compiler/ExprNodes.py: lookup_func_name = '__Pyx_PyObject_LookupS

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

Petr Viktorin schrieb am 03.02.22 um 13:47: On 02. 02. 22 11:50, Stefan Behnel wrote: Maybe we should advertise the two modes more. And make sure that both work. There are certainly issues with the current state of the "limited API" implementation, but that just needs work and te

[Python-Dev] Re: Moving away from _Py_IDENTIFIER().

Ronald Oussoren via Python-Dev schrieb am 03.02.22 um 14:46: On 2 Feb 2022, at 23:41, Eric Snow wrote: * a little less convenient: adding a global string requires modifying a separate file from the one where you actually want to use the string * strings can get "orphaned" (I'm planning on checkin

[Python-Dev] Re: Moving away from _Py_IDENTIFIER().

Eric Snow schrieb am 04.02.22 um 17:35: On Fri, Feb 4, 2022 at 8:21 AM Stefan Behnel wrote: Correct. We (intentionally) have our own way to intern strings and do not depend on CPython's identifier framework. You're talking about __Pyx_StringTabEntry (and __Pyx_InitString())? Y

[Python-Dev] Re: Moving away from _Py_IDENTIFIER().

Inada Naoki schrieb am 08.02.22 um 06:15: On Tue, Feb 8, 2022 at 1:47 PM Guido van Rossum wrote: Thanks for trying it! I'm curious why it would be slower (perhaps less locality? perhaps the ...Id... APIs have some other trick up their sleeve?) but since it's also messier and less backwards co

[Python-Dev] PEP-657 and co_positions (was: Please update Cython *before* introcuding C API incompatible changes in Python)

Pablo Galindo Salgado schrieb am 09.02.22 um 17:40: Should there be a getter/setter for co_positions? We consider the representation of co_postions private Yes, and that's the issue. so we don't want (for now) to ad getters/setters. If you want to get the position of a instruction, you can

[Python-Dev] Re: PEP-657 and co_positions (was: Please update Cython *before* introcuding C API incompatible changes in Python)

Guido van Rossum schrieb am 09.02.22 um 19:36: On Wed, Feb 9, 2022 at 9:41 AM Pablo Galindo Salgado wrote: On Wed, 9 Feb 2022 at 17:38, Stefan Behnel wrote: Pablo Galindo Salgado schrieb am 09.02.22 um 17:40: Should there be a getter/setter for co_positions? We consider the representation

[Python-Dev] Re: PEP-657 and co_positions (was: Please update Cython *before* introcuding C API incompatible changes in Python)

Andrew Svetlov schrieb am 09.02.22 um 19:40: Stefan, do you really need to emulate call stack with positions? Could the __note__ string with generated Cython part of exception traceback solve your needs (https://www.python.org/dev/peps/pep-0678/) ? Thanks for the link, but I think it would be s

[Python-Dev] Re: PEP-657 and co_positions (was: Please update Cython *before* introcuding C API incompatible changes in Python)

Petr Viktorin schrieb am 10.02.22 um 11:22: So, should there be a mechanism to set source/lineno/position on tracebacks/exceptions, rather than always requiring a frame for it? There's "_PyTraceback_Add()" currently, but it's incomplete in terms of what Cython would need. As it stands, Cytho

[Python-Dev] Re: Switching to Discourse

Petr Viktorin schrieb am 15.07.22 um 13:18: The discuss.python.org experiment has been going on for quite a while, and while the platform is not without its issues, we consider it a success. The Core Development category is busier than python-dev. According to staff, discuss.python.org is much

[Python-Dev] Re: Switching to Discourse

h.vetin...@gmx.com schrieb am 18.07.22 um 18:04: One of the comments in the retro was: Searching the archives is much easier and have found me many old threads that I probably would have problem finding before since I haven’t been subscribed for that long. I'm actually reading python-dev, c.

[Python-Dev] Re: The Python 2 death march

Ned Batchelder schrieb am 10.09.19 um 16:54: > this seems confusing to me > What does the "official EOL date" mean if there's a release in April? Also, what day in April? For example, planning the release for the 1st could possibly add further to the confusion. Stefan

[Python-Dev] Re: Pass the Python thread state to internal C functions

Victor Stinner schrieb am 12.11.19 um 23:03: > Are you ok to modify internal C functions to pass explicitly tstate? FWIW, I started doing the same internally in Cython a while back, because like others, I also considered it wasteful to look it up all over the place, often multiple times inside of

[Python-Dev] Last call for comments on PEP 573 (Module State Access from C Extension Methods)

Hi all, I think that PEP 573 is ready to be accepted, to greatly improve the state of extension modules in CPython 3.9. https://www.python.org/dev/peps/pep-0573/ It has come a long way since the original proposal and went through several iterations and discussions by various interested people, e

[Python-Dev] Re: Last call for comments on PEP 573 (Module State Access from C Extension Methods)

Hi Petr! Petr Viktorin schrieb am 14.01.20 um 14:37: > It also includes a more drastic change: it removes the MRO walker from the > proposal. > Reflecting on the feedback, it became clear to me that a MRO walker, as it > was described, won't give correct results in all cases: specifically, is a >

[Python-Dev] Accepting PEP 573 (Module State Access from C Extension Methods)

As (first-time) BDFL delegate, I accept PEP 573 for Python 3.9, "Module State Access from C Extension Methods" https://www.python.org/dev/peps/pep-0573/ Petr, Nick, Eric and Marcel, thank you for your work and intensive discussions on this PEP, and also to everyone else who got involved on mailin

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

Steve Dower schrieb am 14.04.20 um 00:27: > On 13Apr2020 2308, André Malo wrote: >> For one thing, if you open up APIs for Cython, they're open for everybody >> (Cython being "just" another C extension). >> More to the point: The ABIs have the same problem as they have now, >> regardless >> how res

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

André Malo schrieb am 14.04.20 um 13:39: > I think, it does not serve well as a policy for CPython. Since we're talking > hypotheticals right now, if Cython vanishes tomorrow, we're kind of left > empty > handed. Such kind of a runtime, if considered part of the compatibility > "promise", shoul

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

Paul Moore schrieb am 13.04.20 um 14:25: > On a related but different note, what is the recommended policy > (assuming it's not to use the C API) for embedding Python, and for > exposing the embedding app to Python as a C extension? My standard > example of this is the Vim interface to Python - see

[Python-Dev] Re: Cython and incompatible C API changes

Victor Stinner schrieb am 17.06.20 um 13:25: > Le mer. 17 juin 2020 à 12:38, Petr Viktorin a écrit : >>> There is an ongoing discussion about always requiring to run Cython >>> when installing a C extension which uses Cython. >> >> Do you have a link to that discussion? Yeah, I was wondering, too.

[Python-Dev] Re: (PEP 620) C API for efficient loop iterating on a sequence of PyObject** or other C types

Victor Stinner schrieb am 23.06.20 um 11:18: > Maybe an object can > generate a temporary PyObject** view which requires to allocate > resources (like memory) and the release function would release these > resources. I agree that this is more explicit when it comes to resource management, but ther

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

Hi Victor, thanks for your continued work on improving the C-API. I'll comment on the PEP inline. Victor Stinner schrieb am 22.06.20 um 14:10: > PEP available at: https://www.python.org/dev/peps/pep-0620/ > [...] > Motivation > == > > The C API blocks CPython evolutions > --

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

Victor Stinner schrieb am 24.06.20 um 02:14: > Le mar. 23 juin 2020 à 16:56, Stefan Behnel a écrit : >>> Members of ``PyObject`` and ``PyTupleObject`` structures have not >>> changed since the "Initial revision" commit (1990) >> >> While I see an

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

Victor Stinner schrieb am 24.06.20 um 17:40: > My practical problem is how to prevent C extensions accessing the > PyFloatObject.ob_fval member directly. Do extensions really do that in their code? I mean, there *is* a macro for doing exactly this thing, which suggests that users should exactly *n

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

Gustavo Carneiro schrieb am 24.06.20 um 19:19: > On Wed, 24 Jun 2020 at 17:22, Victor Stinner wrote: >> The question becomes: how to promote the limited C API? Should it >> become the default, rather than an opt-in option? > > It would be interesting to find out what is the performance impact of u

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

Victor Stinner schrieb am 26.06.20 um 14:39: > Well, the general problem is to track when the caller ends using a resource. Although that is less of a problem if you only allow exposing the internal data representation and nothing else. In that case, you can tie the lifetime of the data access to

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

Petr Viktorin schrieb am 30.06.20 um 14:51: > For example, could we only deprecate the bad parts, but not remove them > until the experiments actually show that they are preventing a beneficial > change? Big nod on this one. Stefan ___ Python-Dev mailin

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

Victor Stinner schrieb am 02.07.20 um 00:07: > Le mer. 1 juil. 2020 à 23:43, Eric V. Smith a écrit : >> >> On 7/1/2020 3:43 PM, Stefan Behnel wrote: >>> Petr Viktorin schrieb am 30.06.20 um 14:51: >>>> For example, could we only deprecate the bad parts

[Python-Dev] PR checks hang because travis does not report back to github

Hi devs, I have a trivial documentation PR https://github.com/python/cpython/pull/22464 for which travis (unsurprisingly) had a successful run, https://travis-ci.com/github/python/cpython/builds/187435578 but github lists the travis build as "created" instead of "passed". https://github.com/p

[Python-Dev] Re: PR checks hang because travis does not report back to github

Ned Deily schrieb am 05.10.20 um 01:19: > On Oct 4, 2020, at 15:55, Terry Reedy wrote: >> >> On 10/4/2020 2:32 PM, Mariatta wrote: >>> This is a known issue and I have brought it up in GitHub OS Maintainers >>> Feedback Group. It happens to other projects as well. >>> Currently we have branch prot

[Python-Dev] Re: PR checks hang because travis does not report back to github

Victor Stinner schrieb am 05.10.20 um 12:25: > Would you mind reporting the issue to > https://github.com/python/core-workflow/issues so we can aggregate > information about this issue? Done. Stefan ___ Python-Dev mailing list -- python-dev@python.org T

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

Ivan Krstić wrote: > On Mar 4, 2009, at 12:32 PM, James Y Knight wrote: >> I think html5lib would be a better candidate for an imrpoved HTML >> parser in the stdlib than BeautifulSoup. > > While we're talking about alternatives, Ian Bicking appears to swear by > lxml: > >

Re: [Python-Dev] Integrate lxml into the stdlib? (was: Integrate BeautifulSoup into stdlib?)

Hi Guido, I'm happy to see you jump onto this. Guido van Rossum wrote: > No matter how beautiful and fast lxml is, it has one downside where it > comes to installing it into the stdlib: it is based on large, complex > 3rd party libraries, libxml2 and libxslt. I actually had a recent discussion w

Re: [Python-Dev] Integrate lxml into the stdlib?

Guido van Rossum wrote: > On Thu, Mar 5, 2009 at 11:22 AM, Stefan Behnel wrote: >> I'm happy to see you jump onto this. > > I'm not sure why you say that -- all I am doing is advising *against* > inclusion. I understand that. What worth is a discussion where

Re: [Python-Dev] Integrate lxml into the stdlib?

Benjamin Peterson wrote: > 2009/3/5 Guido van Rossum : >> On Thu, Mar 5, 2009 at 2:39 AM, Stefan Behnel wrote: >>> And, BTW, I wouldn't mind getting lxml into the stdlib either. >> No matter how beautiful and fast lxml is, it has one downside where it >> comes t

Re: [Python-Dev] Integrate lxml into the stdlib?

Hi, Brett Cannon wrote: > On Thu, Mar 5, 2009 at 12:52, Stefan Behnel wrote: >> Benjamin Peterson wrote: >>> it depends on Cython, which is wonderful normally, but maybe >>> difficult to deal with in language evolution since we wouldn't have >>> direct

Re: [Python-Dev] Integrate lxml into the stdlib?

Martin v. Löwis wrote: >> I do see the point you are making here. Even if lxml gets mature and >> static, that doesn't necessarily apply to the external libraries it uses. >> However, I should note that exactly the same argument also applies to >> sqlite3 and gdbm, which, again, are in the stdlib t

Re: [Python-Dev] RELEASED Python 3.1 alpha 1

Martin v. Löwis wrote: >>> On behalf of the Python development team and the Python community, I'm >>> happy to announce the first alpha release of Python 3.1. >> Are there any plans for a Windows installer? > > Yes. However, I cannot produce them on weekends. Sounds like a bug in the MS installer

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

Tres Seaver wrote: > Steven D'Aprano wrote: >> Tres, for some reason every time you reply to the list, you send TWO >> copies instead of one: > >> To: python-dev@python.org >> CC: Python Dev > >> Could you please fix that? > > I can try: I normally post via gmane, and leave python-dev CC'ed

Re: [Python-Dev] GPython?

Brett Cannon wrote: > On Thu, Mar 26, 2009 at 18:05, Terry Reedy wrote: >> If one adds type annotations so that values can be unboxed, would not >> Cython, etc, do even better for speedup? > > Nope as Unladen is planning to re-implement the eval loop, something Cython > doesn't optimize without th

[Python-Dev] Serious regression in doctest in Py3.1rc1

Hi, I can't currently file a bug report on this, but I was told by Lisandro Dalcín that there is a serious problem with the doctest module in Py3.1rc1. In Cython, we use doctests to test the compiler in that we compile a Python/Cython module with doctests into a C module and then run doctest on th

Re: [Python-Dev] I am back

s...@pobox.com wrote: > Aahz> On Wed, Jul 01, 2009, Brett Cannon wrote: > > >> Anything happen while I was gone that I should be aware of that is > >> not covered in a PEP? > > Aahz> Yes. > > In particular, Brett, you probably didn't hear that the King of Pop died > last week. I

Re: [Python-Dev] expy: an expressway to extend Python

Yingjie Lan wrote: > This is to announce the initial release of expy 0.1.0. > > More details at http://expy.sourceforge.net/ I'm clearly biased, but my main concern here is that expy requires C code to be written inside of strings. There isn't any good editor support for that, so I doubt that exp

Re: [Python-Dev] [issue6673] Py3.1 hangs in coroutine and eats up all memory

[moving this from the bug tracker] Alexandre Vassalotti wrote: > Alexandre Vassalotti added the comment: > > Not a bug. > > The list comprehension in your chunker: > > while True: > target.send([ (yield) for i in range(chunk_size) ]) > > is equivalent to the following generator in

Re: [Python-Dev] [issue6673] Py3.1 hangs in coroutine and eats up all memory

Nick Coghlan wrote: > Stefan Behnel wrote: >> This is also an important issue for other Python implementations. Cython >> simply transforms comprehensions into the equivalent for-loop, so when we >> implement PEP 342 in Cython, we will have to find a way to emulate >&g

Re: [Python-Dev] [issue6673] Py3.1 hangs in coroutine and eats up all memory

Antoine Pitrou wrote: > Stefan Behnel behnel.de> writes: >> IMHO, that's pretty far from obvious when you look at the code. > > A "yield" wrapped in a list comprehension looks far from obvious IMO anyway, > whether in 2.x or 3.x. It's this kind of &

Re: [Python-Dev] functools.compose to chain functions together

Antoine Pitrou wrote: > Raymond Hettinger rcn.com> writes: >> IMO, its only virtue is that people coming from functional languages >> are used to having compose. Otherwise, it's a YAGNI. > > Then I wonder how partial() ended up in the stdlib. It seems hardly more > useful than compose(). I woul

Re: [Python-Dev] Help needed for tar archive creation with changed UID/GID

bheemesh v wrote: > I am a newbie to this mailing list, i have seen in some mail discussions > about a tar archive creation by forcibly setting the UID/GID to a specific > user (say root). Note that this is the mailing list about core development of the CPython interpreter, not about general Pytho

Re: [Python-Dev] Interest in integrating C decimal module into Python?

Stefan Krah wrote: > Mark Dickinson wrote: >> I think my biggest concern is maintenance: we'd be replacing >> 8500 lines of Python code in a single file, that several of the >> current core developers understand well, with 3 (Stefan, is >> that about accurate?) lines of C in several files, tha

Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it

Willi Richert wrote: > recently I wrote an algorithm, in which very often I had to get an arbitrary > element from a set without removing it. See this discussion: http://comments.gmane.org/gmane.comp.python.ideas/5606 Stefan ___ Python-Dev mailing li

Re: [Python-Dev] Cython as a Python implementation

Maciej Fijalkowski, 05.11.2009 19:01: >> Most Python implementations do not reimplement the stdlib, or at most a >> minor part of it, so that's right out of the discussion. > > Did you actually check? Well, I know that Jython uses the original stdlib modules through svn:externals in the build, la

Re: [Python-Dev] PEP 3003 - Python Language Moratorium

Dino Viehland, 05.11.2009 19:35: > Stefan wrote: >> It /does/ make some static assumptions in that it considers builtins >> true >> builtins. However, it does not prevent you from replacing them in your >> code, as long as you do it inside the module. Certainly a restriction >> compared to Python,

Re: [Python-Dev] Providing support files to assist 3.x extension authors

Case Vanhorsen, 20.12.2009 01:38: When I ported gmpy (Python to GMP multiple precision library) to Python 3.x, I began to use PyLong_AsLongAndOverflow frequently. I found the code to slightly faster and cleaner than using PyLong_AsLong and checking for overflow. You might want to look at the co

Re: [Python-Dev] GIL required for _all_ Python calls?

Guido van Rossum, 07.01.2010 05:29: A better rule would be "you may access the memory buffer in a PyString or PyUnicode object with the GIL released as long as you own a reference to the string object." Everything else is out of bounds (or not worth the bother). Is that a "yes" regarding the OP

Re: [Python-Dev] GIL required for _all_ Python calls?

MRAB, 07.01.2010 04:07: I've been wondering whether it's possible to release the GIL in the regex engine during matching. I know that it needs to have the GIL during memory-management calls, but does it for calls like Py_UNICODE_TOLOWER Py_UNICODE_TOLOWER looks safe to me at first glance. o

Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2

Neil Schemenauer, 11.01.2010 05:17: On Mon, Jan 11, 2010 at 12:02:01AM +0100, "Martin v. Löwis" wrote: [...] would it still be ok if I closed a 2.x feature request as "won't fix", or only committed the new feature to the 3.x branch? Yes. Non-bugfix development on 2.x would optional (i.e. done

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

John Arbash Meinel, 22.01.2010 15:56: > For example, I've never seen a Pyrex "__init__" function show up in > timing, the time spent always gets assigned to the calling function. So > if I want to see it, I set up a 'create_foo(*args, **kwargs)' function > that just does return Foo(*args, **kwargs)

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Collin Winter, 21.01.2010 21:14: > Cython is a super-set of Python, and files annotated for maximum > Cython performance are no longer valid Python code, and will not run > on any other Python implementation. Except when you use plain Python annotations, in which case you get the speed of Cython f

Re: [Python-Dev] patch to make list.pop(0) work in O(1) time

Michael Foord, 26.01.2010 01:14: > How great is the complication? Making list.pop(0) efficient sounds like > a worthy goal, particularly given that the reason you don't use it is > because you *know* it is inefficient I agree. Given a programmer the insight that lists are implemented as arrays in

Re: [Python-Dev] Help wanted on a code generator project

Yingjie Lan, 26.01.2010 12:41: > I am working on a project named expy, which intends to be an express way > to extend Python (currently only supports extension in C, but could be > easily expaned to support more languages). With expy you can write your > code as a real python module, then expy woul

Re: [Python-Dev] Help wanted on a code generator project

Yingjie Lan, 26.01.2010 13:04: >> note that this is quite off-topic for this list, which is about the >> development of the CPython interpreter and runtime environment. > > Sorry if this is bothering you. No problem. > I thought here are a lot of people who > knows how to write extensions, and

Re: [Python-Dev] patch to make list.pop(0) work in O(1) time

Glenn Linderman, 27.01.2010 10:13: > As a newcomer to python, I must say that I wouldn't expect a list to be > like an array. I'd expect it more to be like a list... many > implementations of lists (linked lists, in particular) make it O(1) to > add to the front or back. An array can be used to r

Re: [Python-Dev] Summary of 2 years of Python fuzzing

Neal Norwitz, 28.01.2010 08:31: > One of my points to Victor and everyone else like him is that even > though it may seem no one is listening to you or cares, you might be > surprised to find out how many people really are paying attention and > do care. If you have something you want to do, make

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Daniel Fetchinson, 28.01.2010 13:19: > A question from someone writing C extension modules for python I doubt that this will have any impact on C extension developers. > If this is correct, I still have one worry: since I wouldn't want to > touch the python install most linux distributions ship

Re: [Python-Dev] Forking and Multithreading - enemy brothers

Pascal Chambon, 29.01.2010 22:58: > I've just recently realized the huge problems surrounding the mix of > multithreading and fork() - i.e that only the main thread actually > survived the fork(), and that process data (in particular, > synchronization primitives) could be left in a dangerously bro

Re: [Python-Dev] Forking and Multithreading - enemy brothers

Stefan Behnel, 30.01.2010 07:36: > Pascal Chambon, 29.01.2010 22:58: >> I've just recently realized the huge problems surrounding the mix of >> multithreading and fork() - i.e that only the main thread actually >> survived the fork(), and that process data (in part

Re: [Python-Dev] 3.1.2

Benjamin Peterson, 13.02.2010 03:52: > It's about time for another 3.1 bug fix release. I propose this schedule: > > March 6: Release Candidate (same day as 2.7a4) > March 20: 3.1.2 Final release Does a crash like #7173 qualify as a blocker for 3.1.2? Stefan ___

Re: [Python-Dev] embedding Python interpreter in non-console windows application

stephen, 17.02.2010 06:49: > THE PROBLEM: > I am having a problem that I have seen asked quite a bit on the web, with > little to no follow up. Note that this list is about developing the CPython core runtime, not about solving problems with Python code or Python usage. See the comp.lang.python

Re: [Python-Dev] Update xml.etree.ElementTree for Python 2.7 and 3.2

Florent Xicluna, 18.02.2010 10:21: > For this purpose, I grew the test suite from 300 lines to 1800 lines, using > both > the tests from upstream and the tests proposed by Neil Muller on issue #6232. Just a comment on this. While the new tests may work with ElementTree as is, there are a couple o

Re: [Python-Dev] Update xml.etree.ElementTree for Python 2.7 and 3.2

Florent Xicluna, 20.02.2010 11:53: > Stefan Behnel writes: >> None of theses features is really required to hold for anything but the >> current as-is implementation. > > I agree. > >> So my impression is that many of the tests try to provide guarantees where >

Re: [Python-Dev] Update xml.etree.ElementTree for Python 2.7 and 3.2

Martin v. Löwis, 20.02.2010 13:08: >> Actually this should not be a fork of the upstream library. >> The goal is to improve stability and predictability of the ElementTree >> implementations in the stdlib, and to fix some bugs. >> I thought that it is better to backport the fixes from upstream than

Re: [Python-Dev] Update xml.etree.ElementTree for Python 2.7 and 3.2

Florent XICLUNA, 01.03.2010 00:36: > I exchanged some e-mails with Fredrik last week. Not sure if it will be > 1.2.8 or 1.3, but now he is positive on the goals of the patch. I've > commited all the changes and external fixes to a branch of the Mercurial > repo owned by Fredrik. I'm expecting an an

[Python-Dev] ElementTree.tostring() returning str by default in Py3.2

Hi, I just noticed that the xml.etree.ElementTree.tostring() function in Py3.2 returns a str object by default, unless an encoding is specified. This is a backwards incompatible change compared to ET 1.2. For one, it breaks tons of tests in lxml's compatibility test suite. Previously, the default

Re: [Python-Dev] ElementTree.tostring() returning str by default in Py3.2

Stefan Behnel, 02.03.2010 10:06: > I just noticed that the xml.etree.ElementTree.tostring() function in Py3.2 > returns a str object by default, unless an encoding is specified. This is a > backwards incompatible change compared to ET 1.2. For one, it breaks tons > of tests in lxml

<    1   2   3   4   5   6   7   >