On Mon, Mar 30, 2020 at 10:08:06PM -0700, Guido van Rossum wrote:
> On Mon, Mar 30, 2020 at 10:00 PM Steven D'Aprano
> wrote:
>
> > > it’s optimized for a different use case than string building,
> >
> > It is? That's odd. The whole purpose of StringIO is to build strings.
I misspoke: it is not
On Tue, Mar 31, 2020 at 03:01:51PM +1100, Steven D'Aprano wrote:
> > nor the fastest way
>
> It's pretty close though.
>
> On my test, accumulating 500,000 strings into a list versus a StringIO
> buffer, then building a string, took 27.5 versus 31.6 ms. Using a string
> took 36.4 ms. So it's
On Mon, Mar 30, 2020 at 10:00 PM Steven D'Aprano
wrote:
> > it’s optimized for a different use case than string building,
>
> It is? That's odd. The whole purpose of StringIO is to build strings.
>
> What use-case do you believe it is optimized for?
>
Let me tell you, since I was there.
On Mon, Mar 30, 2020 at 01:59:42PM -0700, Andrew Barnert via Python-ideas wrote:
[...]
> When you call getvalue() it then builds a Py_UCS4*
> representation that’s in this case 4x the size of the final string
> (since your string is pure ASCII and will be stored in UCS1, not
> UCS4). And then
On Mon, Mar 30, 2020 at 04:25:07PM -0700, Christopher Barker wrote:
> As others have pointed out, the OP started in a bit of an oblique way, but
> it maybe come down to this:
>
> There are some use-cases for a mutable string type. And one could certainly
> write one.
With respect Christopher,
On Mon, Mar 30, 2020 at 10:07:30AM -0700, Andrew Barnert via Python-ideas wrote:
> Why? What’s the benefit of building a mutable string around a virtual
> file object wrapped around a buffer (with all the extra complexities
> and performance costs that involves, like incremental Unicode
I have myself been "guilty" of using the problem style for N < 10. In
fact, I had forgotten about the optimization even, since my uses are
negligible time.
For stuff like this, it's fast no matter what:
for clause in query_clauses:
sql += clause
Maybe I have a WHERE or two. Maybe an ORDER
Does anyone know if any linters find and warn about the `string += word` in
a loop pattern? It feels like a linter would be the place to do that. I
don't think we could possibly make it an actual interpreter warning given
borderline OK uses (or possibly even preferred ones). But a little nagging
On Mon, Mar 30, 2020 at 12:37:48PM -0700, Andrew Barnert via Python-ideas wrote:
> On Mar 30, 2020, at 12:00, Paul Sokolovsky wrote:
> > Roughly speaking, to support efficient appending, one need to
> > be ready to over-allocate string storage, and maintain bookkeeping for
> > this. Another known
On Mon, Mar 30, 2020 at 10:24:02AM -0700, Andrew Barnert via Python-ideas wrote:
> On Mar 30, 2020, at 10:01, Brett Cannon wrote:
[talking about string concatenation]
> > I don't think characterizing this as a "mis-optimization" is fair.
[...]
> Yes. A big part of the reason there’s so much
On Tue, Mar 31, 2020 at 10:25 AM Christopher Barker wrote:
>
> As others have pointed out, the OP started in a bit of an oblique way, but
> it maybe come down to this:
>
> There are some use-cases for a mutable string type. And one could certainly
> write one.
>
> presto: here is one:
>
>
As others have pointed out, the OP started in a bit of an oblique way, but
it maybe come down to this:
There are some use-cases for a mutable string type. And one could certainly
write one.
presto: here is one:
https://github.com/Daniil-Kost/mutable_strings
Which looks to me to be more a toy
>
> Perhaps you could use try/finally:
>
> try:
> prepare()
> do_something_sensitive()
> finally:
> cleanup()
>
Well I actually would like to run the else block in case an exception did
occurred.
Let me provide an example from my use case which is the management
On Mon, Mar 30, 2020 at 3:19 PM Serhiy Storchaka
wrote:
> 31.03.20 00:27, Jimmy Thrasibule пише:
> > In my situation, I would like to mix the `with` statement with `else`.
> > In this case I would like that if no exception is raised within the
> > `with` to run the `else` part.
>
> It is easy.
31.03.20 00:27, Jimmy Thrasibule пише:
In my situation, I would like to mix the `with` statement with `else`.
In this case I would like that if no exception is raised within the
`with` to run the `else` part.
It is easy. You do not need "else".
with my_context():
do_something_sensitive()
On Mon, 30 Mar 2020 23:27:19 +0200
Jimmy Thrasibule wrote:
> Now imagine that in my `try .. except` block I have some heavy setup
> to do before `do_something_sensitive()` and some heavy cleanup when
> the exception occurs.
> I'd like my context manager to do the preparation work, execute the
>
Hi,
In Python, there are multiple [compound
statements](https://docs.python.org/3/reference/compound_stmts.html)
with the `else` keyword.
For example:
```
for x in iterable:
if x == sentinel:
break
else:
print("Sentinel not found.")
```
or:
```
try:
Hello,
On Tue, 31 Mar 2020 07:40:01 +1100
Chris Angelico wrote:
> On Tue, Mar 31, 2020 at 7:04 AM Paul Sokolovsky
> wrote:
> > for i in range(5):
> > v = u"==%d==" % i
> > # All individual strings will be kept in the list and
> > # can't be GCed before teh final
On Mar 30, 2020, at 13:06, Paul Sokolovsky wrote:
>
> I appreciate expressing it all concisely and clearly. Then let me
> respond here instead of the very first '"".join() rules!' reply I got.
Ignoring replies doesn’t actually answer them.
> The issue with "".join() is very obvious:
>
>
On Tue, Mar 31, 2020 at 7:04 AM Paul Sokolovsky wrote:
> for i in range(5):
> v = u"==%d==" % i
> # All individual strings will be kept in the list and
> # can't be GCed before teh final join.
> sz += sys.getsizeof(v)
> sb.append(v)
> s =
Hello,
On Mon, 30 Mar 2020 12:37:48 -0700
Andrew Barnert wrote:
> On Mar 30, 2020, at 12:00, Paul Sokolovsky wrote:
> > Roughly speaking, to support efficient appending, one need to
> > be ready to over-allocate string storage, and maintain bookkeeping
> > for this. Another known optimization
Hello,
On Tue, 31 Mar 2020 04:27:04 +1100
Chris Angelico wrote:
[]
> There's a vast difference between "mutable string" and "string
> builder". The OP was talking about this kind of thing:
>
> buf = ""
> for i in range(5):
> buf += "foo"
> print(buf)
>
> And then suggested using a
On Mar 30, 2020, at 12:00, Paul Sokolovsky wrote:
> Roughly speaking, to support efficient appending, one need to
> be ready to over-allocate string storage, and maintain bookkeeping for
> this. Another known optimization CPython does is for stuff like "s =
> s[off:]", which requires maintaining
On Mar 30, 2020, at 10:18, Joao S. O. Bueno wrote:
>
> That said, anyone could tell about small, efficient,
> well maintained "mutable string" classes on Pypi?
I don’t know of one. But what do you actually want it for? In most cases where
you want “mutable strings”, what you really want is
Hello,
On Mon, 30 Mar 2020 09:58:32 -0700
Brett Cannon wrote:
> On Sun, Mar 29, 2020 at 10:58 AM Paul Sokolovsky
> wrote:
>
> > [SNIP]
> >
> > 1. Succumb to applying the same mis-optimization for string type as
> > CPython3. (With the understanding that for speed-optimized projects,
> >
On Tue, Mar 31, 2020 at 5:10 AM Serhiy Storchaka wrote:
>
> 30.03.20 20:27, Chris Angelico пише:
> > def __iadd__(self, s): self.data.append(s)
>
> __iadd__ should return self.
>
And that's what I get for quickly whipping something up and not
testing it. Good catch. But you get the idea - a
30.03.20 20:27, Chris Angelico пише:
def __iadd__(self, s): self.data.append(s)
__iadd__ should return self.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
30.03.20 20:07, Andrew Barnert via Python-ideas пише:
Sadly, this isn’t possible. Large amounts of C code—including builtins and stdlib—won’t let you duck type as a string; as it will do a type check and expect an actual str (and if you subclass str, it will ignore your methods and use the
On Tue, Mar 31, 2020 at 4:20 AM Joao S. O. Bueno wrote:
>
> Hi Andrew -
>
> I made my previous post before reading your first answer.
>
> So, anyway, what we have is that for a "mutable string like object" one
> is free to build his wrapper - StringIO based or not - put it on pypi, and
>
On Mar 30, 2020, at 10:01, Brett Cannon wrote:
>
> I don't think characterizing this as a "mis-optimization" is fair. There is
> use of in-place add with strings in the wild and CPython happens to be able
> to optimize for it. Someone was motivated to do the optimization so we took
> it
Hi Andrew -
I made my previous post before reading your first answer.
So, anyway, what we have is that for a "mutable string like object" one
is free to build his wrapper - StringIO based or not - put it on pypi, and
remember
calling `str()` on it before having it leave your code.
Thank you
On Mar 30, 2020, at 08:29, Joao S. O. Bueno wrote:
>
>
> I agree with the arguments the OP brings forward.
>
> Maybe, it should be the case of having an `StringIO` and `BytesIO` subclass?
> Or better yet, just a class that wraps those, and hide away the other
> file-like
> methods and
On Sun, Mar 29, 2020 at 10:58 AM Paul Sokolovsky wrote:
> [SNIP]
>
> 1. Succumb to applying the same mis-optimization for string type as
> CPython3. (With the understanding that for speed-optimized projects,
> implementing mis-optimizations will eat into performance budget, and
> for
There should be one-- and preferably only one --obvious way to do it. (from The
Zen of Python https://www.python.org/dev/peps/pep-0020/)
However, in something as basic as import syntax, that's not the case. This
example comes from PEP 221 (https://www.python.org/dev/peps/pep-0221/) :
A slightly
30.03.20 15:50, jope...@hotmail.fr пише:
As a result,
`import os.path as p`
stores os.path, not os, in p. This makes it effectively the same as
`from os import path as p`
No, it is not the same.
For example, `from os import mkdir as mkd` works, but `import os.mkdir
as mkd` is an error.
I agree with the arguments the OP brings forward.
Maybe, it should be the case of having an `StringIO` and `BytesIO` subclass?
Or better yet, just a class that wraps those, and hide away the other
file-like
methods and behaviors?
That would keep the new class semantically as a string,
and they
As spotted by response, I did not mature enough my point to see that they could
have a slight difference between both statements.
This thread is no longer relevant.
Thank you
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send
You are right, I did not envisage the case where you could have name mangling
between submodule and variable inside package __init__.py, which could lead to
different behavior. So my statement is erroneous and this thread is no longer
relevant.
Thank you
Maybe you should fill some feature requests to the linter projects, like
flake8, so that
they have an option to distinguish both ways so that one could point
what is the "preferred way" for a given project.
But I don't see any sense on even put a PEP 8 recommendation for this.
On Mon, 30 Mar
The part of "as X" of either "import foo.bar as X" or "from foo import bar
as X" does _one thing_ and is fully self-consistent.
The part of "import foo.bar" and "from foo import bar" does different
things, that sometimes are interchangeable,
and in some cases may have different results -
I completely agree with Andrew Barnert.
I just want to add a little comment about overriding the `+=` (and `+`)
operator for StringIO. Since StringIO is a stream --not a string--, I think
`StringIO` should continue to use the common interface for streams in Python.
`write()` and `read()` are
There is no other advantage than respect of the Zen of Python (and I don't know
how much it counts). Maybe it can simplify interpreter code, but I don't know
about it and I doubt it.
With that, it could help newcomers to Python to choose between the two
syntaxes. (And I've already experienced
joperez＠hotmail.fr wrote:
> There should be one-- and preferably only one --obvious way to do it. (from
> The Zen of
> Python https://www.python.org/dev/peps/pep-0020/)
> However, in something as basic as import syntax, that's not the case. This
> example comes
> from PEP 221
On Tue, Mar 31, 2020 at 12:12 AM wrote:
> That's why I propose to restrict the aliased import statement (`import ... as
> ...`) to not be able to alias imported submodule, letting `from ... import
> ... as ...` statement be the only to do it.
> The roadmap could be to depreciate the statement
There should be one-- and preferably only one --obvious way to do it. (from The
Zen of Python https://www.python.org/dev/peps/pep-0020/)
However, in something as basic as import syntax, that's not the case. This
example comes from PEP 221 (https://www.python.org/dev/peps/pep-0221/) :
A slightly
45 matches
Mail list logo
