> Raymond Hettinger wrote:
> > Use copy.copy() for generic copying -- it works across a wide range
of
> > objects. Alternatively, use the constructor as generic way to make
> > duplicates:
> >
> >dup = set(s)
> >dup = list(l)
> >dup =
> http://www.python.org/peps/pep-0327.html#rounding-algorithms
>
> I'll point to there from the Money PEP, but I think this should be
> somewhere in the docs. I mean, as a final user, you shouldn't read a
> PEP or a 3rd party doc to know how to use a module.
I've got it from here. Will update th
[Brett Cannon]
> I say we steal from the C++ and the RAII paradigm and go with RMUW
> (Resource Management Using 'with'
Or the-keyword-formerly-known-as-do
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
[Facundo]
> The pre-PEP is almost done, and the corresponding
> test cases are all written.
What is the part about the pre-PEP? Something like this probably
shouldn't go in the standard library until it has been proven in the
field. This doubly true for a module that has made some unusual OO
des
[Raymond]
> >>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.
[Ron Adam]
> I tried to bring this up on python-list, but I didn't get much of
> I would use "She left the ballpark." for someone walking into the
> dugout, climbing up into the stands, or walking out of the stadium,
> and might refer to the entire process. Using "She exited the
ballpark."
> to me suggests the exact moment that she went through the door
> dividing outside fro
[Michael Walter]
> How about simply "with block" or "guarded scope" or something like
that?
How would you use that to describe decimal.Context() objects after Nick
adds the __enter__ and __exit__ magic methods? We want something as
direct as, "xrange objects are iterable".
Raymond
_
[Ron Adam]
> The terms __begin__ and __end__, are nearly as general, but they
stress
> better that there are three parts, a beginning, middle and ending.
-1 Those are too generic to communicate anything. You would be better
off using beginwith and endwith or somesuch.
Raymond
_
> > There may be cases where the object being managed is not a resource
> > per-se, but that doesn't mean that the mechanism is misnamed as a
> > 'resource manager'; it's just the most common use case that any of
us
> > have managed to think of (as of yet).
[Michael Hudson]
> This is possible. I
> "Guarding a scope with a decimal.Context() object ."
Doesn't "guard" suggestion conditional execution?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
leave pair.
Raymond
> -Original Message-
> From: Michael Walter [mailto:[EMAIL PROTECTED]
> Sent: Sunday, July 03, 2005 10:28 PM
> To: Raymond Hettinger
> Cc: [EMAIL PROTECTED]; python-dev@python.org
> Subject: Re: [Python-Dev] Terminology for PEP 343
>
> Hmm
> > The mechanism is more general than resource
> >management. Like decorators, the encapsulation of a try/finally
wrapper
> >is completely generic and not married to the resource management
> >context.
[Phillip]
> Expand your mind. :) "Resource" can include whatever objects you want
it
> to --
[Aahz]
> How about "decimal.Context() objects are managed resources" or
"...have
> guarded scopes"? (I'm not terribly wild about either, but they are
> fairly simple and direct.)
See my other posts which bag on both "managed resources" and "guarded".
The part about scopes is less clear -- there i
> Alas, a typical exchange. The checkins are mailed from the committer's
> Sf email address, but the mailing list has been set up to redirect all
> replies to python-dev -- if you don't catch this before sending, you
> may be embarrassed in public or confuse the addressee.
>
> Is this behavior of
[Phillip J. Eby]
>
> with context_expression as variable:
> # perform actions within a context
>
> The "with" statement establishes a context in which some operations
are to
> be performed. Often, this is a resource management context, wherein
some
> resource is allocated when the context is
> I wish to request that 'gregorykjohnson' be added to the Python SF
> project.
I'll enable the permissions tonight.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mai
[Thomas Lotze]
> > I want to ask what you think about introducing a keyword 'eltry'
> > which would be the counterpart of 'elif' for try statements. This
> > had been suggested before on python-list a couple of years ago by
> > Jonathan Gardner, but nothing (that I could find) seems to have come
[Nick Coghlan]
> OK, here's some draft documentation using Phillip's context
> terminology. I think it works very well.
>
> """
> With Statements and Context Management
>
> A frequent need in programming is to ensure a particular action is
> taken after a specific section of code has been execute
> In order to lower the barrier for reporting bugs, writing patches, and
> handling CVS commits, I am writing up checklists for each and I will
> put them up on python.org.
-0 on the checklists. I don't think existing "barriers" are high at
all. The entries may be variously regarded as codifying
> > I compiled a list of some possible new context managers that could
be
> > added to the stdlib. Introducing a new feature should IMO also show
> > usage of it in the distribution itself. That wasn't done with
> > decorators (a decorators module is compiled at the moment, if I'm
> right),
> > but
> raymond> Log Message:
> raymond> Brett requests that Flovis's permissions be dropped.
[Skip]
> Not to put too fine a spin on things, but I think it was more like
Brett
> got
> tired of waiting for Flovis's permissions to be increased and
retracted
> his
> original request.
Brett and Fl
{MAL]
> 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 that.
Substitute "different" for "complicated".
'with' is not applica
> Note zlib 1.2.3 is just out -- the zlib compression/decompression
. . .
> I'd guess this belongs in 2.5, with a possible retrofit for 2.4.
+1 on backporting, but that is up to Anthony.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http
y well with this approach (many methods accept any iterable).
The only inefficiencies that arise are with fine grained methods like
__contains__() and add(); even then, it is no less efficient than pure
Python.
Raymond Hettinger
___
Python-Dev mailin
[François Pinard]
> While some say Subversion is the most reasonable avenue nowadays,
others
> them told me they found something more appealing than Subversion:
>
>http://www.venge.net/monotone/
The current release is 0.21 which suggests that it is not ready for
primetime.
Raymond
The Py3.0 PEPs are a bit disconcerting. Without 3.0 actively in
development, it is difficult to get the participation, interest, and
seriousness of thought that we apply to the current release. The PEPs
may have the effect of prematurely finalizing discussions on something
that still has an ether
> The problem with Raisable
> is that it doesn't contain the word exception; perhaps we can call it
> BaseException?
+1
> A refinement might be to introduce something called Error, which would
> change the last part of the avove hierarchy as follows:
. . .
> This has a nice symmetry between E
Could someone please make an independent check to verify an issue with
the 342 checkin. The test suite passes but when I run IDLE and open a
new window (using Control-N), it crashes and burns.
The problem does not occur just before the checkin:
cvs up -D "2005-08-01 18:00"
But emerges immedia
[ Guido]
> One more thing. Is renaming NameError to NamespaceError really worth
> it? I'd say that NameError is just as clear.
+1 on NameError -- it's clear, easy to type, isn't a gratuitous change,
and doesn't make you think twice about NamespaceError vs NameSpaceError.
Raymond
___
Also strong -1 on renaming RuntimeWarning to SemanticsWarning.
Besides being another unnecessary change (trying to solve a non-existent
problem), this isn't an improvement. The phrase RuntimeWarning is
sufficiently generic to allow it to be used for a number of purposes.
In costrast, SemanticsWar
The PEP moves StopIteration out from under Exception so that it cannot
be caught by a bare except or an explicit "except Exception".
IMO, this is a mistake. In either form, a programmer is stating that
they want to catch and handle just about anything. There is a
reasonable argument that SystemE
> > When a user creates their own exception for exiting multiple levels
of
> > loops or frames, should they inherit from ControlFlowException on
the
> > theory that it no different in intent from StopIteration or should
they
> > inherit from UserError on the theory that it is a custom exception?
>
[Raymond Hettinger wrote]
> >The PEP moves StopIteration out from under Exception so that it
cannot
> >be caught by a bare except or an explicit "except Exception".
> >
> >IMO, this is a mistake. In either form, a programmer is stating that
> >they want
> > > > >+-- NamespaceError (rename of NameError)
> > > > >+-- UnboundFreeError (new)
> > > > >+-- UnboundGlobalError (new)
> > > > >+-- UnboundLocalError
> > > > >
> > > >
> > > > What are these new exceptions for? Under what circumstances are
they
> > >
[Nick Coghlan]
> As others have pointed out, GeneratorExit and StopIteration should
never
> reach
> the job execution loop - if they do, there's a bug in the job, and
they
> should
> be caught and logged.
Please read my other, detailed post on this (8/5/2005 4:05pm). It is a
mistake to bypass con
> PEP 8 doesn't express any preference between the
> two forms of raise statements:
> raise ValueError, 'blah'
> raise ValueError("blah")
>
> I like the second form better, because if the exception arguments are
> long or include string formatting, you don't need to use line
> continuation charact
> The remainder of my message then goes on to describe a hierarchy just
as
> you
> suggest - SystemError, MemoryError, StopIteration and GeneratorExit
are
> all
> still caught by "except Exception:". The only two exceptions which are
no
> longer caught by "except Exception:" are KeyboardInterrupt a
VMError -- This is a new intermediate grouping so it won't break
anything and it does bring together two exceptions relating them by
source. However, I recommend against introducing this new group.
Besides added yet another thing to remember, it violates
Flat-Is-Better-Than-Nested (see FIBTN below
> > How do you then supply a traceback to the raise statement?
>
> raise ValueError, ValueError("blah"), tb
>
> Maybe in Py3K this could become
>
> raise ValueError("bloop"), tb
The instantiation and bindings need to be done in one step without
mixing two syntaxes. Treat this case the same as
> According to the source code, PyTuple_Pack returns a new reference (it
> calls PyTuple_New). It also Py_INCREF's all the objects in the new
> tuple. Is this unusual behavior?
No. That is how containers work. Look at PyBuild_Value() for
comparison.
> None of these added references are doc
[Brett Cannon]
> At this point the only
> changes to the hierarchy are the addition of BaseException and
> TerminatingException, and the change of inheritnace for
> KeyboardInterrupt, SystemExit, and NotImplementedError.
TerminatingException
The rationale for adding Termi
[Brett]
> The problem with existing code checking for this situation is that the
> situation itself is not the same as it will be if bare 'except's
> change::
>
> try:
>...
> except:
>...
> except TerminatingException:
>...
>
> has never really been possible before, but will be if
> > WindowsError
> >
> >
> > This should be kept. Unlike module specific exceptions, this
exception
> > occurs in multiple places and diverse applications. It is
appropriate
> > to list as a builtin.
> >
> > "Too O/S specific" is not a reason for eliminating this. Looking at
the
> >
> > Then I don't follow what you mean by "moved under os".
>
> In other words, to get the exception, do ``from os import
> WindowsError``. Unfortunately we don't have a generic win module to
> put it under. Maybe in the platform module instead?
-1 on either. The WindowsError exception needs to
[Brett]
> I can compromise to this if others prefer this alternative. Anybody
> else have an opinion?
We're not opinion shopping -- we're looking for analysis. Py3.0 is not
supposed to just a Python variant -- it is supposed to be better. It is
not about making compromises -- it is about only m
> There
> is a reason you listed writing a PEP on your own on the "School of
> Hard Knocks" list; it isn't easy. I am trying my best here.
Hang in there. Do what you can to make sure we get a result we can live
with.
-- R
___
Python-Dev mailing lis
[Jim Jewett]
> (1) Is there a reason that you never shrink sets for
discard/remove/pop?
Yes, to avoid adding an O(n) step to what would otherwise be an O(1)
operation. These tight, granular methods are so fast that even checking
for potential resizes would impact their performance.
Also, I was
[James Y Knight]
> Huh, I could *swear* we were talking about fixing things for
> 2.5...but I see at least the current version of the PEP says it's
> talking about 3.0. If that's true, this is hardly worth discussing as
> 3.0 is never going to happen anyways.
>
> And here I was hoping this was an
[Paolino]
> I can't contact sourceforge bug tracker sorry.
I've added a bug report for you:
www.python.org/sf/1257731
> set.remove is trying to freeze sets when they are used as keys.No
matter
> if an __hash__ method is defined.
Will fix. Feel free to email me off-list with any questions.
[Josiah]
> At this point, I'd be happy to get
> /any/ mechanism, with a preference to struct and/or binascii
Assign 1023290 to me and I'll get it done in the next month or so.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
The object and types
PySetObject subclass of object
used for both sets and frozensets
PySet_Type a basetype
PyFrozenSet_Typea basetype
The type check macros
-
PyFrozenS
[Brett]
> This obviously goes against what Guido last said he
> wanted, but I hope I can convince him to get rid of bare 'except's.
-1 on eliminating bare excepts. This unnecessarily breaks tons of code
without offering ANY compensating benefits. There are valid use cases
for this construct. It
> > It is completely Pythonic to have bare keywords
> > apply a useful default as an aid to readability and ease of coding.
[Oleg]
>Bare "while:" was rejected because of "while WHAT?!". Bare
"except:"
> does not cause "except WHAT?!" reaction. Isn't it funny?! (-:
It's both funny and interest
[Bryan O'Sullivan]
> > The centralised SCM tools all create a wall between core developers
> > (i.e. people with commit access to the central repository) and
people
> > who are on the fringes. Outsiders may be able to get anonymous
> > read-only access, but they are left up to their own devices i
[Tim]
> +1 from me. But, I don't think my vote should count much, and (sorry)
> Guido's even less: what do the people who frequently check in want?
> That means people like you (Martin), Michael, Raymond, Walter, Fred.
> ... plus the release manager(s).
+1 from me. CVS is meeting my needs but I
[Michael Hudson]
> I wonder if dir() should strip non-strings?
-0 The behavior of dir() already a bit magical. Python is much simpler
to comprehend if we have direct relationships like dir() and vars()
corresponding as closely as possible to the object's dictionary. If
someone injects non-strin
[Christian Robottom Reis]
> I've done some searching through my code and id() isn't the most-used
> builtin, so from my perspective the impact would be limited, but of
> course others might think otherwise.
>
> Is it worth writing a PEP for this, or is it crack?
FWIW, I use id() all the time and
[Timothy Fitz]
> It seems to
> me that those who want dir to reflect __dict__ should just use
> __dict__ in the first place.
The dir() builtin does quite a bit more than obj.__dict__.keys().
>>> class A(list):
x = 1
>>> dir(A)
['__add__', '__class__', '__contains__', '__delattr__', '__d
> > [Timothy Fitz]
> > > It seems to
> > > me that those who want dir to reflect __dict__ should just use
> > > __dict__ in the first place.
>
> [Raymond]
> > The dir() builtin does quite a bit more than obj.__dict__.keys().
>
> Well that's the whole point, right?
Perhaps. I wasn't taking a po
[Ian Bicking]
> I think partial() misses an important use case of method getting, for
> instance:
>
> lst = ['A', 'b', 'C']
> lst.sort(key=partialmethod('lower'))
We've already got one:
lst.sort(key=operator.attrgetter('lower'))
Raymond
___
> > [Ian Bicking]
> > > I think partial() misses an important use case of method getting,
for
> > > instance:
> > >
> > > lst = ['A', 'b', 'C']
> > > lst.sort(key=partialmethod('lower'))
> >
> > We've already got one:
> >
> >lst.sort(key=operator.attrgetter('lower'))
>
> Doesn't
[Guido]
> They feel related to attrgetter more than to partial.
That suggests operator.methodcall()
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
[Steven Bethard]
> > I agree that an operator.methodcaller() shouldn't try to support
> > multiple methods. OTOH, the syntax
> > methodcall.method(*args, **kwargs)
> > doesn't really lend itself to multiple methods either.
[Josiah Carlson]
> But that's OK, we don't want to be calling multiple
> A new hashlib module to replace the md5 and sha modules. It adds
> support for additional secure hashes such as SHA-256 and SHA-512. The
> hashlib module uses OpenSSL for fast platform optimized
> implementations of algorithms when available. The old md5 and sha
> modules still exist as wrappe
This patch should be reverted or fixed so that the Py2.5 build works
again.
It contains a disasterous search and replace error that prevents it from
compiling. Hence, it couldn't have passed the test suite before being
checked in.
Also, all of the project and config files need to be updated fo
[Raymond Hettinger]
>
> > Could someone please make an independent check to verify an issue
with
> > the 342 checkin. The test suite passes but when I run IDLE and open
a
> > new window (using Control-N), it crashes and burns.
> >
> > The problem does
[Raymond Hettinger]
> > This patch should be reverted or fixed so that the Py2.5 build works
> > again.
> >
> > It contains a disasterous search and replace error that prevents it
from
> > compiling. Hence, it couldn't have passed the test suite before
bei
[Gareth]
> > It's valid C99, meaning "this is an unsigned long long".
> since when does Python require C99 compilers?
Except from PEP 7:
"Use ANSI/ISO standard C (the 1989 version of the standard)."
___
Python-Dev mailing list
Python-Dev@python.or
[Michael Hudson]
> It's an C99 unsigned long long literal, AFAICT (p70 of the PDF I found
> lying around somewhere...), so I think it's just Bill who's behind.
> However, Python doesn't require C99, so it's pretty dodgy code by our
> standards.
More than just dodgy.
Except from PEP 7:
"Use AN
[Gregory P. Smith]
> I don't have a win32 dev environment at the moment so i didn't see
> that. Sorry.
No big deal.
But we still have to get the code back to ANSI compliance.
Do you have an ANSI-strict option with your compiler?
Raymond
___
Python-D
[Gregory P. Smith]
> I just checked in an update removing all of the ULLs. Could you check
> that it compiles on windows and passes test_hashlib.py now?
Okay, all is well.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
The latest version of PEP 348 still proposes that a bare except clause
will default to Exception instead of BaseException. Initially, I had
thought that might be a good idea but now think it is doomed and needs
to be removed from the PEP.
A bare except belongs at the end of a try suite, not in th
[Guido van Rossum]
> If we syntactically enforce that the bare except, if present, must be
> last, would that remove your objection? I agree that a bare except in
> the middle is an anomaly, but that doesn't mean we can't keep bare
> except: as a shorthand for except Exception:.
Hmm. Prohibiting
Hey guys, don't give up your bare except clauses so easily.
They are useful. And, if given the natural meaning of "catch
everything" and put in a natural position at the end of a suite, their
meaning is plain and obvious. Remember beauty counts. I don't think
there would be similar temptation t
[Guido van Rossum]
> > OK, I'm convinced. Let's drop bare except for Python 3.0, and
> > deprecate them until then, without changing the meaning.
> >
> > The deprecation message (to be generated by the compiler!) should
> > steer people in the direction of specifying one particular exception
> > (e
> > Hmm, that may not be a killer. I wonder if it is possible to treat
> > BaseException as a constant (like we do with None) and teach the
> > compiler to interpret it as catching anything that gets raised so
that
> > "except BaseException" will work like a bare except clause does now.
>
> Sorry
> > OK, I'm convinced. Let's drop bare except for Python 3.0, and
> > deprecate them until then, without changing the meaning.
> >
>
> Woohoo
That's no cause for celebration. Efforts to improve Py3.0 have spilled
over into breaking Py2.x code with no compensating benefits. Bare
except clauses a
> > Efforts to improve Py3.0 have spilled
> > over into breaking Py2.x code with no compensating benefits. [...]
> > We don't have to wreck 2.x in order to make 3.0 better.
>
> I think you're overstating things a bit here.
It's only an overstatement if Guido didn't mean what he said. If bare
exc
> 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 many of its features into 2.
> > Also, as we learned with apply(), even if
> > ignored, the deprecation machinery has a tremendous runtime cost.
None
> > of this will make upgrading to Py2.5 an attractive option.
>
> Not in this case; bare except: can be flagged by the parser so the
> warning happens only once per compilatio
> Can str.find be listed in PEP 3000 (under builtins) for removal?
FWIW, here is a sample code transformation (extracted from zipfile.py).
Judge for yourself whether the index version is better:
Existing code:
--
END_BLOCK = min(filesize, 1024 * 4)
fpin.seek(filesize - END_B
> Can str.find be listed in PEP 3000 (under builtins) for removal?
> Would anyone really object?
>
> Reasons:
. . .
I had one further thought. In addition to your excellent list of
reasons, it would be great if these kind of requests were accompanied by
a patch that removed the offending cons
> > The most important reason for the patch is that looking at the
context
> > diff will provide an objective look at how real code will look
before
> > and after the change. This would make subsequent discussions
> > substantially more informed and less anecdotal.
>
> No, you're just artificiall
[Martin]
> For another example, file.read() returns an empty string at EOF.
When my turn comes for making 3.0 proposals, I'm going to recommend
nixing the "empty string at EOF" API. That is a carry-over from C that
made some sense before there were iterators. Now, we have the option of
introduci
FWIW, here are three more comparative code fragments. They are
presented without judgment as an evaluation tool to let everyone form
their own opinion about the merits of each:
--- From CGIHTTPServer.py ---
def run_cgi(self):
"""Execute a CGI script."""
dir, rest = self.cgi_
> For reading bytes, I *know* that a lot of code would become uglier if
> the API changed to raise EOFError exceptions
I had StopIteration in mind. Instead of writing:
while 1:
block = f.read(20)
if line == '':
break
. . .
We would use:
for block in
[Guido]
> However, after 12 years, I believe that the small benefit of having
> find() is outweighed by the frequent occurrence of bugs in its use.
My little code transformation exercise is bearing that out. Two of the
first four cases in the standard library were buggy :-(
Raymond
___
[Tim]
> You probably want "except ValueError:" in all these, not "except
> ValueError():".
Right. I was misremembering the new edict to write:
raise ValueError()
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
[Guido]
> Another observation: despite the derogatory remarks about regular
> expressions, they have one thing going for them: they provide a higher
> level of abstraction for string parsing, which this is all about.
> (They are higher level in that you don't have to be counting
> characters, which
[Marc-Andre Lemburg]
> I may be missing something, but why invent yet another parsing
> method - we already have the re module. I'd suggest to
> use it :-)
>
> If re is not fast enough or you want more control over the
> parsing process, you could also have a look at mxTextTools:
>
> http://w
> > I'm not convinced. Where would you ever care about reading a file in
> > N-bytes chucks?
>
> This was once a standard paradigm for IBM mainframe files. I vaguely
> remember having to specify the block/record size when opening such
files.
> I have no idea of today's practice though.
I believe
[M.-A. Lemburg]
> Also, as I understand Terry's request, .find() should be removed
> in favor of just leaving .index() (which is the identical method
> without the funny -1 return code logic).
>
> So your proposal really doesn't have all that much to do
> with Terry's request, but is a new and sep
As promised, here is a full set of real-world comparative code
transformations using str.partition(). The patch isn't intended to be
applied; rather, it is here to test/demonstrate whether the new
construct offers benefits under a variety of use cases.
Overall, I found that partition() usefully e
[Delaney, Timothy (Tim)]
> +1
>
> This is very useful behaviour IMO.
Thanks. It seems to be getting +1s all around.
> Have the precise return values of partition() been defined?
. . .
> IMO the most useful (and intuitive) behaviour is to return strings in
> all cases.
Yes, there is a precis
Hey guys, don't get lost in random naming suggestions (cut, snap, part,
parts, yada yada yada). Each of those is much less descriptive and
provides less differentiation from other string methods. Saving a few
characters is not worth introducing ambiguity.
Also, the longer name provides a useful
[Tim]
> Anyone remember why setdefault's second argument is optional?
IIRC, this is a vestige from its ancestor. The proposal for
setdefault() described it as behaving like dict.get() but inserting the
key if not found.
> Haven't found
> any 1-arg uses of setdefault() either, except for test c
[Ron Adam]
> This would allow creating an iterator that could iterate though a
string
> splitting on each sep from either the left, or right.
For uses more complex than basic partitioning, people should shift to
more powerful tools like re.finditer(), re.findall(), and re.split().
> I can't thi
[Hye-Shik Chang]
> What would be a result for rpartition(s, '?') ?
> ('', '', 'http://www.python.org')
> or
> ('http://www.python.org', '', '')
The former. The invariants for rpartition() are a mirror image of those
for partition().
> BTW, I wrote a somewhat preliminary patch for this functi
[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:
> > ! _, sep, port = host.partition(':')
> > ! hea
> > While I'm at it, why not propose that for py3k that
> > .rfind/.rindex/.rjust/.rsplit disappear, and
.find/.index/.just/.split
> grow an
> > optional "fromright" (or equivalent) optional keyword argument?
>
> This violates one of my design principles: don't add boolean options
> to an API that
1301 - 1400 of 1487 matches
Mail list logo
