Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

On Wed, Jul 04, 2018 at 03:36:18PM +0300, Ivan Pozdeev via Python-Dev wrote: > On 04.07.2018 15:29, Victor Stinner wrote: > >The PEP 572 has been approved, it's no longer worth it to discuss it ;-) > > > >Victor > > As of now, https://www.python.org/dev/peps/pep-0572/ is marked as "draft". https:

Re: [Python-Dev] Examples for PEP 572

On Wed, Jul 04, 2018 at 10:13:15AM -0700, Devin Jeanpierre wrote: > > > In Python it'd look like this: > > > > > > if x = expr(); x < 0: > > > do_stuff() [...] > > Python's parser is restricted to LL(1) by design, so treating semicolons > > in "if" statements as a special case might not even be

Re: [Python-Dev] Examples for PEP 572

On Wed, Jul 04, 2018 at 08:33:17PM +0300, Ivan Pozdeev via Python-Dev wrote: > >>while total != (total := total + term): > >>    term *= mx2 / (i*(i+1)) > >>    i += 2 > >>return total [...] > It took me a few minutes to figure out that this construct actually > checks term == 0. That's badly

Re: [Python-Dev] Examples for PEP 572

On Wed, Jul 04, 2018 at 08:32:32PM +0200, Sven R. Kunze wrote: > >>while total != (total := total + term): > >>    term *= mx2 / (i*(i+1)) > >>    i += 2 > >>return total > > This very example here caught my eye. > > Isn't total not always equal to total? What would "regular" Python have > look

Re: [Python-Dev] Examples for PEP 572

On Wed, Jul 04, 2018 at 03:24:08PM -0400, Terry Reedy wrote: > On 7/4/2018 9:35 AM, Steven D'Aprano wrote: > >On Wed, Jul 04, 2018 at 05:02:07PM +1000, Chris Angelico wrote: > >>On Wed, Jul 4, 2018 at 4:07 PM, Serhiy Storchaka > >>wrote: > > > >>&q

Re: [Python-Dev] PEP 572, VF/B, and "Shark Jumping"

On Wed, Jul 04, 2018 at 04:52:54PM -0700, Mike Miller wrote: > Additionally, I have noticed a dichotomy between prolific "C programmers" > who've supported this PEP and many Python programmers who don't want it. Prolific C programmers like me, hey? *shakes head in a combination of amusement a

Re: [Python-Dev] Examples for PEP 572

On Wed, Jul 04, 2018 at 01:00:41PM -0700, Devin Jeanpierre wrote: > On Wed, Jul 4, 2018 at 11:04 AM Steven D'Aprano wrote: > > Did you actually mean arbitrary simple statements? > > > > if import math; mylist.sort(); print("WTF am I reading?"); True: > >

Re: [Python-Dev] PEP 572, VF/B, and "Shark Jumping"

On Thu, Jul 05, 2018 at 05:33:50AM +0300, Ivan Pozdeev via Python-Dev wrote: > And https://mail.python.org/pipermail/python-dev/2018-June/154160.html > disproves the "chosen often these days in new languages". Ivan, I think you may have linked to the wrong page. That page was Chris kindly refer

Re: [Python-Dev] Assignment expression and coding style: the while True case

On Thu, Jul 05, 2018 at 12:51:37AM +0200, Victor Stinner wrote: > I propose to start the discussion about "coding style" (where are > assignment expressions appropriate or not?) with the "while True" > case. We don't even have an official implementation yet, and you already want to start prescri

Re: [Python-Dev] PEP 572, VF/B, and "Shark Jumping"

On Thu, Jul 05, 2018 at 08:52:24PM +0300, Ivan Pozdeev via Python-Dev wrote: > * Same goes for `except`: doesn't accept expressions, same semantic. py> def make_exception(arg): ... return ValueError if arg else TypeError ... py> expr = [make_exception] py> try: ... 1+"1" ... except expr[

Re: [Python-Dev] PEP 572: Do we really need a ":" in ":="?

On Thu, Jul 05, 2018 at 09:00:39PM -0400, Alexander Belopolsky wrote: > Do we want to protect users who > cannot tell = from == so much that we are willing to cause Python to be > the first language with two non-interchangeable assignment operators? Not even close to the first. Go beat us to it

Re: [Python-Dev] Symmetric vs asymmetric symbols (was PEP 572: Do we really need a ":" in ":="?)

On Sat, Jul 07, 2018 at 01:03:06PM +1200, Greg Ewing wrote: > Ivan Pozdeev via Python-Dev wrote: > >(while "<>" reads "less or greater" which is mathematically not > >equivalent to that: not everything has a defined ordering relation. > > I think this is a silly argument against "<>". While I ag

Re: [Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

On Sat, Jul 07, 2018 at 02:58:23AM +0300, Ivan Pozdeev via Python-Dev wrote: > >Also, "generator builder" is not much more expressive than "generator > >expression", I agree with Guido on that comment. The only advantage (such little as it is) is that we can refer to them all using the same ter

Re: [Python-Dev] why is not 64-bit installer the default download link for Windows?

On Wed, Jul 11, 2018 at 05:14:34AM +0300, Ivan Pozdeev via Python-Dev wrote: > On 11.07.2018 1:41, Victor Stinner wrote: > >2018-07-09 18:01 GMT+02:00 Steve Dower : > >>The difficulty is that they *definitely* can use the 32-bit version, and > >>those few who are on older machines or older installs

Re: [Python-Dev] PEP 572 and assert

On Tue, Jul 17, 2018 at 07:24:12PM +0300, Serhiy Storchaka wrote: > 17.07.18 18:48, Guido van Rossum пише: > >On Tue, Jul 17, 2018 at 8:28 AM, Serhiy Storchaka >> wrote: > >Should not the assert statement introduce an implicit lexical scope > >for preventing lea

Re: [Python-Dev] PEP 572 and assert

On Wed, Jul 18, 2018 at 03:41:08AM +1000, Steven D'Aprano wrote: > Besides, there is a legitimate use for assignment expressions in > assertions: > > assert (spam := something) > 2, 'not enough spam' > assert sequence[foo] == 999, 'sequence item

Re: [Python-Dev] Issue?

On Wed, Aug 22, 2018 at 06:40:42PM +0800, 楼晓峰 wrote: > Why compare twice? This is not a mailing list for asking for help with your own code. You can try this list instead: https://mail.python.org/mailman/listinfo/python-list -- Steve ___ Python-De

Re: [Python-Dev] Python REPL doesn't work on Windows over remote powershell session (winrm)

On Sat, Aug 25, 2018 at 11:09:10PM +, ZHU Xiang wrote: > But for the remote Windows powershell session the REPL doesn’t work, > when I type ‘’python” on the remote session, there’s nothing happened. [...] > FYI, I’ve also opened a issue on Microsoft Powershell GitHub : > https://github.com/Po

Re: [Python-Dev] Official citation for Python

On Sun, Sep 09, 2018 at 03:43:13PM -0400, Jacqueline Kazil wrote: > The PSF has received a few inquiries asking the question — “How do I cite > Python?”So, I am reaching out to you all to figure this out. If you figure it out, it would be lovely to see some movement on this ticket: https://bugs.

Re: [Python-Dev] Official citation for Python

On Mon, Sep 10, 2018 at 09:25:29PM +0200, Chris Barker via Python-Dev wrote: > I"d like ot know what thee citations are expected to be used for? > > i.e. -- usually, academic papers have a collection of citiations to > acknowledge where you got an idea, or fact, or It serves both to > jusstif

Re: [Python-Dev] Official citation for Python

On Tue, Sep 11, 2018 at 11:16:08AM +0200, Chris Barker wrote: > On Tue, Sep 11, 2018 at 3:48 AM, Steven D'Aprano > wrote: > > > > That is about reproducible results, which is really a different thing > > than > > > the usual citations. > > >

Re: [Python-Dev] Official citation for Python

On Tue, Sep 11, 2018 at 10:35:04PM +0200, Chris Barker wrote: > On Tue, Sep 11, 2018 at 2:45 PM, Steven D'Aprano > wrote: > > > I think this thread is about *academic* citations. > > yes, I assumed that as well, what in any of my posts made you think > otherwise? W

Re: [Python-Dev] Change in Python 3's "round" behavior

On Wed, Sep 26, 2018 at 07:26:17AM -0400, j...@math.brown.edu wrote: > I did find the revealingly-invalid bug report > https://bugs.python.org/issue32956 ("python 3 round bug"), so I asked > there, but wanted to invite anyone else on this list who might be > interested to help. What about those

Re: [Python-Dev] Change in Python 3's "round" behavior

On Thu, Sep 27, 2018 at 05:55:07PM +1200, Greg Ewing wrote: > j...@math.brown.edu wrote: > >I understand from > >https://github.com/cosmologicon/pywat/pull/40#discussion_r219962259 > >that "to always round up... can theoretically skew the data" > > *Very* theoretically. If the number is even a whi

Re: [Python-Dev] switch statement

On Fri, Sep 21, 2018 at 02:10:00PM -0700, Guido van Rossum wrote: > There's already a rejected PEP about a switch statement: > https://www.python.org/dev/peps/pep-3103/. There's no point bringing this > up again unless you have a new use case. > > There have been several promising posts to python-

Re: [Python-Dev] Change in Python 3's "round" behavior

On Sat, Sep 29, 2018 at 09:40:03PM -0400, Alex Walters wrote: > ...and we have a stats module that would be a great place for a round > function that needs to cancel rounding errors. This has nothing to do with statistics. You should consider that this is often called "Banker's Rounding" and wh

Re: [Python-Dev] Change in Python 3's "round" behavior

On Mon, Oct 01, 2018 at 10:50:36AM +1300, Greg Ewing wrote: > Alex Walters wrote: > >Other use case is finance, where you can end up with interest calculations > >that are fractional of the base unit of currency. US$2.345 is impossible > >to > >represent in real currency, so it has to be rounded.

Re: [Python-Dev] dear core-devs

Hi Michael, and welcome, On Tue, Oct 02, 2018 at 12:41:56AM +0200, Michael Felt wrote: [...] > FYI: since the end of July I have dedicated 16 to 24 hours of my free > time to get this done. All for Python; all in my freetime. My employer > does not care - I do, or did. [...] > I am, to put it li

[Python-Dev] Should assert continue to do a LOAD_GLOBAL on AssertionError?

On the bug tracker, there's a discussion about the current behaviour of the assert statement, where shadowing AssertionError will change the behaviour of the assertion. https://bugs.python.org/issue34880 Currently, assert does a LOAD_GLOBAL on AssertionError, which means if you shadow the name

[Python-Dev] Arbitrary non-identifier string keys when using **kwargs

While keyword arguments have to be identifiers, using **kwargs allows arbitrary strings which aren't identifiers: py> def spam(**kwargs): ... print(kwargs) ... py> spam(**{"something arbitrary": 1, '\n': 2}) {'something arbitrary': 1, '\n': 2} There is some discussion on Python-Ideas on whe

Re: [Python-Dev] dear core-devs

On Thu, Oct 04, 2018 at 09:55:10AM +0200, Petr Viktorin wrote: > Is paying the best way to get features into Python? No, but it is *a* way to get features into Python. It may be a good way to get a feature that is important to (generic) you, but the core devs don't have enough time, interest or

Re: [Python-Dev] Arbitrary non-identifier string keys when using **kwargs

On Tue, Oct 09, 2018 at 09:37:48AM -0700, Jeff Hardy wrote: > > When this behavior of set/getattr was discussed a decade or so ago, > > Guido said not to disable it, but I believe he said it should not be > > considered a language feature. There are other situations where CPython > > is 'looser'

Re: [Python-Dev] Arbitrary non-identifier string keys when using **kwargs

On Tue, Oct 09, 2018 at 10:26:50AM -0700, Guido van Rossum wrote: > My feeling is that limiting it to strings is fine, but checking those > strings for resembling identifiers is pointless and wasteful. Sure. The question is, do we have to support uses where people intentionally smuggle non-identi

Re: [Python-Dev] Arbitrary non-identifier string keys when using **kwargs

On Thu, Oct 11, 2018 at 01:27:08PM -0400, Chris Barker - NOAA Federal via Python-Dev wrote: > > On the server side, the application could be doing something like > > assuming that the kwargs are e.g. column names > > This is exactly a use-case for non-identifier strings in kwargs. Why not just p

Re: [Python-Dev] "Deprecation" of os.system in favor of subprocess?

On Wed, Oct 24, 2018 at 09:34:34AM -0400, Calvin Spealman wrote: > Simply put, there is no valid use case for os.system over subprocess That is simply not true. That's your opinion, masquerading as a fact, and made in the face of Steve Dower's description of at least one appropriate use of os.

Re: [Python-Dev] short-circuiting runtime errors/exceptions in python debugger.

On Fri, Oct 26, 2018 at 04:18:37PM -0700, Ed Peschko wrote: > all, > > I was debugging a very long script that I was not all that familiar > with, and I was doing my familiar routine of being very careful in > evaluating expressions to make sure that I didn't hit such statements > as: > > TypeErr

Re: [Python-Dev] Standardize error message for non-pickleable types

On Mon, Oct 29, 2018 at 09:17:12PM +, MRAB wrote: > Therefore, my preference is for: > > "cannot pickle 'XXX' object" +1 I completely concur with MRAB. -- Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mail

Re: [Python-Dev] Standardize error message for non-pickleable types

On Mon, Oct 29, 2018 at 08:51:34PM +0100, Victor Stinner wrote: > Le lun. 29 oct. 2018 à 20:42, Serhiy Storchaka a écrit : > > 1. "pickle" or "serialize"? > > serialize -1 Serializing is more general; pickle is merely one form of serializing: https://en.wikipedia.org/wiki/Comparison_of_data_se

Re: [Python-Dev] Need discussion for a PR about memory and objects

On Sun, Nov 04, 2018 at 11:43:50AM +0100, Stephane Wirtel wrote: > In this PR [https://github.com/python/cpython/pull/3382] "Remove reference > to > address from the docs, as it only causes confusion", opened by Chris > Angelico, there is a discussion about the right term to use for the > address

Re: [Python-Dev] Get a running instance of the doc for a PR.

On Sun, Nov 04, 2018 at 04:12:39PM +0100, Stephane Wirtel wrote: > My workflow is the following steps: > > git wpr XYZ > cd ../cpython-XYZ > ./configure --prefix=$PWD-build --with-pydebug --silent > make -j 4 -s > make PYTHON=../python -C Doc/ venv > make -C Doc/ check suspicious html serve > >

Re: [Python-Dev] Get a running instance of the doc for a PR.

On Sun, Nov 04, 2018 at 12:16:14PM -0500, Ned Deily wrote: > On Nov 4, 2018, at 12:04, Paul Ganssle wrote: > > > Some of the concerns about increasing the surface area I think are a > > bit overblown. I haven't seen any problems yet in the projects that > > do this, You may or may not be right

Re: [Python-Dev] Get a running instance of the doc for a PR.

On Sun, Nov 04, 2018 at 05:05:07PM +0100, Stephane Wirtel wrote: > >If I am making doc patches, shouldn't I be doing that *before* I > >submit the PR? How else will I know that my changes haven't broken the > >docs? > > You can use the web interface of Github and just add/remove/modify a > paragra

Re: [Python-Dev] SyntaxError: can't assign to literal while using ""blkid -o export %s | grep 'TYPE' | cut -d"=" -f3" % (fs)" using subprocess module in Python

This list is for the development *of* the Python interpreter, not support for *using* Python. If you signed up to this mailing list via the web, it clearly says: Do not post general Python questions to this list. highlighted in a great big box in red. Was that not clear enough? What can we

[Python-Dev] Signalling NANs

I'm trying to understand some unexpected behaviour with float NANs in Python 3.5. Background: in IEEE-754 maths, NANs (Not A Number) come in two flavours, so called "quiet NANs" and "signalling NANs". By default, arithmetic operations on qnans return a qnan; operations on snans "signal", which

Re: [Python-Dev] Signalling NANs

On Fri, Nov 09, 2018 at 01:17:09PM -0800, Chris Barker via Python-Dev wrote: > works for me, too: > > In [9]: x = cast_int2float(0x7ff80001) > In [10]: hex(cast_float2int(x)) > Out[10]: '0x7ff80001' > > In [11]: x = cast_int2float(0x7ff1) > In [12]: hex(cast_float2int(

Re: [Python-Dev] Signalling NANs

On Sat, Nov 10, 2018 at 04:27:29PM -0800, Nathaniel Smith wrote: > Apparently loading a sNaN into an x87 register silently converts it to > a qNaN, and on Linux C compilers are allowed to do that at any point: > > > https://stackoverflow.com/questions/22816095/signalling-nan-was-corrupted-whe

Re: [Python-Dev] Need discussion for a PR about memory and objects

Responding to a few points out of order. On Mon, Nov 19, 2018 at 04:14:03PM -0800, Chris Barker via Python-Dev wrote: > I think being a bit more explicit about what properties an ID has, and how > the id() function works, and we may not need an anlogy at all, it's not > that difficult a concept.

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

On Wed, Nov 28, 2018 at 10:43:04AM -0800, Gregory P. Smith wrote: > PyPI makes getting more algorithms easy. Can we please stop over-generalising like this? PyPI makes getting more algorithms easy for *SOME* people. (Sorry for shouting, but you just pressed one of my buttons.) PyPI might as we

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

On Wed, Nov 28, 2018 at 07:14:03PM -0800, Brett Cannon wrote: > On Wed, 28 Nov 2018 at 13:29, Steven D'Aprano wrote: > > > On Wed, Nov 28, 2018 at 10:43:04AM -0800, Gregory P. Smith wrote: > > > > > PyPI makes getting more algorithms easy. > > > > Ca

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

On Thu, Nov 29, 2018 at 09:36:51AM -0500, Benjamin Peterson wrote: > I don't think it's asymmetric. People have raised several practical > problems with a large stdlib in this thread. These include: > > - The evelopment of stdlib modules slows to the rate of the Python > release schedule. That'

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

On Thu, Nov 29, 2018 at 09:53:30AM -0500, Benjamin Peterson wrote: [...] > > This is not an argument either for or against adding LZ4, I have no > > opinion either way. But it is a reminder that "just get it from PyPI" > > represents an extremely privileged position that not all Python users >

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

On Thu, Nov 29, 2018 at 01:30:28PM -0800, Nathaniel Smith wrote: [...] > > > https://anaconda.com/ > > > https://www.activestate.com/products/activepython/ > > > http://winpython.github.io/ > > > http://python-xy.github.io/ > > > https://www.enthought.com/product/canopy/ > > > https://software.int

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

On Fri, Nov 30, 2018 at 01:45:17AM +, Oscar Benjamin wrote: > They do include much more than we need so I'd agree that Anaconda is a > nuclear reactor. The things I want from it are not though. Numpy is > not a nuclear reactor: at it's core it's just providing a > multidimensional array. And

Re: [Python-Dev] Compilation of "except FooExc as var" adds useless store

On Sun, Jan 06, 2019 at 01:10:48PM +0200, Paul Sokolovsky wrote: [...] > P.S. > I actually wanted to argue that such an implementation is hardly ideal > at all. Consider: > > > e = "my precious data" > try: > 1/0 > except Exception as e: > pass > > # Where's my *global* variable? >

Re: [Python-Dev] Compilation of "except FooExc as var" adds useless store

On Sun, Jan 06, 2019 at 03:03:03PM +0200, Paul Sokolovsky wrote: [...] > Ack. Such an explanation makes sense, though semantics behind it is > "magic". And given that variable deletion happens conditionally on > whether exception happened or not, it's still pretty strange. I don't think anyone *l

Re: [Python-Dev] python subprocess module to submit a list of slurm sbatch jobs, each job use multiprocessing.Pool to run simulation on single compute node in cluster

This mailing list is for the development of the Python interpreter, not for asking questions about your own code. Did you sign up using the Python-Dev mailing list website? At the top of the page, it says Do not post general Python questions to this list. For help with Python please se

Re: [Python-Dev] How can i insert more than 32K data to a column type clob in db2 using python programming

On Tue, Jan 08, 2019 at 01:35:29PM +0530, Aman Agrawal wrote: > Hi Team, > > I have tried to insert in clob data type more than 32k byte data but > getting error:- This mailing list is for the development of the Python interpreter, not for asking questions about your own code. Did you sign up u

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

Disclaimer: I'm not a ctypes expert, so I might have this completely wrong. If so, I apologise for the noise. The id() function is documented as returning an abstract ID number. In CPython, that happens to have been implemented as the address of the object. I understand that the only way to pa

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

On Thu, Jan 17, 2019 at 11:37:13AM +0100, Antoine Pitrou wrote: I said: > > The id() function is documented as returning an abstract ID number. In > > CPython, that happens to have been implemented as the address of the > > object. > > > > I understand that the only way to pass the address of

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

On Thu, Jan 17, 2019 at 04:48:38PM -0800, Gregory P. Smith wrote: > 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 i

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

Thanks for the detailed answer. A further question below. On Thu, Jan 17, 2019 at 07:50:51AM -0600, eryk sun wrote: > On 1/17/19, Steven D'Aprano wrote: > > > > I understand that the only way to pass the address of an object to > > ctypes is to use that id. Is that i

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

On Thu, Jan 17, 2019 at 10:09:36PM -0800, Steve Dower wrote: > For everyone who managed to reply *hours* after Eryk Sun posted the > correct answer and still get it wrong, here it is again in full. Sorry, I'm confused by your response here. As far as I can see, nobody except Eryk Sun gave any tec

Re: [Python-Dev] Add more SyntaxWarnings?

On Thu, Jan 24, 2019 at 04:01:26PM -0600, Neil Schemenauer wrote: > On 2019-01-24, Terry Reedy wrote: > > Serhiy Storchaka suggested a compiler SyntaxWarning and uploaded a > > proof-of-concept diff that handled the above and many similar cases. > > I believe that in general we should give better

Re: [Python-Dev] Add more SyntaxWarnings?

At the cost of breaking threading a bit, I'm going to reply to a few different people in one post. On Fri, Jan 25, 2019 at 09:52:53AM +1100, Chris Angelico wrote: > On Fri, Jan 25, 2019 at 9:42 AM Steven D'Aprano wrote: > > We could say that implementations are allowed

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

On Wed, Feb 13, 2019 at 05:16:54PM -0500, Terry Reedy wrote: > It appears python is already python3 for a large majority of human users > (as opposed to machines). > > https://www.jetbrains.com/research/python-developers-survey-2018/ > Nearly 2 valid responses, Oct-Nov. They may be valid re

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

On Wed, Feb 13, 2019 at 03:33:21PM -0800, Barry Warsaw wrote: > I just don’t think Python 4 is anything but distant vaporware. If Python 4 follows 3.9, that could be as little as 3-4 years away :-) > There’s a cost to freaking everyone out that Python 4 is coming and > will be as disruptive as

Re: [Python-Dev] Compact ordered set

On Wed, Feb 27, 2019 at 02:15:53PM -0800, Barry Warsaw wrote: > I’m just relaying a data point. Some Python folks I’ve worked with do > make the connection between dicts and sets, and have questions about > the ordering guarantees of then (and how they relate). Sets and dicts are not related b

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

On Thu, Mar 07, 2019 at 09:56:49AM +, Paul Moore wrote: > On Thu, 7 Mar 2019 at 09:21, Inada Naoki wrote: > > The document of the optionxform shows example > > overrides it to identity function `lambda option: option`. > > https://docs.python.org/3/library/configparser.html#configparser.Config

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

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 terminology is useful, and we don't generally make a practice of talking about

Re: [Python-Dev] Using CLA assistant for Python contributions

On Thu, Mar 07, 2019 at 10:49:50AM -0800, Mariatta wrote: > Unless I hear strong opposition (with reasons) from Python Steering > Council, Python core developers, and active core contributors, I plan to > switch us over to to CLA assistant in the coming week (before my OOOS of > March 18) OOOS? O

Re: [Python-Dev] Using CLA assistant for Python contributions

On Fri, Mar 08, 2019 at 07:25:37AM +, Paul Moore wrote: > PS I would also prefer not to have to re-sign, but just have my > existing confirmation carried over. I don't *know* if there are any > implications at my end around re-signing, and my preference is simply > to not ask that question (on

Re: [Python-Dev] Using CLA assistant for Python contributions

On Fri, Mar 08, 2019 at 10:58:00AM +, Paul Moore wrote: > On Fri, 8 Mar 2019 at 10:39, Steven D'Aprano wrote: > > > > On Fri, Mar 08, 2019 at 07:25:37AM +, Paul Moore wrote: > > > > > PS I would also prefer not to have to re-sign, but just have my >

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

On Tue, Mar 12, 2019 at 05:32:35PM -0700, Gregory P. Smith wrote: > If you might want some of this contributed back to Python later on, you > should not use the GPL. Giampaolo can always change the licence of his work later. You can't take away the GPL from work you've already released, but you

Re: [Python-Dev] int() and math.trunc don't accept objects that only define __index__

On Wed, Mar 13, 2019 at 03:21:31AM -0700, Rémi Lapeyre wrote: > When __index__ is defined it means that there is a lossless conversion > to int possible. In this case, this means a lossless conversion to > float and complex is also possible That's not correct: py> n = 2**64 + 1 py> n == int(flo

Re: [Python-Dev] Remove tempfile.mktemp()

On Wed, Mar 20, 2019 at 11:25:03AM +, Anders Munch wrote: > 128 bits seems like overkill: There's no birthday attack because no-one keeps > 2^(ENTROPY_BITS/2) files around, You haven't seen my Downloads folder... :-) But seriously: > and the attack is running on the attackee's > system, so

Re: [Python-Dev] Remove tempfile.mktemp()

On Wed, Mar 20, 2019 at 12:45:40PM +0100, Victor Stinner wrote: > Hi, > > I'm not really convinced that mktemp() should be made "more secure". > To be clear: mktemp() is vulnerable by design. It's not a matter of > entropy. You can watch the /tmp directory using inotify and "discover" > immediatel

Re: [Python-Dev] Replacement for array.array('u')?

On Fri, Mar 22, 2019 at 08:31:33PM +1300, Greg Ewing wrote: > A poster on comp.lang.python is asking about array.array('u'). > He wants an efficient mutable collection of unicode characters > that can be initialised from a string. > > According to the docs, the 'u' code is deprecated and will be >

Re: [Python-Dev] (no subject)

Hi Robert, This mailing list is for the development of the Python interpreter, not a general help desk. There are many other forums where you can ask for help, such as the comp.lang.python newsgroup, Stackoverflow, /r/python on Reddit, the IRC channel, and more. Perhaps you can help us though,

Re: [Python-Dev] Proposal: dict.with_values(iterable)

On Mon, Apr 22, 2019 at 10:06:20AM -0700, Chris Barker via Python-Dev wrote: > maybe a new dict mapping type -- "shared_dict" -- it would be used in > places like the csv reader where it makes sense, but wouldn't impact the > regular dict at all. > > you could get really clever an have it auto-co

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

On Fri, May 03, 2019 at 10:46:03PM -0400, Eric V. Smith wrote: > Is there a policy against using Unicode identifiers in test files? [...] > I could work around this with exec-ing some strings, but that seems like > added confusion that I'd avoid with a real Unicode identifier. "Look, that's why t

Re: [Python-Dev] Definition of equality check behavior

On Tue, May 07, 2019 at 05:05:57PM -0400, Jordan Adler wrote: [...] > Specifically, a comparison between a primitive (int, str, float were > tested) and an object of a different type always return False, instead of > raising a NotImplementedError. Consider `1 == '1'` as a test case. I think you m

Re: [Python-Dev] Definition of equality check behavior

On Wed, May 08, 2019 at 12:05:07AM +0200, Max Vogler wrote: > Thanks for starting this discussion and addressing my issue, Jordan. > > I would like to clarify the intentions behind my original issue > : It does not > concern coercion in P

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

Disclaimer: this topic seems to have been split over at least two issues on the bug tracker, a Python-Ideas thread from 2018, Discourse (I think...) and who knows what else. I haven't read it all, so excuse me if I'm raising something already discussed. On Mon, May 06, 2019 at 08:39:41PM -0400,

Re: [Python-Dev] Adding a toml module to the standard lib?

On Wed, May 15, 2019 at 10:44:35AM +0200, Bastian Venthur wrote: > Hi, > > I'd like to discuss the idea to add a module to parse TOML [toml-lang] > to Python's standard library. You ought to read this thread here: https://mail.python.org/pipermail/python-ideas/2018-October/054101.html It isn't

Re: [Python-Dev] Adding a toml module to the standard lib?

On Wed, May 15, 2019 at 09:35:16PM +1000, Steven D'Aprano wrote: > It isn't very long (only about a dozen or so quite short posts) but you > probably ought to be at least familiar with it, and if possibly respond > to any opposing comments. Sorry, to clarify, I don't me

Re: [Python-Dev] Parser module in the stdlib

On Mon, May 20, 2019 at 08:55:59AM -0700, Guido van Rossum wrote: > I am interested in switching CPython's parsing strategy to something else > (what exactly remains to be seen) Are you re-thinking the restriction to LL(1) grammars? -- Steven ___ Pyt

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

The PEP title is prejudicial and inaccurate. These aren't "dead batteries", these are *working batteries* that you want to remove. If you want a fair and open debate on this, please change the title to something less prejudicial. If this were my PEP, I'd call it "Removing unloved batteries from

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

Let me be clear: I do not oppose the removal of modules where necessary, but I do not like this PEP as it stands. But full credit to Christian for graciously accepting feedback; I also acknowledge that if this PEP is accepted, we still have at least two releases to change our minds about indivi

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On Tue, May 21, 2019 at 01:13:30PM -0400, Edwin Zimmerman wrote: [...] [-- Attachment #2: winmail.dat --] [-- Type: application/ms-tnef, Encoding: base64, Size: 8.4K --] Wow! I haven't see one of those for *years* -- I haven't noticed one for about 15 years, and I thought it was an obsolete form

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On Wed, May 22, 2019 at 10:07:31AM +0200, Christian Heimes wrote: > On 22/05/2019 06.20, Arfrever Frehtes Taifersar Arahesis wrote: > > It is possible to have a modern Linux desktop system with PAM not > > installed at all, and therefore not used. [...] Christian wrote: > Thanks for bringing thi

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On Wed, May 22, 2019 at 01:59:59PM +0900, Stephen J. Turnbull wrote: > This looks to me like an opening to a special class of supply chain > attacks. [...] > One thing we *could* do that would require moderate effort would be to > put them up on PyPI ourselves, and require that would-be maintaine

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On Tue, May 21, 2019 at 01:59:56PM -0400, Terry Reedy wrote: > On 5/21/2019 9:01 AM, Steven D'Aprano wrote: > ... > >Many Python users don't have the privilege of being able to install > >arbitrary, unvetted packages from PyPI. They get to use only packages > >fr

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On Wed, May 22, 2019 at 01:31:18PM +0200, Christian Heimes wrote: > On 22/05/2019 12.19, Steven D'Aprano wrote: > > I don't think this PEP should become a document about "Why you should > > use PAM". I appreciate that from your perspective as a Red Hat security

Re: [Python-Dev] PEP 594: update 1

On Thu, May 23, 2019 at 02:06:13PM -0700, Brett Cannon wrote: > On Wed, May 22, 2019 at 1:23 PM Sean Wallitsch < > sean.wallit...@dreamworks.com> wrote: > > > My apologies for that oversight. My understanding is that many of the > > methods present in aifc depend heavily on audioop for reading and

[Python-Dev] PEP 594 - a proposal for unmaintained modules

I don't know if this is a good idea or a terrible idea or somewhere in between, so I'm throwing it out to see if anyone likes it. Let's add a third option to PEP 594 between "keep" and "remove": explicitly flagging a module as unmaintained. Unmaintained modules: - will raise a warning when impo

Re: [Python-Dev] PEP 558: Defined semantics for locals()

(And this time I will remember to remove the SPAM label...) On Sun, May 26, 2019 at 08:44:33AM +1000, Chris Angelico wrote: > From my reading of the description, you could also "assert a is b" - > is that correct? Yes, that's already the behaviour. py> def demo(): ... a = locals() ... b

Re: [Python-Dev] [SPAM?] Re: PEP 558: Defined semantics for locals()

Richard, your email seems to have introduced a spurious "SPAM" label to this thread, which may confuse some email clients into treating it as spam. Can you teach your email program that this mailing list is ham, not spam, or failing that, at least edit the subject line to remove the label? Thanks.

Re: [Python-Dev] PEP 558: Defined semantics for locals()

On Sun, May 26, 2019 at 08:04:11PM +1000, Steven D'Aprano wrote: > Richard, your email seems to have introduced a spurious "SPAM" label [...] > edit the subject line to remove the > label? Thanks. I've done so for this response

Re: [Python-Dev] PEP 558: Defined semantics for locals()

On Sun, May 26, 2019 at 09:20:53PM +1000, Chris Angelico wrote: > Sure, but this PEP is all about defining things that weren't > previously defined, so I wanted to clarify intent rather than current > behaviour. As I understand it, the intent is to: - fix some annoyances/bugs involved when you h

Re: [Python-Dev] PEP 594 - a proposal for unmaintained modules

On Sun, May 26, 2019 at 04:03:11PM +0300, Ivan Pozdeev via Python-Dev wrote: > On 24.05.2019 9:55, Steven D'Aprano wrote: > >I don't know if this is a good idea or a terrible idea or somewhere in > >between, so I'm throwing it out to see if anyone likes it. [...]

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