Re: Negative array indicies and slice()
On 10/29/2012 10:53 PM, Michael Torrie wrote: On 10/29/2012 01:34 PM, Andrew Robinson wrote: No, I don't think it big and complicated. I do think it has timing implications which are undesirable because of how *much* slices are used. In an embedded target -- I have to optimize; and I will have to reject certain parts of Python to make it fit and run fast enough to be useful. Since you can't port the full Python system to your embedded machine anyway, why not just port a subset of python and modify it to suit your needs right there in the C code. It would be a fork, yes, You're exactly right; That's what I *know* I am faced with. Without a libc, an MMU on the CPU, and a kernel, it's not going to just compile and run. I have libc. The MMU is a problem; but the compiler implements the standard "C" math library; floats, though, instead of doubles. That's the only problem -- there. What you want with slicing behavior changes has no place in the normal cPython implementation, for a lot of reasons. The main one is that it is already possible to implement what you are talking about in your own python class, which is a fine solution for a normal computer with memory and CPU power available. If the tests I outlined in the previous post inaccurately describe a major performance improvement and at least a modest code size reduction; or will *often* introduce bugs -- I *AGREE* with you. Otherwise, I don't. I don't think wasting extra CPU power is a good thing -- Extra CPU power can always be used by something else I won't belabor the point further. I'd love to see a counter example to the specific criteria I just provided to IAN -- it would end my quest; and be a good reference to point others to. -- http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
On 10/29/2012 11:51 PM, Ian Kelly wrote: On Mon, Oct 29, 2012 at 4:39 PM, Andrew Robinson As above, you're looking at the compiler code, which is why you're finding things like "line" and "column". The tuple struct is defined in tupleobject.h and stores tuple elements in a tail array. If you re-check my post to chris, I listed the struct you mention. The C code is what is actually run (by GDB breakpoint test) when a tuple is instantiated. If the tuple were stripped of the extra data -- then it ought to be as small as slice(). But it's not as small -- so either the sys.getsizeof() is lying -- or the struct you mention is not complete. Which? --Andrew. -- http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
On Mon, Oct 29, 2012 at 7:49 PM, Chris Kaynor wrote:
> NOTE: The above is taken from reading the source code for Python 2.6.
> For some odd reason, I am getting that an empty tuple consists of 6
> pointer-sized objects (48 bytes on x64), rather than the expected 3
> pointer-sized (24 bytes on x64). Slices are showing up as the expected
> 5 pointer-sized (40 bytes on x64), and tuples grow at the expected 1
> pointer (8 bytes on x64) per item. I imagine I am missing something,
> but cannot figure out what that would be.
I'm likewise seeing 4 extra words in tuples in 32-bit Python 3.3.
What I've found is that for tuples and other collection objects, the
garbage collector tacks on an extra header before the object in
memory. That header looks like this:
typedef union _gc_head {
struct {
union _gc_head *gc_next;
union _gc_head *gc_prev;
Py_ssize_t gc_refs;
} gc;
long double dummy; /* force worst-case alignment */
} PyGC_Head;
gc_next and gc_prev implement a doubly-linked list that the garbage
collector uses to explicitly track this object. gc_refs is used for
counting references during a garbage collection and stores the GC
state of the object otherwise.
I'm not entirely certain why collection objects get this special
treatment, but there you have it.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
On Mon, Oct 29, 2012 at 6:17 PM, Andrew Robinson wrote: > If you re-check my post to chris, I listed the struct you mention. > The C code is what is actually run (by GDB breakpoint test) when a tuple is > instantiated. When you were running GDB, were you debugging the interactive interpreter or a precompiled script? The interactive interpreter does a compilation step for every line entered. > If the tuple were stripped of the extra data -- then it ought to be as small > as slice(). > But it's not as small -- so either the sys.getsizeof() is lying -- or the > struct you mention is not complete. As just explained, the extra 16 bytes are added by the garbage collector. -- http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
On Mon, Oct 29, 2012 at 5:54 PM, Andrew Robinson wrote: >> I don't know of a reason why one might need to use a negative start >> with a positive stop, though. > > I've already given several examples; and another poster did too I meant that I don't know of a reason to do that given the existing semantics, which is what you were asking for. :-) I understand and agree that there are potential applications for allowing slices to wrap around from negative to positive. What I'm not convinced of is that these applications need or should be handled by the slicing operation -- which is more commonly understood as producing subsequences -- especially since they already can be handled relatively easily by iteration. I think that more users would find the behavior surprising than useful. -- http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
By the way Andrew, the timestamps on your emails appear to be off, or possibly the time zone. Your posts are allegedly arriving before the posts you reply to, at least according to my news client. On Mon, 29 Oct 2012 12:34:24 -0700, Andrew Robinson wrote: > On 10/29/2012 05:02 PM, Steven D'Aprano wrote: >> On Mon, 29 Oct 2012 08:42:39 -0700, Andrew Robinson wrote: >> > But, why can't I just overload the existing __getitem__ for lists > and not bother writing an entire class? >> You say that as if writing "an entire class" was a big complicated >> effort. It isn't. It is trivially simple, a single line: >> >> class MyList(list): >> ... > No, I don't think it big and complicated. I do think it has timing > implications which are undesirable because of how *much* slices are > used. In an embedded target -- I have to optimize; and I will have to > reject certain parts of Python to make it fit and run fast enough to be > useful. Then I look forward to seeing your profiling results that show that the overhead of subclassing list is the bottleneck in your application. Until then, you are making the classic blunder of the premature optimizer: "More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason — including blind stupidity." — W.A. Wulf I am not impressed by performance arguments when you have (apparently) neither identified the bottlenecks in your code, nor even measured the performance. You are essentially *guessing* where the bottlenecks are, and *hoping* that some suggested change will be an optimization rather than a pessimization. Of course I may be wrong, and you have profiled your code and determined that the overhead of inheritance is a problem. If so, that's a different ball game. But your posts so far suggest to me that you're trying to predict performance optimizations rather than measure them. You can just overload that one method in a subclass of list. Being able to monkey-patch __getitem__ for the list class itself would not be advisable, as it would affect all list slicing anywhere in your program and possibly lead to some unexpected behaviors. >>> That's what I am curious about. >>> What unexpected behaviors would a "monkey patch" typically cause? >> What part of "unexpected" is unclear? >> > Ahh -- The I don't know approach! It's only unexpected if one is a bad > programmer...! No, it is unexpected because once you start relying on monkey-patching, and the libraries you install are monkey-patching, you have a combinational explosion of interactions. Any piece of code, anywhere, could monkey-patch any other piece of code -- it is a form of action-at-a- distance coding, like GOTOs and global variables. Use it with caution, in moderation. >> Let me see if I can illustrate a flavour of the sort of things that can >> happen if monkey-patching built-ins were allowed. [...] > Right, which means that people developing the libraries made > contradictory assumptions. Not necessarily. Not only can monkey-patches conflict, but they can combine in bad ways. It isn't just that Fred assumes X and Barney assumes not-X, but also that Fred assumes X and Barney assumes Y and *nobody* imagined that there was some interaction between X and Y. [...] >> Ruby allows monkey-patching of everything. And the result was >> predictable: >> >> http://devblog.avdi.org/2008/02/23/why-monkeypatching-is-destroying- ruby/ >> >> > I read that post carefully; and the author purposely notes that he is > exaggerating. Not carefully enough. He notes that he was using a provocative title and that he doesn't actually think that Ruby is being destroyed. But the actual harm he describes is real, e.g. bugs that take months to track down. > What you are talking about is namespace preservation; I haven't mentioned namespaces. Nothing I have said has anything to do with namespaces. I remember Apple monkey-patching routines in ROM back in the mid 1980s, long before there was anything corresponding to namespaces in Apple's programming model. > and I am thinking > about it. I can preserve it -- but only if I disallow true Python > primitives in my own interpreter; I can't provide two sets in the memory > footprint I am using. If you want to write a language that is not Python, go right ahead. > If someone had a clear explanation of the disadvantages of allowing an > iterator, or a tuple -- in place of a slice() -- I would have no qualms > dropping the subject. However, I am not finding that yet. I am finding > very small optimization issues... Python has certain public interfaces. If your language does not support those public interfaces, then it might be an awesome language, but it is not Python. Python slices have certain features: * they can be used repeatedly; * they have public attributes start, step and stop; * The stop attribute can be None, and the slice will default t
Re: Negative array indicies and slice()
On Tue, Oct 30, 2012 at 1:21 AM, Ian Kelly wrote: > I'm not entirely certain why collection objects get this special > treatment, but there you have it. Thinking about it some more, this makes sense. The GC header is there to support garbage collection for the object. Atomic types like ints do not need this header because they do not reference other objects and so cannot be involved in reference cycles. For those types, reference counting is sufficient. For types like collections that do reference other objects, garbage collection is needed. Expanding on this, I suspect it is actually a bug that slice objects are not tracked by the garbage collector. The following code appears to result in a memory leak: import gc gc.disable() while True: for i in range(100): l = [] s = slice(l) l.append(s) del s, l _ = gc.collect() Try running that and watch your Python memory usage climb and climb. For contrast, replace the slice with a list and observe that memory usage does *not* climb. On each iteration, the code constructs a reference cycle between a slice and a list. It seems that because slices are not tracked by the garbage collector, it is unable to break these cycles. -- http://mail.python.org/mailman/listinfo/python-list
Re: date and time comparison how to
On 10/30/2012 12:20 AM, noydb wrote: > On Monday, October 29, 2012 11:11:55 PM UTC-4, Dave Angel wrote: >> On 10/29/2012 10:13 PM, noydb wrote: >> >>> I guess I get there eventually! >> >>> >> >> > > okay, I see. > But for the user supplied date... I'm not sure of the format just yet... > testing with a string for now (actual date-date might be possible, tbd > later), so like '10292012213000' (oct 29, 2012 9:30pm). How would you get > that input into a format to compare with dt above? > See http://docs.python.org/2/library/datetime.html There are a number of constructors for datetime. For example, now = datetime.datetime.now() spec = datetime.strptime(datstring, format) spec = datetime.datetime(year, month, day[, hour[, minute[, second[, microsecond) In each case, you have an optional tz for timezone. Or if possible, use utc versions of these functions to get "greenwich" times. tz is one of the biggest pains, and the quirks vary between operating systems and filesystems. If possible in your environment, use utcnow, utcfromtimestamp, etc. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: I need help installing pypng in Python 3.3
On Monday, October 29, 2012 3:48:09 PM UTC+1, Andrew Robinson wrote: > On 10/29/2012 06:39 AM, [email protected] wrote: > > > That's very kind of you but I don't think it would be particularly fitted > > to my needs. The program I'm trying to code creates an image as an 2D array > > of "pixels" which is defined by RGBA value. My program needs to access and > > modifies every component of every pixels in the image following a set of > > rules, kind of like the game of life, only more complex. > > > > > > In fact I only need a library to "push" this array of pixels in a > > displayable format for the GUI and in PNG format to write the image to > > disk. I don't need to do any fancy stuff with the image, just being able to > > display and write it. > > > > > > > > Then, actually, what I am suggesting was *almost* perfect. > > To do transparency, you need to write the portable any map (PAM) formation. > > > > Simply print a text header to a file which says: > > > > P7 > > WIDTH 10 > > HEIGHT 10 > > DEPTH 4 > > MAXVAL 255 > > TUPLTYPE RGB_ALPHA > > ENDHDR > > > > And then dump your 2D array to that same file. > > A very quick example in 17 lines of code: > > > > io = open( "anyname.pam","w") > > x,y = 10,10 > > gray=(128,128,128,255) # R,G,B,A value > > picture = [ [ gray ] * x ] * y # Make a blank gray canvas 2D array > > > > # Do whatever you want to the 2D picture array here! > > > > io.write( "P7\nWIDTH %d\nHEIGHT %d\nDEPTH 4\nMAXVAL 255\nTUPLTYPE > > RGB_ALPHA\nENDHDR\n" % (x,y) ) > > > > for yi in xrange( y ): > > for xi in xrange( x ): > > pixel = picture[yi][xi] > > io.write( chr(pixel[0]) ) # R value > > io.write( chr(pixel[1]) ) # G value > > io.write( chr(pixel[2]) ) # B value > > io.write( chr(pixel[3]) ) # A value > > io.flush() > > > > io.close() > > > > And that's it. You may of course make this more efficient -- I'm just > > showing it this way for clarity. > > Many programs can read PAM directly; but for those that can't you can > > use nettools, or imagemagick, to convert it to PNG. That's really interesting! Thank you so much! Never heard of PAM before... I will try that! -- http://mail.python.org/mailman/listinfo/python-list
exec with partial globals
Hi,
I'd like to give the user the ability to enter code which may only rebind
a given set of names but not all ones.
This does NOT work
A=1
B=2
Code=compile('A=7','','exec')
exec(Code,{'A':0})
print("I've got A={}".format(A)) # prints 1
How can 'filter' the gobal namespace such that modifying 'A' is allowed
but any attempt to modify 'B' should give an exception.
Many thanks for a hint,
Helmut.
--
http://mail.python.org/mailman/listinfo/python-list
Re: exec with partial globals
On Tue, Oct 30, 2012 at 11:00 PM, Helmut Jarausch
wrote:
> Hi,
>
> I'd like to give the user the ability to enter code which may only rebind
> a given set of names but not all ones.
>
> How can 'filter' the gobal namespace such that modifying 'A' is allowed
> but any attempt to modify 'B' should give an exception.
I don't know of any way to do that _as such_, but you can simply
follow up the exec with direct retrieval from the globals.
>>> a=1; b=2
>>> code=compile("a=7",'','exec')
>>> ns={'a':0}
>>> exec(code,ns)
>>> a=ns["a"]
(Incidentally, it's normal to use lower case for most names, reserving
the leading uppercase letter for types/classes.)
The exec'd code gets its own namespace (defined by the dictionary,
same as you were doing - note that the 'a' inside that namespace has
nothing to do with the 'a' outside it), and then you explicitly fetch
the values you want.
A slightly more sophisticated example might include a list of shared
variables, for example:
shared = ['a']
outer = globals()
ns = {v:outer[v] for v in shared}
exec(code,ns);
for v in shared: outer[v]=ns[v]
Untested but should work. (Is there any way to directly apply filter()
to a dictionary? That's what I'm really looking for here.)
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: exec with partial globals
On 10/30/2012 08:00 AM, Helmut Jarausch wrote:
> Hi,
>
> I'd like to give the user the ability to enter code which may only rebind
> a given set of names but not all ones.
> This does NOT work
> A=1
> B=2
> Code=compile('A=7','','exec')
> exec(Code,{'A':0})
> print("I've got A={}".format(A)) # prints 1
>
>
> How can 'filter' the gobal namespace such that modifying 'A' is allowed
> but any attempt to modify 'B' should give an exception.
>
>
> Many thanks for a hint,
> Helmut.
A=1
B=2
Code=compile('A=7','','exec')
vars = {'A':A}
exec(Code, vars)
A = vars["A"]
print("I've got A={}".format(A)) # prints 1
That now prints "I've got A=7"
More generally, you could write a loop, copying globals into vars, and
another one, copying them back.
No idea what you're really after; this is one of the more dangerous
things to try.
Although you can constrain the globals seen by the code, that code can
still use builtins, do imports, delete files, etc.
Further, if your user is clever enough, he can do:
Code=compile('A=7; print("howdy"); import __main__;
__main__.B=42','','exec')
What are you really trying to permit him to do? Initialize some
variables for you? How about an .ini file ?
--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
Re: problems with xml parsing (python 3.3)
If someone comes across this posting with the same problem, the best answer seems to be: avoid Pythons xml.etree.ElementTree and use this library instead: http://lxml.de/ It works like expected and supports xpath much better. -- http://mail.python.org/mailman/listinfo/python-list
Re: exec with partial globals
On Tue, 30 Oct 2012 08:33:38 -0400, Dave Angel wrote:
> On 10/30/2012 08:00 AM, Helmut Jarausch wrote:
>> Hi,
>>
>> I'd like to give the user the ability to enter code which may only rebind
>> a given set of names but not all ones.
>> This does NOT work
>> A=1
>> B=2
>> Code=compile('A=7','','exec')
>> exec(Code,{'A':0})
>> print("I've got A={}".format(A)) # prints 1
>>
>>
>> How can 'filter' the gobal namespace such that modifying 'A' is allowed
>> but any attempt to modify 'B' should give an exception.
>>
>>
>> Many thanks for a hint,
>> Helmut.
>
> A=1
> B=2
> Code=compile('A=7','','exec')
> vars = {'A':A}
> exec(Code, vars)
> A = vars["A"]
> print("I've got A={}".format(A)) # prints 1
>
> That now prints "I've got A=7"
>
> More generally, you could write a loop, copying globals into vars, and
> another one, copying them back.
>
> No idea what you're really after; this is one of the more dangerous
> things to try.
>
> Although you can constrain the globals seen by the code, that code can
> still use builtins, do imports, delete files, etc.
>
> Further, if your user is clever enough, he can do:
>
> Code=compile('A=7; print("howdy"); import __main__;
> __main__.B=42','','exec')
>
> What are you really trying to permit him to do? Initialize some
> variables for you? How about an .ini file ?
Many thanks Chris, many thanks to Dave.
First, in my application only trusted people will use it.
Here my example. I'd like to update a spreadsheet by data given by another
spreadsheet. I like to allow to modify only certain columns of the first
spreadsheet. The update formula and possible conditions are entered at
run time and the available fields are only known once the spreadsheets
have been read.
Given spreadsheet S (Source) and D (Destination) as objects (wrapping a
dictionary) a possible (legal) input would be
D.price= D.price-S.discount
No other fields of 'D' should be modifiable.
Again, I don't need to take actions against a malicious user,
just take care about a typo or mistake
Thanks again,
Helmut.
--
http://mail.python.org/mailman/listinfo/python-list
Re: exec with partial globals
On Tue, Oct 30, 2012 at 11:57 PM, Helmut Jarausch wrote: > Given spreadsheet S (Source) and D (Destination) as objects (wrapping a > dictionary) a possible (legal) input would be > > D.price= D.price-S.discount > > No other fields of 'D' should be modifiable. That's a bit harder. What you're describing, using exec with specific globals, would not be able to do this. You'd need to build a proxy object that decides whether or not to pass on the change. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
calling one staticmethod from another
Hi! I can call a staticmethod f() of class C like "C.f()" or with an instance like "C().f()". Inside that staticmethod, I have neither the class (at least not the original one) nor do I have an instance, so I can't call a different staticmethod from the same class. The obvious solution is to make this a classmethod instead, with a mostly-unused "cls" parameter. Am I missing something? Uli -- http://mail.python.org/mailman/listinfo/python-list
Re: exec with partial globals
On 10/30/2012 08:57 AM, Helmut Jarausch wrote:
> On Tue, 30 Oct 2012 08:33:38 -0400, Dave Angel wrote:
>
>> On 10/30/2012 08:00 AM, Helmut Jarausch wrote:
>>> Hi,
>>>
>>> I'd like to give the user the ability to enter code which may only rebind
>>> a given set of names but not all ones.
>>> This does NOT work
>>> A=1
>>> B=2
>>> Code=compile('A=7','','exec')
>>> exec(Code,{'A':0})
>>> print("I've got A={}".format(A)) # prints 1
>>>
>>>
>>> How can 'filter' the gobal namespace such that modifying 'A' is allowed
>>> but any attempt to modify 'B' should give an exception.
>>>
>>>
>>> Many thanks for a hint,
>>> Helmut.
>> A=1
>> B=2
>> Code=compile('A=7','','exec')
>> vars = {'A':A}
>> exec(Code, vars)
>> A = vars["A"]
>> print("I've got A={}".format(A)) # prints 1
>>
>> That now prints "I've got A=7"
>>
>> More generally, you could write a loop, copying globals into vars, and
>> another one, copying them back.
>>
>> No idea what you're really after; this is one of the more dangerous
>> things to try.
>>
>> Although you can constrain the globals seen by the code, that code can
>> still use builtins, do imports, delete files, etc.
>>
>> Further, if your user is clever enough, he can do:
>>
>> Code=compile('A=7; print("howdy"); import __main__;
>> __main__.B=42','','exec')
>>
>> What are you really trying to permit him to do? Initialize some
>> variables for you? How about an .ini file ?
> Many thanks Chris, many thanks to Dave.
>
> First, in my application only trusted people will use it.
>
> Here my example. I'd like to update a spreadsheet by data given by another
> spreadsheet. I like to allow to modify only certain columns of the first
> spreadsheet. The update formula and possible conditions are entered at
> run time and the available fields are only known once the spreadsheets
> have been read.
>
> Given spreadsheet S (Source) and D (Destination) as objects (wrapping a
> dictionary) a possible (legal) input would be
>
> D.price= D.price-S.discount
>
> No other fields of 'D' should be modifiable.
>
> Again, I don't need to take actions against a malicious user,
> just take care about a typo or mistake
>
> Thanks again,
> Helmut.
>
If the user will only be modifying fields of specific class instances,
then generate those instances with property wrappers around the readonly
attributes.
If the class were statically defined, you'd do something like:
class MyClass(object):
def __init__(self, data1, data2, data3):
self._data1 = data1
self._data2 = data2
self.data3 = data3 #this one is writable, directly
@property
def data1(self): #this is readonly
return self._data1
@property
def data2(self):#this is readonly
return self._data2
mysrc = MyClass(1,2,3)
mydest = MyClass(4,5,6)
print( mydest.data1, mydest.data2, mydest.data3, "\n") #prints 4,5,6
vars = {"src": mysrc, "dest": mydest}
Code=compile('dest.data3=17','','exec')
exec(Code, vars)
print( mydest.data1, mydest.data2, mydest.data3, "\n")#prints 4,5,17
Now, once you see how to do it statically, you can try to do it dynamically,
deciding which attributes need property wrappers, and which ones are plain data.
--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
Re: calling one staticmethod from another
Ulrich Eckhardt wrote:
I can call a staticmethod f() of class C like "C.f()" or with an
instance like "C().f()". Inside that staticmethod, I have neither the
class (at least not the original one) nor do I have an instance, so I
can't call a different staticmethod from the same class. The obvious
solution is to make this a classmethod instead, with a mostly-unused
"cls" parameter.
Am I missing something?
class Spam():
@staticmethod
def green():
print('on a train!')
@staticmethod
def question():
print('would you, could you', end='')
Spam.green()
It can be a pain if you change the class name, but it is certainly one way to
do it.
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
Re: calling one staticmethod from another
On 10/30/2012 08:25 AM, Ulrich Eckhardt wrote: > Hi! > > I can call a staticmethod f() of class C like "C.f()" or with an > instance like "C().f()". Inside that staticmethod, I have neither the > class (at least not the original one) nor do I have an instance, so I > can't call a different staticmethod from the same class. The obvious > solution is to make this a classmethod instead, with a mostly-unused > "cls" parameter. > > Am I missing something? > > Uli I'd think the obvious solution is to move both the functions outside of the class. I haven't figured out the justification for staticmethod, except for java or C++ converts. But if you like the staticmethod for other reasons, why is it you can't just use C.g() ? -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
shannan is so good at giving head pt 22
shannan is so good at giving head pt 22 http://www.google.com/search?hl=en&q=shannan+is+so+good+at+giving+head+pt+22+site:ryurikpiroumita.blogspot.com&btnI=I%27m+Feeling+Lucky -- http://mail.python.org/mailman/listinfo/python-list
Re: Nice solution wanted: Hide internal interfaces
2012/10/30 alex23 : > On Oct 30, 2:33 am, Johannes Bauer wrote: >> I'm currently looking for a good solution to the following problem: I >> have two classes A and B, which interact with each other and which >> interact with the user. Instances of B are always created by A. >> >> Now I want A to call some private methods of B and vice versa (i.e. what >> C++ "friends" are), but I want to make it hard for the user to call >> these private methods. > > One approach could be to only have the public interface on B, and then > create a wrapper for B that provides the private interface: > > class B: > def public_method(self): > pass > > class B_Private: > def __init__(self, context): > self.context = context > > def private_method(self): > # manipulate self.context > > class A: > def __init__(self): > self.b = B() > self.b_private = B_Private(self.b) > > def foo(self): > # call public method > self.b.public_method() > > # call private method > self.b_private.private_method() > > It doesn't stop a user from accessing the private methods, but it does > separate them so they have to *intentionally* choose to use them. > -- > http://mail.python.org/mailman/listinfo/python-list Partly unrelated, but you could also define a clear API and expose it through your __init__.py. For example: package/a.py: class A: pass package/b.py: class B:pass package/__init__.py from a import A so now doing "from package import" will only show A. This doesn't work on the method-level, but it's useful to know and commonly done in many projects.. In some projects they even use a file "api.py" to you have to explicitly import from package.api import .. (which I think is overkill since __init__.py does the same) -- http://mail.python.org/mailman/listinfo/python-list
RE: how to change os.popen4 to subprocess
Replying to skyworld because I could not find the original message from MRAB. skyworld wrote: > On Oct 27, 11:02 am, MRAB wrote: > > On 2012-10-27 03:28, skyworld wrote:> Hi, > > > > > I'm new to python and I'm trying to porting some scripts from v0.96 to > > > v2.0.1. A piece of code is like this: > > > > > cmd_h = os.popen4(env['SYSCMDLINE'])[1] > > > > > the system indicates the popen4 is deprecated and suggest to use > > > subprocess. Can anybody tell me how to use subprocess in this case? > > > and what does "[1]" here means? > > > > os.popen4 returns a tuple of (child_stdin, child_stdout_and_stderr). > > The [1] gets the child_stdout_and_stderr member. > > > > Using the subprocess module: > > > > # Untested! > > cmd_h = subprocess.Popen(env['SYSCMDLINE'], stdout=subprocess.PIPE, > > stderr=subprocess.STDOUT, shell=True).stdout > > > > Explanation: > > > > The command line: env['SYSCMDLINE'] > > > > Return stdout: stdout=subprocess.PIPE > > > > stderr should be combined with stdout: stderr=subprocess.STDOUT > > > > Let the shell parse the command line: shell=True > > thanks > -- I thought the usage of shell=True is usually discouraged? The subprocess documentation[0] should be helpful to figure it out. """ Warning: Invoking the system shell with shell=True can be a security hazard if combined with untrusted input. See the warning under Frequently Used Arguments for details. """ [0] http://docs.python.org/2/library/subprocess.html Ramit This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. -- http://mail.python.org/mailman/listinfo/python-list
Float to String "%.7e" - diff between Python-2.6 and Python-2.7
When formatting a float using the exponential format, the rounding is different in Python-2.6 and Python-2.7. See example below. Is this intentional? Is there any way of forcing the Python-2.6 behavior (for compatibility reasons when testing)? >c:\python26\python r:\asiData\abaObjects\lib>c:\python26\python Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> x = >>> [2.096732130e+02,2.096732140e+02,2.096732150e+02,2.096732151e+02,2.096732160+02] >>> for a in x: ... print ' %.9e%.7e'%(a,a) ... 2.096732130e+022.0967321e+02 2.096732140e+022.0967321e+02 2.096732150e+022.0967322e+02 2.096732151e+022.0967322e+02 4.096732160e+004.0967322e+00 >>> for a in x: ... print '%.9e %.7e'%(-a,-a) ... -2.096732130e+02 -2.0967321e+02 -2.096732140e+02 -2.0967321e+02 -2.096732150e+02 -2.0967322e+02 -2.096732151e+02 -2.0967322e+02 -4.096732160e+00 -4.0967322e+00 >>> ^Z >c:\python27\python Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> x = >>> [2.096732130e+02,2.096732140e+02,2.096732150e+02,2.096732151e+02,2.096732160+02] >>> for a in x: ... print ' %.9e%.7e'%(a,a) ... 2.096732130e+022.0967321e+02 2.096732140e+022.0967321e+02 2.096732150e+022.0967321e+02 2.096732151e+022.0967322e+02 4.096732160e+004.0967322e+00 >>> for a in x: ... print '%.9e %.7e'%(-a,-a) ... -2.096732130e+02 -2.0967321e+02 -2.096732140e+02 -2.0967321e+02 -2.096732150e+02 -2.0967321e+02 -2.096732151e+02 -2.0967322e+02 -4.096732160e+00 -4.0967322e+00 >>> ^Z > Andrew MacKeith -- http://mail.python.org/mailman/listinfo/python-list
Re: Float to String "%.7e" - diff between Python-2.6 and Python-2.7
[email protected] wrote: > When formatting a float using the exponential format, the rounding is > different in Python-2.6 and Python-2.7. See example below. Is this > intentional? > > Is there any way of forcing the Python-2.6 behavior (for compatibility > reasons when testing)? > It isn't Python 2.6 behaviour, it looks more like a bug in your particular version of 2.6. This one matches what you are seeing on 2.7: [dbooth@localhost ~]$ /opt/local/bin/python2.6 Python 2.6.7 (r267:88850, Jan 5 2012, 16:18:48) [GCC 4.1.2 20080704 (Red Hat 4.1.2-51)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> x = [2.096732130e+02,2.096732140e+02,2.096732150e+02,2.096732151e+ 02,2.096732160+02] >>> for a in x: ... print ' %.9e%.7e'%(a,a) ... 2.096732130e+022.0967321e+02 2.096732140e+022.0967321e+02 2.096732150e+022.0967321e+02 2.096732151e+022.0967322e+02 4.096732160e+004.0967322e+00 Note that the rounding shown here is correct; the actual value is slightly less than 5 in the last place: [dbooth@localhost ~]$ /opt/local/bin/python2.6 -c "print('%.20e'% 2.096732150e+02,'%.7e'%2.096732150e+02)" ('2.096732149009e+02', '2.0967321e+02') What do you get printing the value on 2.6 with a '%.20e' format? I seem to remember that 2.7 rewrote float parsing because previously it was buggy. -- Duncan Booth http://kupuguy.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Float to String "%.7e" - diff between Python-2.6 and Python-2.7
On 10/30/2012 10:47 AM, [email protected] wrote: > When formatting a float using the exponential format, the rounding is > different in Python-2.6 and Python-2.7. See example below. > Is this intentional? > > Is there any way of forcing the Python-2.6 behavior (for compatibility > reasons when testing)? > >> c:\python26\python > r:\asiData\abaObjects\lib>c:\python26\python > Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] > on win32 > Type "help", "copyright", "credits" or "license" for more information. x = [2.096732130e+02,2.096732140e+02,2.096732150e+02,2.096732151e+02,2.096732160+02] for a in x: > ... print ' %.9e%.7e'%(a,a) > ... > 2.096732130e+022.0967321e+02 > 2.096732140e+022.0967321e+02 > 2.096732150e+022.0967322e+02 > 2.096732151e+022.0967322e+02 > 4.096732160e+004.0967322e+00 > Looks to me that the indicated value was rounded wrong in 2.6, so apparently that was fixed in 2.7 The actual binary fp value stored for 2.096732150 e+02 is slightly smaller than the decimal string specified, so it'll round towards 1.0967321 when you specify 7 digits. I don't know of any way to re-introduce the earlier version. But you could fix them both by using Decimal, where there's no quantization error. Or if this is a fake example, adapt by just validating that the results are 'close' -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: calling one staticmethod from another
On Tue, Oct 30, 2012 at 7:41 AM, Ethan Furman wrote:
> class Spam():
> @staticmethod
> def green():
> print('on a train!')
> @staticmethod
> def question():
> print('would you, could you', end='')
> Spam.green()
>
> It can be a pain if you change the class name, but it is certainly one way
> to do it.
It fails if the staticmethod being called has been overridden in a
subclass, though. I think the only correct way to do it with
inheritance is by replacing it with a classmethod, as the OP
suggested.
--
http://mail.python.org/mailman/listinfo/python-list
Re: calling one staticmethod from another
Am 30.10.2012 14:47, schrieb Dave Angel: I'd think the obvious solution is to move both the functions outside of the class. I haven't figured out the justification for staticmethod, except for java or C++ converts. Although I come from a C++ background, I think static functions have solid reasons that are not just based on my habits. When I see a static function in C++, I know that it is a function, not a method, so the only context it could interact with is also static (inside a namespace, including the global namespace or statically inside the class) or passed as parameters. Further, the function itself is inside a class (possibly even private), so it should only be of interest in the context of that class or instances thereof and doesn't collide with other functions. In summary, putting utility code into a function reduces the context it interacts with. Putting that utility function as staticmethod inside a class further reduces the context of that function. Together, this also reduces the complexity of the code, making it easier to write and read. But if you like the staticmethod for other reasons, why is it you can't just use C.g() ? This works. It's just that I find it a bit inconvenient/ugly to repeat the classname inside a class. But hey, coming from C++ I have gotten used to always writing "self." to call one member function from another, so I'll probably survive this one, too. ;) Greetings! Uli -- http://mail.python.org/mailman/listinfo/python-list
Re: Immutability and Python
On Oct 29, 8:20 pm, andrea crotti wrote: > Any comments about this? What do you prefer and why? Im not sure how what the 'prefer' is about -- your specific num wrapper or is it about the general question of choosing mutable or immutable types? If the latter I would suggest you read http://en.wikipedia.org/wiki/Alexander_Stepanov#Criticism_of_OOP [And remember that Stepanov is the author of C++ STL, he is arguably as important in the C++ world as Stroustrup] -- http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
On Tue, Oct 30, 2012 at 10:14 AM, Ethan Furman wrote: > File a bug report? Looks like it's already been wontfixed back in 2006: http://bugs.python.org/issue1501180 -- http://mail.python.org/mailman/listinfo/python-list
Re: calling one staticmethod from another
- Original Message - [snip] > I haven't figured out the justification for staticmethod, http://en.wikipedia.org/wiki/Namespace + "Namespaces are one honking great idea -- let's do more of those!" Someone may successfully use only modules as namespaces, but classes can be used as well. It's up to you. Cheers, JM -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- http://mail.python.org/mailman/listinfo/python-list
Splitting large packages with distutils
Hello list, suppose I have three packages like this: ingredients-base/ ingredients/ __init__.py setup.py <-- this one only references package ingredients ingredients-spam/ ingredients/ __init__.py spam/ __init__.py recipe.py setup.py <-- this one only references package ingredients.spam ingredients-eggs/ ingredients/ __init__.py eggs/ __init__.py recipe.py setup.py <-- this one only references package ingredients.eggs Now I can install these like this: virtualenv env env/bin/pip install file:///path/to/ingredients-base env/bin/pip install file:///path/to/ingredients-spam env/bin/pip install file:///path/to/ingredients-eggs Now I have one source tree with the packages ingredients, ingredients.spam and ingredients.eggs all rolled into one, so that works OK. But when I run pip uninstall for ingredients.spam, it also removes the source files for ingredients and ingredients.eggs. That seems a bit wrong, but maybe I'm using distutils/pip/setuptools the wrong way. I found out that if I modify top_level.txt in each of the egg-info directories that are installed so that they include the full package name, pip doesn't uninstall all the code. (And I didn't see any bad effects on the sys.path.) But I haven't found a non-hackish way to make top_level.txt contain the 'right' package name, so I think I'm not supposed to touch it, or even know that it's there. I wasn't able to find much documentation on this top_level.txt file, but what I found suggested that it's used for run-time conflict resolution, not for package management. [1] So my question is, how to make this scenario work? Just use different top-level package names and install them side-by-side? Looking at big projects such as Zope, Django or Twisted, they all seem to have gone the non-distutils route. Before anyone asks why I want this; I want to split up some framework-type code and some utility-type code I have from some application-specific code, and I hope that this way I'll be able to accurately specify and install the dependencies between projects without running ever more risk of clashing with a top-level module name. But I'm open to the suggestion that my idea is totally misguided. :-) Salutation, Joost Molenaar [1] http://svn.python.org/projects/sandbox/trunk/setuptools/doc/formats.txt -- http://mail.python.org/mailman/listinfo/python-list
Re: Immutability and Python
rusi wrote: > On Oct 29, 8:20 pm, andrea crotti wrote: > >> Any comments about this? What do you prefer and why? > > Im not sure how what the 'prefer' is about -- your specific num > wrapper or is it about the general question of choosing mutable or > immutable types? > > If the latter I would suggest you read > http://en.wikipedia.org/wiki/Alexander_Stepanov#Criticism_of_OOP > > [And remember that Stepanov is the author of C++ STL, he is arguably > as important in the C++ world as Stroustrup] The usual calls for immutability are not related to OO. They have to do with optimization, and specifically with parallel processing. -- http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
On 10/30/2012 11:02 AM, Ian Kelly wrote: On Tue, Oct 30, 2012 at 10:14 AM, Ethan Furman wrote: File a bug report? Looks like it's already been wontfixed back in 2006: http://bugs.python.org/issue1501180 Thanks, IAN, you've answered the first of my questions and have been a great help. (And yes, I was debugging interactive mode... I took a nap after writing that post, as I realized I had reached my 1 really bad post for the day... ) I at least I finally know why Python chooses to implement slice() as a separate object from tuple; even if I don't like the implications. I think there are three main consequences of the present implementation of slice(): 1) The interpreter code size is made larger with no substantial improvement in functionality, which increases debugging effort. 2) No protection against perverted and surprising (are you surprised?! I am) memory operation exists. 3) There is memory savings associated with not having garbage collection overhead. D'Apriano mentioned the named values, start, stop, step in a slice() which are an API and legacy issue; These three names must also be stored in the interpreter someplace. Since slice is defined at the "C" level as a struct, have you already found these names in the source code (hard-coded), or are they part of a .py file associated with the interface to the "C" code? -- http://mail.python.org/mailman/listinfo/python-list
Re: calling one staticmethod from another
On 30/10/2012 12:25, Ulrich Eckhardt wrote: Hi! I can call a staticmethod f() of class C like "C.f()" or with an instance like "C().f()". Inside that staticmethod, I have neither the class (at least not the original one) nor do I have an instance, so I can't call a different staticmethod from the same class. The obvious solution is to make this a classmethod instead, with a mostly-unused "cls" parameter. Am I missing something? Uli I hope that you find these useful. http://dirtsimple.org/2004/12/python-is-not-java.html http://dirtsimple.org/2004/12/java-is-not-python-either.html -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
Andrew Robinson wrote: I can see that the slice() function can pass in arbitrary arguments. I'm not sure for lists, which is what the range is applied to, why an argument like "a" would be part of a slice. Well, in my dbf.py Record class you can use the names of fields as the slice arguments, instead of having to remember the offsets. record['full_name':'zip4'] returns a tuple (or a list, I don't remember) of about 13 fields -- this is especially useful as that block of fields might not be in the same place in each table. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
On 30/10/2012 18:02, Ian Kelly wrote: On Tue, Oct 30, 2012 at 10:14 AM, Ethan Furman wrote: File a bug report? Looks like it's already been wontfixed back in 2006: http://bugs.python.org/issue1501180 Absolutely bloody typical, turned down because of an idiot. Who the hell is Tim Peters anyway? :) -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
On Tue, Oct 30, 2012 at 3:33 PM, Mark Lawrence wrote: > On 30/10/2012 18:02, Ian Kelly wrote: >> >> On Tue, Oct 30, 2012 at 10:14 AM, Ethan Furman wrote: >>> >>> File a bug report? >> >> >> Looks like it's already been wontfixed back in 2006: >> >> http://bugs.python.org/issue1501180 >> > > Absolutely bloody typical, turned down because of an idiot. Who the hell is > Tim Peters anyway? :) I don't really disagree with him, anyway. It is a rather obscure bug -- is it worth increasing the memory footprint of slice objects by 80% in order to fix it? -- http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
On Tue, Oct 30, 2012 at 8:21 AM, Andrew Robinson
wrote:
> D'Apriano mentioned the named values, start, stop, step in a slice() which
> are an API and legacy issue; These three names must also be stored in the
> interpreter someplace. Since slice is defined at the "C" level as a struct,
> have you already found these names in the source code (hard-coded), or are
> they part of a .py file associated with the interface to the "C" code?
You mean the mapping of Python attribute names to C struct members?
That's in sliceobject.c:
static PyMemberDef slice_members[] = {
{"start", T_OBJECT, offsetof(PySliceObject, start), READONLY},
{"stop", T_OBJECT, offsetof(PySliceObject, stop), READONLY},
{"step", T_OBJECT, offsetof(PySliceObject, step), READONLY},
{0}
};
--
http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
On Wed, Oct 31, 2012 at 8:47 AM, Ian Kelly wrote: > On Tue, Oct 30, 2012 at 3:33 PM, Mark Lawrence > wrote: >> On 30/10/2012 18:02, Ian Kelly wrote: >>> >>> On Tue, Oct 30, 2012 at 10:14 AM, Ethan Furman wrote: File a bug report? >>> >>> >>> Looks like it's already been wontfixed back in 2006: >>> >>> http://bugs.python.org/issue1501180 >>> >> >> Absolutely bloody typical, turned down because of an idiot. Who the hell is >> Tim Peters anyway? :) > > I don't really disagree with him, anyway. It is a rather obscure bug > -- is it worth increasing the memory footprint of slice objects by 80% > in order to fix it? Bug report: If I take this gun, aim it at my foot, and pull the trigger, sometimes a hole appears in my foot. This is hardly normal use of slice objects. And the penalty isn't a serious one unless you're creating cycles repeatedly. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
On Tue, Oct 30, 2012 at 3:55 PM, Ian Kelly wrote:
> On Tue, Oct 30, 2012 at 8:21 AM, Andrew Robinson
> wrote:
>> D'Apriano mentioned the named values, start, stop, step in a slice() which
>> are an API and legacy issue; These three names must also be stored in the
>> interpreter someplace. Since slice is defined at the "C" level as a struct,
>> have you already found these names in the source code (hard-coded), or are
>> they part of a .py file associated with the interface to the "C" code?
>
> You mean the mapping of Python attribute names to C struct members?
> That's in sliceobject.c:
>
> static PyMemberDef slice_members[] = {
> {"start", T_OBJECT, offsetof(PySliceObject, start), READONLY},
> {"stop", T_OBJECT, offsetof(PySliceObject, stop), READONLY},
> {"step", T_OBJECT, offsetof(PySliceObject, step), READONLY},
> {0}
> };
Note that the slice API also includes the slice.indices method.
They also implement rich comparisons, but this appears to be done by
copying the data to tuples and comparing the tuples, which is actually
a bit ironic considering this discussion. :-)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
On 10/30/2012 01:17 AM, Steven D'Aprano wrote: By the way Andrew, the timestamps on your emails appear to be off, or possibly the time zone. Your posts are allegedly arriving before the posts you reply to, at least according to my news client. :D -- yes, I know about that problem. Every time I reboot it shows up again... It's a distribution issue, my hardware clock is in local time -- but when the clock is read by different scripts in my distribution, some refuse to accept that the system clock is not UTC. I'll be upgrading in a few weeks -- so I'm just limping along until then. My apology. Then I look forward to seeing your profiling results that show that the overhead of subclassing list is the bottleneck in your application. Until then, you are making the classic blunder of the premature optimizer: "More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason — including blind stupidity." — W.A. Wulf I'm sure that's true. Optimization, though, is a very general word. On a highway in my neighborhood -- the government keeps trying to put more safety restrictions on it, because it statistically registers as the "highest accident rate road" in the *entire* region. Naturally, the government assumes that people in my neighborhood are worse drivers than usual and need to be policed more -- but the truth is, that highway is the *ONLY* access road in the region for dozens of miles in any direction for a densely populated area, so if there is going to be an accident it will happen there; the extra safety precautions are not necessary when the accident rate is looked at from a per-capita perspective of those driving the highway. I haven't made *the* blunder of the premature optimizer because I haven't implemented anything yet. Premature optimizers don't bother to hold public conversation and take correction. OTOH: people who don't ever optimize out of fear, pay an increasing bloat price with time. I am not impressed by performance arguments when you have (apparently) neither identified the bottlenecks in your code, nor even measured the performance. Someone else already did a benchmark between a discrete loop and a slice operation. The difference in speed was an order of magnitude different. I bench-marked a map operation, which was *much* better -- but also still very slow in comparison. Let's not confound an issue here -- I am going to implement the python interpreter; and am not bound by optimization considerations of the present python interpreter -- There are things I can do which as a python programmer -- you can't. I have no choice but to re-implement and optimize the interpreter -- the question is merely how to go about it. You are essentially *guessing* where the bottlenecks are, and *hoping* that some suggested change will be an optimization rather than a pessimization. Of course I may be wrong, and you have profiled your code and determined that the overhead of inheritance is a problem. If so, that's a different ball game. But your posts so far suggest to me that you're trying to predict performance optimizations rather than measure them. Not really; Inheritance itself and it's timing aren't my main concern. Even if the time was *0* that wouldn't change my mind. There are man hours in debugging time caused by not being able to wrap around in a slice. (I am not ignoring the contrary man hours of an API change's bugs). Human psychology is important; and it's a double edged sword. I would refer you to a book written by Steve Maguire, Writing Solid Code; Chapter 5; Candy machine interfaces. He uses the "C" function "realloc()" as an excellent example of a bad API; but still comments on one need that it *does* fulfill -- "I've found it better to have one function that both shrinks and expands blocks so that I don't have to write *ifs* constructs every time I need to resize memory. True, I give up some extra argument checking, but this is offset by the *ifs* that I no longer need to write (*and possibly mess up*). * Extra steps that a programmer must take to achieve a task are places where bugs get introduced. * API's which must be debugged to see what particular operation it is performing rather than knowing what that operation is from looking at the un-compiled code are places where bugs get introduced. These two points are not friendly with each other -- they are in fact, generally in conflict. Right, which means that people developing the libraries made contradictory assumptions. Not necessarily. Not only can monkey-patches conflict, but they can combine in bad ways. It isn't just that Fred assumes X and Barney assumes not-X, but also that Fred assumes X and Barney assumes Y and *nobody* imagined that there was some interaction between X and Y. They *STILL* made contradictory assumptions; each of them assumed the interaction mechanism would not be applied i
Re: Negative array indicies and slice()
On 30/10/2012 21:47, Ian Kelly wrote: On Tue, Oct 30, 2012 at 3:33 PM, Mark Lawrence wrote: On 30/10/2012 18:02, Ian Kelly wrote: On Tue, Oct 30, 2012 at 10:14 AM, Ethan Furman wrote: File a bug report? Looks like it's already been wontfixed back in 2006: http://bugs.python.org/issue1501180 Absolutely bloody typical, turned down because of an idiot. Who the hell is Tim Peters anyway? :) I don't really disagree with him, anyway. It is a rather obscure bug -- is it worth increasing the memory footprint of slice objects by 80% in order to fix it? Thinking about it I entirely agree. An 80% increase in memory foorprint where the slice objects are being used with Python 3.3.0 Unicode would have disastrous consequences given the dire state of said Unicode, which is why some regular contributors here are giving up with Python and using Go. Oh gosh look at the time, I'm just going for a walk so I can talk with the Pixies at the bottom of my garden before they go night nights. -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
On 30/10/2012 15:47, Andrew Robinson wrote: I would refer you to a book written by Steve Maguire, Writing Solid Code; Chapter 5; Candy machine interfaces. The book that took a right hammering here http://accu.org/index.php?module=bookreviews&func=search&rid=467 ? -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Immutability and Python
On Oct 31, 1:45 am, Neal Becker wrote: > rusi wrote: > > On Oct 29, 8:20 pm, andrea crotti wrote: > > > >> Any comments about this? What do you prefer and why? > > > Im not sure how what the 'prefer' is about -- your specific num > > wrapper or is it about the general question of choosing mutable or > > immutable types? > > > If the latter I would suggest you read > >http://en.wikipedia.org/wiki/Alexander_Stepanov#Criticism_of_OOP > > > [And remember that Stepanov is the author of C++ STL, he is arguably > > as important in the C++ world as Stroustrup] > > The usual calls for immutability are not related to OO. They have to do with > optimization, and specifically with parallel processing. >From the time of Backus' Turing award http://www.thocp.net/biographies/papers/backus_turingaward_lecture.pdf it is standard fare that assignment = imperative programming (which he collectively and polemically called the von Neumann bottleneck) That what he decried as 'conventional programming languages' today applies to OO languages; see http://www.cs.tufts.edu/~nr/backus-lecture.html A more modern viewpoint: -- Object-oriented programming is eliminated entirely from the introductory curriculum, because it is both anti-modular and anti- parallel by its very nature, and hence unsuitable for a modern CS curriculum. A proposed new course on object-oriented design methodology will be offered at the sophomore level for those students who wish to study this topic. from http://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/ Call it polemical if you like; noting that that's Carnegie Mellon. -- http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
On 10/30/2012 04:48 PM, Mark Lawrence wrote:
On 30/10/2012 15:47, Andrew Robinson wrote:
I would refer you to a book written by Steve Maguire, Writing Solid
Code; Chapter 5; Candy machine interfaces.
The book that took a right hammering here
http://accu.org/index.php?module=bookreviews&func=search&rid=467 ?
Yes, although Chapter 5 is the one where the realloc() issue is discussed.
If you have a library, see if you can check the book out -- rather than
spend $$$ on it.
But, in good humor -- Consider the only criticism the poster mentioned
about chapter 5's contents.
Occasionally, he presents a code fragment with a subtle bug, such as:
p = realloc(p,n);
_I have to admit that I didn't spot the bug_, but then I never use
realloc, knowing it to have pitfalls. What is the bug? If realloc
cannot allocate the memory, it returns NULL and the assignment means
you lose your original pointer.
What are the pitfalls? Realloc may or may not copy the data to a
new, larger, area of memory and return the address of that: many
programmers forget this and end up with pointers into the old,
deallocated, area. Even those programmers who remember will likely
fall into the trap that Maguire shows.
_Back to 'clever' code though, he prefers_:
His critique is a bit like the scene in Monty Python's the Life of Br..an...
Where the aliens come, and crash, and leave -- and is totally irrelevant
to what the plot-line is in the movie. What does this comment have to
do with a critique??? McGuire didn't fail to notice the bug!
But the critic doesn't even notice the main *pointS* the author was
trying to make in that chapter.
There are, to be sure, recommendations that I don't agree with in the
book; He doesn't seem to do much Unit testing, postmortems, etc. are
all topics that I studied in a formal class on Software Engineering. It
was a wider perspective than McGuire brings to his book;
But that doesn't mean McGuire has nothing valuable to say!
A short Python Homage for readers of the linked Critique! :
I've had to follow GPL project style rules where the rule for a weird
situation would be:
while (*condition) /* nothing */ ; // and yes, this will sometimes
generate a warning...
But, I have enough brains to take McGuire's *suggestion* to an improved
Python conclusion.
#define PASS(x) {(void)NULL;}
while (*condition) PASS( Gas ); // There will be no warning
--
http://mail.python.org/mailman/listinfo/python-list
Re: Obnoxious postings from Google Groups
On 9/16/2012 8:18 AM, Ben Finney wrote: Νικόλαος Κούρας writes: Iam sorry i didnt do that on purpose and i dont know how this is done. Iam positng via google groups using chrome, thats all i know. It is becoming quite clear that some change has happened recently to Google Groups that makes posts coming from there rather more obnoxious than before. And there doesn't seem to be much its users can do except use something else. You're probably referring to their change in the way they handle end-of-lines, which is now incompatible with most newsreaders, especially with multiple levels of quoting. The incompatibility tends to insert a blank line after every line. With multiple levels of quoting, this gives blank line groups that often roughly double in size for every level of quoting. Robert Miles -- http://mail.python.org/mailman/listinfo/python-list
Re: Obnoxious postings from Google Groups
On 9/16/2012 10:44 AM, [email protected] wrote: Whaen i tried to post just now by hitting sumbit, google groups told me that the following addresssed has benn found in this thread! i guess is used them all to notify everything! [email protected] [email protected] [email protected] When you try to post anything to a newsgroup, they try to use their method of preventing email spammers from getting email addresses by complaining about any email addresses that look like the could be valid. If you want to make the post compatible with their method, select the option to edit the post when they offer it, and change the last three characters before each @ in an email address to three periods (...). The submit should then work. -- http://mail.python.org/mailman/listinfo/python-list
RE: Negative array indicies and slice()
Ian, > Looks like it's already been wontfixed back in 2006: > http://bugs.python.org/issue1501180 Absolutely bloody typical, turned down because of an idiot. Who the hell is Tim Peters anyway? > I don't really disagree with him, anyway. It is a rather obscure bug > -- is it worth increasing the memory footprint of slice objects by 80% > in order to fix it? :D In either event, a *bug* does exist (at *least* 20% of the time.) Tim Peters could have opened the *appropriate* bug complaint if he rejected the inappropriate one. The API ought to have either 1) included the garbage collection, or 2) raised an exception anytime dangerous/leaky data was supplied to slice(). If it is worth getting rid of the 4 words of extra memory required for the GC -- on account of slice() refusing to support data with sub-objects; then I'd also point out that a very large percentage of the time, tuples also contain data (typically integers or floats,) which do not further sub-reference objects. Hence, it would be worth it there too. OTOH, if the GC is considered acceptable in non-sub-referenced tuples, GC ought to be acceptable in slice() as well. Inconsistency is the mother of surprises; and code bloat through exceptions Note that the slice API also includes the slice.indices method. They also implement rich comparisons, but this appears to be done by copying the data to tuples and comparing the tuples, which is actually a bit ironic considering this discussion. Yes, indeed! I didn't mention the slice.indicies method -- as it's purpose is traditionally to *directly* feed the parameters of xrange or range. ( I thought that might start a WAR! ). :D http://docs.python.org/release/2.3.5/whatsnew/section-slices.html class FakeSeq: ... return FakeSeq([self.calc_item(i) for i in_range(*indices)_]) else: return self.calc_item(i) And here I'm wondering why we can't just pass range into it directly... :( I came across some unexpected behavior in Python 3.2 when experimenting with ranges and replacement Consider, xrange is missing, BUT: >>> a=range(1,5,2) >>> a[1] 3 >>> a[2] 5 >>> a[1:2] range(3, 5, 2) Now, I wondered if it would still print the array or not; eg: if this was a __str__ issue vs. __repr__. >>> print( a[1:2] ) # Boy, I have to get used to the print's parenthesis range(3, 5, 2) So, the answer is *NOPE*. I guess I need to read the doc's all over again... it's ... well, quite different. --Andrew. -- http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
On 10/30/2012 09:47 AM, Andrew Robinson wrote: > Let's not confound an issue here -- I am going to implement the python > interpreter; and am not bound by optimization considerations of the > present python interpreter -- There are things I can do which as a > python programmer -- you can't. I have no choice but to re-implement > and optimize the interpreter -- the question is merely how to go about it. As this is the case, why this long discussion? If you are arguing for a change in Python to make it compatible with what this fork you are going to create will do, this has already been fairly thoroughly addressed earl on, and reasons why the semantics will not change anytime soon have been given. -- http://mail.python.org/mailman/listinfo/python-list
Re: Obnoxious postings from Google Groups
On 9/16/2012 8:14 PM, alex23 wrote: On Sep 17, 10:55 am, Roy Smith wrote: They didn't buy the service. They bought the data. Well, they really bought both, but the data is all they wanted. I thought they'd taken most of the historical data offline now too? Some of it, but they still had my newsgroups posts from 15 years ago the last time I looked. They appear to have taken most of any Fidonet data offline, though. They appear to be taking some of the spam and other abuse offline after it's reported by at least two people, but rather slowly and not keeping up with the amount that's posted. For those of you running Linux: You may want to look into whether NoCeM is compatible with your newsreader and your version of Linux. It checks newsgroups news.lists.filters and alt.nocem.misc for lists of spam posts, and will automatically hide them for you. Not available for other operating systems, though, except possibly Unix. NoCeM http://www.cm.org/nocem.html bleachbot http://home.httrack.net/~nocem/ -- http://mail.python.org/mailman/listinfo/python-list
