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

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

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)

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

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

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

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

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

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)

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

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

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:

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

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

Re: [Python-Dev] PEP 572: Assignment Expressions

> Personally, I even slightly prefer > > a := 3 > > to the commonplace > > a = 3 > because it visually expresses the asymmetry of the operation. Careful here! That’s a fine argument for using := in a new language, but people using := when they don’t need an expression because they like the symbol

Re: [Python-Dev] PEP 572: Assignment Expressions

> On Apr 19, 2018, at 4:27 PM, Christoph Groth wrote: > def sync_runner(learner, f, static_hint): >while True: >points = learner.get(static_hint) >if not points: >break >learner.feed(f(points)) > > > > With assignment

Re: [Python-Dev] Soliciting comments on the future of the cmd module (bpo-33233)

Is bringing cmd2 into the standard library an option to be considered? That water get included batteries and a more featurefull and supported lib. It seems (on python-ideas) that people are often told, when they have a suggestion for the stdlib, that they put it on pypi and see if it gains

Re: [Python-Dev] The `for y in [x]` idiom in comprehensions

> Is it similar enough to > >def f(x=[0]): No, not at all — it’s a very different use case. When I first saw this on the original thread, I needed to stare at it a good while, and then whip up some code to experiment with it to know what it did. And not because I don’t know what a single

Re: [Python-Dev] Dataclasses, frozen and __post_init__

would also be a property of values. But it would require a flag, and a bunch of logic overhead, which could get pretty ugly so maybe not worth it. -CHB On Mon, Feb 19, 2018 at 5:06 PM, Chris Barker - NOAA Federal < chris.bar...@noaa.gov> wrote: > If I have this right, on the discuss

Re: [Python-Dev] Dataclasses, frozen and __post_init__

If I have this right, on the discussion about frozen and hash, a use case was brought up for taking a few steps to create an instance (and thus wanting it not frozen) and then wanting it hashable. Which pointed to the idea of a “ freeze this from now on” method. This seems another use case —

Re: [Python-Dev] Dataclasses and correct hashability

>> IMO, the danger of >> "@dataclass(hash=True)" far overweighs whatever convenience it might >> provide. Is there any reason specifying has=True could set frozen=True unless the user specifically sets frozen=False? Or is that already the case? I think the folks that are concerned about this

Re: [Python-Dev] OS-X builds for 3.7.0

> It would be nice to do more things the Apple way, including porting to modern > runtime feature availability check cascades of the Cocoa APIs and using the > Apple provided system Frameworks. This seems like a rather major workload and > should be targeting 3.8. Yeah — too much to do for 3.7

Re: [Python-Dev] OS-X builds for 3.7.0

And maybe we could even get rid of the "Framework" builds.. > Please do not. These make life easier for doing things the Apple way for signed sandboxed applications. Thanks — good to hear there is a good reason for them. I’ve always thought that Frameworks were designed with other

Re: [Python-Dev] f-strings

That's covered under "format specifiers" I think. The PEP mentions this: https://www.python.org/dev/peps/pep-0498/#format-specifiers I can see how a newbie might not realize that that means that f-strings use the same formatting language as the .format() method, and or where to find

Re: [Python-Dev] Is static typing still optional?

. I see a couple of options: 1a: Use a default type annotation, if one is not is supplied. typing.Any would presumably make the most sense. 1b: Use None if not type is supplied. 2: Rework the code to not require annotations at all. I think I'd prefer 1a, since it's easy. 2) would be great :-)

Re: [Python-Dev] iso8601 parsing

Thanks either way, -Mike On 2017-12-07 17:57, Chris Barker - NOAA Federal wrote: ___ 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/chris.

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)

I made the following two changes to the PEP 540: * open() error handler remains "strict" * remove the "Strict UTF8 mode" which doesn't make much sense anymore +1 — ignore my previous note. -CHB I wrote the Strict UTF-8 mode when open() used surrogateescape error handler in the UTF-8 mode. I

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v2)

I’m a bit confused: File names and the like are one thing, and the CONTENTS of files is quite another. I get that there is theoretically a “default” encoding for the contents of text files, but that is SO likely to be wrong as to be ignorable. open() already defaults to utf-8. Which is a fine

Re: [Python-Dev] iso8601 parsing

>but is it that hard to parse arbitrary ISO8601 strings in once you've gotten this far? It's a bit uglier than I'd like, but not THAT bad a spec. No, and in fact this PR is adapted from a *more general* ISO-8601 parser that I wrote (which is now merged into master on python-dateutil). In the

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

This seems like overkill to me. By the same logic, we should add a "delay garbage collection" mode, that allows people to test that their code doesn't make unwarranted assumptions that a reference-counting garbage collector is in use. Actually, there is a LOT of code out there that expects

Re: [Python-Dev] PEP 557: Data Classes

- record +1 This really does match well with the record concept in databases, and most people are familiar with that. Though it will. E a touch confusing until (if ever) most of the database and cab traders, etc start using them. It also matches pretty well with numpy "record arrays":

Re: [Python-Dev] PEP 557: Data Classes

> On Sep 12, 2017, at 9:01 AM, Chris Barker - NOAA Federal > <chris.bar...@noaa.gov> wrote: > This really does match well with the record concept in databases, and most > people are familiar with that. Though it will. E a touch confusing until (if > ever) most of the dat

Re: [Python-Dev] To reduce Python "application" startup time

> Anyway, I think researching import tree of popular library is good > startline > about optimizing startup time. > I agree -- in this case, you've identified that asyncio is expensive -- good to know. In the jinja2 case, does it always need asyncio? Pep8 as side, I think it often makes sense

Re: [Python-Dev] enable-framework Vs. Naught

> This list is for development of furture releases. Questions about using > current releases should go to python-list, Stackoverflow, or other help > forums. The python-Mac SIG would be a good one for this. CHB > > -- > Terry Jan Reedy > > > ___ >

Re: [Python-Dev] Adding bytes.frombuffer() constructor to PEP 467

> This is what happens with numpy arrays: > > >>> bytes(numpy.array([2], 'i1')) > b'\x00\x00' > > >>> bytes(numpy.array([2, 2], 'i1')) > b'\x02\x02' > > For better or worse, single-element numpy arrays have a working __index__ > methods Ouch -- that probably is for the worse.. There are Numpy

Re: [Python-Dev] O(1) deletes from the front of bytearray (was: Re: Adding bytes.frombuffer() constructor to PEP 467 (was: [Python-ideas] Adding bytes.frombuffer() constructor)

> The proposal is that it should be documented as being part of the > language spec starting in 3.4 (or whatever). Is the performance characteristics of any object part of the language spec? I.e if someone wrote an implementation with an O(n) insert dict, it would suck, but wouldn't it still be

Re: [Python-Dev] Adding bytes.frombuffer() constructor to PEP 467 (was: [Python-ideas] Adding bytes.frombuffer() constructor

>> >> >> Method proliferation on builtins is a Big Deal(TM) > > I wanted to quantify this concept, so here's a quick metric that helps > convey how every time we add a new builtin method we're immediately > making Python harder to comprehend: > def get_builtin_types(): >... import

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

>> , which aren't in any wide spread use yet and > probably won't be for quite a few years ahead. Anything added to the stdlib now will be in py3.6+, yes? Which won't be in widespread use for quite a few years yet, either. So if ( and that's a big if) it's possible to anticipate what will be in

Re: [Python-Dev] pathlib - current status of discussions

> On Apr 13, 2016, at 8:31 PM, Nick Coghlan wrote: > >>> class Special(bytes): >>> def __fspath__(self): >>> return 'str-val' >>> obj = Special('bytes-val', 'utf8') >>> path_obj = fspath(obj, allow_bytes=True) >>> >>> With #2, path_obj == 'bytes-val'. With

Re: [Python-Dev] pathlib - current status of discussions

> with the > rationale being the one someone mentioned regarding ease-of-use in > os.path. > > Consider os.path.join: Why in the world do the os.path functions need to work with Path objects? ( and other conforming objects) Thus all started with the goal of using Path objects in the stdlib,

Re: [Python-Dev] Pathlib enhancments - method name only

> On Apr 8, 2016, at 3:00 PM, Eric Snow wrote: > >> On Fri, Apr 8, 2016 at 12:25 PM, Brett Cannon wrote: >> I personally still like __ospath__ as well. > > Same here. The strings are essentially an OS-dependent serialization, > rather than related

Re: [Python-Dev] Other pathlib improvements? was: When should pathlib stop being provisional?

>> Personally, the main issue I have with remembering pathlib method >> names, is the inconsistency with the existing modules. Was this *really* not brought up when this was introduced? Oh well. We could add aliases, but I think it's not such a big deal. I'm convinced that the largest barrier

Re: [Python-Dev] Defining a path protocol

>> Ah, good point. I think that kills __path__ then as an option. Darn. I really preferred that. Oh well. > __fspath__ +0.1 But not a big deal. I think this is pretty much for occasional use by library authors, so not a big deal what it is named. Which also means that I don't think we need a

Re: [Python-Dev] Windows: Remove support of bytes filenames in the os module?

All I can say is "ouch". Hard to call it a regression to no longer allow this mess... CHB > On Feb 8, 2016, at 4:37 PM, eryk sun wrote: > >> On Mon, Feb 8, 2016 at 2:41 PM, Chris Barker wrote: >> Just to clarify -- what does it currently do for bytes?

Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)

>> and there are a LOT of next-to worthless docstrings in the stdlib -- it >> would be nice to clean them all up. >> >> Is there any reason not to, other than someone having to do the work? And yes, I'd be willing to submit a patch. > Is this just a matter of _datetimemodule.c (and various

Re: [Python-Dev] PEP 0484 - the Numeric Tower

>> Well, that's what you get in exchange for "type safety". > > AIUI, the point of type annotations is that some use cases benefit *a > lot* from machine-parsable type information, not that type annotation > is a universally good idea in itself. It's not type *safety* that's > the aim here. It's

Re: [Python-Dev] PEP 0484 - the Numeric Tower

And these days > anybody who is using Decimal for Money (which ought to be everybody, I'm not so sure about that -- using base-10 is nice, but it doesn't automatically buy you the appropriate rounding rules, etc that you need to "proper" accounting. And, as MA pointed out, in much "finance"

Re: [Python-Dev] PEP 0484 - the Numeric Tower

> Yes, but what I expect the type annotations to be used for, especially > in the SciPy world, is to make things easier for Numba to generate fast > code. Well, probably not. There are two reasons to have type declarations: performance and type safety. But the current type annotations are

Re: [Python-Dev] PEP 0484 - the Numeric Tower

I merely worry about what happens if people > start relying upon the fact that a float annotation 'will handle all > the numbers I care about' to the forgotten Decimal users such as > myself. Well, that's what you get in exchange for "type safety". Which is exactly why I'm concerned about

Re: [Python-Dev] VS 2010 compiler

TL;DR -- yes, documenting this in packaging.python.org would be great! > Part of the problem here is that people put up postings saying "do > this" having checked that it works for them, and then others say "but > it doesn't work", without giving any information as to why or > providing any means

Re: [Python-Dev] Washington DC Python sprint report

Sent from my iPhone > On Sep 28, 2015, at 2:18 PM, Barry Warsaw wrote: > >> On Sep 28, 2015, at 08:22 AM, Guido van Rossum wrote: >> >> I saw that you had a need for an asyncio tutorial. I wonder if the "500 >> lines" chapter on asyncio would help? I didn't write it; I only

Re: [Python-Dev] VS 2010 compiler

> I'm not sure why INADA Naoki's answer above wasn't sufficient for you? It may be -- I've still have to test. Neither Windows nor py3 are my primary production versions. But the last time I tried the SDK approach was for py2.7 on Win64, and it was both a pain, and impossible to set up to "just

Re: [Python-Dev] VS 2010 compiler

> On Sep 29, 2015, at 9:20 AM, Steve Dower wrote: > >> On 29Sep2015 0820, Chris Barker wrote: >> OK -- I'm going to get off my soap box now -- time to actually suggest >> doc patches > > Just bear in mind that you're suggesting patches for Python 3.3 and 3.4, > which

[Python-Dev] VS 2010 compiler

As I understand it, the MS VS2010 compiler is required (or at least best practice) for compiling Python extensions for the python.org Windows builds of py 3.4 and ?[1] However, MS now makes it very hard (impossible?) to download VS2010 Express ( or Community, or whatever the free as in beer

Re: [Python-Dev] VS 2010 compiler

> This is the main motivation for moving to VS 2015 for Python 3.5. Yes,I've followed that work to the degree I understand it, and it looks like a great move. Thanks so much for your (continuing) efforts with this. > put a bit of >> >> pressure on MS to make it available, as they have for VS2008

Re: [Python-Dev] VS 2010 compiler

permission for. But it still may be the best bet. I'll give it a try when I have a chance. And this should be in the "official" docs... -CHB On Sat, Sep 26, 2015 at 12:24 AM, Chris Barker - NOAA Federal < chris.bar...@noaa.gov> wrote: > As I understand it, the MS VS2010 compiler is

Re: [Python-Dev] PEP needed for http://bugs.python.org/issue9232 ?

there's been enough debate that I suspect we need a PEP. I think we might just need another round of discussion here. Please no :-) Looking back at the previous discussion, it looked like it's all been said, and there was almost unanimous approval (with some key mild disapproval) for the

Re: [Python-Dev] updating ensurepip to include wheel

I'm confident we're going to want a support prebuilt wheels only installation option downstream in the Linux distro world - Interesting-- so move to a Python specific binary distribution option -- rather than using rm or deb packages? Doesn't lead to a dependency heck? I.e no way to express

Re: [Python-Dev] updating ensurepip to include wheel

Please don't add extra pain for purity and make sure that ensurepip installs pip and not slow pip until you install wheel in the venv. This is a really good point -- other than purity, what is the downside? Arguably, the only reason setuptools, pip, and wheel are not in the standard library are

Re: [Python-Dev] Backporting the 3.5+ Windows build project files to 2.7

I'd like to backport those new project files to 2.7, Would this change anything about how extensions are built? There is now the ms compiler for 2.7 would that work? Or only in concert with VS2010 express? -CHB and Intel is willing to fund that work as part of making Python ICC compilable

Re: [Python-Dev] Pydoc Replacement for Python's help()?

Just want to make sure you're aware of the new mobile-sig: https://mail.python.org/mailman/listinfo/mobile-sig No need to do this on your own. -Chris On Jan 27, 2015, at 4:21 PM, Cyd Haselton chasel...@gmail.com wrote: On Tue, Jan 27, 2015 at 2:45 PM, Glenn Linderman v+pyt...@g.nevcal.com

Re: [Python-Dev] Bytes path support

Does Unix even support UTF-16 as an encoding? I suppose, these days, it probably does, for reading contents of files created on Windows, etc. I don't think Unix supports any encodings at all for the _contents_ of files -- that's up to applications. Of course the command line text processing

Re: [Python-Dev] sum(...) limitation

I'm very sympathetic to Steven's explanation that we wouldn't be having this discussion if we used a different operator for string concatenation. Sure -- but just imagine the conversations we could be having instead : what does bit wise and of a string mean? A bytes object? I cod see it as a

Re: [Python-Dev] sum(...) limitation

Sorry for the bike shedding here, but: The quadratic behaviour of repeated str summation is a subtle, silent error. OK, fair enough. I suppose it would be hard and ugly to catch those instances and raise an exception pointing users to .join. *is* controversial that CPython silently optimises

Re: [Python-Dev] PEP 471 -- os.scandir() function -- a better and faster directory iterator

On Jun 26, 2014, at 4:38 PM, Tim Delaney timothy.c.dela...@gmail.com wrote: On 27 June 2014 09:28, MRAB pyt...@mrabarnett.plus.com wrote: -1 for windows_wildcard (it would be an attractive nuisance to write windows-only code) Could you emulate it on other platforms? +1 on the rest of it.

Re: [Python-Dev] ConfigParser mangles keys with special chars

On Apr 25, 2014, at 11:47 AM, Terry Reedy tjre...@udel.edu wrote: So I wonder whether the thought-to-be-buggy behavior is actually buggy with respect to *all* the supported styles or just some of them. I can't how being able to write a file that isn't read back with the same meaning could be

Re: [Python-Dev] pep8 reasoning

One added note: if greeting == True: if greeting is True: This one is based on the preference for identity checks when singletons are involved, rather than equality tests. Being composed of English words, the latter is also more readable. It's the same reason why you would do identity

Re: [Python-Dev] PEP 0404 and VS 2010

with older releases (I admit I don't understand the ABI compatibility on OSX). Well, with OS-X, it's not exactly the C lic in the same way, but there are different SDKs for different OS versions, and you can add to that PPC vs Intel processors and 32 vs 64 bit. So we have for years had two

Re: [Python-Dev] PEP 428 - pathlib - ready for approval

On Nov 20, 2013, at 4:53 PM, Antoine Pitrou solip...@pitrou.net wrote: When pathlib-in-the-stdlib stabilizes, I plan to release a pathlib 1.0 on PyPI that will integrate the PEP's API. Great, thanks! Chris In the meantime, if you don't mind installing from VCS, you clone the Mercurial