[Python-Dev] Re: Should the definition of an "(async) iterator" include __iter__?

Note: I am all for not enforcing anything here -- let's keep duck typing alive! If static type checkers want to be more pedantic, they can be -- that's kinda what they are for :-) But the OP wrote: """ "[i]terators are required to have an __iter__()

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

On Mon, Nov 23, 2020 at 8:20 AM Brian Coleman wrote: > Take as an example a function designed to process a tree of nodes similar > to that which might be output by a JSON parser. There are 4 types of node: > > - A node representing JSON strings > - A node representing JSON numbers > - A node repr

[Python-Dev] Re: Unification of the Mac builds?

Thanks Ronald, This is really helpful. -CHB On Fri, Jan 15, 2021 at 5:43 AM Ronald Oussoren wrote: > > > On 14 Jan 2021, at 23:03, Chris Barker via Python-Dev < > python-dev@python.org> wrote: > > Ned, > > Thanks -- I'll take further discussion to the pyth

[Python-Dev] Re: Unification of the Mac builds?

Ned, Thanks -- I'll take further discussion to the python-mac list. Ronald: That’s a feature of the framework build. The unix build is exactly the same > as a unix build on other platform. Adding the same feature to the unix > build should be possible, but would complicate the build. I have no

[Python-Dev] Re: Story behind vars() vs .__dict__

This was discussed a bit over on python-ideas recently, so a note from me, and one from that thread: Or for that matter, not the reason to provide > object's internal storage via object's attribute: obj.__dict__. > Well, it IS an implementation detail that it's a dictionary, but having a dunder t

[Python-Dev] Re: unittest of sequence equality

On Wed, Dec 23, 2020 at 1:06 AM Steven D'Aprano wrote: > We're not obligated to take heroic > measures to integrate numpy arrays with unittest methods. If we can do > so easily, sure, let's fix it. > > I think Ivan's suggestion that the assertSequenceEqual method fall back > on element-by-element

[Python-Dev] Unification of the Mac builds?

Sorry if I'm out of the loop here, but with Apple's new chip coming out, we need new a build configuration (which I think has already been started, if not done). Perhaps we could take this opportunity to better modularize / unify the build setup? As it was last I checked, you really had only two

[Python-Dev] Re: PEP 611: The one million limit.

I am not qualified to comment on much of this, but one simple one: 1 million is a nice round easy to remember number. But you can fit 2 million into 21 bits, and still fit three into 64 bits, so why not? Ialso noticed this: > Reference Implementation > > None, as yet. T

[Python-Dev] Re: The Python 2 death march

On Tue, Sep 17, 2019 at 10:39 PM Terry Reedy wrote: > I agree. The thread title is a bit extreme. There will be a long > twilight. > > > Metaphorically that is correct, but at the same time there are > > things like https://pythonclock.org which > > is one per

[Python-Dev] Re: The Python 2 death march

Peter, I think that went just to me, which I suspect was not what you intended, so I've brought it back on the list: On Tue, Sep 17, 2019 at 12:06 PM Peter Wang wrote: > On Mon, Sep 16, 2019 at 5:55 PM Chris Barker via Python-Dev < > python-dev@python.org> wrote: > >>

[Python-Dev] Re: The Python 2 death march

Regardless of the date of the final release, no one's Python2 install will stop working, and people will still be able to download and install that last release. So I like the metaphor -- it's being "sunset" -- there will be a long dusk .. a month or tow makes no difference to anyone's workflo

[Python-Dev] Re: Building Standalone Python Applications with PyOxidizer

Congrats on this new tool -- I'll be checking it out. With a quick glance at the docs, I see this: """ PyOxidizer loads everything from memory and there is no explicit I/O being performed. When you import a Python module, the bytecode for that module is being loaded from a memory address in the e

[Python-Dev] Re: strip behavior provides inconsistent results with certain strings

This was quite extensively discussed on python-ideas recently: https://mail.python.org/archives/list/python-id...@python.org/thread/RJARZSUKCXRJIP42Z2YBBAEN5XA7KEC3/#WIRID57ESUFUAQQQ6ZUY2RK5PKQQYSJ3 (I'm finding it hard to find a good thread view in the new interface -- but that will get you star

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

On Fri, Apr 12, 2019 at 10:20 AM Brett Cannon wrote: > >> This doesn't strike me as needing an optimization through a dedicated > method. > 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

Re: [Python-Dev] PEP-582 and multiple Python installations

Sorry somehow missed Steve Dower's post: that discussion is mostly happening at https://discuss.python.org/t/pep-582-python-local-packages-directory/963/ I"ll go there to comment. -CHB On Thu, Apr 4, 2019 at 9:02 AM Chris Barker - NOAA Federal < chris.bar...@noaa.gov> wrote: > > > I'd like t

Re: [Python-Dev] datetime.timedelta total_microseconds

On Wed, Feb 27, 2019 at 3:04 PM Richard Belleville wrote: > Timedelta division is quite a nice solution to the problem. However, since > we're maintaining a python version agnostic library at least until 2020, we > need a solution that works in python 2 as well. > So you were limited to a py2 so

Re: [Python-Dev] datetime.timedelta total_microseconds

Did we ever hear back from the OP as to whether they were using py2 or 3? If they were unable to find timedelta division in py3 -- that's a pretty good case that we need something else. The OP: """ On Wed, Feb 13, 2019 at 9:10 PM Richard Belleville via Python-Dev < python-dev@python.org> wrote:

Re: [Python-Dev] datetime.timedelta total_microseconds

On Wed, Feb 27, 2019 at 7:15 AM Paul Ganssle wrote: > As another data point, I also have a background in the physical sciences, > and I actually do find it quite intuitive. The first time I saw this idiom > I took it to heart immediately and only stopped using it because many of > the libraries I

Re: [Python-Dev] datetime.timedelta total_microseconds

On Tue, Feb 26, 2019 at 7:22 PM Terry Reedy wrote: > > timedelta.total_seconds() > > To me, total_x implies that there is a summation of multiple timedeltas, > and there is not. So not intuitive to me. THAT was a discussion for when it was added -- I can't say it's my favorite name either. But

Re: [Python-Dev] Compact ordered set

On Tue, Feb 26, 2019 at 3:43 PM Barry Warsaw wrote: > The behavior differences between dicts and sets is already surprising to > many users, so we should be careful not to make the situation worse. > It's a nice to have, but other than the fact that we all used to use a dict when we really want

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

On Tue, Feb 26, 2019 at 3:25 PM Barry Warsaw wrote: > > Who gets to decide on PEP 394 changes? > > Honestly, I think it’s the active distro maintainers who need to make this > decision. They have the pulse of their own communities and users, and can > make the best decisions and compromises for

Re: [Python-Dev] datetime.timedelta total_microseconds

This thread petered out, seemingly with a consensus that we should update the docs -- is anyone doing that? But anyway, I'd like to offer a counterpoint: >From the OP, it is clear that: * Folks have a need for timedeltas to be converted to numbers values, with units other than seconds (milliseco

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

On Tue, Feb 26, 2019 at 9:58 AM Barry Warsaw wrote: > I see this question as having several parts, and the conflation of them is > part of the reason why the unversioned `python` command is so problematic. > Python is used for: > > * OS functionality > * to run applications that aren’t critical t

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

On Fri, Feb 15, 2019 at 2:39 PM Brett Cannon wrote: > In my experience after using 'py' on Windows I consistently miss it on > UNIX now, so to me there is enough of a benefit that I will continue to > chip away at the project until it's done regardless of whether anyone else > uses it. :) > And

Re: [Python-Dev] datetime.timedelta total_microseconds

On Fri, Feb 15, 2019 at 11:58 AM Rob Cliffe via Python-Dev < python-dev@python.org> wrote: > A function with "microseconds" in the name IMO misleadingly suggests that > it has something closer to microsecond accuracy than a 1-second granularity. > it sure does, but `delta.total_seconds()` is a fl

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

On Wed, Feb 13, 2019 at 12:29 PM Barry Warsaw wrote: > I think we should aspire for this to be the case too, eventually. When > this has come up in the past, we’ve said that it’s not appropriate to > change PEP 394 until Python 2 is officially deprecated. OTOH, I appreciate > that distros and o

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

On Mon, Nov 19, 2018 at 1:41 AM Antoine Pitrou wrote: > I'd rather keep the reference to memory addressing than start doing car > analogies in the reference documentation. > I agree -- and any of the car analogies will probably be only valid in some jurisdictions, anyway. I think being a bit mo

Re: [Python-Dev] Signalling NANs

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(x)) Out[12]: '0x7ff1' OS-X, conda build: Python 3.7.0 | packaged by conda-forge

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

On Wed, Oct 24, 2018 at 9:06 AM, Victor Stinner wrote: > I like os.system() and use it everyday. me too. Python has been evolved over the years away from a "scripting language", and becoming more of a "systems language". Which is mostly a good thing, but no need to gratuitously make quick scri

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

it may or may not apply to everywhere nameapaces are used in the interpreter... > but __dict__ is described as " [a] dictionary or other mapping object". > exactly. -CHB On Sun, 7 Oct 2018 at 19:38, Chris Barker via Python-Dev < > python-dev@python.org> wrote: > >> O

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

On Fri, Oct 5, 2018 at 3:01 PM Brett Cannon wrote: > I'm also fine with saying that keys in **kwargs that are not proper > identifiers is an implementation detail. > It's not just **kwargs -- you can also use arbitrary names with setattr() / getattr() : In [6]: setattr(foo, "4 not an identifier

Re: [Python-Dev] Official citation for Python

> > On Saturday, September 15, 2018, Jacqueline Kazil > wrote: > >> I just got caught up on the thread. This is a really great discussion. >> Thank you for all the contributions. >> >> Before we get into the details, let's go back to the main use case we are >> trying to solve. >> *As a user, I am

Re: [Python-Dev] Official citation for Python

Thanks Wes. """ > Python > > Guido van Rossum: Scripting the Web with Python. In "Scripting Languages: > Automating the Web", World Wide Web Journal, Volume 2, Issue 2, Spring > 1997, O'Reilly. > > Aaron Watters, Guido van Rossum, James C. Ahlstrom: Internet Programming > with Python. MIS Press/He

Re: [Python-Dev] Official citation for Python

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? > There's a metric ton of information on the web about citing software, > there are existing standards, a

Re: [Python-Dev] Official citation for Python

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. > > I don't think it is. I think you are seeing a distinction that is not > there. no need for us to agree on that, but there are sti

Re: [Python-Dev] Official citation for Python

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 jusstify something and make it clear that it is not your own idea (i.e. not pagerism). in the

Re: [Python-Dev] Issue?

python used the "timsort" sorting routine: https://en.wikipedia.org/wiki/Timsort So you can look at that and confirm that this is correct behaviour (I'm betting it is :-) But in general, sorting is O(n log(n)) -- there are going to be more than n comparisons. If comparing is slow, you want to u

Re: [Python-Dev] Pre- and post-conditions

This is an appropriate topic for pyton-ideas: https://mail.python.org/mailman/listinfo/python-ideas not python-dev. I'm sure you'll find interest in your idea there. -CHB On Wed, Aug 15, 2018 at 1:25 AM, Marko Ristin-Kaufmann < marko.ris...@gmail.com> wrote: > Hi python devs, > > I would be

Re: [Python-Dev] Error message for wrong number of arguments

On Wed, Aug 1, 2018 at 2:40 PM, Armin Rigo wrote: > On 30 July 2018 at 22:19, Chris Barker via Python-Dev > wrote: > > Oh well. This is a serious usability issue -- but what can you do? > > I think that argument clinic knows if the built-in function is > supposed to be a

Re: [Python-Dev] Error message for wrong number of arguments

On Mon, Jul 30, 2018 at 11:39 AM, Jeroen Demeyer wrote: > On 2018-07-30 20:22, Chris Barker wrote: > >> is it possible for the interpreter to know when this error is >> generated that this is a bound method expecting a "self", rather than an >> arbitrary function with n parameters? >> > > That wo

Re: [Python-Dev] Error message for wrong number of arguments

On Mon, Jul 30, 2018 at 5:12 AM, Jeroen Demeyer wrote: > I think it has been argued before that it's a feature that self is > counted. I suppose it is, as it's technically correct, but it's also a HUGE source of confusion, particularly for newbies. IF this is being touched anyway, is it possibl

Re: [Python-Dev] PEP 572 and assert

> > I don't see why. As Chris said, side effects in asserts are nothing new > and > Indeed -- this new feature makes it easier to affect the local scope in all sorts of new places. It was decided that the additional complexity is worth it to make the language more expressive, and it was also decid

Re: [Python-Dev] Const access to CPython objects outside of GIL?

On Tue, Jul 17, 2018 at 4:34 AM, Victor Stinner wrote: > > IMHO you need a different approach to implement optimizations. For > example, use your objects which don't rely on the GIL to be > consistent. Sadly, I have no experience with that and so cannot > provide any example. > I DO NOT understa

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

Thanks Nick, I'll adopt this approach when I update my teaching materials. If I think of it, I"ll post here when I do that -CHB On Sun, Jul 15, 2018 at 12:21 AM, Nick Coghlan wrote: > On 13 July 2018 at 15:30, Chris Barker via Python-Dev > wrote: > > On Mon, Jul 9,

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

On Mon, Jul 9, 2018 at 3:18 PM, Guido van Rossum wrote: > Definitely docs first. And we should keep references to generator > expressions too, if only to explain that they've been renamed. > > Perhaps someone should try it out in a 3rd party tutorial to see how it > goes? > I'm not sure what "tr

Re: [Python-Dev] Examples for PEP 572

On Wed, Jul 4, 2018 at 7:20 AM, David Mertz wrote: > > That said, this is a silly game either way. And even though you CAN > (sometimes) bind in an expression pre-572, that's one of those perverse > corners that one shouldn't actually use. > not only shouldn't by hardly anyone ever does / would

Re: [Python-Dev] Examples for PEP 572

On Tue, Jul 3, 2018 at 2:51 PM, Chris Angelico wrote: > On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka > wrote: > > I believe most Python users are not > > professional programmers -- they are sysadmins, scientists, hobbyists and > > kids -- > > [citation needed] fair enough, but I think we

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Mon, Jul 2, 2018 at 11:42 PM, Tim Peters wrote: > "comprehensions" was always a dubious term, carried over from set theory > where the term focuses on the optional "if" part rather than the more > fundamental iterator or computation parts. > I always wondered about that :-) -- I'd say for mo

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Sun, Jul 1, 2018 at 5:25 PM, Steven D'Aprano wrote: > > > an optional topic. Once widely used, it ain't optional. > > Without knowing the details of your course, and who they are aimed at, > we cannot possibly judge this comment. Decorators are widely used, but > surely you don't teach them in

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Sun, Jul 1, 2018 at 8:35 AM, Michael Selik wrote: > As Mark and Chris said (quoting Mark below), this is just one straw in the > struggle against piling too many things on the haystack. Unlike some > changes to the language, this change of such general use that it won't be > an optional topic.

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Thu, Jun 28, 2018 at 9:28 AM, Tim Peters wrote: > >>> g = (x:=i for i in range(3)) > Common or not, I have no idea why anyone would write a genexp like the one > you gave, except to contrive an example of silly behavior exhibited by > silly code ;-) > yes, it was a contrived example, but the

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 12:01 PM, Eric V. Smith wrote: > >>> def test(): > >>>spam = 1 > >>>ham = 2 > >>>vars = [key1+key2 for key1 in locals() for key2 in locals()] > >>>return vars > >>> > >>> Wanna guess what that's gonna return? > Guessing aside, messing around with locals()

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Fri, Jun 22, 2018 at 7:23 PM, Steven D'Aprano wrote: > > But once it becomes a more common idiom, students will see it in the wild > > pretty early in their path to learning python. So we'll need to start > > introducing it earlier than later. > > Students see many features early in their path

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Fri, Jun 22, 2018 at 10:09 AM, Michael Selik wrote: > I forgot to add that I don't anticipate changing my lesson plans if this > proposal is accepted. There's already not enough time to teach everything > I'd like. Including a new assignment operator would distract from the > learning objectiv

Re: [Python-Dev] A more flexible task creation

Excuse my ignorance (or maybe it's a vocabulary thing), but I'm trying to understand the problem here. But if I have this right: I've been using asyncio a lot lately and have encountered this problem > several times. Imagine you want to do a lot of queries against a database, > spawning 1 tas

Re: [Python-Dev] Docstrings on builtins

On Tue, Jun 5, 2018 at 8:01 AM, Ivan Pozdeev wrote: > In [5]: print(str.__doc__) > str(object='') -> str > str(bytes_or_buffer[, encoding[, errors]]) -> str > > Create a new string object from the given object. If encoding or > errors is specified <...> > As you can see, the start of the type's d

Re: [Python-Dev] Docstrings on builtins

OK, looking a bit deeper: In [69]: timedelta.__new__.__doc__ Out[69]: 'Create and return a new object. See help(type) for accurate signature.' In [70]: timedelta.__init__.__doc__ Out[70]: 'Initialize self. See help(type(self)) for accurate signature.' In [71]: timedelta.__doc__ Out[71]: 'Diff

Re: [Python-Dev] Docstrings on builtins

t; Clinic and then run "make clinic" to regenerate the generated files. > good idea. Now to find some time to actually work on this... -CHB > Victor > > 2018-06-04 23:45 GMT+02:00 Chris Barker via Python-Dev < > python-dev@python.org>: > > Over on pytho

[Python-Dev] Docstrings on builtins

Over on python-ideas, someone is/was proposing literals for timedeltas. I don't expect that will come to anything, but it did make me take a look at the docstring for datetime.timedelta. I use iPython's ? a lot for a quick overview of how to use a class/function. This is what I get: In [8]: time

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

On Sat, May 12, 2018 at 8:14 AM, Skip Montanaro wrote: > > I have found 2to3 conversion to be remarkably easy and painless. > > > And the whole Unicode thing is much easier. > Another point here: between 3.0 and 3.6 (.5?) -- py3 grew a lot of minor features that made it easier to write py2/py3

Re: [Python-Dev] Python startup time

On Mon, May 14, 2018 at 12:33 PM, INADA Naoki wrote: > It will broke hash randomization. > > See also: https://www.cvedetails.com/cve/CVE-2017-11499/ I'm not enough of a security expert to know how much that matters in this case, but I suppose one could do a bit of post-proccessing on the image

Re: [Python-Dev] Python startup time

On Fri, May 11, 2018 at 11:05 AM, Ryan Gonzalez wrote: > https://refi64.com/uprocd/ very cool -- but *nix only, of course :-( But it seems that there is a demand for this sort of thing, and a few major projects are rolling their own. So maybe it makes sense to put something into the standard

Re: [Python-Dev] bpo-33257: seeking advice & approval on the course of action

On Wed, May 2, 2018 at 8:21 PM, Terry Reedy wrote: > On 5/2/2018 4:38 PM, Ivan Pozdeev via Python-Dev wrote: > >> The bottom line is: Tkinter is currently broken >> > > This is way over-stated. Many modules have bugs, somethings in features > more central to their main purpose. I'll suggest a