se looking for some places to apply the idea
and have come up empty handed. This could mean that I've not yet
grasped the essence of what makes the idea useful or it may have other
implications such as apps needing to be designed from the ground-up
[Raymond]
> > Likewise, is it correct that "yield" is anti-parallel to the current
> > meaning? Inside a generator, it returns control upwards to the
caller.
> > But inside a block-iterator, it pushes control downwards (?inwards)
to
> > the block it controls.
to me that the word "block"
already has meaning in the context of threading.Lock.acquire() which has
an optional blocking argument defaulting to 1.
In example 4, consider adding a comment that the "continue" has its
normal (non-extending) meaning.
The examples should demonstra
effect on timings. It's too early for that discussion, but
keep it in mind.
That's pretty much it for my first readings of the PEP. All-in-all it
has come together nicely.
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
exit__() didn't
> raise RuntimeError("or some other exception")
>
> I'd like the block statement to be defined exclusively in terms of
> __exit__() though.
That sounds like a winner.
Raymond
___
Python-Dev mailing
he cover announcement should impart the initial spin as a
request for the community to create, explore, and learn from use cases.
That will help make the discussion more constructive, less abstract, and
more grounded in reality (wishful thinking).
That probably beats, "Here's 3500 words of
ious right-thing-to-do will be
influenced by what happens with 340.
Everyone's bandwidth is being maxed-out at this stage. So it is
somewhat helpful to keep focused on the core proposal of generator
driven block/suite thingies.
Raymond
___
Python
not a good
idea. Putting tools in the standard library should be the last
evolutionary step, not the first.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.p
ing several ASPN
recipes and a wiki:
http://www.python.org/moin/PythonDecoratorLibrary
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
e improper, in the sense that they change the signature
of
> the function they decorate.
Signature changing and signature preserving are probably better
classifications than proper and improper. Even then, some decorators
like atexit() and classmethod() may war
g that it's not
> countering those items nor repeating them.
If someone volunteers to split it out for you, I think it would be
worthwhile. Right now, the PEP is hard to swallow in one bite.
Improving its digestibility would be a big help when the PEP is offered
up to the tender mercies to comp.l
func.func_defaults, func.func_closure)
>
> and I *hate* it!
Sounds reasonable.
Choices:
- submit a patch adding a __copy__ method to functions,
- submit a patch for the copy module, or
- submit a feature request, assign to me, and wait.
Raymond Hettinger
__
> -was, under the covers, a (optential) looping construct. This
> +was, under the covers, a (potential) looping construct. This
I'm glad I didn't fix this one.
I thought he meant to use "optional".
Raymond Hettinger
, alter, and then restore:
oldprec = decimal.getcontext().prec
decimal.getcontext().prec += 2
yield None
decimal.getcontext().prec = oldprec
Raymond Hettinger
___
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 original -- the
important change was the absolute save and restore versus the original
relative adjust up and adjust down.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
e whole
context and let the wrapped block only work with a copy.
oldcontext = decimal.getcontext()
newcontext = oldcontext.copy()
newcontext.prec += 2
yield None
decimal.setcontext(oldcontext)
This approach defends against various kinds of unruly behavior by the
> I think you're missing a decimal.setcontext(newcontext) before the
> yield..
Right.
___
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/arc
make sure the context gets restored even if an exception is raised at
some unexpected point in the middle of the computation.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsu
following example shows the
kind of oddity that can arise when working with quantities that have not
been rounded to the current precision:
>>> from decimal import getcontext, Decimal as D
>>> getcontext().prec = 3
>>> D(&#
[Raymond]
> > The following example shows the kind of oddity that can arise when
> > working with quantities that have not been rounded to the current
> precision:
> >
> > >>> from decimal import getcontext, Decimal as D
> > >>> getcontext().p
backwards compatability, it
introduces yet another new/old style distinction where we have to keep
both forms in perpetuity.
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
ution to
long standing issues. I would rather not have it contaminated with
distracting issues and co-routine dreams.
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
> Okay. Maybe we should just update PEP 325, then?
-1.
Keep this separate.
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-
> [Raymond Hettinger]
> > Are the value and traceback arguments optional as they are with the
> > current raise statement? If they are optional, what would the
default
> > be? I think the preferred choice is to have the call to the throw
> > method be the anchor po
O).
>
> If either of those PEP authors feels like updating their PEP, they
> have my blessings! I probably won't get to writing my own for a few
> more days.
Okay, I volunteer to recast PEP 288 to encompass your combined proposa
is alone and simply document the best practices (using unary plus
after a precision change and constructing using create_decimal whenever
context is important to construction).
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
hen
> ignoring it). Raymond take notice if you're still working on the PEP.
Got 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/
[Tim suggesting that I'm clueless and dazzled by sparkling lights]
> There seems to be an unspoken "wow that's cool!" kind of belief
> that because Python's Decimal representation is _potentially_
> unbounded, the constructor should build an object big enough to
> hold any argument exactly (up t
decimal design rationale to schoolbook
math
---
I can't find this link. If someone remembers, please post it.
Okay, I've said my piece.
Do what you will.
Raymond
___
Pytho
Be careful with this proposed change. It is a can of worms.
Better yet, don't do it. We already have a context aware
constructor method if that is what you really want.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
ally, the implementation relies on
the existing behavior so it is not easily changed. Don't do it.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/
ontext traps InvalidOperation, an
exception is raised; otherwise, the constructor returns a new Decimal
with the value of NaN.
"""
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
[Guido]
> > You know that, but Raymond seems confused. From one of his posts
(point
> (k)):
[Raymond]
> > "Throughout the implementation, the code calls the Decimal
> > constructor to create intermediate values. Every one of those calls
> > would need to
>> d.getcontext().prec = 4
>>>
d.getcontext().create_decimal("1.234567890123456789012345678901234567890
123456789")
Decimal("1.235")
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
harm in allowing any context free
construction while I see greater harm from re-introducing representation
error when that is what we were trying to fix in the first place.
The rest is just practicalities and engineering (altering decimal's
internals may be a non-trivial undertaking)
Some of the private email I've received indicates a need for a decimal
FAQ that would shorten the module's learning curve.
A discussion draft follows.
Raymond
---
Q. It is cumbersome to type decimal.Decimal('1234.5')
tart out with CVS tracker permissions.
When you have a patch that is really to apply,
upload it to the tracker and assign to me.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
> Let's start out with CVS tracker permissions.
> When you have a patch that is really to apply,
> upload it to the tracker and assign to me.
really --> ready
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
;s no harm in having these surface. If the category is accurate,
let's use it. If the bug is out of date, we can mark it as such and
close it.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
ot a real problem in practice).
Raymond
P.S. When setting a time deadline for an OP to respond, we should use
some terminology other than "deprecated". The word doesn't fit well and
can be confused with the unrelated topic of module or feature
deprecation.
___
> If Raymond would rather defer to me, I can give it a shot in a revised
> version of PEP 343,
Thanks, that would be great. The decimal conversation used up a lot of
my available cycles.
Raymond
___
Python-Dev mailing list
Python-Dev@pyth
r policy. Is there anyone else on python-dev who thinks it's
a bad idea to automatically close reports without checking whether the issue is
real?
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
ssing the particular
issue in question. Go recruit some qualified developers. Or just find
a bug that interests you and fix it.
Closing bugs without reading them is an anti-contribution. If it were a
best practice, then there would already be a cron job in place to do it
automatically.
Raymond
gt; skipyes = _len(code); emit(0)
> _compile(code, av[1], flags)
> if av[2]:
The times two operation also occurs twice in nearby code. Are those
also incorrect?
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev
a wonderful,
must-have addition.
Raymond Hettinger
___
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 standard library.
Rewritten:
If Fredrik Lundh were supportive of the idea, I think the Standard
Library would benefit greatly from incorporating ElementTree.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
re else (what is thrown at or
into). It is simple, clear, and tends to suggest all the right things.
I have no doubt that someone can point out differing semantics in other
languages but I don't care. The verbal cue is what we are after.
Raymond
__
:
being the equivalent of;
_firstpass = True
while _firstpass or :
_firstpass = False
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
). I can currently recognize such constructs and am
working
> on
> code generation.
I think it unwise to allow x to be any expression. Besides altering
existing semantics, it leads to code redundancy and to a fragile
construct (where the slightest alte
ust don't fit the Python mold.
In contrast, the dowhile solution only takes about 30 seconds to get
used to. Maybe that idea should follow the path of the genexp PEP, get
rejected now, and then get resurrected as a bright idea two years from
now. Or ma
[BJörn Lindqvist]
> I would like to have do-while's like this:
>
> do:
>
> until
>
> But I'm sure that has problems too.
That looks nice to me.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
[Jp Calderone]
> Anything can be a for loop.
>
> for chunk in iter(lambda: f1.read(CHUNK_SIZE), ''):
> f2.write(chunk)
It would be nice to have this encapsulated in a file method:
for chunk in f1.iterblocks(CHUNK_SIZE):
f2.
t what you want, there would
need to be a new method in the file API. The reason is roughly similar
to why we have iteritems as part of the mapping API and not as a
standalone itertool.
for data in inp.read(blocksize):
. . .
Raymond
___
P
r inp.
itertools work with generic iterators, not ones with a specific API.
Law of Demeter.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/option
[Bob]
> islice depends on __getitem__.
Incorrect. It uses the iterator protocol.
___
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
.
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
r, how 342 intends to overcome
the off-by-one issue, how it addresses all of the other objections
leveled at the now dead PEP 288, and why no one appears concerned about
introducing yet another new-style/old-style issue that will live in
perpetuity.
Raymond
Sidenote: generator attributes also fa
to the more likely use case of
wanting the access only the largest counts:
>>> nlargest(2, d.iteritems(), itemgetter(1))
[('b', 23), ('d', 17)]
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyt
The need for the indices() proposal was mostly met by PEP 279's
enumerate() builtin.
Commenting on 279 before it was accepted for Py2.3, PEP 281's author,
Magnus Lie Hetland, wrote, "I'm quite happy to have it make PEP 281
f retirement a few months ago. Guido hated every
variation of argument passing and frequently quipped that data passing
was trivially accomplished though mutable arguments to a generator,
through class based iterators, or via a global variable. I believe al
clarity, explainability,
obviousness, usefulness, and necessity. IMO, it fails most of those
tests.
I would not look forward to explaining "continue EXPR" in the tutorial
and think it would stand out as an anti-feature.
Raymond
___
Python-D
a syntax error and would
become valid:
x, = 1
The proposal adds iterability to all integers but silently does nothing
for negative values.
A minor additional concern is that floats are not given an equivalent
capability (for obvious reasons) but this breaks sym
://hrsbstaff.ednet.ns.ca/waymac/History%20A/A%20Term%201/1.%20Rome/R
oman_Numerals.htm
http://www.sizes.com/numbers/roman_numerals.htm
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
as
default arguments or indicating values that are not applicable).
Mysteriously, the PEP consumes only *args but not **kwargs.
It also fails with respect to clarity and explicitness. Defining a
short, explicit default function is a hands-down winner in these two
important measures of merit.
, multiple contexts, and alternate rounding modes have been fully thought out. Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/
ingle
accumulation recipe that would work with a variety of binary operators.
Executive summary: cute, but unpersuasive and unnecessary, not worth
the time to code, test, document, maintain, and explain.
Raymond
___
Python-Dev mailing list
Pytho
which only targets simple,
obvious cases. The discussed extensions are unattractive and should be
skipped.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
IIRC, there was a decision to not implement phase C and to keep the
trailing L in representations of long integers.
If so, I believe the PEP can be marked as final. We've done all we're
going to do.
Raymond
___
Python-Dev mailing list
apana.org.au/~abo/projects/utils/
Thank both of you for the excellent posts. This is exactly kind of
feedback and analysis that will show whether continue EXPR is worth 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
warnings in place for Py2.5. There is no need to exacerbate the
problem. Alternately, simplify the issue by declaring that the values
will be handled as if by xrange().
The above recommendations should get the PEP ready for judgement day.
Good luck.
Raymond
_
[Raymond Hettinger]
> > I think it unwise to allow x to be any expression. Besides altering
> > existing semantics, it leads to code redundancy and to a fragile
> > construct (where the slightest alteration of any of the expressions
> > triggers a silent reversion to O(n)
[Raymond Hettinger]
> > > I recommend that the proposed syntax be altered to be more
parallel
> > > with the existing for-loop syntax to make it more parsable for
both
> > > humans and for the compiler.
[Michael Hudson]
> > Although all your suggestions are imp
f we want to be on the leading
edge, we can't be copying what was done years ago in Lua. ;-)
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opt
best
unpleasant). Also, the naming is off -- 'def' defines some variable
name. In Lua, the 'def' is called 'function' which doesn't imply a
variable assignment.
Raymond
___
Python-Dev mailing list
Python-Dev@python
no one will likely find the benefit to be
perceptible.
Suggest rejecting this PEP and making a note for Py3.0 to either sync-up
the type names or abandon the types module entirely.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http
feeling of security. I think not.
There isn't anything wrong with having a verifier module, but I can't
think of any benefit that would warrant changing the bytecode semantics
just to facilitate one of the static stack checks.
Raymond
___
This PEP is an empty stub that is unlikely to ever get filled-out in a
way that adds anything beyond what is already implemented and
documented.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
Please do not spam multiple mail lists with these posts (edu-sig,
python-dev, and tutor).
Raymond
- Original Message -
From: "Smith" <[EMAIL PROTECTED]>
To:
Cc: ;
Sent: Monday, February 13, 2006 12:10 PM
Subject: Re: [
[Guido van Rossum]
> Somewhat controversial:
>
> - bytes("abc") == bytes(map(ord, "abc"))
At first glance, this seems obvious and necessary, so if it's somewhat
controversial, then I'm missing something. What's the issue?
Raymond
__
o come up with relative and absolute
tolerances that make their application succeed over the full domain of possible
inputs).
Raymond
relevant posts from Greg and Terry
[Greg Ewing]
>> I don't think you're doing anyone any favours by trying to protect
>> them fr
):
dd[word].append(word)
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
> My conclusion is that setdefault() is a failure -- it was a
> well-intentioned construct, but doesn't actually create more readable
> code.
It was an across the board failure: naming, clarity, efficiency.
Can we agree to slate dict.setdefault() to disappear in Py
's the right way to avoid Liskov violations from altered
invariants and API changes. Besides, with Python's propensity for duck typing,
there's no reason to subclass when we don't have to.
Raymond
___
Python-Dev mailing list
Python-
del d[some_key]
assert some_key not in d
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
over the whole contents? If the latter, then do
you
worry that "dd[v]=k" does not imply "(k,v) in dd.items()"?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
g invariant that "k in dd" implies "k in
dd.keys()"?
Is the notion of __contains__ at odds with notion of universality?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-d
rt(lambda a, b: cmp(a.aliases[0], b.aliases[0]))
to:
self._cmds.sort(key=operator.itemgetter(0))
or if you want to avoid module dependencies:
self._cmds.sort(key=lambda a: a[0])
4) In _preCommand, the sort simplifies from:
[Raymond Hettinger]
> 1) The "chars" variable can be eliminated and the "while chars" and
> "c=chars.pop(0)" sequence simplified to just:
>for c in reversed(str):
Actually, that should have been just:
lines.
BTW, addspec() could be made completely general by supporting all possible
keywords at once:
def addspec(**kwds):
def decorator(func):
func.__dict__.update(kwds)
return func
return decorator
With an open definition like that, users can specify new attributes with
or not.
That makes sense, though it seems over-the-top to need a zero-factory for a
multiset.
An alternative is to have two possible attributes:
d.default_factory = list
or
d.default_value = 0
with an exception being raised when both are defined (the test is done when the
a
[Crutcher Dunnavant ]
>> There are many times that I want d[key] to give me a value even when
>> it isn't defined, but that doesn't always mean I want to _save_ that
>> value in the dict.
How does that differ from the existin
t to do the initial setup in two lines, a classmethod
could serve as an alternate constructor (leaving the regular contructor fully
interchangeable with dicts):
dd = defaultdict.setup(list, {'k1':'v1', 'k2:v2'})
or when t
W, I'm happy with the proposal and think it is a nice addition to Py2.5.
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
; on the other hand is associated with nothing. You might as
well
argue to call it magicdictionary because "magic" has two letters less than
"default" ;-)
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
Then you will likely be happy with Guido's current version of the patch.
- Original Message -
From: "Crutcher Dunnavant" <[EMAIL PROTECTED]>
To: "Raymond Hettinger" <[EMAIL PROTECTED]>
Cc: "Python Dev"
Sent: Monday, February 20, 200
> Speaking of which, I suspect it'll be a lot more common to need integer
> objects in the full range [0, 255] than it is now.
>
> Perhaps we should extend the pre-allocated integer objects to cover the
> full byte range.
+1
___
Python-Dev mailing list
memory and make the code readable.
Try to resist generalizing the name into nothingness.
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
fficult.
My recommendation: Dump the on_missing()
hook. That leaves the dict API unmolested and allows a more
straight-forward implementation/explanation of collections.default_dict or
whatever it ends-up being named. The result is delightfully s
ct. The "anything" class can be viewed
as
either a sequence or a mapping.
In this and other posts, you seem to be focusing your design around notions of
strong typing and mandatory interfaces. I would suggest that that approach is
futile unless you control all of the code being
get exactly the same beginner's error we
> already have with function defaults:
That makes sense.
I'm somewhat happy with the patch as it stands now. The only part that needs
serious rethinking is putting on_missing() in regular dicts. See my other
email
on that subject.
Ra
1101 - 1200 of 1495 matches
Mail list logo
