I built a small application using PyQt4 and pyqtgraph to visualize some
data. The app has 32 graphs that plot deques of size 512. The plots are
updated when 200 ints are cycled through each deque.
The plotting slows down in a linear manner with respect to time. In
other words after cycling through
Hi,
ISE Development gmail.com> writes:
> 'code' object 'function' object
>
> co_name: test __qualname__: test
> co_name: T__qualname__: T
> co_name: method __qualname__: test..T.method
>
> The second call corresponds to th
kjs riseup.net> writes:
>
> I have come to believe that the growing number of weakrefs is slowing
> down execution. Is my analysis misguided? How can I introspect further?
> If the slowdown can be attributed to weakref escalation, what are some
> next steps?
The way to analyze this is to build s
On 2014-09-07 02:47, Steven D'Aprano wrote:
Kurt Mueller wrote:
Processing any Unicode string will work with small and wide
python 2.7 builds and also with python >3.3?
( parts of small build python will not work with values over 0x )
( strings with surrogate pairs will not work correctly o
On Mon, Sep 8, 2014 at 12:52 AM, MRAB wrote:
> I don't think you should be saying that it stores the string in Latin-1
> or UTF-16 because that might suggest that they are encoded. They aren't.
Except that they are. RAM stores bytes [1], so by definition
everything that's in memory is encoded. Yo
In article ,
Chris Angelico wrote:
> You can't store a list in memory; what you store is a set of bits
> which represent some metadata and a bunch of pointers.
Well, technically, what you store is something which has the right
behavior. If I wrote:
my_huffman_coded_list = [0] * 100
I
MRAB wrote:
> I don't think you should be saying that it stores the string in Latin-1
> or UTF-16 because that might suggest that they are encoded. They aren't.
Of course they are encoded. Memory consists of bytes, not Unicode code
points, which are abstract numbers representing characters (and o
On Sunday, September 7, 2014 10:33:26 PM UTC+5:30, Steven D'Aprano wrote:
> MRAB wrote:
> > I don't think you should be saying that it stores the string in Latin-1
> > or UTF-16 because that might suggest that they are encoded. They aren't.
> Of course they are encoded. Memory consists of bytes,
Roy Smith wrote:
> In article ,
> Chris Angelico wrote:
>
>> You can't store a list in memory; what you store is a set of bits
>> which represent some metadata and a bunch of pointers.
>
>
> Well, technically, what you store is something which has the right
> behavior. If I wrote:
No. Chris
Rustom Mody wrote:
> On Sunday, September 7, 2014 10:33:26 PM UTC+5:30, Steven D'Aprano wrote:
>> MRAB wrote:
>
>> > I don't think you should be saying that it stores the string in Latin-1
>> > or UTF-16 because that might suggest that they are encoded. They
>> > aren't.
>
>> Of course they are
On Sunday, September 7, 2014 11:38:41 PM UTC+5:30, Steven D'Aprano wrote:
> Rustom Mody wrote:
> > On Sunday, September 7, 2014 10:33:26 PM UTC+5:30, Steven D'Aprano wrote:
> >> MRAB wrote:
> >> > I don't think you should be saying that it stores the string in Latin-1
> >> > or UTF-16 because that
On Sat, 6 Sep 2014 12:53:16 +0200, Manolo Martínez wrote:
> On 09/06/14 at 08:38pm, Steven D'Aprano wrote:
>> But even that's not how the specialists do it. If you want to check whether
>> (say) 2**3000+1 is prime, you don't want to use trial division at all...
>
> When I was interested in these th
Antoine Pitrou:
> kjs riseup.net> writes:
>>
>> I have come to believe that the growing number of weakrefs is slowing
>> down execution. Is my analysis misguided? How can I introspect further?
>> If the slowdown can be attributed to weakref escalation, what are some
>> next steps?
>
> The way t
On 09/07/14 at 06:53pm, Peter Pearson wrote:
> On Sat, 6 Sep 2014 12:53:16 +0200, Manolo Martínez wrote:
> > On 09/06/14 at 08:38pm, Steven D'Aprano wrote:
> >> But even that's not how the specialists do it. If you want to check whether
> >> (say) 2**3000+1 is prime, you don't want to use trial div
On 09/07/2014 01:11 PM, kjs wrote:
> Thanks for the advice. I commented out the graph generation and PyQt call
>
self.app.processEvents()
>
> where in the class __init__
>
self.app = QtGui.QApplication(sys.argv)
>
> This stopped the weakref proliferation. All other objects grow and
>
On 2014-09-07 22:41, Tony the Tiger wrote:
[snip]
As it says here:
https://www.python.org/community/lists/
"""Rudeness and personal attacks, even in reaction to blatant
flamebait, are strongly frowned upon. People may strongly disagree on
an issue, but usually discussion remains civil. In case
Antoine Pitrou wrote:
> Hi,
>
> ISE Development gmail.com> writes:
>> 'code' object 'function' object
>>
>> co_name: test __qualname__: test
>> co_name: T__qualname__: T
>> co_name: method __qualname__: test..T.method
>>
>>
On 9/7/14 5:41 PM, Tony the Tiger wrote:
Now, kindly get the fuck outta here, you fucking retard!
/Grrr
That was unnecessary, ineffective, and totally outside the bounds of
this community's norms: http://www.python.org/psf/codeofconduct
Behave.
--
Ned Batchelder, http://nedbatchelder
On Mon, Sep 8, 2014 at 1:40 AM, Roy Smith wrote:
> Well, technically, what you store is something which has the right
> behavior. If I wrote:
>
> my_huffman_coded_list = [0] * 100
>
> I don't know of anything which requires Python to actually generate a
> million 0's and store them somewhere
On Mon, Sep 8, 2014 at 4:34 AM, Rustom Mody wrote:
> IOW I interpret MRAB's statement that strings should not be thought
> of as encoded because they consist of abstract code-points, seems to me (a
> unicode-ignoramus!) a reasonable outlook
The original question was regarding storage - how PEP 3
On Sun, Sep 7, 2014 at 11:53 AM, Peter Pearson
wrote:
> On Sat, 6 Sep 2014 12:53:16 +0200, Manolo Martínez wrote:
>> On 09/06/14 at 08:38pm, Steven D'Aprano wrote:
>>> But even that's not how the specialists do it. If you want to check whether
>>> (say) 2**3000+1 is prime, you don't want to use tr
Chris Angelico :
> The original question was regarding storage - how PEP 393 says that
> strings will be encoded in memory in any of three ways (Latin-1,
> UCS-2/UTF-16, or UCS-4/UTF-32). But even in our world, that is not
> what a string *is*, but only what it is made of.
I'm a bit surprised tha
On Mon, Sep 8, 2014 at 3:44 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> The original question was regarding storage - how PEP 393 says that
>> strings will be encoded in memory in any of three ways (Latin-1,
>> UCS-2/UTF-16, or UCS-4/UTF-32). But even in our world, that is not
>> what a stri
23 matches
Mail list logo
