[Python-ideas] support toml for pyproject support

[Jimmy Girardet]

Hi,

I don't know if this was already debated  but I don't know how to search
in the whole archive of the list.


For  now the  adoption of pyproject.toml file is more difficult because
toml is not in the standard library.

Each tool which wants to use pyproject.toml has to add a toml lib  as a
conditional or hard dependency.

Since toml is now the standard configuration file format, it's strange
the python does not support it in the stdlib lije it would have been
strange to not have the configparser module.


I know it's complicated to add more and more thing to the stdlib but I
really think it is necessary for python packaging being more consistent.


Maybe we could thought to a readonly lib to limit the added code.


If it's conceivable, I'd be happy to help in it.


Nice Day guys and girls.

Jimmy


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add list.join() please

[Jimmy Girardet]

Hi,

At the end this long thread because 2 functions doing quite the same
thing have the same name but not the same signature and it's confusing
for some people (I'm one of those)

|str.||join|(/iterable/)

|os.path.||join|(/path/, /*paths/)


There are strong arguments about why it's implemented like that and why
it's very difficult to change it.

Maybe some change could be giving str.join 1 iterable or many args :
about str.join:
   a - if 0 arg : error
   b - if 1 arg : process or return error if not iterable
   c - if > 1 arg: do b using all args as one iterable

maybe some performance issues could go against it.

I agree with the fact that this is a minor need and it should not allow
major change
Le 30/01/2019 à 11:01, Jamesie Pic a écrit :
> I'm not disagreeing by any mean. I'm just saying assembling strings is
> a common programing task and that we have two different methods with
> the same name and inconsistent signatures and that it's error-prone.
> I'm most certainly *not* advocating for breaking compatibility or
> whatnot.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

[Jimmy Girardet]

Hi,

I'm not sure to understand the real purpose of Vector.

Is that a new collection ?

Is that a list with a builtin map() function ?

Is it a  wrapper to other types ?

Should it be iterable ?


The clear need explained before is using fluent interface on a collection :

MyVector.strip().replace("A","E")

Why do we need Vector to behave like list. We just want to work on our
strings but with a cleaner/shorter/nicer syntax.

My idea (not totally clear in my mind) is that Vector should behave
quite like the type it wraps so having only one type.

I don't want a collection of strings, I want a MegaString (...) which I
can use exactly like alone string.

An iteration on Vector would iter like itertools.chain does.

At the end, I would only need one more method which would return an
iterable of the items like MyVector.explode()


For me Vector should be something like that :

class Vector:

    def __init__(self, a_list):
    self.data = a_list
    self._type = type(self.data[0])

    for data in self.data:
    if type(data) != self._type:
    raise TypeError

    def __getattr__(self, name):
    fn =  getattr(self._type, name)

    def wrapped(*args, **kwargs):
    self.data = [fn(i, *args, **kwargs) for i in self.data]
    return self
    return wrapped

    def explode(self):
  return iter(self.data)


I'm not saying it should only handle strings but it seems to be the
major use case.

Jimmy


Le 04/02/2019 à 17:12, David Mertz a écrit :
> On Mon, Feb 4, 2019 at 7:14 AM Kirill Balunov  > wrote:
>
> len(v)   # -> 12
>
> v[len]   # -> 
>
>
> In this case you can apply any function,
> even custom_linked_list frommy_inhouse_module.py. 
>
>
> I think I really like this idea.  Maybe as an extra spelling but still
> allow .apply() to do the same thing. It feels reasonably intuitive to
> me. Not *identical to* indexing in NumPy and Pandas, but sort of in
> the same spirit as predicative or selection based indices.
>
> What do other people on this thread think? Would you learn that
> easily? Could you teach it?
>  
>
> >>> v[1:]  
>  'Sep', 'Oct', 'Nov', 'Dec']>  
> >>> v[i[1:]] # some helper class `i`
>  'ep', 'ct', 'ov', 'ec']>  
>
>
> This feels more forced, unfortunately.  Something short would be good,
> but not sure I like this.  This is really just a short spelling of
> pandas.IndexSlice or numpy.s_  It came up in another thread some
> months ago, but there is another proposal to allow the obvious
> spelling `slice[start:stop:sep]` as a way of creating slices.
>
> Actually, I guess that's all halfway for the above.  We'd need to do
> this still:
>
> v[itemgetter(IndexSlicer[1:])]
>
>  
> That's way too noisy.  I guess I just don't find the lowercase `i` to
> be iconic enough.  I think with a better SHORT name, I'd like:
>
> v[Item[1:]]
>
>
>  Maybe that's not the name?
>
> -- 
> 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 the 21st century what the slave trade was to the 16th.
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/


Le 04/02/2019 à 17:12, David Mertz a écrit :
> On Mon, Feb 4, 2019 at 7:14 AM Kirill Balunov  > wrote:
>
> len(v)   # -> 12
>
> v[len]   # -> 
>
>
> In this case you can apply any function,
> even custom_linked_list frommy_inhouse_module.py. 
>
>
> I think I really like this idea.  Maybe as an extra spelling but still
> allow .apply() to do the same thing. It feels reasonably intuitive to
> me. Not *identical to* indexing in NumPy and Pandas, but sort of in
> the same spirit as predicative or selection based indices.
>
> What do other people on this thread think? Would you learn that
> easily? Could you teach it?
>  
>
> >>> v[1:]  
>  'Sep', 'Oct', 'Nov', 'Dec']>  
> >>> v[i[1:]] # some helper class `i`
>  'ep', 'ct', 'ov', 'ec']>  
>
>
> This feels more forced, unfortunately.  Something short would be good,
> but not sure I like this.  This is really just a short spelling of
> pandas.IndexSlice or numpy.s_  It came up in another thread some
> months ago, but there is another proposal to allow the obvious
> spelling `slice[start:stop:sep]` as a way of creating slices.
>
> Actually, I guess that's all halfway for the above.  We'd need to do
> this still:
>
> v[itemgetter(IndexSlicer[1:])]
>
>  
> That's way too noisy.  I guess I just don't find the lowercase `i` to
> be iconic enough.  I think with a better SHORT name, I'd like:
>
>   

[Python-ideas] add fluent operator to everything

[Jimmy Girardet]

Hi,

There was the discussion about vector, etc...

I think I have a frustration about chaining things easily in python in
the stdlib where many libs like orm  do it great.

Here an example :

The code is useless, just to show the idea

>>> a = [1,2,3]

>>> a.append(4)

>>> a.sort()

>>> c = max(a) + 1


I would be happy to have

>>> [1,2,3].append(4)::sort()::max() +1

It makes things very easy to read: first create list, then append 4,
then sort, then get the max.

To resume, the idea is to apply via a new operator (::, .., etc...) the
following callable on the previous object. It's clearly  for standalone
object or after a method call when the return is None (there is fluent 
`.` when there is a return value)

>> object::callable()  = callable(object)
>> object(arg)::callable = callable(object(arg))

def callable(arg1,arg2):
   pass

>> object::callable(arg) == callable(object, arg)

The idea is to use quite everything as first argument of any callable.

I do not know if it was already discussed, and if it would be
technically doable.

Nice Day
Jimmy

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] add fluent operator to everything

[Jimmy Girardet]

Hi,

thank for the replies.

I searched on python-idea as Chris proposed me with "chain" and I've
found 2 relevant discussions :

* A  proposal from Cris Angelico ;-)
https://mail.python.org/pipermail/python-ideas/2014-February/026079.html

"""Right. That's the main point behind this: it gives the *caller* the
choice of whether to chain or not. That's really the whole benefit,
right there.""" ChrisA


the killer  answer of Nick Coghlan
https://mail.python.org/pipermail/python-ideas/2014-February/026158.html
explaining that the main point is about mutating and transforming : this
is a part of Nick's answer :

> start piece of answer Compare:

    seq = get_data()
    seq.sort()

    seq = sorted(get_data())

Now, compare that with the proposed syntax as applied to the first
operation:

    seq = []->extend(get_data())->sort()

That *looks* like it should be a data transformation pipeline, but
it's not - each step in the chain is mutating the original object,
rather than creating a new one. That's a critical *problem* with the
idea, not a desirable feature.
> end of answer

It seems that in 2014 Guido was against chaining method.


* Then in 2017 :
https://mail.python.org/pipermail/python-ideas/2017-August/046770.html

quite the same thing with a "rcompose" idea.


So i understand that in this and previous discussions,  the main
argument against it  was that mutation should looks like mutation  and
not transformation (which returns value).

This seems like a strong thing in core-dev mind since it's about design
of the language.

I totally agree with this idea of "mutating does not "return  value" but
as a "user" of the language I easily can deal with the 2 ideas of
"mutating does not return value" and "lets chain those things". I think
you can do the last without breaking the first.


"Although practicality beats purity"

a : object::mutable1()::mutable2()::mutable3()::mutable4()

b : multligne sequence

mutable1(object)

mutable2(object)

mutable3(object)

mutable4(object)




Pros for a:

    - stands in one line without loosing clarity.

    - user are now used to play with "fluent" syntax in many libs or
languages.

Cons for a:

    - b was here before :-) and fits the idioms of the language.

    - a may look like you're using some `return Value` on mutating
operation. I read somewhere that we are adult enough to be careful of
what we are doing so, this cons is not obvious to me.

At the very beginning of my thoughts I (maybe naively) thought that "a"
could easily be converted to "b" at compile time but I'm not aware of
those internal things.
 

Le 20/02/2019 à 04:10, Stephen J. Turnbull a écrit :
> In most cases, where one doesn't care about performance, one can rewrite
> as
>
> max(a := sorted([1, 2, 3] + [4])) + 1
Indeed, but at first glance, it's not obvious where  it starts and where
it stops.

[1,2,3].append(4)::List.sort()::max() +1  

gives you a sequential way of reading things like you talk or speak in
every day life.

> I think given the current design with its long history, it would be
> more useful to identify pain points where functions like sorted()
> don't exist.
You're right on it. The str class is a  straightforward swiss army knife
with methods you can chain. list or dict do not fit this idea.

Jimmy

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Jimmy Girardet]

Hi,

I'm not old on this list but every time there is a proposal, the answer
is "what are you trying to solve ?".

Since

|z ={**x,**y} and z.update(y) Exists, I can"t find the answer.
|

|
|


Le 02/03/2019 à 04:52, Steven D'Aprano a écrit :
> Executive summary:
>
> - I'm going to argue for subclass-preserving behaviour;
>
> - I'm not wedded to the idea that dict += should actually call the 
> update method, so long as it has the same behaviour;
>
> - __iadd__ has no need to return NotImplemented or type-check its 
> argument.
>
> Details below.
>
>
> On Fri, Mar 01, 2019 at 04:10:44PM -0800, Brandt Bucher wrote:
>
> [...]
>> In your Python implementation samples from the PEP, dict subclasses will
>> behave differently from how list subclasses do. List subclasses, without
>> overrides, return *list* objects for bare "+" operations 
> Right -- and I think they are wrong to do so, for reasons I explained 
> here:
>
> https://mail.python.org/pipermail/python-ideas/2019-March/055547.html
>
> I think the standard handling of subclasses in Python builtins is wrong, 
> and I don't wish to emulate that wrong behaviour without a really good 
> reason. Or at least a better reason than "other methods break 
> subclassing unless explicitly overloaded, so this should do so too".
>
> Or at least not without a fight :-)
>
>
>
>> (and "+=" won't call an overridden "extend" method).
> I'm slightly less opinionated about that. Looking more closely into the 
> docs, I see that they don't actually say that += calls list.extend:
>
> s.extend(t)   extends s with the contents of t (for
> or s += t the most part the same as s[len(s):len(s)] = t)
>
> https://docs.python.org/3/library/stdtypes.html#mutable-sequence-types
>
> only that they have the same effect. So the wording re lists calling 
> extend certainly needs to be changed. But that doesn't mean that we must 
> change the implementation. We have a choice:
>
> - regardless of what lists do, we define += for dicts as literally 
>   calling dict.update; the more I think about it, the less I like this.
>
> - Or we say that += behaves similarly to update, without actually 
>   calling the method. I think I prefer this.
>
> (The second implies either that += either contains a duplicate of the 
> update logic, or that += and update both delegate to a private, C-level 
> function that does most of the work.)
>
> I think that the second approach (define += as having the equivalent 
> semantics of update but without actually calling the update method) is 
> probably better. That decouples the two methods, allows subclasses to 
> change one without necessarily changing the other.
>
>
>> So a more analogous
>> pseudo-implementation (if that's what we seek) would look like:
>>
>> def __add__(self, other):
>> if isinstance(other, dict):
>> new = dict.copy(self)
>> dict.update(new, other)
>> return new
>> return NotImplemented
> We should not require the copy method.
>
> The PEP should be more explicit that the approximate implementation does 
> not imply the copy() and update() methods are actually called.
>
>
>> def __iadd__(self, other):
>> if isinstance(other, dict):
>> dict.update(self, other)
>> return self
>> return NotImplemented
> I don't agree with that implementation.
>
> According to PEP 203, which introduced augmented assignment, the 
> sequence of calls in ``d += e`` is:
>
> 1. Try to call ``d.__iadd__(e)``.
>
> 2. If __iadd__ is not present, try ``d.__add__(e)``.
>
> 3. If __add__ is missing too, try ``e.__radd__(d)``.
>
> but my tests suggest this is inaccurate. I think the correct behaviour 
> is this:
>
> 1. Try to call ``d.__iadd__(e)``.
>
> 2. If __iadd__ is not present, or if it returns NotImplemented, 
>try ``d.__add__(e)``.
>
> 3. If __add__ is missing too, or if it returns NotImplemented,
>fail with TypeError.
>
> In other words, e.__radd__ is not used.
>
> We don't want dict.__iadd__ to try calling __add__, since the later is 
> more restrictive and less efficient than the in-place merge. So there is 
> no need for __iadd__ to return NotImplemented. It should either succeed 
> on its own, or fail hard:
>
> def __iadd__(self, other):
> self.update(other)
> return self
>
> Except that the actual C implementation won't call the update method 
> itself, but will follow the same semantics.
>
> See the docstring for dict.update for details of what is accepted by 
> update.
>
>

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Jimmy Girardet]

> but requires either some obscure syntax or a statement instead of a simple
> expression.
>
> The proposal is to enable the obvious syntax for something that should be
> obvious.
>
> Stefan

The discussions on this list show that the behavior of `+` operator with
dict will never be obvious (first wins or second wins or add results or
raise Exception). So the user will always have to look at the doc or
test it to know the intended behavior.

That said, [1,2] + [3] equals  [1,2,3]  but not[1,2, [3]] and that was
not obvious to me, and I survived.

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Dict joining using + and +=

[Jimmy Girardet]

Indeed the "obscure" argument should be thrown away.

The `|` operator in sets seems to be evident for every one on this list
but I would be curious to know how many people first got a TypeError
doing set1 + set2 and then found set1 | set2 in the doc.

Except for math geek the `|` is always something obscure.


>> Even if dict1 - dict2 were
>> added to the language, I think I'd steer clear of it as being too
>> obscure.
> Everything is obscure until people learn it and get used to it.
>
>


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Jimmy Girardet]

> Does anyone have an example of another programming language that
> allows for addition of dictionaries/mappings?
>

kotlin does that (`to` means `:`)   :

fun main() {
    var a = mutableMapOf("a" to 1, "b" to 2)
    var b = mutableMapOf("c" to 1, "b" to 3)
    println(a)
    println(b)
    println(a + b)
    println(b + a)
}
   
{a=1, b=2}
{c=1, b=3}
{a=1, b=3, c=1}
{c=1, b=2, a=1}
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why operators are useful

[Jimmy Girardet]

Hi,

Please let me share my story of non experienced python programmer.

Last year I wanted to merge three dicts  for config stuff.

I found very quickly the answer : a = {**b, **c, **d}

Sadly I was working on python 3.3 and that was nos possible to use this
syntax. I don't remember what I did next : use chain,; ChainMap,  some
comprehension or some a.update() but I was missing the "upacking syntax".

The syntax {**b,**c} wasn't hard to remember. That wasn't something
known by mathematician, experienced programmers or some artist at the
first look maybe. But It's a clear syntax easy to remember. Easy because
two arterisk `**` in python is a well known syntax due to `**kwargs` in
many functions. And easy because at the end it's idiomatic.

Many things are not straightforward in python depending where you come
from :

if __name__ == '__main__':  # Ugly

len(collection) et not collection.len() # Ugly depending your
programming background

item  in collection instead of collection.contains(i) # same thing.

list/dict comprehensions...


At the end, only a few things are straightforward at the beginning, so
d1+d2 fails isn't a big deal since you will easy remember after a quick
initial search the idiom {**d1,***d2}


Jimmy


Le 18/03/2019 à 15:12, Antoine Pitrou a écrit :
> On Mon, 18 Mar 2019 14:06:53 +
> Rhodri James  wrote:
>> On 16/03/2019 12:01, Gustavo Carneiro wrote:
>>> Already been said, but might have been forgotten, but the new proposed
>>> syntax:
>>>
>>>  new = a + b
>>>
>>> has to compete with the already existing syntax:
>>>
>>>  new = {**a, **b}
>>>   
>> That's easy.  Whether it's spelt with "+" or "|" or pretty much anything 
>> else, the operator version is clearer and cleaner.  "{**a, **b}" is a 
>> combination of operators and literal (display) syntax, and following 
>> Guido's reasoning that makes it inherently harder to interpret.  It's 
>> also ugly IMHO, but that's me.
> The question is whether it's too hard or ugly for the use cases.  In
> other words: where are the use cases where it's frequent enough to
> merge dicts that a nicer syntax is required?
>
> (also, don't forget you can still use the copy() + update() method)
>
> Regards
>
> Antoine.
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/