Re: [Python-Dev] Ancient use of generators

2015-05-07 Thread David Mertz
oncept) harks back to PEP 288 <https://www.python.org/dev/peps/pep-0288/>, > which was rejected. PEP 288 also proposed some changes to generators. The > interesting bit though is in the references: there are two links to old > articles by David Mertz that describe using generators in state

Re: [Python-Dev] Why aren't decorators just expressions?

2017-09-16 Thread David Mertz
I always realized the restriction was there, and once in a while mention it in teaching. But I've NEVER had an actual desire to use anything other that a simple decorator or a "decorator factory" (which I realize is a decorator in the grammar, but it's worth teaching how to parameterize custom ones

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

2017-10-22 Thread David Mertz
I worked at a molecular dynamics lab for a number of years. I advocated switching all our code to using attosecond units (rather than fractional picoseconds). However, this had nothing whatsoever to do with the machine clock speeds, but only with the physical quantities represented and the scaling

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

2017-11-06 Thread David Mertz
I strongly opposed adding an ordered guarantee to regular dicts. If the implementation happens to keep that, great. Maybe OrderedDict can be rewritten to use the dict implementation. But the evidence that all implementations will always be fine with this restraint feels poor, and we have a perfectl

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

2017-11-07 Thread David Mertz
On Nov 6, 2017 9:11 PM, "Raymond Hettinger" wrote: > On Nov 6, 2017, at 8:05 PM, David Mertz wrote: > I strongly opposed adding an ordered guarantee to regular dicts. If the implementation happens to keep that, great. Maybe OrderedDict can be rewritten to use the dict impleme

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

2017-11-22 Thread David Mertz
Inasmuch as I get to opine, I'm +1 on SyntaxError. There is no behavior for that spelling that I would find intuitive or easy to explain to students. And as far as I can tell, the ONLY time anything has ever been spelled that way is in comments saying "look at this weird edge case behavior in Pytho

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

2017-11-25 Thread David Mertz
FWIW, on a side point. I use 'yield' and 'yield from' ALL THE TIME in real code. Probably 80% of those would be fine with yield statements, but a significant fraction use `gen.send()`. On the other hand, I have yet once to use 'await', or 'async' outside of pedagogical contexts. There are a whole

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

2017-11-25 Thread David Mertz
On Sat, Nov 25, 2017 at 3:37 PM, Guido van Rossum wrote: > Maybe you didn't realize async/await don't need an event loop? Driving an > async/await-based coroutine is just as simple as driving a yield-from-based > one (`await` does exactly the same thing as `yield from`). > I realize I *can*, but

[Python-Dev] Using async/await in place of yield expression

2017-11-26 Thread David Mertz
Changing subject line because this is way off to the side. Guido and Nathaniel point out that you can do everything yield expressions do with async/await *without* an explicit event loop. While I know that is true, it feels like the best case is adding fairly considerable ugliness to the code in

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

2017-11-29 Thread David Mertz
I like much of the thinking in Random's approach. But I still think None isn't quite special enough to warrant it's own syntax. However, his '(or None: name.strip()[4:].upper())' makes me realize that what is being asked in all the '?(', '?.', '?[' syntax ideas is a kind of ternary expression. Ex

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

2017-12-17 Thread David Mertz
On Sun, Dec 17, 2017 at 8:22 AM, Guido van Rossum wrote: > On Sun, Dec 17, 2017 at 2:11 AM, Julien Salort wrote: > >> Naive question from a lurker: does it mean that it works also if one >> annotates with something that is not a type, e.g. a comment, >> >> @dataclass >> class C: >> a: "This

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

2017-12-22 Thread David Mertz
There name Data seems very intuitive to me without suggesting type declaration as Any does (but it can still be treated as a synonym by actual type checkers) On Dec 22, 2017 12:12 PM, "Paul Moore" wrote: > On 22 December 2017 at 19:50, Gregory P. Smith wrote: > > > My preference for this is "ju

Re: [Python-Dev] Guido's Python 1.0.0 Announcement from 27 Jan 1994

2018-01-27 Thread David Mertz
Does anyone have an archive of the Python 1.0 documentation? Sadly http://www.cwi.nl/~guido/Python.html is not a live URL :-). On Sat, Jan 27, 2018 at 9:08 AM, Chris Angelico wrote: > On Sun, Jan 28, 2018 at 3:58 AM, Senthil Kumaran > wrote: > > Someone in HackerNews shared the Guido's Python

Re: [Python-Dev] Dataclasses and correct hashability

2018-02-02 Thread David Mertz
I agree with Ethan, Elvis, and a few others. I think 'hash=True, frozen=False' should be disabled in 3.7. It's an attractive nuisance. Maybe not so attractive because its obscurity, but still with no clear reason to exist. If many users of of dataclass find themselves defining '__hash__' with mut

Re: [Python-Dev] Dataclasses and correct hashability

2018-02-05 Thread David Mertz
Absolutely I agree. 'unsafe_hash' as a name is clear warning to users. On Feb 4, 2018 10:43 PM, "Chris Barker" wrote: On Sun, Feb 4, 2018 at 11:57 PM, Gregory P. Smith wrote: > +1 using unsafe_hash as a name addresses my concern. > mine too -- anyone surprised by using this deserves what the

Re: [Python-Dev] Dataclasses and correct hashability

2018-02-06 Thread David Mertz
Honestly, the name I would most want for the keyword argument is '_hash'. That carries the semantics I desire. On Feb 6, 2018 10:13 AM, "Ethan Furman" wrote: > On 02/06/2018 09:38 AM, Guido van Rossum wrote: > > Where do you get the impression that one would have to explicitly request >> __hash_

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

2018-02-23 Thread David Mertz
On Feb 23, 2018 9:26 PM, "Steven D'Aprano" wrote: Given a potentially expensive DRY violation like: [(function(x), function(x)+1) for x in sequence] there are at least five ways to solve it. A 6th way is to wrap the expensive function in @lru_cache() to make it non-expensive. [(a, a

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

2018-02-23 Thread David Mertz
FWIW, the nested loop over a single item is already in the language for 15 years or something. It's not that ugly, certainly not enough to need a new 'let' or 'where' keyword that basically does exactly the same thing with 3 fewer characters. On Feb 23, 2018 10:04 PM, Dav

Re: [Python-Dev] Symmetry arguments for API expansion

2018-03-12 Thread David Mertz
If anyone cares, my vote is to rip out both .as_integer_ratio() and .is_integer() from Python. I've never used either and wouldn't want to. Both seem like perfectly good functions for the `math` module, albeit the former is simply the Fraction() constructor. I can see no sane reason why anyone wo

Re: [Python-Dev] Symmetry arguments for API expansion

2018-03-12 Thread David Mertz
On Mon, Mar 12, 2018, 3:25 PM Tim Peters wrote: > [David Mertz ] > > ... > > I can see no sane reason why anyone would ever call float.is_integer() > > actually. That should always be spelled math.isclose(x, int(x)) because > > IEEE-754. Attractive nuisance is probab

Re: [Python-Dev] Deprecating float.is_integer()

2018-03-21 Thread David Mertz
I've been using and teaching python for close to 20 years and I never noticed that x.is_integer() exists until this thread. I would say the "one obvious way" is less than obvious. On the other hand, `x == int(x)` is genuinely obvious... and it immediately suggests the probably better `math.isclose

Re: [Python-Dev] Deprecating float.is_integer()

2018-03-21 Thread David Mertz
On Wed, Mar 21, 2018 at 3:02 PM, Tim Peters wrote: > [David Mertz] > > I've been using and teaching python for close to 20 years and I never > > noticed that x.is_integer() exists until this thread. > > Except it was impossible to notice across most of those years,

Re: [Python-Dev] Deprecating float.is_integer()

2018-03-21 Thread David Mertz
Ok. I'm wrong on that example. On Wed, Mar 21, 2018, 9:11 PM Tim Peters wrote: > [David Mertz ] > >> For example, this can be true (even without reaching inf): > >> > >> >>> x.is_integer() > >> True > >> >>> (math.sqrt(

Re: [Python-Dev] Sets, Dictionaries

2018-03-29 Thread David Mertz
I agree with everything Steven says. But it's true that even as a 20-year Python user, this is an error I make moderately often when I want an empty set... Notwithstanding that I typed it thousands of times before sets even existed (and still type it when I want an empty dictionary). That said, I'

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

2018-04-17 Thread David Mertz
Strongly agree with Nick that only simple name targets should be permitted (at least initially). NONE of the motivating cases use more complex targets, and allowing them encourages obscurity and code golf. On Tue, Apr 17, 2018, 8:20 AM Nick Coghlan wrote: > On 17 April 2018 at 17:46, Chris Angel

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

2018-04-20 Thread David Mertz
It's horrors like this: g(items[idx] := idx := f()) That make me maybe +0 if the PEP only allowed simple name targets, but decisively -1 for any assignment target in the current PEP. I would much rather never have to read awful constructs like that than get the minor convenience of: if

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

2018-04-21 Thread David Mertz
It feels very strange that the PEP tries to do two almost entirely unrelated things. Assignment expressions are one thing, with merits and demerits discussed at length. But "fixing" comprehension scoping is pretty much completely orthogonal. Sure, it might be a good idea. And yes there are interac

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

2018-04-21 Thread David Mertz
27;s nothing quite analogous in current Python for: while (command := input("> ")) != "quit": print("You entered:", command) On Sat, Apr 21, 2018, 11:57 AM Nick Coghlan wrote: > On 22 April 2018 at 01:44, David Mertz wrote: > > It feels very strange

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

2018-04-24 Thread David Mertz
I do think the pronunciation issue that Greg notices is important. I teach Python for most of my living, and reading and discussing code segments is an important part of that. When focussing on how Python actually *spells* something, you can't always jump to the higher-level meaning of a construc

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

2018-04-26 Thread David Mertz
> > [Raymond Hettinger ] > > Python is special, in part, because it is not one of those languages. > > It has virtues that make it suitable even for elementary school children. > > We can show well-written Python code to non-computer folks and walk > > them through what it does without their brains

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

2018-04-26 Thread David Mertz
FWIW, the combination of limiting the PEP to binding expressions and the motivating example of sequential if/elif tests that each need to utilize an expression in their body (e.g. matching various regexen by narrowing, avoiding repeated indent) gets me to +1. I still think the edge case changes to

Re: [Python-Dev] Dealing with tone in an email

2018-05-05 Thread David Mertz
The below is really just making this whole situation worse. On Sat, May 5, 2018 at 8:22 PM, Ivan Pozdeev via Python-Dev < python-dev@python.org> wrote: > As I suspected. This is a classic scenario that is occasionally seen > anywhere: "everyone is underestimating a problem until a disaster strike

Re: [Python-Dev] Slow down...

2018-05-08 Thread David Mertz
This seems like a rather bad idea. None of the core changes in the last few versions were on the radar 10 years in advance. And likewise, no one really knows what new issues will become critical over the next 10. The asyncio module and the async/await keywords only developed as important concerns

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

2018-06-25 Thread David Mertz
On Mon, Jun 25, 2018 at 5:14 PM Steve Holden wrote: > I'd like to ask: how many readers of ​ > > ​this email have ever deliberately taken advantage of the limited Python 3 > scope in comprehensions and generator expressions to use what would > otherwise be a conflicting local variable name?​ > I

Re: [Python-Dev] Python and Linux Standard Base

2018-06-27 Thread David Mertz
The main wiki page was last touched at all in 2016. The mailing list in Jan 2018 had about 8 comments, none of them actually related to LSB. They stopped archiving the ML altogether in Feb 2018. I think it's safe to say the parrot is dead. On Wed, Jun 27, 2018, 9:50 AM Antoine Pitrou wrote: > On

Re: [Python-Dev] What's New editing

2015-07-05 Thread David Mertz
On Sun, Jul 5, 2015 at 6:06 PM, Nick Coghlan wrote: > On 6 July 2015 at 03:52, R. David Murray wrote: > > Just so people aren't caught unawares, it is very unlikely that I will > have > > time to be the final editor on "What's New for 3.5" they way I was for > 3.3 and > > 3.4. > > And thank you

Re: [Python-Dev] What's New editing

2015-07-06 Thread David Mertz
. If this is OK with the powers-that-be, I'll coordinate with David Murray on how best to take over this task from him. Thanks, David... On Sun, Jul 5, 2015 at 8:51 PM, Nick Coghlan wrote: > On 6 July 2015 at 12:42, David Mertz wrote: > > I think I might be able to "volu

Re: [Python-Dev] How far to go with user-friendliness

2015-07-17 Thread David Mertz
Nothing huge to add, and I'm not experienced using mock. But the special handling of 'assret' as a "misspelling of 'assert'" definitely strikes me as a wart also. That sort of thing really has no place in a library itself, but rather only in a linter. On Fri, Jul 17, 2015 at 9:20 AM, Steven D'Ap

Re: [Python-Dev] Status on PEP-431 Timezones

2015-07-25 Thread David Mertz
At the risk of being off-topic, I realize I really DO NOT currently understand datetime in its current incarnation. It's too bad PEP 431 proves so difficult to implement. Even using `pytz` is there any way currently to get sensible answers to, e.g.: from datetime import * from pytz import timezo

Re: [Python-Dev] PEP-498: Literal String Formatting

2015-08-09 Thread David Mertz
On Sun, Aug 9, 2015 at 11:22 AM, Eric V. Smith wrote: > > I think it has to do with the nature of the programs that people write. > I write software for internal use in a large company. In the last 13 > years there, I've written literally hundreds of individual programs, > large and small. I just

Re: [Python-Dev] PEP-498: Literal String Formatting

2015-08-09 Thread David Mertz
sn't look like that (especially to beginners whom I might teach). The name 'scope_format' is ugly, and something shorter would be nicer, but I think this conveys my idea. Yours, David... On Sun, Aug 9, 2015 at 6:14 PM, David Mertz wrote: > On Sun, Aug 9, 2015 at 11:22 AM, Eric V. Smi

Re: [Python-Dev] PEP-498: Literal String Formatting

2015-08-10 Thread David Mertz
I know. I elided including the nonexistent `nonlocals()` in there. But it *should* be `lngb()`. Or call it scope(). :-) On Aug 10, 2015 10:09 AM, "Steven D'Aprano" wrote: > On Sun, Aug 09, 2015 at 06:14:18PM -0700, David Mertz wrote: > > [...] > > That said, there

Re: [Python-Dev] What's New editing

2015-09-05 Thread David Mertz
his, but I wonder if maybe someone else would like to be co-author since the increased workload doesn't actually seem likely to diminish soon. On Wed, Sep 2, 2015 at 7:03 PM, Yury Selivanov wrote: > > > On 2015-07-06 11:38 AM, David Mertz wrote: > >> Hi Folks, >> >>

Re: [Python-Dev] Conversion of a standard unicode string to a bit string in Python

2015-10-17 Thread David Mertz
This list is for discussion of development of the Python core language and standard libraries, not for development *using* Python. It sounds like you should probably do your homework problem on your own, actually, but if you seek advice, something like StackOverflow or python-list are likely to be

Re: [Python-Dev] type(obj) vs. obj.__class__

2015-10-18 Thread David Mertz
This recipe looks like a bad design to me to start with. It's too-clever-by-half, IMO. If I were to implement RingBuffer, I wouldn't futz around with the __class__ attribute to change it into another thing when it was full. A much more obvious API for users would be simply to implement a RingBuf

Re: [Python-Dev] type(obj) vs. obj.__class__

2015-10-18 Thread David Mertz
; self.data[self.cur] = x > self.cur = (self.cur + 1) % self.max > def get(self): > return self.data[self.cur:] + self.data[:self.cur] > > > > On 18 October 2015 at 08:45, David Mertz wrote: > >> This recipe looks like a bad design to me to start

Re: [Python-Dev] type(obj) vs. obj.__class__

2015-10-18 Thread David Mertz
cilities. They don't say anything about this "mutate the __class__ trick", but I somehow suspect he'd put that in that category. On Sun, Oct 18, 2015 at 6:47 PM, Steven D'Aprano wrote: > On Sun, Oct 18, 2015 at 05:35:14PM -0700, David Mertz wrote: > > > In any case

Re: [Python-Dev] PEP-8 wart... it recommends short names because of DOS

2015-10-20 Thread David Mertz
DOS Python programmers probably can't use `concurrent` or `multiprocessing`. ☺ On Oct 20, 2015 6:26 PM, "Gregory P. Smith" wrote: > https://www.python.org/dev/peps/pep-0008/#names-to-avoid > > *"Since module names are mapped to file names, and some file systems are > case insensitive and truncate

Re: [Python-Dev] PEP 8 recommends short module names because FAT is still common today (was: PEP-8 wart... it recommends short names because of DOS)

2015-10-20 Thread David Mertz
Even thumb drives use VFAT. Yes it's an ugly hack, but the names aren't limited to 8.3. On Oct 20, 2015 6:59 PM, "Ben Finney" wrote: > "Gregory P. Smith" writes: > > > There haven't been computers with less than 80 character file or path > > name element length limits in wide use in decades... ;

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

2016-02-11 Thread David Mertz
Great PEP overall. We definitely don't want the restriction to grouping numbers only in threes. South Asian crore use grouping in twos. https://en.m.wikipedia.org/wiki/Crore On Feb 11, 2016 7:04 PM, "Glenn Linderman" wrote: > On 2/11/2016 4:16 PM, Steven D'Aprano wrote: > > On Thu, Feb 11, 2016

Re: [Python-Dev] Examples for PEP 572

2018-07-04 Thread David Mertz
On Wed, Jul 4, 2018 at 3:02 AM Chris Angelico wrote: > "Assignment is a statement" -- that's exactly the point under discussion. > "del is a statement" -- yes, granted > "function and class declarations are statements" -- class, yes, but > you have "def" and "lambda" as statement and expression e

Re: [Python-Dev] Examples for PEP 572

2018-07-04 Thread David Mertz
ldn't actually use. On Wed, Jul 4, 2018 at 9:58 AM Chris Angelico wrote: > On Wed, Jul 4, 2018 at 11:52 PM, David Mertz wrote: > > On Wed, Jul 4, 2018 at 3:02 AM Chris Angelico wrote: > >> > >> "Assignment is a statement" -- that's exactly the

Re: [Python-Dev] Examples for PEP 572

2018-07-04 Thread David Mertz
On Wed, Jul 4, 2018 at 12:13 PM Steven D'Aprano wrote: > On Wed, Jul 04, 2018 at 10:20:35AM -0400, David Mertz wrote: > > Hmmm... I admit I didn't expect quite this behavior. I'm don't actually > > understand why it's doing what it does. > > > >

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

2018-07-05 Thread David Mertz
On Thu, Jul 5, 2018, 7:46 PM Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: > It also appears that there are no cases where = can be substituted for := > and not cause a syntax error. This means that ":" in ":=" is strictly > redundant. > Under your proposal, this is ambiguous: '

Re: [Python-Dev] Call for prudence about PEP-572

2018-07-08 Thread David Mertz
The case I find more reasonable is assignment in earlier arguments: z = something () w = myfun(x := get_data(), y=calculate(x, z)) I would probably recommend against that in code review, but it's not absurdly obfuscated. On Sun, Jul 8, 2018, 1:15 PM Giampaolo Rodola' wrote: > > > On Sun, Jul 8

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

2018-07-12 Thread David Mertz
On Thu, Jul 12, 2018, 1:24 PM Barry Warsaw wrote: > It’s not the first time I’ve found myself in this position with a new > Python feature, and it’s one of the reasons I deeply trust Guido’s > intuition and sensibilities. > Sure... Except for the terrible choice to drop the '<>' inequality opera

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

2018-07-15 Thread David Mertz
I've pretty much always taught using the "comprehension" term. It makes sense to introduce comprehensions on concrete collections first. Then I typically say something like "This special kind of comprehension is called a 'generator expression'". Usually that's accompanied by a motivation like creat

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

2018-11-28 Thread David Mertz
+1 to Brett's idea. It's hard to have a good mental model already of which compression algorithms are and are not in stdlib. A package to contain them all would help a lot. On Wed, Nov 28, 2018, 12:56 PM Brett Cannon Are we getting to the point that we want a compresslib like hashlib if we > are

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

2018-11-29 Thread David Mertz
On Thu, Nov 29, 2018, 2:55 PM Paul Moore ... and some users need a single, unambiguous choice for the > "official, complete" distribution. Which need the current stdlib > serves extremely well. > Except it doesn't. At least not for a large swatch of users. 10 years ago, what I wanted in Python w

[Python-Dev] Interested in serving on Steering Council

2019-01-02 Thread David Mertz
voters wish to elect me. Thanks, David Mertz... -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to t

Re: [Python-Dev] Interested in serving on Steering Council

2019-01-04 Thread David Mertz
I do not wish to presume too much on the judgement of the core developers. But I thank Steve Dower for his characterizations which pretty much exactly explain why I've had those involvements with the Python community and language I have had, and haven't done other things. I've been part of the Pyt

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

2019-01-18 Thread David Mertz
On Fri, Jan 18, 2019, 5:55 AM Antoine Pitrou > > id() returning the address of the object should be a guaranteed feature > > For me, the definitive answer is "yes, it's a CPython feature". > That doesn't mean the CPython feature has to live forever. We may want > to deprecate it at some point W

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

2019-01-18 Thread David Mertz
sun. On Fri, Jan 18, 2019 at 10:29 AM David Mertz wrote: > On Fri, Jan 18, 2019, 5:55 AM Antoine Pitrou >> >> > id() returning the address of the object should be a guaranteed feature >> >> For me, the definitive answer is "yes, it's a CPython feature&qu

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

2019-01-30 Thread David Mertz
Ditto +1 option 4 On Wed, Jan 30, 2019, 5:56 PM Paul Moore On Wed, 30 Jan 2019 at 22:35, Raymond Hettinger > wrote: > > My recommendation is Option 4 as being less disruptive and more > beneficial than the other options. In the unlikely event that anyone is > currently depending on the reorderi

Re: [Python-Dev] Register-based VM [Was: Possible performance regression]

2019-03-11 Thread David Mertz
Parrot got rather further along than rattlesnake as a register based VM. I don't think it every really beat CPython in speed though. http://parrot.org/ On Mon, Mar 11, 2019, 5:57 PM Neil Schemenauer wrote: > On 2019-02-27, Victor Stinner wrote: > > The compiler begins with using static single a

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

2019-03-19 Thread David Mertz
In my opinion, any test that relied on a non-promised accident of serialization is broken today. Very often, such bad tests mask bad production code that makes the same unsafe assumptions. This is similar to tests that assumed a certain dictionary order, before we got guaranteed insertion order. O

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

2019-05-27 Thread David Mertz
On Sun, May 26, 2019 at 11:17 PM Steven D'Aprano wrote: > > Nobody reads warnings. > > If nobody reads warnings, we should just remove the warnings module and > be done with it. That should probably be a PEP. > We'll have to start issuing a PendingDeprecationWarning when folk import the `warning

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

2019-06-06 Thread David Mertz
The old URL is definitely a lot friendlier, even apart from the length. I know at a glance the month and list where the thread occurred, which is perhaps the most important metadata. In the new link I only know what mailing list it happened on, and nothing else meaningful. On Thu, Jun 6, 2019, 8:2

[Python-Dev] Re: _Py_Identifier should support non-ASCII string?

2019-06-20 Thread David Mertz
This change would break two lovely functions I wrote this week. On Thu, Jun 20, 2019, 12:35 PM Steve Dower wrote: > On 20Jun2019 0205, Inada Naoki wrote: > > Hi, all. > > > > Both of PyUnicdoe_FromString() and _Py_Identifier are > > supporting UTF-8 for now. We can not change PyUnicode_FromStri

[Python-Dev] Re: _Py_Identifier should support non-ASCII string?

2019-06-20 Thread David Mertz
Ok. Good point. I used Unicode identifiers in my own project, not in CPython. Some Greek letters that represent common mathematical concepts. On Thu, Jun 20, 2019, 11:27 PM Inada Naoki wrote: > On Fri, Jun 21, 2019 at 6:55 AM David Mertz wrote: > > > > This change would b

[Python-Dev] Re: Comparing dict.values()

2019-07-24 Thread David Mertz
I agree with Greg. There are various possible behaviors that might make sense, but having `d.values() != d.values()` is about the only one I can see no sense in. This really feels like a good cade for reading a descriptive exception. If someone wants too compare `set(d.values())` that's great. If

[Python-Dev] Re: Comparing dict.values()

2019-07-24 Thread David Mertz
Cliffe via Python-Dev < python-dev@python.org> wrote: > > > On 25/07/2019 00:09:37, David Mertz wrote: > > I agree with Greg. > > > > There are various possible behaviors that might make sense, but having > > `d.values() != d.values()` is about the only one I

[Python-Dev] Fwd: Re: Comparing dict.values()

2019-07-25 Thread David Mertz
On Thu, Jul 25, 2019 at 4:35 AM Petr Viktorin wrote: > It's not the equality operator that errors: `==` means element-wise > comparison in Numpy. The error would come from a conversion of the array > to bool: > > >>> numpy.array([1, 2, 3]) == numpy.array([1, 3, 4]) > array([ True, False, False])

[Python-Dev] Re: Fwd: Re: Comparing dict.values()

2019-07-26 Thread David Mertz
On Fri, Jul 26, 2019, 8:02 AM Greg Ewing wrote: > David Mertz wrote: > > > > We COULD do that with > > `d1.values() == d2.values()` in principle. This "DictValuesComparison" > > object could have methods like `.equal_as_set()` and > > `.equal_as_list()`. H

[Python-Dev] Words rather than sigils in Structural Pattern Matching

2020-11-12 Thread David Mertz
I have read a great deal of discussion on the pattern matching PEPs and less formal discussions. It is possible I have overlooked some post in all of that, of course. ... OK, just saw Guido's "wait for new SC" comment, which I suppose applies to this too :-). One idea that I cannot recall seeing

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

2020-11-15 Thread David Mertz
Complimentary != Complementary On Sun, Nov 15, 2020, 4:51 AM Paul Sokolovsky wrote: > Hello, > > As was mentioned many times on the list, PEP634-PEP636 are thoroughly > prepared and good materials, many thanks to their authors. PEP635 > "Motivation and Rationale" (https://www.python.org/dev/peps

[Python-Dev] Re: The semantics of pattern matching for Python

2020-11-21 Thread David Mertz
On Sat, Nov 21, 2020 at 12:23 PM Steven D'Aprano wrote: > Clearly Spam(a=1, b=2) does not necessarily result in an instance with > attributes a and b. But the pattern `Spam(a=1, b=2)` is intended to be > equivalent to (roughly): > > if (instance(obj, Spam) > and getattr(obj, a) == 1 >

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

2020-11-21 Thread David Mertz
o, really use this name as a value!" I like a word better, but none of the current keywords really make sense, so it would need to be a new word. I suggested "value", but another word might be better. On Thu, Nov 12, 2020 at 7:38 PM David Mertz wrote: > One idea that I can

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

2020-11-21 Thread David Mertz
On Sat, Nov 21, 2020 at 2:47 PM Guido van Rossum wrote: > On Sat, Nov 21, 2020 at 9:52 AM David Mertz wrote: > >> So in my mind, if I had the choice, it is a decision between a sigil and >> a word to indicate "no, really use this name as a value!" I like a wor

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

2020-11-23 Thread David Mertz
On Mon, Nov 23, 2020, 2:58 PM Ethan Furman > >> if isinstance(node, StringNode): > >> return node.value > >> elif isinstance(node, NumberNode): > >> return float(node.value) > >> elif isinstance(node, ListNode): > >> return [p

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

2020-11-23 Thread David Mertz
I have a little bit of skepticism about the pattern matching syntax, for similar reasons to those Larry expresses, and that Steve Dower mentioned on Discourse. Basically, I agree matching/destructuring is a powerful idea. But I also wonder how much genuinely better it is than a library that does

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

2020-11-23 Thread David Mertz
On Mon, Nov 23, 2020 at 9:02 PM Brian Coleman wrote: > > Basically, I agree matching/destructuring is a powerful idea. But I also > > wonder how much genuinely better it is than a library that does not > require > > a language change. For example, I could create a library to allow this: > >

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

2020-11-23 Thread David Mertz
On Mon, Nov 23, 2020, 4:32 PM Eric V. Smith > I just commented on Steve's post over on Discourse. The problem with this > is that the called function (m.case, here) needs to have access to the > caller's namespace in order to resolve the expressions, such as StringNode > and PairNone. This is one

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

2020-11-23 Thread David Mertz
> > I'd put the question this way: assuming Matcher can be written (with a bit > of stack magic), and assuming that the strings inside m.case() calls are > exactly the same mini-languague PEP 634 proposes, would you want a syntax > change? > > No, I wouldn't! > Is one of us mixing up negations? Are

[Python-Dev] Re: nanosecond stat fields, but not os.path methods ?

2020-12-07 Thread David Mertz
Are there any filesystems that can actually record a meaningful ns modification time? I find discussions claiming this: - XFS and EXT3: second precision - EXT4: millisecond precision - NTFS: 100ns precision - APFS: 1 ns precision But also notes that the precision is likely to exceed the accuracy

[Python-Dev] Re: SC 2020 recommendation for PEP 634

2020-12-08 Thread David Mertz
As a candidate for the new SC, if elected I would certainly find it more useful to have more specific thoughts from the outgoing SC than simply "we recommend." How divided was the vote? Who took the sides? What were the major points of disagreement? That sort of thing. On Tue, Dec 8, 2020 at 9:39

[Python-Dev] Re: unittest of sequence equality

2020-12-22 Thread David Mertz
On Tue, Dec 22, 2020 at 6:57 PM Alan G. Isaac wrote: > The following test fails because because `seq1 == seq2` returns a > (boolean) NumPy array > whenever either seq is a NumPy array. > > import unittest > import numpy as np > unittest.TestCase().assertSequenceEqual([1.,2.,3.], >

[Python-Dev] Re: unittest of sequence equality

2020-12-22 Thread David Mertz
On Tue, Dec 22, 2020 at 11:44 PM Alan G. Isaac wrote: > My question is not about work arounds. > It is about whether the current definition of a sequence > (in collections.abc) should govern `assertSequenceEqual`. > Why do you think a NumPy array is a sequence? E.g.: >>> a array([[1, 2],

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

2021-02-14 Thread David Mertz
On Sun, Feb 14, 2021, 2:53 PM Gregory P. Smith wrote: > *TL;DR of my TL;DR* - Not conveying bool-ness directly in the return > annotation is my only complaint. A BoolTypeGuard spelling would > alleviate that. > This is exactly my feeling as well. In fact, I do not understand why it cannot simpl

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

2021-02-14 Thread David Mertz
On Sun, Feb 14, 2021, 5:34 PM Guido van Rossum wrote: > But note that 'bool' in Python is not subclassable. > Sure. But that's why I suggested 'Bool' rather than 'bool'. It's a different spelling, but one with a really obvious connection. > > I.e. if I read this: >> >> def is_str_list(v: List[A

[Python-Dev] Re: Python 0.9.1

2021-02-18 Thread David Mertz
Will someone publish an manylinux build to conda-forge (or their own channel)? On Thu, Feb 18, 2021 at 9:15 PM Dan Stromberg wrote: > > On Thu, Feb 18, 2021 at 12:02 AM Paul Sokolovsky > wrote: > >> I think to resolve this issue to the completion, and avoid possibility >> of an intermediary to

[Python-Dev] Re: Python 0.9.1

2021-02-18 Thread David Mertz
I've provided this excellent language interpreter as a conda package. For users of conda, you can install it (on Linux) with: conda install -c davidmertz python=0.9 (perhaps put it in a different environment than base). I'm embarrassed by how much effort that took me. I used to teach conda-

[Python-Dev] Re: Python 0.9.1

2021-02-19 Thread David Mertz
In conversation with Dan, I have fixed my conda package (but overwritten the same version). I needed to add this to the build: # sudo apt-get install gcc-multilib CC='gcc -m32' make python I don't have 32-bit headers by default anymore on my distro. With that change, I can run: % conda install

[Python-Dev] Re: Steering Council update for February

2021-03-10 Thread David Mertz
On Wed, Mar 10, 2021 at 1:13 PM Evpok Padding wrote: > Apparently renaming a git branch to follow the general convention is now > an unbearable outrage. It strikes me as a somewhat odd hill to die on, but > okay. However there is a code of conduct that is supposed to be followed > here https://ww

[Python-Dev] Re: Steering Council update for February

2021-03-10 Thread David Mertz
On Wed, Mar 10, 2021, 4:30 PM Steven D'Aprano wrote: > > All the other examples are also forced and contrived. This is perhaps > worst. I own several chains for purposes having nothing to do with bondage > or oppression. > > Chains are an almost universal symbol of bondage and slavery: "Man is

[Python-Dev] Re: Boundaries between numbers and identifiers

2021-04-13 Thread David Mertz
I feel like all of these examples, if found in the wild, are far more likely to be uncaught bugs than programmer intent. Being strict about spaces (or parents, brackets, etc. in other contexts) around numbers is much more straightforward than a number of edge cases where is not obvious what will ha

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

2021-04-14 Thread David Mertz
I recently encountered this, which is very useful, but only for a human-readable perspective. >>> import vaex >>> vaex.__version__ {'vaex': '4.1.0', 'vaex-core': '4.1.0', 'vaex-viz': '0.5.0', 'vaex-hdf5': '0.7.0', 'vaex-server': '0.4.0', 'vaex-astro': '0.8.0', 'vaex-jupyter': '0.6.0', 'vaex-ml': '

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

2021-04-14 Thread David Mertz
arker wrote: > On Wed, Apr 14, 2021 at 7:48 AM David Mertz wrote: > >> >>> vaex.__version__ >> {'vaex': '4.1.0', 'vaex-core': '4.1.0', 'vaex-viz': '0.5.0', 'vaex-hdf5': >> '0.7.0', '

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

2021-04-14 Thread David Mertz
On Wed, Apr 14, 2021 at 5:44 PM Christopher Barker wrote: > Another possible issue: using Version would require an extra import in > many module initializations -- is that a performance issue that would > matter? > I like having a `Version` object that is easily importable in the standard librar

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

2021-04-14 Thread David Mertz
On Wed, Apr 14, 2021 at 9:12 PM Paul Moore wrote: > If it's not basically equivalent to packaging.version.Version (and > based on PEP 440) then we'll be creating a nightmare of confusion, > because PEP 440 versions are fundamental to packaging. > Are you suggesting that users should have to inst

  1   2   >