Re: [Python-Dev] results of id() and weakref.getweakrefs() sometimes break on object resurrection

Hello Stefan, On Sun, 26 Oct 2014 00:20:47 +0200 "Stefan Richthofer" wrote: > Hello developers, > > I observed strange behaviour in CPython (tested in 2.7.5 and 3.3.3) > regarding object resurrection. Your runGC() function is buggy, it does not run the GC under CPython. Fix it and the first pr

Re: [Python-Dev] Status of C compilers for Python on Windows

On Sat, 25 Oct 2014 19:24:38 -0400 "R. David Murray" wrote: > > I know I for one do not generally test patches on Windows because I > haven't taken the time to learn how to build CPython on it. Sure, I > could test pure python changes by applying patches to an installed > Python, but that's an o

Re: [Python-Dev] results of id() and weakref.getweakrefs() sometimes break on object resurrection

On Sun, 26 Oct 2014 02:50:39 +0200 "Stefan Richthofer" wrote: > Okay, sorry, I was thinking too Jython-like. I fixed runGC() just to > see now that it does not even trigger resurrection, since under > CPython there are no finalizers executed in ref cycles (i.e. I find my > objects in gc.garbage).

Re: [Python-Dev] results of id() and weakref.getweakrefs() sometimes break on object resurrection

On Mon, 27 Oct 2014 14:36:31 +0100 Stefan Richthofer wrote: > Your test program performs no resurrection of x. > > Interestingly, it does not change behavior if you write > > class X(object): > def __del__(self): > X.x = self > print ref() > > (Thanks for making me aware

Re: [Python-Dev] results of id() and weakref.getweakrefs() sometimes break on object resurrection

On Mon, 27 Oct 2014 16:20:06 +0100 Stefan Richthofer wrote: > > I already pointed out > "One can surely argue x2 has never been dead, or see it as > "it was killed along with x and then resurrected by x"." > > In Java and thus in Jython, it is treated as the second one. You mean Jython deletes

Re: [Python-Dev] results of id() and weakref.getweakrefs() sometimes break on object resurrection

On Mon, 27 Oct 2014 17:23:23 +0100 Stefan Richthofer wrote: > > >You mean Jython deletes instance attributes before calling __del__ ? > > No. I think the term of "object resurrection" usually does not mean bringing > back a deleted object in the sense that memory was already freed. > I think it

Re: [Python-Dev] results of id() and weakref.getweakrefs() sometimes break on object resurrection

On Mon, 27 Oct 2014 18:40:24 +0100 Stefan Richthofer wrote: > >If Jython does things differently, then certainly its behaviour is > >incompatible with the common expectations of Python developers. > > Guido recently pointed out that it is allowed for different Python > implementations to alter de

Re: [Python-Dev] PEP 475

on-dev/2014-September/136101.html > > Antoine Pitrou wrote " I'm +1 on the whole PEP" and R. David Murray > wrote "Personally, I really want Python to handle EINTR for me". > > What's the next step? Who wants to handle this PEP? Guido? Antoine? Is

Re: [Python-Dev] PEP 475

On Wed, 29 Oct 2014 00:05:57 +0100 Victor Stinner wrote: > 2014-10-28 22:36 GMT+01:00 Antoine Pitrou : > > Is there an implementation somewhere? > > There is no implementation yet. This time, I chose to focus on the PEP > before working on an implementation :-) >

Re: [Python-Dev] Status of C compilers for Python on Windows

On Wed, 29 Oct 2014 10:31:50 -0400 "R. David Murray" wrote: > On Wed, 29 Oct 2014 10:22:14 -0400, Tres Seaver wrote: > > On 10/28/2014 11:59 PM, Stephen J. Turnbull wrote: > > > > > most developers on Windows do have access to Microsoft tool > > > > I assume you mean python-dev folks who work

Re: [Python-Dev] Status of C compilers for Python on Windows

On Wed, 29 Oct 2014 11:07:53 -0400 Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 10/29/2014 10:31 AM, R. David Murray wrote: > > > If you are writing code targeted for Windows, I think you are very > > likely to have an MSDN subscription of some sort if your packag

Re: [Python-Dev] Status of C compilers for Python on Windows

On Thu, 30 Oct 2014 01:09:45 +1000 Nick Coghlan wrote: > > Lots of folks are happy with POSIX emulation layers on Windows, as > they're OK with "basically works" rather than "works like any other > native application". "Basically works" isn't sufficient for many > Python-on-Windows use cases thou

Re: [Python-Dev] The role of NotImplemented: What is it for and when should it be used?

On Mon, 3 Nov 2014 08:48:07 -0800 Guido van Rossum wrote: > Gotta be brief, but NotImplemented is for all binary ops. Even in-place ops? Regards Antoine. > Power may be an > exception because it's ternary? > On Nov 3, 2014 8:08 AM, "Brett Cannon" wrote: > > > > > > > On Mon Nov 03 2014 at

Re: [Python-Dev] The role of NotImplemented: What is it for and when should it be used?

On Mon, 3 Nov 2014 09:05:43 -0800 Guido van Rossum wrote: > Sorry, was too quick. For immutable types __iop__ may not exist and then > the fallback machinery should work normally using NotImplemented. But if > __iop__ exists it can choose not to allow __rop__, because the type would > presumably

Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #22773: fix failing test with old readline versions due to issue #19884.

On Tue, 04 Nov 2014 09:58:29 -0400 Benjamin Peterson wrote: > > On Tue, Nov 4, 2014, at 09:55, antoine.pitrou wrote: > > https://hg.python.org/cpython/rev/eba6e68e818c > > changeset: 93382:eba6e68e818c > > branch: 2.7 > > parent: 93379:e54d0b197c82 &

Re: [Python-Dev] pathlib difference to the backport

On Mon, 10 Nov 2014 13:45:57 +0200 Ionel Cristian Mărieș wrote: > Hey, > > It appears there's a peculiar difference between the pathlib in the 3.4 > branch and the one on bitbucket: cpython's pathlib.Path implements a no-op > context manager interface. What's the purpose of that? Hum... That's a

Re: [Python-Dev] Windows Dedicated Mailing List

On Fri, 14 Nov 2014 16:35:12 + Steve Dower wrote: > I'd like to keep development *of* Python here, regardless of platform. > Otherwise all the Linux and Mac people might forget about us :) +1 from a Linux developer. I find it useful to know what happens on other platforms (also I occasionall

Re: [Python-Dev] OneGet provider for Python

On Fri, 14 Nov 2014 18:12:59 -0600 Vincent Povirk wrote: > I have been following OneGet development very closely, and I have > volunteered to create a OneGet provider for installing Python > packages. Normally, I would keep quiet about this sort of thing until > I have actual code that works, but

Re: [Python-Dev] OneGet provider for Python

On Sat, 15 Nov 2014 22:53:09 +0100 Victor Stinner wrote: > > Also, distutils-sig does seem more appropriate, > > IMO we need a new mailing to discuss which mailing list is the most > appropriate (which includes another new mailing list). I suggest you first write a PEP, and find a BDFL-delegate.

Re: [Python-Dev] PEP 479: Change StopIteration handling inside generators

On Thu, 20 Nov 2014 11:36:54 -0800 Guido van Rossum wrote: > I've made some updates to the PEP: > > - added 19-Nov-2014 to Post-History > - removed "implicitly-raised" from the abstract > - changed the __future__ thing to generator_return To me "generator_return" sounds like the addition to gene

Re: [Python-Dev] PEP 479: Change StopIteration handling inside generators

On Thu, 20 Nov 2014 14:04:24 -0800 Guido van Rossum wrote: > On Thu, Nov 20, 2014 at 12:13 PM, Serhiy Storchaka > wrote: > > > On 20.11.14 21:58, Antoine Pitrou wrote: > > > >> To me "generator_return" sounds like the addition to generator syntax > &

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

On Fri, 21 Nov 2014 13:29:11 + Brett Cannon wrote: > > If that "must be self-hosted" constraint is removed, then the obvious > > candidate for Mercurial hosting that supports online editing + pull > > requests is the PSF's BitBucket account. > > > > There's also CodePlex and (ironically) Sour

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

On Fri, 21 Nov 2014 11:03:35 -0500 Benjamin Peterson wrote: > > I hate to say this, but if we're going to have "doc" repos hosted in a > different place than code, we might as bite the bullet and move them to > Git + GitHub. That would surely maximize the community size + ease of > use objective

Re: [Python-Dev] PEP 479: Change StopIteration handling inside generators

On Fri, 21 Nov 2014 05:47:58 -0800 Raymond Hettinger wrote: > > Another issue is that it breaks the way I and others have taught for years > that generators are a kind of iterator (an object implementing the iterator > protocol) and that a primary motivation for generators is to provide a > si

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

On Sun, 23 Nov 2014 22:58:02 +0900 "Stephen J. Turnbull" wrote: > Nick Coghlan writes: > > > By contrast, proposals to switch from Mercurial to Git impose a > > *massive* burden on contributors that don't already know git. > > Let's not get carried away here. The *massive* burden is the moani

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

On Tue, 25 Nov 2014 16:17:06 +1000 Nick Coghlan wrote: > > The subsequent discussion has made me realise that dissatisfaction > with the current state of the infrastructure amongst core developers > is higher than I previously realised, so I've re-evaluated my own > priorities, and will be spendi

Re: [Python-Dev] cpython (3.4): handle errors without a reason attribute

On Wed, 26 Nov 2014 00:06:06 + benjamin.peterson wrote: > https://hg.python.org/cpython/rev/e635c3ba75c8 > changeset: 93591:e635c3ba75c8 > branch: 3.4 > user:Benjamin Peterson > date:Tue Nov 25 15:43:58 2014 -0600 > summary: > handle errors without a reason attribute

Re: [Python-Dev] cpython (3.4): handle errors without a reason attribute

On Tue, 25 Nov 2014 19:21:08 -0500 Benjamin Peterson wrote: > > > > You should be able to keep the e.reason test if you only catch SSLError. > > Unfortunately, test_robotparser seems to manage to raise a cert > validation error without a reason. Ahh... Perhaps it's urllib catching the SSLError

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

On Sat, 29 Nov 2014 01:59:06 + Nathaniel Smith wrote: > > Option 1: Make it possible to change the type of a module object > in-place, so that we can write something like > >sys.modules[__name__].__class__ = MyModuleSubclass > > Option 1 downside: The invariants required to make __class

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

On Sat, 29 Nov 2014 20:02:50 + Nathaniel Smith wrote: > > > > Option 1b: have __class__ assignment delegate to a tp_classassign slot > > on the old class, so that typeobject.c doesn't have to be cluttered with > > many special cases. > > I'm intrigued -- how would this help? It would allow M

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On Sun, 30 Nov 2014 00:15:55 + (UTC) Alex Gaynor wrote: > > The seconds experience I have is that of Django's migration to git and github. > For a long time we were on SVN, and we were very resistant to moving to > DVCS in > general, and github in particular. Multiple times I said that I did

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On Sun, 30 Nov 2014 16:23:08 +1100 Chris Angelico wrote: > > Yes, GitHub is proprietary. But all of your actual code is stored in > git, which is free, and it's easy to push that to a new host somewhere > else, or create your own host. This proposal is for repositories that > don't need much in t

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On Sun, 30 Nov 2014 19:19:50 + Brett Cannon wrote: > > As the PEP points out, the devguide, devinabox, and the PEPs have such a > shallow development process that hosting them on Bitbucket wouldn't be a > big thing. But if we don't view this as a long-term step towards moving > cpython develo

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On Sun, 30 Nov 2014 10:05:01 -0800 Guido van Rossum wrote: > > I bring this up to emphasize that (unlike GNU software and the FSF) Python > has no additional hidden agenda of bringing freedom to all software. As far as GNU and the FSF are concerned, I don't think the agenda is "hidden" at all ;-

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

On Sun, 30 Nov 2014 11:15:50 -0800 Guido van Rossum wrote: > On Sun, Nov 30, 2014 at 6:15 AM, Brett Cannon wrote: > > > > On Sat, Nov 29, 2014, 21:55 Guido van Rossum wrote: > > > > All the use cases seem to be about adding some kind of getattr hook to > > modules. They all seem to involve modi

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On Sun, 30 Nov 2014 22:06:03 -0500 Terry Reedy wrote: > > If the mirror experiment is successful, the devguide might be the next > experiment. It does not have any one maintainer, and *is* tied to the > tracker. But herein lies the problem with the devguide. There are 22 > issues, down just

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On Mon, 1 Dec 2014 08:46:46 +0100 Matěj Cepl wrote: > On 2014-12-01, 02:12 GMT, Pierre-Yves David wrote: > > Migrating the DVCS content is usually easy. > > This is lovely mantra, but do you speak from your own > experience? I did move rope from Bitbucket to > https://github.com/python-rope an

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

On Mon, 1 Dec 2014 21:38:45 + Nathaniel Smith wrote: > > object_set_class is responsible for checking whether it's okay to take > an object of class "oldto" and convert it to an object of class > "newto". Basically it's goal is just to avoid crashing the interpreter > (as would quickly happen

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On Tue, 02 Dec 2014 18:21:39 + Brett Cannon wrote: > > So if we did have a discussion at the summit and someone decided to argue > for FLOSS vs. not as a key factor then I would politely cut them off and > say that doesn't matter to me and move on. As I said, I would moderate the > conversat

Re: [Python-Dev] WebM MIME type in mimetypes module

On Tue, 2 Dec 2014 16:07:47 -0800 Chris Rebert wrote: > Hi all, > > I'm seeking to move http://bugs.python.org/issue16329 towards conclusion. > Since the discussion on the issue itself seems to have petered out, I > thought I'd bring it up here. > > To summarize the issue, it proposes adding an

Re: [Python-Dev] datetime nanosecond support (ctd?)

I think strftime / strptime support is a low-priority concern on this topic, and can probably be discussed independently of the core nanosecond support. Regards Antoine. On Thu, 11 Dec 2014 11:14:27 -0800 Guido van Rossum wrote: > Another issue to consider here is that parsing and printing sh

Re: [Python-Dev] datetime nanosecond support (ctd?)

On Thu, 11 Dec 2014 13:43:05 -0600 Skip Montanaro wrote: > On Thu, Dec 11, 2014 at 1:23 PM, Antoine Pitrou wrote: > > I think strftime / strptime support is a low-priority concern on this > > topic, and can probably be discussed independently of the core > > nanosecond suppo

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

On Mon, 15 Dec 2014 19:08:17 -0800 Mark Roberts wrote: > > So, I'm the guy that used the "hate" word in relation to writing 2/3 > compliant code. And really, as a library maintainer/writer I do hate > writing 2/3 compatible code. Having 4 future imports in every file and > being forced to use a c

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

On Tue, 16 Dec 2014 19:25:35 + Brett Cannon wrote: > > As for the changing of the default in Python 3, that's because we decided > to make iterators the default everywhere. And that was mostly for > consistency, not performance reasons. It was also for flexibility as you > can go from an iter

Re: [Python-Dev] libffi embedded in CPython

On Fri, 19 Dec 2014 09:52:26 + Paul Moore wrote: > On 19 December 2014 at 08:26, Maciej Fijalkowski wrote: > > I would like to add that "not doing anything" is not a good strategy > > either, because you accumulate bugs that get fixed upstream (I'm > > pretty sure all the problems from cpytho

Re: [Python-Dev] New Windows installer for Python 3.5

On Sat, 3 Jan 2015 23:34:05 + Steve Dower wrote: > I've put together a short post showing where I've been taking the Windows > installer for Python 3.5, since I know there are interested people on this > list who will have valuable feedback. > > http://stevedower.id.au/blog/the-python-3-5-

Re: [Python-Dev] New Windows installer for Python 3.5

On Tue, 6 Jan 2015 23:56:30 +1000 Nick Coghlan wrote: > On 5 January 2015 at 18:17, Paul Moore wrote: > > On 5 January 2015 at 01:20, Steve Dower wrote: > >> I think this means the best way to make multiple versions work properly is > >> to rename python.exe to python3.5.exe, then install the

Re: [Python-Dev] Overriding stdlib http package

On Wed, 14 Jan 2015 08:32:23 -0800 Demian Brecht wrote: > Hi all, > > As part of the work I'm doing on httplib3 (now that I've actually gotten > a bit of time), one of the things I'm trying to get done is injection of > httplib3 over http in order to not have to modify all import paths in > modul

Re: [Python-Dev] Overriding stdlib http package

On Wed, 14 Jan 2015 12:04:22 -0500 Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 01/14/2015 11:54 AM, Antoine Pitrou wrote: > > On Wed, 14 Jan 2015 08:32:23 -0800 Demian Brecht > > wrote: > >> Hi all, > >> > >>

Re: [Python-Dev] bytes & bytearray

On Mon, 19 Jan 2015 12:01:36 -0500 "Eric V. Smith" wrote: > > I'd return a new copy (or, not implement it at all and let the default > machinery call __mod__, and do the assignment). That's the least > surprising to me, since the goal is to be compatible with 2.7's str > %-formatting. +1 for a c

Re: [Python-Dev] Can Python Be Built Without Distutils

On Sat, 24 Jan 2015 21:53:06 +0100 "M.-A. Lemburg" wrote: > > BTW: Parallel execution, cross compilation can be added > to setup.py. I don't think parallel execution is all > that important, $ ./python setup.py build_ext --help [...] --parallel (-j) number of parallel build jobs Regards

Re: [Python-Dev] Can Python Be Built Without Distutils

On Sun, 25 Jan 2015 05:22:48 + "Gregory P. Smith" wrote: > Why doesn't our Makefile supply that flag with the make parallelism level > in the sharedmods step? If I run "make -j4" here, it works (on the default branch). Regards Antoine. ___ Python-

Re: [Python-Dev] Any grammar experts?

On Sat, 24 Jan 2015 21:10:51 -0500 Neil Girdhar wrote: > To finish PEP 448, I need to update the grammar for syntax such as > > {**x for x in it} Is this seriously allowed by the PEP? What does it mean exactly? Regards Antoine. ___ Python-Dev maili

Re: [Python-Dev] Any grammar experts?

On Sun, 25 Jan 2015 14:59:42 -0800 Guido van Rossum wrote: > On Sun, Jan 25, 2015 at 7:32 AM, Georg Brandl wrote: > > > On 01/25/2015 04:08 PM, Antoine Pitrou wrote: > > > On Sat, 24 Jan 2015 21:10:51 -0500 > > > Neil Girdhar wrote: > > >> To finish

Re: [Python-Dev] Any grammar experts?

On Mon, 26 Jan 2015 10:46:02 -0500 "R. David Murray" wrote: > On Mon, 26 Jan 2015 09:43:26 -0500, Barry Warsaw wrote: > > On Jan 25, 2015, at 09:31 PM, R. David Murray wrote: > > > > >> > > {*x for x in it} > > >> > > > > >> > > which is a set comprehension, while the other is a dict > > >> >

Re: [Python-Dev] is a new buildbot gps-debian-profile-opt possible?

Of course. I hadn't had time to answer your private e-mail but will do so soon :-) Regards Antoine. On Mon, 26 Jan 2015 17:24:31 + "Gregory P. Smith" wrote: > I want this buildbot to run "make profile-opt" instead of "make all" and > it'd be best if it could _not_ have --with-pydebug on t

Re: [Python-Dev] Any grammar experts?

On Mon, 26 Jan 2015 12:06:26 -0800 Ethan Furman wrote: > It destroy's the chaining value and pretty much makes the improvement not an > improvement. If there's a possibility that > the same key could be in more than one of the dictionaries then you still > have to do the > > dict.update(anot

Re: [Python-Dev] Any grammar experts?

On Mon, 26 Jan 2015 12:22:20 -0800 Ethan Furman wrote: > On 01/26/2015 12:09 PM, Antoine Pitrou wrote: > > On Mon, 26 Jan 2015 12:06:26 -0800 > > Ethan Furman wrote: > >> It destroy's the chaining value and pretty much makes the improvement not > >> an

Re: [Python-Dev] Any grammar experts?

On Mon, 26 Jan 2015 16:28:24 -0500 "R. David Murray" wrote: > > My use case is a configuration method that takes keyword parameters. > In tests I want to specify a bunch of default values for the > configuration, but I want individual test methods to be able > to override those values. So I have

[Python-Dev] Pronouncing on PEP 475 - last call

Hello, As BDFL-delegate, I'd like to pronounce soon on PEP 475 - "Retry system calls failing with EINTR". I've just pushed some small rephrasings, which should appear soon (at https://www.python.org/dev/peps/pep-0475/). There is a working implementation by Charles-François at http://bugs.python.

Re: [Python-Dev] Workflow PEP proposals are now closed

Hi, What does "closed" mean in this context? Regards Antoine. On Mon, 02 Feb 2015 14:35:47 + Brett Cannon wrote: > The PEPs under consideration are PEPs 474 > and 462 > from Nick Coghlan to use > Kal

Re: [Python-Dev] cpython (merge 3.4 -> default): Merge 3.4 (asyncio)

On Mon, 02 Feb 2015 17:38:10 + victor.stinner wrote: > https://hg.python.org/cpython/rev/42b376c8cf60 > changeset: 94465:42b376c8cf60 > parent: 94463:0b3bc51341aa > parent: 94464:2cd6621a9fbc > user:Victor Stinner > date:Mon Feb 02 18:36:59 2015 +0100 > summary: >

[Python-Dev] PEP 475 accepted

Hello, I'm now accepting PEP 475 - "Retry system calls failing with EINTR". You can read it at https://www.python.org/dev/peps/pep-0475/ The implementation is more or less ready at http://bugs.python.org/issue23285, so you can expect it to land in the main repo relatively soon. Regards Antoine

Re: [Python-Dev] PEP 475 accepted

On Mon, 2 Feb 2015 12:49:32 -0800 Guido van Rossum wrote: > W00t! Congratulations les Français! I hoped nobody would notice :-) Regards Antoine. > > On Mon, Feb 2, 2015 at 12:45 PM, Antoine Pitrou wrote: > > > > > Hello, > > > > I'm now accepting P

Re: [Python-Dev] (no subject)

On Tue, 10 Feb 2015 08:43:53 +1000 Nick Coghlan wrote: > > For example, the potential for arcane call arguments suggests the need for > a PEP 8 addition saying "first standalone args, then iterable expansions, > then mapping expansions", even though syntactically any order would now be > permitte

Re: [Python-Dev] (no subject) PEP 448

On Mon, 9 Feb 2015 16:06:20 -0500 Neil Girdhar wrote: > Hello all, > > The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is > implemented now based on some early work by Thomas Wouters (in 2008) and > Florian Hahn (2013) and recently completed by Joshua Landau and me. To be clear,

Re: [Python-Dev] (no subject)

On Tue, 10 Feb 2015 19:04:03 +1300 Greg Ewing wrote: > Donald Stufft wrote: > > > > perhaps a better > > solution is to simply make it so that something like ``a_list + > > an_iterable`` is valid and the iterable would just be consumed and +’d > > onto the list. > > I don't think I like the a

Re: [Python-Dev] (no subject)

On Mon, 09 Feb 2015 18:06:02 -0800 Ethan Furman wrote: > On 02/09/2015 05:14 PM, Victor Stinner wrote: > > > > def partial(func, *args, **keywords): > > def newfunc(*fargs, **fkeywords): > > return func(*(args + fargs), **keywords, **fkeywords) > > ... > > return newfunc > >

Re: [Python-Dev] (no subject)

On Tue, 10 Feb 2015 23:16:38 +1000 Nick Coghlan wrote: > On 10 Feb 2015 19:24, "Terry Reedy" wrote: > > > > On 2/9/2015 7:29 PM, Neil Girdhar wrote: > >> > >> For some reason I can't seem to reply using Google groups, which is is > >> telling "this is a read-only mirror" (anyone know why?) > > >

Re: [Python-Dev] (no subject)

On Wed, 11 Feb 2015 18:45:40 +1300 Greg Ewing wrote: > Antoine Pitrou wrote: > >>>>bytearray(b"a") + b"bc" > > > > bytearray(b'abc') > > > >>>>b"a" + bytearray(b"bc") > > > > b&#x

Re: [Python-Dev] PEP 471 (scandir): Poll to choose the implementation (full C or C+Python)

On Fri, 13 Feb 2015 13:27:04 +0200 Serhiy Storchaka wrote: > On 13.02.15 12:07, Victor Stinner wrote: > > * C implementation: scandir is at least 3.5x faster than listdir, up > > to 44.6x faster on Windows > > Results on Windows was obtained in the becnhmark that doesn't drop disk > caches and

Re: [Python-Dev] PEP 471 (scandir): Poll to choose the implementation (full C or C+Python)

On Fri, 13 Feb 2015 11:07:03 +0100 Victor Stinner wrote: > > * C implementation: scandir is at least 3.5x faster than listdir, up > to 44.6x faster on Windows > * C+Python implementation: scandir is not really faster than listdir, > between 1.3x and 1.4x faster So amusingly, the bottleneck is no

Re: [Python-Dev] PEP 471 (scandir): Poll to choose the implementation (full C or C+Python)

On Fri, 13 Feb 2015 08:35:00 -0500 Ben Hoyt wrote: > > If we go ahead with the all C approach, I'd be in favour of > refactoring a little and putting the new scandir code into a separate > C file. There are two ways to do this: a) sticking with a single > Python module and just referencing the no

Re: [Python-Dev] PEP 471 (scandir): Add a new DirEntry.inode() method?

On Sat, 14 Feb 2015 15:32:07 -0500 Ben Hoyt wrote: > > +1 we need to provide the inode (we shouldn't be throwing anything from the > > underlying directory entry away when possible). But... > > > > I think the "or None" semantics are a bad idea. It'd be better for this to > > raise AttributeError

Re: [Python-Dev] cpython: Improve struct cache locality by bring commonly accessed fields close together.

On Fri, 20 Feb 2015 08:50:10 + raymond.hettinger wrote: > https://hg.python.org/cpython/rev/0ba4bcc0a7a6 > changeset: 94696:0ba4bcc0a7a6 > user:Raymond Hettinger > date:Fri Feb 20 00:50:04 2015 -0800 > summary: > Improve struct cache locality by bring commonly accessed fie

Re: [Python-Dev] TypeError messages

On Sat, 21 Feb 2015 10:57:49 -0500 "R. David Murray" wrote: > On Sun, 22 Feb 2015 00:26:23 +1000, Nick Coghlan wrote: > > On 21 February 2015 at 00:05, Brett Cannon wrote: > > > I agree that type names don't need to be quoted. > > > > As a user, I actually appreciate the quotes, because they m

Re: [Python-Dev] TypeError messages

On Fri, 20 Feb 2015 14:05:11 + Brett Cannon wrote: > On Thu Feb 19 2015 at 5:52:07 PM Serhiy Storchaka > wrote: > > > Different patterns for TypeError messages are used in the stdlib: > > > > expected X, Y found > > expected X, found Y > > expected X, but Y found > > expe

Re: [Python-Dev] Prefixes and namespaces

On Sat, 21 Feb 2015 21:28:21 +0200 Serhiy Storchaka wrote: > /* Namespaces are one honking great idea -- let's do more of those! */ > > There are two ways to avoid name conflicts: prefixes and namespaces. > Programming languages that lacks namespaces (such as C) need to use > prefixes. For exa

Re: [Python-Dev] TypeError messages

On Sat, 21 Feb 2015 21:39:32 + MRAB wrote: > On 2015-02-21 17:14, Antoine Pitrou wrote: > > On Fri, 20 Feb 2015 14:05:11 + > > Brett Cannon wrote: > >> On Thu Feb 19 2015 at 5:52:07 PM Serhiy Storchaka > >> wrote: > >> > >> > Dif

Re: [Python-Dev] Emit SyntaxWarning on unrecognized backslash escapes?

On Mon, 23 Feb 2015 16:58:29 -0300 "Joao S. O. Bueno" wrote: > On 23 February 2015 at 16:47, Antoine Pitrou wrote: > > On Mon, 23 Feb 2015 09:29:09 -0800 > > Guido van Rossum wrote: > >> On Mon, Feb 23, 2015 at 9:01 AM, Ethan Furman wrote: > >> > &

Re: [Python-Dev] PEP 488: elimination of PYO files

On Fri, 06 Mar 2015 18:11:19 + Brett Cannon wrote: > And the dropping of docstrings does have an impact on > memory usage when you use Python at scale. What kind of "scale" are you talking about? Do you have any numbers about such impact? > You're also assuming that we will never develop an

Re: [Python-Dev] PEP 488: elimination of PYO files

On Sat, 7 Mar 2015 09:34:20 +1100 Steven D'Aprano wrote: > On Fri, Mar 06, 2015 at 09:37:05PM +0100, Antoine Pitrou wrote: > > On Fri, 06 Mar 2015 18:11:19 + > > Brett Cannon wrote: > > > And the dropping of docstrings does have an impact on > > > mem

Re: [Python-Dev] boxing and unboxing data types

On Mon, 9 Mar 2015 15:12:44 +1100 Steven D'Aprano wrote: > > My summary is as follows: > > __int__ is used as the special method for int(), and it should coerce > the object to an integer. This may be lossy e.g. int(2.999) --> 2 or may > involve a conversion from a non-numeric type to integer

Re: [Python-Dev] libffi embedded in CPython

On Wed, 11 Mar 2015 17:27:58 + Brett Cannon wrote: > > Did anyone ever step forward to do this? I'm a bit worried about the > long-term viability of ctypes if we don't have a maintainer or at least > someone making sure we are staying up-to-date with upstream libffi. The > ctypes module is a

Re: [Python-Dev] libffi embedded in CPython

On Wed, 11 Mar 2015 19:54:58 +0200 Maciej Fijalkowski wrote: > > > > Depends what you call "dangerous". C code doesn't rot quicker than pure > > Python code :-) Also, libffi really offers a wrapper around platform > > ABIs, which rarely change. > > And yet, lesser known ABIs in libffi contain bug

Re: [Python-Dev] (ctypes example) libffi embedded in CPython

On Wed, 11 Mar 2015 19:05:57 +0100 Antoine Pitrou wrote: > > > > > > But they are not ctypes. For example, cffi wouldn't be obvious to use > > > for interfacing with non-C code, since it requires you to write C-like > > > declarations. > > > &g

Re: [Python-Dev] libffi embedded in CPython

On Wed, 11 Mar 2015 22:20:58 + Brett Cannon wrote: > > You're ignoring that it's not maintained, According to which metric/criterion? changeset: 94932:86c9ef950288 user:Steve Dower date:Tue Mar 10 09:56:38 2015 -0700 summary: Issue #23606: Disable ctypes.util.find_lib

Re: [Python-Dev] libffi embedded in CPython

On Wed, 11 Mar 2015 23:10:14 +0200 Maciej Fijalkowski wrote: > > > > Well, sure. The point is, such bugs are unlikely to appear at a fast > > rate... Also, I don't understand why libffi issues would affect cffi > > any less than it affects ctypes, at least in the compiler-less mode of > > operatio

Re: [Python-Dev] libffi embedded in CPython

On Wed, 11 Mar 2015 22:55:33 + Paul Moore wrote: > On 11 March 2015 at 22:33, Maciej Fijalkowski wrote: > > You're missing my point. Ripping off the libffi from CPython is a good > > idea to start with. Maybe deprecating ctypes is *also* a good idea, > > but it's a separate discussion point.

Re: [Python-Dev] Request for comments: [issue22941] IPv4Interface arithmetic changes subnet mask

On Thu, 12 Mar 2015 12:37:16 + "Loevborg, Soeren Jakob" wrote: > > >>> import ipaddress > >>> ipaddress.IPv4Interface('10.0.0.1/8') + 1 > IPv4Interface('10.0.0.2/32') > >>> ipaddress.IPv6Interface('fd00::1/64') + 1 > IPv6Interface('fd00::2/128') Given that the behaviour is unlikely to match

Re: [Python-Dev] Request for comments: [issue22941] IPv4Interface arithmetic changes subnet mask

On Thu, 12 Mar 2015 14:08:01 -0400 Scott Dial wrote: > On 2015-03-12 10:46 AM, Eric V. Smith wrote: > > On 3/12/2015 10:00 AM, Antoine Pitrou wrote: > >> Related issue: > >> > >>>>> ipaddress.IPv4Interface('10.0.0.255/8') + 1 > >

Re: [Python-Dev] backwards and forwards compatibility, the exact contents of pickle files, and IntEnum

On Sat, 14 Mar 2015 22:52:17 -0700 Ethan Furman wrote: > I'm not sure exactly how to phrase this inquiry, so please bear with me. > > What exactly does backwards compatibility mean as far as pickle goes? We > have the various protocols, we have the > contents of pickle files created at those p

Re: [Python-Dev] Use ptyhon -s as default shbang for system python executables/daemons

On Sat, 21 Mar 2015 21:52:34 +1000 Nick Coghlan wrote: > On 19 March 2015 at 07:51, Donald Stufft wrote: > > I’ve long wished that the OS had it’s own virtual environment. A lot of > > problems > > seems to come from trying to cram the things the OS wants with the things > > that > > the user w

Re: [Python-Dev] Use ptyhon -s as default shbang for system python executables/daemons

On Mon, 23 Mar 2015 07:22:56 -0700 Toshio Kuratomi wrote: > > Building off Nick's idea of a system python vs a python for users to use, I > would see a more useful modification to be able to specify SPYTHONPATH (and > other env vars) to go along with /usr/bin/spython . That way the user > mainta

Re: [Python-Dev] Use ptyhon -s as default shbang for system python executables/daemons

On Mon, 23 Mar 2015 08:06:13 -0700 Toshio Kuratomi wrote: > > > > I really think Donald has a good point when he suggests a specific > > virtualenv for system programs using Python. > > > The isolation is what we're seeking but I think the amount of work required > and the added complexity for t

Re: [Python-Dev] --with-valgrind and --enable-shared

On Mon, 23 Mar 2015 19:16:17 +0100 Andrea Griffini wrote: > On Mon, Mar 23, 2015 at 7:08 PM, Brett Cannon wrote: > > > > It's not really our place to say if it makes sense for Arch to compile > > with valgrind flags turned on. It really depends on how they use Python in > > their Linux distributi

Re: [Python-Dev] Use ptyhon -s as default shbang for system python executables/daemons

On Mon, 23 Mar 2015 21:58:06 + "Gregory P. Smith" wrote: > > virtualenv is an amazing hack that I promote to most anyone for their own > applications use with the occasional known caveats (solvable by regurly > rebuilding your virtualenvs)... But I wouldn't want to see it used for the > core

Re: [Python-Dev] libffi embedded in CPython

On Wed, 25 Mar 2015 08:15:18 + Paul Moore wrote: > On 25 March 2015 at 08:05, Maciej Fijalkowski wrote: > > Linux crashes. The mechanism for detecting the number of arguments is > > only available on windows (note that this is a band-aid anyway, since > > if your arguments are of the wrong ki

Re: [Python-Dev] libffi embedded in CPython

On Wed, 25 Mar 2015 09:22:01 + Paul Moore wrote: > On 25 March 2015 at 09:09, Antoine Pitrou wrote: > > I'm not sure we guarantee anything. In any case, it's only a small > > proportion of the kind of crashes you can get by messing the signature. > > Fair po

Re: [Python-Dev] Socket timeout: reset timeout at each successful syscall?

On Fri, 3 Apr 2015 13:56:44 +0200 Victor Stinner wrote: > > The problem is that the socket.sendall() method may require multiple > syscalls. In this case, does the timeout count for the total time or > only for a single syscall? Asked differently: should we reset the > timeout each time a syscall

<    1   2   3   4   5   6   7   8   9   10   >