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] 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] 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] 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] 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] 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] 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] 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] 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 funct

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] 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] 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] Official citation for Python

gt;> >> Jackie Kazil >> Board of Directors, PSF >> >> >> >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: http

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

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

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 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] 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] 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] "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] Signalling NANs

loat2int(x)) >> '0x7ff80001' >> > > I got '0x7ff1'. > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe:

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] 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] 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 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] 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] 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 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] 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] 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] 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

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

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

[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

[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] 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: 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] 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: 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: 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: 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: 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: 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: 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

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

Re: [Python-Dev] Python startup time

Inspired by chg: Could one make a little startup utility that, when invoked the first time, starts up a raw python interpreter, keeps it running somewhere, and then forks it to run the actual python code. Then every invocation after that would make a new fork. I presume forking is a LOT faster th

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

> while the changes introduced by Python 3 > affect pretty much everyone, even people who only write small simple > scripts. Sure they do, but the *hard stuff* not so much. I have found 2to3 conversion to be remarkably easy and painless. And the whole Unicode thing is much easier. CHB > Regar

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

> between 3.0 and 3.6 (.5?) -- py3 grew a lot of minor features that made it >> easier to write py2/py3 compatible code. >> u"string", b'bytes %i' % something -- and when where the various >> __future__ imports made available? >> > > You'll need to be more specific. __future__ has been around for

Re: [Python-Dev] Docstrings on builtins

> > This may even be a bug/feature of IPython, Ahh, thanks! I’ll look into that. -CHB ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/

Re: [Python-Dev] Microsoft to acquire GitHub for $7.5 b

> We shouldn't be uniquely or especially concerned just because > Microsoft has purchased Github. Nothing has changed. Exactly — but this change HAS made people think about an issue that we should have already been thinking about. At the end of the day, anyone, or any project, would be well serv

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

Sent from my iPhone > > So what about: > > > > l = [x:=i for i in range(3)] > > > > vs > > > > g = (x:=i for i in range(3)) > > > > Is there any way to keep these consistent if the "x" is in the regular > > local scope? > > I'm not clear on what the question is. The list comprehension would bind

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

> On Jun 28, 2018, at 8:21 PM, Tim Peters wrote: Seems it’s all been said, and Tim’s latest response made an excellent case for consistency. But: > Regardless of how assignment expressions work in listcomps and genexps, this > example (which uses neither) _will_ rebind the containing block's `

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

> On Jul 2, 2018, at 8:34 AM, Steven D'Aprano wrote: Guido has decided — and despite my concerns, I’m going to enjoy my new loop-and-a half construct:-) But a comment on this: > comprehension are no more special than > assignments inside any other expression. They bind in the current scope, > s

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

Are we just having fun here? Or might we actually start using a new naming convention for the-syntax-formerly-known-as-generator-expressions? -CHB Sent from my iPhone > On Jul 3, 2018, at 11:54 PM, Greg Ewing wrote: > > Steven D'Aprano wrote: >> - list builder syntax is syntax which returns a

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

TL;DR- +1 on advocating the term “generator comprehension” as a synonym for “generator expression” in future documentation and instructional materials. The long version: If we were starting from scratch, maybe it would makes sense to use “ builder” or something else, rather than comprehension. B

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

> 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. The rules for valid field names could very well be different than Python’s rules. The kwargs implementation is not

Re: [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!

I’m all for extending the life of 3.6, it sure feels recent to me! > 3.6 is the default Python in Ubuntu 18.04 LTS and RHEL 8. And due to several > important syntax features it can be a minimal required version for long time. Which is a good argument for why we may not need longer term support f

Re: [Python-Dev] Sub-interpreters: importing numpy causes hang

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 them to put them in their own namespace — that is, a plug-in is a single package, with however many sub modules as it

Re: [Python-Dev] Add more SyntaxWarnings?

>. There's nothing mysterious about e.g. `TypeError: unsupported operand type(s) for +: 'int' and 'str'`, unlike the case of the two concatenated tuples. (Surely people get errors about int+str all the time, and they've never complained -- unlike the tuple tuple case.) Well, yes, that particular e

Re: [Python-Dev] Add more SyntaxWarnings?

> But as a rule, >> there are a LOT of errors that can be pretty mysterious to newbies. > > Isn't that the very definition of "newbie"? That's half a joke, but I > really don't think that programmers new to Python should be the > standard. Python is broadly advocated (and used) as a first languag

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

> On Feb 13, 2019, at 9:13 AM, Steve Dower > > I'm inclined to view "python" as the default, official command, with the > versioned ones being workarounds added by distributors. +1 — almost. I agree that “python” be the default, but it would be good to require (or at least highly encourage) that

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

> I'd like to raise a potential edge case that might be a problem, and likely > an increasingly common one: users with multiple installations of the *same* > version of Python. I would suggest that that use case is best addressed by a system that isolates the entire python environment, such as c

Re: [Python-Dev] Consolidating channel of record [was: 581 (Using GitHub issues for CPython) is accepted]

Frankly, multiple long meandering threads in s single mailing list are not s very good archive either. Ideally, the PEP is updated with a summary of the issues discussed as the discussion unfolds. (And links to the main discussion threads?) It founds like that didn’t happen in this case, but it’

<    1   2   3   4