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: 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] 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] 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] 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] 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] 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] 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] [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] [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] 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] 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 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 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 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] 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] 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/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/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] Common subset of python 2 and python 3

On 1/15/2014 8:21 AM, Chris Angelico wrote: > On Wed, Jan 15, 2014 at 11:22 PM, "Martin v. Löwis" > wrote: >> I don't think that it is possible to write an interpreter that is fully >> compatible for all it accepts. Would you think that the program >> >> print(repr(2**80).endswith("L")) >> >> is

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On 1/15/2014 9:45 AM, Brett Cannon wrote: > That's too vague; % interpolation does not support other format > operators in the same way as str.format() does. % interpolation has > specific code to support %d, etc. But str.format() gets supported for > {:d} not from special code but because e.g. fl

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On 1/15/2014 4:32 PM, Ethan Furman wrote: > A question for anyone that has extensive experience in both %-formatting > and .format-formatting: Would it be possible, at least for int and > float, to take whatever is in the specifier and convert to %? Example: > > "Weight: {wgt:-07f}".format(wgt

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On 01/16/2014 11:23 AM, Ethan Furman wrote: > On 01/16/2014 06:45 AM, Brett Cannon wrote: >> On Thu, Jan 16, 2014 at 2:51 AM, Ethan Furman wrote: >>> On 01/15/2014 06:45 AM, Brett Cannon wrote: This is why I have argued that if you specify it as "if there is a format spec specified,

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On 01/16/2014 01:55 PM, Ethan Furman wrote: >> "Magic" methods, including __format__, are called on the type, not the >> instance. > > Yes, that's why I said `myNum(17)` and not `myNum`. Oops, apologies. I misread the code. Eric. ___ Python-Dev maili

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On 1/17/2014 6:42 AM, Nick Coghlan wrote: > > On 17 Jan 2014 18:03, "Eric Snow" <mailto:ericsnowcurren...@gmail.com>> wrote: >> >> On Thu, Jan 16, 2014 at 11:30 AM, Eric V. Smith <mailto:e...@trueblade.com>> wrote: >> > For the fi

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On 01/17/2014 07:34 AM, Eric V. Smith wrote: > On 1/17/2014 6:42 AM, Nick Coghlan wrote: >> >> On 17 Jan 2014 18:03, "Eric Snow" > <mailto:ericsnowcurren...@gmail.com>> wrote: >>> >>> On Thu, Jan 16, 2014 at 11:30 AM, Eric V. Smith > <ma

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On 01/17/2014 10:15 AM, Mark Lawrence wrote: > On 17/01/2014 14:50, Eric V. Smith wrote: >> On 01/17/2014 07:34 AM, Eric V. Smith wrote: >>> On 1/17/2014 6:42 AM, Nick Coghlan wrote: >>>> >>>> On 17 Jan 2014 18:03, "Eric Snow" >>> &l

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On 01/17/2014 10:24 AM, Eric V. Smith wrote: > On 01/17/2014 10:15 AM, Mark Lawrence wrote: >> On 17/01/2014 14:50, Eric V. Smith wrote: >>> On 01/17/2014 07:34 AM, Eric V. Smith wrote: >>>> On 1/17/2014 6:42 AM, Nick Coghlan wrote: >>>&g

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On 01/17/2014 11:58 AM, Brett Cannon wrote: > > > > On Fri, Jan 17, 2014 at 11:16 AM, Barry Warsaw > wrote: > > On Jan 17, 2014, at 11:00 AM, Brett Cannon wrote: > > >I would rephrase it to "switch to %-formatting for bytes usage for > their > >common

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On 01/17/2014 02:04 PM, Glenn Linderman wrote: > On 1/17/2014 7:15 AM, Mark Lawrence wrote: >> For both options 1 and 2 surely you cannot be suggesting that after >> people have written 2.x code to use format() as %f formatting is to be >> deprecated, they now have to change the code back to the wa

Re: [Python-Dev] PEP 461 updates

On 1/17/2014 4:37 PM, Chris Barker wrote: > For the record, we've got a pretty good thread (not this good, though!) > over on the numpy list about how to untangle the mess that has resulted > from porting text-file-parsing code to py3 (and the underlying issue > with the 'S' data type in numpy...)

Re: [Python-Dev] .clinic.c vs .c.clinic

On 1/18/2014 11:24 AM, Stefan Krah wrote: > Serhiy Storchaka wrote: >> Now generated files have suffixes .clinic.c. I think it will be better, if >> they >> will end at special suffix (.c.clinic or even just .clinic). > > Can the output not go into a header file with static inline functions? >

Re: [Python-Dev] lambda (x, y):

On 1/24/2014 10:50 AM, Ram Rachum wrote: > I don't like how in Python 3.x, you can't do this: > > lambda (x, y): whatever > > It's quite useful in Python 2 > > if I understand correctly, it's a side effect of such packed arguments > not being allowed in function definitions. (i.e. def instea

Re: [Python-Dev] lambda (x, y):

On 01/26/2014 09:59 AM, francis wrote: > On 01/26/2014 03:42 AM, Raymond Hettinger wrote: >> >> I think that is an over-simplification. The argument unpacking was handy >> in a number of situations where *args wouldn't suffice: >> >>lambda (px, py), (qx, qy): ((px - qx) ** 2 + (py - qy) ** 2)

Re: [Python-Dev] [PATCH] Add an authorization header to the initial request.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/11/2014 08:04 AM, Matěj Cepl wrote: > On 2014-02-11, 12:27 GMT, you wrote: >>> This is my first attempt to contribute to Python itself, so >>> please be gentle with me. Yes, I know that I miss unit tests >>> and port to other branches of Python

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

On 2/21/2014 5:06 PM, Greg Ewing wrote: > Nick Coghlan wrote: >> On 21 February 2014 13:15, Chris Angelico wrote: >> >>> Generator expressions require parentheses, unless they would be >>> strictly redundant. Ambiguities with except expressions could be >>> resolved in the same way, forcing nes

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

On 2/22/2014 6:27 AM, Antoine Pitrou wrote: > On Sat, 22 Feb 2014 22:13:58 +1100 > Chris Angelico wrote: >> Lib/inspect.py:1350: >> return sys._getframe(1) if hasattr(sys, "_getframe") else None >> becomes >> return (sys._getframe(1) except AttributeError: None) > > May hide a bug if sys

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 2

On 2/23/2014 4:25 PM, Ethan Furman wrote: > I agree that having only one decimal format code would be nice, or even > two if the second one did something different, and that three seems > completely over the top -- unfortunately, Python 3.4 still supports all > three (%d, %i, and %u). Not supportin

Re: [Python-Dev] Python 4: don't remove anything, don't break backward compatibility

On 03/10/2014 02:21 PM, MRAB wrote: > On 2014-03-10 17:08, R. David Murray wrote: >> On Mon, 10 Mar 2014 16:06:22 -, Brett Cannon >> wrote: >>> On Mon Mar 10 2014 at 11:50:54 AM, Victor Stinner >>> >>> wrote: >>> >>> > 2014-03-10 16:25 GMT+01:00 Stefan Richthofer >>> : >>> > > I don't see the

Re: [Python-Dev] Whats New in 3.4 is pretty much done...

Thanks for all of the great work! -- Eric. > On Mar 10, 2014, at 10:05 PM, "R. David Murray" wrote: > > Well, I think What's New for 3.4 is done. I've been through all of the > NEWS items from the start of 3.4 through the beta1 release. I've gone > over the list of changes Serhiy found via th

Re: [Python-Dev] Whats New in 3.4 is pretty much done...

On 3/11/2014 9:05 AM, Victor Stinner wrote: > 2014-03-11 13:28 GMT+01:00 Nick Coghlan : >> I was thinking of adding a new "Migrating from Python 2" section at >> the end of the porting guide, noting the changed recommendations in >> the migration guide (i.e. people that read it a while ago should r

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 3/23/2014 11:37 AM, Donald Stufft wrote: > > On Mar 23, 2014, at 11:34 AM, Antoine Pitrou wrote: > >> On Sun, 23 Mar 2014 07:29:07 + >> Cory Benfield wrote: >>> This is an interesting idea. My biggest problem with it is that, at least >>> with the ssl library, these aren’t server-only pr

Re: [Python-Dev] Incorrect behavior in str.format() method when padding with '\x00'

On 04/02/2014 04:08 PM, John Tyree wrote: > > Hi all, > > Is there any particularly reason for the following behavior on both > 2.7.6 and 3.4.0 ? > > >>> "{:\x00<5}".format(2) > '2' > >>> > "{:\x20<5}".format(2) >

Re: [Python-Dev] Incorrect behavior in str.format() method when padding with '\x00'

On 04/03/2014 11:37 AM, R. David Murray wrote: > On Thu, 03 Apr 2014 11:20:20 -0400, "Eric V. Smith" > wrote: >> On 04/02/2014 04:08 PM, John Tyree wrote: >>> >>> Hi all, >>> >>> Is there any particularly reason for the following behavi

Re: [Python-Dev] Incorrect behavior in str.format() method when padding with '\x00'

On 04/03/2014 11:49 AM, MRAB wrote: > On 2014-04-03 16:20, Eric V. Smith wrote: >> On 04/02/2014 04:08 PM, John Tyree wrote: >>> >>> Hi all, >>> >>> Is there any particularly reason for the following behavior on both >>> 2.7.6 and 3.

Re: [Python-Dev] Behaviour change of object().format()

On 05/06/2014 10:33 AM, James Swift wrote: > Hi, > > In 3.3 I could do the following > "{x:s}".format(**{'x': [1, 2, 3]}) > '[1, 2, 3]' > > But in 3.4 > "{x:s}".format(**{'x': [1, 2, 3]}) > Traceback (most recent call last): > File "", line 1, in > TypeError: non-empty format strin

Re: [Python-Dev] Existence of pythonNN.zip in sys.path

On 5/6/2014 1:14 PM, Terry Reedy wrote: > On 5/5/2014 5:32 PM, Anthony Tuininga wrote: >> Hi, >> >> I am the author of cx_Freeze which creates "frozen" executables from >> Python scripts. To this point I have been using frozen modules (compiled >> C) but this has the side effect of bundling parts o

Re: [Python-Dev] Existence of pythonNN.zip in sys.path

On 05/07/2014 01:13 PM, Terry Reedy wrote: > On 5/7/2014 7:45 AM, Eric V. Smith wrote: >> On 5/6/2014 1:14 PM, Terry Reedy wrote: >>> On 5/5/2014 5:32 PM, Anthony Tuininga wrote: >>>> Hi, >>>> >>>> I am the author of cx_Freeze which creates

Re: [Python-Dev] %x formatting of floats - behaviour change since 3.4

On 6/3/2014 5:38 PM, Chris Angelico wrote: > I'm helping out with the micropython project and am finding that one > of their tests fails on CPython 3.5 (fresh build from Mercurial this > morning). It comes down to this: > > Python 3.4.1rc1 (default, May 5 2014, 14:28:34) > [GCC 4.8.2] on linux >

Re: [Python-Dev] namedtuple implementation grumble

On 6/7/2014 10:46 AM, Nick Coghlan wrote: > On 7 June 2014 04:50, Chris Withers wrote: >> Curious as to what lead to that implementation approach? What does it buy >> that couldn't have been obtained by a mixin providing the functionality? > > In principle, you could get the equivalent of collect

Re: [Python-Dev] namedtuple implementation grumble

On 6/8/2014 3:37 PM, dw+python-...@hmmz.org wrote: > On Sun, Jun 08, 2014 at 03:13:55PM -0400, Eric V. Smith wrote: > >>> The current implementation is also *really* easy to understand, >>> while writing out the dynamic type creation explicitly would likely >>>

Re: [Python-Dev] namedtuple implementation grumble

On 6/8/2014 7:31 PM, Steven D'Aprano wrote: > On Sun, Jun 08, 2014 at 03:13:55PM -0400, Eric V. Smith wrote: >> On 6/7/2014 10:46 AM, Nick Coghlan wrote: >>> On 7 June 2014 04:50, Chris Withers wrote: >>>> Curious as to what lead to that implementation a

Re: [Python-Dev] namedtuple implementation grumble

>> I wonder how a hybrid approach would work? Use a dynamically-created >> class, but then construct the __new__ method using exec and inject it >> into the new class. As far as I can see, it's only __new__ that benefits >> from the exec approach. >> >> Anyone tried this yet? Is it worth an expe

Re: [Python-Dev] Call for prudence about PEP-572

On 7/8/2018 5:41 AM, Giampaolo Rodola' wrote: As for "assert" what I'm concern about is the proliferation of things like this:     class Foo:         def __init__(self):             assert self.x := fun1()             assert self.y := fun2()             assert self.z := fun3() When I look

Re: [Python-Dev] Call for prudence about PEP-572

On 7/8/2018 1:23 PM, Chris Angelico wrote: On Mon, Jul 9, 2018 at 3:14 AM, Giampaolo Rodola' wrote: On Sun, Jul 8, 2018 at 6:45 PM Steve Holden wrote: But the PEP 8 spellings are foo(x=1) and f(x := 1). The extra spacing makes it obvious that this isn't a regular named argume

Re: [Python-Dev] Call for prudence about PEP-572

On 7/8/2018 1:59 PM, Chris Angelico wrote: On Mon, Jul 9, 2018 at 3:55 AM, Eric V. Smith wrote: I agree with Chris in this case. That said, there is at least one place where the grammar does forbid you from doing something that would otherwise make be allowable: decorators. @lookup[0

Re: [Python-Dev] Time for 3.4.9 and 3.5.6

On 7/8/2018 8:35 PM, Terry Reedy wrote: On 7/8/2018 1:05 PM, Ivan Pozdeev via Python-Dev wrote: I'll use this opportunity to remind you that 3.4 build is broken -- it can't be built from start to installer with the instructions given because of outside factors (CPython has migrated from Hg to G

Re: [Python-Dev] Finding Guido's replacement

On 7/24/2018 4:32 PM, Gregory P. Smith wrote: On Tue, Jul 24, 2018 at 12:27 PM Abdur-Rahmaan Janhangeer mailto:arj.pyt...@gmail.com>> wrote: not googler i mean google. they requested a change to a pep "They"?  nah.  "Google LLC" did not request anything. People who happen to be working f

Re: [Python-Dev] Python 2.7 EOL date

On 8/23/2018 4:30 PM, Victor Stinner wrote: Hi, The reference is the PEP 373 "Python 2.7 Release Schedule". See the "Update" section: https://www.python.org/dev/peps/pep-0373/#update We could probably make it more clear in this section and/or in https://www.python.org/dev/peps/pep-0373/#id4 t

Re: [Python-Dev] Python 2.7 EOL date

On 8/23/2018 8:14 PM, Barry Warsaw wrote: On Aug 23, 2018, at 15:23, Eric V. Smith wrote: On 8/23/2018 4:30 PM, Victor Stinner wrote: Hi, The reference is the PEP 373 "Python 2.7 Release Schedule". See the "Update" section: https://www.python.org/dev/peps/pep-0373/#update

Re: [Python-Dev] Schedule of the Python 3.7.1 release?

On 9/5/2018 6:22 AM, Christian Heimes wrote: On 2018-09-05 11:56, Victor Stinner wrote: Hi, Someone asked somewhere (oops, I forgot where!) when is Python 3.7.1 scheduled. I wanted to reply when I saw that it was scheduled for 2 months ago: "3.7.1: 2018-07-xx" https://www.python.org/dev/peps/p

Re: [Python-Dev] bpo-34595: How to format a type name?

On 9/12/2018 8:33 PM, Victor Stinner wrote: Hi, For the type name, sometimes, we only get a type (not an instance), and we want to format its FQN. IMHO we need to provide ways to format the FQN of a type for *types* and for *instances*. Here is my proposal: * Add !t conversion to format string

Re: [Python-Dev] bpo-34595: How to format a type name?

On 9/13/2018 5:52 PM, Petr Viktorin wrote: On 09/13/18 14:08, Victor Stinner wrote: Le jeu. 13 sept. 2018 à 16:01, Eric V. Smith a écrit : * Add !t conversion to format string I'm strongly opposed to this. This !t conversion would not be widely applicable enough to be generally useful

Re: [Python-Dev] bpo-34595: How to format a type name?

On 9/13/2018 8:04 PM, Victor Stinner wrote: Le ven. 14 sept. 2018 à 00:09, Eric V. Smith a écrit : f'{type(obj)}' becomes type(obj).__format__(''), so you can return something other than __str__ or __repr__ does. It's only by convention that an object's __format_

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

On 9/19/2018 9:25 PM, Barry Warsaw wrote: On Sep 19, 2018, at 20:34, Gregory P. Smith wrote: There's ongoing work to rewrite zipimport.c in python using zipfile itself Great timing! Serhiy’s rewrite of zipimport in Python has just landed in 3.8, although it doesn’t use zipfile. What’s in

Re: [Python-Dev] Postponed annotations break inspection of dataclasses

On 9/22/2018 12:41 PM, Guido van Rossum wrote: This is a good catch -- thanks for bringing it up. I'm adding Eric Smith (author of dataclasses) and Ivan Levkivskyi (co-author of typing) as well as Łukasz Langa (author of PEP 563) to the thread to see if they have further insights. I don't see

Re: [Python-Dev] Postponed annotations break inspection of dataclasses

Yes, it’s https://bugs.python.org/issue34776 -- Eric > On Sep 27, 2018, at 12:05 PM, Ivan Levkivskyi wrote: > > Do we have a b.p.o. issue about this? If no, then I would recommend to open > one, so that we will not loose track of this. > > -- > Ivan > > > >> On Sat, 22 Sep 2018 at 16:32, D

Re: [Python-Dev] [Python-checkins] bpo-34203: FAQ now recommends python 3.x over 2.x (GH-9796)

On 10/12/2018 5:17 AM, Tal Einat wrote: The latest stable releases can always be found on the `Python download page -`_. There are two recommended production-ready -versions at this point in time, because at the moment there are two branches of -stable rele

Re: [Python-Dev] [Python-checkins] bpo-34203: FAQ now recommends python 3.x over 2.x (GH-9796)

> On Oct 12, 2018, at 7:03 PM, Martin Panter wrote: > >> On 12/10/2018, Eric V. Smith wrote: >>> On 10/12/2018 5:17 AM, Tal Einat wrote: >>> >>> The latest stable releases can always be found on the `Python download page >>> -<https://www.p

Re: [Python-Dev] C API changes

On 11/26/2018 7:08 PM, Larry Hastings wrote: On 11/23/18 5:15 AM, Armin Rigo wrote: Also FWIW, my own 2 cents on the topic of changing the C API: let's entirely drop ``PyObject *`` and instead use more opaque handles---like a ``PyHandle`` that is defined as a pointer-sized C type but is not actu

Re: [Python-Dev] Add more SyntaxWarnings?

On 1/24/2019 6:16 PM, Eric V. Smith wrote: On 1/24/2019 5:52 PM, Chris Angelico wrote: +1. If it's something that the peephole optimizer is already allowed to change (eg "1"+"1" is constant-folded) and there is absolutely no way that it can ever be changed at run time

Re: [Python-Dev] Add more SyntaxWarnings?

On 1/24/2019 5:52 PM, Chris Angelico wrote: On Fri, Jan 25, 2019 at 9:42 AM Steven D'Aprano wrote: We could say that implementations are allowed to raise errors at compile time instead of run time, but aren't required to. Then it becomes a matter of "quality of implementation". For literal int

Re: [Python-Dev] configparser: should optionxform be idempotent?

> On Mar 8, 2019, at 12:12 AM, Steven D'Aprano wrote: > >> On Fri, Mar 08, 2019 at 12:56:13PM +1300, Greg Ewing wrote: >> >> In any case, the word is easy enough to avoid in this case. > > I don't think we should avoid using standard terminology even if we can. > Knowledge of standard termino

[Python-Dev] Unicode identifiers in test files?

Is there a policy against using Unicode identifiers in test files? As part of adding !d to f-strings, there's a code path that's only executed if the text of the expression is non-ascii. The easiest way to exercise it, and the way I found a bug, is by using an identifier with Unicode chars. I

Re: [Python-Dev] Unicode identifiers in test files?

On 5/4/19 2:48 AM, Serhiy Storchaka wrote: 04.05.19 05:46, Eric V. Smith пише: Is there a policy against using Unicode identifiers in test files? As part of adding !d to f-strings, there's a code path that's only executed if the text of the expression is non-ascii. The easiest way t

Re: [Python-Dev] Unicode identifiers in test files?

On 5/4/19 3:54 AM, Eric V. Smith wrote: On 5/4/19 2:48 AM, Serhiy Storchaka wrote: 04.05.19 05:46, Eric V. Smith пише: Is there a policy against using Unicode identifiers in test files? As part of adding !d to f-strings, there's a code path that's only executed if the text of the

[Python-Dev] Easier debugging with f-strings

Last fall Larry Hastings made a suggestion for adding a way to make so-called "print-based debugging" easier with f-strings. Basically the approach is that f-strings would be able to produce the text of the expression and the value of that expression, without repeating the expression in the f-s

Re: [Python-Dev] Easier debugging with f-strings

On 5/7/19 9:49 AM, Barry Warsaw wrote: On May 7, 2019, at 03:52, Steve Holden wrote: What's not to like? My only complaint is that you steadfastly refuse use Guido’s time machine keys to make this available in 3.7. Open a feature request here: https://github.com/asottile/future-fstrings

Re: [Python-Dev] Easier debugging with f-strings

Hi, Tim. Your name came up frequently as a target for this use case. I think we’ve come up with a pretty good solution. Now if I could only convince my clients to upgrade from 2.7! I’ve heard about these f-string things, and I think I would enjoy using them. Eric > On May 7, 2019, at 12:50

Re: [Python-Dev] Easier debugging with f-strings

ready discussed. Yeah, it's all over the place. At this stage, I think discussing it here is best. On Mon, May 06, 2019 at 08:39:41PM -0400, Eric V. Smith wrote: After that lightning talk, Larry and I talked about it some more, and for a number of reasons decided that it would make more

Re: [Python-Dev] Redoing failed PR checks

I think you can close and reopen the PR. That’s what I’m trying on my blocked PR. -- Eric V. Smith True Blade Systems, Inc (301) 859-4544 > On May 8, 2019, at 10:07 AM, Mark Shannon wrote: > > Hi, > > How do I redo a failed PR check? > The appveyor failure for https:/

[Python-Dev] ast changes for "debug" f-strings

I added an optional "expr_text" field to the FormattedValue node, which represents the text of the expression in a "debug" f-string expression. So in f'{x=}', expr_text would be "x=". This strictly speaking isn't necessary. I could have added another Constant node for "x=" and left FormattedVa

Re: [Python-Dev] ast changes for "debug" f-strings

On 5/20/2019 10:32 AM, Batuhan Taskaya wrote: > This strictly speaking isn't necessary. I could have added another Constant node for "x=" and left FormattedValue alone. I didn't for three reasons: it was expedient; it didn't require a lot of surgery to f-string parsing, which the extra Constant

Re: [Python-Dev] Python in next Windows 10 update

That’s great, Steve. Thanks for all of the work (by you and others) on this. -- Eric V. Smith True Blade Systems, Inc (301) 859-4544 > On May 21, 2019, at 4:30 PM, Steve Dower wrote: > > Hi all > > Just sharing this here because I think it's important for us to be awar

[Python-Dev] Re: Replacing 4 underscores with a $ sign, idea for a PEP

You’ll have to manually re-send it. -- Eric V. Smith (301) 502-0945 cell > On Jul 21, 2019, at 11:23 AM, ka...@beholdingeye.com wrote: > > Sorry for posting to the wrong list! If this could be moved I'd appreciate it. > ___ > Pyt

[Python-Dev] Re: Comparing dict.values()

On 7/24/2019 1:30 PM, Brett Cannon wrote: Serhiy Storchaka wrote: o you propose? What is the use case for it? If you want to compare dict value views as ordered sequences, it can be surprised that d1.values() != d2.values() when d1 == d2. It will be inconsistent with orderless comparison of key

[Python-Dev] Re: Comparing dict.values()

On 7/25/2019 4:27 AM, Kyle Stanley wrote: Serhiy Storchaka wrote: Is there any precedence of raising an exception in the equality comparison? Does 3 == "3" returning False make more sense to you? Personally, I don't find ``3 == "3"`` to be an equivalent comparison to ``d0.values() == d1.va

[Python-Dev] Re: Comparing dict.values()

7/25/2019 6:00 AM, Eric V. Smith wrote: On 7/25/2019 4:27 AM, Kyle Stanley wrote: Serhiy Storchaka wrote: Is there any precedence of raising an exception in the equality comparison? Does 3 == "3" returning False make more sense to you? Personally, I don't find ``3 ==

[Python-Dev] Re: Comparing dict.values()

On 7/25/2019 4:19 PM, Kyle Stanley wrote: Serhiy Storchaka wrote: Actually, the == operator cannot return NotImplemented. Thanks for the clarification. What is the reason for this limitation and is it only possible for the `==` operator to return one of `None`, `False`, or `True`? It seems

[Python-Dev] Re: Comparing dict.values()

On 7/26/2019 8:24 AM, Greg Ewing wrote: Steven D'Aprano wrote: But the basic semantics hasn't really changed: two (multi)sets of values are equal if they have the same individual values, regardless of order. Why regardless of order? Dicts have an ordering nowadays. Why shouldn't that ordering

[Python-Dev] Re: What to do about invalid escape sequences

On 8/5/2019 4:30 PM, raymond.hettin...@gmail.com wrote: Thanks for weighing in. I think this is an important usability discussion. IMO it is the number one issue affecting the end user experience with this release. If we could get more people to actively use the beta release, the issue wo

[Python-Dev] Re: os.scandir bug in Windows?

On 10/18/2020 12:25 PM, Rob Cliffe via Python-Dev wrote: How do I do that, please?  I can't see an obvious create option on that web page.  Do I need to log in? Yes, you need to log in before you can open an issue. You might need to create an account first if you don't have one: it's called "R

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On 11/2/2020 9:31 AM, Thomas Wouters wrote: On Sat, Oct 31, 2020 at 12:25 PM Steven D'Aprano > wrote: I really don't get why so many people are hung up over this minuscule issue of giving `_` special meaning inside match statements. IMO, consistency wi

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

On 11/23/2020 5:44 PM, David Mertz wrote: I'd put the question this way: assuming Matcher can be written (with a bit of stack magic), and assuming that the strings inside m.case() calls are exactly the same mini-languague PEP 634 proposes, would you want a syntax change? N

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

On 11/23/2020 3:44 PM, David Mertz wrote: I have a little bit of skepticism about the pattern matching syntax, for similar reasons to those Larry expresses, and that Steve Dower mentioned on Discourse. Basically, I agree matching/destructuring is a powerful idea.  But I also wonder how much

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

On 11/23/2020 4:49 PM, David Mertz wrote: On Mon, Nov 23, 2020, 4:32 PM Eric V. Smith I just commented on Steve's post over on Discourse. The problem with this is that the called function (m.case, here) needs to have access to the caller's namespace in order to r

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 1/11/2021 1:10 PM, Larry Hastings wrote: Certainly.  I'm just another victim in the copy-and-paste wars. I actually have write access to the PEPs repo (I'm a former release manager) so I'd be happy to check it in myself once it gets a number, however that happens.  Before I do so I'll stu

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

On 2/10/2021 10:29 AM, Paul Moore wrote: On Wed, 10 Feb 2021 at 14:33, Anders Munch wrote: The idea is to make is so that working code only needs to change once, even when supporting multiple Python versions. That one change is to add either an explicit encoding=None (for backwards-compatibi

[Python-Dev] Re: Merge Request Review Reminder

thon.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LPCY3R4WINI5XCMWGPDA3EI52HMCPJTS/ Code of Conduct: http://python.org/p

[Python-Dev] Re: NamedTemporaryFile and context managers

On 4/8/2021 4:43 PM, Antoine Pitrou wrote: On Thu, 8 Apr 2021 13:31:26 -0700 Ethan Furman wrote: ```python from tempfile import NamedTemporaryFile with NamedTemporaryFile() as fp: fp.write(b'some data') fp.close() # Windows workaround fp.open() data = fp.read() assert

<    1   2   3   4   5   6   >