On 1/31/2019 12:51 PM, Chris Barker via Python-ideas wrote:
I do a lot of numerical programming, and used to use MATLAB and now
numpy a lot. So I am very used to "vectorization" -- i.e. having
operations that work on a whole collection of items at once.
Example:
a_numpy_array * 5
multiplies
On Fri, Feb 1, 2019 at 4:51 AM Chris Barker wrote:
> I know that when I'm used to working with numpy and then need to do some
> string processing or some such, I find myself missing this "vectorization" --
> if I want to do the same operation on a whole bunch of strings, why do I need
> to writ
On Thu, Jan 31, 2019 at 12:52 PM Chris Barker via Python-ideas <
python-ideas@python.org> wrote:
> I know that when I'm used to working with numpy and then need to do some
> string processing or some such, I find myself missing this "vectorization"
> -- if I want to do the same operation on a whol
On Wed, Jan 30, 2019 at 10:14 PM Chris Angelico wrote:
>
> I didn't, but I don't know if Chris Barker did.
>
nope -- not me either :-)
> (Can't swing a cat without hitting someone named Steve or Chris, in
> some spelling or another!)
>
good thing there aren't a lot of cats being swung around,
On Thu, Jan 31, 2019 at 5:09 PM Steven D'Aprano wrote:
>
> On Wed, Jan 30, 2019 at 12:37:45PM +0100, Jamesie Pic wrote:
> > Thanks for your reply Jimmy ! As suggested by Chris and Steven, we
> > might also want to throw in a "key" kwarg, that could be none by
> > default to keep BC, but also allow
On Wed, Jan 30, 2019 at 12:37:45PM +0100, Jamesie Pic wrote:
> Thanks for your reply Jimmy ! As suggested by Chris and Steven, we
> might also want to throw in a "key" kwarg, that could be none by
> default to keep BC, but also allow typecasting:
>
> ' '.join('a', 2, key=str)
Please don't misrepr
Thank you Christopher for the heads up. Using paths as an example were
really poor, they distract readers from the actual problem that is
assembling a human readable string.
Maybe pointless, but on the basis of 30 seconds to run my test suite,
see my failure, correct it, and run it again to be at
> 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
No, we don’t — one is for assembling paths, one for generic strings.
And in recent versions, there is a new totally different way to assembl
Let's see if this gets any download at all: https://pypi.org/project/mapjoin/
Sorry for this obscenity xD
Thank you all for your replies !
Have a great day
Best regards
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mail
Thanks for your email Barry. This is indeed a good point and the
proposal has changed a bit since then. It's more "add a key kwarg to
str.join where you can set key=str yourself if you want".
___
Python-ideas mailing list
Python-ideas@python.org
https://m
> On 30 Jan 2019, at 10:07, Jamesie Pic wrote:
>
> On Wed, Jan 30, 2019 at 7:03 AM Robert Vanden Eynde
> wrote:
>>>
>>> Raises an error. Why should:
>>>
>>> “”.join([2, “2”]) not raise an error as well?
>>
>> I agree
>
> What do you think could be the developer intent when they do
> ",".jo
On Wed, Jan 30, 2019 at 10:33 PM Jamesie Pic wrote:
>
> On Wed, Jan 30, 2019 at 11:06 AM Chris Angelico wrote:
>
> > Most places where you need to talk to humans, you'll end up either
> > interpolating the values into a template of some sort (see: percent
> > formatting, the format method, and f-
I really don't get the "two different signatures" concern. The two
functions do different things, why would we expect them to automatically
share a signature.
There are a zillion different open() functions or methods in the standard
library, and far more in third party software. They each have var
Thanks for your reply Jimmy ! As suggested by Chris and Steven, we
might also want to throw in a "key" kwarg, that could be none by
default to keep BC, but also allow typecasting:
' '.join('a', 2, key=str)
--
∞
___
Python-ideas mailing list
Python-idea
On Wed, Jan 30, 2019 at 11:06 AM Chris Angelico wrote:
> Most places where you need to talk to humans, you'll end up either
> interpolating the values into a template of some sort (see: percent
> formatting, the format method, and f-strings), or plug individual
> values straight into method calls
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 l
Oops, fixing my last example:
readable = mapjoin(
'hello',
f'__{name}__',
sep='\n',
# key=format_record, could be used here
)
Signature would be like (illustrating defaults): mapjoin(*args,
sep='\n', key=str)
___
Python-ideas mailing lis
Wow, thanks for your great reply Steven ! It really helps me get a
better understanding of what I'm trying to do and move forward in my
research !
Some values are not going to be nice as strings, so I think I'm more
going to try to make a convenience shortcut for str map join, for when
I want to g
On Wed, Jan 30, 2019 at 11:07:52AM +0100, Jamesie Pic wrote:
> What do you think could be the developer intent when they do
> ",".join([2, "2']) ?
I don't know what your intent was, although I can guess, but I do know
that I sure as hell don't want a dumb piece of software like the
interpreter
On Wed, Jan 30, 2019 at 11:24 AM Eric V. Smith wrote:
> Your examples show literals, but I literally (heh) never use str.join
> this way. I always pass it some variable. And 100% of the time, if that
> variable (say it's a list) contains something that's not a string, I
> want it to raise an excep
On Wed, Jan 30, 2019 at 11:06 AM Chris Angelico wrote:
>
> Most places where you need to talk to humans, you'll end up either
> interpolating the values into a template of some sort (see: percent
> formatting, the format method, and f-strings), or plug individual
> values straight into method call
On 1/30/2019 5:07 AM, Jamesie Pic wrote:
On Wed, Jan 30, 2019 at 7:03 AM Robert Vanden Eynde
wrote:
Raises an error. Why should:
“”.join([2, “2”]) not raise an error as well?
I agree
What do you think could be the developer intent when they do
",".join([2, "2']) ?
If the intent is clearl
On Wed, Jan 30, 2019 at 11:17 AM Jamesie Pic wrote:
> often mistake because switching over from os.path.join and str.join.
I didn't mean "replacing an os.path.join call with an str.join call",
I mean that I'm calling str.join 2 seconds after os.path.join, and
forgot about the inconsistency we hav
On Wed, Jan 30, 2019 at 9:21 AM Steven D'Aprano wrote:
>
> If you don't like the two built-in stringify functions, you can write
> your own, and they still work with for-loops, comprehensions and map().
I don't disagree, after all, there are many NPM packages that contain
really short functions,
On Wed, Jan 30, 2019 at 7:14 AM Robert Vanden Eynde
wrote:
> But 🦆 duck typing is nasty... I don't want that in the stdlib (but in a pip
> package, sure!)
Not only do I actually like your implementation, but I also love duck
typing. For me duck typing means freedom, not barrier.
--
∞
_
On Wed, Jan 30, 2019 at 7:03 AM Robert Vanden Eynde
wrote:
>>
>> Raises an error. Why should:
>>
>> “”.join([2, “2”]) not raise an error as well?
>
> I agree
What do you think could be the developer intent when they do
",".join([2, "2']) ?
If the intent is clearly to assemble a string, as it loo
On Wed, Jan 30, 2019 at 8:50 PM Jamesie Pic wrote:
>
> For me, assembling a string from various variables is a much more
> common programing task, because that's how users except software to
> communicate with them, be it on CLI, GUI, or through Web.
>
> It doesn't matter if your software works an
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.
___
On Wed, Jan 30, 2019 at 2:45 AM David Mertz wrote:
> Done! Does that really need to be in the STDLIB?
Well, Robert suggested to define it in the python startup script. The
issue I'm having with that is that it will make my software harder to
distribute: it will require the user to hack their star
Thanks Steven for your reply.
For me, assembling a string from various variables is a much more
common programing task, because that's how users except software to
communicate with them, be it on CLI, GUI, or through Web.
It doesn't matter if your software works and the user doesn't
understand it
On Wed, Jan 30, 2019 at 12:09:55AM +, Alex Shafer wrote:
> 2) strings are special and worthy of a "special case" because strings
> tend to be human readable and are used in all kinds of user interface.
So are ints, floats, bools, lists, tuples, sets, dicts, etc.
We already have a "stringify
On 1/29/2019 7:12 PM, MRAB wrote:
On 2019-01-29 23:30, Terry Reedy wrote:
On 1/28/2019 8:40 PM, Jamesie Pic wrote:
> 0. os.path.join takes *args
Since at least 1 path is required, the signature is join(path, *paths).
I presume that this is the Python version of the Unix version of the
system
> def stringify(*args, *, sep:str=SomeDefault):
>
I meant def stringify(*args, sep:str=SomeDefault)
So an idea would use duck typing to find out if we have 1 iterable or a
multiple stuff :
def stringify(*args, sep:str=SomeDefault, fmt=''):
it = args[0] if len(args) == 1 and hasattr(args[0], '
>
> def stringify(self, sep):
> return sep.join(str(i) for i in self)
>
= map(sep.join(map(str, self))
However some folks want:
def stringify(*args, *, sep:str=SomeDefault):
return sep.join(map(str, args))
In order to have:
>>> stringify(1, 2, "3", sep="-")
1-2-3
And I agree about the
> Alex Shafer via Python-ideas wrote:
>> 1) I'm in favor of adding a stringify method to all collections
>
> Are you volunteering to update all the collection
> classes in the world written in Python? :-)
To be fair, we could add an implementation to the sequence ABC, and
get pretty far.
Not that
I love it when the discussion goes fast like here! :D
The messages are short or long-structured-and-explaining, I love it :)
-- Sorry if I may look like a troll sometimes, I truly like the
conversation and I want to share the excitement :)
___
Python-id
On Wed, 30 Jan 2019, 04:46 David Mertz wrote:
Of course not! [...]
>
I agree
> Of course, it also doesn't work on dictionaries. [...]
>
I agree
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Alex Shafer via Python-ideas wrote:
1) I'm in favor of adding a stringify method to all collections
Are you volunteering to update all the collection
classes in the world written in Python? :-)
--
Greg
___
Python-ideas mailing list
Python-ideas@pyth
On 2019-01-29 15:38, Greg Ewing wrote:
Brendan Barnwell wrote:
Personally what I find is perverse is that .join is a method of
strings but does NOT call str() on the items to be joined.
Neither do most other string methods:
>>> s = "hovercraft"
>>> s.count(42)
Traceback (most recent c
The point really is that something called 'stringify()' could do a lot of
different reasonable and useful things. None of them are universally what
users would want. Unless you have to function scads if optional keyword
arguments, is behavior would surprise many users and not for their purpose.
On
Of course not! The request was for something that worked on Python
*collections*. If the OP wanted something that worked on iterables in
general, we'd need a different function with different behavior.
Of course, it also doesn't work on dictionaries. I don't really have any
ideas what the desired
> stringify = lambda it: type(it)(map(str, it))
>
stringify(range(5)) doesn't work ^^
One advantage or having a standard function is that it has been designed by
a lot of persons for all possible use cases :)
___
Python-ideas mailing list
Python-ideas@p
+1
On Wed, 30 Jan 2019, 02:57 David Mertz "Not every five line function needs to be in the standard library"
>
> ... even more true for every one line function. I can think of a few
> dozen variations of similar but not quite identical behavior to my little
> stringify() that "could be useful."
On 2019-01-29 16:14, MRAB wrote:
On 2019-01-29 23:38, Greg Ewing wrote:
Brendan Barnwell wrote:
Personally what I find is perverse is that .join is a method of
strings but does NOT call str() on the items to be joined.
Neither do most other string methods:
>>> s = "hovercraft"
>>> s.
On 29/01/2019 01:40, Jamesie Pic wrote:
... I'm still sometimes confused between the different syntaxes used
by join methods:
0. os.path.join takes *args
1. str.join takes a list argument, this inconsistence make it easy to
mistake with the os.path.join signature
It seems fairly consistent t
Frankly this sounds like resistance to adaptation and evolution. How long ago
was that adage written? Or perhaps this is a pathological instance of the
snowball fallacy? Adding one widely requested feature does not imply that all
requested features will be added.
Original Message --
"Not every five line function needs to be in the standard library"
... even more true for every one line function. I can think of a few dozen
variations of similar but not quite identical behavior to my little
stringify() that "could be useful." Python gives us easy composition to
create each of
That would be strongly preferred to duplication across hundreds of use cases
and thousands (millions?) of users. Not all of them are likely to come up with
the most efficient implementation either.
Original Message
On Jan 29, 2019, 18:44, David Mertz wrote:
> stringify = lambda
stringify = lambda it: type(it)(map(str, it))
Done! Does that really need to be in the STDLIB?
On Tue, Jan 29, 2019, 7:11 PM Alex Shafer via Python-ideas <
python-ideas@python.org wrote:
> 1) I'm in favor of adding a stringify method to all collections
>
> 2) strings are special and worthy of a
+1 Good performance analysis IMHO :)
On Tue, 29 Jan 2019, 22:24 Jonathan Fine I've not been following closely, so please forgive me if I'm repeating
> something already said in this thread.
>
> Summary: str.join allows us to easily avoid, when assembling strings,
> 1. Quadratic running time.
> 2.
+1 to that email !! (how to do that in email haha)
On Tue, 29 Jan 2019, 21:50 Chris Barker via Python-ideas <
python-ideas@python.org wrote:
> A couple notes:
>
> On Tue, Jan 29, 2019 at 5:31 AM Jamesie Pic wrote:
>
>> can you clarify the documentation
>> topic you think should be improved or cr
On 2019-01-29 23:38, Greg Ewing wrote:
Brendan Barnwell wrote:
Personally what I find is perverse is that .join is a method of
strings but does NOT call str() on the items to be joined.
Neither do most other string methods:
>>> s = "hovercraft"
>>> s.count(42)
Traceback (most recent c
On 2019-01-29 23:30, Terry Reedy wrote:
On 1/28/2019 8:40 PM, Jamesie Pic wrote:
> 0. os.path.join takes *args
Since at least 1 path is required, the signature is join(path, *paths).
I presume that this is the Python version of the Unix version of the
system call that it wraps.. The hidden a
1) I'm in favor of adding a stringify method to all collections
2) strings are special and worthy of a "special case" because strings tend to
be human readable and are used in all kinds of user interface.
Original Message
On Jan 29, 2019, 16:04, Steven D'Aprano wrote:
> On Tue
Brendan Barnwell wrote:
Personally what I find is perverse is that .join is a method of
strings but does NOT call str() on the items to be joined.
Neither do most other string methods:
>>> s = "hovercraft"
>>> s.count(42)
Traceback (most recent call last):
File "", line 1, in
TypeError:
On 1/28/2019 8:40 PM, Jamesie Pic wrote:
> 0. os.path.join takes *args
Since at least 1 path is required, the signature is join(path, *paths).
I presume that this is the Python version of the Unix version of the
system call that it wraps.. The hidden argument is os.sep. It is
equivalent to
On Tue, Jan 29, 2019 at 10:51:26PM +0100, Jamesie Pic wrote:
> What do you think of list.stringify(delim) ?
What's so special about lists? What do you think of:
tuple.stringify
deque.stringify
iterator.stringify
dict.keys.stringify
etc. And what's so special about strings that l
On Tue, Jan 29, 2019 at 9:50 PM Chris Barker via Python-ideas
wrote:
> I would think "assembling strings", though there is a lot out there already.
Which one do you prefer ?
> So in the end, join really does only make sense as string method.
What do you think of list.stringify(delim) ?
Thanks
Thank you Jonathan, performance is one of the various reasons I prefer
join to assembles strings, than, say, triple-quote dedent'ed f-strings
or concatenation. It also plays well syntaxically, even though there
is still a little room for improvement. For example, in PHP
implode('-', array(2, 'a'))
On Tue, Jan 29, 2019 at 09:21:48PM +, Jonathan Fine wrote:
> I've not been following closely, so please forgive me if I'm repeating
> something already said in this thread.
>
> Summary: str.join allows us to easily avoid, when assembling strings,
> 1. Quadratic running time.
> 2. Redundant tr
I've not been following closely, so please forgive me if I'm repeating
something already said in this thread.
Summary: str.join allows us to easily avoid, when assembling strings,
1. Quadratic running time.
2. Redundant trailing comma syntax error.
The inbuilt help(str.join) gives:
S.join(ite
A couple notes:
On Tue, Jan 29, 2019 at 5:31 AM Jamesie Pic wrote:
> can you clarify the documentation
> topic you think should be improved or created ? "Assembling strings"
>
I would think "assembling strings", though there is a lot out there already.
> or "inconsistencies between os.path.jo
funcoperators is pretty neat ! But at this stage of the discussion I
would also try to get automatic string casting since the purpose is to
assemble a string.
It would be great in the stdlib because switching between os.path.join
and str.join is so error-prone, and assembling strings seems like a
Oh and if you want to write ['a', 'b', 'c'].join('.')
Check out pip install funcoperators and you can write :
['a', 'b', 'c'] |join('.')
Given you defined the function below :
from funcoperators import postfix
def join(sep):
return postfix(lambda it: sep.join(map(str, it))
You can even cho
So you'd propose to add some kind of
def Join(sep, *args):
return sep.join(map(str, args))
To the standard lib ?
Or to add another method to str class that do that ?
class str:
...
def Join(self, *args):
return self.join(map(str, args))
I agree such a function is super
Thanks for the advice Jonathan, can you clarify the documentation
topic you think should be improved or created ? "Assembling strings"
or "inconsistencies between os.path.join and str.join" ?
I've written an article to summarize but I don't want to publish it
because my blog serves my lobbying for
> So, do you think anything can be done to make when
> assembling strings less confusing / fix the inconsistency
> between the syntax of of os.path.join and str.join ?
How about improving the documentation. Providing additional examples
might be a good starting point.
That could make a good blog
Thanks for your feedback !
So, do you think anything can be done to make when assembling strings less
confusing / fix the inconsistency between the syntax of of os.path.join and
str.join ?
Have a great day
___
Python-ideas mailing list
Python-ideas@pyth
>
>
> Personally what I find is perverse is that .join is a method of
> strings
> but does NOT call str() on the items to be joined.
Yeah, that's a good reason to use .format when you have a fixed number of
arguments.
"{}, {}, {}, {}".format(some, random, stuff, here)
And then there is
Just by the title I thought you meant
>>> [1].join([2, 3, 4])
[2, 1, 3, 1, 4]
This is what I'd expect on the list class.
So -1 for your suggestion but +1 for what I thought you meant before I read the
complete mail :)
> On 29 Jan 2019, at 02:40, Jamesie Pic wrote:
>
> Hello,
>
> During t
On Tue, Jan 29, 2019 at 4:48 PM David Mertz wrote:
> In the first case, the object (a heterogenous list) can NEVER support a
> .join() method. It's simply the wrong kind of object. Of course, it's right
> as far as the basic type system goes, but its deeper (maybe "structural")
> type cannot su
One could always write
str.join('_', ['list', 'of', 'strings'])
I'm not advocating for this syntax, but perhaps it is clarifying. Also, a
quick search finds this thread from 20 years ago on this very issue:
https://mail.python.org/pipermail/python-dev/1999-June/095366.html
On Mon, Jan 28, 2019
On Tue, Jan 29, 2019, 12:22 AM Brendan Barnwell
> What would you expect to happen with this line:
> >
> > ['foo', b'foo', 37, re.compile('foo')].join('_')
>
> That problem already exists with str.join though. It's just
> currently spelled this way:
>
> ','.join(['foo', b'foo', 37, re.com
If there is a more Pythonic way of joining lists, tuples, sets, etc., it is
by using a keyword and not a method. For example, using a keyword, say
*joins*:
'-' joins ['list', 'of', 'strings']
>
This is more readable than using the method join() since you can read this
as "dash joins a list of str
On 2019-01-28 18:22, David Mertz wrote:
On Mon, Jan 28, 2019 at 8:44 PM Jamesie Pic mailto:j...@yourlabs.org>> wrote:
['cancel', name].join('_')
This is a frequent suggestion. It is also one that makes no sense
whatsoever if you think about Python's semantics. What would you expect
to ha
On Mon, Jan 28, 2019 at 8:44 PM Jamesie Pic wrote:
> ['cancel', name].join('_')
>
This is a frequent suggestion. It is also one that makes no sense
whatsoever if you think about Python's semantics. What would you expect to
happen with this line:
['foo', b'foo', 37, re.compile('foo')].join('_'
PS: sorry for my silly example, i know that example could also be written
f'cancel_{name}', which is awesome, thank you for that ! But for more
complex strings I'm trying to avoid:
def foo():
return textwrap.dedent(f'''
some
{more(complex)}
{st.ri("ng")}
''').strip()
For some
Hello,
During the last 10 years, Python has made steady progress in convenience to
assemble strings. However, it seems to me that joining is still, when
possible, the cleanest way to code string assembly.
However, I'm still sometimes confused between the different syntaxes used
by join methods:
78 matches
Mail list logo
