On 11/30/2010 07:19 PM, Nick Coghlan wrote:
On Wed, Dec 1, 2010 at 8:48 AM, Ron Adam wrote:
* It almost seems like the concept of a sub-module (in a package) is flawed.
I'm not sure I can explain what causes me to feel that way at the moment
though.
It isn't flawed, it is j
chose to
mention one of the ones that could easily make the affected code
*break* :)
Right. It would require additional pieces as well.
Ron :-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscrib
nconsistencies would be found sooner. The
doc strings could be the brief quick ref documents, which it currently
isn't always brief and/or present, and the python manual could include
the pydoc output (or selected parts of it) along with the longer
explanation and discussion. Having pydo
no performance advantage to combining the two, I think it
would be better to keep them separate. So I'm -0 on giving the int
constructor a rounding argument.
Just my 2 cents,
Ron
___
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
dd up the effort over all the
> programs that use int(round()).
I think the only time it would be a burden is if a single program uses
int(round()) many times, otherwise it is only a very small additional
amount to type for each program. In the case of single program using it
many times, a
Nick Coghlan wrote:
> Ron Adam wrote:
>> Consider an example where you are combining data that had different
>> number of significant digits. Keeping all the digits of your answer
>> gives a false since of accuracy. The extra digits are meaningless
>> because the
a case where it should be up to the programmer to make sure
the comparison makes sense in the context it is being used. That is, if
I'm comparing two different forms of data, it's up to me to convert them
explicitly to the same form before comparing them?
In the case of comparin
ued behavior in the documents as well. And so
Unicode to String comparisons should be the second exception to not
doing data form conversions when comparing two objects. At least for
pre-Py3k.
Are there other cases where different types of objects compare equal?
(Not including those where the us
t be possible to generate warnings when either Unicode or stings
are coerced to the other implicitly but not explicitly?
That may also generate a warning in the case of the dictionary problem
being discussed, (I think), and may be more useful for checking for
non-intentionally mixed Unicode and s
of sep from the right
into a tuple of left, sep, and right parts.
Returns ('', '', S) if sep is not found in S.
I feel the terms head and tail, rest etc... should be used in examples
where their meaning will be clear by the context they are used in. But
not in the definition where their meanings are not obvious.
Cheers,
Ron
___
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
Ron Adam wrote:
Correcting myself...
> I hope this discussion is only about the words used and the
> documentation and not about the actual order of what is received. I
> would expect both the following should be true, and it is the current
> behavior.
>
> ''
Raymond Hettinger wrote:
> Another thought is that strings don't really have a left and right.
> They have a beginning and end. The left/right or top/bottom distinction
> is culture specific.
Well, it should have been epartition() and not rpartition() in that case. ;-)
Is python ever edite
c
strings.
Many of those are documented format lines with the form ...
name( longs_list_of_arguments ... ) -> long_list_of_return_types ...
Rather than fix all of those, I'm changing the version of pydoc I've been
rewriting to wordwrap lines. Although that's not the
ng the exit_condition at the top doesn't really put anything out of order.
If the exit_condition is not evaluated until the top of the second loop, the
names it uses do not need to be pre defined, they can just be assigned in the
loop.
Ron
___
P
Michael Urman wrote:
> On 10/1/06, Ron Adam <[EMAIL PROTECTED]> wrote:
>> (I don't think this has been suggested yet.)
>>
>> while , :
>>
>
> [snip]
>
>> Putting both the entry and exit conditions at the top is easier to read.
n't strike me as super important" [1]
I looked though a few files in the library for different while usage patterns
and there really wasn't as many while loops that would fit this pattern as I
expected. There are much more while loops with one or more exit conditions in
the middle as th
dedent_lines, prepend_lines, wrap_lines, and of course join_lines
as in '\n'.join(L), the inverse of s.splitlines(), and there also readlines()
and writelines(). Also possilby find_line or find_in_lines(). These really
shouldn't seem anymore out of place than numeric ope
Josiah Carlson wrote:
> Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>> Ron Adam wrote:
>>
>>> I think what may be missing is a larger set of higher level string
>>> functions
>>> that will work with lists of strings directly. Then lists of strings
Nicko van Someren wrote:
> On 6 Oct 2006, at 12:37, Ron Adam wrote:
>
>>>> I've never liked the "".join([]) idiom for string concatenation; in my
>>>> opinion it violates the principles "Beautiful is better than ugly." and
>>>>
objects" without the duplications of the python type for
every element.
I think maybe some more complete examples demonstrating how it is to be used
from both the Python and C would be good.
Cheers,
Ron
___
Python-Dev mailing list
Python-Dev@
The still very rough source files can be downloaded from:
http://ronadam.com/dl/_pydoc.zip
There is still much to do, but I think having some experienced feed back on
where it should go is important.
Cheers,
Ron Adam
ps.. Please disregard the website for now, it's purpose wa
Laurent Gautier wrote:
> Ron,
>
> I agree that pydoc could benefit a bit from some cleanup.
> As you point it out, the ability to write quick viewers would be
> very helpful. I came across that when wanting to develop script
> on a remote web server for which I only had FTP ac
Ka-Ping Yee wrote:
> Hi Ron and Laurent,
>
> I welcome attempts to improve pydoc (especially since I don't have
> much time to work on improving it myself). I definitely agree that
> moving to CSS is long overdue, though I would like some input on
> the style of the prod
for docstrings":
> http://www.python.org/dev/peps/pep-0287/
Thanks for the link. PEP 287 looks to be fairly general in that it expresses a
general desire rather than a specification.
Ron
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyt
Laurent Gautier wrote:
> Ron,
>
> Thanks for your detailed answer.
> I inserted comments below.
You welcome.
>> I think any API issues could be worked out. Are there any programs
>> you know of,
>> (yours?), that import pydoc besides the python console?
&g
Talin wrote:
> Ron Adam wrote:
>> Larry Hastings wrote:
>>> For those of us without eidetic memories, PEP 287 is "use
>>> reStructuredText for docstrings":
>>> http://www.python.org/dev/peps/pep-0287/
>> Thanks for the link. PEP 287 l
Laurent Gautier wrote:
> 2007/1/6, Ron Adam <[EMAIL PROTECTED]>:
>> Laurent Gautier wrote:
> [...]
> I read your comment about having not too many things changed for 2.6.
> (or that will be bumped to 3000).
>
> A suggestion I would have would be to create an h
came from.
I don't know latex markup, but it seems like mathematical latex markup might be
done either way.
Cheers,
Ron
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:
Laurent Gautier wrote:
> 2007/1/7, Ron Adam <[EMAIL PROTECTED]>:
>> Laurent Gautier wrote:
>> > 2007/1/6, Ron Adam <[EMAIL PROTECTED]>:
> [...]
>> I'd like to know more about using the sandbox, I know it would be easy
>> for
>> people to rea
nformation I need. The actual editing is not a problem.
I think making external utilities such as these easy to use will go a long way.
Cheers,
Ron
___
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
#x27;Hello World'
if bar.['__%s__' % attr] > -42: print 'Hello World'
To me it's easier to parse the second one visually.
Ron
___
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
;m overlooking something obvious I think, but the spelling is nice.
obj[foo] -> access content
obj.foo -> access attribute directly
obj.attr[foo]-> access attribute dynamically
Ron
___
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
Martin v. Löwis wrote:
> Ron Adam schrieb:
>> Would it be possible for attrview to be a property?
>
> Sure. It might conflict with a proper name of an attribute, of course.
>
>> Something like... (Probably needs more than this to handle all cases.)
>>
>>
f somelist: ...
if somedict: ...
If they do have contents of some some type, you then need to test the
contents to see what is in them. Which might be a True or False values of
some type.
I suggest you take this to comp.lang.python to get further help with using
bool. It is a good idea to test thoughts like this out there first.
Cheers,
Ron
___
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
Neal Norwitz wrote:
> I recognize there is a big problem here. Each of us as individuals
> don't scale. So in order to get stuff done we need to be more
> distributed. This means distributing the workload (partially so we
> don't burn out). In order to do that we need to distribute the
> know
Neal Norwitz wrote:
> On 3/6/07, Ron Adam <[EMAIL PROTECTED]> wrote:
>> Neal Norwitz wrote:
>>
>> I'm looking forward to a new tracker and hope it manages single
>> projects...
>> (patches and bugs) better. It would be great if we could search for
Martin v. Löwis wrote:
> Ron Adam schrieb:
>> But the tracker needs to be able to actually track the status of
>> individual items for this to work. Currently there's this huge list
>> and you have to either wade though it to find out the status of each
>> ite
Johann C. Rocholl wrote:
> Brilliant!
>
> On 4/1/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> def foo${LATIN SMALL LETTER LAMBDA WITH STROKE}$(x${DOUBLE-STRUCK
>> CAPITAL C}$):
>> return None${ZERO WIDTH NO-BREAK SPACE}$
>>
>> This is still easy to read and makes the full power of
an be submitted and a final discussion can take place on the
python-dev list at a later date.
Thanks and Regards,
Ron Adam
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pytho
ord?
class A(object):
def f(self):
def inner():
super f
return 'A' + f()
print inner()
Cheers,
Ron
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
continuation character even though
it's not at the end of a physical line. So it gives an error.
In the second case, its accepted as a continuation character, *and* a '\'
character at the same time. (?)
Cheers,
Ron
___
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
Benji York wrote:
> Ron Adam wrote:
>> The following inconsistency still bothers me, but I suppose it's an edge
>> case that doesn't cause problems.
>>
>> >>> print r"hello world\"
>>File "", line 1
>>
.MULTILINE)
-s = unicode(r'\x00="\'a\\b\x80\xff\u\u0001\u1234',
'unicode-escape')
+s = unicode(r'''\x00="\'a\\b\x80\xff\u\u0001\u1234''', d
-_escape = re.compile(r"[&<>\"\x80-\xff]+"
. You just need to supply
a callback to get the pages. It's a separate module now.
Cheers,
Ron
> I've written a converter tool that handles most of the LaTeX markup and turns
> it
> into reST, as well as a builder tool that adds many custom directives and
> roles,
> a
far we've only had one instance over how long?
Lets spend the brain power on getting it up and running first.
Cheers,
Ron
___
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
would be in
the category of foolish consistency because changing that, introduces other
inconsistencies I'd rather not have.
It doesn't bother me that the functions arguments aren't the same order of
the diffs as long as the labels and wording are obvious eno
uot; are just two objects.
The terms "x in y" and "x not in y" look like what you should get from
containment or regex asserts.
I guess what I'm try to say is think of the whole picture when trying to
make improvements like these, an idea that works for one or two thing
n.) That
description fits well with the items already there.
An open status is the same as (not (closed-committed or closed-rejected)).
The placement of some items could be better. Status, and priority would
fit better in the classification section. Stag
:-D
Great job Georg!
Ron Adam
On 01/16/2011 01:33 AM, Georg Brandl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On behalf of the Python development team, I'm very happy to announce the
first release candidate of Python 3.2.
Python 3.2 is a continuation of the efforts to im
27;has no name')
>>> e.__name__
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'Exception' object has no attribute '__name__'
Ron Adam
___
Python-Dev mailing list
Python-Dev@python.o
On 01/17/2011 02:27 PM, Georg Brandl wrote:
Am 17.01.2011 21:22, schrieb Ron Adam:
Is this on purpose?
Python 3.2rc1 (py3k:88040, Jan 15 2011, 18:11:39)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more informati
On 01/18/2011 01:14 AM, Georg Brandl wrote:
For these cases, you can use traceback.format_exception_only().
Thanks George, That works nicely.
Ron ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
e hardest part is making changes in a
way that is very unlikely to break someone's program. Mess up someone's
pay role process some place (even by the smallest change) and people will
get very unhappy really quick. It's also not good to crash space shuttles
or google. ;-)
Cheers,
meant here.
Oh... I guess I was a bit optimistic.
Thanks for noticing
Hey, I still got the time machine locked away in my parents' basement...
It's a time machine, there is no way you can be sure it isn't being used in
this present time, from some other time pe
ed out.
I suggest separating these two items out into their own PEP, and doing them
first.
Cheers,
Ron
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/
On 03/05/2011 01:14 AM, Nick Coghlan wrote:
On Sat, Mar 5, 2011 at 2:40 PM, Ron Adam wrote:
Fixing direct execution inside packages
+1 on both of these.
I don't see any major problems with these. Any minor issues can be worked
out.
I suggest separating these two items out into thei
On 03/05/2011 06:33 PM, Nick Coghlan wrote:
On Sun, Mar 6, 2011 at 4:11 AM, Ron Adam wrote:
Adding a second references to the '__main__' module begins to blur the
purpose of sys.modules from being a place to keep imported modules to a
place that also has some ordering i
#x27;d be very happy!
>>>
>>> Maybe your quick dispatch feature could be added to pydoc too?
>> It is my intention to work together with Ron Adam to make the pydoc <->
>> documentation integration as seamless as possible.
>
> So I'll be able to re
ly lacking.
>>>>
>>>> If pydoc could show all this documentation as well I'd be very happy!
>>>>
>>>> Maybe your quick dispatch feature could be added to pydoc too?
>>> It is my intention to work together with Ron Adam to make the pyd
Nick Craig-Wood wrote:
> On Wed, May 23, 2007 at 12:46:50PM -0500, Ron Adam wrote:
>> Nick Craig-Wood wrote:
>>> So I'll be able to read the main docs for a module in a terminal
>>> without reaching for the web browser (or info)? That would be great!
>>&
---
copy right
The user comment section could have it's own side bar if that's desirable.
Also the python version information needs to be on every page someplace.
Ron
___
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
type(iter)
>>> type(str)
>>> type(int)
>>> type(list)
Cheers,
Ron
___
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
ks. That is
hard to see on my computer because it is so close to the grey tone.
Also shouldn't the light blue background bar extend all the way to the end
for all open items?
Cheers,
Ron
___
Python-Dev mailing list
Python-Dev@python.org
http://
adding
this as an option for those who want to use it is very easy to do.
The test file I used to generate the following output is attached.
Cheers,
Ron
###
#
# Test output using standard assertEquals and assertRaises.
#
* The data has the form [(ref#, expect, args, kwds), ...]
Facundo Batista wrote:
> 2007/9/19, Ron Adam <[EMAIL PROTECTED]>:
>
>> I noticed that there is a background of light blue between marks. That is
>> hard to see on my computer because it is so close to the grey tone.
>
> Made it a little darker, now it's easi
Facundo Batista wrote:
> 2007/10/24, Ron Adam <[EMAIL PROTECTED]>:
>
>>> Note that these items are *all* open.
>> I think the page title should reflect this. Possible changing it from
>>
>> "Python tickets"
>>
>> to
>>
mond on __root__ but I'm still
> open for better suggestions.
My first thought was that __root__ would be the global name space and
__builtin(s)__ would be the default module that gets loaded into the
__root__ name space. But I see I have that reversed.
Ron
___
t__ relatively short has the benefit of being able to easily
use "__root__.name" in the case where "name" was/is used in the local
scope. I don't see any reason to make it harder. There might even be a
use case for using all explicit __root__ references.
So +1 on __root__ f
ature > rejected > closed
Filtering on the above status keywords would give good results I think.
The fix-provided and patch_provided status items might be split into tests,
docs, and patch/fix provided. But that may not be needed.
Cheers,
Ron
&g
Facundo Batista wrote:
> 2007/12/8, Ron Adam <[EMAIL PROTECTED]>:
>
>> Looks much improved! :-)
>
> Thanks!
>
>
>> Maybe components and keywords could be combined together and use check
>> boxes so more than one item at a time can be selected
Facundo Batista wrote:
> 2007/12/10, Ron Adam <[EMAIL PROTECTED]>:
>
>> This is from the search page of the tracker.
>>
>>
>> don't care
>>
>>
>> accepted
>>
>> duplicate
>>
* This didn't show up when I sent it the other day, so I'm resending it.
Facundo Batista wrote:
> 2007/12/10, Ron Adam <[EMAIL PROTECTED]>:
>
>> This is from the search page of the tracker.
>>
>>
>> don't care
>>
>> -
import.
This still improves readability and flattens out the multiple nested
structure which I believe is what makes the current way unappealing.
I think multiple possible imports in "from - import"s statements should not
be allowed. When you consider multiple imports from possibly m
going into the math module.
Works for me.
It seems simple enough to just do ...
from math import round_even as round
This gives me the specific rounding behavior I want without a lot of noise.
Ron
>> I should also admit that the 2-arg version of round() was
>> borrowed f
trings, the 72 character width allows for the added indent in class and
method sections.
Ron
___
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/
Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Feb 21, 2008, at 12:33 PM, Ron Adam wrote:
>
>> Barry Warsaw wrote:
>>
>>> Why should docstrings and comments be limited to 72 characters when
>>> code is limited to 79 c
can be confused with 'solution/patch works for me'.
I've generally seen the phrase 'works for me' to mean agreement of a
proposed action of some sort.
Maybe something along the lines of 'can not reproduce' would be better?
Ron
> I'd prefer to k
sults in a
regular python exception and a trace back of the test case. An error in
the module being tested results in an specific unittest exception
indicating what type of error was found in the module followed by the
original exception and traceback from the module being tested.
Ro
t more flexible it could be changed just a bit.
def flatten(L):
""" Flatten a list in place. """
objtype = type(L)
i = 0
while i < len(L):
while type(L[i]) is objtype:
L[i:i+1] = L[i]
i += 1
return L
Martin v. Löwis wrote:
How does 1 directory scale when one day you have possibly thousands of
tests?
I find this a theoretical question. It took 18 years to arrive at 500
test files. Assuming a linear growth, we get 1000 tests in 2025, and
2000 tests in 2060. People can worry about reorganizi
pecific exception code can better handle some cases where a
wrong traceback would be returned. ie.. the test code traceback rather
than the code being tested traceback.
Is there any interest in going in this direction with unittests?
Ron
_
t also reduces the level of indentation needed.
Ron
___
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
Ben Finney wrote:
Ron Adam <[EMAIL PROTECTED]> writes:
+1 for a simpler testing module.
I've no objection.
Just letting you know there is interest in a lighter weight testing
suite.
'doctest' is a very simple testing module, that is a very useful tool.
Lo
en the exception needs to be caught and passed out
via the failureException, and not the returned value.
Ron
___
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
f use that is more useful?
For example for partially consumed iterators it might be useful to express
how many items have been taken, and how many are left to take when that
info is available. (?)
The idea is that pretty printing is usually used
-+
And just list the stages like...
status: Open stage: In progress -> needs docs
status: Open stage: In progress -> needs patch review
status: Open stage: Accepted -> commit review
status: Closed stage: Accepted -> committed
stat
lds about 10% faster, and everything else about
2%-3% faster (on average). But it does need to be checked.
Cheers,
Ron
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mai
ngle line.)
The next level up would be to require them on all blocks, even two line
if expressions, but I'm not sure that is really needed. At some point
the extra noise of the braces makes things harder to read rather than
easier, and what you gain in preventing one type of error may in
Hi, this is my first post here and I've been following this very
interesting discussion as is has developed.
A really short intro about me, I was trained as a computer tech in the
early 80's... ie. learned transistors, gates, logic etc... And so my
focus tends to be from that of a troublesho
he expression as a
whole as a 'service' or a 'resouce manager'. And a simple description
of it would be
A SERVE statement serves NAME(s) from a SERVER to the following
statement block.
(Details of how to use SERVE blocks and SERVERS.)
Ron Adam
__
Guido van Rossum wrote:
[Ron Adam]
How about 'serve' as in a server of items from a service?
No, please. This has way too strong connotations with network protocols.
Errr... you're right of course... :-/ (I was thinking *way* to narrow.)
I think the context is correct, just need
I expect there's an obvious reason why this hasn't been suggested
already that I'm not currently thinking of, but here it is anyway. :-)
How about an *extended while* syntax as a block keyword alternative?
Reasoning: The block statement resembles a "while" block in some ways in
that it is a
Eric Nieuwland wrote:
> This is linear. No looping whatsoever. And easily translated to a
> simple language construct and a protocol:
>
> class resource(object):
> def __init__(self,...):
> # store resource parameters
> def __acquire__(self):
> # whatever
Gustavo Niemeyer wrote:
> Greetings,
>
>
>>Reasoning: The block statement resembles a "while" block in some ways in
>>that it is a conditional block that may be executed only once, or
>>possibly not at all (or many times). And the word "while" is also
>>descriptive of how a block is used.
>>
Eric Nieuwland wrote:
> Ron Adam wrote:
>
>> Eric Nieuwland wrote:
>>
>>> This is linear. No looping whatsoever. And easily translated to a
>>> simple language construct and a protocol:
>>>
>>> class resource(object):
>>
Ron Adam wrote:
A minor correction to the Block class due to re-editing.
> def __call__(self, *args):
> self.block(*args)
> self.__del__()
This should have been.
def __call__(self, *args):
try:
self.block(*args)
except Except
Phillip J. Eby wrote:
> At 01:58 PM 5/6/2005 +1000, Delaney, Timothy C (Timothy) wrote:
>
>>Personally, I'm of the opinion that we should make a significant break
>>(no pun intended ;) and have for-loops attempt to ensure that iterators
>>are exhausted.
>
>
> This is simply not backward compatib
Josiah Carlson wrote:
> You should know why that can't work. If I pass a list, is a list an
> iterator? No, but it should neither be created nor destroyed before or
> after.
>
> The discussion has been had in regards to why re-using 'for' is a
> non-starter; re-read the 200+ messages in t
Nick Coghlan wrote:
> Ron Adam wrote:
>
>>I agree, re-using or extending 'for' doesn't seem like a good idea to me.
>
>
> I agree that re-using a straight 'for' loop is out, due to performance and
> compatibility issues with applying finalis
Josiah Carlson wrote:
> For is already tuned to be as fast as possible, which makes sense; it is
> used 4,523 times in Python 2.4.0's standard library, and easily hundreds
> of thousands of times in user code. Changing the standard for loop is
> not to be done lightly.
Agreed!
>>And why this is
101 - 200 of 285 matches
Mail list logo
