[Python-ideas] Re: Enhance list.index with a comparison function

[David Mertz]

On Sat, May 23, 2020, 12:26 AM Steven D'Aprano

> Obviously not all such key functions are that simple and you may need to
> write a helper function, but the same applies to filter.
>

I like the key function much better than the predicate. In large part
that's because as soon as you say predicate, I think filter. Particularly
if I care about laziness in not looking through extra items.

If you wanted everything matching a predicate, using a comprehension just
seems more obvious. It could be lazy with a generator comprehension, not
them you need next() to get the first.

Key= has the obvious parallel with sorted() and friends. Even then, a
function similar to sorted() feels more general than a method on lists only.

I.e.

index_of(needle, haystack, key=func)

I'm not sure where that would live exactly, maybe itertools. I think you
were on my side in believing an import from standard library is not a huge
burden.

I think if such a function existed, I'd want another argument to match n !=
1 results. But then it gets ugly because one index is an integer, and
multiple indices are some sort of collection. So maybe one is best...
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/W24RTDL4VHKNDMLVMRO6CB3V2AT544XP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhance list.index with a comparison function

[Steven D'Aprano]

On Fri, May 22, 2020 at 06:37:11PM -0700, Ethan Furman wrote:
> On 05/22/2020 05:11 PM, David Mertz wrote:
> >On 05/22/2020 04:43 AM, Steven D'Aprano wrote:
> 
> >>i = somelist.index(needle, pred=comparison)
> 
> >Why not just this (by object, not by its index, but that seems simpler):
> >
> >  >>> do_something(next(filter(pred, somelist)))
> >  Something about 55
> >  >>> somelist
> >  [3, 4, 29, 23, 46, 55, 90, 81]
> >  >>> pred
> >  
> 
> Steven, using David's example list, what would `needle` and `comparison` be 
> in your proposal?

Good question! Thank you for pushing me to think about this a little 
harder.

I read David's example as "first item that is divisible by 5" so the 
predicate would be rubbish:

# I can never remember if the needle comes first or second...
somelist.index(0, pred=lambda a, b: a%5 == b)
somelist.index(0, pred=lambda a, b: b%5 == a)

Yuck. So I think I have the wrong mental model here.

Going back to the thread on discuss that inspired the question, I think 
a *key function* is probably better:

for index, blwr in enumerate(blowers):
if blwr.id_ == value:
print(index)
break

# becomes
blowers.index(value, key=operator.attrgetter('id_'))

# or if you prefer
blowers.index(value, key=lambda obj: obj.id_)

although I expect the attrgetter version may be faster, for those who 
care about such things.

With a key function, David's example becomes:

somelist.index(0, key=lambda n: n%5)


Here are a few more possibilities.

# number not divisible by 5
somelist.index(True, key=lambda x: bool(x%5))

# case-insensitive search
somelist.index('spam', key=str.casefold)

# number less than 0
somelist.index(True, key=lambda x: x<0)

# item of length exactly 2
somelist.index(2, key=len)

# identity search
somelist.index(True, key=lambda obj: obj is someobj)

# find a non-NAN
somelist.index(False, key=math.isnan)

# find a particular user
somelist.index('guido', key=lambda user: user.name)

# instance of a class
somelist.index(MyClass, key=type)  # doesn't match subclasses
# does match subclasses
somelist.index(True, key=lambda obj: isinstance(obj, MyClass))

# z-coordinate of a 3D point equals -7
somelist.index(-7, key=lambda point: point[2])

# sum of values in the item equals 99
somelist.index(99, key=sum)

# sum of sales for the month is greater than 1000
somelist.index(True, key=lambda x: sum(x.sales() > 1000))


Obviously not all such key functions are that simple and you may need 
to write a helper function, but the same applies to filter.

Some of these examples are a little artificial, in that you might want 
*all* of the items that match, not just the first. In that case, a 
filter function is probably better. Or you could loop, adjusting the 
start index each time. But if you do want only the first matching value, 
or if you know that there is only one such value, then a key function is 
more obvious than calling next and filter.


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IVPAOSLKVJTBU367CMA6W2YT3BT7JQ5D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhance list.index with a comparison function

[David Mertz]

On Fri, May 22, 2020 at 8:59 PM Steven D'Aprano  wrote:

> > Why not just this (by object, not by its index, but that seems simpler):
> > >>> do_something(next(filter(pred, somelist)))
>
> Sure, that works too. But have you ever written it for real? I haven't.
> And having seen it, I'll probably forget all about it within an hour.
>

Yes, I've written that, or something very similar for real.  More than once
even.  But I do think in functional terms fairly easily.

However, even if you don't do it that way, changing the signature on method
on `list` specifically feels really clunky.  What if I want to do something
to the first item in a tuple that meets a condition?  Or the first from a
deque. Or from a set.  Or even the first matching key from a dictionary. Or
the first match from some third-party collection?

Even if next(filter(...)) isn't how you think, an imperatively written
function can be much more generic. For example (untested):

def process_first(it, pred=lambda _: True, func=lambda _: _, sentinel=None):
for item in it:
if pred(item):
return func(item)
return sentinel

Just stick that somewhere, and it does everything you want and more.  I use
a sentinel rather than raise an exception if nothing matches.  That feels
much more natural to me, but you can change that if such makes more sense
to you.  Likewise, if you want to return the "index", it's a simple enough
change (but what is the index of an unsized iterable?  I mean, of course
you can enumerate() or i+=1... but it might not really be an index.



-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FTKB5JBIJZAWGXIR4MSKVQOTSEPQOZE5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhance list.index with a comparison function

[Ethan Furman]

On 05/22/2020 05:11 PM, David Mertz wrote:

On 05/22/2020 04:43 AM, Steven D'Aprano wrote:



i = somelist.index(needle, pred=comparison)



Why not just this (by object, not by its index, but that seems simpler):

  >>> do_something(next(filter(pred, somelist)))
  Something about 55
  >>> somelist
  [3, 4, 29, 23, 46, 55, 90, 81]
  >>> pred
  


Steven, using David's example list, what would `needle` and `comparison` be in 
your proposal?

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/S2BQMHS3AMCLTCL5XEXXG3NUDD3WROJH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhance list.index with a comparison function

[Steven D'Aprano]

On Fri, May 22, 2020 at 08:11:16PM -0400, David Mertz wrote:
> >
> > After I answered that question, it dawned on me that I have probably
> > written something like that loop, or variations of it, a thousand times:
> >
> > for obj in somelist:
> > if comparison(obj, needle):
> > do_something(obj)
> > break
> >
> 
> Why not just this (by object, not by its index, but that seems simpler):
> 
> >>> do_something(next(filter(pred, somelist)))

Sure, that works too. But have you ever written it for real? I haven't. 
And having seen it, I'll probably forget all about it within an hour.

People who think in functional programming terms will probably love the 
`next(filter(...))` idiom, but not everyone thinks or likes functional 
programming idioms, and there are many people who would reject a patch 
containing that idiom.

Here are some difficulties with the functional version:

1. It requires teaching people about iterators and `next` first.

2. If you want to operate on a sublist, you have to teach them about 
slicing, so you can introduce itertools.islice, rather than just say 
"give the start and end positions as arguments".

3. If you need the index instead of the value, using filter becomes 
downwrite obfuscated:

next(filter(lambda t: pred(t[1]), enumerate(iterable)))[0]

so it becomes a question of having horses for courses.

We have a simple answer to a simple question:

"How do I search a list?"
"Use list.index"

With this proposal, we get:

"How do I search a list by some key?"
"Use list.index with a key function"



-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3J522Z2CG6UQZQVUZEU7DSIYXFHLYC2M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

[Steven D'Aprano]

On Thu, May 21, 2020 at 02:50:00PM +0200, Alex Hall wrote:
> On Thu, May 21, 2020 at 12:27 AM James Lu  wrote:
> 
> > > This is already valid in 3.8, so we should forget about overloading :=
> > > with a second meaning.
> >
> > def func(x=(a:=expression), y=a+1):
> > def func(x:=options):
> >
> > These two syntaxes do not conflict with each other.
> >
> 
> Technically no, but there is potential to confuse beginners.

Forget beginners, I know that will confuse me!

Technically, *yes*, they do conflict.

Ask yourself what the walrus operator `:=` means in Python 3.8, and you 
have a single answer:

- "it's like `=` only it works as an operator".

Now ask yourself what the walrus operator means if James' proposal is 
accepted. The answer becomes:

- "well, that depends on where you see it..."

or:

- "in this context, it's like `=` only it works as an operator"

- "but in this context, it changes the meaning of assignment 
  completely to something very different to how the `=` works 
  everywhere else"

That's certainly a conflict.

This isn't necessarily a deadly objection. For example, the `@` symbol 
in decorator syntax and the `@` symbol in expressions likewise 
conflicts:

@decorate(spam @ eggs)
def aardvark(): ...

but both uses of the `@` symbol well and truly proved their usefulness. 
Whereas in this case:

- the walrus operator is still new and controversial;
- James' proposed `:=` in signatures hasn't proven it's usefulness.


>  What about:
> 
> def func(x=:options):

As a beginner, it took me months to remember to use colons in dict 
displays instead of equals signs, and they are two extremely common 
operations that beginners learn from practically Day 1. Even now, 20 
years later, I still occasionally make that error. (Especially if I'm 
coding late at night.)

You're proposing to take one uncommon operator, `:=`, and flip the order 
of the symbols to `=:`, as a beginner-friendly way to avoid confusion.

As if people don't get confused enough by similar looking and sounding 
things that differ only in slight order. To steal shamelessly from the 
stand-up comedian Brian Regan:


I before E except after C,
or when sounding like A like in NEIGHBOUR and WEIGH,
on weekends and holidays,
and all throughout May,
you'll be wrong no matter what you say.


> or a more realistic example:
> 
> def func(options=:{}):


Add annotations and walrus operator:

def flummox(options:dict=:(a:={x: None})):

and we now have *five* distinct meanings for a colon in one line.


> Personally I think the best way forward on this would be to accept PEP 505.

For the benefit of those reading this who haven't memorised all 
multiple-hundreds of PEPs by ID, that's the proposal to add None-aware 
operators to the language so we can change code like:

if arg is None:
arg = expression

into

arg ??= expression


In this thread, there has been hardly any mention of the times where 
None is a legitimate value for the argument, and so the sentinal needs 
to be something else. I have written this many times:

_MISSING = object()

def func(arg=_MISSING):
if arg is _MISSING:
arg = expression

Null-coalescing operators will help in only a subset of cases where we 
want late-binding of default arguments.


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3NOYNP3SSFQ7APYMQ3EJX2XWJMXHX5CE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhance list.index with a comparison function

[David Mertz]

>
> After I answered that question, it dawned on me that I have probably
>
written something like that loop, or variations of it, a thousand times:
>
> for obj in somelist:
> if comparison(obj, needle):
> do_something(obj)
> break
>

Why not just this (by object, not by its index, but that seems simpler):

>>> do_something(next(filter(pred, somelist)))
Something about 55
>>> somelist
[3, 4, 29, 23, 46, 55, 90, 81]
>>> pred


My style works on general iterables, including infinite ones (that
hopefully eventually have something fulfilling pred()).

-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/P6SZC2PBIEDBHGCAI46YFDD6T4NIA2ZZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Enhance list.index with a comparison function

[Steven D'Aprano]

Have a look at this short thread on discuss:

https://discuss.python.org/t/searching-array-of-data-objects/4251/1

After I answered that question, it dawned on me that I have probably 
written something like that loop, or variations of it, a thousand times:

for obj in somelist:
if comparison(obj, needle):
do_something(obj)
break

and now it's a thousand and one times *wink*

So here's a thought... suppose we gave list.index an optional keyword- 
only comparison function? The typical name for those is "pred", as in 
predicate. Then the above becomes:

try:
i = somelist.index(needle, pred=comparison)
except ValueError:
pass
else:
do_something(somelist[i])

If you know for sure the search item exists, then you can drop the 
try...except...else:

do_something(somelist[somelist.index(needle, pred=comparison)])

If `pred` is missing or None, a standard equality search is performed.

Together with the operator module, this would allow us to perform common 
searches at C speed:

# find the first item less than needle
somelist.index(needle, pred=operator.lt)

We can search a sublist efficiently:

# copies the sublist :-(
for obj in somelist[25:95354]:
...

# save memory by inefficiently walking the entire list :-(
for i, obj in enumerate(somelist):
if i < 25: continue
if i >= 95354: break
...

# avoids both wasting memory and wasting time :-)
i = somelist.index(needle, 25, 95354, pred=comparison)


What do you think?



-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NUR43GEEUX6RBSXK3LQZIAU2FIN5HCQL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python tagged unions based on dataclasses

[Paul Sokolovsky]

Hello,

On Fri, 22 May 2020 21:01:03 +0100
Andrey Cizov  wrote:

> Sorry I forgot to add the URL:
> https://pypi.org/project/tagged-dataclasses/

How does this compare with many other implementations spread over the
interwebs?

As a quick comment, looks verbose comparing to ML ;-).

For comparison, I found an algebraic2.py in ~/my-python-hacks/, no
dataclasses or particular IDEs involved:

--
from collections import namedtuple

# Ideal syntax:
#
#Type = (
#Int(i: int) |
#Str(s: str) |
#Plus(l: Type, r: Type)
#)

def V(name, **args):
return namedtuple(name, args.keys())


class Union:

def __init__(self, *variants):
self.variants = list(variants)

def add(self, *variants):
self.variants.extend(variants)

def __instancecheck__(self, inst):
return isinstance(inst, tuple(self.variants))


def match(val, typ):
if isinstance(val, typ):
# Have to return scalar instead of a tuple due to CPython
# deficiency with := operator
return val[0]
--


Can be used as:

--
UnaryExpr = Union(
Int := V("Int", i=int),
Str := V("Str", s=str),
)

# Recursive variants should be added after initial definition
UnaryExpr.add(
Inc := V("Inc", e=UnaryExpr),
Dec := V("Dec", e=UnaryExpr),
)


def eval(var: UnaryExpr):
if i := match(var, Int):
return i
elif s := match(var, Str):
return s
elif e := match(var, Inc):
return eval(e) + 1
elif e := match(var, Dec):
return eval(e) - 1


expr = Dec(Int(123))
print(isinstance(expr, UnaryExpr))
print(eval(expr))
--

It's sad "UnaryExpr" (instead of e.g. BinaryExpr) because of a known
deficiency of CPython:

---
$ python3.8 -c "( (a, b) := (1, 2) )"
  File "", line 1
SyntaxError: cannot use assignment expressions with tuple
---

Btw, does anybody know a Python implementation which has this bug
fixed?


> 
> On Fri, 22 May 2020 at 20:25, Andrey Cizov  wrote:
> 
> > I have developed a library to introduce tagged unions to python
> > that uses dataclasses to define disjoint members of the tagged
> > union (by defining them as Optional fields). With some additional
> > validation I make sure that only one of the fields is not None.
> >
> > I find that it also fits well with the existing analysis tools and
> > IDEs (e.g. PyCharm) and doesn’t require any additional work in
> > order to be supported.
> >
> > I would like to see some criticism and whether that could
> > potentially be a good candidate for python standard library in the
> > future.

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CVOCMSJYQHTUADG5GEQICVV3X25JLR5R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python tagged unions based on dataclasses

[Andrey Cizov]

Sorry I forgot to add the URL:
https://pypi.org/project/tagged-dataclasses/

On Fri, 22 May 2020 at 20:25, Andrey Cizov  wrote:

> I have developed a library to introduce tagged unions to python that uses
> dataclasses to define disjoint members of the tagged union (by defining
> them as Optional fields). With some additional validation I make sure that
> only one of the fields is not None.
>
> I find that it also fits well with the existing analysis tools and IDEs
> (e.g. PyCharm) and doesn’t require any additional work in order to be
> supported.
>
> I would like to see some criticism and whether that could potentially be a
> good candidate for python standard library in the future.
>
>
> --
> Andrey Cizov
>
-- 
Andrey Cizov
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BDN2GR4LIHIEYJK3GIH2JBEADV73P44B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Steven D'Aprano]

On Thu, May 21, 2020 at 06:48:55PM +0300, Serhiy Storchaka wrote:
> 21.05.20 16:45, Alex Hall пише:
> >≥ instead of >= might be an improvement because that's a 
> >symbol learned in school, but ultimately the student still needs to 
> >learn what `>=` means as it will be used most of the time.
> 
> But in my school I learned ⩾, not ≥. It was used in USSR and I believe 
> in other European countries (maybe it is French or Germany tradition?).

As far as I am aware, there is no mathematical difference between the 
two greater-than-or-equal operators ⩾ and ≥ it is a purely stylistic 
issue, just as some fonts use two lines in dollar signs and some only 
one. I don't know why Unicode gives them two different code points, but 
if I were a betting man, I would put money on it being because some 
legacy character set provided them both.

(One of the motivations of Unicode is to allow the round-tripping from 
every common legacy charset without loss.)

> If Python will become accepting ≥ as an alias of >=, I insist that it 
> should accept also ⩾. And ⊃, because it is the symbol used for superset 
> relations for sets (currently written as >= in Python). 

An annoying thing about superset and subset operators is that 
mathematicians don't agree on whether the superset symbol ⊃ is strict or 
not. This is why we also have unambiguous symbols ⊇ (superset-or-equal) 
and ⊋ (strict superset not equal).


> And maybe other 
> national or domain specific mathematical symbols. Imagine confusion when 
> >=, ≥, ⩾ and ⊃ are occurred in the same program.

Imagine the confusion if somebody had variables spam, Spam, sPAM, SPam, 
sPAm. Or worse, SPΑM, SPАM and SPAM.

*wink*

Let's not worry too much encouraging people's bad habits. People can 
write obfuscated code in any language. I am sure that before this is a 
problem, linters and code formatters like black will keep it under 
control.


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5727HGSASTJSUYSQMQ3H3UAXY4R57HMV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

[Alex Hall]

On Thu, May 21, 2020 at 2:50 PM Alex Hall  wrote:

> Personally I think the best way forward on this would be to accept PEP
> 505. It wouldn't solve this particular problem in the most concise way but
> it would be pretty good and would be more broadly useful.
>

Having thought about this problem a bit more, I'm now less sure of this
stance. I think there's a decent benefit to being able to specify a
late/lazy default in the signature that goes beyond being concise, and I
don't think anyone has mentioned it.

Signatures are an important source of information beyond their obvious
essential need. They're essentially documentation - often the first bit of
documentation that human readers look at when looking up a function, and
often the only documentation that automated tools can use. And defaults are
an important part of that documentation.

Take a look at the official documentation for these callables and their
parameters which default to None:

https://docs.python.org/3/library/collections.html#collections.ChainMap.new_child
https://docs.python.org/3/library/logging.handlers.html#logging.StreamHandler
https://docs.python.org/3/library/json.html#json.dump (in particular the
`cls` parameter)

(we may not be able to change these signatures due to compatibility, but
they should still demonstrate the point)

In all cases it's not immediately clear what the actual default value is,
or even what kind of object is meant to be passed to that parameter. You
simply have to read through the documentation, which is quite verbose and
not that easy to skim through. That's not the fault of the documentation -
it could perhaps be improved, but it's not easy. It's just English (or any
human language) is not very efficient here. Imagine how much easier it
would be to mentally parse the documentation if the signatures were:

```
ChainMap.new_child(m={})
StreamHandler(stream=sys.stderr)
json.dump(..., cls=JSONEncoder, ...)
```

In the case of json.dump, I don't know why that isn't already the
signature, does anyone know? In the other cases there are good reasons
those can't be the actual signatures, so imagine instead the ideal syntax
for late binding. The point is that the signature now conveys the default
as well as the type of the parameter, and there's less need to read through
documentation. Conversely you can probably also write less documentation,
or remove some existing clutter in an upgrade.

There's a similar benefit if the author hasn't provided any documentation
at all - it's not nice to have to read through the source of a function
looking for `if m is None: m = {}`.

The signature and its defaults are also helpful when you're not looking at
documentation or source code at all. For example, PyCharm lets me press a
key combination to see the signature of the current function, highlighting
the parameter the caret is on. Here is what it looks like for `json.dumps`:

[image: Screen Shot 2020-05-22 at 21.32.21.png]

That's not very helpful! Here's the same for logging.StreamHandler:

[image: Screen Shot 2020-05-22 at 21.33.08.png]

That's sort of better, but mentally parsing `Optional[IO[str]]=...` might
just slow me down more than it helps.

PyCharm also uses defaults for rudimentary type checking. For example, if
you set `{}` as a default value, it assumes that parameter must be a dict,
and warns you if you enter something else:

[image: Screen Shot 2020-05-22 at 21.35.07.png]

Of course it also warns that the parameter has a mutable default, which
this proposal could solve.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6TGESU6AQSDFLIV2UBHAB4E2NVVREVPA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Python tagged unions based on dataclasses

[Andrey Cizov]

I have developed a library to introduce tagged unions to python that uses
dataclasses to define disjoint members of the tagged union (by defining
them as Optional fields). With some additional validation I make sure that
only one of the fields is not None.

I find that it also fits well with the existing analysis tools and IDEs
(e.g. PyCharm) and doesn’t require any additional work in order to be
supported.

I would like to see some criticism and whether that could potentially be a
good candidate for python standard library in the future.


-- 
Andrey Cizov
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IGSGFGEANPEAFZ53EQRTT7LBPPOII3WR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: How to propose a change with tests where the failing test case (current behaviour) is bad or dangerous

[Rob Cliffe via Python-ideas]

On 21/05/2020 14:50, Steve Barnes wrote:

The issue is simple and simple enough for a beginner to fall foul of - test 
procedure:
Change directory to any directory with files in totally a few 10s of megs 
(ideally but it doesn't matter much).
python -m zipfile -c my_zipfile.zip .

Wait a few minutes and press control-C then do a directory - you will find that 
my_zipfile.zip is huge (much bigger than the total of the files in the original 
directory). The same applies to tarfile.

If you fail to hit control-C soon enough (how long depends on the spare space 
on the current drive) it will crash when it runs out of disk space, possibly, 
on some systems, requiring a format and re-install of the OS.

The cause of the problem is that when zipfile &/or tarfile is archiving to a 
file in the current directory it tries to add the target file to the input list and 
you have an Ouroboros situation. The fix is also simple - exclude the target file 
from the permitted inputs.

Am I missing something here?
IIUC zipfile.py tries to add the zipfile it's creating to the zipfile 
it's creating.

That's a bug, pure and simple (and a dangerous one).
It should be rewritten to build a list of the files it's going to zip up 
(before creating its own zipfile), then work from that list.

Surely it can't be that hard?


I have seen this happen in the wild, I do know that python is not the only 
archiving tool that suffers from this problem but that seems to me to be no 
reason not to address this.

If write were patched to simply count the bytes but not write the file then the 
problem would not occur so I guess that it would need to be patched in a 
transparent manner.

Steve Barnes

-Original Message-
From: remi.lape...@henki.fr 
Sent: 21 May 2020 13:56
To: python-ideas@python.org
Subject: [Python-ideas] Re: How to propose a change with tests where the 
failing test case (current behaviour) is bad or dangerous

If the file is supposed to be small, would patching write() in the test to 
accumulate the number of bytes written and fail the test when it goes over what 
it's supposed to be possible?

What is the issue?
___
Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an 
email to python-ideas-le...@python.org 
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ORPDN4CITJZSO246HWCKNZUKA4IT3QWC/
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OT5M4U4RPJAU7HXXFONGTL442OCHGSXY/
Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SL2TWGUUYCDNEPIXLR3GK6AOOD2ZAAUY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Rhodri James]

On 22/05/2020 18:21, Mike Miller wrote:
More importantly, does it help readability?  I think it does, however 
not strongly.  I'm perhaps +0.5 on a few of these characters.  Word 
processors do upgrades to hyphens, for example, to make the resulting 
doc more readable.  Is that kind of thing useful for Python?


Generally speaking, no.  Editors that do things for you behind your back 
are an open invitation to bugs.  I find that for most word processing 
that I do, I have to turn off the automatic 
translation/correction/whatever to prevent them from incorrectly 
rewriting my input.  Prettifying code so that it no longer runs when you 
cut and paste is one example; more often I find they mangle the 
capitalisation of company names, product ID and so forth.  I would hate 
to find an editor starting to do similar things for me.  Sometimes even 
basic things like "electric modes" (auto-indentation after you hit 
RETURN) can make more work for you!


--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SICQPMANE6YBDRAHVYGIWF4KXQZ7U4ZF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Mike Miller]

On 2020-05-22 05:57, Joao S. O. Bueno wrote:

render . However, that does not mean it will render ok
as a single-cell character in a mono-spaced font - as the
character "east asian width" property is marked as "A" (Ambiguous),



Yes, though I'm sure no one is seriously proposing using wide, or combining 
chars, or other obscure things.  Just some useful symbols from around the 0x2000 
range of the BMP, which are widely/universally supported by now.  To be honest, 
keyboard entry is the least interesting aspect of this.


To reiterate, we found a zero-ongoing-effort entry method, typing and leaving " 
-> " in the source, and "upgrading it" to " → " with a formatter or other tool 
when desired.  That's assuming you already have tools set up.  I recommend them, 
but they would not be required obviously and neither would the upgraded 
character for compatibility reasons.


More importantly, does it help readability?  I think it does, however not 
strongly.  I'm perhaps +0.5 on a few of these characters.  Word processors do 
upgrades to hyphens, for example, to make the resulting doc more readable.  Is 
that kind of thing useful for Python?


-Mike
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/L2GR7SZZGCTVN2JTXBPGAJ3AMCTPC6FY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Ricky Teachey]

On Fri, May 22, 2020 at 11:21 AM David Mertz  wrote:


> The main point of this, is that the code is still just plain ASCII, it
> just happens to look "fancier."  It requires no plugins, and it does not
> require a JetBrains IDE or editor.  I haven't tried every editor, but I
> believe that most or all that use GUI fonts will work fine.  Not sure about
> ligatures and Linux terminal, someone can try it.
>

The ability to pretty-ify code in this way is inspiring; I'm going to have
to look into it.

There could be many other IMO more useful/helpful pretty-fication ideas out
there that could not be accomplished with unicode, or simple "replace these
symbols with another one" configurations.

Couple of examples:

1. I've often thought it would be nice if the parameter type-hints sort of
floated underneath (or maybe above? underneath makes more sense to me) the
parameter names, rather than using the colon at all. Or, perhaps using
colors to specify types - Indigo for ints, scarlet for strings, fuchsia for
floats, perhaps italics for optionals, that sort of thing.

2. Another really nice improvement, so that I could share raw,
copy-and-pasted pretty-ified code with my professional engineering
coworkers (as a set of engineering calculations), would be for the editor
to detect mathematical equations and display them that way. Like:

from scipy.integrate import quad

def f(x, i, j, a, b):
return quad(a*x**2 + b , 0, 1, args=(a,b))

...would be displayed *automatically* (without having to muck about with
sympy), and able to be copied, as:

[image: image.png]

( latex code: $f=\int_{i}^{j} a x^2 + b \,dx$ )

*BACK ON TOPIC:*

The point of giving the examples above is not to rabbit trail, but to agree
with others who have basically said going down this particular road--
putting a lot of effort into including fancy unicode symbols as part of the
syntax-- would be a mistake.

IMO, a big reason it would be a mistake is, it doesn't bring *ENOUGH* to
the table for making things look nicer-- there is so much more that could
be done to make reading python an even more pleasurable experience beyond
using unicode symbols. And not only that, make it useful to more people
beyond the circle of those who actually even *KNOW* they are reading
"python" (as opposed to just English pseudocode describing
mathematical/algorithmic processes).

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/J7NDPLZKA4JDXVAEMCFHII556MWJP63N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[David Mertz]

As is... my editor looks like this.  I don't type all those special things,
except once in a configuration file.  But the "prettification" is handled
transparently when I type some ASCII sequences.
[image: Python-arrow.png]



> that’s nice ! it’s a real shame though, and a bit of a waste honestly,
> that everybody needs to cook their own brew of an editor to get there
> and primarily all I’m trying to say is that, one day, this will be a legal
> piece of code, so that we can share and enjoy exactly like this
> instead of in poor work-it-out-yourself ascii
>

The first screenshot (of completely pointless code I just typed to use a
few symbols or sequences) used vim conceal plugin; also my particular
configuration of what to substitute visually on screen.  That approach lets
entire patterns get replaced by... whatever you want.  E.g. I replace
`set()` with the empty-set symbol, but no one else is required to by the
plugin if they don't want to (or the script Z/R for int/float, likewise).

For comparison, I changed my system text editor to use JetBrains Mono
Medium.  The editor is called "Text Editor" on my system, but it's a
rebranded gEdit, which is a pretty reasonable code editor.  Someone else in
the thread pointed to that font which uses ligatures to make composed
characters.  So it's not a substitution but simply another way of drawing
some letter pairs.  The result is in the attached screenshot.

This approach is somewhat less flexible in that it gets exactly those
ligatures that JetBrains decides you want.  In concept, there is no reason
this couldn't create a 'float' ligature that renders as a script R, for
example.  But that is not a combo JetBrains decided to use.

The main point of this, is that the code is still just plain ASCII, it just
happens to look "fancier."  It requires no plugins, and it does not require
a JetBrains IDE or editor.  I haven't tried every editor, but I believe
that most or all that use GUI fonts will work fine.  Not sure about
ligatures and Linux terminal, someone can try it.



-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/25AQCLEWJXK6IQ23KSIKQW3E5IUOGP43/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Chris Angelico]

On Fri, May 22, 2020 at 11:02 PM Joao S. O. Bueno  wrote:
> I am recording a video series trying to present Python programing to
> absolute beginners - and to keep things timely, the ambiguity between
> two valid quote types is already a _pain_  - which I simply try to avoid
> by making consistent use of just one quote type. But after a 4 hour
> crash course,
> no one that is not already familiar with coding, could come up comfortable 
> with
> using both ' or " interchangibly unless I spend 30 minutes focusing ont that.

Seriously? In primary school English class I learned that you can nest
quotations by using different quote characters. Maybe we need to
consider that first-grade English (or whatever your native language
is) should be considered a prerequisite for coding, and just teach
those kinds of concepts (including words like "singular" and "plural",
since they're so helpful for diagnosing bugs).

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6NUXGP76X5BODZ6CTQO2XNDTVGFHOMV7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Dan Sommers]

On Friday, May 22, 2020, at  8:28, Steven D'Aprano wrote:

> On Thu, May 21, 2020 at 09:43:33AM -0400, Dan Sommers wrote:
>
>> I had a customer who was old enough to
>> use upper case letter O for zero and lower case letter l for 1 because
>> she was old enough to have learned to type before typewriters had number
>> keys; that made a real mess of sorting street addresses.

> https://historythings.com/life-changing-invention-typewriters/

I can see 0, 2, 3, 4, 5, and 6 clearly.  I can't see a 1, although it
appears that the key between the 0 and the Q is missing its label.

> https://historythings.com/wp-content/uploads/2016/07/006136-l.jpg
> 
> The photo isn't clear enough to see the keys, but there are 44 of
> them. Since the Sholdes typewriter didn't have lowercase letters, it's
> hard to imagine what the remaining keys after the uppercase letters
> and punctuation marks were if they weren't digits.

The photo is not clear, but I can convince myself that the keys on the
top row start at 2 and run through 9 and 0.  Still no 1.

> And this 1903 Olympia typewriter clearly has digits:
>
> https://historythings.com/wp-content/uploads/2016/07/SAM_2381_clipped_rev_1.png

Still no 1.

> It is certainly true that many people of a certain age used to
> interchange 0 and O, and 1 and l, but I don't think it had anything to
> do with learning to type on typewriters without digits. What did they
> use when they needed the digits 2 through 9?

Okay, "before typewriters had number keys" is obviously wrong.  Those
pictures support "before typewriters had 1 keys."

-- 
“Atoms are not things.” – Werner Heisenberg
Dan Sommers, http://www.tombstonezero.net/dan
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/A3VY7HYW6XOJT4XOGHETRMOZALGSXSC2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Joao S. O. Bueno]

On Thu, 21 May 2020 at 18:15, Mike Miller  wrote:
>
>
> On 2020-05-21 05:48, Joao S. O. Bueno wrote:
> > Input _is_ hard or rare. Deal with it.
> > Even the font is not uniformily configured across systems, and  a glyph  one
> > does see here may not show properly on the terminal, or other
>
>
> Maybe long ago.  My terminals support even color emoji, have for years, and 
> are
> all free.
>

If you format all your computers from a single image, maybe.

My pet project over the last year is a unicode art library,
I use a Ubuntu 2018 and a Fedora system daily  -
on my personal machine, which is the Fedora, I've installed
all available font packages an their kitchen sink.

Still, emoji support varies wildly across terminal programs
and even across the same terminal program in Ubuntu and
on Fedora.

Although, yes, it is likely that "older" glyphs like unicode
mathematic symbols will be present in all of then and
render . However, that does not mean it will render ok
as a single-cell character in a mono-spaced font - as the
character "east asian width" property is marked as "A" (Ambiguous),
and may vary according to the installed font - even Qt5, perhaps
the most sophisticated windowing toolkit available in the World,
is severely bugged when displaying non single-width characters
in a monospaced cell character environment such as
coding space. (Of course, it may be that native Windows character
and widget engines or Mac OS's are better in this particular
requisite)



> The only thing I've seen recently that doesn't is the Linux console, which I 
> use
> rarely for admin tasks.  (Oddly enough, it does handle right arrow properly.)
> fbterm is an option there for those wanting more.
>
> Even Windows 10 has gotten in on the act terminal-wise.  If you're still on XP
> or 7, it's way past time to upgrade.
>

I consider this thread to be moot at this time - I am just answering this
e-mail because you answered me directly - but I had seem no
strong support, I had seem you not answering direct questioning
about how this will make things harder to learn and use
but for writting down your own rationalizations on it.

I'd suggest you'd just pause for a bit, and read carefully some of the
other e-mails, if mine, focused mainly technical infeasibility
of even typing or displaying that character, and consider these
questionings for real - not with the ready made answers you have
ready in your mind.

I am recording a video series trying to present Python programing to
absolute beginners - and to keep things timely, the ambiguity between
two valid quote types is already a _pain_  - which I simply try to avoid
by making consistent use of just one quote type. But after a 4 hour
crash course,
no one that is not already familiar with coding, could come up comfortable with
using both ' or " interchangibly unless I spend 30 minutes focusing ont that.
> -Mike
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/IMQFQ7JLOMJ2PE3MLPEHYTTWNUSH3HBQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2544WLVWARH23QSLRMX2USP25RCXAOOE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

[Rhodri James]

On 22/05/2020 02:10, Tiago Illipronti Girardi wrote:

Is `?=` an operator? One could define `a ?= b` as `if a is None: a = b`
(which is similar to make's operator, for example).


PEP 505 (https://www.python.org/dev/peps/pep-0505/) prefers "??=". 
That's a discussion that comes back now and again, but doesn't seem to 
get much traction one way or another.


--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3DPYXLZ7HOZMEWN6WBOENBQSFZDUPHJN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Steven D'Aprano]

On Thu, May 21, 2020 at 09:43:33AM -0400, Dan Sommers wrote:

> I had a customer who was old enough to
> use upper case letter O for zero and lower case letter l for 1 because
> she was old enough to have learned to type before typewriters had number
> keys; that made a real mess of sorting street addresses.

How old was your customer?

The Hansen Writing Ball, first commercially sold in 1870, had digit 
keys:

https://historythings.com/life-changing-invention-typewriters/

The first recognisable typewriter, the Sholdes and Glidden Type-writer 
(note the hyphen!), was sold in 1864. Here's a photo of one:

https://historythings.com/wp-content/uploads/2016/07/006136-l.jpg

The photo isn't clear enough to see the keys, but there are 44 of 
them. Since the Sholdes typewriter didn't have lowercase letters, it's 
hard to imagine what the remaining keys after the uppercase letters 
and punctuation marks were if they weren't digits.

(44 keys would nicely match 26 letters, 10 digits, space and seven 
punctuation marks.)

And this 1903 Olympia typewriter clearly has digits:

https://historythings.com/wp-content/uploads/2016/07/SAM_2381_clipped_rev_1.png

It is certainly true that many people of a certain age used to 
interchange 0 and O, and 1 and l, but I don't think it had anything to 
do with learning to type on typewriters without digits. What did they 
use when they needed the digits 2 through 9?


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/T3D76PIO7VE2FSKEXYHORWGWFDY544MR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

[Tiago Illipronti Girardi]

Is `?=` an operator? One could define `a ?= b` as `if a is None: a = b`
(which is similar to make's operator, for example). Compare:

def func(arg, option=None):
option ?= expr
#impl

instead of:

def func(arg, option=None):
if option is None:
option = expr
#impl

def func(arg, option=None):
if option is None: option = expr
#impl

def func(arg, option=None):
option = expr if option is None else option
#impl

def func(arg, option=None):
option = option if option is not None else expr
#impl

or the proposed:

def func(arg, option?=expr):
#impl

One could argue that the OP proposal is cleaner, but it adds *another* special
notation on function definition.

On performance, this would have tobe evaluated most likely upon entering the 
call.
With the `if` guards or a hypothetical `?=` assignment, the programmer can 
better
control execution (other arguments and/or options may render the test 
irrelevant).

The great disadvantage of the `if` guard is a line of screen and an identation 
level,
(which reminds me of PEP 572 rationale).

I don't really like this `?=` assignment aesthetically, but I have written code 
that
would look cleaner with it (though beauty is the eye of the beholder).

Implementing only this operator would be at least simpler than both OP proposal
and full PEP 505 (see also Neil Girdhar post above).
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZJIEQAS3MG7OZG3VN5OTU27GCEGGLAO7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: How to propose a change with tests where the failing test case (current behaviour) is bad or dangerous

[Steven D'Aprano]

On Fri, May 22, 2020 at 08:09:29AM +, Steve Barnes wrote:

> Unfortunately we have no control over where the tests may be run – if 
> run on Windows from the C: drive it could potentially brick the entire 
> machine, (which of course some people might consider a bonus of 
> course).

I'm rather shocked to learn that (allegedly?) you can brick modern 
Windows by filling the drive up. If this was Windows 95 I might believe 
it, but Windows 7 or 10? Have you confirmed this or is it just a guess?

As for strategies for the test... you could write the test to skip on 
Windows. Using `unittest`:

@unittest.skipif(os.name == 'nt', 'dangerous to run on Windows')

Does Windows have the capacity to create a file system on the fly and 
then mount it, as we can do in Linux?

# Untested.
dd if=/dev/zero of=/tmp/disk count=2048
mkfs.ntfs -v Untitled /tmp/disk
sudo mount -t ntfs /tmp/disk /mnt/

In pseudo-code:

- create a temporary file of 2048 bytes;
- write a NTFS file system in that file;
- mount that file system somewhere so it is visible;

So have the test create a new file system on the fly, cd into that file 
system, run the test proper, and if it fills up, no harm done.

If you cannot create a file system on the fly, perhaps you can prepare 
one before hand, manually, as part of the test requirements, and refuse 
to run if that scratch (pseudo)disk doesn't exist.


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SSIJ3YLGQHFBZZRKECQC2JM42PMKYAPN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Bernardo Sulzbach]

>
> I believe I speak for a significant majority of professional programmers
> when I say that eye-candy like this adds no value to the language for me.
> It gives me no new capabilities, I don't see it making me more productive,
> and we have syntax that works quite well already.
>

This speaks for me. Not only such an addition requires substantial support,
which it doesn't seem to be gathering, it requires some quantitative
evidence that this is better than what we already have in some meaningful
aspect.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IYT344CYIOOI7FJAOERTE5ID5EYEJFMY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: How to propose a change with tests where the failing test case (current behaviour) is bad or dangerous

[Steve Barnes]

From: Guido van Rossum 
Sent: 21 May 2020 16:59
To: Steve Barnes 
Cc: remi.lape...@henki.fr; python-ideas@python.org
Subject: Re: [Python-ideas] Re: How to propose a change with tests where the 
failing test case (current behaviour) is bad or dangerous

Hi Steve,

Have you considered and rejected filing a bug on 
bugs.python.org?

Or are you specifically concerned about how to write a test for this behavior 
that doesn't fill up the disk when the bug is present? On Unixoid systems 
there's a resource limit you can set to limit disk space IIRC (e.g. on my Mac, 
`ulimit -a` shows various limits including file size).

Solving this by patching write() seems somewhat complex because you'd really 
have to patch open() to return an io.IO subclass that has a patched write() 
method. But I'm sure it can be done in the context of a specific test. I 
wouldn't try patching it for *all* tests though -- there are many tests that 
might fail due to such a change. It also wouldn't help for file operations made 
directly from C code.

--Guido


[Steve Barnes]
Unfortunately we have no control over where the tests may be run – if run on 
Windows from the C: drive it could potentially brick the entire machine, (which 
of course some people might consider a bonus of course).
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YKJXUXLH4HGNXFVHYRSNPLIXQZUEIF6P/
Code of Conduct: http://python.org/psf/codeofconduct/