Re: [Python-Dev] Changing Clinic's output

I favor a dual-mode approach. I think the existing behavior is best for the conversion of existing modules, because it's easy to interactively verify the generated code. Once that's done, long-term maintenance definitely favors a more centralized format. +1 _pickle.original.c /* used only during c

Re: [Python-Dev] PEP 460 reboot

On 1/14/2014 3:54 PM, Guido van Rossum wrote: > On Tue, Jan 14, 2014 at 12:13 PM, Ethan Furman wrote: >> In Py2, because '%15s' can actually take 17 characters, I have to use '%15s' >> % data_value[:15] everywhere. > > Wow. I thought there would be some combination using %.15s but I can't > get t

Re: [Python-Dev] PEP 460 reboot

On 01/14/2014 01:52 PM, Guido van Rossum wrote: > But the way to arrive at this behavior without duplicating a whole lot > of code seems to be to call the existing text-based __format__ API and > convert the result to bytes -- for numbers this should be safe (their > formatting produces just ASCII

Re: [Python-Dev] PEP 460 reboot

On 1/13/2014 4:59 PM, Guido van Rossum wrote: > On Mon, Jan 13, 2014 at 1:29 PM, Glenn Linderman > wrote: >> If somehow (unlikely though it seems) we end up keeping %s (e.g. >> strictly to ease porting), we could also keep %r as an alias for %a. >> >> >> %s for strictly interpolating bytes eases

Re: [Python-Dev] PEP 460 reboot

On 01/13/2014 03:09 PM, Guido van Rossum wrote: > If we have %b for strictly interpolating bytes, I'm fine with adding > %a for calling ascii() on the argument and then interpolating the > result after ASCII-encoding it. > > If somehow (unlikely though it seems) we end up keeping %s (e.g. > strict

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

On 1/10/2014 8:12 PM, Antoine Pitrou wrote: > On Fri, 10 Jan 2014 16:23:53 -0800 > Ethan Furman wrote: >> On 01/08/2014 02:42 PM, Antoine Pitrou wrote: >>> >>> With Victor's consent, I overhauled PEP 460 and made the feature set >>> more restricted and consistent with the bytes/str separation. >>

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

On 1/10/2014 6:02 PM, Antoine Pitrou wrote: > On Fri, 10 Jan 2014 14:58:15 -0800 > Ethan Furman wrote: >> On 01/10/2014 02:42 PM, Antoine Pitrou wrote: >>> On Fri, 10 Jan 2014 17:33:57 -0500 >>> "Eric V. Smith" wrote: >>>> On 1/10/2014 5:29 PM

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

On 1/10/2014 5:29 PM, Antoine Pitrou wrote: > On Fri, 10 Jan 2014 12:56:19 -0500 > "Eric V. Smith" wrote: >> >> I agree. I don't see any reason to exclude int and float. See Guido's >> messages http://bugs.python.org/issue3982#msg180423 and >> h

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

On 1/10/2014 5:12 PM, Victor Stinner wrote: > 2014/1/10 Juraj Sukop : >> In the case of PDF, the embedding of an image into PDF looks like: >> >> 10 0 obj >> << /Type /XObject >> /Width 100 >> /Height 100 >> /Alternates 15 0 R >> /Length 2167 >> >

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

On 1/10/2014 12:17 PM, Juraj Sukop wrote: > (Sorry if this messes-up the thread order, it is meant as a reply to the > original RFC.) > > Dear list, > > newbie here. After much hesitation I decided to put forward a use case > which bothers me about the current proposal. Disclaimer: I happen to >

Re: [Python-Dev] [Python-checkins] peps: PEP 460: add .format_map()

On 1/10/2014 10:20 AM, Nick Coghlan wrote: > On 10 January 2014 07:41, Eric V. Smith wrote: >> I'm not sure how format_map helps in porting from 2 to 3, since it >> doesn't exist in any version of 2. >> >> Although that said, it's no doubt a usefu

Re: [Python-Dev] [Python-checkins] peps: PEP 460: add .format_map()

I'm not sure how format_map helps in porting from 2 to 3, since it doesn't exist in any version of 2. Although that said, it's no doubt a useful feature, just not useful in code that supports both 2 and 3 with a single code base or when porting to 3. Eric. On 1/9/2014 4:02 PM, antoine.pitrou wro

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

On 01/07/2014 06:24 AM, Stefan Krah wrote: > Antoine Pitrou wrote: >>> Very nice, thanks. If I was to make a blasphemous suggestion I would >>> even target it for Python 3.4. (No, seriously, this is a big issue >>> - see the recent discussion by Armin - and the big names involved show >>> that i

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

On 01/06/2014 09:50 AM, Xavier Morel wrote: > On 2014-01-06, at 14:44 , Antoine Pitrou wrote: >>> Then, >>> the following points must be decided to define the complete list of >>> supported features (formatters): >>> >>> * Format integer to hexadecimal? ``%x`` and ``%X`` >>> * Format integer to oc

Re: [Python-Dev] 2.x vs 3.x survey results

Somewhere you need to describe the survey methodology, who was surveyed, how were they selected, etc. On Thu, Jan 2, 2014 at 2:54 PM, Dan Stromberg wrote: > On Thu, Jan 2, 2014 at 1:34 PM, Antoine Pitrou > wrote: > > On Thu, 2 Jan 2014 13:10:36 -0800 > > Dan Stromberg wrote: > >> Is there a b

Re: [Python-Dev] assert(blah blah) in the C code base

On 12/27/2013 7:53 PM, Ethan Furman wrote: > Greetings! > > I'm working on Issue19995, and I'm seeing stuff like this: > > assert(PyLong_Check(val)); > > My question is: Are these asserts in final production code? > > My possible scenarios are: > > - the assert isn't in place > - the as

Re: [Python-Dev] How long the wrong type of argument should we limit (or not) in the error message (C-api)?

On 12/16/2013 03:49 PM, Nick Coghlan wrote: > > On 17 Dec 2013 02:23, "Eric V. Smith" <mailto:e...@trueblade.com>> wrote: >> >> On 12/16/2013 10:29 AM, Walter Dörwald wrote: >> > I'd vote for including the module name in the string and using &g

Re: [Python-Dev] cffi in stdlib

On Thu, Dec 19, 2013 at 2:07 AM, Maciej Fijalkowski wrote: > On Thu, Dec 19, 2013 at 3:17 AM, Gregory P. Smith wrote: > > > > > > > > On Tue, Dec 17, 2013 at 8:43 AM, Stefan Krah > wrote: > >> > >> Maciej Fijalkowski wrote: > >> >

Re: [Python-Dev] cffi in stdlib

On Tue, Dec 17, 2013 at 8:43 AM, Stefan Krah wrote: > Maciej Fijalkowski wrote: > > I would like to discuss on the language summit a potential inclusion > > of cffi[1] into stdlib. This is a project Armin Rigo has been working > > for a while, with some input from other developers. > > I've trie

Re: [Python-Dev] How long the wrong type of argument should we limit (or not) in the error message (C-api)?

On 12/16/2013 10:29 AM, Walter Dörwald wrote: > I'd vote for including the module name in the string and using > __qualname__ instead of __name__, i.e. make "{:T}".format(obj) > equivalent to > "{0.__class__.__module__}.{0.__class__.qualname__}".format(obj). That's not possible in general. The for

Re: [Python-Dev] [Python-checkins] cpython (2.7): Fix test_fcntl to run properly on systems that do not support the flags

On Mon, Nov 25, 2013 at 12:46 AM, Nick Coghlan wrote: > > On 25 Nov 2013 14:46, "gregory.p.smith" > wrote: > > > > http://hg.python.org/cpython/rev/cac7319c5972 > > changeset: 87537:cac7319c5972 > > branch: 2.7 > > parent: 875

[Python-Dev] buildbot's are needlessly compiling -O0

our buildbots are setup to configure --with-pydebug which also unfortunately causes them to compile with -O0... this results in a python binary that is excruciatingly slow and makes the entire test suite run take a long time. given that nobody is ever going to run a gdb or another debugger on the

Re: [Python-Dev] can someone create a buildbot slave name & password for me?

On Sat, Nov 23, 2013 at 12:31 PM, Barry Warsaw wrote: > On Nov 23, 2013, at 10:34 AM, Gregory P. Smith wrote: > > >I've got a nice ARM box to add to the pool (it should be a lot faster and > >more reliable than warsaw-ubuntu-arm; hopefully making its way to stable). >

[Python-Dev] can someone create a buildbot slave name & password for me?

I've got a nice ARM box to add to the pool (it should be a lot faster and more reliable than warsaw-ubuntu-arm; hopefully making its way to stable). proposed slave name: gps-ubuntu-exynos5-armv7l description: Ubuntu ARM - Dual Cortex A15 2GiB (ie: a repurposed samsung ARM chromebook) thanks, -g

Re: [Python-Dev] PEP 428 - pathlib - ready for approval

On 11/20/2013 09:01 AM, Ethan Furman wrote: > On 11/20/2013 04:25 AM, Garth Bushell wrote: >> >> I'm also quite uneasy on the case insensitive comparison on Windows as >> the File system NTFS is case sensitive. > > No, it's case-preserving. > >> """Current Windows file systems, like NTFS, are cas

Re: [Python-Dev] [RELEASED] Python 3.3.3 final

How else would you know that anyone is listening? :) [yay, thanks for our being release monkey!] -gps On Tue, Nov 19, 2013 at 11:40 AM, Georg Brandl wrote: > Am 19.11.2013 17:14, schrieb Mark Lawrence: > > On 19/11/2013 06:59, Georg Brandl wrote: > >> > >> To download Python 3.3.3 rc2 visit:

Re: [Python-Dev] [Python-checkins] cpython: Fix _Py_normalize_encoding(): ensure that buffer is big enough to store "utf-8"

On 11/7/2013 5:13 PM, Victor Stinner wrote: > 2013/11/7 Eric V. Smith : >> Then how about at least a comment about how 6 is derived? >> >> if (lower_len < 6) /* 6 == strlen("utf-8") + 1 */ >> return 0; > > Ok, I added the com

Re: [Python-Dev] [Python-checkins] cpython: Fix _Py_normalize_encoding(): ensure that buffer is big enough to store "utf-8"

On 11/7/2013 4:38 PM, Victor Stinner wrote: > 2013/11/7 Benjamin Peterson : >> 2013/11/7 victor.stinner : >>> http://hg.python.org/cpython/rev/99afa4c74436 >>> changeset: 86995:99afa4c74436 >>> user:Victor Stinner >>> date:Thu Nov 07 13:33:36 2013 +0100 >>> summary: >>> Fix _Py

Re: [Python-Dev] [Python-checkins] cpython (3.3): Issue #18345: Added cookbook example illustrating handler customisation.

On 11/05/2013 07:55 AM, Eric V. Smith wrote: > I love all things British, but the python source code usually uses > "customiz*" (341 instances) over "customis*" (19 instance, 8 of which > are in logging). > > I realize "foolish consistency", and all

Re: [Python-Dev] [Python-checkins] cpython (3.3): Issue #18345: Added cookbook example illustrating handler customisation.

On 11/05/2013 05:03 AM, vinay.sajip wrote: > http://hg.python.org/cpython/rev/5636366db039 > changeset: 86936:5636366db039 > branch: 3.3 > parent: 86933:2c191b0b5e7a > user:Vinay Sajip > date:Tue Nov 05 10:02:21 2013 + > summary: > Issue #18345: Added cookbook exa

Re: [Python-Dev] python2 and python3 and vim

On Sun, Nov 3, 2013 at 8:59 AM, R. David Murray wrote: > I came across this in the VIM documentation: > > Vim can be built in four ways (:version output): > 1. No Python support(-python, -python3) > 2. Python 2 support only(+python or +python/dyn, -python3) > 3. Python

Re: [Python-Dev] On suppress()'s trail blazing (was Re: cpython: Rename contextlib.ignored() to contextlib.ignore())

> Right again. The simplest rule to remember seems to be "don't use yield or > yield-from inside a with-statement". You can relax it by limiting it to > context managers that manage any kind of shared resource, but that is > probably already too subtle: e.g. yielding inside "with open(file) as f" >

Re: [Python-Dev] On suppress()'s trail blazing (was Re: cpython: Rename contextlib.ignored() to contextlib.ignore())

On Thu, Oct 17, 2013 at 9:06 AM, Barry Warsaw wrote: > On Oct 18, 2013, at 01:26 AM, Nick Coghlan wrote: > > >By contrast, suppress() and redirect_stdout() are the *first* general > >purpose context managers added to contextlib since its incarnation in > >Python 2.5 (although there have been many

Re: [Python-Dev] Right place for PBKDF2 wrapper

On Sat, Oct 12, 2013 at 2:31 PM, Christian Heimes wrote: > Am 12.10.2013 23:04, schrieb Gregory P. Smith: > > agreed with any of these three. > > I'm going for hashlib.pbkdf2_hmac() for now. Right now it's just one > function. We can always add a new module for

Re: [Python-Dev] Right place for PBKDF2 wrapper

On Sat, Oct 12, 2013 at 11:06 AM, Georg Brandl wrote: > Am 12.10.2013 19:37, schrieb Antoine Pitrou: > > On Sat, 12 Oct 2013 19:19:44 +0200 > > Christian Heimes wrote: > ... > >> * add PBKDF2 to ``hashlib`` > >> * make ``hashlib`` a package and add PBKDF2 to a new ``hashlib.kdf`` > module > >>

Re: [Python-Dev] Support for marking limited API elements in C API docs

On 10/12/2013 4:04 PM, Georg Brandl wrote: > Am 12.10.2013 21:56, schrieb Antoine Pitrou: >> On Sat, 12 Oct 2013 21:19:16 +0200 >> Georg Brandl wrote: >>> Am 12.10.2013 20:20, schrieb Serhiy Storchaka: 12.10.13 21:04, Georg Brandl написав(ла): > in light of the recent thread about PEPs no

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

On Fri, Oct 11, 2013 at 11:41 AM, Glenn Linderman wrote: > On 10/11/2013 10:19 AM, Eric V. Smith wrote: > > On 10/11/2013 12:43 PM, Barry Warsaw wrote: > > On Oct 11, 2013, at 06:27 PM, Georg Brandl wrote: > > > Maybe to fit in with other verb-like APIs used as conte

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

On 10/11/2013 12:43 PM, Barry Warsaw wrote: > On Oct 11, 2013, at 06:27 PM, Georg Brandl wrote: > >> Maybe to fit in with other verb-like APIs used as context managers: >> it's open() not opened(). > > open() predates context managers, but maybe we need a new convention. > > with ignore(FileNotF

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

On 10/11/2013 5:00 AM, Antoine Pitrou wrote: > > Let me answer here to Nick's argument on the tracker (made last year, > before the patch was committed): > >> As with many context managers, a key benefit here is in the priming >> effect for readers. In this code: >> >> try: >># Whatev

Re: [Python-Dev] lzma and 'x' mode open

Please open a bug report on bugs.python.org so this doesn't get lost. -- Eric. > On Oct 8, 2013, at 8:49 PM, Tim Heaney wrote: > > I love the 'x' mode open in recent versions of Python. I just discovered that > lzma.open doesn't support it. It seems there's an elif that explicitly checks > t

Re: [Python-Dev] Make str/bytes hash algorithm pluggable?

On Thu, Oct 3, 2013 at 1:06 PM, Victor Stinner wrote: > 2013/10/3 Christian Heimes : > > A hash algorithm can be added and one avaible hash > > algorithm can be set before Py_Initialize() is called for the first > > time. > > "Py_Initialize" is not the good guard. Try for example "python3 -X > fau

Re: [Python-Dev] Make str/bytes hash algorithm pluggable?

On Thu, Oct 3, 2013 at 12:05 PM, Guido van Rossum wrote: > We already have adopted a feature that plugged most viable attacks on web > apps, I think that's enough. > Actually... we did not do a very good job on that: http://bugs.python.org/issue14621 The point of allowing alternates is to let p

Re: [Python-Dev] Make str/bytes hash algorithm pluggable?

On Thu, Oct 3, 2013 at 11:42 AM, Christian Heimes wrote: > Hi, > > some of you may have seen that I'm working on a PEP for a new hash API > and new algorithms for hashing of bytes and str. The PEP has three major > aspects. It introduces DJB's SipHash as secure hash algorithm, chances > the hash A

Re: [Python-Dev] Getting Tulip (PEP 3156) into the 3.4 stdlib, marked provisional, named asyncio

On 09/29/2013 08:55 PM, Guido van Rossum wrote: > On Sun, Sep 29, 2013 at 5:40 PM, Eric V. Smith <mailto:e...@trueblade.com>> wrote: > > On 9/27/2013 9:14 PM, Brett Cannon wrote: > > > I don't see any issue with redirecting the discussion. > pyt

Re: [Python-Dev] Getting Tulip (PEP 3156) into the 3.4 stdlib, marked provisional, named asyncio

On 9/27/2013 9:14 PM, Brett Cannon wrote: > I don't see any issue with redirecting the discussion. python-tulip@ is > acting like a SIG for the module, so no real precedent beyond it not > being hosted as a mail.python.org list. I'm sure I'm in the minority, but I'd like

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

On Wed, Sep 18, 2013 at 6:38 AM, Ronald Oussoren wrote: > > > On Sep 18, 2013, at 03:03 PM, "Martin v. Löwis" > wrote: > > Am 15.09.13 00:56, schrieb Ryan: > > +1. A 10.6-only build makes sense. > > > I'd like to support Russell's point: this could put a burden on everyone > releasing extension m

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

Just drop support for 10.6 with Python 3.4. Problem solved. People on that old of a version of the OS can build their own Python 3.4 or do the right thing and upgrade or just install Linux. This isn't Windows. Compiler tool chains are freely available for the legacy platform. We don't need to main

Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Fix http.server's request handling case on trailing '/'.

On 9/13/2013 3:22 AM, senthil.kumaran wrote: > http://hg.python.org/cpython/rev/b85c9d2a5227 > changeset: 85672:b85c9d2a5227 > parent: 85668:66ec8431032d > parent: 85671:1fcccbbe15e2 > user:Senthil Kumaran > date:Fri Sep 13 00:22:45 2013 -0700 > summary: > Fix http.se

Re: [Python-Dev] Add a "transformdict" to collections

On 9/10/2013 6:18 PM, Ethan Furman wrote: > On 09/10/2013 03:12 PM, MRAB wrote: >> On 10/09/2013 22:46, Antoine Pitrou wrote: >>> On Tue, 10 Sep 2013 18:44:20 -0300 >>> "Joao S. O. Bueno" wrote: On 10 September 2013 18:06, Antoine Pitrou wrote: > On Tue, 10 Sep 2013 17:38:26 -0300

Re: [Python-Dev] Add a "transformdict" to collections

On 09/10/2013 11:54 AM, Janzert wrote: > On 9/10/2013 10:54 AM, Antoine Pitrou wrote: >> (also, I would intuitively expect the latest key to be held, not the >> first one, since that's what happens for values.) >> >> Regards >> >> Antoine. >> > > I intuitively expected, and I think most often woul

Re: [Python-Dev] Add a new tracemalloc module to trace memory allocations

First, I really like this. +1 On Wed, Aug 28, 2013 at 6:07 PM, Victor Stinner wrote: > 2013/8/29 Victor Stinner : > > My proposed implementation for Python 3.4 is different: > > > > * no enable() / disable() function: tracemalloc can only be enabled > > before startup by setting PYTHONTRACEMALLO

Re: [Python-Dev] EINTR handling...

On Fri, Aug 30, 2013 at 10:57 AM, Guido van Rossum wrote: > I don't have a strong opinion on this either. The distinction between > send() and send_all() makes sense to me though (send_all() works hard to > get all your data out, send() only does what it can quickly). > > Personally for calls lik

Re: [Python-Dev] PEP 450 adding statistics module

On 8/15/2013 10:44 PM, Steven D'Aprano wrote: > On 16/08/13 04:10, Eric V. Smith wrote: > >> I agree with Mark: the proposed median, median.low, etc., doesn't feel >> right. Is there any example of doing this in the stdlib? > > The most obvious case is

Re: [Python-Dev] PEP 450 adding statistics module

On 8/15/2013 2:24 PM, R. David Murray wrote: > On Thu, 15 Aug 2013 14:10:39 -0400, "Eric V. Smith" > wrote: >> On 08/15/2013 01:58 PM, Mark Dickinson wrote: >>> On Thu, Aug 15, 2013 at 2:08 PM, Steven D'Aprano >> <mailto:st...@pearwood.info>> wr

Re: [Python-Dev] PEP 450 adding statistics module

On 08/15/2013 01:58 PM, Mark Dickinson wrote: > On Thu, Aug 15, 2013 at 2:08 PM, Steven D'Aprano > wrote: > > > - Each scheme ended up needing to be a separate function, for ease > of both implementation and testing. So I had four private median > function

Re: [Python-Dev] format, int, and IntEnum

On 08/15/2013 11:21 AM, Ethan Furman wrote: > Given that the !r and !s format codes can be used to get the repr and > str of an IntEnum, would it be acceptable to have IntEnum's __format__ > simply pass through to int's __format__? And likewise with all mix-in > classes? That helps with str.forma

Re: [Python-Dev] format, int, and IntEnum

On 08/15/2013 11:06 AM, Nick Coghlan wrote: > On 15 August 2013 05:03, Eric V. Smith wrote: >> On 8/15/2013 12:27 AM, Nick Coghlan wrote: >>> I think Eric is overinterpreting the spec, there. While that particular >>> sentence requires that the empty format str

Re: [Python-Dev] format, int, and IntEnum

On Aug 15, 2013, at 11:36 AM, Eli Bendersky wrote: > > > > On Thu, Aug 15, 2013 at 8:15 AM, Eric V. Smith wrote: >> On Aug 15, 2013, at 10:59 AM, Eli Bendersky wrote: >> >>> >>> >>> >>> On Thu, Aug 15, 2013 at 3:03 AM, Eric V.

Re: [Python-Dev] format, int, and IntEnum

On Aug 15, 2013, at 10:59 AM, Eli Bendersky wrote: > > > > On Thu, Aug 15, 2013 at 3:03 AM, Eric V. Smith wrote: >> On 8/15/2013 12:27 AM, Nick Coghlan wrote: >> > I think Eric is overinterpreting the spec, there. While that particular >> > sentence requir

Re: [Python-Dev] format, int, and IntEnum

On 8/15/2013 12:27 AM, Nick Coghlan wrote: > I think Eric is overinterpreting the spec, there. While that particular > sentence requires that the empty format string will be equivalent to a > plain str() operation for builtin types, it is only a recommendation for > other types. For enums, I believ

Re: [Python-Dev] Inherance of file descriptor and handles on Windows (PEP 446)

On Fri, Jul 26, 2013 at 3:23 PM, Antoine Pitrou wrote: > On Sat, 27 Jul 2013 00:18:40 +0200 > Victor Stinner wrote: > > 2013/7/26 Antoine Pitrou : > > > On Fri, 26 Jul 2013 22:17:47 +0200 > > >> """ > > >> On Linux, setting the close-on-flag has a low overhead on > > >> performances. Results of

Re: [Python-Dev] Inherance of file descriptor and handles on Windows (PEP 446)

On 7/24/2013 6:25 PM, Guido van Rossum wrote: >>> To reduce the need for 3rd party subprocess creation code, we should >>> have better daemon creation code in the stdlib -- I wrote some damn >>> robust code for this purpose in my previous job, but it never saw the >>> light of day. >> >> What do yo

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

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() already and always returns NULL. Or do you prefer > >>> to return NULL explicitly? > >> > >> It might alw

Re: [Python-Dev] Avoiding error from repr() of recursive dictview

On Mon, Jul 22, 2013 at 2:44 PM, Ben North wrote: > Hi, > > A friend of mine, Ruadhan O'Flanagan, came across a bug which turned out > to be the one noted in [http://bugs.python.org/issue18019], i.e.: > > >>> d={} > >>> d[42]=d.viewvalues() > >>> d > > > This issue has been fixed in hg; the beha

Re: [Python-Dev] [Python-checkins] cpython (3.3): let's not return NULL from functions that should return ints

[re-sending to python-dev] On 7/21/2013 4:27 PM, benjamin.peterson wrote: > @@ -267,7 +267,7 @@ > Py_DECREF(io); > Py_DECREF(binary); > PyMem_FREE(found_encoding); > -return PyErr_SetFromErrnoWithFilenameObject(PyExc_IOError, filename); > +return 0; >

Re: [Python-Dev] Misc re.match() complaint

On Mon, Jul 15, 2013 at 4:14 PM, Guido van Rossum wrote: > In a discussion about mypy I discovered that the Python 3 version of > the re module's Match object behaves subtly different from the Python > 2 version when the target string (i.e. the haystack, not the needle) > is a buffer object. > >

Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores

+1 This is already how we've been behaving for years. On Sun, Jul 14, 2013 at 4:09 AM, Nick Coghlan wrote: > On 14 July 2013 18:11, Nick Coghlan wrote: > >> Currently, the naming section of PEP 8 doesn't say very much about what a >> leading underscore *means* in the Python standard library.

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

Please update the docstring in subprocess.py with the wording improvements that you settle on while you're at it. On Sat, Jul 6, 2013 at 6:03 AM, Ronald Oussoren wrote: > > On 6 Jul, 2013, at 14:09, Ronald Oussoren wrote: > > > > > On 6 Jul, 2013, at 13:59, R. David Murray wrote: > >> > >> IMO

Re: [Python-Dev] Issue 18312 "fix" broke buildbots

On 07/02/2013 10:33 AM, R. David Murray wrote: > On Tue, 02 Jul 2013 09:52:56 -0400, "Eric V. Smith" > wrote: >> I'm not sure how my change broke the buildbots, but apparently it did. I >> need to run to a meeting now, but I can roll this back in the next fe

[Python-Dev] Issue 18312 "fix" broke buildbots

I'm not sure how my change broke the buildbots, but apparently it did. I need to run to a meeting now, but I can roll this back in the next few hours. If someone else wants to roll it back before I get to it, feel free. Sorry about the problem. I tested it locally, I'm not sure how the buildbots

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

On 7/1/2013 5:13 PM, R. David Murray wrote: > distclean still needs to be fixed, so please open a new issue for > adding buildclean or whatever you want to call it, as Eric requested > in the existing issue. I finally got around to testing it today, so I'm going to check in my change to 18312 some

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

9 AM, R. David Murray wrote: > On Mon, 01 Jul 2013 08:33:38 +0200, Georg Brandl wrote: > > Am 26.06.2013 16:24, schrieb Victor Stinner: > > > 2013/6/26 Eric V. Smith : > > >> I think that's exactly what's happening. > > >> >

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

On 6/26/2013 9:02 AM, Eric V. Smith wrote: > On 6/26/2013 8:44 AM, Oleg Broytman wrote: >> On Wed, Jun 26, 2013 at 08:18:27AM -0400, "Eric V. Smith" >> wrote: >>>>>> find $(srcdir)/* ... >>>>>> >>>>>> to avoid th

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

On 6/26/2013 8:57 AM, Ronald Oussoren wrote: > > 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

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

On 6/26/2013 8:44 AM, Oleg Broytman wrote: > On Wed, Jun 26, 2013 at 08:18:27AM -0400, "Eric V. Smith" > wrote: >>>>> find $(srcdir)/* ... >>>>> >>>>> to avoid this problem. It won't expand the .hg top-level directory. >>

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

On 6/26/2013 8:18 AM, 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,

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

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? >>> find $(srcdir)/* ... >>> >>> to avoid this problem. It wo

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

On 6/25/2013 9:33 PM, Senthil Kumaran wrote: > > > > On Tue, Jun 25, 2013 at 5:58 PM, Benjamin Peterson > wrote: > > 2013/6/25 Victor Stinner >: > > And then I ran "make distclean"... > > You've left us hanging... >

Re: [Python-Dev] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod

On Jun 24, 2013 9:11 PM, "Guido van Rossum" wrote: > > On Mon, Jun 24, 2013 at 7:47 PM, Raymond Hettinger < raymond.hettin...@gmail.com> wrote: >> >> >> >> On Jun 24, 2013, at 4:07 AM, Victor Stinner wrote: >> >>> Out of curiosity, do you know (remember) how was the number 62 chosen? >>> Is it a

Re: [Python-Dev] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod

Your work is great! I even agree with the changes on a coding best practices level. It's just that it belongs on the default (3.4) branch as it is an enhancement, not a bug fix. We don't do new things on release branches. I agree that can be extremely frustrating at times, knowing that code won'

Re: [Python-Dev] stat module in C -- what to do with stat.py?

On 6/21/2013 7:39 AM, Nick Coghlan wrote: > On 21 June 2013 17:25, Victor Stinner wrote: >> 2013/6/21 Nick Coghlan : >>> Because practicality beats purity. This "wrong" Python code has been >>> good enough for all Python version up until 3.4, it makes sense to >>> keep it as a fallback instead of

Re: [Python-Dev] stat module in C -- what to do with stat.py?

On 6/20/2013 4:53 PM, Victor Stinner wrote: > 2013/6/20 Eric V. Smith >: >> But isn't the real problem with this module in Python the fact that the >> constants might be wrong? I'm not sure what, if anything, we can do >> about that. > > Python is provi

Re: [Python-Dev] stat module in C -- what to do with stat.py?

On 6/20/2013 9:40 AM, Nick Coghlan wrote: > On 20 June 2013 23:29, Christian Heimes wrote: >> Am 20.06.2013 15:21, schrieb Florent: >>> we already have "_pyio.py", we could have "_pystat.py". >> >> Works for me. > > I suggest following the guidelines in PEP 399 for cross implementation > compatib

Re: [Python-Dev] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod

Raymond - Why did you do this in the 2.7 branch? It hasn't been done in 3.3 or default and it isn't not the sort of change we make in a stable release branch without justification. What issue was this for? What problem were you solving? -gps On Mon, Jun 17, 2013 at 11:08 PM, Ethan Furman w

Re: [Python-Dev] backported Enum

I tend to just pick a name and stick with it. subprocess32 is subprocess backported from 3.2 (with the 3.3 timeout feature also in it). unittest2 is unittest from 2.7. It tends to work. and it also emphasizes that i'm unlikely to backport future non-bugfix updates beyond the release mentioned a

Re: [Python-Dev] cpython: Issue #3329: Add new APIs to customize memory allocators

fwiw i'm also supportive of adding these apis. Lets PEP away to iron out any details or document disagreements but overall I'd also like to see something a lot like these go in. -gps On Fri, Jun 14, 2013 at 10:50 PM, Nick Coghlan wrote: > On 15 June 2013 11:54, Victor Stinner wrote: > > 2013

Re: [Python-Dev] Problem building Python 2.7.5 with separate sysroot

On Fri, 2013-05-31 at 01:21 -0700, Ned Deily wrote: > In article <1369986770.4119.43.camel@homebase>, > Paul Smith wrote: > > > Hi all. I'm trying to build Python 2.7.5 on a GNU/Linux (Linux Mint 14) > > system, but using a different sysroot (that is, a separate

[Python-Dev] Problem building Python 2.7.5 with separate sysroot

Hi all. I'm trying to build Python 2.7.5 on a GNU/Linux (Linux Mint 14) system, but using a different sysroot (that is, a separate /usr/include, /usr/lib, etc., not the real one for my system). I have shell script wrappers around GCC and its various tools that invoke it with the right paths to fo

Re: [Python-Dev] PEP 442 delegate

+1 I second the scoundrel! fwiw, that pep being implemented is going to be a great addition to Python. :) On Tue, May 21, 2013 at 8:57 AM, Antoine Pitrou wrote: > > Hello, > > I would like to nominate Benjamin as BDFL-Delegate for PEP 442. > Please tell me if you would like to object :) > > R

Re: [Python-Dev] PEP 409 and the stdlib

On May 20, 2013, at 11:46 AM, Antoine Pitrou wrote: > On Mon, 20 May 2013 07:12:07 -0700 > Ethan Furman wrote: >> >> As a case in point, base64.py is currently getting a bug fix, and also >> contains this code: >> >> def b32decode(s, casefold=False, map01=None): >> . >> . >> . >

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

On May 19, 2013 4:31 PM, "Benjamin Peterson" wrote: > > 2013/5/19 Gregory P. Smith : > > Idea: I don't believe anybody has written a fixer for lib2to3 that applies > > fixers to doctests. That'd be an interesting project for someone. > > 2to3 c

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

On Sat, May 18, 2013 at 11:41 PM, Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > > On May 14, 2013, at 9:39 AM, Gregory P. Smith wrote: > > Bad: doctests. > > > I'm hoping that core developers don't get caught-up in the "doctests are >

Re: [Python-Dev] Mysterious Python pyc file corruption problems

On Thu, May 16, 2013 at 11:04 AM, Barry Warsaw wrote: > On May 16, 2013, at 09:44 AM, Ethan Furman wrote: > > >Is it happening on the same machines? If so, perhaps a daemon to monitor > >those files and then scream and shout when one changes. Might help track > >down what's going on at the time

Re: [Python-Dev] Best practices for Enum

Bad: doctests. On Tue, May 14, 2013 at 5:08 AM, Steven D'Aprano wrote: > On 14/05/13 16:51, Gregory P. Smith wrote: > [...] > > This sounds like a feature request for doctest. doctest could be educated >> about enums and automatically compare to the integer value for su

Re: [Python-Dev] Best practices for Enum

On Sun, May 12, 2013 at 4:49 PM, Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > > * will enums break doctests or any existing user code > Those are already broken by design. We shouldn't be limited just because someone wrote a bad test that assumed a particular repr of a value. We've

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

On Sun, May 12, 2013 at 3:04 PM, Ben Hoyt wrote: > > And if we're creating a custom object instead, why return a 2-tuple > > rather than making the entry's name an attribute of the custom object? > > > > To me, that suggests a more reasonable API for os.scandir() might be > > for it to be an iter

Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

On Mon, May 6, 2013 at 7:50 PM, Terry Jan Reedy wrote: > On 5/6/2013 6:34 PM, Antoine Pitrou wrote: > >> On Mon, 06 May 2013 18:23:02 -0400 >> Terry Jan Reedy wrote: >> >>> >>> 'Item' is necessarily left vague for mutable sequences as bytearrays >>> also store values. The fact that Antoine's exa

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

On 5/4/2013 2:42 AM, Nick Coghlan wrote: > On Sat, May 4, 2013 at 4:10 PM, Georg Brandl wrote: >> Am 04.05.2013 01:22, schrieb Antoine Pitrou: >>> On Sat, 04 May 2013 11:15:17 +1200 >>> Greg Ewing wrote: Eli Bendersky wrote: > I'm just curious what it is about enums that sets everyone on

Re: [Python-Dev] The end of 2.7

On Sun, Apr 7, 2013 at 6:53 AM, Christian Tismer wrote: > Hi Skip, > > > On 07.04.13 14:10, Skip Montanaro wrote: > > I started writing this last night before the flurry of messages which > arrived overnight. I thought originally, "Oh, Skip, you're being too > harsh." But now I'm not so sure.

Re: [Python-Dev] The end of 2.7

I agree with Benjamin though is it really necessary to do two 2.7 releases a year for the last two years? that's rather rapid (but as the release manager its your call). A few of us (sorry I forgot who all was there though I think Martin was?) had a discussion at PyCon a few weeks ago and seemed

<    8   9   10   11   12   13   14   15   16   17   >