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

On Thu, Mar 27, 2014 at 3:47 AM, Victor Stinner wrote: > The PEP 461 looks good to me. It's a nice addition to Python 3.5 and > the PEP is well defined. > +1 > I can help to implement it. Maybe, it would be nice to provide an > implementation as a third-party party module on PyPI for Python > 2

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] Windows installers and OpenSSL

Yep. All binary Python distributions that bundle SSL support need updating. But... what MRAB said. We also *likely* have SSL certificates and SSH host keys on python.orginfrastructure that need to be revoked and new certs reissued *after* all of those machines have been patched and their services

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

On Mon, May 5, 2014 at 2:52 PM, Anthony Tuininga wrote: > On Mon, May 5, 2014 at 3:50 PM, Paul Moore wrote: > >> On 5 May 2014 22:32, Anthony Tuininga wrote: >> > So my question is: can I safely make use of this "feature"? It has >> remained >> > in place since at least Python 2.6 but I don't w

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] Raspberry Pi Buildbot

On Fri, Jun 13, 2014 at 3:24 AM, Tal Einat wrote: > Is there one? If not, would you like me to set one up? I've got one at > home with Raspbian installed not doing anything, it could easily run a > buildslave. > > Poking around on buildbot.python.org/all/builders, I can only see one > ARM buildbo

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] Question about PEP 484

On Mon, Jul 16, 2018 at 1:44 PM Guido van Rossum wrote: > As one of the authors of PEP 484, *I* never thought there was an ambiguity > here. The intention was for stub files to conform to the same grammar as > regular .py files, but with a different interpretation. > > > "Have the same syntax as

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

On Tue, Jul 24, 2018 at 12:27 PM Abdur-Rahmaan Janhangeer < 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 for Google on a Google owned project asked a question see

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

Re: [Python-Dev] USE_STACKCHECK and running out of stack

On Sat, Jul 28, 2018 at 7:51 AM Ronald Oussoren via Python-Dev < python-dev@python.org> wrote: > Hi, > > I’m looking at PyOS_CheckStack because this feature might be useful on > macOS (and when I created bpo-33955 for this someone ran with it and > created a patch). > > Does anyone remember why th

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] AES decryption/encryption support for zipfile

On Wed, Sep 5, 2018 at 8:24 AM 大野隆弘 wrote: > Sorry, allow me to ask one more thing. > If I want to use AES in zipfile module, what the good way to implement? > If anyone wants to add support for additional zipfile encryption/decryption methods, there are a few options: (a) Fork the stdlib zipfi

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 Sat, Sep 15, 2018 at 2:53 AM Paul Moore wrote: > On Fri, 14 Sep 2018 at 23:28, Neil Schemenauer > wrote: > > > > On 2018-09-14, Larry Hastings wrote: > > > [..] adding the stat calls back in costs you half the startup. So > > > any mechanism where we're talking to the disk _at all_ simply >

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

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

Re: [Python-Dev] Questions about signal handling.

On Mon, Sep 24, 2018 at 1:20 PM Eric Snow wrote: > On Mon, Sep 24, 2018 at 11:14 AM Yury Selivanov > wrote: > > On Fri, Sep 21, 2018 at 7:04 PM Eric Snow > wrote: > > > 1. Why do we restrict calls to signal.signal() to the main thread? > > > 2. Why must signal handlers run in the main thread? >

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] Use of objdump within ctypes _get_soname()

On Mon, Oct 8, 2018 at 11:59 PM Ray Donnelly wrote: > Hi, > > We ran into an issue on the Anaconda Distribution recently where we > added libarchive-c to conda-build (so we can un-compress more source > archive formats than tarfile supports) and everything was good a few > hours, until it hit var

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] "Deprecation" of os.system in favor of subprocess?

The os module is by definition special. It exposes libc and platform APIs. That there are Python modules that provide similar functionality, often surpassing it and sometimes being built on top of it, is intentional. Random quotes from the Zen don't win arguments. Although practicality beats pu

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

On Fri, Nov 9, 2018 at 5:50 PM Nathaniel Smith wrote: > On Fri, Nov 9, 2018 at 4:30 PM, Victor Stinner > wrote: > > Ah, important points. I don't want to touch the current C API nor make > > it less efficient. And compatibility in both directions (current C API >

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

On Sun, Nov 11, 2018 at 3:19 PM Victor Stinner wrote: > Le sam. 10 nov. 2018 à 04:02, Nathaniel Smith a écrit : > > So is it fair to say that your plan is that CPython will always use > > the current ("old") API internally, and the "new" API will be > >

Re: [Python-Dev] General concerns about C API changes

On Tue, Nov 13, 2018 at 7:06 PM Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > Overall, I support the efforts to improve the C API, but over the last few > weeks have become worried. I don't want to hold up progress with fear, > uncertainty, and doubt. Yet, I would like to be more com

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

> > It seems like the discussion so far is: > > Victor: "I know people when people hear 'new API' they get scared and > think we're going to do a Python-3-like breaking transition, but don't > worry, we're never going to do that." > Nathaniel: "But then what does the new API add?" > Greg: "It lets

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] C API changes

On Mon, Nov 26, 2018 at 4:10 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 >

Re: [Python-Dev] Inclusion of lz4 bindings in stdlib?

On Wed, Nov 28, 2018 at 9:52 AM Brett Cannon wrote: > Are we getting to the point that we want a compresslib like hashlib if we > are going to be adding more compression algorithms? > Lets avoid the lib suffix when unnecessary. I used the name hashlib because the name hash was already taken by

Re: [Python-Dev] Inclusion of lz4 bindings in stdlib?

On Wed, Nov 28, 2018 at 10:43 AM Gregory P. Smith wrote: > > On Wed, Nov 28, 2018 at 9:52 AM Brett Cannon wrote: > >> Are we getting to the point that we want a compresslib like hashlib if we >> are going to be adding more compression algorithms? >> > &g

Re: [Python-Dev] Standard library vs Standard distribution?

meta: I'm not participating in this sub-thread. Just changing the subject line. On Thu, Nov 29, 2018 at 9:17 AM Christian Heimes wrote: > On 29/11/2018 17.32, Antoine Pitrou wrote: > > We may ask ourselves if there is really a large difference between a > > "standard distribution" and a "standar

Re: [Python-Dev] Inclusion of lz4 bindings in stdlib?

2018 at 12:04 PM INADA Naoki > wrote: > >> On Thu, Nov 29, 2018 at 6:27 AM Steven D'Aprano >> wrote: >> > >> > On Wed, Nov 28, 2018 at 10:43:04AM -0800, Gregory P. Smith wrote: >> > >> > > PyPI makes getting more algorithms easy. &

Re: [Python-Dev] ctypes: is it intentional that id() is the only way to get the address of an object?

I've heard that libraries using ctypes, cffi, or cython code of various sorts in the real world wild today does abuse the unfortunate side effect of CPython's implementation of id(). I don't have specific instances of this in mind but trust what I've heard: that it is happening. id() should never

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] Sub-interpreters: importing numpy causes hang

On Thu, Jan 24, 2019 at 1:25 PM Chris Barker - NOAA Federal via Python-Dev < python-dev@python.org> wrote: > If your primary concern is module clashes between plugins, maybe you > can hack around that: > > 1) if the plugins are providing copies of any other modules, then you > can simply require t

Re: [Python-Dev] How to update namedtuple asdict() to use dict instead of OrderedDict

On Wed, Jan 30, 2019 at 2:32 PM Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > Now that regular dicts are ordered and compact, it makes more sense for > the _asdict() method to create a regular dict (as it did in its early days) > rather than an OrderedDict. The regular dict is much sm

Re: [Python-Dev] Is distutils.util.get_platform() the "current" or the "target" platform

On Thu, Feb 14, 2019 at 11:38 AM Steve Dower wrote: > As part of adding ARM32 support for Windows, we need to enable > cross-compilation in distutils. This is easy enough, though it requires > somehow getting the target platform as well as the current platform. > > Right now, the change at https:

Re: [Python-Dev] Is distutils.util.get_platform() the "current" or the "target" platform

On Fri, Feb 15, 2019 at 2:02 PM Steve Dower wrote: > On 14Feb2019 1147, Gregory P. Smith wrote: > > To alleviate confusion long term I'd love it if we could deprecate the > > unqualified get_platform() API and point people towards always being > > explicit abou

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On Thu, Feb 14, 2019 at 9:29 AM Barry Warsaw wrote: > On Feb 13, 2019, at 23:08, Matěj Cepl wrote: > > > Is this relevant to the discussion at hand? We are talking about > > the binary /usr/bin/python3 which will be surely be provided > > even by Python 4, won't it? > > Why would it be? Since t

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On Mon, Feb 18, 2019, 7:34 AM Matthias Klose On 16.02.19 00:15, Gregory P. Smith wrote: > > On Thu, Feb 14, 2019 at 9:29 AM Barry Warsaw wrote: > > > >> On Feb 13, 2019, at 23:08, Matěj Cepl wrote: > >> > >>> Is this relevant to the discussion at hand?

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On Tue, Feb 26, 2019 at 8:59 AM INADA Naoki wrote: > > > > With *Homebrew*, `python` points to Homebrew’s Python 2.7.x (if > > installed) otherwise the macOS system Python. That's exactly according > > to the PEP. They tried to switch python to python3 before, and got > > rather nasty backlash ci

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On Tue, Feb 26, 2019 at 9:55 AM Barry Warsaw wrote: > > There haven't been many new ideas since this summary – mostly it was > explaining and re-hashing what's been mentioned before. > > Thanks for the summary Petr. > > Here’s another way to think about the problem. I know Nick and I have > talk

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On Tue, Feb 26, 2019 at 2:28 PM Victor Stinner wrote: > Le mar. 26 févr. 2019 à 22:24, Gregory P. Smith a écrit > : > > A feature that I find missing from posix-y OSes that support #! lines is > an ability to restrict what can use a given interpreter. > > Fedora runs sys

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On Tue, Feb 26, 2019 at 2:31 PM Steve Dower wrote: > On 2/26/2019 1:20 PM, Gregory P. Smith wrote: > > For an OS distro provided interpreter, being able to restrict its use to > > only OS distro provided software would be ideal (so ideal that people > > who haven'

Re: [Python-Dev] Compile-time resolution of packages [Was: Another update for PEP 394...]

On Wed, Feb 27, 2019 at 5:12 PM Toshio Kuratomi wrote: > > On Tue, Feb 26, 2019 at 2:07 PM Neil Schemenauer > wrote: > >> On 2019-02-26, Gregory P. Smith wrote: >> > On Tue, Feb 26, 2019 at 9:55 AM Barry Warsaw wrote: >> > For an OS distro provided interpr

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

On Thu, Mar 7, 2019 at 2:12 PM Mariatta wrote: > > On Thu, Mar 7, 2019 at 12:35 PM Matthew Woodcraft > wrote: > >> >> One part of this PEP stands out to me: >> >> | We should not be moving all open issues to GitHub. Issues with little >> | or no activity should just be closed. Issues with no dec

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

Re: [Python-Dev] (Licensing question) backport of shutil.copyfile() functionality

Things in the standard library are already covered by the PSF license so that is what should be kept on backports from the stdlib to earlier versions. I do recommend keeping your backported stuff and new functionality separate (separate packages ideally, but that'll depend on how intertwined thing

Re: [Python-Dev] (Licensing question) backport of shutil.copyfile() functionality

On Tue, Mar 12, 2019 at 2:55 PM Giampaolo Rodola' wrote: > > > On Tue, Mar 12, 2019 at 3:01 AM Glenn Linderman > wrote: > >> On 3/11/2019 4:35 PM, Giampaolo Rodola' wrote: >> >> Hello, >> some time ago I contributed a couple of patches to speedup shutil.copy*() >> functions: >> https://bugs.pyth

Re: [Python-Dev] Is XML serialization output guaranteed to be bytewise identical forever?

On Mon, Mar 18, 2019 at 9:44 PM Terry Reedy wrote: > On 3/18/2019 6:41 PM, Raymond Hettinger wrote: > > We're having a super interesting discussion on > https://bugs.python.org/issue34160 . It is now marked as a release > blocker and warrants a broader discussion. > > > > Our problem is that at

Re: [Python-Dev] Is XML serialization output guaranteed to be bytewise identical forever?

On Tue, Mar 19, 2019, 4:53 AM Ned Batchelder wrote: > On 3/19/19 4:13 AM, Serhiy Storchaka wrote: > > 19.03.19 00:41, Raymond Hettinger пише: > >> 4) Fix the tests in the third-party modules to be more focused on > >> their actual test objectives, the semantics of the generated XML > >> rather th

Re: [Python-Dev] Best way to specify docstrings for member objects

(answers above and below the quoting) I like the idea of documenting attributes, but we shouldn't force the user to use __slots__ as that has significant side effects and is rarely something people should bother to use. There are multiple types of attributes. class and instance. but regardless

[Python-Dev] PEP 556 threaded garbage collection & linear recursion in gc

https://www.python.org/dev/peps/pep-0556/ This PEP is currently Deferred as nobody is actively working on a test implementation. A situation came up the other day where I *believe* this could've helped. Scenario (admittedly not one most environments run into): A Python process with a C++ extensi

Re: [Python-Dev] PEP 556 threaded garbage collection & linear recursion in gc

ual next time I hear of such a report. -G On Wed, Mar 27, 2019, 5:38 PM Tim Peters wrote: > [Gregory P. Smith ] > > ... > > A situation came up the other day where I believe this could've helped. > > > > Scenario (admittedly not one most environments run into)

Re: [Python-Dev] Strange umask(?)/st_mode issue

I wouldn't expect it to be the case in a CI environment but I believe a umask can be overridden if the filesystem is mounted and configured with acls set? (oh, hah, Ivan just said the same thing) -gps On Sat, Mar 30, 2019 at 9:05 AM Steve Dower wrote: > On 29Mar.2019 1944, Steve Dower wrote: >

Re: [Python-Dev] Strange umask(?)/st_mode issue

On Mon, Apr 1, 2019 at 4:49 PM Cameron Simpson wrote: > On 01Apr2019 15:44, Steve Dower wrote: > >On 01Apr2019 1535, Cameron Simpson wrote: > >>On 01Apr2019 09:12, Steve Dower wrote: > >>>On 30Mar2019 1130, Gregory P. Smith wrote: > >>>>I wouldn&#

Re: [Python-Dev] Need help to fix HTTP Header Injection vulnerability

On Tue, Apr 9, 2019 at 4:45 PM Karthikeyan wrote: > I would recommend fixing it since it's potentially remote code execution > on systems like Redis (latest versions of Redis have this mitigated) though > I must admit I don't fully understand the complexity since there are > multiple issues linke

Re: [Python-Dev] Need help to fix HTTP Header Injection vulnerability

On Wed, Apr 10, 2019 at 11:00 AM Ivan Pozdeev via Python-Dev < python-dev@python.org> wrote: > > On 10.04.2019 7:30, Karthikeyan wrote: > > Thanks Gregory. I think it's a good tradeoff to ensure this validation > only for URLs of http scheme. > > I also agree handling newline is little problematic

[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 Fri, May 3, 2019 at 10:46 PM Eric V. Smith wrote: > 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 > e

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:/

Re: [Python-Dev] bpo-36829: Add sys.unraisablehook()

I like the feature, we should have it. It'll be useful for debugging and probably more. Which brings me to the annoying paint color question: These exceptions were most definitely raised. Thus the term "unraisable" is wrong. I believe you really mean "uncatchable". -gps On Thu, May 16, 2019 at

[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

Re: [Python-Dev] Have a big machine and spare time? Here's a possible Python bug.

I suggest filing a bug to track this... On Thu, May 23, 2019 at 10:13 AM Tim Peters wrote: > [Inada Naoki ] > > ... > > 2. This loop is cleary hot: > > > https://github.com/python/cpython/blob/51aa35e9e17eef60d04add9619fe2a7eb938358c/Objects/obmalloc.c#L1816-L1819 > > Which is 3 lines of code pl

Re: [Python-Dev] [python-committers] PEP 595: Improving bugs.python.org

-cc: committers to avoid crossposting. I have feedback for roundup as experienced on BPO that should be represented within PEP 595 if we are going to have a summary of "improving roundup for BPO" captured in a PEP (presumably already rejected given 581? But good to have documented regardless so _t

Re: [Python-Dev] [python-committers] PEP 595: Improving bugs.python.org

On Fri, May 24, 2019 at 1:48 PM Ezio Melotti wrote: > > On Fri, May 24, 2019, 20:23 Gregory P. Smith wrote: > >> -cc: committers to avoid crossposting. >> > > +1 (I wanted to include committers, since the announcement about PEP 581 > was posted there too, but it&#

[Python-Dev] Re: python-ideas and python-dev migrated to Mailman 3/HyperKitty

On Thu, Jun 6, 2019 at 6:19 AM Victor Stinner wrote: > Le jeu. 6 juin 2019 à 14:18, Steven D'Aprano a > écrit : > > i.e. 25-40% longer. Is there a shorter permalink form available, like > > goo.gl, bitly, youtu.be etc use? That would be awesome if we could use > > them instead. > > I really disl

[Python-Dev] Re: PEP 581 has been updated with "Downsides of GitHub" section

On Mon, Jul 1, 2019 at 9:01 AM Steven D'Aprano wrote: > On Sat, Jun 29, 2019 at 10:26:04AM -0500, Skip Montanaro wrote: > > > You have missed at least one: the minimum technology requirement for > > > using Github is a lot more stringent than for Roundup. Github's minimum > > > system requirement

[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

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