On Tuesday 10 May 2016 12:42, Chris Angelico wrote:
> On Tue, May 10, 2016 at 12:32 PM, Steven D'Aprano
> wrote:
>> Floats are old (they go back to the first release of Python), they have
>> many quirks (x + y - x is not necessarily equal to y), and people make
>> many errors with floats. Does th
On Tuesday 10 May 2016 18:15, David Palao wrote:
> 2016-05-10 9:54 GMT+02:00 Steven D'Aprano
> :
>> I'm surprised that Spanish names are not affected. Consider a woman who goes
>> by the personal name of Maria Teresa, whose father's first surname was
>> García and mother's first surname was Ramír
On Wednesday, May 11, 2016 at 5:30:48 PM UTC-4, sohca...@gmail.com wrote:
> On Wednesday, May 11, 2016 at 12:14:43 PM UTC-7, Thomas 'PointedEars' Lahn
> wrote:
> > sohcahto...@gmail.com wrote:
> >
> > > I don't blame people for not wanting to use their real name on the
> > > Internet, especially
On Wednesday, May 11, 2016 at 12:14:43 PM UTC-7, Thomas 'PointedEars' Lahn
wrote:
> sohcahto...@gmail.com wrote:
>
> > I don't blame people for not wanting to use their real name on the
> > Internet, especially if you're a woman. There are a lot of crazy people
> > out there that will find out w
On Sunday, May 8, 2016 at 5:44:25 PM UTC-7, Thomas 'PointedEars' Lahn wrote:
> Also, it would be a good idea if you posted under your real name. Internet
> is the thing with cables; Usenet is the thing with people. I for one tend
> to avoid communicating with few-letter entities; exceptions to
2016-05-10 9:54 GMT+02:00 Steven D'Aprano
:
> On Tuesday 10 May 2016 17:13, Paul Rubin wrote:
>
>> Steven D'Aprano writes:
>>> Australia's naming laws almost certainly wouldn't allow such a name.
>>
>> https://en.wikipedia.org/wiki/Facebook_real-
> name_policy_controversy#Vietnamese
>
> "Phuc Dat
On Tuesday 10 May 2016 17:13, Paul Rubin wrote:
> Steven D'Aprano writes:
>> Australia's naming laws almost certainly wouldn't allow such a name.
>
> https://en.wikipedia.org/wiki/Facebook_real-
name_policy_controversy#Vietnamese
"Phuc Dat Bich" was a hoax, but it probably would be allowed in A
Steven D'Aprano writes:
> Australia's naming laws almost certainly wouldn't allow such a name.
https://en.wikipedia.org/wiki/Facebook_real-name_policy_controversy#Vietnamese
--
https://mail.python.org/mailman/listinfo/python-list
On Tuesday 10 May 2016 13:45, Rustom Mody wrote:
> See:
> http://www.alphr.com/computing/1000378/facebook-rejects-native-american-
names-as-fake-again
Somebody should set up a kick-starter to pay someone to change their legal
name to "Facebook-Are-Arseholes", then open a Facebook account with i
On Tuesday, May 10, 2016 at 2:52:13 AM UTC+5:30, Thomas 'PointedEars' Lahn
wrote:
> Chris Angelico wrote:
>
> > On Mon, May 9, 2016 at 10:44 AM, Thomas 'PointedEars' Lahn wrote:
> >> Also, it would be a good idea if you posted under your real name.
> >> Internet is the thing with cables; Usenet
On Tue, May 10, 2016 at 12:32 PM, Steven D'Aprano wrote:
> Floats are old (they go back to the first release of Python), they have many
> quirks (x + y - x is not necessarily equal to y), and people make many
> errors with floats. Does this mean they are deprecated? Of course not.
Careful there S
On Tue, 10 May 2016 07:21 am, Thomas 'PointedEars' Lahn wrote:
> Chris Angelico wrote:
>
>> On Mon, May 9, 2016 at 10:44 AM, Thomas 'PointedEars' Lahn
>> wrote:
>>> With the “%” string operator (deprecated), str.format(), and
>>> str.Template, you can use other values in string values even witho
You're saying that wasn't a coded message?
On Sun, May 8, 2016, 10:44 PM srinivas devaki
wrote:
> I'm so sorry, forgot to lock my phone.
> On May 9, 2016 9:01 AM, "srinivas devaki"
> wrote:
>
> > f be gfdnbh be b GB GB BH GB vbjfhjb GB bffbbubbv GB hbu hbu
> > fjbjfbbbufhbvh VB have fqb
f be gfdnbh be b GB GB BH GB vbjfhjb GB bffbbubbv GB hbu hbu
fjbjfbbbufhbvh VB have fqbgvfb NB bb GB GB GB GB bbu GB vu GB vu GB GB
b GB fbufjnb BH GB GB bvvfbubbjubuv GB b fbufbbby GB bfff GB f GB
bbbu GB GB ffinj GB vh vh fjb GB fj GB h h GB gjfthey're the b GB gjf GBG
GBG q GB fb
I'm so sorry, forgot to lock my phone.
On May 9, 2016 9:01 AM, "srinivas devaki"
wrote:
> f be gfdnbh be b GB GB BH GB vbjfhjb GB bffbbubbv GB hbu hbu
> fjbjfbbbufhbvh VB have fqbgvfb NB bb GB GB GB GB bbu GB vu GB vu GB GB
> b GB fbufjnb BH GB GB bvvfbubbjubuv GB b fbufbbby GB bf
On Mon, May 9, 2016 at 10:44 AM, Thomas 'PointedEars' Lahn
wrote:
> With the “%” string operator (deprecated), str.format(), and str.Template,
> you can use other values in string values even without concatenation.
Not deprecated. Don't spread FUD.
> Finally, with SQL you should prefer Prepared
DFS wrote:
> sSQL = "line 1\n"
> sSQL += "line 2\n"
> sSQL += "line 3"
What is wrong with it in Python is that it is unnecessarily inefficient.
Python has implicit string concatenati
On Sat, Jan 12, 2013 at 1:38 AM, wrote:
> The difference between a correct (coherent) unicode handling and ...
This thread was about byte string concatenation, not unicode, so your
rant is not even on-topic here.
--
http://mail.python.org/mailman/listinfo/python-list
On Sun, Jan 13, 2013 at 1:27 AM, Terry Reedy wrote:
> On 1/12/2013 6:42 AM, Chris Angelico wrote:
>>
>> On Sat, Jan 12, 2013 at 10:31 PM, Terry Reedy wrote:
>>>
>>> 0.410.4395.2("WHERE IN THE WORLD IS CARMEN SAN
>>> DEIGO?"*10).lower()
>>
>>
>> Why does stringbench misspell the name C
On 1/12/2013 6:42 AM, Chris Angelico wrote:
On Sat, Jan 12, 2013 at 10:31 PM, Terry Reedy wrote:
0.410.4395.2("WHERE IN THE WORLD IS CARMEN SAN
DEIGO?"*10).lower()
Why does stringbench misspell the name Carmen Sandiego? Copyright avoidance?
Or ignorance. Perhaps I will fix it so
On Sat, Jan 12, 2013 at 10:31 PM, Terry Reedy wrote:
> 0.410.4395.2("WHERE IN THE WORLD IS CARMEN SAN
> DEIGO?"*10).lower()
Why does stringbench misspell the name Carmen Sandiego? Copyright avoidance?
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
On 1/12/2013 3:38 AM, wxjmfa...@gmail.com wrote:
from timeit import timeit, repeat
size = 1000
r = repeat("y = x + 'a'", setup = "x = 'a' * %i" % size)
print('1:', r)
r = repeat("y = x + 'é'", setup = "x = 'a' * %i" % size)
print('2:', r)
r = repeat("y = x + 'œ'", setup = "x = 'a' * %i" % size)
from timeit import timeit, repeat
size = 1000
r = repeat("y = x + 'a'", setup = "x = 'a' * %i" % size)
print('1:', r)
r = repeat("y = x + 'é'", setup = "x = 'a' * %i" % size)
print('2:', r)
r = repeat("y = x + 'œ'", setup = "x = 'a' * %i" % size)
print('3:', r)
r = repeat("y = x + '€'", setup = "
On 11/01/2013 20:16, Ian Kelly wrote:
On Fri, Jan 11, 2013 at 12:03 PM, Rotwang wrote:
Hi all,
the other day I 2to3'ed some code and found it ran much slower in 3.3.0 than
2.7.2. I fixed the problem but in the process of trying to diagnose it I've
stumbled upon something weird that I hope some
On Fri, Jan 11, 2013 at 12:03 PM, Rotwang wrote:
> Hi all,
>
> the other day I 2to3'ed some code and found it ran much slower in 3.3.0 than
> 2.7.2. I fixed the problem but in the process of trying to diagnose it I've
> stumbled upon something weird that I hope someone here can explain to me. In
>
Hi all,
the other day I 2to3'ed some code and found it ran much slower in 3.3.0
than 2.7.2. I fixed the problem but in the process of trying to diagnose
it I've stumbled upon something weird that I hope someone here can
explain to me. In what follows I'm using Python 2.7.2 on 64-bit Windows
7
On Fri, Aug 12, 2011 at 11:25:06AM +0200, Stefan Behnel wrote:
> przemol...@poczta.fm, 11.08.2011 16:39:
>> On Thu, Aug 11, 2011 at 02:48:43PM +0100, Chris Angelico wrote:
>>> On Thu, Aug 11, 2011 at 2:46 PM, wrote:
This is the way I am going to use.
But what is the best data type to hol
On Aug 12, 8:10 am, przemol...@poczta.fm wrote:
> Good question but I try to explain what motivates me to do it.
> First reason (I think the most important :-) ) is that I want to learn
> something new - I am new to python (I am unix/storage sysadmin but with
> programming
> background so python w
przemol...@poczta.fm, 11.08.2011 16:39:
On Thu, Aug 11, 2011 at 02:48:43PM +0100, Chris Angelico wrote:
On Thu, Aug 11, 2011 at 2:46 PM, wrote:
This is the way I am going to use.
But what is the best data type to hold so many rows and then operate on them ?
List of strings. Take it straight
On Thu, Aug 11, 2011 at 3:39 PM, wrote:
> On Thu, Aug 11, 2011 at 02:48:43PM +0100, Chris Angelico wrote:
>> List of strings. Take it straight from your Oracle interface and work
>> with it directly.
>
> Can I use this list in the following way ?
> subprocess_1 - run on list between 1 and 1
>
On Thu, Aug 11, 2011 at 02:48:43PM +0100, Chris Angelico wrote:
> On Thu, Aug 11, 2011 at 2:46 PM, wrote:
> > This is the way I am going to use.
> > But what is the best data type to hold so many rows and then operate on
> > them ?
> >
>
> List of strings. [...]
Let's assume I have the whole l
On Thu, Aug 11, 2011 at 02:48:43PM +0100, Chris Angelico wrote:
> On Thu, Aug 11, 2011 at 2:46 PM, wrote:
> > This is the way I am going to use.
> > But what is the best data type to hold so many rows and then operate on
> > them ?
> >
>
> List of strings. Take it straight from your Oracle inte
On Thu, Aug 11, 2011 at 02:38:32PM -0700, SigmundV wrote:
> When I saw the headline I thought "oh no, not string concatenation
> again... we have had scores of these thread before...", but this is a
> rather interesting problem. The OP says he's not a database
> dev
When I saw the headline I thought "oh no, not string concatenation
again... we have had scores of these thread before...", but this is a
rather interesting problem. The OP says he's not a database
developer, but why is he then fiddling with internal database
operations? Wouldn&#x
On Thu, Aug 11, 2011 at 2:46 PM, wrote:
> This is the way I am going to use.
> But what is the best data type to hold so many rows and then operate on them ?
>
List of strings. Take it straight from your Oracle interface and work
with it directly.
ChrisA
--
http://mail.python.org/mailman/listi
On Thu, Aug 11, 2011 at 11:59:31AM +0100, Chris Angelico wrote:
>
> What may be the easiest way is to do the select in a single process,
> then partition it and use the Python multiprocessing module to split
> the job into several parts. Then you need only concatenate the handful
> of strings.
Th
Chris Angelico, 11.08.2011 12:59:
On Thu, Aug 11, 2011 at 7:40 AM, wrote:
I am not a database developer so I don't want to change the whole process
of data flow between applications in my company. Another process is
reading this XML from particular Oracle table so I have to put the final XML
t
ugh, to ascertain where
>> the bottleneck really is. Is it actually slow doing the concatenation,
>> or is it taking more time reading/writing the disk? Is it actually all
>> just taking time due to RAM usage? Proper string concatenation doesn't
>> need a huge amount of
> the job into several parts. Then you need only concatenate the handful
> of strings.
This is the way I am going to use.
> You'll need to do some serious profiling, though, to ascertain where
> the bottleneck really is. Is it actually slow doing the concatenation,
> o
tion,
or is it taking more time reading/writing the disk? Is it actually all
just taking time due to RAM usage? Proper string concatenation doesn't
need a huge amount of CPU.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
On Wed, Aug 10, 2011 at 03:38:42PM +0100, Chris Angelico wrote:
> On Wed, Aug 10, 2011 at 3:38 PM, Chris Angelico wrote:
> > Which SQL library are you suing?
>
> And this is why I should proof-read BEFORE, not AFTER, sending.
>
> Which SQL library are you *using*?
cx_oracle
Regards
Przemyslaw
) script which connects to database,
>>>> fetches
>>>> hundreds of thousands of rows, concat them (basically: create XML)
>>>> and then put the result into another table. Do I have any choice
>>>> regarding string concatenation in Python from the perform
e XML)
and then put the result into another table. Do I have any choice
regarding string concatenation in Python from the performance point of view ?
Since the number of rows is big I'd like to use the fastest possible library
(if there is any choice). Can you recommend me something ?
First off,
przemol...@poczta.fm wrote:
> Hello,
>
> I'd like to write a python (2.6/2.7) script which connects to database,
> fetches hundreds of thousands of rows, concat them (basically: create XML)
> and then put the result into another table. Do I have any choice
> regarding
On Wed, Aug 10, 2011 at 3:38 PM, Chris Angelico wrote:
> Which SQL library are you suing?
And this is why I should proof-read BEFORE, not AFTER, sending.
Which SQL library are you *using*?
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
On Wed, Aug 10, 2011 at 2:31 PM, wrote:
> - fetch all rows from the database (up to 1 million): what is recommended
> data type ?
> - spawn X python processes each one:
> - concat its own subset
> - merge the result from all the subprocesses
>
What you're writing is, fundamentally, glue betw
m (basically: create XML)
> > and then put the result into another table. Do I have any choice
> > regarding string concatenation in Python from the performance point of view
> > ?
> > Since the number of rows is big I'd like to use the fastest possible library
> >
On Wed, Aug 10, 2011 at 12:17 PM, wrote:
> Hello,
>
> I'd like to write a python (2.6/2.7) script which connects to database,
> fetches
> hundreds of thousands of rows, concat them (basically: create XML)
> and then put the result into another table. Do I have any ch
Hello,
I'd like to write a python (2.6/2.7) script which connects to database, fetches
hundreds of thousands of rows, concat them (basically: create XML)
and then put the result into another table. Do I have any choice
regarding string concatenation in Python from the performance point of
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
On 2011.07.10 09:33 AM, Roy Smith wrote:
> The canonical way to do that would be something like
>
> fields = [demux_filter, field_filter, fpsin_filter, i2pfilter,
> dn_filter, fpsout_filter, trim_filter, info_filter]
> avs.write(''.join(fields)
Roy Smith wrote:
> The canonical way to do that would be something like
>
> fields = [demux_filter,
> field_filter,
> fpsin_filter,
> i2pfilter,
> dn_filter,
> fpsout_filter,
> trim_filter,
> info_filter]
> avs.write(''.join(fi
In article ,
Andrew Berg wrote:
> How should I go about switching from concatenation to string formatting
> for this?
>
> avs.write(demux_filter + field_filter + fpsin_filter + i2pfilter +
> dn_filter + fpsout_filter + trim_filter + info_filter)
>
> I can think of a few ways, but none of them
Andrew Berg wrote:
> How should I go about switching from concatenation to string formatting
> for this?
>
> avs.write(demux_filter + field_filter + fpsin_filter + i2pfilter +
> dn_filter + fpsout_filter + trim_filter + info_filter)
>
> I can think of a few ways, but none of them are pretty.
fi
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
On 2011.07.10 04:47 AM, Vinay Sajip wrote:
> You don't need logutils, just the BraceMessage class - which is
> shown in the blog post (around 10 lines). Feel free to use it with
> copy and paste :-)
I didn't realize that was the actual class when
Andrew Berg gmail.com> writes:
> On 2011.07.10 02:23 AM, Vinay Sajip wrote:
> > There are examples in the blog post I linked to earlier:
> It seems that would require logutils. I'm trying to keep dependencies to
> a minimum in my project, but I'll take a look at logutils and see if
> there's anyt
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
On 2011.07.10 02:23 AM, Vinay Sajip wrote:
> There are examples in the blog post I linked to earlier:
It seems that would require logutils. I'm trying to keep dependencies to
a minimum in my project, but I'll take a look at logutils and see if
the
Andrew Berg gmail.com> writes:
> How would I do that with the newer formatting? I've tried:
There are examples in the blog post I linked to earlier:
http://plumberjack.blogspot.com/2010/10/supporting-alternative-formatting.html
Regards,
Vinay Sajip
--
http://mail.python.org/mailman/listinf
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
How should I go about switching from concatenation to string formatting
for this?
avs.write(demux_filter + field_filter + fpsin_filter + i2pfilter +
dn_filter + fpsout_filter + trim_filter + info_filter)
I can think of a few ways, but none of th
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
On 2011.07.10 12:55 AM, Dennis Lee Bieber wrote:
> Maybe it's been removed, but from the help file for my installation
help(file) returns a NameError in 3.2. It shows up as a built-in
function in the 2.7 docs, but not in the py3k docs. It's not me
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
On 2011.07.09 11:04 PM, Andrew Berg wrote:
>
> Is barf built-in as well?
>
That came off more hostile than I wanted, so I'll rephrase it:
I doubt it has anything to do with built-ins, since it fails on a
variable name that obviously does not re
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
On 2011.07.09 09:54 PM, Dennis Lee Bieber wrote:
> "file" is a built-in (related to "open").
Also:
> Traceback (most recent call last): File
> "C:\Users\Bahamut\workspace\Disillusion\disillusion.py", line 178, in
> save_preset() File
> "C:\Users\
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
On 2011.07.09 09:54 PM, Dennis Lee Bieber wrote:
> "file" is a built-in (related to "open").
It is? What is it?
>>> type(file)
Traceback (most recent call last):
File "", line 1, in
NameError: name 'file' is not defined
I don't see it in
On 2011.07.09 06:06 AM, Vinay Sajip wrote:
> In a logging context at least, using the form like
>
> logger.debug("formatting message with %s", "arguments")
>
> rather than
>
> logger.debug("formatting message with %s" % "arguments")
How would I do that with the newer formatting? I've tried:
> logge
Andrew Berg gmail.com> writes:
> Other than the case where a variable isn't a string (format() converts
> variables to strings, automatically, right?) and when a variable is used
> a bunch of times, concatenation is fine, but somehow, it seems wrong.
> Sorry if this seems a bit silly, but I'm a n
On Sat, Jul 9, 2011 at 12:16 AM, Chris Angelico wrote:
> Has the same optimization been implemented for Unicode? The page
> doesn't mention Python 3 at all, and I would guess that the realloc
> optimization would work fine for both types of string.
Seems to be implemented for strs in 3.2, but not
gt;From that page:
"Also, this is only for plain (byte) strings, not for Unicode strings;
as of Python 2.4.2, Unicode string concatenation remains
un-optimized."
Has the same optimization been implemented for Unicode? The page
doesn't mention Python 3 at all, and I would guess that t
On Fri, Jul 8, 2011 at 11:30 PM, Steven D'Aprano
wrote:
> Billy Mays wrote:
>
>> If it means anything, I think concatenation is faster.
>
> You are measuring the speed of an implementation-specific optimization.
> You'll likely get *very* different results with Jython or IronPython, or
> old versi
Billy Mays wrote:
> If it means anything, I think concatenation is faster.
You are measuring the speed of an implementation-specific optimization.
You'll likely get *very* different results with Jython or IronPython, or
old versions of CPython, or even if you use instance attributes instead of
lo
ceback (most recent call last):
File "", line 1, in
TypeError: %d format: a number is required, not NoneType
If you don't give a type code, format converts any object to string (if
possible).
> and when a variable is used
> a bunch of times, concatenation is fine, but somehow,
* John Gordon (Fri, 8 Jul 2011 20:23:52 + (UTC))
> I prefer this usage:
>
> logger.error('%s could not be stored - %s' % \
> (self.preset_file, sys.exc_info()[1]))
The syntax for formatting logging messages according to the
documentation is:
Logger.error(msg, *args)
NOT
Logger.erro
On 2011.07.08 05:59 PM, Ben Finney wrote:
> With the caveat that the formatting of that line should be using PEP 8
> indentation for clarity:
PEP 8 isn't bad, but I don't agree with everything in it. Certain lines
look good in chunks, some don't, at least to me. It's quite likely I'm
going to be wr
Ben Finney writes:
> logger.error(
> '{0} could not be stored - {1}'.format(
> (self.preset_file, sys.exc_info()[1]))
>
> I usually prefer to use named placeholders instead of positional, but
> this duplicates your original.
Ah, I see that the OP *did* use named placeholders.
On Fri, Jul 8, 2011 at 3:50 PM, Ben Finney wrote:
> * The ‘%’ string formatting operator is superseded in current Python
> versions by the more flexible ‘format’ method of string objects.
>
AFAIK, % formatting is the only kind of formatting that works portably
across all of CPythons 2.5, 2.6, 2.
Andrew Berg writes:
> Is it bad practice to use this
> > logger.error(self.preset_file + ' could not be stored - ' +
> > sys.exc_info()[1])
This is not necessarily bad practice, but there are not many points in
its favour. It's inflexible and makes the eventual formatting harder to
discern.
> I
John Gordon writes:
> I prefer this usage:
>
> logger.error('%s could not be stored - %s' % \
> (self.preset_file, sys.exc_info()[1]))
That can be improved by learning two things:
* The backslash-linebreak is ugly and fragile, and almost never needed,
since Python knows to continue a st
On Fri, Jul 8, 2011 at 3:23 PM, Benjamin Kaplan
wrote:
> String formatting is the One Right Way here. It's fine to use string
> concatenation for a few things, but the operation is O(n^2) because each
> concat occurs one at a time: Python allocates space for a string the size of
ong.
> Sorry if this seems a bit silly, but I'm a novice when it comes to
> design. Plus, there's not really supposed to be "more than one way to do
> it" in Python.
>
String formatting is the One Right Way here. It's fine to use string
concatenation for a few
On 07/08/2011 04:18 PM, Andrew Berg wrote:
Is it bad practice to use this
logger.error(self.preset_file + ' could not be stored - ' +
sys.exc_info()[1])
Instead of this?
logger.error('{file} could not be stored -
{error}'.format(file=self.preset_file, error=sys.exc_info()[1]))
Other than th
In Andrew Berg
writes:
> Is it bad practice to use this
> > logger.error(self.preset_file + ' could not be stored - ' +
> > sys.exc_info()[1])
> Instead of this?
> > logger.error('{file} could not be stored -
> > {error}'.format(file=self.preset_file, error=sys.exc_info()[1]))
> Other than the
Is it bad practice to use this
> logger.error(self.preset_file + ' could not be stored - ' +
> sys.exc_info()[1])
Instead of this?
> logger.error('{file} could not be stored -
> {error}'.format(file=self.preset_file, error=sys.exc_info()[1]))
Other than the case where a variable isn't a string (f
ing to a list and then joining
> > > this list when done is the fastest technique for string
> > > concatenation. Is this true?
>
> > > The 3 string concatenation techniques I can think of are:
>
> > > - append to list, join
> > > - stri
is the fastest technique for string
> > concatenation. Is this true?
>
> > The 3 string concatenation techniques I can think of are:
>
> > - append to list, join
> > - string 'addition' (s = s + char)
> > - cStringIO
>
> There is a fourth technique, and tha
My local news feed seems to have lost the early part of this thread, so
I'm afraid I don't know who I'm quoting here:
> My understanding is that appending to a list and then joining
> this list when done is the fastest technique for string
> concatenation. Is this
pyt...@bdurham.com wrote:
> My understanding is that appending to a list and then joining
> this list when done is the fastest technique for string
> concatenation. Is this true?
>
> The 3 string concatenation techniques I can think of are:
>
> - append to list, join
>
On Sat, 02 Oct 2010 13:17:02 -0700, Carey Tilden wrote:
> Have you profiled an application and found string concatenation to be
> a performance bottleneck? I would be surprised, but it's always
> possible. If not, I'd suggest you choose the technique that is most
> clear
Carey,
> Have you profiled an application and found string concatenation to be a
> performance bottleneck? I would be surprised, but it's always possible.
The "application" is very simple - its essentially a finite state
machine that parses complex RTF files. We read cha
e feedback - really appreciated.
Malcolm
# test performance of various string concatenation techniques
import cStringIO
import timeit
source = 'x' * 500
def testListAppend():
output = list()
for char in source:
output.append( char )
output = &
On Sat, Oct 2, 2010 at 12:09 PM, wrote:
> My understanding is that appending to a list and then joining this list when
> done is the fastest technique for string concatenation. Is this true?
Have you profiled an application and found string concatenation to be
a performance bottlene
On 10/2/2010 12:09 PM pyt...@bdurham.com said...
Your times will improve when not burdened by the repeated method lookups
and element-wise list creation:
try with eg,
def testListAppend2():
output = list()
append = output.append
for char in source:
append( char )
outpu
My understanding is that appending to a list and then joining
this list when done is the fastest technique for string
concatenation. Is this true?
The 3 string concatenation techniques I can think of are:
- append to list, join
- string 'addition' (s = s + char)
- cStringIO
The
Nick Craig-Wood wrote:
> The optimized += depends on their being no other references to the
> string. Strings are immutable in python. So append must return a new
> string. However the += operation was optimised to do an in-place
> append if and only if there are no other references to the stri
Sammo wrote:
> String concatenation has been optimized since 2.3, so using += should
> be fairly fast.
>
> In my first test, I tried concatentating a 4096 byte string 1000 times
> in the following code, and the result was indeed very fast (12.352 ms
> on my machine).
>
On Feb 14, 5:33 pm, Steven D'Aprano wrote:
> > AFAIK, using list mutation and "".join only improves performance if
> > the "".join is executed outside of the loop.
>
> Naturally. If you needlessly join over and over again, instead of delaying
> u
On Feb 14, 4:47 pm, Steven D'Aprano wrote:
> > Sammo gmail.com> writes:
> >> String concatenation has been optimized since 2.3, so using += should
> >> be fairly fast.
>
> > This is implementation dependent and shouldn't be relied upon.
>
> It
Sammo wrote:
> Okay, this is what I have tried for string concatenation:
>
> 1. Using += implemented using simple operations (12 ms)
> 2. Using += implemented inside a class (4000+ ms)
> 3. Using "".join implemented using simple operations (4000+ ms)
> 4. Using "
Steven D'Aprano wrote:
> Benjamin Peterson wrote:
>
>> Sammo gmail.com> writes:
>>
>>> String concatenation has been optimized since 2.3, so using += should
>>> be fairly fast.
>>
>> This is implementation dependent and shouldn't be
Benjamin Peterson wrote:
> Sammo gmail.com> writes:
>
>> String concatenation has been optimized since 2.3, so using += should
>> be fairly fast.
>
> This is implementation dependent and shouldn't be relied upon.
It's also a fairly simple optimization and
Okay, this is what I have tried for string concatenation:
1. Using += implemented using simple operations (12 ms)
2. Using += implemented inside a class (4000+ ms)
3. Using "".join implemented using simple operations (4000+ ms)
4. Using "".join implemented inside a class (400
Sammo gmail.com> writes:
>
> String concatenation has been optimized since 2.3, so using += should
> be fairly fast.
This is implementation dependent and shouldn't be relied upon.
>
> Note that I need to do something to mydata INSIDE the loop, so please
> don'
String concatenation has been optimized since 2.3, so using += should
be fairly fast.
In my first test, I tried concatentating a 4096 byte string 1000 times
in the following code, and the result was indeed very fast (12.352 ms
on my machine).
import time
t = time.time()
mydata = ""
mor
1 - 100 of 154 matches
Mail list logo
