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
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
>
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
> developer, but why is he then fiddl
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't it be better to go
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
On Thu, Aug 11, 2011 at 12:52 PM, wrote:
> On Thu, Aug 11, 2011 at 11:59:31AM +0100, Chris Angelico wrote:
>> There's no guarantee that all of that 256GB is available to you, of course.
>
> I am the admin of this server - the memory is available for us :-)
Hehe. I mean to any particular applicat
On Thu, Aug 11, 2011 at 11:59:31AM +0100, Chris Angelico wrote:
> 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 Orac
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
> there.
I think you may be lo
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
On Wed, Aug 10, 2011 at 06:20:10PM +0200, Stefan Behnel wrote:
> przemol...@poczta.fm, 10.08.2011 15:31:
>> On Wed, Aug 10, 2011 at 01:32:06PM +0100, Chris Angelico wrote:
>>> On Wed, Aug 10, 2011 at 12:17 PM, wrote:
I'd like to write a python (2.6/2.7) script which connects to database,
>>>
przemol...@poczta.fm, 10.08.2011 15:31:
On Wed, Aug 10, 2011 at 01:32:06PM +0100, Chris Angelico wrote:
On Wed, Aug 10, 2011 at 12:17 PM, wrote:
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)
an
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 string concatenation in Pyth
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
On Wed, Aug 10, 2011 at 01:32:06PM +0100, Chris Angelico wrote:
> 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 pu
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 choice
> regarding string conca
-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
On Sat, Jul 9, 2011 at 3:30 PM, Steven D'Aprano
wrote:
> It also doesn't generalise: only appends are optimized, not prepends.
>
> If you're interested in learning about the optimization:
>
> http://utcc.utoronto.ca/~cks/space/blog/python/ExaminingStringConcatOpt
>From that page:
"Also, this is o
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
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 the case
* 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
> the first 2 thin
On Fri, Jul 8, 2011 at 1: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
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
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).
>
> import time
> t =
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
> until the end, then you might as well do string conca
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's also a fairly simple optimization and really only a
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 "".join implemented inside a class
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 relied upon.
>
> It's also a fairly simple optimization and
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 really only applies to direct
object a
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 (4000+ ms)
On Feb 14, 3:1
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't tell me to append moredata to a
On Jun 17, 1:01 am, "Gabriel Genellina" <[EMAIL PROTECTED]>
wrote:
> En Mon, 16 Jun 2008 07:34:06 -0300, Bart Kastermans <[EMAIL PROTECTED]>
> escribió:
>
> > Summary: can't verify big O claim, how to properly time this?
>
> > This is interesting. I had never attempted to verify a big O
> > state
"Ian Kelly" <[EMAIL PROTECTED]> writes:
> On Mon, Jun 16, 2008 at 11:09 AM, Jean-Paul Calderone
> <[EMAIL PROTECTED]> wrote:
>> It will depend what version of Python you're using and the *exact* details
>> of the code in question. An optimization was introduced where, if the
>> string being conca
En Mon, 16 Jun 2008 07:34:06 -0300, Bart Kastermans <[EMAIL PROTECTED]>
escribió:
> Summary: can't verify big O claim, how to properly time this?
>
> This is interesting. I had never attempted to verify a big O
> statement
> before, and decided that it would be worth trying. So I wrote some
> c
On Mon, Jun 16, 2008 at 12:07 PM, Alex Elder <[EMAIL PROTECTED]> wrote:
> I found this article useful when dealing with strings in Python:
>
>http://www.skymind.com/~ocrow/python_string/
>
> It may help squeeze some more time out of your code. 8-)
Things seem to have changed since then. I
On Mon, 16 Jun 2008 11:30:19 -0600, Ian Kelly <[EMAIL PROTECTED]> wrote:
On Mon, Jun 16, 2008 at 11:09 AM, Jean-Paul Calderone
<[EMAIL PROTECTED]> wrote:
It will depend what version of Python you're using and the *exact* details
of the code in question. An optimization was introduced where, if
I found this article useful when dealing with strings in Python:
http://www.skymind.com/~ocrow/python_string/
It may help squeeze some more time out of your code. 8-)
Alex.
--
http://mail.python.org/mailman/listinfo/python-list
On Mon, Jun 16, 2008 at 11:09 AM, Jean-Paul Calderone
<[EMAIL PROTECTED]> wrote:
> It will depend what version of Python you're using and the *exact* details
> of the code in question. An optimization was introduced where, if the
> string being concatenated to is not referred to anywhere else, it
On Mon, 16 Jun 2008 10:41:05 -0600, Ian Kelly <[EMAIL PROTECTED]> wrote:
On Mon, Jun 16, 2008 at 4:34 AM, Bart Kastermans <[EMAIL PROTECTED]> wrote:
This is interesting. I had never attempted to verify a big O
statement
before, and decided that it would be worth trying. So I wrote some
code to
On Mon, Jun 16, 2008 at 4:34 AM, Bart Kastermans <[EMAIL PROTECTED]> wrote:
> This is interesting. I had never attempted to verify a big O
> statement
> before, and decided that it would be worth trying. So I wrote some
> code to
> collect data, and I can't find that it goes quadratic. I have th
Thanks guys ! Growing and learning :)
--
http://mail.python.org/mailman/listinfo/python-list
Cristian.Codorean a écrit :
> I was just reading a "Python Speed/Performance Tips" article on the
> Python wiki
> http://wiki.python.org/moin/PythonSpeed/PerformanceTips
> and I got to the part that talks about string concatenation and that it
> is faster when using join instead of += because of st
Cristian.Codorean wrote:
> I was just reading a "Python Speed/Performance Tips" article on the
> Python wiki
> http://wiki.python.org/moin/PythonSpeed/PerformanceTips
> and I got to the part that talks about string concatenation and that it
> is faster when using join instead of += because of strin
Cristian.Codorean wrote:
> I was just reading a "Python Speed/Performance Tips" article on the
> Python wiki
> http://wiki.python.org/moin/PythonSpeed/PerformanceTips
> and I got to the part that talks about string concatenation and that
> it is faster when using join instead of += because of stri
98 matches
Mail list logo
