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
> 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
> 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
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 :)
___
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
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
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.
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
+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"
>>>
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
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
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 =
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.
>
+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
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
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
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
Is it that really obnoxious? Does using upper case for constants measurably
slows down coders? Can you cite the actual papers describing such
experiments that lead to this conclusion ?
Because, from my experience having a visual clue that a value is a constant
or an enum is something pretty
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
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
On 29Jan2019 15:44, Jamesie Pic wrote:
On Fri, Jan 4, 2019 at 10:07 PM Bernardo Sulzbach
wrote:
I'd suggest violating PEP-8 instead of trying to change it.
TBH even my bash global environment variables tend to become more and
more lowercase ...
If you mean _exported_ variables, then this
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
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:
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
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
בתאריך שבת, 5 בינו׳ 2019, 2:10, מאת Abe Dillon
> The whole point of the all-caps globals is to tell you a lot about what
>> they are.
>
> A lot? The only thing it canonically tells you is to not modify it
>
Wrong. It also tells it's unlikely to be modified by the code that does
declare it,
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
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
> 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
>
>
> 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
40 matches
Mail list logo
