Greg Ewing wrote:
> Raymond Hettinger wrote:
>
>> -1 on an extra built-in just to save the time for function call
>
> The time isn't the main issue. The main issue
> is that almost all the use cases for round()
> involve doing an int() on it afterwards. At
> least nobody has put forward an argume
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
M.-A. Lemburg wrote:
> Terry Reedy wrote:
>> "Michael Hudson" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>> Michael Chermside <[EMAIL PROTECTED]> writes:
>>>
I'm changing the subject line because I want to convince everyone that
the problem being discussed in the "un
Michael Foord wrote:
> David Hopwood wrote:[snip..]
>>
we should, of course, continue to use the one we always used (for
"ascii", there is no difference between the two).
>>> +1
>>>
>>> This seems the most (only ?) logical solution.
>>>
>> No; always considering Unicod
M.-A. Lemburg wrote:
> Michael Chermside wrote:
>>> How about we change unicode-vs-str __eq__ to
>>> issue a warning (and return False) instead of raising
>>> UnicodeException?
>> [... Marc-Andre Lemburg agrees ...]
>>> Great! Now we need someone to volunteer to write a patch (which should
>>
Michael Chermside wrote:
> Jim Jewett writes:
>> This change [in docs] looks wrong:
>>
>> PyDoc_STRVAR(rpartition__doc__,
>> -"S.rpartition(sep) -> (head, sep, tail)\n\
>> +"S.rpartition(sep) -> (tail, sep, head)\n\
>
> Raymond Hettinger replies:
>> It is correct. There may be some confusion in t
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
Josiah Carlson wrote:
> "BJörn Lindqvist" <[EMAIL PROTECTED]> wrote:
>>> If there are "rampant criticisms" of the Python docs, then those that
>>> are complaining should take specific examples of their complaints to the
>>> sourceforge bug tracker and submit documentation patches for the
>>> releva
Nick Coghlan wrote:
> Hans Polak wrote:
>> Hi,
>>
>>
>>
>> Just an opinion, but many uses of the ‘while true loop’ are instances of
>> a ‘do loop’. I appreciate the language layout question, so I’ll give you
>> an alternative:
>>
>>
>>
>> do:
>>
>>
>>
>>
>>
>>
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.
Nick Coghlan wrote:
> Fuzzyman wrote:
>> Nick Coghlan wrote:
>>> In my example, the 3 sections (, and >> completion
>>> code> are all optional. A basic do-while loop would look like this:
>>>
>>> do:
>>>
>>> while
>>>
>>> (That is, is still repeated each time around t
Gregory P. Smith wrote:
>> I've never liked the "".join([]) idiom for string concatenation; in my
>> opinion it violates the principles "Beautiful is better than ugly." and
>> "There should be one-- and preferably only one --obvious way to do it.".
>> (And perhaps several others.) To that end I
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
>>>>
> The only benefit I imagine would be for an extension module library
> writer and for users of the struct and array modules. But, other than
> that, I don't know. It actually doesn't have to be exposed to Python.
> I used Python notation in the PEP to explain what is basically a
> C-structur
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 access: I ended
> up ha
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 produced pages.
Additional in
Larry Hastings wrote:
> Just asking--are you going in a PEP-287-ly way as you work? If not,
> would your work make PEP 287 easier to implement?
Pydoc does no reformatting or changes to doc strings. They are displayed "as
is" in plain text. About the only formatting that is done is to wrap lo
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?
>
> What I did barely qualifies a
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
Neal Becker wrote:
> No time to review this now, but I'd just like to say that the 1 thing I'd
> like to see is support for decent mathematical markup. I think at this
> point that support for latex markup is the way to achieve this.
There are two separate issues related to this I'd like to point
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
Raymond Hettinger wrote:
> [A.M. Kuchling]
>> 2.6 wouldn't go changing existing APIs to begin requiring or returning
>> the bytes type[*], of course, but extensions and new modules might use
>> it.
>
> The premise is dubious.
>
> If I am currently maintaining a module, why would I switch to a byt
Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Feb 12, 2007, at 7:32 PM, Guido van Rossum wrote:
>
>> Oh, now I am definitely in favor of .[]! I read it in gmail in FireFox
>> which uses a small variable-pitch font whose dot is a single pixel.
>> The .() example was
Georg Brandl wrote:
> Martin v. Löwis schrieb:
>> Anthony Baxter schrieb:
and the "wrapper class" idea of Nick Coghlan:
attrview(obj)[foo]
>>> This also appeals - partly because it's not magic syntax
>> I also like this. I would like to spell it attrs, and
>> I think its specification
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.)
>>
>>
Larry Hastings wrote:
> Neal Becker wrote:
>> Instead, bool fails in _the worst possible way_: it silently gives a
>> _wrong result_.
>
> I disagree with the word "fail" there; Python is working correctly. The
> behavior of converting expressions to a boolean is well-defined:
> http://docs.
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
Delaney, Timothy (Tim) wrote:
> What I'm proposing is that the `super = super_factory()` line be
> implicit in this case, resulting in the following code behaving
> identically:
>
> class A(object):
> def f(self):
> def inner():
> return 'A' + super.f()
>
Georg Brandl wrote:
> FWIW, I'm -1 on both proposals too. I like implicit string literal
> concatenation
> and I really can't see what we gain from backslash continuation removal.
>
> Georg
-1 on removing them also. I find they are helpful.
It could be made optional in block headers that end
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
>>
Martin v. Löwis wrote:
>> This is what prompted my question, actually: in Py3k, in the
>> str/unicode unification branch, r"\u1234" changes meaning: before the
>> unification, this was an 8-bit string, where the \u was not special,
>> but now it is a unicode string, where \u *is* special.
>
> That
Georg Brandl wrote:
> Hi,
>
> over the last few weeks I've hacked on a new approach to Python's
> documentation.
> As Python already has an excellent documentation framework, the docutils,
> with a
> readable yet extendable markup format, reST, I thought that it should be
> possible to use those
Talin wrote:
> Josiah Carlson wrote:
>> Captchas like this are easily broken using computational methods, or
>> even the porn site trick that was already mentioned. Never mind
>> Stephen's stated belief, that you quoted, that he believes that even the
>> hard captchas are going to be beaten by com
On 12/18/2010 04:46 PM, Terry Reedy wrote:
On 12/18/2010 3:48 PM, Antoine Pitrou wrote:
On Sat, 18 Dec 2010 21:00:04 +0100 (CET)
ezio.melotti wrote:
Author: ezio.melotti
Date: Sat Dec 18 21:00:04 2010
New Revision: 87389
Log:
#10573: use actual/expected consistently in unittest methods.
Ch
On 12/24/2010 02:03 PM, Raymond Hettinger wrote:
On Dec 24, 2010, at 10:56 AM, Terry Reedy wrote:
On 12/24/2010 11:09 AM, Michael Foord wrote:
On 22/12/2010 02:26, Terry Reedy wrote:
On 12/21/2010 7:17 AM, Michael Foord wrote:
My first priority is that doc and code match.
Close second is
On 01/10/2011 12:01 PM, Antoine Pitrou wrote:
Hello,
I would like to advocate again for the removal of the "unit test
needed" stage on the tracker, which regularly confuses our triagers
into thinking it's an actual requirement or expectation from
contributors and bug reporters.
This keeps
:-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/pyth
On 02/01/2011 09:51 AM, anatoly techtonik wrote:
So far only Georg explained what patches sent to mailing list will not
be reviewed, because there is too much volume. But bugtracker is not a
patch tracker. It doesn't allow to monitor incoming patches by module,
its search is very poor. Of cour
On 03/01/2011 01:22 PM, Georg Brandl wrote:
On 01.03.2011 16:05, Antoine Pitrou wrote:
On Tue, 1 Mar 2011 16:52:58 +0200
Eli Bendersky wrote:
The PEP (http://www.python.org/dev/peps/pep-0385/) says in "Timeline":
2010-03-05: final conversion (tentative)
I assume 2011-03-05 is meant here.
On 03/04/2011 09:30 AM, Nick Coghlan wrote:
Fixing dual imports of the main module
--
Two simple changes are proposed to fix this problem:
1. In ``runpy``, modify the implementation of the ``-m`` switch handling to
install the specified module in ``sys.
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!
>>&
Georg Brandl wrote:
> Hi,
>
> We managed to get an up to date version of the web version of the docs running
> on the server. The address is still the same (http://pydoc.gbrandl.de:3000)
> and
> it's also still running on top of wsgiref.
>
> Changes so far:
>* comments: each page that is gen
Georg Brandl wrote:
> Sure, you could use ``iter(())`` or ``iter([])``, but for consistency's sake
> wouldn't it make sense for ``iter()`` to return an empty iterator, as
> ``str()``
> returns an empty string etc.?
>
> Georg
There is a difference.
>>> type(iter)
>>> type(str)
>>> type(int
Facundo Batista wrote:
> 2007/9/10, Facundo Batista <[EMAIL PROTECTED]>:
>
>> I modified my tool, whichs makes a summary of all the Python tickets
>> (I moved the source where the info is taken from SF to our Roundup).
>
> Based on an idea from Dennis Benzinger, now the temporal bars show the
>
The value of a unittest test is not in how well they pass, but in how well
they fail.
While looking at possibly helping with the str_uni branch when that was
going on I found that in some cases unittest failure results can take a
little bit (or a lot) of work to figure out just what was fai
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
>>
Christian Heimes wrote:
> I'm sending this mail to Python-dev in the hope to reach more developers.
>
> GvR likes to rename the __builtin__ to reduce confusing between
> __builtin__ and __builtins__. He wanted to start a poll on the new name
> but apparently he forgot.
>
>>From http://bugs.pyth
Fred Drake wrote:
> On Nov 28, 2007, at 9:31 PM, Brett Cannon wrote:
>> +1 for either __root_namespace__ or __root__.
>
>
> What is it with nutrient extractors for plants that makes sense here?
Root is a word that takes on a specific meaning depending on the context.
Root as in tooth
Facundo Batista wrote:
> 2007/11/1, Facundo Batista <[EMAIL PROTECTED]>:
>
>>> I think the keyword and keywords interface can be improved. Do you have
>>> any plans in that direction?
>> Surely!
>>
>> But, no, I have no plans to do it, as I can not make cgi scripts in my
>> hosting, so these pa
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
>>
>> -
Raymond Hettinger wrote:
> The standard library, my personal code, third-party packages, and my
> employer's code base are filled with examples of the following pattern:
>
> try:
>import threading
> except ImportError:
>import dummy_threading as threading
>
> try:
> import xml.etre
Raymond Hettinger wrote:
> Please ignore my last email. The idea for combining trunc, ceil,
> floor, etc was probably just a distractor.
I was going to suggest the same round(n, mode="round_method_of choice") to
both round and int(), where int is more forgiving for input. But wasn't
convince
Barry Warsaw wrote:
> Why should docstrings and comments be limited to 72 characters when
> code is limited to 79 characters? I ask because there is an ongoing
> debate at my company about this.
I'm not sure if this is the main reason, but when using pydoc to view
docstrings, the 72 chara
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
Nick Coghlan wrote:
> Martin v. Löwis wrote:
>> One issue to consider is also politeness. People sometimes complain that
>> they feel treated unfair if their report is declared "invalid" - they
>> surely believed it was a valid report, at the time they made it.
>
> I agree with Martin for both o
Michael Foord wrote:
> Guido van Rossum wrote:
>> I'm worried that a mass renaming would do anything but inconvenience
>> users during the already stressful 2->3 transition.
>>
>> I'm more in favor of the original proposal of reducing the redundancy
>> post-3.0.
>>
>>
>
> So nix the PEP-8'if
Raymond Hettinger wrote:
"Jim Jewett"
It isn't really stringiness that matters, it is that you have to
terminate even though you still have an iterable container.
Well said.
Guido had at least a start in Searchable, back when ABC
were still in the sandbox:
Have to disagree here. An obj
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
Antoine Pitrou wrote:
Ben Finney benfinney.id.au> writes:
That would better be written (preferring PEP 8 names)
"fail_unless_equal".
Which is still a double negative ("fail" and "unless" are both negative words).
That's another reason to avoid "assert" in the name: these methods
*don't* n
Raymond Hettinger wrote:
From: "Ben Finney" <[EMAIL PROTECTED]>
Right, so I'm putting up a separate PEP just for the renaming. Should
be arriving on this list soon.
I would like to work with you or someone else who is interested
on an alternative PEP for a separate, simpler test module
using
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
Nick Coghlan wrote:
Taking an existing function such as assertRaises and going "hey, we
aren't using the return value from this, wouldn't it be really
convenient if it told us the exact exception it actually caught?"
doesn't cause any problems for existing code, and makes it much easier
to
Steven D'Aprano wrote:
Michael Foord wrote:
Don't we have a pretty-print API - and isn't it spelled __str__ ?
Not really. If it were as simple as calling str(obj), there would be no
need for the pprint module.
I agree. And when I want to use pprint, there are usually additional
output
On Wed, 2011-10-19 at 22:17 +0300, anatoly techtonik wrote:
> Does everybody feel comfortable with 'stage' and 'resultion' fields in
> tracker?
>
> I understand that 'stage' defines workflow and 'resolution' is status
> indicator, but the question is - do we really need to separate them?
> For ex
Hi, I Just added issue 13607 with a patch that removes the generator
specific checks and code out of the ceval PyEval_EvalFrameEx() function.
Those parts where moved up into the generator gen_send_ex() function.
Doing that removed the generator flag checks from the eval loop and made
it a bit c
On Mon, 2012-01-02 at 14:44 +1000, Nick Coghlan wrote:
> I've been having an occasional argument with Benjamin regarding braces
> in 4-line if statements:
>
> if (cond)
> statement;
> else
> statement;
>
> vs.
>
> if (cond) {
> statement;
> } else {
> statement;
> }
>
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
Josiah Carlson wrote:
> Ron Adam <[EMAIL PROTECTED]> wrote:
>
>>Josiah Carlson wrote:
>>
>>>>I think a completely separate looping or non-looping construct would be
>>>>better for the finalization issue, and maybe can work with class's with
&
Nick Coghlan wrote:
> Iterating over a sequence. If it's single-pass (and always single pass), you
> should use a user defined statement instead.
> That's the technique suggested for the single-pass user defined statements.
> However, a 'for loop with finalisation' is *still fundamentally an i
Josiah Carlson wrote:
> Ron Adam <[EMAIL PROTECTED]> wrote:
>>I should have said "...should not finalize at the end of the for loop".
>> With generators, you may not want them to finalize before you are done
>>with them, and the same with class&#x
Josiah Carlson wrote:
> Ron Adam <[EMAIL PROTECTED]> wrote:
>
>> There's also the possibility to use conditional looping based on the
value returned from the generator.
>>
>> do VAR from EXPR if VAR==CONST:
>>BLOCK
>&g
101 - 200 of 280 matches
Mail list logo
