out well too, then there would be some basis for
Py3.0 using decimal as the default float.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opti
--> update
> I'm willing to Just Fix It,
Please don't. All of the differences between set and Set were
intentional improvements (i.e. the hash algorithm's are different).
Raymond
___
Python-Dev mailing list
Python-Dev@pyth
:
mylist[:] = [] # clear
Raymond
___
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
he glossary. The choice of words will likely have a great effect on
learnability and on how people think about the new tool.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
and still feels that way years later.
Raymond
___
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
> 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 =
got it from here. Will update the docs.
Raymond
___
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
[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.py
ksheet, row or column, or
specific cell. It is not linked to the context for mathematical
operations.
While the Money module remains experimental, it should remain a
third-party package.
Raymond
___
Python-Dev mailing list
Python-Dev@pyth
[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 pyth
just
> expressing an opinion. So take it for what it's worth.
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 buil
[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 obje
[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.
R
t).
[Michael Hudson]
> This is possible. I just wanted to expand everyone's minds :)
Stick by your guns. The mechanism is more general than resource
management. Like decorators, the encapsulation of a try/finally wrapper
is completely generic and not m
> "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/p
ning the guard" has a
specific meaning with the "guard" part being consistent with the above.
One example:
http://www.cs.utexas.edu/users/psp/unity/notes/07-89.pdf
IOW, guard is a specific term, not an amorphous metaphor that can be
accurately applied to the enter/exit or enter/
s that our two new keywords
are prepositions and the process that they apply to is somewhat
abstract.
Raymond
P.S. I would still like to encourage the adoption of __leave__ instead
of __exit__. The first suggests part of an enter/leave pair. The
latter could too easily be taken as a standalon
One is expected to be used with "as" and
the other is not. Neither of the above wordings begin to suggest
whether decimal.Context.__enter__ will return a useful value (the PEP
has examples of each).
Raymond
___
Python-Dev mailing list
Pyt
37, but you wouldn't know that from reading python-dev.
A few years ago, the cc to python-dev was not automatic and the default
reply address was the original committer. That worked much better.
Raymond
P.S. I still don't follow the whole yours/mine comment from Michael.
The off
ork well. It's certainly the first case where I've been able to
> easily explain what decimal.Context does (or will do) when used in a
> 'with' statement.
I think you're onto something. Stick with it. Your whole write-up is
clear. It is the first one that does
> 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-d
doesn't seem to be %s-encoded" % decoder.__name__
FWIW, the looping solution has worked out well in practice. From
csv.py:
for thisType in [int, long, float, complex]:
try:
thisType(row[col])
break
except (ValueError, OverflowError):
ls them. Remember, the methods will appear among a slew of other
methods that have nothing to do with with-statements. There will be no
surrounding contextual clue as to what these methods are for.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
htt
l reports that don't fit one or all of those criteria. I don't
want to unnecessarily raise the bar and not have someone report a
potentially valid bug.
IMO, the proposal is administrivia that doesn't add value and possibly
makes things worse (by causing some folks to not go through th
g the standard library to cast a particular solution in
stone.
This doesn't preclude individual patches such as a context manager for
decimal.Context objects. Each proposal should be considered on its own
merits rather than as a part of an overall effort to ram a bunch of
these in
> 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
> h
or "complicated".
'with' is not application specific, it is incredibly general. All it
does is abstract recurring uses of try/finally.
Naming it after a specific class of applications would be a mistake.
Raymond
___
Python-Dev maili
> 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
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
primetim
likelihood of either throwing away previous good
decisions or adopting new ideas that later prove unworkable. IOW,
unless the current tree is thought to be really bad, then the new tree
ought to be very close to what we have now.
Raymond
> -Original Message-
> From: [EMAIL PRO
specific application (i.e. a case could
be made that NotImplementedError is sometimes just a regular exception
that can be expected to arise and be handled in the normal course of
business). Unless we can point to real problems that people are having
today, then these kind of changes are likely unw
ut emerges immediately after:
cvs up -D "2005-08-01 21:00"
Raymond
___
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
[ 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
essarily better, and there is a high risk of
introducing new usability problems.
Raymond
___
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
n).
Be careful with these proposals. While well intentioned, they have
ramifications that aren't instantly apparent. Each one needs some deep
thought, user discussion, usability testing, and a darned good reason
for changing what we already hav
e versus another. A common and basic use case for
quick and dirty exceptions is to break out of nested loops and
functions. That is control flow as well as quick-and-dirty.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
[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
ated to bytecode). So UnboundFreeError is
> > > raised when the interpreter cannot find a variable that is a free
> > > variable. UnboundLocalError already exists. UnboundGlobalError
is to
> > > prevent NameError from being overloaded. UnboundFreeError is to
> >
truct. Your proposal breaks a major use case for it (preventing
your sales demos from crashing in front of your customers, writing
fault-tolerant programs, etc.)
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
would also choose the second form. But why
bother inflicting our preference on others, both forms are readable so
we won't gain anything by dictating a style.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
Exception:" are KeyboardInterrupt and
SystemExit.
Ah, I was too quick on the draw. It now appears that you were already
converted :-) Now, if only the PEP would get updated ...
BTW, why did you exclude MemoryError?
Raymond
___
Python-Dev m
etting your mind arbitrarily impose patterns on it.
Raymond
___
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
g two syntaxes. Treat this case the same as everything else:
raise ValueError("blip", traceback=tb)
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mai
> 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
ustrated at these reviews. Because there was no
research into existing code, working to solve known problems, evaluation
of alternatives, or usability analysis, it is no surprise Sturgeon's Law
would apply. Since Python has been around so long, it is also no
surprise that what we have now is p
will ever use. Try not to add a new
word whose only function is to replace a two-word tuple (TOOWTDI). Try
not to unnecessarily nest the tree (FITBN). Try not to propose
solutions to problems that don't exist (PBP).
Raymond
___
Python-Dev ma
e exception would be moved under
> os, so it would be more of a renaming than a removal.
Isn't OSError already used for another purpose (non-platform dependent
exceptions raised by the os module)?
Raymond
___
Python-Dev mailing list
Pyth
Mac errors and Linux
errors. Also, it wouldn't tie a language feature to the name of an MS
product.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.or
ins. It is
simply crummy design to take a multi-module, multi-application exception
and push it down into a module namespace.
+0 on renaming; +1 on leaving as-is.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
> 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
a goal to eliminate redundant calls
to PyObject_Hash(). The nice performance improvement was an unexpected
bonus.
Your questions are good. Thanks for reading the code and thinking about
it. Hope you enjoy the new implementation which for the first time can
outperform dicts in terms of both spa
had been kept only for backwards compatibility.
Raymond
___
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
with any questions.
Raymond
___
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
[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
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
tuple itself has been sufficiently obvious and explicit. This rationale
assumes that code readers aren't smart enough to infer that SystemExit
has something to do with termination.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
eaning clear:
try:
block()
except SpecificException:
se_handler()
except:
handle_everything_else()
The pattern of use is similar to a "default" in a switch-case construct.
Viewed out-of-context, one would ask "default WHAT&q
s only a small learning curve to cvs users. Optionally adding
svk to the mix allows us to get the benefits of a distributed system
without any
additional migration or support issues. Very nice.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
[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 i
shot based on the light conditions and camera
settings. IOW, if you make the tools too smart, they become harder to
use. Leica had it right all along.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
use id() all the time and like having it as a builtin.
Raymond
___
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
, '__hash__',
'__iadd__', '__imul__', '__init__', '__iter__', '__le__', '__len__',
'__lt__', '__module__', '__mul__', '__ne__', '__new__', '__reduce__',
'__reduc
> > [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'
[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:
> > We've already got one:
> >
> >lst.sort(key=operator.attrgetter('lower'))
>
> Doesn't that just sort on the str.lower or unicode.lower method
object?
My mistake. It sorts on the bound method rather than the results of
applying that me
[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
ith map(), if a new function doesn't fit neatly, take that as
a cue to be writing a plain for-loop.
Raymond
___
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
ompiler limit
: too many open parentheses
Also, there should be updating entries to Misc/NEWS,
PC/VC6/pythoncore.dsp, and PC/config.c.
Raymond
___
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
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
t dodgy.
Except from PEP 7:
"Use ANSI/ISO standard C (the 1989 version of the standard)."
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pytho
[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
__
[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.or
ng around the mental confusion caused a bare
except clause in the middle of a try-suite rather than at the end. We
have to avoid code that looks like it does one thing but actually does
something else.
Raymond
___
Python-Dev mailing list
Python-Dev@pyt
a
code review or inspection. I suspect it would. The code looks like
does one thing but actually does something else. This may or may not be
a big deal.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listin
t example makes you think twice about whether the
final case really does get everything (sometimes implicit IS better than
explicit).
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
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.
Raymond
___
like a bare except clause does now.
>
> Sorry Raymond, but my first reaction is "ick" :). That seems to be a
> big change in the semantics of exception matching. I think I'd rather
> keep bare except than add that!
That may be your only other option if we're waiting until 3
benefit from the whole PEP is that in 3.0, it will no
longer be necessary to write "except (KeyError, SystemExit): raise".
Steven and Jack's research show that that doesn't arise much in practice
anyway. IOW, there's nothing worth inflicting destruction on tons of
2.x
pt clauses weren't banned for 3.0, then we would
have no problem writing code that works on all versions on Python from
2.0 to 3.0, that doen't break existing code, and that doesn't invalidate
the text in Python books. IMO, that is a nice situation.
> 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
is to leave bare excepts in for Py3.0. That
buys us a happy world where code old code continues to work and new code
can be written that functions as intended on all pythons new and old.
I'm no fan of bare exceptions, but I'm not inclined to shoot myself in
the foot to be rid of them. I w
> 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
. Each provided a new insight (zipfile was not
improved, webbrowser was improved, and urlparse was about the same).
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://m
oposition. Why not use
the wealth of data at our fingertips to augment a priori reasoning and
anecdotes. I'm not at all arguing against the proposal; I'm just asking
for a thoughtful design process.
Raymond
P.S. Josiah was not alone. The comp.lang.python discussion had other
posts
have the option of
introducing much cleaner iterator versions of these methods that use
compact, fast, and readable for-loops instead of multi-statement
while-loop boilerplate.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.or
except ValueError():
pass
else:
if optval[pos-1].isspace():
optval = optval[:pos]
optval = optval.strip()
. . .
--- StringIO.py ---
i = self.buf.find('\n', self.pos)
if i < 0:
newpos = self.len
el
> 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 :-(
R
[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.
ting
> characters, which is about the lowest-level activity in programming --
> only counting bytes is lower!)
>
> Maybe if we had a *good* way of specifying string parsing we wouldn't
> be needing to call find() or index() so much at all! (A good example
> is the code that Raymo
IO.py, since the task at hand IS
calculating an index, an indexless higher level construct doesn't help.
However, many of the other s.find() use cases in the library simplify as
readily and directly as the above cgi server example.
Raymond
--
f today's practice though.
I believe this still comes up in 100% of the cases where you're
buffering reads of large binary files. Given lot of RAM, this probably
doesn't come up as much nowadays.
Raymond
___
Python-Dev mailing list
Python-D
1, in -toplevel-
rest, query = rest.rsplit('?', 1)
ValueError: need more than 1 value to unpack
The whole point of str.partition() is to repackage str.split() in a way
that is conducive to fulfilling many of the existing use cases for
str.find() and str.index().
In going throu
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
combined to the whole. IOW, it is exactly the right
word. I won't part with it easily.
http://www.google.com/search?q=quicksort+partition
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-d
enefit from the length
argument. I think you'll find that it comes up so infrequently and with
such differing needs that it would be a mistake to bake this into the
proposal.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
1301 - 1400 of 1495 matches
Mail list logo
