Re: [Python-Dev] sum(...) limitation

On 12 Aug 2014, at 10:02, Armin Rigo wrote: > Hi all, > > The core of the matter is that if we repeatedly __add__ strings from a > long list, we get O(n**2) behavior. For one point of view, the > reason is that the additions proceed in left-to-right order. Indeed, > sum() could proceed in a m

Re: [Python-Dev] Mac popups running make test

> On 12 May 2015, at 18:14, Tal Einat wrote: > > On Tue, May 12, 2015 at 4:14 PM, Skip Montanaro > wrote: >> >>> Twice now, I've gotten this popup: ... >> >> Let me improve my request, as it seems there is some confusion about >> what I want. I'm specifically not asking that the popups not be

Re: [Python-Dev] Investigating time for `import requests`

Op 3 okt. 2017 om 04:29 heeft Barry Warsaw het volgende geschreven: > On Oct 2, 2017, at 14:56, Brett Cannon wrote: > >> So Mercurial specifically is an odd duck because they already do lazy >> importing (in fact they are using the lazy loading support from importlib). >> In terms of all of

Re: [Python-Dev] Investigating time for `import requests`

Op 10 okt. 2017 om 01:48 heeft Brett Cannon mailto:br...@python.org>> het volgende geschreven: > > > On Mon, Oct 2, 2017, 17:49 Ronald Oussoren, <mailto:ronaldousso...@mac.com>> wrote: > Op 3 okt. 2017 om 04:29 heeft Barry Warsaw <mailto:ba...@python.org>>

Re: [Python-Dev] What is the design purpose of metaclasses vs code generating decorators? (was Re: PEP 557: Data Classes)

> On 14 Oct 2017, at 16:37, Martin Teichmann wrote: > >> Things that will not work if Enum does not have a metaclass: >> >> list(EnumClass) -> list of enum members >> dir(EnumClass) -> custom list of "interesting" items >> len(EnumClass) -> number of members >> member in EnumClass -> True or

Re: [Python-Dev] Reminder: 12 weeks to 3.7 feature code cutoff

> On 1 Nov 2017, at 22:47, Ned Deily wrote: > > Happy belated Halloween to those who celebrate it; I hope it wasn't too > scary! Also possibly scary: we have just a little over 12 weeks remaining > until Python 3.7's feature code cutoff, 2018-01-29. Those 12 weeks include a > number of trad

Re: [Python-Dev] [ssl] The weird case of IDNA

> On 31 Dec 2017, at 18:07, Nathaniel Smith wrote: > > On Dec 31, 2017 7:37 AM, "Stephen J. Turnbull" > > wrote: > Nathaniel Smith writes: > > > Issue 1: Python's built-in IDNA implementation is wrong (implements > > IDNA 2003, not IDNA 2008). >

Re: [Python-Dev] OS-X builds for 3.7.0

> On 30 Jan 2018, at 18:42, Chris Barker wrote: > > Ned, > > It looks like you're still building OS-X the same way as in the past: > > Intel 32+64 bit, 10.6 compatibility > > Is that right? > > Might it be time for an update? > > Do we still need to support 32 bit? From: > > https://appl

Re: [Python-Dev] [python-committers] [RELEASE] Python 3.7.0b1 is now available for testing

> On 1 Feb 2018, at 02:34, Ned Deily wrote: > > […] > > Attention macOS users: with 3.7.0b1, we are providing a choice of > two binary installers. The new variant provides a 64-bit-only > version for macOS 10.9 and later systems; this variant also now > includes its own built-in version of Tc

Re: [Python-Dev] How can we use 48bit pointer safely?

On Mar 30, 2018, at 08:31 AM, INADA Naoki wrote: Hi, As far as I know, most amd64 and arm64 systems use only 48bit address spaces. (except [1]) [1] https://software.intel.com/sites/default/files/managed/2b/80/5-level_paging_white_paper.pdf It means there are some chance to compact some dat

Re: [Python-Dev] How can we use 48bit pointer safely?

On Mar 30, 2018, at 03:11 PM, "Joao S. O. Bueno" wrote: Not only that, but afaik Linux could simply raise that 57bit virtual to 64bit virtual without previous warning on any version change. The change from 48-bit to 57-bit virtual addresses was not done without any warning because that would

Re: [Python-Dev] How can we use 48bit pointer safely?

On Mar 30, 2018, at 01:40 PM, Antoine Pitrou wrote: A safer alternative is to use the *lower* bits of pointers. The bottom 3 bits are always available for storing ancillary information, since typically all heap-allocated data will be at least 8-bytes aligned (probably 16-bytes aligned on 64-b

Re: [Python-Dev] Drop/deprecate Tkinter?

> On 2 May 2018, at 22:51, Ivan Pozdeev via Python-Dev > wrote: > > As https://bugs.python.org/issue33257 and https://bugs.python.org/issue33316 > showed, Tkinter is broken, for both Py2 and Py3, with both threaded and > non-threaded Tcl, since 2002 at least, and no-one gives a damn. The se

Re: [Python-Dev] Stable ABI

> On 3 Jun 2018, at 12:03, Christian Tismer wrote: > > On 02.06.18 05:47, Nick Coghlan wrote: >> On 2 June 2018 at 03:45, Jeroen Demeyer > > wrote: >> >>On 2018-06-01 17:18, Nathaniel Smith wrote: >> >>Unfortunately, very few people use the stable ABI cu

Re: [Python-Dev] Stable ABI

> On 4 Jun 2018, at 08:35, Ronald Oussoren wrote: > > > >> On 3 Jun 2018, at 17:04, Eric V. Smith > <mailto:e...@trueblade.com>> wrote: >> >> On 6/3/2018 10:55 AM, Christian Tismer wrote: >>> On 03.06.18 13:18, Ronald Oussoren wrote: &

Re: [Python-Dev] Stable ABI

> On 3 Jun 2018, at 17:04, Eric V. Smith wrote: > > On 6/3/2018 10:55 AM, Christian Tismer wrote: >> On 03.06.18 13:18, Ronald Oussoren wrote: >>> >>> >>>> On 3 Jun 2018, at 12:03, Christian Tismer wrote: >> ... >>>> &g

Re: [Python-Dev] Idea: reduce GC threshold in development mode (-X dev)

> On 8 Jun 2018, at 12:36, Serhiy Storchaka wrote: > > 08.06.18 11:31, Victor Stinner пише: >> Do you suggest to trigger a fake "GC collection" which would just >> visit all objects with a no-op visit callback? I like the idea! >> >> Yeah, that would help to detect objects in an inconsistent s

Re: [Python-Dev] Some data points for the "annual release cadence" concept

> On 13 Jun 2018, at 15:42, Nick Coghlan wrote: > > On 13 June 2018 at 02:23, Guido van Rossum > wrote: > So, to summarize, we need something like six for C? > > Yeah, pretty much - once we can get to the point where it's routine for folks > to be building "abiX" or

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

> On 17 Jun 2018, at 11:00, Jeroen Demeyer wrote: > > Hello, > > I have been working on a slightly different PEP to use a new type slot > tp_ccalloffset instead the base_function base class. You can see the work in > progress here: > > https://github.com/jdemeyer/PEP-ccall > > By creating

Re: [Python-Dev] Some data points for the "annual release cadence" concept

> On 15 Jun 2018, at 13:00, Nick Coghlan wrote: > > On 14 June 2018 at 06:30, Ronald Oussoren <mailto:ronaldousso...@mac.com>> wrote: >> On 13 Jun 2018, at 15:42, Nick Coghlan > <mailto:ncogh...@gmail.com>> wrote: >> >> Yeah, pretty much - onc

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

> On 17 Jun 2018, at 16:31, Stefan Behnel wrote: > > 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 configura

Re: [Python-Dev] Computed Goto dispatch for Python 2

Op 28 mei 2015 om 21:37 heeft Chris Barker het volgende geschreven: > On Thu, May 28, 2015 at 12:25 PM, Sturla Molden > wrote: > >> The system >> Python should be left alone as it is. > > absolutely! > > By the way, py2app will build an application bundle that depends on the > system pyt

[Python-Dev] PEP 447 (type.__getdescriptor__)

for a real-world example of that. Regards, Ronald The PEP text (with an outdated section with benchmarks removed): PEP: 447 Title: Add __getdescriptor__ method to metaclass Version: $Revision$ Last-Modified: $Date$ Author: Ronald Oussoren Status: Draft Type: Standards Track Content-Type

Re: [Python-Dev] PEP 447 (type.__getdescriptor__)

> On 22 Jul 2015, at 18:02, Terry Reedy wrote: > > On 7/22/2015 3:25 AM, Ronald Oussoren wrote: >> Hi, >> >> Another summer with another EuroPython, which means its time again to >> try to revive PEP 447… >> >> I’ve just pushes a minor update to t

Re: [Python-Dev] PEP 447 (type.__getdescriptor__)

> On 22 Jul 2015, at 19:12, Steve Dower wrote: > > Terry Reedy wrote: >> On 7/22/2015 3:25 AM, Ronald Oussoren wrote: >>> Hi, >>> >>> Another summer with another EuroPython, which means its time again to >>> try to revive PEP 447… >>&g

Re: [Python-Dev] PEP 447 (type.__getdescriptor__)

hat I have to reimplement all logic in both object.__getattribute__ and super.__getattribute__ to be able to have a customisation of one small aspect of attribute lookup. Ronald > > d. > > On 22 July 2015 at 09:25, Ronald Oussoren wrote: >> Hi, >> >> Another summe

Re: [Python-Dev] PEP 447 (type.__getdescriptor__)

> On 24 Jul 2015, at 16:17, Nick Coghlan wrote: > > On 23 July 2015 at 03:12, Steve Dower <mailto:steve.do...@microsoft.com>> wrote: >> Terry Reedy wrote: >>> On 7/22/2015 3:25 AM, Ronald Oussoren wrote: >>>> Hi, >>>> >>>>

Re: [Python-Dev] PEP 447 (type.__getdescriptor__)

> On 24 Jul 2015, at 17:29, Nick Coghlan wrote: > > On 25 July 2015 at 00:50, Brett Cannon wrote: >> Leave the decorator out like __new__, otherwise people are bound to forget >> it and have a hard time debugging why their code doesn't work. > > I'd actually advocate for keeping this as a meta

Re: [Python-Dev] PEP 447 (type.__getdescriptor__)

d update the cache. Ronald > On 24 Jul 2015, at 19:55, Ronald Oussoren wrote: > >> >> On 24 Jul 2015, at 17:29, Nick Coghlan > <mailto:ncogh...@gmail.com>> wrote: >> >> On 25 July 2015 at 00:50, Brett Cannon > <mailto:br...@python.org>> wro

Re: [Python-Dev] PEP 447 (type.__getdescriptor__)

> On 25 Jul 2015, at 17:39, Mark Shannon wrote: > > Hi, > > On 22/07/15 09:25, Ronald Oussoren wrote:> Hi, >> >> Another summer with another EuroPython, which means its time again to >> try to revive PEP 447… >> > > IMO, there are two mai

Re: [Python-Dev] PEP 447 (type.__getdescriptor__)

> On 26 Jul 2015, at 09:14, Ronald Oussoren wrote: > > >> On 25 Jul 2015, at 17:39, Mark Shannon > <mailto:m...@hotpy.org>> wrote: >> >> Hi, >> >> On 22/07/15 09:25, Ronald Oussoren wrote:> Hi, >>> >>> Another summer w

Re: [Python-Dev] Status on PEP-431 Timezones

> On 27 Jul 2015, at 04:04, Tim Peters wrote: > > >> As an example, consider an alarm clock. I want it to go off at 7am >> each morning. I'd feel completely justified in writing tomorrows_alarm >> = todays_alarm + timedelta(days=1). >> >> If the time changes to DST overnight, I still want the

Re: [Python-Dev] Status on PEP-431 Timezones

> On 27 jul. 2015, at 20:49, Tim Peters wrote: > > [Ronald Oussoren ] >> IMHO “+ 1 days” and “+ 24 hours” are two different things. >> Date arithmetic is full of messy things like that. > > But it's a fact that they _are_ the same in naive time, which Pyt

Re: [Python-Dev] Status on PEP-431 Timezones

> On 28 Jul 2015, at 03:13, Tres Seaver wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/27/2015 06:11 PM, Ronald Oussoren wrote: > >> Treating time as UTC with conversions at the application edge might >> be "cleaner" in some

Re: [Python-Dev] Status on PEP-431 Timezones

> On 28 Jul 2015, at 03:13, Tres Seaver wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/27/2015 06:11 PM, Ronald Oussoren wrote: > >> Treating time as UTC with conversions at the application edge might >> be "cleaner" in some

Re: [Python-Dev] PEP 447 (type.__getdescriptor__)

> On 26 Jul 2015, at 14:18, Mark Shannon wrote: > >> On 26 July 2015 at 10:41 Ronald Oussoren wrote: >> >> >> >>> On 26 Jul 2015, at 09:14, Ronald Oussoren wrote: >>> >>> >>>> On 25 Jul 2015, at 17:39, Mark Shannon >

Re: [Python-Dev] Verification of SSL cert and hostname made easy

> On 30 nov. 2013, at 19:29, Christian Heimes wrote: > > With CERT_REQUIRED OpenSSL verifies that the peer's certificate is > directly or indirectly signed by a trusted root certification authority. > With Python 3.4 the ssl module is able to use/load the system's trusted > root certs on all ma

Re: [Python-Dev] Python 3.4: What to do about the Derby patches

On 20 Feb 2014, at 08:09, Nick Coghlan wrote: > On 20 February 2014 16:42, Ronald Oussoren wrote: >> >> On 17 Feb 2014, at 00:43, Nick Coghlan wrote: >> >>> >>> On 17 Feb 2014 08:36, "Greg Ewing" wrote: >>>> >>>> La

Re: [Python-Dev] Python 3.4: What to do about the Derby patches

On 17 Feb 2014, at 00:43, Nick Coghlan wrote: > > On 17 Feb 2014 08:36, "Greg Ewing" wrote: > > > > Larry Hastings wrote: > > > >> 3) We hold off on merging the rest of the Derby patches until after 3.4.0 > >> final ships, then we merge them into the 3.4 maintenance branch so they go > >> in

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 21 Feb 2014, at 16:52, Chris Angelico wrote: > On Sat, Feb 22, 2014 at 1:34 AM, Brett Cannon wrote: >> While I like the general concept, I agree that it looks too much like a >> crunched statement; the use of the colon is a non-starter for me. I'm sure >> I'm not the only one whose brain has

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 27 Feb 2014, at 11:09, Chris Angelico wrote: > On Thu, Feb 27, 2014 at 7:44 PM, Ronald Oussoren > wrote: >> What about (also mentioned in the PEP)? >> >> value = (expr except Exception try default) >> >> This seems to read nicely, although “try” is at

Re: [Python-Dev] cffi in stdlib

On 26 Feb, 2013, at 16:13, Maciej Fijalkowski wrote: > Hello. > > I would like to discuss on the language summit a potential inclusion > of cffi[1] into stdlib. The API in general looks nice, but I do have some concens w.r.t. including cffi in the stdlib. 1. Why is cffi completely separate

Re: [Python-Dev] cffi in stdlib

On 27 Feb, 2013, at 10:06, Maciej Fijalkowski wrote: > On Wed, Feb 27, 2013 at 9:29 AM, Ronald Oussoren > wrote: >> >> On 26 Feb, 2013, at 16:13, Maciej Fijalkowski wrote: >> >>> Hello. >>> >>> I would like to discuss on the language summ

Re: [Python-Dev] [Python-checkins] peps: New DSL syntax and slightly changed semantics for the Argument Clinic DSL.

On 18 Mar, 2013, at 8:16, Larry Hastings wrote: > > This has some consequences. For example, inspect.getfullargspec, > inspect.Signature, and indeed types.FunctionObject and types.CodeObject have > no currently defined mechanism for communicating that a parameter is > positional-only. I st

Re: [Python-Dev] [Python-checkins] peps: New DSL syntax and slightly changed semantics for the Argument Clinic DSL.

On 18 Mar, 2013, at 23:43, Larry Hastings wrote: > On 03/18/2013 02:29 AM, Ronald Oussoren wrote: >> On 18 Mar, 2013, at 8:16, Larry Hastings wrote: >>> This has some consequences. For example, inspect.getfullargspec, >>> inspect.Signature, and inde

Re: [Python-Dev] Rough idea for adding introspection information for builtins

On 19 Mar, 2013, at 10:24, Larry Hastings wrote: > > >>> We'd want one more mild hack: the DSL will support positional >>> parameters, and inspect.Signature supports positional parameters, so >>> it'd be nice to render that information. But we can't represent that in >>> Python syntax (or a

Re: [Python-Dev] How to fix the incorrect shared library extension on linux for 3.2 and newer?

On 4 Apr, 2013, at 14:46, Julian Taylor wrote: > The values on macos for these variables still look wrong in 3.3.1rc1: > > ./configure --prefix=/Users/jtaylor/tmp/py3.3.1 --enable-shared > on macosx-10.8-x86_64 > > sys.version_info(major=3, minor=3, micro=1, releaselevel='candidate', > serial

Re: [Python-Dev] casefolding in pathlib (PEP 428)

On 12 Apr, 2013, at 10:39, Antoine Pitrou wrote: >> >> >> Perhaps it would be best if the code never called lower() or upper() >> (not even indirectly via os.path.normcase()). Then any case-folding >> and path-normalization bugs are the responsibility of the application, >> and we won't have to

Re: [Python-Dev] casefolding in pathlib (PEP 428)

On 12 Apr, 2013, at 15:00, Christian Heimes wrote: > Am 12.04.2013 14:43, schrieb Ronald Oussoren: >> At least for OSX the kernel will normalize names for you, at least for HFS+, >> and therefore two names that don't compare equal with '==' can refer to the >

Re: [Python-Dev] casefolding in pathlib (PEP 428)

On 12 Apr, 2013, at 16:59, Antoine Pitrou wrote: > Le Fri, 12 Apr 2013 14:43:42 +0200, > Ronald Oussoren a écrit : >> >> On 12 Apr, 2013, at 10:39, Antoine Pitrou wrote: >>>> >>>> >>>> Perhaps it would be best if the code never c

Re: [Python-Dev] libffi inclusion in python

On 18 apr. 2013, at 18:09, Ned Deily wrote: > In article > , > Benjamin Peterson wrote: >> 2013/4/18 Maciej Fijalkowski : >>> libffi has bugs sometimes (like this >>> http://bugs.python.org/issue17580). Now this is a thing that upstream >>> fixes really quickly, but tracking down issues on bugs

Re: [Python-Dev] libffi inclusion in python

On 19 Apr, 2013, at 10:13, Dirkjan Ochtman wrote: > On Thu, Apr 18, 2013 at 11:17 PM, Ronald Oussoren > wrote: >> Stripping libffi from python's source tree would be fine by me, but would >> require testing with upstream libffi. AFAIK system libffi on osx wouldn&#

Re: [Python-Dev] [Python-checkins] cpython (3.3): backported rev 79713 from 3.4, test_recursion_limit skipped for -O0

On 24 Apr, 2013, at 1:32, "lukasz.langa" wrote: > http://hg.python.org/cpython/rev/9755036c81d0 > changeset: 83510:9755036c81d0 > branch: 3.3 > parent: 83508:44d764238f0d > user:Łukasz Langa > date:Wed Apr 24 01:29:26 2013 +0200 > summary: > backported rev 79713 fro

Re: [Python-Dev] [Python-checkins] cpython (3.3): backported rev 79713 from 3.4, test_recursion_limit skipped for -O0

On 24 Apr, 2013, at 8:14, Ronald Oussoren wrote: > > On 24 Apr, 2013, at 1:32, "lukasz.langa" wrote: > >> http://hg.python.org/cpython/rev/9755036c81d0 >> changeset: 83510:9755036c81d0 >> branch: 3.3 >> parent: 83508:44d764238f0d >&g

Re: [Python-Dev] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info

On 10 May, 2013, at 14:16, Antoine Pitrou wrote: > Le Fri, 10 May 2013 13:46:30 +0200, > Christian Heimes a écrit : >> >> Hence I'm +1 on the general idea but -1 on something stat like. IMHO >> os.scandir() should yield four objects: >> >> * name >> * inode >> * file type or DT_UNKNOWN >> * s

Re: [Python-Dev] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info

On 10 May, 2013, at 15:54, Antoine Pitrou wrote: > Le Fri, 10 May 2013 15:46:21 +0200, > Christian Heimes a écrit : > >> Am 10.05.2013 14:16, schrieb Antoine Pitrou: >>> But what if some systems return more than the file type and less >>> than a full stat result? The general problem is POSIX's

Re: [Python-Dev] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info

On 10 May, 2013, at 16:30, MRAB wrote: >> > [snip] > In the python-ideas list there's a thread "PEP: Extended stat_result" > about adding methods to stat_result. > > Using that, you wouldn't necessarily have to look at st.st_mode. The method > could perform an additional os.stat() if the field

Re: [Python-Dev] Segmentation fault on 3.4 with --pydebug

On 30 May, 2013, at 13:08, Łukasz Langa wrote: > This happens after Benjamin's changes in 83937. Anybody else seeing this? > > Intel i5 2.4 GHz, Mac OS X 10.8.3, clang > > $ hg up default > $ make distclean > $ MACOSX_DEPLOYMENT_TARGET=10.8 ./configure --with-pydebug > $ make > $ ./python.exe

Re: [Python-Dev] Putting the Mac Build in the Apple App Store

On 4 Jun, 2013, at 6:44, Raymond Hettinger wrote: > Does anyone know what we would need to do to get Python in the Apple > application store as a free App? > > The default security settings on OS X 10.8 block the installation of the DMG > (or any software downloaded outside the app store).

Re: [Python-Dev] Validating SSL By Default (aka Including a Cert Bundle in CPython)

On 3 Jun, 2013, at 7:58, Benjamin Peterson wrote: > 2013/6/2 Donald Stufft : >> As of right now, as far as I can tell, Python does not validate HTTPS >> certificates by default. As far as I can tell this is because there is no >> guaranteed certificates available. >> >> So I would like to propo

Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

On 26 Jun, 2013, at 14:18, Eric V. Smith wrote: > On 6/26/2013 6:43 AM, a.cava...@cavallinux.eu wrote: >> .. or having hg "purging" unwanted build artifact (probably cleaning up >> the .hgignore file first) > > How would that work? How could hg purge the .bak, .orig, .rej, .old, > etc. files? >

Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

On 26 Jun, 2013, at 15:39, Barry Warsaw wrote: > On Jun 26, 2013, at 09:04 AM, Eric V. Smith wrote: > >> I run 'make distclean' fairly often, but maybe it's just out of habit. >> If I'm adding/deleting modules, I want to make sure there are no build >> artifacts. And since I have modified files

[Python-Dev] Hooking into super() attribute resolution

, and I'm sure that I'll find edge cases that I haven't thought about yet when I add tests. Ronald PEP: TODO Title: Hooking into super attribute resolution Version: $Revision$ Last-Modified: $Date$ Author: Ronald Oussoren Status: Draft Type: Standards Track Content-Type: text/x

Re: [Python-Dev] PEP 446: Add new parameters to configure the inherance of files and for non-blocking sockets

On 4 Jul, 2013, at 13:19, Victor Stinner wrote: > 2013/7/4 Victor Stinner : >> Add a new optional *cloexec* on functions creating file descriptors: >> >> * ``io.FileIO`` >> * ``io.open()`` >> * ``open()`` > > The PEP 433 proposes adding an "e" mode to open in alternatives. I > didn't keep this

Re: [Python-Dev] lament for the demise of unbound methods

On 4 Jul, 2013, at 13:21, Chris Withers wrote: > Hi All, > > In Python 2, I can figure out whether I have a method or a function, and, > more importantly, for an unbound method, I can figure out what class the > method belongs to: > > >>> class MyClass(object): > ... def method(self): pass

Re: [Python-Dev] Hooking into super() attribute resolution

Last-Modified: $Date$ Author: Ronald Oussoren Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 12-Jun-2013 Post-History: 2-Jul-2013, ? Abstract In current python releases the attribute resolution of the `super class`_ peeks in the ``__dict__`` attribute of class

Re: [Python-Dev] [Python-checkins] cpython (3.3): Issue #17860: explicitly mention that std* streams are opened in binary mode by

On 6 Jul, 2013, at 13:59, R. David Murray wrote: > On Sat, 06 Jul 2013 10:25:19 +0200, ronald.oussoren > wrote: >> http://hg.python.org/cpython/rev/a2c2ffa1a41c >> changeset: 84453:a2c2ffa1a41c >> branch: 3.3 >> parent: 84449:df79735b21c1 >> u

Re: [Python-Dev] PEP 446: Add new parameters to configure the inherance of files and for non-blocking sockets

On 6 Jul, 2013, at 14:04, Victor Stinner wrote: > 2013/7/6 Charles-François Natali : >>> I've read your "Rejected Alternatives" more closely and Ulrich >>> Drepper's article, though I think the article also supports adding >>> a blocking (default True) parameter to open() and os.open(). If you >

Re: [Python-Dev] [Python-checkins] cpython (3.3): Issue #17860: explicitly mention that std* streams are opened in binary mode by

On 6 Jul, 2013, at 14:09, Ronald Oussoren wrote: > > On 6 Jul, 2013, at 13:59, R. David Murray wrote: >> >> IMO, either the default should be mentioned first, or the default >> should be mentioned in a parenthetical. Otherwise it sounds like >> newline tra

Re: [Python-Dev] Rough idea for adding introspection information for builtins

On 6 Jul, 2013, at 19:33, Larry Hastings wrote: > > Once builtins have introspection information, pydoc can do a better job, and > Argument Clinic can stop generating its redundant prototype line. Not entirely on topic, but close enough: pydoc currently doesn't use the __signature__ informati

Re: [Python-Dev] Rough idea for adding introspection information for builtins

On 7 Jul, 2013, at 4:48, Larry Hastings wrote: > > If we combine that with the admittedly-new "/" indicating "all previous > parameters are positional-only", Signature objects use a name in angled brackets to indicate that a parameter is positional only, for example "input()". That might be

Re: [Python-Dev] Rough idea for adding introspection information for builtins

On 7 Jul, 2013, at 13:35, Larry Hastings wrote: > > On 07/07/2013 07:25 AM, Ronald Oussoren wrote: >> Signature objects use a name in angled brackets to indicate that a parameter >> is positional only, for example "input()". That might be an >> alternative to

Re: [Python-Dev] Rough idea for adding introspection information for builtins

On 7 Jul, 2013, at 19:20, Larry Hastings wrote: > On 07/07/2013 01:42 PM, Ronald Oussoren wrote: >> On 7 Jul, 2013, at 13:35, Larry Hastings >> wrote: >> >>> On 07/07/2013 07:25 AM, Ronald Oussoren wrote: >>> >>>> Signature objec

Re: [Python-Dev] Hooking into super() attribute resolution

efer to follow the documented procedure and have someone that knows what he's doing look at the metadata before checking in. > > Sent from my Windows Phone > From: Ronald Oussoren > Sent: ‎7/‎6/‎2013 0:47 > To: Ronald Oussoren > Cc: python-dev@python.org Dev > Subject: Re: [Python-

Re: [Python-Dev] Hooking into super() attribute resolution

On 8 Jul, 2013, at 17:19, Steve Dower wrote: > The only real advantage is a simpler signature and more easily explained use > (assuming the person you're explaining it to is familiar with metaclasses, so > most of the hard explaining has been done). The signature is as complex as it is to be

Re: [Python-Dev] Hooking into super() attribute resolution

On 9 Jul, 2013, at 1:21, Steve Dower wrote: >> > > Except that if it's on a metaclass, the 'instance' it has access to is cls. > The descriptor side of things is more interesting, but I see no reason why > super can't do that itself, since it knows the actual instance to call > __get__ with.

Re: [Python-Dev] Hooking into super() attribute resolution

On 9 Jul, 2013, at 1:21, Steve Dower wrote: > > Except that if it's on a metaclass, the 'instance' it has access to is cls. > The descriptor side of things is more interesting, but I see no reason why > super can't do that itself, since it knows the actual instance to call > __get__ with. (P

[Python-Dev] PEP 447: hooking into super() attribute resolution

super attribute resolution Version: $Revision$ Last-Modified: $Date$ Author: Ronald Oussoren Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 12-Jun-2013 Post-History: 2-Jul-2013, ? Abstract In current python releases the attribute resolution of the `super cl

Re: [Python-Dev] PEP 447: hooking into super() attribute resolution

On 15 Jul, 2013, at 18:49, Guido van Rossum wrote: > > >> A major open issue: the __locallookup__ method could also be used for normal >> attribute resolution, but that probably causes issues with attribute caching >> (see the PEP for details). I haven't worked out yet if it is worthwhile to

Re: [Python-Dev] [Python-checkins] cpython: Issue #18393: Remove use of deprecated API on OSX

On 15 Jul, 2013, at 18:43, Zachary Ware wrote: > On Mon, Jul 15, 2013 at 11:32 AM, ronald.oussoren > wrote: >> http://hg.python.org/cpython/rev/ccbaf6762b54 >> changeset: 84634:ccbaf6762b54 >> user:Ronald Oussoren >> date:Mon Jul 15 18:32:09 20

Re: [Python-Dev] Why does PEP 8 advise against explicit relative imports?

On 16 Jul, 2013, at 14:02, Thomas Wouters wrote: > On Tue, Jul 16, 2013 at 1:40 PM, Nick Coghlan wrote: > >> PEP 8 advises developers to use absolute imports rather than explicit >> relative imports. >> >> Why? Using absolute imports couple the internal implementation of a >> package to its p

Re: [Python-Dev] dict __contains__ raises TypeError on unhashable input

On 20 Jul, 2013, at 1:47, Ethan Furman wrote: > While working on issue #18508 I stumbled across this: > > Traceback (most recent call last): > ... > File "/usr/local/lib/python3.4/enum.py", line 417, in __new__ >if value in cls._value2member_map: > TypeError: unhashable type: 'list' > > I

Re: [Python-Dev] Building a Faster Python

On 22 Jul, 2013, at 3:01, Larry Hastings wrote: > On 07/21/2013 04:36 PM, Raymond Hettinger wrote: >> Our current Mac OS X builds use GCC-4.2. >> >> On Python2.7, I ran a comparison of gcc-4.2.1 builds >> versus gcc-4.8.1 and found that the latter makes a much >> faster Python. PyBench2.0 show

Re: [Python-Dev] Building a Faster Python

On 22 Jul, 2013, at 1:36, Raymond Hettinger wrote: > Our current Mac OS X builds use GCC-4.2. > > On Python2.7, I ran a comparison of gcc-4.2.1 builds > versus gcc-4.8.1 and found that the latter makes a much > faster Python. PyBench2.0 shows the total running time > dropping from 5653ms to 45

Re: [Python-Dev] Building a Faster Python

On 22 Jul, 2013, at 1:46, Ben Hoyt wrote: > > PyBench2.0 shows the total running time dropping from 5653ms to 4571ms. > > That's very cool -- a significant improvement. Is this the kind of change > that could go into 2.7.6 binaries? I'd prefer not to do that (but don't build the installers an

Re: [Python-Dev] cpython (2.7): Issue #18441: Make test.support.requires('gui') skip when it should.

On 22 Jul, 2013, at 7:35, Ned Deily wrote: > In article <51ecae41.5060...@udel.edu>, Terry Reedy > wrote: >> > > This is exactly what Issue8716 was about. The buildbot has no way of > knowing ahead of time whether a test will cause a crash or not. Yes, Tk > should not crash but it does i

Re: [Python-Dev] Building a Faster Python

On 22 Jul, 2013, at 9:32, Maciej Fijalkowski wrote: > On Mon, Jul 22, 2013 at 9:32 AM, Maciej Fijalkowski wrote: >> On Mon, Jul 22, 2013 at 8:15 AM, Antoine Pitrou wrote: >>> On Sun, 21 Jul 2013 16:36:35 -0700 >>> Raymond Hettinger wrote: Our current Mac OS X builds use GCC-4.2. >>

Re: [Python-Dev] Building a Faster Python

On 22 Jul, 2013, at 17:08, David Malcolm wrote: > On Mon, 2013-07-22 at 09:32 +0200, Maciej Fijalkowski wrote: >> On Mon, Jul 22, 2013 at 9:32 AM, Maciej Fijalkowski wrote: >>> On Mon, Jul 22, 2013 at 8:15 AM, Antoine Pitrou wrote: On Sun, 21 Jul 2013 16:36:35 -0700 Raymond Hettinger

Re: [Python-Dev] [Python-checkins] cpython: Issue #18520: Add a new PyStructSequence_InitType2() function, same than

On 23 Jul, 2013, at 2:01, Benjamin Peterson wrote: > We've cheerfully broken the ABI before on minor releases, though if > it's part of the stable ABI, we can't be cavaliar about that anymore. It is not part of the stable ABI. Given that the implementation of PyStructSequence_InitType() in the

Re: [Python-Dev] tuple index out of range

On 23 Jul, 2013, at 12:17, Nicholas Hart wrote: > Hi, > > I am new to this list and to troubleshooting python. I hope someone can help > me. I am getting this tuple index out of range error while running a test > call to my python code. Not sure what this error really means and was hoping

Re: [Python-Dev] cpython (3.3): return NULL here

On 23 Jul, 2013, at 17:36, Christian Heimes wrote: > Am 23.07.2013 17:10, schrieb Benjamin Peterson: >>> PyErr_SetFromErrno() already and always returns NULL. Or do you prefer >>> to return NULL explicitly? >> >> It might always return NULL, but the compiler sees (PyObject *)NULL >> when this f

Re: [Python-Dev] [Python-checkins] cpython (3.3): return NULL here

On 24 Jul, 2013, at 8:43, Gregory P. Smith wrote: > > On Tue, Jul 23, 2013 at 8:46 AM, Ronald Oussoren > wrote: > > On 23 Jul, 2013, at 17:36, Christian Heimes wrote: > > > Am 23.07.2013 17:10, schrieb Benjamin Peterson: > >>> PyErr_SetFromErrno() al

Re: [Python-Dev] Daemon creation code in the standard library

On 25 Jul, 2013, at 4:18, Ben Finney wrote: > Ben Finney writes: > >> Work continues on the PEP 3143-compatible ‘python-daemon’, porting it to >> Python 3 and aiming for inclusion in the standard library. At first glance the library appears to close all open files, with an option to exclude s

Re: [Python-Dev] Official github mirror for CPython?

On 26 Jul, 2013, at 9:50, Antoine Pitrou wrote: > Le Fri, 26 Jul 2013 09:31:50 +1000, > Nick Coghlan a écrit : >> >> To be honest, if people are going to spend time tinkering with our VCS >> infrastructure, one of the most interesting things we could do is >> explore what would be involved in

[Python-Dev] PEP 446: cloexec flag on os.open

Victor, PEP 446 mentions that a cloexec flag gets added to os.open. This API already has a way to specify this: the O_CLOEXEC bit in the flags argument. A new cloexec parameter is nicely consistent with the other APIs, but introcudes a second way to set that flag. What will the following calls

[Python-Dev] PEP 447: add type.__locallookup__

addition * type.__locallookup__ is no longer optional. * I've added benchmarking results using pybench. (using the patch attached to issue 18181) Ronald PEP: 447 Title: Add __locallookup__ method to metaclass Version: $Revision$ Last-Modified: $Date$ Author: Ronald Oussoren Status:

Re: [Python-Dev] PEP 447: add type.__locallookup__

On 29 Jul, 2013, at 14:58, Antoine Pitrou wrote: > > Hi, > > Le Mon, 29 Jul 2013 14:49:18 +0200, > Ronald Oussoren a écrit : >> Hi, >> >> This PEP proposed to add a __locallookup__ slot to type objects, >> which is used by _PyType_Lookup and supe

Re: [Python-Dev] PEP 447: add type.__locallookup__

On 29 Jul, 2013, at 15:07, Ronald Oussoren wrote: > > On 29 Jul, 2013, at 14:58, Antoine Pitrou wrote: > >> >> Hi, >> >> Le Mon, 29 Jul 2013 14:49:18 +0200, >> Ronald Oussoren a écrit : >>> Hi, >>> >>> This PEP proposed t

[Python-Dev] to rename or not...

Hi, The relevant issue for this question is Plistlib contains object serialization logic that is in spirit simular to json and pickle, but has a different output format and different limitations. The functions in the module don't reflect that though, they are

Re: [Python-Dev] PEP 447: add type.__locallookup__

On 29 Jul, 2013, at 14:49, Ronald Oussoren wrote: > Hi, > > This PEP proposed to add a __locallookup__ slot to type objects, > which is used by _PyType_Lookup and super_getattro instead of peeking > in the tp_dict of classes. The PEP text explains why this is needed. > >

  1   2   3   4   5   >