Re: [Python-Dev] Bug or not? Different behaviour iterating list and collections.deque
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Christos Georgiou schrieb:
>> Is that intentional?
>
> It would have helped if you had said what "that" is you are referring
> to, it would also have helped if you had stated an opinion on whether
> you believe that to be a bug. For example, I think I would have phrased
> your post like this:
Yes, you are correct: I see now that I was too cryptic, but being cryptic
was not my intention; instead, I wanted to avoid a discussion on the issue
of the algorithm, which I didn't manage to avoid, so obviously my terseness
was mistaken. I should be clear from the start.
In retrospection, the example code I chose, although it showed the two
issues I thought important ('list / deque iteration discrepancy' and 'empty
/ non-empty deque iteration discrepancy') was not as plain as needed, since
it gave to Josiah, at least, the impression that the matter was about list /
deque merging.
> """
> If I apply .next() to an iter of a deque that has been modified, I
> get a RuntimeError:
>
> py> d=collections.deque()
> py> d.append(10)
> py> i=iter(d)
> py> d.append(10)
> py> i.next()
> Traceback (most recent call last):
> File "", line 1, in ?
> RuntimeError: deque mutated during iteration
>
> Yet when I apply .next() to an iter of an initially-empty deque,
> I get StopIteration:
>
> py> d=collections.deque()
> py> i=iter(d)
> py> d.append(10)
> py> i.next()
> Traceback (most recent call last):
> File "", line 1, in ?
> StopIteration
>
> Is this a bug? Shouldn't the second example also raise the RuntimeError
> as the deque has been modified?
> (also, is appending an element a modification or a mutation?)
> """
>
> To this question (.next on an iterator of a modified deque), my answer
> would be: "yes, that is a bug".
Yes. This behaviour was meant to be shown with the 'special_case' check. I
will open a bug for this.
> However, I feel you are referring to a different issue, unfortunately,
> I cannot tell from your post what that issue is.
No, you managed to capture large part of the essence of what I was saying,
but again, this was not your responsibility, but mine. I should be more
explicit.
Thank you.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug or not? Different behaviour iterating list andcollections.deque
"Josiah Carlson" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > "Christos Georgiou" <[EMAIL PROTECTED]> wrote: >> [snip] >> issue, but please understand this is not a question for help to change >> the >> algorithm (this has been done already), so it's not a question of c.l.py. >> It's a matter of discrepancy. > [snip] > > [snip Josiah's wordy "it's intentional and not a bug" in the form of a > suggestion > for a change of algorithm] Like I said, this wasn't a c.l.py question, even if you thought it deserved a c.l.py answer. In any case, you answered my question, and thank you. It not being a bug suits me just fine. Allow me to make sure we talk about the same thing here, though: both the example code I provided and the original one do modify the iterable *only* between the following A and B points in time: Point A: itertools.chain calls iter() on the iterable. (Appending to the iterable (list, deque) occur here, and only here.) Point B: itertools.chain starts calling iterable.next(). This is a different case from the one mentioned in the post by Raymond, and that is why I asked. For example, if itertools.chain called iter() on its arguments when actually needing to iterate over them instead of at the beginning, the code would work. But I really, really don't mind whatever the function, as long as it's by design, and that's the reason I didn't submit a bug in the tracker. That's all. I won't (and never intended) to defend any algorithms. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug or not? Different behaviour iterating list andcollections.deque
Forgive my piggy backing, but I forgot to include the only related post I found, which did not clear things up for me: http://groups.google.com/group/comp.lang.python/msg/e2dcb2362649a601 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Bug or not? Different behaviour iterating list and collections.deque
Hello, people. I am not sure whether this is a bug or intentional, so I thought checking it with you before opening a bug. I will explain this issue, but please understand this is not a question for help to change the algorithm (this has been done already), so it's not a question of c.l.py. It's a matter of discrepancy. A list that changes while iterating produces no errors, while a deque fails. Given the following example code: #code start import itertools, collections def item_is_special(item): "Just a dummy check in this example" return item % 3 == 0 def item_products(item): "Also a dummy function for the example" return [item*20+1, item*30+1] def process_list(items, type_of_que, special_case): # we want to process some items, but some of them # produce other items to be processed by the # same algorithm products= type_of_que() if special_case: products.append(-1) for item in itertools.chain(items, products): if item_is_special(item): for product in item_products(item): products.append(product) else: print "got", item #code end we have the following cases: >>> process_list(numbers, list, False) got 1 got 2 got 61 got 91 List works as expected. >>> process_list(numbers, collections.deque, False) got 1 got 2 deque does not work, most probably because deque.__iter__ of an empty deque ignores later changes. For this reason the `special_case' parameter was inserted in the code above, so that there is at least an item when itertools.chain calls iter on the deque: >>> process_list(numbers, collections.deque, True) got 1 got 2 Traceback (most recent call last): File "", line 1, in File "testdequeiter.py", line 17, in process_list for item in itertools.chain(items, products): RuntimeError: deque mutated during iteration Is that intentional? If not, let me know so that I open a bug. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tix not included in 2.5 for Windows
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Please submit a bug report to sf.net/projects/python. Done: www.python.org/sf/1568240 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Tix not included in 2.5 for Windows
Does anyone know why this happens? I can't find any information pointing to this being deliberate. I just upgraded to 2.5 on Windows (after making sure I can build extensions with the freeware VC++ Toolkit 2003) and some of my programs stopped operating. I saw in a French forum that someone else had the same problem, and what they did was to copy the relevant files from a 2.4.3 installation. I did the same, and it seems it works, with only a console message appearing as soon as a root window is created: attempt to provide package Tix 8.1 failed: package Tix 8.1.8.4 provided instead Cheers. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] once [was: Simple Switch statementZ]
I haven't followed the complete discussion about once, but I would assume it would be used as such: once = that is, always an assignment, with the value stored as a cellvar, perhaps, on first execution 0f the code. Typically I would use it as: def function(a): once pathjoin = os.path.join ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Visual studio 2005 express now free
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > - Paul Moore has contributed a Python build procedure for the > free version of the 2003 compiler. This one is without IDE, > but still, it should allow people without a VS 2003 license > to work on Python itself; it should also be possible to develop > extensions with that compiler (although I haven't verified > that distutils would pick that up correctly). AFAIR Paul Moore was based on some other instructions posted previously somewhere on the net, which I followed at least a year back; it was a little hard to fix all variables etc, but I managed to build for 2.4 an extension of mine (haar transformation for image comparisons) successfully using just the setup.py of my module. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Grammar Ambiguity
"Michael Foord" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > It worries me that there might be a valid expression allowed here that I > haven't thought of. My current rules allow anything that looks like > ``(a, [b, c, (d, e)], f)`` - any nested identifier list. Would anything > else be allowed ? Anything that goes in the left hand side of an assignment: # example 1 >>> a=[1,2] >>> for a[0] in xrange(10): pass # example 2 >>> class A(object): pass >>> a=A() >>> for a.x in xrange(10): pass ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch or feature? Tix.Grid working for 2.5
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Christos Georgiou wrote: >> I would like to know if supplying a patch for it sometime in the next >> couple >> of weeks would be considered a patch (since the widget currently is not >> working at all, its class in Tix.py contains just a pass statement) or a >> feature (ie extra functionality) for the 2.5 branch... > > I wouldn't object to including it before beta 1. Just in case the auto-assignment email still does not work, I have submitted the patch since March 31. OTOH, if I need to review 5 bugs/patches, I'll try to find some time to do that. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch or feature? Tix.Grid working for 2.5
"Neal Norwitz" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On 3/18/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Christos Georgiou wrote: > > I would like to know if supplying a patch for it sometime in the next > > couple > > of weeks would be considered a patch (since the widget currently is not > > working at all, its class in Tix.py contains just a pass statement) or a > > feature (ie extra functionality) for the 2.5 branch... [Martin] > I wouldn't object to including it before beta 1. Good to have a general deadline (ObRef Douglas Adams: ""I like deadlines; I especially like the whooshing sound they make as they go flying by.") [Neal] > Nor would I. I'm not sure if this helps or not, but a general rule of > thumb is if it's 100 lines it's probably a patch. If it's 1000 lines, > it's probably a major feature. Given such a patch is pure python and > probably much closer to 100 lines, this should be ok. It should amount to 100-200 lines as far as I can see, I'm just playing with .tk.call and writing down how to do stuff, and trying to grok the general style of classes interfacing to Tkinter/Tix. DisplayStyle is already there, which is good. Thankfully the tix docs seem to be complete, so it should be only a matter of time. I will try to update tixwidgets.py with a demo page too. [Neal] > BTW, have you contacted the Tix people? It is a separate project and > looks like people are working on it. http://tix.sourceforge.net/ That's where I got the documentation. I haven't contacted them, though, because I saw that Tix.py hasn't been modified for 4 years now. I will offer the patch both to the Python and the Tix Tix.py though, thanks for the suggestion. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Patch or feature? Tix.Grid working for 2.5
I made a plea for help months ago (just checked, and it was Jan 2004! time flies like a fruit or something, ref http://mail.python.org/pipermail/python-list/2004-January/202704.html ) about directions to fix the borken Tix.Grid widget; I had no replies. I finally found some spare time (too little, though, much work, wife expecting etc) and I started work on it, and at the moment it can be added in a window and has some functionality, but I need a lot more finding my way about using tcl/tk --I have almost zero knowledge of the language. I would like to know if supplying a patch for it sometime in the next couple of weeks would be considered a patch (since the widget currently is not working at all, its class in Tix.py contains just a pass statement) or a feature (ie extra functionality) for the 2.5 branch... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes thoughts
"Josiah Carlson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
"Christos Georgiou" <[EMAIL PROTECTED]> wrote:
[Christos]
> Well, what's the result of
>
> bytes([1,0,0])^ bytes([1,0])
>
> ? Is it bytes([0,0,0]) (à la little-endian) or is it bytes([1,1,0])
> (straight conversion to base-256)? Or perhaps throw a ValueError if the
> sizes differ?
[Josiah]
> It's a ValueError. If the sizes matched, it would be a per-element
> bitwise xor.
I agree ("in the face of ambiguity..."), although I understand that it
wasn't
obvious that I do from the way I asked the question, which I was expecting
Greg to answer :)
[Christos]
> These details should be considered in the PEP.
[Josiah]
> They aren't considered because they are *obvious* to most (if not all)
> sane people who use Python.
I beg to disagree. I don't know whether you are Dutch or not, but most of
the Python users aren't; one of the reason PEPs exist is to explain what
*should* "be obvious at first" when one is Dutch ;-) Apart from joking,
PEPs should be a record of beating/thinking the PEP subject to its death:
"The PEP author is responsible for building consensus within the
community and documenting dissenting opinions."
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch to MS VC++ 2005 ?!
"M.-A. Lemburg" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Microsoft has recently released their express version of the Visual C++. > Given that this version is free for everyone, wouldn't it make sense > to ship Python 2.5 compiled with this version ?! > >http://msdn.microsoft.com/vstudio/express/default.aspx Link to the middle of a previous thread about the same option: http://mail.python.org/pipermail/python-dev/2005-November/058052.html Link describes hands-on experience by Paul Moore. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes thoughts
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Baptiste Carvello wrote: > [Baptiste] >> while manipulating binary data will happen mostly with bytes objects, >> some >> operations are better done with ints, like the bit manipulations with the >> &|~^ >> operators. [Greg] > Why not just support bitwise operations directly > on the bytes object? Well, what's the result of bytes([1,0,0])^ bytes([1,0]) ? Is it bytes([0,0,0]) (à la little-endian) or is it bytes([1,1,0]) (straight conversion to base-256)? Or perhaps throw a ValueError if the sizes differ? These details should be considered in the PEP. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] fixing log messages
[Fredrik Lundh] >> (but alright, as long as you don't call me "Fred"...) [Steve Holden] > Did I *ever* do that? That would have been an embarrassing slip ;-) I know I'm extremely late, but there should be a POTF (Pun Of The Fortnight) from now on. A member of the Mund-SIG ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] buildbot, and test failures
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Anthony Baxter wrote: >> I >> have an Ubuntu x86 box here that can become one (I think the only >> linux, currently, is Gentoo...) > > How different are the Linuxes, though? How many of them do we need? Actually, we would need enough to cover the libc/gcc combinations that are most common. This isn't feasible, though, so in case we add more Linux machines, at least make sure that the libc/gcc combo is not one already used in the existing ones. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Building Python with Visual C++ 2005 Express Edition
I didn't see any mention of this product in the Python-Dev list, so I thought to let you know. http://msdn.microsoft.com/vstudio/express/visualc/download/ There is also a link for a CD image (.img) file to download. I am downloading now, so I don't know yet whether Python compiles with it without any problems. So if anyone has previous experience, please reply. PS This page ( http://msdn.microsoft.com/vstudio/express/support/faq/default.aspx#pricing ) says that if you download it until Nov 7, 2006, it's a gift --the Microsoft VC++ compiler for free (perhaps a cut-down version). Bits from the FAQ: http://msdn.microsoft.com/vstudio/express/support/faq/default.aspx 4. Can be used even for commercial products without licensing restrictions 40. It includes the optimizing compiler (without stuff like Profile Guided Optimizations) 41. Builds both native and managed applications (you 99% need to download the SDK too) 42. No MFC or ATL included ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bool(iter([])) changed between 2.3 and 2.4
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >> [Fred] >> > think iterators shouldn't have length at all: >> > they're *not* containers and shouldn't act that way. >> >> Some iterators can usefully report their length with the invariant: >>len(it) == len(list(it)). > >I still consider this an erroneous hypergeneralization of the concept >of iterators. Iterators should be pure iterators and not also act as >containers. Which other object type implements __len__ but not >__getitem__? Too late, and probably irrelevant by now; the answer though is set([1,2,3]) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] list splicing
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Karl Chen wrote: >> Hi, has anybody considered adding something like this: >> a = [1, 2] >> [ 'x', *a, 'y'] >> >> as syntactic sugar for >> a = [1, 2] >> [ 'x' ] + a + [ 'y' ]. > > You can write that as > a = [1, 2] > a[1:1] = a I'm sure you meant to write: a = [1, 2] b = ['x', 'y'] b[1:1] = a Occasional absence of mind makes other people feel useful! PS actually one *can* write a = [1, 2] ['x', 'y'][1:1] = a since this is not actually an assignment but rather syntactic sugar for a function call, but I don't know how one would use the modified list, since b = ['x','y'][1:1] = a doesn't quite fulfill the initial requirement ;) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 3000 and exec
This might be minor-- but I didn't see anyone mentioning it so far. If `exec` functionality is to be provided, then I think it still should be a keyword for the parser to know; currently bytecode generation is affected if `exec` is present. Even if that changes for Python 3k (we don't know yet), the paragraph for exec should be annotated with a note about this issue. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] itertools.chain should take an iterable ?
"Paolino" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > What if I want to chain an infinite list of iterables? > Shouldn't itertools.chain be built to handle that? Raymond already suggested a four-line function that does exactly that. Create your own personal-library modules containing the functions you find useful as building blocks, and when you have a large sw base using them, present your building blocks along with their use cases as arguments for inclusion in the standard library. > I don't think it is a problem to accept only the second case you paste > and produce TypeError on the others. It would break compatibility with the current uses of itertools.chain . I like it (and have used it) as it is. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Docs/Pointer to Tools/scripts?
"Reinhold Birkenfeld" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hi, > > after adding Oleg Broytmann's findnocoding.py to Tools/scripts, I wonder > whether the Tools directory is documented at all. There are many useful > scripts there which many people will not find if they are not listed > anywhere in the docs. AFAIK the only documentation is the README file in said directory. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] plans for 2.4.2 and 2.5a1
> At the moment I'm trying to create a minimal file that when imported fails > with 2.4.1 . I'll update the case as soon as I have one, but I wanted to > draw some attention in python-dev in case it rings a bell. Please ignore my previous message --through gmane I saw only mwh's message, and after sending my reply, I got Walter's message. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] plans for 2.4.2 and 2.5a1
"Michael Hudson" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Anthony Baxter <[EMAIL PROTECTED]> writes: > >> So I'm currently planning for a 2.4.2 sometime around mid September. I >> figure >> we cut a release candidate either on the 7th or 14th, and a final a week >> later. > > Cool. I'm not sure how many outstanding bugs should be fixed before > 2.4.2. Some stuff to do with files with PEP 263 style declarations? > (Walter? I've lost track of these). This is a serious issue (spurious syntax errors). One bug about files with encoding declarations is www.python.org/sf/1163244 . So far, it seems that source files having a size of f*n+x (for some small indeterminate value of x, and f is a power of 2 like 512 or 1024) occasionally fail to compile with spurious syntax errors. (I once had a file show up the line with the "syntax error", and the reported line was comprised half from the failing line and half from the line above --unfortunately I kept the file for examination in a USB key that some colleague formatted). The syntax errors disappear if the coding declaration is removed or if some blank lines are inserted before the failing line. I think this occurs only on Windows, so it should be something to do with line endings and buffering. At the moment I'm trying to create a minimal file that when imported fails with 2.4.1 . I'll update the case as soon as I have one, but I wanted to draw some attention in python-dev in case it rings a bell. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
"Michael Hudson" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Guard? Monitor? Don't really like either of these. > I know I am late, but since guard means something else, 'sentinel' (in the line of __enter__ and __exit__ interpretation) could be an alternative. Tongue in cheek. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] List copy and clear (was Re: Inconsistent API forsets.Set and build-in set)
"Tim Peters" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Or my personal favorite, > >while mylist: >del mylist[::2] > > Then the original index positions with the most consecutive trailing 1 > bits survive the longest, which is important to avoid ZODB cache bugs > . This is a joke, hopefully, and in that case, I fell for it. If not, please provide a url with related discussion (for educational purposes :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 340 keyword: after
"Chris Ryland" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I hate to add to what could be an endless discussion, but... ;-) > > In this case, "while" is the better time-related prefix, whether > keyword (hopeless, due to ages-old boolean-controlled loop association) > or function, since you want to imply that the code block is going > on *while* the lock is held or *while* the file is open (and you also > want to imply that afterwards, something else happens, i.e., cleanup). > > while_locked(myLock): ># code that needs to hold the lock Ah. You mean 'during' :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Python 2.4 | 7.3 The for statement
It is easier if we see it beforehand: - leave = False alist = [1,2,3,3,4,5,6,7,8,9] for item in alist and not leave: if item is 1: leave = True Apart from other objections, this is valid Python now, and failing with 'TypeError: iteration over non-sequence'. self.introduce: This is not my first Python-dev message, but I never have introduced myself so far. So: I began my career as a programmer in 1990 working with C and Unify Accell/SQL, and continued with various RDBMS systems (Ingres, Oracle) creating commercial tailor-made applications (CRM and ERP, but before these terms were coined AFAIK). However, since 1986 (during school) I helped older friends (students) with C programs on Unix systems (met Unix before IBM compatible machines). And I won't mention Sinclair ZX Spectrum and Sinclair QL use as a kid :) Along programming, I worked as a sysadm for my companies' systems (and as a support sysadm for clients' systems, including SysV/68k, Ultrix, AIX, HP-UX, SCO, Irix, and various Linux distros since 2.4 kernel), so I have a thorough shell scripting background. I never liked Perl when I found out about it, so I continued my awk usage. I also had a very good knowledge of Access 97 at the time (loved the data engine, hated the program itself). Python I met in 2000 as a script to analyse LaBrea tarpit logs, and reading the code instantly clicked for me (it was very close to the language I always intended to write myself RSN :). It was love at first code viewing. I have since become a Python advocate. Personal computer-related interests include image processing (and cataloguing), database design, game solving, "interconnected" generic information storage and retrieval (attempts in which will be superseded soon --hopefully-- by Chandler... :) My current employment as part of the customer support team for SGI systems in EMEA territory leaves little time for Python (attempts at social life worsens things too), and often enough this lack of time makes my posts to comp.lang.python somewhat sloppy... Though I won't ever be a called a *bot, I surely hope I can contribute a little. Thanks for reading! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
