Re: [Python-ideas] unittest: 0 tests pass means failure of the testsuite

2019-03-06 Thread Matěj Cepl
Nathaniel Smith píše v St 06. 03. 2019 v 19:21 -0800: > You probably want to file a bug on the setuptools tracker: > https://github.com/pypa/setuptools > > It's maintained by different people than Python itself, and is > responsible for defining 'setup.py test'. I think we have to bugs (or defici

Re: [Python-ideas] unittest: 0 tests pass means failure of the testsuite

2019-03-06 Thread Serhiy Storchaka
06.03.19 22:12, Matěj Cepl пише: I am a lead maintainer of Python packages in OpenSUSE and I can see the pattern of many packagers adding blindly python setup.py test to %check section of our SPEC file. The problem is that if the package doesn't use unittest (it actually uses nose, pytest

Re: [Python-ideas] unittest: 0 tests pass means failure of the testsuite

2019-03-06 Thread Nathaniel Smith
On Wed, Mar 6, 2019 at 12:13 PM Matěj Cepl wrote: > > Hi, > > I am a lead maintainer of Python packages in OpenSUSE and I can > see the pattern of many packagers adding blindly > > python setup.py test > > to %check section of our SPEC file. The problem is that if the > package doesn't use uni

Re: [Python-ideas] Allow creation of polymorph function (async function executable syncronously)

2019-03-06 Thread Wes Turner
Here's syncer/syncer.py: https://github.com/miyakogi/syncer/blob/master/syncer.py I think the singledispatch is pretty cool. ```python #!/usr/bin/env python3 # -*- coding: utf-8 -*- import sys from functools import singledispatch, wraps import asyncio import inspect import types from typing impo

Re: [Python-ideas] unittest: 0 tests pass means failure of the testsuite

2019-03-06 Thread Terry Reedy
On 3/6/2019 3:12 PM, Matěj Cepl wrote: Hi, I am a lead maintainer of Python packages in OpenSUSE and I can see the pattern of many packagers adding blindly python setup.py test to %check section of our SPEC file. I am not familiar with setup.py, so I don't know how this affects the pre

Re: [Python-ideas] Allow creation of polymorph function (async function executable syncronously)

2019-03-06 Thread Nathaniel Smith
On Wed, Mar 6, 2019 at 4:37 PM pylang wrote: >> def maybe_async(fn): >> @functools.wraps(fn) >> def wrapper(*args, **kwargs): >> coro = fn(*args, **kwargs) >> if asyncio.get_running_loop() is not None: >> return coro >> else: >> return await

Re: [Python-ideas] Allow creation of polymorph function (async function executable syncronously)

2019-03-06 Thread pylang
Jorropo states: Polymorph function work exacly like async function BUT they assure of the > ability to execute syncronously. - sic > Async functions can call sync functions, but not vice versa. Consider a third party solution - trio , that allows sync functio

Re: [Python-ideas] PEP: Dict addition and subtraction

2019-03-06 Thread Chris Angelico
On Thu, Mar 7, 2019 at 10:52 AM Josh Rosenberg wrote: > The closest I can come to a thorough definition of what + does in Python (and > most languages) right now is that: > > 1. Returns a new thing of the same type (or a shared coerced type for number > weirdness) > 2. That combines the informat

Re: [Python-ideas] PEP: Dict addition and subtraction

2019-03-06 Thread Josh Rosenberg
On Wed, Mar 6, 2019 at 10:31 PM Greg Ewing wrote: > > You might as well say that using the + operator on vectors is > nonsense, because len(v1 + v2) is not in general equal to > len(v1) + len(v2). > > Yet mathematicians are quite happy to talk about "addition" > of vectors. > > Vectors addition i

Re: [Python-ideas] PEP: Dict addition and subtraction

2019-03-06 Thread Greg Ewing
Ka-Ping Yee wrote: len(dict1 + dict2) does not equal len(dict1) + len(dict2), so using the + operator is nonsense. You might as well say that using the + operator on vectors is nonsense, because len(v1 + v2) is not in general equal to len(v1) + len(v2). Yet mathematicians are quite happy to ta

Re: [Python-ideas] unittest: 0 tests pass means failure of the testsuite

2019-03-06 Thread Guido van Rossum
I would just file a bug and add a PR. On Wed, Mar 6, 2019 at 12:14 PM Matěj Cepl wrote: > Hi, > > I am a lead maintainer of Python packages in OpenSUSE and I can > see the pattern of many packagers adding blindly > > python setup.py test > > to %check section of our SPEC file. The problem is

Re: [Python-ideas] dict literal allows duplicate keys

2019-03-06 Thread Jonathan Fine
Hi Guido You wrote: > Would it shut down this particular subthread if (as the language's designer, > if not its BDFL) I declared that this was an explicit design decision that I > made nearly 30 years ago? I should perhaps blog about the background of this > decision, but it was quite a consci

Re: [Python-ideas] unittest: 0 tests pass means failure of the testsuite

2019-03-06 Thread MRAB
On 2019-03-06 20:12, Matěj Cepl wrote: Hi, I am a lead maintainer of Python packages in OpenSUSE and I can see the pattern of many packagers adding blindly python setup.py test to %check section of our SPEC file. The problem is that if the package doesn't use unittest (it actually uses no

[Python-ideas] unittest: 0 tests pass means failure of the testsuite

2019-03-06 Thread Matěj Cepl
Hi, I am a lead maintainer of Python packages in OpenSUSE and I can see the pattern of many packagers adding blindly python setup.py test to %check section of our SPEC file. The problem is that if the package doesn't use unittest (it actually uses nose, pytest or something), it could lead to

Re: [Python-ideas] OT: about hasty posts from phones

2019-03-06 Thread Abdur-Rahmaan Janhangeer
Sorry about adding a few words here, i know you are all more 'advanced' programmers than me. I just wanted to ask the list to keep threads informative. Just today i decided to take the bulls by the horn and read the add dictionaries by using the + operator. Midway, i asked myself if i was getting

Re: [Python-ideas] dict literal allows duplicate keys

2019-03-06 Thread Guido van Rossum
Would it shut down this particular subthread if (as the language's designer, if not its BDFL) I declared that this was an explicit design decision that I made nearly 30 years ago? I should perhaps blog about the background of this decision, but it was quite a conscious one. There really is no point

[Python-ideas] OT: about hasty posts from phones

2019-03-06 Thread Guido van Rossum
On Wed, Mar 6, 2019 at 9:12 AM Christopher Barker wrote: > [...] > Sorry — on a phone, kinda hard to check now. > A point of order: if you're away from a real keyboard/screen, maybe it's better to wait. The conversation isn't real-time, and you don't win points by answering first. We could a

Re: [Python-ideas] PEP: Dict addition and subtraction

2019-03-06 Thread Michael Lee
> > If we use this "literally concat" metaphor, I still think set should have > `+` as alias to `|` for consistency. > I agree. I think "|" keeps commutativity only because it's minor than `+`. > I suppose that's true, fair point. I guess I would be ok with | no longer always implying commutati

Re: [Python-ideas] OT: Dictionary display documentation

2019-03-06 Thread Rhodri James
On 06/03/2019 18:12, Rhodri James wrote: On 06/03/2019 17:43, Jonathan Fine wrote: Indeed. Although off-topic, I think {'a': 0, 'a': 1} == {'a': 1} True is much better than "This means that you can specify the same key multiple times in the key/datum list, and the final dictionary’s value fo

[Python-ideas] OT:

2019-03-06 Thread Rhodri James
On 06/03/2019 17:43, Jonathan Fine wrote: Indeed. Although off-topic, I think {'a': 0, 'a': 1} == {'a': 1} True is much better than "This means that you can specify the same key multiple times in the key/datum list, and the final dictionary’s value for that key will be the last one given."

Re: [Python-ideas] dict literal allows duplicate keys

2019-03-06 Thread Jonathan Fine
SUMMARY: Off-thread-topic comment on examples and words in documentation. Inada Naoki quoted (from doc.python ref [6] in my original post): > > If a comma-separated sequence of key/datum pairs is given, they are > > evaluated from left to right to define the entries of the dictionary: each > >

Re: [Python-ideas] dict literal allows duplicate keys

2019-03-06 Thread Inada Naoki
https://docs.python.org/3/reference/expressions.html#dictionary-displays > If a comma-separated sequence of key/datum pairs is given, they are evaluated > from left to right to define the entries of the dictionary: each key object > is used as a key into the dictionary to store the corresponding

Re: [Python-ideas] PEP: Dict addition and subtraction

2019-03-06 Thread Jonathan Fine
I wrote: > I wonder, is this behaviour of {'a': 0, 'a': 1} documented (or tested) > anywhere? I've answered my own question here: [Python-ideas] dict literal allows duplicate keys https://mail.python.org/pipermail/python-ideas/2019-March/055717.html Finally, Christopher Barker wrote: > Yes, and

Re: [Python-ideas] Suggestions: dict.flow_update and dict.__add__

2019-03-06 Thread Christopher Barker
Do go read the recent thread about this - there is a lot there! Titled something like “fluent programming” Sorry — on a phone, kinda hard to check now. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Developme

[Python-ideas] dict literal allows duplicate keys

2019-03-06 Thread Jonathan Fine
SUMMARY: The outcome of a search for: python dict literal duplicate keys. No conclusions (so far). BACKGROUND In the thread "PEP: Dict addition and subtraction" I wrote > >>> {'a': 0, 'a': 1} > {'a': 1} > I wonder, is this behaviour of {'a': 0, 'a': 1} documented (or tested) > anywhere

Re: [Python-ideas] PEP: Dict addition and subtraction

2019-03-06 Thread Inada Naoki
On Wed, Mar 6, 2019 at 10:59 PM Michael Lee wrote: > > I think the behavior proposed in the PEP makes sense whether you think of "+" > as meaning "concatenation" or "merging". > > If your instinct is to assume "+" means "concatenation", then it would be > natural to assume that {"a": 1, "b": 2}

Re: [Python-ideas] Suggestions: dict.flow_update and dict.__add__

2019-03-06 Thread Brice Parent
Why not simply propose an external lib with FluentDict and other Fluent[Anything] already packaged? I don't know if I'd use it personnally, but it definitely could have some users. Le 05/03/2019 à 09:48, Jonathan Fine a écrit : SUMMARY Instead of using dict + dict, perhaps use dict.flow_updat

Re: [Python-ideas] PEP: Dict addition and subtraction

2019-03-06 Thread Jonathan Fine
Michael Lee wrote: > If your instinct is to assume "+" means "concatenation", then it would be > natural to assume that {"a": 1, "b": 2} + {"c": 3, "b": 4} would be identical > to {"a": 1, "b": 2, "c": 3, "b": 4} -- literally concat the key-value pairs > into a new dict. > But of course, you c

Re: [Python-ideas] PEP: Dict addition and subtraction

2019-03-06 Thread Chris Angelico
On Thu, Mar 7, 2019 at 12:59 AM Michael Lee wrote: > If your instinct is to assume "+" means "concatenation", then it would be > natural to assume that {"a": 1, "b": 2} + {"c": 3, "b": 4} would be identical > to {"a": 1, "b": 2, "c": 3, "b": 4} -- literally concat the key-value pairs > into a n

Re: [Python-ideas] PEP: Dict addition and subtraction

2019-03-06 Thread Michael Lee
> > I strongly agree with Ka-Ping. '+' is intuitively concatenation not > merging. The behavior is overwhelmingly more similar to the '|' operator in > sets (whether or not a user happens to know the historical implementation > overlap). I think the behavior proposed in the PEP makes sense whethe

Re: [Python-ideas] PEP: Dict addition and subtraction

2019-03-06 Thread Brice Parent
Le 06/03/2019 à 13:53, Chris Angelico a écrit : On Wed, Mar 6, 2019 at 11:18 PM Brice Parent wrote: The major implication to such a modification of the Dict.update method, is that when you're using it with keyword arguments (by opposition to passing another dict/iterable as positional), you'r

Re: [Python-ideas] PEP: Dict addition and subtraction

2019-03-06 Thread Chris Angelico
On Wed, Mar 6, 2019 at 11:18 PM Brice Parent wrote: > The major implication to such a > modification of the Dict.update method, is that when you're using it > with keyword arguments (by opposition to passing another dict/iterable > as positional), you're making a small non-backward compatible chan

Re: [Python-ideas] PEP: Dict addition and subtraction

2019-03-06 Thread David Mertz
I strongly agree with Ka-Ping. '+' is intuitively concatenation not merging. The behavior is overwhelmingly more similar to the '|' operator in sets (whether or not a user happens to know the historical implementation overlap). I think growing the full collection of set operations world be a pleas

Re: [Python-ideas] PEP: Dict addition and subtraction

2019-03-06 Thread Jonathan Fine
Rhodri James wrote: > Making assumptions about length where any dictionary > manipulations are concerned seems unwise to me I think you're a bit hasty here. Some assumptions are sensible. Suppose a = len(d1) b = len(d2) c = len(d1 + d2) # Using the suggested syntax. Then we know

Re: [Python-ideas] PEP: Dict addition and subtraction

2019-03-06 Thread Josh Rosenberg
On Wed, Mar 6, 2019 at 11:52 AM Rhodri James wrote: > On 06/03/2019 10:29, Ka-Ping Yee wrote: > > len(dict1 + dict2) does not equal len(dict1) + len(dict2), so using the + > > operator is nonsense. > > I'm sorry, but you're going to have to justify why this identity is > important. Making assump

Re: [Python-ideas] PEP: Dict addition and subtraction

2019-03-06 Thread Jonathan Fine
Ka-Ping Yee wrote: > > len(dict1 + dict2) does not equal len(dict1) + len(dict2), so using the + > operator is nonsense. > > len(dict1 + dict2) cannot even be computed by any expression involving +. > Using len() to test the semantics of the operation is not arbitrary; the fact > that the sizes

Re: [Python-ideas] PEP: Dict addition and subtraction

2019-03-06 Thread Brice Parent
Le 06/03/2019 à 10:50, Rémi Lapeyre a écrit : Le 05/03/2019 à 23:40, Greg Ewing a écrit : Steven D'Aprano wrote: The question is, is [recursive merge] behaviour useful enough and common enough to be built into dict itself? I think not. It seems like just one possible way of merging values ou

Re: [Python-ideas] PEP: Dict addition and subtraction

2019-03-06 Thread Rhodri James
On 06/03/2019 10:29, Ka-Ping Yee wrote: len(dict1 + dict2) does not equal len(dict1) + len(dict2), so using the + operator is nonsense. I'm sorry, but you're going to have to justify why this identity is important. Making assumptions about length where any dictionary manipulations are concer

Re: [Python-ideas] PEP: Dict addition and subtraction

2019-03-06 Thread Ka-Ping Yee
len(dict1 + dict2) does not equal len(dict1) + len(dict2), so using the + operator is nonsense. len(dict1 + dict2) cannot even be computed by any expression involving +. Using len() to test the semantics of the operation is not arbitrary; the fact that the sizes do not add is a defining quality of

Re: [Python-ideas] PEP: Dict addition and subtraction

2019-03-06 Thread Rémi Lapeyre
Le 6 mars 2019 à 10:26:15, Brice Parent (cont...@brice.xyz(mailto:cont...@brice.xyz)) a écrit: > > Le 05/03/2019 à 23:40, Greg Ewing a écrit : > > Steven D'Aprano wrote: > >> The question is, is [recursive merge] behaviour useful enough and > > > common enough to be built into dict itself? > > > >

Re: [Python-ideas] PEP: Dict addition and subtraction

2019-03-06 Thread Inada Naoki
On Wed, Mar 6, 2019 at 5:34 PM Stefan Behnel wrote: > > INADA Naoki schrieb am 05.03.19 um 08:03:> On Tue, Mar 5, 2019 at 12:02 AM > Stefan Behnel wrote: > >> INADA Naoki schrieb am 04.03.19 um 11:15: > >>> Why statement is not enough? > >> > >> I'm not sure I understand why you're asking this, bu

Re: [Python-ideas] PEP: Dict addition and subtraction

2019-03-06 Thread Brice Parent
Le 05/03/2019 à 23:40, Greg Ewing a écrit : Steven D'Aprano wrote: The question is, is [recursive merge] behaviour useful enough and > common enough to be built into dict itself? I think not. It seems like just one possible way of merging values out of many. I think it would be better to prov

Re: [Python-ideas] PEP: Dict addition and subtraction

2019-03-06 Thread Stefan Behnel
INADA Naoki schrieb am 05.03.19 um 08:03:> On Tue, Mar 5, 2019 at 12:02 AM Stefan Behnel wrote: >> INADA Naoki schrieb am 04.03.19 um 11:15: >>> Why statement is not enough? >> >> I'm not sure I understand why you're asking this, but a statement is >> "not enough" because it's a statement and not