Greg Ewing wrote:
> Ron Adam wrote:
>
>>There seems to be some confusion as to weather or
>>not 'for's will do finalizing. So I was trying to stress I think
>>regular 'for' loops should not finalize. They should probably give an
>>error if an
Josiah Carlson wrote:
> I wasn't expressing my opinion, I was attempting to express as to where
> the discussion went and concluded. I honestly can't remember having an
> opinion on the subject, but I seem to have convinced Nick earlier that
> they shouldn't loop, and he (re-)convinced me that in
Josiah Carlson wrote:
>> Ron Adam <[EMAIL PROTECTED]> wrote:
>>Yes, so just "do [VAR from] EXPR1:"
>
> Regardless of the 'finalization' syntax, I'm talking about the fact that
> including extra 'if EXPR' or 'while EXPR
It's been interesting watching all the loops this discussion has gone
through. I'm not sure the following is compatible with the current
proposals, but maybe it will spur some ideas or help rule out something.
There have been several examples of problems with opening several
resources inside
A additional comment (or 2) on my previous message before I go back to
lurk mode.
If the recommended use of each resource template is kept to a single
resource, then each enter and exit can be considered a whole block of
code that will either pass or fail. You can then simplify the previous
t
Reinhold Birkenfeld wrote:
> Hello,
>
> I am currently having some thoughts about the standard library, with regard
> to Python 2.5 and 3.0. Since I don't want to withhold them from you, here
> are they ;)
>
> - Flat namespace: Should we tend to a more hierarchic library (e.g.
> inet.url, inet.
Bob Ippolito wrote:
>
> On Jun 7, 2005, at 11:47 AM, Josiah Carlson wrote:
>
>> Ron Adam wrote:
>> [snip]
>>
>>> Having less in the core distribution means smaller complete
>>> applications
>>> to install when py2exe is used. There
Greg Ewing wrote:
> Guido van Rossum wrote:
>> On 2/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>
>>> At 04:29 PM 2/13/2006 -0800, Guido van Rossum wrote:
>>>
On 2/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
What would bytes("abc\xf0", "latin-1") *mean*?
>>> I'm saying th
Greg Ewing wrote:
> Ron Adam wrote:
>
>> My first impression and thoughts were: (and seems incorrect now)
>>
>> bytes(object) -> byte sequence of objects value
>>
>> Basically a "memory dump" of objects value.
>
> As I understa
Greg Ewing wrote:
> I think you don't understand what an encoding is. Unicode
> strings don't *have* an encoding, because theyre not encoded!
> Encoding is what happens when you go from a unicode string
> to something else.
Ah.. ok, my mental picture was a bit off. I had this reversed somewhat.
Josiah Carlson wrote:
> Bob Ippolito <[EMAIL PROTECTED]> wrote:
>>
>> On Feb 17, 2006, at 8:33 PM, Josiah Carlson wrote:
>>
>>> Greg Ewing <[EMAIL PROTECTED]> wrote:
Stephen J. Turnbull wrote:
>> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
> Guido> - b = bytes(t, en
Josiah Carlson wrote:
> Ron Adam <[EMAIL PROTECTED]> wrote:
>> Josiah Carlson wrote:
>>> Bengt Richter had a good idea with bytes.recode() for strictly bytes
>>> transformations (and the equivalent for text), though it is ambiguous as
>>> to the d
Aahz wrote:
> On Sat, Feb 18, 2006, Ron Adam wrote:
>> I like the bytes.recode() idea a lot. +1
>>
>> It seems to me it's a far more useful idea than encoding and decoding by
>> overloading and could do both and more. It has a lot of potential to be
>> an
Josiah Carlson wrote:
> Ron Adam <[EMAIL PROTECTED]> wrote:
>> Josiah Carlson wrote:
> [snip]
>>> Again, the problem is ambiguity; what does bytes.recode(something) mean?
>>> Are we encoding _to_ something, or are we decoding _from_ something?
>> This
Josiah Carlson wrote:
> Ron Adam <[EMAIL PROTECTED]> wrote:
> Except that ambiguates it even further.
>
> Is encodings.tounicode() encoding, or decoding? According to everything
> you have said so far, it would be decoding. But if I am decoding binary
> data, why should
Bengt Richter wrote:
> On Sat, 18 Feb 2006 23:33:15 +0100, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> note what base64 really is for. It's essence is to create a _character_
> sequence
> which can succeed in being encoded as ascii. The concept of base64 going
> str->str
> is really a mental sho
Bengt Richter wrote:
> On Sat, 18 Feb 2006 09:59:38 +0100,
> =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <[EMAIL PROTECTED]> wrote:
> Thinking about bytes recently, it occurs to me that bytes are really not
> intrinsically
> numeric in nature. They don't necessarily represent uint8's. E.g., a bin
Jeremy Hylton wrote:
> On 2/21/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
>> I had to lookup top-post :-).
>>
>> On 2/21/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
>>> On Tue, 21 Feb 2006 08:02:08 -0500, "Jeremy Hylton" <[EMAIL PROTECTED]>
>>> wrote:
Jeremy
>>> Hey, only Guido is allowed
Greg Ewing wrote:
> Ron Adam wrote:
>
>> Storing byte information as 16 or 32 bits ints could take up a rather
>> lot of memory in some cases.
>
> I don't quite see the point here. Inside a bytes object,
> they would be stored 1 byte per byte. Nobody is suggestin
Terry Reedy wrote:
> "Greg Ewing" <[EMAIL PROTECTED]> wrote in message
>
>> Which is why I think that only *unicode* codings should be
>> available through the .encode and .decode interface. Or
>> alternatively there should be something more explicit like
>> .unicode_encode and .unicode_decode th
Stephen J. Turnbull wrote:
>>>>>> "Ron" == Ron Adam <[EMAIL PROTECTED]> writes:
>
> Ron> Terry Reedy wrote:
>
> >> I prefer the shorter names and using recode, for instance, for
> >> bytes to bytes.
>
> Ron>
u like detailed logical analysis, it might be of some interest even if
it's reviewing the obvious to those who already know.
(And hopefully I didn't make any really obvious errors myself.)
Stephen J. Turnbull wrote:
>>>>>> "Ron" == Ron Adam <[EMAIL PROTECT
Neil Schemenauer wrote:
> Michael Hoffman <[EMAIL PROTECTED]> wrote:
>> Am I the only one who finds the use of "self" on a classmethod to be
>> incredibly confusing? Can we please follow PEP 8 and use "cls"
>> instead?
>
> Sorry, using "self" was an oversight. It should be "cls", IMO.
>
> Neil
Neil Schemenauer wrote:
> Ron Adam <[EMAIL PROTECTED]> wrote:
>> Why was it decided that the unicode encoding argument should be ignored
>> if the first argument is a string? Wouldn't an exception be better
>> rather than give the impression it does something wh
Greg Ewing wrote:
> Stephen J. Turnbull wrote:
>> It's "what is the Python compiler/interpreter going
> > to think?" AFAICS, it's going to think that base64 is
> > a unicode codec.
>
> Only if it's designed that way, and I specifically
> think it shouldn't -- i.e. it should be an error
> to att
Terry Reedy wrote:
> "Almann T. Goo" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> On 2/26/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>>> Alternatively, 'global' could be redefined to mean
>>> what we're thinking of for 'outer'. Then there would
>>> be no change in keywordage.
>>
Alex Martelli wrote:
> On Feb 26, 2006, at 11:47 AM, Ron Adam wrote:
>...
>> How would you know you aren't in inadvertently masking a name in a
>> function you call?
>
> What does calling have to do with it? Nobody's proposing a move to
> (shudder) d
Alex Martelli wrote:
>> I'm -1 on adding the intermediate (outer) scopes to functions. I'd even
>> like to see closures gone completely, but there's probably a reason they
>> are there. What I like about functions is they are fast, clean up
>> behind themselves, and act *exactly* the same on cons
Nick Coghlan wrote:
> All the unicode codecs, on the other hand, use encode to get from characters
> to bytes and decode to get from bytes to characters.
>
> So if bytes objects *did* have an encode method, it should still result in a
> unicode object, just the same as a decode method does (beca
Greg Ewing wrote:
> Ron Adam wrote:
>
>> While playing around with the example bytes class I noticed code reads
>> much better when I use methods called tounicode and tostring.
>>
>> b64ustring = b.tounicode('base64')
>> b = bytes(b64ustring
Josiah Carlson wrote:
> Greg Ewing <[EMAIL PROTECTED]> wrote:
>>u = unicode(b)
>>u = unicode(b, 'utf8')
>>b = bytes['utf8'](u)
>>u = unicode['base64'](b) # encoding
>>b = bytes(u, 'base64') # decoding
>>u2 = unicode['piglatin'](u1) # encoding
>>u1 = unicode(u2, '
Greg Ewing wrote:
> Ron Adam wrote:
>
>> This uses syntax to determine the direction of encoding. It would be
>> easier and clearer to just require two arguments or a tuple.
>>
>> u = unicode(b, 'encode', 'base64')
>> b = byt
Greg Ewing wrote:
> Ron Adam wrote:
>
>> This would apply to codecs that
>> could return either bytes or strings, or strings or unicode, or bytes or
>> unicode.
>
> I'd need to see some concrete examples of such codecs
> before being convinced that they
Greg Ewing wrote:
> Baptiste Carvello wrote:
>
>> what about
>>
>> except with :
>>
>> a program dies "with" an error message, not "as" an error message.
>
> No. The exception object you're catching *is* the value,
> not something which *has* a value. I maintain that "as"
> is the correct w
[EMAIL PROTECTED] wrote:
> Skip> There seem to be other places where Python is beginning to require
> Skip> parens even though they aren't strictly necessary to resolve
> Skip> syntactic ambiguity.
>
> Guido> In the style guide only, I hope.
>
> Alex> Technically, I believe th
Fredrik Lundh wrote:
> Guido van Rossum wrote:
>
> >> just map
>>> switch EXPR:
>>> case E1:
>>> ...
>>> case in E2:
>>> ...
>>> else:
>>> ...
>>>
>>> to
>>>
>>> VAR = EXPR
>>> if VAR == E1:
>>> ...
>>> elif VAR in E2:
>>>
Raymond Hettinger wrote:
>>From what I can see, almost everyone wants a switch statement, though perhaps
> for different reasons.
>
> The main points of contention are 1) a non-ambiguous syntax for assigning
> multiple cases to a single block of code, 2) how to compile variables as
> constants
> Given that variant, my reasons for preferring Option 2 over Option 3 are:
> - the semantics are the same at module, class and function level
> - the order of execution roughly matches the order of the source code
> - it does not cause any surprises when switches are inside conditional logic
Guido van Rossum wrote:
> On 6/27/06, Ron Adam <[EMAIL PROTECTED]> wrote:
>> I use dict base dispatching in a number of my programs and like it with
>> the exception I need to first define all the code in functions (or use
>> lambda) even if they are only one line. So
Guido van Rossum wrote:
>> What was intended probably would be more closely related to constructing
>> a switch with BASICS gosub command.
>
> I understand now.
>
> But I have a question: if I write
>
> for i in range(10):
>switch S:
> case i: print 42
>
> (i.e. the switch is *inside
Ron Adam wrote:
> In this instance the switch would be redefined 10 times. The ending
> switch would be:
>
> switch S:
>case 10: print 42
Silly mistake correction... :)
switch S:
case 9: print 42
___
> I believe at least one poster has pointed out that 'once' (if defined
> suitably) could be used as a better way to do this:
>
> def index_functions(n):
> return [(lambda: once i) for i in range(n)]
>
> But delaying the evaluation of the once argument until the function is
> called would b
Christos Georgiou wrote:
> 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:
>
>
Nick Coghlan wrote:
> Donovan Baarda wrote:
>
>>As I see it, a lambda is an anonymous function. An anonymous function is
>>a function without a name.
>
>
> And here we see why I'm such a fan of the term 'deferred expression'
> instead of 'anonymous function'.
>
> Python's lambda expressions *
Keith Dart wrote:
> On Mon, 20 Jun 2005, Keith Dart wrote:
>
>
>>But then I wouldn't know if it overflowed 32 bits. In my usage, the
>>integer will be translated to an unsigned (32 bit) integer in another
>>system (SNMP). I want to know if it will fit, and I want to know early if
>>there will be
Nick Coghlan wrote:
> Raymond Hettinger wrote:
>
>>Whatever term is selected, it should be well thought-out and added to
>>the glossary. The choice of words will likely have a great effect on
>>learnability and on how people think about the new tool.
I tried to bring this up on python-list, but
Raymond Hettinger wrote:
> On a separate note, I also propose that __exit__() be renamed to
> __leave__(). The enter/leave word pairing are a better fit in standard
> English:
I tend to associate leave with leaving, and leaving with arriving.
I didn't even think the __enter__ / __exit__ names w
Raymond Hettinger wrote:
> Hmm, that got me to thinking a bit more. Here's another subjective two
> cents worth. "exit" seems to be a more global concept and "leave" seems
> more local. For instance, I leave a room but exit a building. In
> Python, sys.exit and os._exit are grand exits rather
Nick Coghlan wrote:
> On the other hand 'enter and exit' rolls off the tongue
> significantly better than 'enter and leave'
My only concern is enter and exit may be too general. They are
frequently used in other places, although __enter__ and __exit__ are
less common, so maybe it's a non issue.
Raymond Hettinger wrote:
> There is no value in expanding a concept to the point of being
> meaningless (i.e. meaning whatever you want it to or nothing at all).
> Instead, we need a phrase that expresses the essence of the following:
>
>
> abc = EXPR
> exc = (None, None, None)
>
Guido van Rossum wrote:
> I even wonder if else-clauses on for/while were a good idea. (The one
> on try is definitely a good idea since the use case is quite frequent
> and only clumsily handled otherwise; the use cases for else on
> for/while are less convincing IMO.)
I'm +1 on removing the el
Michael Hudson wrote:
> Ron Adam <[EMAIL PROTECTED]> writes:
>
>
>>Guido van Rossum wrote:
>>
>>
>>>I even wonder if else-clauses on for/while were a good idea. (The one
>>>on try is definitely a good idea since the use case is quite frequent
&g
Thomas Lotze wrote:
> Ron Adam <[EMAIL PROTECTED]> wrote:
>>3. In a while loop, it's a value test, where the else block gets
>>executed if the while condition evaluates as false, the while block
>>may or may not execute. You still need a flag to test for
Michael Hudson wrote:
> "M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
>
>
>>This is exactly what I'm getting at: I can see the potential
>>use for resource management (which is what started out the
>>whole idea IIRC), but fail to see why you'd want to use it
>>for anything more complicated than tha
Guido van Rossum wrote:
> On 7/15/05, Ron Adam <[EMAIL PROTECTED]> wrote:
> [several new syntax proposals]
>
> Please stop proposing new syntax. The PEP was accepted after quite
> enough back-and-forth; there's no point opening this up yet again.
My apologie
Nick Coghlan wrote:
> Phillip J. Eby wrote:
>
>>+1. The main things that need fixing, IMO, are the need for critical and
>>control flow exceptions to be distinguished from "normal" errors. The rest
>>is mostly too abstract for me to care about in 2.x.
>
>
> I guess, before we figure out "whe
Raymond Hettinger wrote:
> Hey guys, don't give up your bare except clauses so easily.
Yes, Don't give up. I often write code starting with a bare except,
then after it works, stick a raise in it to determine exactly what
exception I'm catching. Then use that to rewrite a more explicit except
Raymond Hettinger wrote:
>>Deprecation means your code will still work I hope every book that
>>documents "except:" also adds "but don't use this except under very
>>special circumstances".
>>
>>I think you're overreacting (again), Raymond. 3.0 will be much more
>>successful if we can introduce man
Raymond Hettinger wrote:
> Looking at sample code transformations shows that the high-power
> mxTextTools and re approaches do not simplify code that currently uses
> s.find(). In contrast, the proposed partition() method is a joy to use
> and has no surprises. The following code transformation
Raymond Hettinger wrote:
> [Delaney, Timothy (Tim)]
>
>>+1
>>
>>This is very useful behaviour IMO.
>
>
> Thanks. It seems to be getting +1s all around.
Wow, a lot of approvals! :)
>>Have the precise return values of partition() been defined?
+1 on the Name partition, I considered split or
Phillip J. Eby wrote:
> At 02:25 PM 8/30/2005 -0400, Raymond Hettinger wrote:
>
>> That case should be handled with consecutive partitions:
>>
>> # keep everything after the second 'X'
>> head, found, s = s.partition('X')
>> head, found, s = s.partition('x')
I was thinking of cases where head is
Benji York wrote:
> Raymond Hettinger wrote:
>
>>[Fredrik Lundh]
>>
>>
>>>it is, however, a bit worrying that you end up ignoring one or more
>>>of the values in about 50% of your examples...
>>
>>It drops to about 25% when you skip the ones that don't care about the
>>found/not-found field:
>>
>
Fredrik Lundh wrote:
> Ron Adam wrote:
>
>
>>For cases where single values are desired, attribues could work.
>>
>>Slicing:
>> line = line.partition(';').head
>> line = line.partition('#').head
>>
>>But i
Nick Coghlan wrote:
> Ron Adam wrote:
>
>>I don't feel there is a need to avoid numbers entirely. In this case I
>>think it's the better way to find the n'th seperator and since it's an
>>optional value I feel it doesn't add a lot of
Reinhold Birkenfeld wrote:
> Greg Ewing wrote:
>
>>Charles Cazabon wrote:
>>
>>
>>>Perhaps py3k could have a py2compat module. Importing it could have the
>>>effect of (for instance) putting compile, id, and intern into the global
>>>namespace, making print an alias for writeln,
>>
>>There's no w
Jim Jewett wrote:
>
>>Another real problem with print is that, while the
>>automatic insertion of spaces is nice for beginners,
>>it often gets in the way, and what you have to do to
>>avoid this is pretty nasty: either drop print altogether
>>in favor of sys.stdout.write(), or use string concate
Paul Moore wrote:
> On 9/2/05, Ron Adam <[EMAIL PROTECTED]> wrote:
>
>>Jim Jewett wrote:
>>
>>>Putting the spaces back in (without a format string) would
>>>be even worse. Charles Cazabon's pointed out that it *could*
>>>be as simple
Nick Coghlan wrote:
> All,
>
> I put up a Wiki page for the idea of replacing the print statement with an
> easier to use builtin:
>
> http://wiki.python.org/moin/PrintAsFunction
>
> Cheers,
> Nick.
Looks like a good start, much better than just expressing opinions. :-)
How about making it a
Raymond Hettinger wrote:
> [Barry]
>
>>Actually, we probably only /need/ printf(), and certainly for C
>>programmers (are there any of us left? ;), I think that would be a
>
> small
>
>>conceptual leap. The motivation for keeping a non-formatting version
>
> is
>
>>for simple cases, and begin
Fred L. Drake, Jr. wrote:
> It would be good to have more specific guidelines for documentation.
Would it be possible to have each item in the documentation start out by
auto quoting that items __doc__ string?
Then omissions, errors, and contradictions would be easy to find and the
full docume
Raymond Hettinger wrote:
> I propose that in Py3.0, the "and" and "or" operators be simplified to
> always return a Boolean value instead of returning the last evaluated
> argument.
>
> 1) The construct can be error-prone. When an error occurs it can be
> invisible to the person who wrote it. I
Fredrik Lundh wrote:
> Michael Hudson wrote:
>
>
>>>While you're at it, maybe we should switch to && and || as well?
>>>That's another thing I always mistype when switching between
>>>languages...
>>
>>You're joking, surely?
>
>
> for Python 3000, I'd recommend switching to "and then" and "or e
Nick Coghlan wrote:
> Greg Ewing wrote:
>>One nice thing about "x if b else y" is that it
>>chains without needing any more keywords:
>>
>> x if b else y if c else z
>>
>>But if you require parens, it's not so nice:
>>
>> (x if b else (y if c else z))
> If Guido chose this form, I would expec
Steven Bethard wrote:
> Please no more syntax proposals! There were enough in the PEP. It
> looks like most people support a conditional expression of some sort.
> We need to leave the syntax to Guido. We've already proved that like
> the decorators discussions, we can't as a community agree o
Greg Ewing wrote:
> Ron Adam wrote:
>
>
>>(a if e then b)
>>((a1 if e1 then b1) if e then b)
>>(a if e then (a2 if e2 then b2))
>>((a1 if e1 then b1) if e then (a2 if e2 then b2))
>
>
> I think you mean 'else' rather than 'then' in
Antoine Pitrou wrote:
>>The only problem is that it's not easy to come up with a regex-based
>>way to transform
>>
>>C and X or Y
>>
>>into
>>
>>X if C else Y
One way is to parse it manually to a list. This was just a test, but
more samples can be added friarly easy.
samples = [
#
Delaney, Timothy (Tim) wrote:
> Paul Du Bois wrote:
>
>
>>On 10/10/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>
>>> cmd, *args = input.split()
>>
>>These examples also have a reasonable implementation using list.pop(),
>>albeit one that requires more typing. On the plus side, it does not
>>v
Reinhold Birkenfeld wrote:
> Greg Ewing wrote:
>
>>Guido van Rossum wrote:
>>
>>
>>>BTW, what should
>>>
>>>[a, b, *rest] = (1, 2, 3, 4, 5)
>>>
>>>do? Should it set rest to (3, 4, 5) or to [3, 4, 5]?
>>
>>Whatever type is chosen, it should be the same type, always.
>>The rhs could be any itera
Nick Coghlan wrote:
> Ron Adam wrote:
>
>>I wonder if something like the following would fulfill the need?
>
>
> Funny you should say that. . .
>
> A pre-PEP propsing itertools.iunpack (amongst other things):
> http://mail.python.org/pipermail/python-dev/2004-Nov
err relative to the
accepted value.
Absolute error
Relative error = -- x 100%
Accepted value
"""
def isclose(observed, accepted, abs_err, rel_err):
"""Determine if the accuracy of a observed value is
201 - 280 of 280 matches
Mail list logo
