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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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_
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
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
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
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
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
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,
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(
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'
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
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
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
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
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
>
> [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
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
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
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
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
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
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
.
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
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
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
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
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
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
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,
>>
>>
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
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
; 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
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
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
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... ;
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
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
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
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.
> >
> >
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: '
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
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
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
+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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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])
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
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
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
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
>
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
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
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
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
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:
>
>
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
>
> 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
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
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
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.],
>
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],
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
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
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
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-
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
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
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
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
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': '
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', '
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
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 - 100 of 196 matches
Mail list logo
