Re: sort order for strings of digits
Le mercredi 31 octobre 2012 16:17:19 UTC+1, djc a écrit :
> I learn lots of useful things from the list, some not always welcome. No
>
> sooner had I found a solution to a minor inconvenience in my code, than
>
> a recent thread here drew my attention to the fact that it will not work
>
> for python 3. So suggestions please:
>
>
>
> TODO 2012-10-22: sort order numbers first then alphanumeric
>
> >>> n
>
> ('1', '10', '101', '3', '40', '31', '13', '2', '2000')
>
> >>> s
>
> ('a', 'ab', 'acd', 'bcd', '1a', 'a1', '222 bb', 'b a 4')
>
>
>
> >>> sorted(n)
>
> ['1', '10', '101', '13', '2', '2000', '3', '31', '40']
>
> >>> sorted(s)
>
> ['1a', '222 bb', 'a', 'a1', 'ab', 'acd', 'b a 4', 'bcd']
>
> >>> sorted(n+s)
>
> ['1', '10', '101', '13', '1a', '2', '2000', '222 bb', '3', '31', '40',
>
> 'a', 'a1', 'ab', 'acd', 'b a 4', 'bcd']
>
>
>
>
>
>
>
> Possibly there is a better way but for Python 2.7 this gives the
>
> required result
>
>
>
> Python 2.7.3 (default, Sep 26 2012, 21:51:14)
>
>
>
> >>> sorted(int(x) if x.isdigit() else x for x in n+s)
>
> [1, 2, 3, 10, 13, 31, 40, 101, 2000, '1a', '222 bb', 'a', 'a1', 'ab',
>
> 'acd', 'b a 4', 'bcd']
>
>
>
>
>
> [str(x) for x in sorted(int(x) if x.isdigit() else x for x in n+s)]
>
> ['1', '2', '3', '10', '13', '31', '40', '101', '2000', '1a', '222 bb',
>
> 'a', 'a1', 'ab', 'acd', 'b a 4', 'bcd']
>
>
>
>
>
> But not for Python 3
>
> Python 3.2.3 (default, Oct 19 2012, 19:53:16)
>
>
>
> >>> sorted(n+s)
>
> ['1', '10', '101', '13', '1a', '2', '2000', '222 bb', '3', '31', '40',
>
> 'a', 'a1', 'ab', 'acd', 'b a 4', 'bcd']
>
>
>
> >>> sorted(int(x) if x.isdigit() else x for x in n+s)
>
> Traceback (most recent call last):
>
>File "", line 1, in
>
> TypeError: unorderable types: str() < int()
>
> >>>
>
>
>
> The best I can think of is to split the input sequence into two lists,
>
> sort each and then join them.
>
>
>
>
>
> --
>
> djc
>>> # Py 3.2.3
>>> z = ['1', '10', '101', '13', '1a', '2', '2000',
... '222 bb', '3', '31', '40', 'a', 'a1', 'ab',
... 'acd', 'b a 4', 'bcd'
... ]
>>> n, s = [], []
>>> for e in z:
... if e.isdigit():
... n.append(int(e))
... else:
... s.append(e)
...
>>> n.sort()
>>> s.sort()
>>> ns = [str(e) for e in n]
>>> ns.extend(s)
>>> ns
['1', '2', '3', '10', '13', '31', '40', '101', '2000', '1a',
'222 bb', 'a', 'a1', 'ab', 'acd', 'b a 4', 'bcd']
jmf
--
http://mail.python.org/mailman/listinfo/python-list
python and Open cv
How to load a yml file in python and work with it ??
I used : import cv
data = cv.Load("Z:/data/xyz_0_
300.yml")
But when I print data.. it just gives the detail of the image like number
of rows and columns etc
I want read what is there in the pixel of the image..
I tried to use the following code .. but it gives me only the pixel values
not the information contained in pixel ??
def AccessPixels(img):
for y in range(0, img.height):
for x in range(0, img.width):
cv.Get2D(img, y, x) # Slow get pixel value.
cv.Set2D(img, y, x, (0, 0, 0, 0)) # Slow set pixel value.
can somebody help.. thanx in advance !!!
--
http://mail.python.org/mailman/listinfo/python-list
Re: Obnoxious postings from Google Groups
/ Robert Miles wrote on Wed 31.Oct'12 at 0:39:02 -0500 / > 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. Anybody serious about programming should be using a form of UNIX/Linux if you ask me. It's inconceivable that these systems should be avoided if you're serious about Software Engineering and Computer Science, etc. For UNIX there are loads of decent news reading software and mail user agents to learn and use. slrn is a good one and point it at gmane.org as someone else pointed out. I can't even imagine using a browser or Google Groups, etc. now. -- http://mail.python.org/mailman/listinfo/python-list
Re: Obnoxious postings from Google Groups
/ Steven D'Aprano wrote on Wed 31.Oct'12 at 22:33:16 + / > On Wed, 31 Oct 2012 12:32:57 -0700, rurpy wrote: > I don't killfile merely for posting from Gmail or Google Groups, but > regarding your second point, it has seemed to me for some years now that > Gmail is the new Hotmail, which was the new AOL. Whenever there is an > inane, lazy, mind-numbingly stupid question or post, chances are > extremely high that the sender has a Gmail address. That's a bit harsh but then, sadly there's some truth in it. I subscribe to a number of technical mailing lists, like that of my OS OpenBSD and the problem doesn't exist there whether they use Gmail or Hotmail, etc, or not. This and the tutor python list are the two I have the most problems with formatting. Some people just don't seem to give a shit about sending horrid html and other irritating formatted mail in spite of being asked not to do so. -- http://mail.python.org/mailman/listinfo/python-list
Re: python and Open cv
On 01.11.2012, at 09:55, inshu chauhan wrote: > How to load a yml file in python and work with it ?? > Try one of these: http://pypi.python.org/pypi?%3Aaction=search&term=yaml&submit=search -- Stefan H. Holek ste...@epy.co.at -- http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
On 10/31/12 8:16 PM, Andrew Robinson wrote: On 10/31/2012 02:20 PM, Ian Kelly wrote: On Wed, Oct 31, 2012 at 7:42 AM, Andrew Robinson wrote: Then; I'd note: The non-goofy purpose of slice is to hold three data values; They are either numbers or None. These *normally* encountered values can't create a memory loop. So, FOR AS LONG, as the object representing slice does not contain an explicit GC pair; I move that we mandate (yes, in the current python implementation, even as a *fix*) that its named members may not be assigned any objects other than None or numbers eg: Lists would be forbidden Since functions, and subclasses, can be test evaluated by int( the_thing_to_try ) and *[] can too, generality need not be lost for generating nothing or numbers. PEP 357 requires that anything implementing the __index__ special method be allowed for slicing sequences (and also that __index__ be used for the conversion). For the most part, that includes ints and numpy integer types, but other code could be doing esoteric things with it. I missed something... (but then that's why we're still talking about it...) Reading the PEP, it notes that *only* integers (or longs) are permitted in slice syntax. (Overlooking None, of course... which is strange...) The PEP gives the only exceptions as objects with method "__index__". Automatically, then, an empty list is forbidden (in slice syntax). However, What you did, was circumvent the PEP by passing an empty list directly to slice(), and avoiding running it through slice syntax processing. Why do you think it is forbidden by the syntax? [~] |1> class A(object): ..> def __getitem__(self, key): ..> return key ..> [~] |2> a = A() [~] |3> a[[]:] slice([], None, None) The PEP is a little unclear and refers to a state of the Python interpreter that no longer exists. At the time, I think __getslice__() was still not deprecated, and it did require ints (or after the PEP, __index__able objects). __getslice__() is now deprecated in favor of __getitem__() where you can interpret slice objects with arbitrary objects to your heart's content. Arbitrary objects *are* definitely allowed by the slice syntax (how could the syntax know what is an int and what is another kind of object?). Most objects that interpret slices, especially the builtin sequence types, do require __index__able objects (or None). So, what's the psychology behind allowing slice() to hold objects which are not converted to ints/longs in the first place? In numpy, we (ab)use this freedom for some convenient notation in special objects. We have a couple of grid-making convenience objects: [~] |5> numpy.mgrid[1.5:2.5:0.1] array([ 1.5, 1.6, 1.7, 1.8, 1.9, 2. , 2.1, 2.2, 2.3, 2.4]) This syntax uses the start:stop:step notation to make a float range. If we use an imaginary integer in the "step" slot, mgrid will interpret it as the number of items requested instead of the step. [~] |6> numpy.mgrid[1.5:2.5:11j] array([ 1.5, 1.6, 1.7, 1.8, 1.9, 2. , 2.1, 2.2, 2.3, 2.4, 2.5]) -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: python and Open cv
On 01/11/2012 08:55, inshu chauhan wrote:
How to load a yml file in python and work with it ??
I used : import cv
data = cv.Load("Z:/data/xyz_0_
300.yml")
But when I print data.. it just gives the detail of the image like number
of rows and columns etc
I want read what is there in the pixel of the image..
I tried to use the following code .. but it gives me only the pixel values
not the information contained in pixel ??
def AccessPixels(img):
for y in range(0, img.height):
for x in range(0, img.width):
cv.Get2D(img, y, x) # Slow get pixel value.
cv.Set2D(img, y, x, (0, 0, 0, 0)) # Slow set pixel value.
can somebody help.. thanx in advance !!!
I think the subject should be changed to "Obnoxious postings from Google
Groups", given this is the same question from the same person within 24
hours but a different subject line, and from a gmail address.
--
Cheers.
Mark Lawrence.
--
http://mail.python.org/mailman/listinfo/python-list
Re: how to perform word sense disambiguation?
On 11/1/12 5:14 AM, nachiket wrote: an initial part of my project involves assigning sense to each word in sentence. I came across this tool called wordnet. do share your views You can get access to Wordnet and a wide variety of useful tools in NLTK: http://nltk.org/ http://nltk.org/book/ch06.html http://nltk.org/api/nltk.classify.html -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
Per community request turbogears and pysi were added. The following posts have been updated: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html http://mindref.blogspot.com/2012/10/python-web-pep8-consistency.html Comments or suggestions are welcome. Thanks. Andriy > From: andriy.kornats...@live.com > To: python-list@python.org > Subject: Fastest web framework > Date: Sun, 23 Sep 2012 12:19:16 +0300 > > > I have run recently a benchmark of a trivial 'hello world' application for > various python web frameworks (bottle, django, flask, pyramid, web.py, > wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find > it interesting: > > http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html > > Comments or suggestions are welcome. > > Thanks. > > Andriy Kornatskyy > > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: datetime issue
On 2012-10-31, ru...@yahoo.com wrote: > On 10/31/2012 09:11 AM, Grant Edwards wrote:> On 2012-09-16, ?? > wrote: >> >>> Iam positng via google groups using chrome, thats all i know. >> >> Learn something else. Google Groups is seriously and permanently >> broken, and all posts from Google Groups are filtered out and ignored >> by many people (including myself -- I only saw this because somebody >> else replied to it). > > Feel free to filter whatever you want but be aware than in > doing so you risk missing information that could help you > avoid disseminating erroneous info. Of course, carrying out > some kind of private war against Google Groups may be more > important to you than that... Based on past experience, the chances of useful information being posted via Google Groups is very small. The benefit of avoiding all the spam and garbage the comes from that source is more than worth the small risk of missing something worthwhile. Note that I'm _not_ talking about people posting to the mailing list using Gmail -- only people posting via the Google Groups web UI. -- Grant Edwards grant.b.edwardsYow! Four thousand at different MAGNATES, MOGULS gmail.com& NABOBS are romping in my gothic solarium!! -- http://mail.python.org/mailman/listinfo/python-list
Fwd: python and Open cv
-- Forwarded message --
From: inshu chauhan
Date: Thu, Nov 1, 2012 at 1:26 PM
Subject: Re: python and Open cv
To: Mark Lawrence
I am sorry.. but I need to know what are the rules and what about gmail ??
Many people are using gmail to mail to the list.
On Thu, Nov 1, 2012 at 12:15 PM, Mark Lawrence wrote:
> On 01/11/2012 08:55, inshu chauhan wrote:
>
>> How to load a yml file in python and work with it ??
>>
>> I used : import cv
>> data = cv.Load("Z:/data/xyz_0_
>> 300.yml")
>>
>> But when I print data.. it just gives the detail of the image like number
>> of rows and columns etc
>> I want read what is there in the pixel of the image..
>>
>> I tried to use the following code .. but it gives me only the pixel values
>> not the information contained in pixel ??
>>
>> def AccessPixels(img):
>> for y in range(0, img.height):
>> for x in range(0, img.width):
>> cv.Get2D(img, y, x) # Slow get pixel value.
>> cv.Set2D(img, y, x, (0, 0, 0, 0)) # Slow set pixel value.
>>
>>
>> can somebody help.. thanx in advance !!!
>>
>>
> I think the subject should be changed to "Obnoxious postings from Google
> Groups", given this is the same question from the same person within 24
> hours but a different subject line, and from a gmail address.
>
>
> --
> Cheers.
>
> Mark Lawrence.
>
> --
> http://mail.python.org/**mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
Andrew Robinson wrote: On 10/31/2012 02:20 PM, Ian Kelly wrote: On Wed, Oct 31, 2012 at 7:42 AM, Andrew Robinson wrote: Then; I'd note: The non-goofy purpose of slice is to hold three data values; They are either numbers or None. These *normally* encountered values can't create a memory loop. So, FOR AS LONG, as the object representing slice does not contain an explicit GC pair; I move that we mandate (yes, in the current python implementation, even as a *fix*) that its named members may not be assigned any objects other than None or numbers eg: Lists would be forbidden Since functions, and subclasses, can be test evaluated by int( the_thing_to_try ) and *[] can too, generality need not be lost for generating nothing or numbers. PEP 357 requires that anything implementing the __index__ special method be allowed for slicing sequences (and also that __index__ be used for the conversion). For the most part, that includes ints and numpy integer types, but other code could be doing esoteric things with it. I missed something... (but then that's why we're still talking about it...) Reading the PEP, it notes that *only* integers (or longs) are permitted in slice syntax. Keep in mind that PEPs represent Python /at that time/ -- as Python moves forward, PEPs are not updated (this has gotten me a couple times). The change would be backward-incompatible in any case, since there is certainly code out there that uses non-numeric slices -- one example has already been given in this thread. Hmmm. Now, I'm thinking -- The purpose of index(), specifically, is to notify when something which is not an integer may be used as an index; You've helpfully noted that index() also *converts* those objects into numbers. Ethan Fullman mentioned that he used the names of fields, "instead of having to remember the _offsets_"; Which means that his values _do convert_ to offset numbers Furman, actually. :) And my values do *not* convert to indices (at least, not automatically). My __getitem__ code looks like: elif isinstance(item, slice): sequence = [] if isinstance(item.start, (str, unicode)) \ or isinstance(item.stop, (str, unicode)): field_names = dbf.field_names(self) start, stop, step = item.start, item.stop, item.step if start not in field_names or stop not in field_names: raise MissingFieldError( "Either %r or %r (or both) are not valid field names" % (start, stop)) if step is not None and not isinstance(step, (int, long)): raise DbfError( "step value must be an int or long, not %r" % type(step)) start = field_names.index(start) stop = field_names.index(stop) + 1 item = slice(start, stop, step) for index in self._meta.fields[item]: sequence.append(self[index]) return sequence In other words, the slice contains the strings, and my code calculates the offsets -- Python doesn't do it for me. His example was actually given in slice syntax notation [::]. Hence, his objects must have an index() method, correct?. Nope. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
On Fri, Nov 2, 2012 at 1:12 AM, Ethan Furman wrote:
> In other words, the slice contains the strings, and my code calculates
> the offsets -- Python doesn't do it for me.
That's correct, but you're still translating those strings into
numeric indices. You can slice a database record based on column names
(though personally I would recommend against it - creates too much
dependence on column order, which I prefer to treat as
non-significant), but you can't, for instance, slice a dictionary by
keys:
foo = {"asdf":123,"qwer":234,"zxcv":345,"1234":456}
foo["qwer":"1234"] # What should this return?
I suppose conceptually you could slice any iterable by discarding till
you match the start, then yielding till you match the stop, then
returning (it'd function like itertools.islice but using non-numeric
indices - somehow). But it still depends on there being a dependable
order.
(Incidentally, isinstance(X, (str, unicode)) can become isinstance(X,
basestring) - they both inherit from that.)
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
pythonic way
what is the most pythonic way to do this : if 0 < ix < 10 and 0 < iy < 10 ??? -- http://mail.python.org/mailman/listinfo/python-list
How to remotely Automate GUI using pywinauto
Hi, Here I have a situation: I am trying to automate a GUI application and get some data from it. I tried using 'pywinauto' to launch the application and select the data and save it in -say notepad and later read it. This works fine when the script is locally run on the windows machine. My scenario is to do it remotely. What I have done is, keep the script in a location on windows machine and execute from a linux machine over SSH. The scripts gets Initiated but raises exception as below: File "C:\Python27\lib\site-packages\pywinauto\application.py", line 229, in __getattr__ ctrls = _resolve_control(self.criteria) File "C:\Python27\lib\site-packages\pywinauto\application.py", line 788, in _resolve_control raise e.original_exception Can anyone please tell me how to remotely Automate Windwos GUI using pywinauto , or there another better method. Thanks, Shambhu -- http://mail.python.org/mailman/listinfo/python-list
Re: pythonic way
On 2012-11-01 15:32, inshu chauhan wrote: what is the most pythonic way to do this : if 0 < ix < 10 and 0 < iy < 10 ??? That looks Pythonic to me, except for the missing colon. -- http://mail.python.org/mailman/listinfo/python-list
Re: pythonic way
On 11/01/12 10:32, inshu chauhan wrote: > what is the most pythonic way to do this : > >if 0 < ix < 10 and 0 < iy < 10 ??? What's wrong with the syntax you provide? It's perfectly pythonic: ix = 42 yx = 3.14159 if 0 < ix < 10 and 0 < iy < 10: do_stuff(ix, iy) else: do_other_stuff(ix, iy) -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: pythonic way
On 11/1/2012 11:32 AM, inshu chauhan wrote:
what is the most pythonic way to do this :
if 0 < ix < 10 and 0 < iy < 10 ???
end with : instead of ???
>>> ix, iy = 3,4
>>> if 0 < ix < 10 and 0 < iy < 10:
print('This was too easy')
This was too easy
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
Chris Angelico wrote: On Fri, Nov 2, 2012 at 1:12 AM, Ethan Furman wrote: In other words, the slice contains the strings, and my code calculates the offsets -- Python doesn't do it for me. That's correct, but you're still translating those strings into numeric indices. True, but the point is that the /slice/ contains a data type that is neither a number, nor directly translatable into a number (that is, no __index__ method), and my code would cease to function should that change to slices be made. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: pythonic way
On Thu, Nov 1, 2012 at 9:32 AM, inshu chauhan wrote: > what is the most pythonic way to do this : > >if 0 < ix < 10 and 0 < iy < 10 ??? > I suppose you could do if all(0 < i < 10 for i in (ix, iy)): but I think that the original is more readable unless you have several variables to test. -- http://mail.python.org/mailman/listinfo/python-list
Re: pythonic way
: On 1 November 2012 11:32, inshu chauhan wrote: > what is the most pythonic way to do this : > >if 0 < ix < 10 and 0 < iy < 10 ??? As everyone else has said, it's perfectly pythonic once you stick the colon on the end. You might find it more instantly readable with some extra parentheses: if (0 < ix < 10) and (0 < iy < 10): # do something ... but that's really just down to taste. -[]z. -- http://mail.python.org/mailman/listinfo/python-list
Re: python and Open cv
: On 1 November 2012 08:48, inshu chauhan wrote: > I am sorry.. but I need to know what are the rules and what about gmail ?? > Many people are using gmail to mail to the list. There aren't any rules about gmail (except the unwritten rule that to be a "real" geek you need to use a mail client that takes a whole weekend to configure, and another three years to properly understand). It's helpful to other people on the list, though, if you post follow-up questions in the same thread - finding the last relevant message and hitting "reply to all" will do this in gmail. -[]z. -- http://mail.python.org/mailman/listinfo/python-list
Re: python and Open cv
Zero Piraeus writes: > There aren't any rules about gmail (except the unwritten rule that to > be a "real" geek you need to use a mail client that takes a whole > weekend to configure, and another three years to properly understand). Ha! 3 years? I've been using gnus for nearly 20 years and I still don't understand it! -- http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
On 11/01/2012 07:12 AM, Ethan Furman wrote: Andrew Robinson wrote: On 10/31/2012 02:20 PM, Ian Kelly wrote: On Wed, Oct 31, 2012 at 7:42 AM, Andrew Robinson wrote: Then; I'd note: The non-goofy purpose of slice is to hold three data values; They are either numbers or None. These *normally* encountered values can't create a memory loop. So, FOR AS LONG, as the object representing slice does not contain an explicit GC pair; A little review... The premise of my statement here, is that Tim Peter's closed the Bug report; http://bugs.python.org/issue1501180 With the *reason* being that using GC was *goofy* on account of what slice() was intended to hold, None and a number. So, My first attempt at bug fix was simply to take Tim Peter's at his word... since we all assume he *isn't* a "Bloody Idiot". Hey isn't that a swear-word somewhere in the world? Its not where I live, but I seem to recall... oh, well... whatever. I missed something... (but then that's why we're still talking about it...) Reading the PEP, it notes that *only* integers (or longs) are permitted in slice syntax. Keep in mind that PEPs represent Python /at that time/ -- as Python moves forward, PEPs are not updated (this has gotten me a couple times). And, since I am reading them in the order written (but in 3.0) trying to get the whole of Python into my mind on the journey to prep for porting it into a tiny chip -- I'm frustrated by not being finished yet... Furman, actually. :) :-! And my values do *not* convert to indices (at least, not automatically). Ahhh (Rhetorical & sarcastic) I was wondering how you added index() method to strings, not access it, and still be following the special PEP we are talking about,when you gave that example using unwrapped strings. -- H was that PEP the active state of Python, when Tim rejected the bug report? eg: have we "moved on" into a place where the bug report ought to be re-issued since that PEP is now *effectively* passe, and Tim could thus be vindicated from being a "b... Idiot?" (Or has he been given the 1st place, Python Twit award -- and his *man* the bug list been stripped?) In other words, the slice contains the strings, and my code calculates the offsets -- Python doesn't do it for me. ~Ethan~ I see, so the problem is that PEP wants you to implement the index(), but that is going to cause you to subclass string, and add a wrapper interface every time you need to index something. eg: doing something llke --- mydbclass[ MyString( 'fromColumn' ) : MyString( 'toColum' ) ] and the code becomes a candy machine interface issue (Chapter 5, Writing Solid Code). My favorite line there uses no swearing "If they had just taken an extra *30* seconds thinking about their design, they could have saved me, and I'm sure countless others, from getting something they didn't want." I laugh, if they didn't get it already -- an extra *30* seconds is WY to optimistic. Try minutes at least, will a policeman glaring over their shoulder. But anyhow --- The problem lies in *when* the conversion to an integer is to take place, not so much if it is going to happen. Your indexes, no matter how disguised, eventually will become numbers; and you have a way that minimizes coding cruft (The very reason I started the thread, actually... subclassing trivially to fix candy machine interfaces leads to perpetual code increases -- In cPython source-code, "realloc" wrappers and "malloc" wrappers are found I've seen these wrappers *re*-invented in nearly every C program I've every looked at! Talk about MAN-hours, wasted space, and cruft.) So; is this a reasonable summary of salient features (status quo) ? * Enforcing strict numerical indexes (in the slice [::] operator) causes much psychological angst when attempting to write clear code without lots of wrapper cruft. * Pep 357 merely added cruft with index(), but really solved nothing. Everything index() does could be implemented in __getitem__ and usually is. * slice().xxxs are merely a container for *whatever* was passed to [::] * slice() is * slice is also a full blown object, which implements a trivial method to dump the contents of itself to a tuple. * presently slice() allows memory leaks through GC loops. * Slice(), even though an object with a constructor, does no error checking to deny construction of memory leaks. If people would take 30 seconds to think about this the more details added -- the more comprehensive can be my understanding -- and perhaps a consensus reached about the problem. These are a list of relevant options, without respect to feasability. * Don't bother to fix the bug; allow Python to crash with a subtle bug that often take weeks to track down by the very small minority doing strange things (Equivalent to the "monkey patch" syndrome of D'Aprano; BTW: The longer the bug is left unfix
Re: Negative array indicies and slice()
On Thu, Nov 1, 2012 at 10:32 PM, Andrew Robinson wrote: > presently slice() allows memory leaks through GC loops. Forgive me if I've missed something here, but isn't it only possible to make a refloop by decidedly abnormal behaviour? Stuff like: a=[]; a.append(slice(a)) Seriously, who does this? First you have to have a reference to a container in place of an index, and then you have to retain the slice object inside that same container as well. Neither operation is normal use of a slice. Where is the problem? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
On Thu, Nov 1, 2012 at 5:32 AM, Andrew Robinson wrote: > H was that PEP the active state of Python, when Tim rejected the bug > report? Yes. The PEP was accepted and committed in March 2006 for release in Python 2.5. The bug report is from June 2006 has a version classification of Python 2.5, although 2.5 was not actually released until September 2006. > Pep 357 merely added cruft with index(), but really solved nothing. > Everything index() does could be implemented in __getitem__ and usually is. No. There is a significant difference between implementing this on the container versus implementing it on the indexes. Ethan implemented his string-based slicing on the container, because the behavior he wanted was specific to the container type, not the index type. Custom index types like numpy integers on the other hand implement __index__ on the index type, because they apply to all sequences, not specific containers. This must be separate from standard int conversion, because standard int conversion is too general for indexing. > slice is also a full blown object, which implements a trivial method to dump > the contents of itself to a tuple. slice.indices() does not trivially dump its contents as given. It takes a sequence length and adjusts its indices to that length. The C implementation of this is around 60 lines of code. > Don't bother to fix the bug; allow Python to crash with a subtle bug that > often take weeks to track down by the very small minority doing strange > things (Equivalent to the "monkey patch" syndrome of D'Aprano; BTW: The > longer the bug is left unfixed, the more people will invent "uses" for it ) It's been 6 years already. AFAIK nobody has invented any uses that are actually at risk of invoking the GC bug. -- http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
Ian Kelly wrote: On Thu, Nov 1, 2012 at 5:32 AM, Andrew Robinson wrote: Don't bother to fix the bug; allow Python to crash with a subtle bug that often take weeks to track down by the very small minority doing strange things (Equivalent to the "monkey patch" syndrome of D'Aprano; BTW: The longer the bug is left unfixed, the more people will invent "uses" for it ) It's been 6 years already. AFAIK nobody has invented any uses that are actually at risk of invoking the GC bug. The bug is not that slice allows non-numbers, but that slice objects aren't tracked by gc; I'm not seeing an issue with not fixing the bug. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
lazy properties?
Seeing the wonderful "lazy val" in Scala I thought that I should try to get the following also in Python. The problem is that I often have this pattern in my code: class Sample: def __init__(self): self._var = None @property def var(self): if self._var is None: self._var = long_computation() else: return self._var which is quite useful when you have some expensive attribute to compute that is not going to change. I was trying to generalize it in a @lazy_property but my attempts so far failed, any help on how I could do that? What I would like to write is @lazy_property def var_lazy(self): return long_computation() and this should imply that the long_computation is called only once.. -- http://mail.python.org/mailman/listinfo/python-list
Re: python and Open cv
On Thu, Nov 1, 2012 at 7:02 PM, Paul Rudin wrote: > Zero Piraeus writes: > > > There aren't any rules about gmail (except the unwritten rule that to > > be a "real" geek you need to use a mail client that takes a whole > > weekend to configure, and another three years to properly understand). > :D :D :D > > Ha! 3 years? I've been using gnus for nearly 20 years and I still don't > understand it! > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: pythonic way
OK ..I got it.. On Thu, Nov 1, 2012 at 5:54 PM, Zero Piraeus wrote: > : > > On 1 November 2012 11:32, inshu chauhan wrote: > > what is the most pythonic way to do this : > > > >if 0 < ix < 10 and 0 < iy < 10 ??? > > As everyone else has said, it's perfectly pythonic once you stick the > colon on the end. You might find it more instantly readable with some > extra parentheses: > > if (0 < ix < 10) and (0 < iy < 10): > # do something > > ... but that's really just down to taste. > > -[]z. > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: lazy properties?
On Thu, Nov 1, 2012 at 3:38 PM, Andrea Crotti wrote: > What I would like to write is > @lazy_property > def var_lazy(self): > return long_computation() > > and this should imply that the long_computation is called only once.. If you're using Python 3.2+, then functools.lru_cache probably suffices for your needs. @property @functools.lru_cache() def var_lazy(self): return long_computation() If you really need to shorten that to a single declaration: def lazy_property(func): return property(functools.lru_cache()(func)) -- http://mail.python.org/mailman/listinfo/python-list
Re: datetime issue
On Wednesday, October 31, 2012 3:38:57 PM UTC-6, Mark Lawrence wrote: > On 31/10/2012 19:35, ru...@yahoo.com wrote: >> "Broken"? Yes. But so is every piece of software in one way >> or another. Thunderbird is one of the most perpetually buggy >> pierces of software I have ever used on a continuing basis > > Please provide evidence that Thunderbird is buggy. I use it quite > happily, don't have problems, and have never seen anybody complaining > about it. I hesitate to respond to this because thunderbird bugs are really OT, but since you insist... A few years ago started keeping a list TB problems I encountered. I stopped maintaining it a year or so ago. It is a mixture of bugs, misfeatures, and things I couldn't figure out, etc. Many have been fixed in later versions. Nevertheless, it illustrates *my* experience with TB. Note that despite the problems, I still use TB in some contexts. Different apps have different bugs/(mis)features and every person has their own weighting factors on those bugs. End result is different people prefer different apps for different purposes (and some of us find GG the least worst choice for posting here.) * In Search dialog clicked on the Search in folder dropdown after an earlier search and TB crashed (disappeared along with the new message I was editing.) [3.0.1] * Search for japanese text in body no longer works (never finds text even when it exists). [3.0.1] Used to work. * Each mail message displays useless header info that uses 25% of the available vertical space. * When editing a reply message, typing a return at eol results in two blank lines inserted. * When editing message, siometimes edit cursor disappears tho editing still seems to work normally. * Requires voodoo to create hmtl new message when default is plain text or visa versa. Have to hold shift key while clicking "write" button. Shift while choosing "new", "reply", etc in menu doesn't work. * Frequently, clinking on a usenet newsgroup results in TB freeze. Only solution is to remove group and re-add later. (Problem since 2.x days.) * Frequently after an apparently normal shutdown, attempt to restart results in "TB is already running" error. * Some folders in the folder tree view are greyed out and not selectable even though they have no visible different properties than selectable ones. Don't know how they got that way. * Clicking on a folder in the folder tree pane results in a pop- up dialog "this folder is not selectable" that has to be dismissed, even though one is trying to get it's properties, or is selecting it to create a subfolder. * Messages change from "read" to "unread" in folders at random when folder is accessed, or even when it is not accessed. [gone in 3.0.3?] * Interminttently, when I click a usenet message to view it, the contents pane remains blank. Contents of that message remain blank foreever. [new with 3.0.1]. * When TB main window closed while editing an email, can no longer save the email, even if the TB main window is reopened. * Counts of new messages in usenet groups are often wildly high. * When opening up a usenet server, status bar reports "no new messages on server" even though TB then updates the groups with the new messages that *are* on the server. [new in 3.0.1] * After upgrade to TB-3.0, opening a usenet server results not only in the group being scanned for new messages in each group (as before) but also the headers for all those new messages being downloaded (slow on a dialup connection and a waste of time if I don't intend to read anything in that group). No obvious way to revert to original behaviour. * Even tho the number of unread messages listed beside a usenet group in the folder pane is less than the download limit, I sometimes get pop-up asking how many messages to download, when I access the group. (side effect of above problem I think.) * Sometimes TB downloads two copies of each header. * When I compress folders, get a series of several dozen pop- up messages (each requiring a click on "OK") telling me that foplder "xx" is not selectable. * Copy-paste from TB to other app fails if TB is closed before the paste -- the paste buffer appears empty [TB-3.0b4] * Copy paste fails by removing text (forgot if it is just the copied text or other text) in the TB message when pasted somewhere else. [TB-2?] * After upgrade to TB-3.0x, i no longer see a way to create a new imap subfolder. Had to create it using MSOE. * After upgrade to TB-3.0x double clicking on attached .jpg image no longer opens it -- only option is to save and open outside of TB. phfft. * HTF do you change the font size for plain text message composition? Prefs has a setting for html but... * search of body for multiple "anded" text never ends if one of the search boxes is empty. * Search "stop" button doesn't stop search. * One group frequently, without any actio
Re: lazy properties?
On 01Nov2012 21:38, Andrea Crotti wrote:
| Seeing the wonderful "lazy val" in Scala I thought that I should try to
| get the following also in Python.
| The problem is that I often have this pattern in my code:
|
| class Sample:
| def __init__(self):
| self._var = None
|
| @property
| def var(self):
| if self._var is None:
| self._var = long_computation()
| else:
| return self._var
|
|
| which is quite useful when you have some expensive attribute to compute
| that is not going to change.
| I was trying to generalize it in a @lazy_property but my attempts so far
| failed, any help on how I could do that?
|
| What I would like to write is
| @lazy_property
| def var_lazy(self):
| return long_computation()
|
| and this should imply that the long_computation is called only once..
I've got one of these which I use exactly as you wish above:
def lazy_property(func):
''' A property whose access is controlled by a lock if unset.
'''
lock_name = '_lock'
prop_name = '_' + func.__name__
unset_object = None
def getprop(self):
''' Attempt lockless fetch of property first.
Use lock if property is unset.
'''
p = getattr(self, prop_name)
if p is unset_object:
with getattr(self, lock_name):
p = getattr(self, prop_name)
if p is unset_object:
##debug("compute %s...", prop_name)
p = func(self)
##warning("compute %s[%s].%s: %s", self, id(self), prop_name,
type(p))
setattr(self, prop_name, p)
return p
return property(getprop)
It computes the cached property name from the function name, but uses a
global lock name "_lock" on the basis that the long_computation() will
use shared state with the rest of the object.
The microoptimisation of the lockless fetch may be either nonportable or
pointless.
I need to abstract this with a deeper level of nesting to support
chaning lock_name, prop_name and unset_object if the caller desires, but
for what you want it will work out of the box.
I've got a similar thing that watches files for modification and reloads
at need.
Cheers,
--
Cameron Simpson
Cordless hoses have been around for quite some time. They're called buckets.
- Dan Prener
--
http://mail.python.org/mailman/listinfo/python-list
Re: Obnoxious postings from Google Groups
On 11/01/2012 03:55 AM, Jamie Paul Griffin wrote: > Anybody serious about programming should be using a form of > UNIX/Linux if you ask me. It's inconceivable that these systems > should be avoided if you're serious about Software Engineering and > Computer Science, etc. For UNIX there are loads of decent news > reading software and mail user agents to learn and use. slrn is a > good one and point it at gmane.org as someone else pointed out. I > can't even imagine using a browser or Google Groups, etc. now. Are you saying that this group is only for "serious" programmers? "serious" is also a matter of opinion. I have some serious programmer friends who maintain, in complete sincerity, that serious programmers should not waste time on slow, script-kiddie languages like Python, but should be developing their skills with serious professional languages like Java, C#, etc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
On 11/01/2012 12:07 PM, Ian Kelly wrote: On Thu, Nov 1, 2012 at 5:32 AM, Andrew Robinson wrote: H was that PEP the active state of Python, when Tim rejected the bug report? Yes. The PEP was accepted and committed in March 2006 for release in Python 2.5. The bug report is from June 2006 has a version classification of Python 2.5, although 2.5 was not actually released until September 2006. That explain's Peter's remark. Thank you. He looks *much* smarter now. Pep 357 merely added cruft with index(), but really solved nothing. Everything index() does could be implemented in __getitem__ and usually is. No. There is a significant difference between implementing this on the container versus implementing it on the indexes. Ethan implemented his string-based slicing on the container, because the behavior he wanted was specific to the container type, not the index type. Custom index types like numpy integers on the other hand implement __index__ on the index type, because they apply to all sequences, not specific containers. Hmmm... D'Aprano didn't like the monkey patch;and sub-classing was his fix-all. Part of my summary is based on that conversation with him,and you touched on one of the unfinished points; I responded to him that I thought __getitem__ was under-developed. The object slice() has no knowledge of the size of the sequence; nor can it get that size on it's own, but must passively wait for it to be given to it. The bottom line is: __getitem__ must always *PASS* len( seq ) to slice() each *time* the slice() object is-used. Since this is the case, it would have been better to have list, itself, have a default member which takes the raw slice indicies and does the conversion itself. The size would not need to be duplicated or passed -- memory savings, & speed savings... I'm just clay pidgeoning an idea out here Let's apply D'Aprano 's logic to numpy; Numpy could just have subclassed *list*; so let's ignore pure python as a reason to do anything on the behalf on Numpy: Then, lets' consider all thrid party classes; These are where subclassing becomes a pain -- BUT: I think those could all have been injected. >>> class ThirdParty( list ): # Pretend this is someone else's... ... def __init__(self): return ... def __getitem__(self,aSlice): return aSlice ... We know it will default work like this: >>> a=ThirdParty() >>> a[1:2] slice(1, 2, None) # So, here's an injection... >>> ThirdParty.superOnlyOfNumpy__getitem__ = MyClass.__getitem__ >>> ThirdParty.__getitem__ = lambda self,aSlice: ( 1, 3, self.superOnlyOfNumpy__getitem__(aSlice ).step ) >>> a[5:6] (1, 3, None) Numpy could have exported a (workable) function that would modify other list functions to affect ONLY numpy data types (eg: a filter). This allows user's creating their own classes to inject them with Numpy's filter only when they desire; Recall Tim Peter's "explicit is better than implicit" Zen? Most importantly normal programs not using Numpy wouldn't have had to carry around an extra API check for index() *every* single time the heavily used [::] happened. Memory & speed both. It's also a monkey patch, in that index() allows *conflicting* assumptions in violation of the unexpected monkey patch interaction worry. eg: Numpy *CAN* release an index() function on their floats -- at which point a basic no touch class (list itself) will now accept float as an index in direct contradiction of PEP 357's comment on floats... see? My point isn't that this particular implementation I have shown is the best (or even really safe, I'd have to think about that for a while). Go ahead and shoot it down... My point is that, the methods found in slice(), and index() now have moved all the code regarding a sequence *out* of the object which has information on that sequence. It smacks of legacy. The Python parser takes values from many other syntactical constructions and passes them directly to their respective objects -- but in the case of list(), we have a complicated relationship; and not for any reason that can't be handled in a simpler way. Don't consider the present API legacy for a moment, I'm asking hypothetical design questions: How many users actually keep slice() around from every instance of [::] they use? If it is rare, why create the slice() object in the first place and constantly be allocating and de-allocating memory, twice over? (once for the original, and once for the repetitive method which computes dynamic values?) Would a single mutable have less overhead, since it is destroyed anyway? -- http://mail.python.org/mailman/listinfo/python-list
Re: datetime issue
On 11/01/2012 06:09 AM, Grant Edwards wrote:> On 2012-10-31, ru...@yahoo.com wrote: >> On 10/31/2012 09:11 AM, Grant Edwards wrote:> On 2012-09-16, ?? >> wrote: >>> Iam positng via google groups using chrome, thats all i know. >>> >>> Learn something else. Google Groups is seriously and permanently >>> broken, and all posts from Google Groups are filtered out and ignored >>> by many people (including myself -- I only saw this because somebody >>> else replied to it). >> >> Feel free to filter whatever you want but be aware than in >> doing so you risk missing information that could help you >> avoid disseminating erroneous info. Of course, carrying out >> some kind of private war against Google Groups may be more >> important to you than that... > > Based on past experience, the chances of useful information being > posted via Google Groups is very small. The benefit of avoiding all > the spam and garbage the comes from that source is more than worth the > small risk of missing something worthwhile. > > Note that I'm _not_ talking about people posting to the mailing list > using Gmail -- only people posting via the Google Groups web UI. Your experience is that most GG posts are junk but not most Gmail posts. And yet someone else posted that Gmail posts are the junk ones. So I wonder how accurate these evaluations are. In either case, while there has been some spam and garbage posts in c.l.p in the past, I haven't seen very many lately. And even in the past, they seemed pretty recognizable to me and easily skipped over. As for stupid questions, undesired formatting etc, I seldom look at the message headers so I never noticed whether they are mostly from GG or Gmail. But then again I never found it hard to glance at a post and move on if I didn't want to read it. YMMV. -- http://mail.python.org/mailman/listinfo/python-list
Re: Private methods
On Tue, Oct 9, 2012 at 5:51 PM, Steven D'Aprano wrote: > On Tue, 09 Oct 2012 11:08:13 -0600, Ian Kelly wrote: > >> I tend to view name mangling as being more for avoiding internal >> attribute collisions in complex inheritance structures than for >> designating names as private. > > Really? I tend to view name mangling as a waste of time, and complex > inheritance structures as something to avoid. Name mangling is also useful for object tagging. Suppose you have object A that is passed object B and needs to track some data concerning object B, but does not need a strong reference to B. One solution is to use a weak-key dictionary, but this relies upon B being hashable, and I find it neater to just store the data on B itself. The problem is that whatever name you use might conflict with an existing attribute belonging to B. class Tagger(object): def tag(self, taggee): taggee.__tag = some_tag_data One of the curious ramifications of Python's name-mangling system is that even though the attribute above is being set on some arbitrary object, the mangling that is applied is in any case that of the class Tagger. Thus the mangled attribute name ends up being "_Tagger__tag", which is unlikely to cause a conflict. There are some disadvantages to tagging. One is that you can't tag objects of built-in types. Another is that you can't tag instances of classes with __slots__. I tend to view the latter as another reason to avoid using __slots__. -- http://mail.python.org/mailman/listinfo/python-list
Re: lazy properties?
> If you're using Python 3.2+, then functools.lru_cache probably > ... And if you're on 2.X, you can grab lru_cache from http://code.activestate.com/recipes/498245-lru-and-lfu-cache-decorators/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Obnoxious postings from Google Groups
On Fri, Nov 2, 2012 at 9:08 AM, wrote: > On 11/01/2012 03:55 AM, Jamie Paul Griffin wrote: >> Anybody serious about programming should be using a form of >> UNIX/Linux if you ask me. It's inconceivable that these systems >> should be avoided if you're serious about Software Engineering and >> Computer Science, etc. For UNIX there are loads of decent news >> reading software and mail user agents to learn and use. slrn is a >> good one and point it at gmane.org as someone else pointed out. I >> can't even imagine using a browser or Google Groups, etc. now. > > Are you saying that this group is only for "serious" programmers? It's not; also, so long as Python maintains an official Windows build, this list/group will be fielding questions about Windows. But there's still good reason to grab a Linux. http://catb.org/~esr/faqs/smart-questions.html#idp29970256 > "serious" is also a matter of opinion. I have some serious > programmer friends who maintain, in complete sincerity, that > serious programmers should not waste time on slow, script-kiddie > languages like Python, but should be developing their skills > with serious professional languages like Java, C#, etc. And there are probably still a few around who maintain that Java, C#, and even C are too modern, and that serious programmers use FORTRAN or COBOL. Or assembly language. Let 'em. Meanwhile I'll have demonstrable code done while they're still fiddling around with details, because my languages (including, though by no means limited to, Python) do most of the work for me. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: sort order for strings of digits
On Thu, 01 Nov 2012 11:53:06 +1100, Chris Angelico wrote: > On Thu, Nov 1, 2012 at 10:44 AM, Steven D'Aprano > wrote: >> On the contrary. If you are using cmp with sort, your sorts are slow, >> and you should upgrade to using a key function as soon as possible. >> >> > But cmp_to_key doesn't actually improve anything. So I'm not sure how > Py3 has achieved anything; Py2 supported key-based sorting already. Yes, but there is a lot of old code pre-dating key-based sorts. There's also some examples of code where it isn't obvious how to write it as a key-based sort, but a comparison function is simple. And people coming from other languages that only support comparison-based sorts (C?) will probably continue with what they know. Even though key-based sorting is better, there's a lot of comparison sorting that falls under "if it ain't broke, don't fix it". So even though key-based sorts are better, there are still comparison- based sorts in the wild. Python 2 has to support them. Python 3, which is allowed to break backwards compatibility, does not. So when porting to 3, you have to change the sorts. Most of the time it is simple to convert a comparison-based sort to a key- based sort. For the cases where you either can't come up with a good key function yourself, or were you want to do so mechanically, Python provides cmp_to_key. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
On Thu, Nov 1, 2012 at 4:25 PM, Andrew Robinson wrote: > The bottom line is: __getitem__ must always *PASS* len( seq ) to slice() > each *time* the slice() object is-used. Since this is the case, it would > have been better to have list, itself, have a default member which takes the > raw slice indicies and does the conversion itself. The size would not need > to be duplicated or passed -- memory savings, & speed savings... And then tuple would need to duplicate the same code. As would deque. And str. And numpy.array, and anything else that can be sliced, including custom sequence classes. > Let's apply D'Aprano 's logic to numpy; Numpy could just have subclassed > *list*; Numpy arrays are very different internally from lists. They are basically fancy wrappers of C arrays, whereas lists are a higher-level abstraction. They allow for multiple dimensions, which lists do not. Slices of numpy arrays produce views, whereas slices of lists produce brand new lists. And they certainly do not obey the Liskov Substitution Principle with respect to lists. class ThirdParty( list ): # Pretend this is someone else's... > ... def __init__(self): return > ... def __getitem__(self,aSlice): return aSlice > ... > > We know it will default work like this: a=ThirdParty() a[1:2] > slice(1, 2, None) > > # So, here's an injection... ThirdParty.superOnlyOfNumpy__getitem__ = MyClass.__getitem__ ThirdParty.__getitem__ = lambda self,aSlice: ( 1, 3, self.superOnlyOfNumpy__getitem__(aSlice ).step ) a[5:6] > (1, 3, None) I'm not understanding what this is meant to demonstrate. Is "MyClass" a find-replace error of "ThirdParty"? Why do you have __getitem__ returning slice objects instead of items or subsequences? What does this example have to do with numpy? > Numpy could have exported a (workable) function that would modify other list > functions to affect ONLY numpy data types (eg: a filter). This allows > user's creating their own classes to inject them with Numpy's filter only > when they desire; > > Recall Tim Peter's "explicit is better than implicit" Zen? We could also require the user to explicitly declare when they're performing arithmetic on variables that might not be floats. Then we can turn off run-time type checking unless the user explicitly requests it, all in the name of micro-optimization and explicitness. Seriously, whether x is usable as a sequence index is a property of x, not a property of the sequence. Users shouldn't need to pick and choose *which* particular sequence index types their custom sequences are willing to accept. They should even be able to accept sequence index types that haven't been written yet. > Most importantly normal programs not using Numpy wouldn't have had to carry > around an extra API check for index() *every* single time the heavily used > [::] happened. Memory & speed both. The O(1) __index__ check is probably rather inconsequential compared to the O(n) cost of actually performing the slicing. > It's also a monkey patch, in that index() allows *conflicting* assumptions > in violation of the unexpected monkey patch interaction worry. > > eg: Numpy *CAN* release an index() function on their floats -- at which > point a basic no touch class (list itself) will now accept float as an index > in direct contradiction of PEP 357's comment on floats... see? Such a change would only affect numpy floats, not all floats, so it would not be a monkey-patch. In any case, that would be incorrect usage of __index__. We're all consenting adults here; we don't need supervision to protect us from buggy third-party code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
andrew...@gmail.com於 2012年10月29日星期一UTC+8上午11時12分11秒寫道：
> The slice operator does not give any way (I can find!) to take slices from
> negative to positive indexes, although the range is not empty, nor the
> expected indexes out of range that I am supplying.
>
>
>
> Many programs that I write would require introducing variables and logical
> statements to correct the problem which is very lengthy and error prone
> unless there is a simple work around.
>
>
>
> I *hate* replicating code every time I need to do this!
>
>
>
> I also don't understand why slice() is not equivalent to an iterator, but can
> replace an integer in __getitem__() whereas xrange() can't.
>
>
>
>
>
> Here's an example for Linux shell, otherwise remove /bin/env...
>
> {{{#!/bin/env python
>
> a=[1,2,3,4,5,6,7,8,9,10]
>
> print a[-4:3] # I am interested in getting [7,8,9,10,1,2] but I get [].
>
> }}}
I'll suggest to use the reverse method
to get what you want.
Of course, the reverse method is not efficient for
a list of a huge number of objects in python.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Obnoxious postings from Google Groups
On Fri, 02 Nov 2012 10:32:08 +1100, Chris Angelico wrote: > And there are probably still a few around who maintain that Java, C#, > and even C are too modern, and that serious programmers use FORTRAN or > COBOL. Huh. If you're messing about with ancient[1] languages like Java, C# and especially C, you're not a real programmer. Real programmers use modern, advanced languages like D, Erlang, Go or Haskell. [1] "Ancient" is a frame of mind, not a chronological state. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Obnoxious postings from Google Groups
In article <50932111$0$29967$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano wrote: > Huh. If you're messing about with ancient[1] languages like Java, C# and > especially C, you're not a real programmer. Real programmers use modern, > advanced languages like D, Erlang, Go or Haskell. Does anybody actually use D for anything? I looked at the language a while ago. There seemed to be a lot in it that made sense. Does it get any real use, or is it just an interesting research project? -- http://mail.python.org/mailman/listinfo/python-list
Re: Obnoxious postings from Google Groups
On Fri, 02 Nov 2012 01:25:37 -, Steven D'Aprano wrote: Huh. If you're messing about with ancient[1] languages like Java, C# and especially C, you're not a real programmer. Real programmers use modern, advanced languages like D, Erlang, Go or Haskell. Advanced? Huh. I have here a language that does exactly what I want without all that messy syntax nonsense. I call it "Research Assistant." -- Rhodri James *-* Wildebeest Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Avoiding defunct processes
Hello, I create child processes with subprocess.Popen(). Then I either wait for them to finish or kill them. Either way these processes end up as defunct until the parent process completes: $ ps e 6851 pts/5Z+ 1:29 [python] This confuses another library as to whether the processes are complete. For now I detect which processes are defunct by parsing the output of "ps". What would you recommend? I am hoping there is a cleaner way. Richard -- http://mail.python.org/mailman/listinfo/python-list
Re: Negative array indicies and slice()
On Thu, 01 Nov 2012 15:25:51 -0700, Andrew Robinson wrote: > On 11/01/2012 12:07 PM, Ian Kelly wrote: >>> Pep 357 merely added cruft with index(), but really solved nothing. >>> Everything index() does could be implemented in __getitem__ and >>> usually is. >> >> No. There is a significant difference between implementing this on the >> container versus implementing it on the indexes. Ethan implemented his >> string-based slicing on the container, because the behavior he wanted >> was specific to the container type, not the index type. Custom index >> types like numpy integers on the other hand implement __index__ on the >> index type, because they apply to all sequences, not specific >> containers. > > Hmmm... > D'Aprano didn't like the monkey patch;and sub-classing was his fix-all. I pointed out that monkey-patching is a bad idea, even if it worked. But it doesn't work -- you simply cannot monkey-patch built-ins in Python. Regardless of whether "I like" the m-p or not, *you can't use it* because you patch built-in list methods. The best you could do is subclass list, then shadow the built-in name "list" with your subclass. But that gives all sorts of problems too, in some ways even worse than monkey-patching. You started this thread with a question about slicing. You believe that one particular use-case for slicing, which involves interpreting lists as circular rather than linear, is the use-case that built-in list slicing should have supported. Fine, you're entitled to your option. But that boat has sailed about 20 years ago. Python didn't make that choice, and it won't change now. If you write up a PEP, you could aim to have the built-in behaviour changed for Python 4 in perhaps another 10-15 years or so. But for the time being, that's not what lists, tuples, strings, etc. do. If you want that behaviour, if you want a circular list, then you have to implement it yourself, and the easiest way to do so is with a subclass. That's not a "fix-all". I certainly don't believe that subclassing is the *only* way to fix this, nor that it will fix "all" things. But it might fix *some* things, such as you wanting a data type that is like a circular list rather than a linear list. If you prefer to create a circular-list class from scratch, re- implementing all the list-like behaviour, instead of inheriting from an existing class, then by all means go right ahead. If you have a good reason to spend days or weeks writing, testing, debugging and fine-tuning your new class, instead of about 15 minutes with a subclass, then I'm certainly not going to tell you not to. > Part of my summary is based on that conversation with him,and you > touched on one of the unfinished points; I responded to him that I > thought __getitem__ was under-developed. The object slice() has no > knowledge of the size of the sequence; nor can it get that size on it's > own, but must passively wait for it to be given to it. That's because the slice object is independent of the sequence. As I demonstrated, you can pass a slice object to multiple sequences. This is a feature, not a bug. > The bottom line is: __getitem__ must always *PASS* len( seq ) to > slice() each *time* the slice() object is-used. The bottom line is: even if you are right, so what? The slice object doesn't know what the length of the sequence is. What makes you think that __getitem__ passes the length to slice()? Why would it need to recreate a slice object that already exists? It is the *sequence*, not the slice object, that is responsible for extracting the appropriate items when __getitem__ is called. __getitem__ gets a slice object as argument, it doesn't create one. It no more creates the slice object than mylist[5] creates the int 5. > Since this is the case, But it isn't. > it would have been better to have list, itself, have a default member > which takes the raw slice indicies and does the conversion itself. The > size would not need to be duplicated or passed -- memory savings, & > speed savings... We have already demonstrated that slice objects are smaller than (x)range objects and three-item tuples. In Python 3.3: py> sys.getsizeof(range(1, 10, 2)) # xrange remained in Python 3 24 py> sys.getsizeof((1, 10, 2)) 36 py> sys.getsizeof(slice(1, 10, 2)) 20 It might help you to be taken seriously if you base your reasoning on Python as it actually is, rather than counter-factual assumptions. > I'm just clay pidgeoning an idea out here Let's apply D'Aprano 's > logic to numpy; Numpy could just have subclassed *list*; Sure they could have, if numpy arrays were intended to be a small variation on Python lists. But they weren't, so they didn't. > so let's ignore > pure python as a reason to do anything on the behalf on Numpy: > > Then, lets' consider all thrid party classes; These are where > subclassing becomes a pain -- BUT: I think those could all have been > injected. > > >>> class ThirdParty
Re: Avoiding defunct processes
On Fri, Nov 2, 2012 at 1:16 PM, Richard wrote: > Hello, > > I create child processes with subprocess.Popen(). > Then I either wait for them to finish or kill them. > Either way these processes end up as defunct until the parent process > completes: > $ ps e > 6851 pts/5Z+ 1:29 [python] > > This confuses another library as to whether the processes are > complete. > For now I detect which processes are defunct by parsing the output of > "ps". > What would you recommend? I am hoping there is a cleaner way. That's a zombie process, it's finished but the parent hasn't wait()ed for it yet. http://docs.python.org/3.3/library/subprocess.html#subprocess.Popen.wait Once the process has ended, call that to get its return value and clean everything up. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
