(more than a line or two). For a long-time, we've
always said that it is okay to submit plain text doc contributions and
that another person downstream would do the mark-up. We've had
few takers.
Raymond
___
Python-Dev mailing list
Python-D
, to ensure it's truly unambiguous
> in the context of that use case.
Right.
That's why Barry and others write:
missing = object()
v = d.get(k, missing)
That is the guaranteed way to get a unique object.
Raymond
___
Python-Dev mailing l
sal would
tend to steer people down the wrong road, away from more
natural solutions to problems involving iterators. A basic step
in learning the language is to differentiate between sequences
and general iterators -- we should not conflate the two.
Raymond
_
s: getitem(genprimes(), -1).
I'll study Walter's use case but my instincts say that adding
getitem() will do more harm than good.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
kip-over, etc) the first 1000 true items and it did
return EVERY element from the first false to the end. It did not produce any
output for the first 1000 inputs so it took a while to
get to the first output (the first false). Hope that clears it up
[Stephen J. Turnbull]
> Shouldn't the "until" in the doc be "while"? Alternatively, "true"
> could be changed to "false".
Yes. I'll make the change.
Raymond
___
Python-Dev mailing list
Pytho
The docs do make a distinction and generally follow the definitions given in
the glossary for the tuturial.
In the case of iter(collection), I prefer the current wording because the
target object need not support __iter__, it is sufficient
to supply a sequential __getitem__ method.
Raymond
sider using the abstract API:
f = PyObject_CallFunction(&PyFrozenSet_Type, "(OOO)", obj1, obj2, obj3);
That will roll the whole process up into one line.
Hope this was helpful,
Raymond
---
Bill Janssen <[EMAI
know where to create the n empty slots (since their
location is determined by the hash value of the keys). That is a reason that
the tuple/list API differs from the set/frozenet/dict API.
Raymond
___
Python-Dev mailing list
Python-Dev@python.or
ling to unnecessarily expand the module.
However, for Py3k, I'm open to changing the signature for chain().
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.o
[Bruce Frederiksen]
>>>> I've added a new function to itertools called 'concat'. This
>>>> function is
>>>> much like chain, but takes all of the iterables as a single
>>>> argument.
[Raymond]
>> Any practical use case
If the differences are few, I prefer that you insert some conditionals
that attach different functions based on the version number. That way
we can keep a single version of the source that works on all of the
pythons.
Raymond
On Sep 29, 2007, at 8:26 AM, "Thomas Wouters" <[EM
bug fixes and
backported. This is especially important in this case
because other errors have been fixed and the test cases have grown.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsu
ut 2.4?
If there are any plans for another 2.4 release, then yes; otherwise, why bother.
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
For Py2.6, I fixed a long standing irritant where the count raised an
OverflowError when it reached LONG_MAX.
If you guys agree that is a bug fix, I'll backport it to Py2.5.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
ing else that wraps functions.
Alternatively, the doc string could be made a little
more informative:
__doc__ = 'property of function %s: %s' % (f.__name__, f.__doc__)
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
> and have a matching propdel decorator?
-1. That would be a complete waste of builtin space.
Put stuff in when it is really needed. Ideas are
not required to automatically propagate from the
commonly used cases to the rarely used cases.
Raym
a
short, simple mnemonic to the functionality.
Also, I find that these unique words are easier to search for. I once co-owned
a magazine called Know Your Boston and it was very difficult for clients to
find using Google.
Raymond
___
Pytho
> As you may have seen, I have recently been granted developer
> privileges on python svn.
Hello Amaury. Welcome aboard.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
better suggestions. Also, the
recipe itself is a combination of the best of prior attempts. Unfortunately,
each of several commenters revisit everything from scratch and propose their
own complete rewrites that ignore the requests and commments of all those who
pre
for a spin).
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
> In my opinion __replace__ should be able to replace multiple fields.
This suggestion is accepted and checked-in. See revision 58975.
Surprisingly, the required signature change results in improved
clarity. This was an all around win.
Raym
boost
to the Queue module and a number of other tools that
were using lists for deque-style operations.
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
> It looks like we're in agreement to drop unbound methods
+1 It is a bit cleaner to simply return the unmodified function.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
> I never even saw that one. I'm hoping Raymond will have another look.
Great. Will review it this week.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.py
> Hm... [EMAIL PROTECTED] bounced. I wonder what's going on there..
I'm now in an EWT spin-off company. The new email address is [EMAIL PROTECTED]
Also, I frequently check the [EMAIL PROTECTED] account too.
Raymond
___
Python-Dev
find the meaning to be transparent and the proposal adds new syntax
without adding functionality.
Also, I do not find the "emtpy generator" use case to be even slightly
motivating. If an empty iterator were needed for some
reason, I would just write: iter([]) and be done with it.
Raymo
In your example, why do you "raise StopIteration" instead just writing "return"?
- Original Message -
From: "Manuel Alejandro Cerón Estrada" <[EMAIL PROTECTED]>
Take a look at this example:
def lines():
for line in my_file:
if some_error():
raise StopIteration()
> 2007/12/8, Raymond Hettinger <[EMAIL PROTECTED]>:
>>...the proposal adds new syntax without adding functionality.
>
> That is indeed the definition of syntactic sugar [1]. Python is full
> of that, for example the import statement.
. . .
> The real problem is that
>
test_threading for example.
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
The standard library, my personal code, third-party packages, and my employer's
code base are filled with examples of the following pattern:
try:
import threading
except ImportError:
import dummy_threading as threading
try:
import xml.etree.cElementTree as ET
except ImportError:
tr
re problematic as "emptymodule" seems too magical.
> . . .
> try:
>readline = None
>import readline
> except ImportError:
>pass
Perhaps "import readline or None" would have been a better way to capture that
pattern as well as the "except pass
eed go away in Py3.0, what is
the typical pattern?
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
(I think Google is still
running tons of code on 2.2, 2.3, and 2.4). There
needs to be a good incentive for upgrading; otherwise, Py2.6 *will* fail.
The specific change suggested here is possibly (and perhaps probably) harmless;
however, it is part of a larger trend that is not
hea
tegory of things that don't provide them any
benefit).
> Right now, in the trunk, math.float(1) returns 1,
> where it should return 1.0 for compatibility with 2.5.
> Jeffrey, can you fix this and similar incompatibilities
> you introduced?
Thanks for zapping this.
Raymond
it is easy to explain, it runs fast, and it is not hard
to get right.
my two cents,
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pyth
[Paul Moore]
> 1 .__str__()
> This one is a number "1" followed by
> the operator "." followed by "__str__".
FWIW, I would avoid the odd spacing and write this as:
(1).__str__()
Raymond
___
Python-Dev
esponding to some
set of keys. There are probably a lot of functions that take keys and values
separately, so it would not be uncommon to call those with a pattern like:
save_config(configfile, d.keys(), d.values()).
In the OP's context where multiple threads are running,
ypes
> that support it?
That would clutter the interface. Just specify a universal rounding mode for
__round__ and have Decimal's implementation of that
method comply.
If someone wants more control than that, they can manipulate the decim
[Tim]
> I agree it's far from obvious to most how
> to accomplish rounding using the decimal facilities.
FWIW, there is an entry for this in the Decimal FAQ:
http://docs.python.org/lib/decimal-faq.html
Raymond
___
Python-Dev mailing list
more harm than good.
Raymond
- Original Message -
From: "Jeffrey Yasskin" <[EMAIL PROTECTED]>
To: "Raymond Hettinger" <[EMAIL PROTECTED]>
Cc: "Mark Dickinson" <[EMAIL PROTECTED]>; "Python 3000" <[EMAIL PROTECTED]>;
Sent
to a module that already has a huge number of methods. Our
goal is to keep that module as a minimal
implementation of the spec. Fattening the API will make the module harder to
use, not simpler.
Raymond
___
Python-Dev mailing list
Python-Dev@py
[Raymond]
>> There should probably be a PEP sets clearer guidelines about what should be
>> backported from Py3.0.
>>
>> Perhaps something like this:
>> * If there is a new feature that can be implemented in both and will make
>> both more attractive, then it
die right now.
The sentiment is unchanged -- please do not build-out the API for the
decimal module. It is intended to be minimal and needs to stay that
way. Further additions will only make it harder to use, harder to
maintain, and will complicate efforts to rewrite the module in C.
Raymond
ng, this doesn't improve Py2.6 in the least.
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
API, please pay special attention. In this case, you are working
directly against a core philosophy for the design and maintenance
of the module.
I admire your enthusiasm, but please hold it in check.
Raymond
___
Python-Dev mailing list
Python-Dev@python.o
urrent proposal to add a duplicate method.
If someone really cared about making the module easier to use, I would fully
support efforts to write a tutorial on the fundamentals
or an effort to write a client module implementing only a subset of the spec.
Raymond
__
round module
quality, duplication, and obsolence. In contrast, I do not think that
introducing a hierarchy of namespaces is of interest to most users. That
exercise may well make the language harder to use/learn, not easier.
my-two-cents-ly,
Raymond
__
This seems like something that could reasonably be added to Py2.6.
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
't a common use case to need to sum two dictionaries while
keeping both of the inputs unaltered.
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/305268.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
time?
What are the use cases?
FWIW, the Py3.0 API for dicts will support some set-like
operations. Perhaps, that fits the bill.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
he work. (The abc.py module needs to be updated
> too.)
I think this would end-up being clutter, something added
just because it could be done, not because we have compelling
use cases that can't be met with existing dicts, sets, and lists.
Raymond
___
[Raymond]
>>> When does it come-up that you want a third summed dict
>>> while keeping the two originals around unchanged? Does
>>> it matter that the addition is non-commutative? Would
>>> a + b + c produce an intermediate a/b combo and then
>>> ano
collections.namedtuple(). The _fields tuple should only include the
visible positional fields while _asdict() and _replace() should include all of
the fields whether visible or accessible only by
attribute access.
Thanks for the nice work.
Raymond
_
basically that they *are* tuples with the added
nicity of attribute access and a self-documenting repr.
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
t jump all at once.
Multiple-ways-to-do-it should not be the motto for 2.6. Instead, let's provide
the best transition tools possible and keep both 2.6 and 3.0 as clean as
possible (no duplicative or half-intergrated functionality).
Raymond
___
to have transition issues. It would be nice for us
knuckle-draggers to not have to face the issue until 3.0.
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
; and change all of the
standard library modules? Is this going to pop-up everywhere
and become something you have to know about whether or
not you're a volunteering forward-looking programmer? I hope not.
Raymond
___
Python-Dev mailing list
Python
pressed by:
for elem in container:
assert elem in container
It looks like changing the semantics would introduce some weirdness.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Un
tainer. The code
for sets and frozensets makes that assumption, for example. And, when the code
does break, the errors will be darned hard to find.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pytho
n the language.
There are a handful of needs met by the numeric tower but
they only warrant minimal changes to the language.
Raymond
P.S. The docstring for trunc() makes it sound like an imprecisely
specified version of round().
trunc() looks like int() but it
;m curious why trunc() ended-up in builtins instead of the math
module. Doesn't it make sense to collect similar functions
with similar signatures in the same place?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
[Raymond Hettinger]
> Since something similar is happening to math.ceil and math.floor,
> I'm curious why trunc() ended-up in builtins instead of the math
> module. Doesn't it make sense to collect similar functions
> with similar signatures in the same place?
[Christian H
s and ints and
has no internal references to the rational module).
Raymond
---
def _binary_float_to_ratio(x):
"""x -> (top, bot), a pair of ints s.t. x = top/bot.
The conversion is done exactly, without rounding.
ice of spreading modules these across the library isn't
serving us well.
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 int() for making ints from the non-fractional
portion of a float.
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
> but if Guido
> likes the idea of a standard naming convention (such as the ABC suffix)
> for classes that use the ABCMeta metaclass, I'd certainly be happy to go
> through and update the affected classes and the code which refers to them.
A prefix would be
> If you want ABCs to be more easily recognizable
> as such, perhaps we could use a naming convention,
Essentially, that's all I was asking for. It doesn't
really matter to me whether numbers.py gets called
abc_numbers or abc.numbers. Either one would be an
improv
> If the decision comes to be that int(float) should be blessed
> as a correct way to truncate a float, I'd agree with Raymond
> that trunc() is just duplication and should be eliminated.
Yay, we've make progress!
> I'd,of course, rather have a spelling that says wh
r chucks of
the new model? I'm not seeing any limits on
Py3.0-->Py2.6 contamination.
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
o have frac()
which has the obvious interpretation.
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
ats rounded to n-digits.
I've taught a lot of classes to spreadsheet users and have observed that people
get it right away.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscrib
> 'bytearray' is a separate issue. It's a brand new type: a *mutable*
> byte array. Its status as a built-in and completely different API
> makes it much more convenient than using the old array module.
That's reasonable.
Raymond
_
[Christian Heimes]
> In my opinion float(complex) does do the most sensible thing. It fails
> and points the user to abs().
Right.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsub
y has
problems with it. The tools is ubiquitous in other languages,
spreadsheets, and calculators.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/
;s a bit weird to decide that int() needs to lose that capability so we get
generalized Integrals as output. What's wrong with
coercion to a concrete type?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
[Raymond Hettinger]
>> The idea that programmers are confused by int(3.7)-->3 may not be nuts, but
>> it doesn't match any experience I've had with any
>> programmer, ever.
[Christian Heimes]
> You haven't been doing newbie support in #python lately. Sta
needing
to decide whether to provide __trunc__ which will typically be the
same thing.
In time, I believe it will become self-evident that having both int()
and trunc() is a wart. If trunc() goes into 2.6 and 3.0, then we're
going to have to live with this for a long time.
Purity m
> Then int() can be defined by deferring to trunc()
> -- as opposed to round().
That part is new and represents some progress. If I understand it
correctly, it means that we won't have both __int__ and __trunc__
magic methods. That's a good
[GvR]
>> > - trunc(), round(), floor() and ceil() should all be built-ins,
>> > corresponding to __trunc__, __round__, __floor__ and __ceil__.
In Py2.6, what will the signatures be?
Last I heard, ceil() and floor() were still going to be float
What is the current thinking on this? Is the target still April 2008 as
mentioned in PEP361? Are we going to have an alpha sometime soonish?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
[MvL]
> I wouldn't want to propose removal of len(), no. However,
> I do think that adding more builtins (trunc in particular)
> is bad, especially when they make perfect methods.
+1
Raymond
___
Python-Dev mailing list
Python-Dev@p
f x>0 else math.ceil(x)
elif mode==ROUND_TO_EVEN:
. . .
Maybe we don't need a separate function and magic method for every possible
rounding mode.
Also, I think there was some discussion of changing round() to use
statistician's rounding. We might as well make it e
rmatting on output, while in Python the same thing would
> typically be done with "%.2f" % x rather than round(x, 2).
+1 for deprecating the second argument to round().
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
mixin capabilities
to automatically provide all of these given one or two of
them as primitives.
Raymond
P.S I get no shortage of hits for searches like:
http://www.google.com/search?q=truncate+string
___
Python-Dev mailing list
Python-Dev@python.org
h
stare, which did not surprise me too much as it is not a common
> (American) English word.
Even to adults, the word has other meanings:
http://en.wikipedia.org/wiki/Truncation_%28disambiguation%29
Raymond
___
Python-Dev mailing list
Python-
Should the implementation of __trunc__ have its own slot like we have for
nb_index?
Raymond
---
[EMAIL PROTECTED] ~/py26/Objects $ grep "__trunc__" *.c
floatobject.c: {"__trunc__", (PyCFunction)float_trunc, METH
nc() function which is currently
implemented with PyObject_CallMethod(number, "__trunc__", "")
instead of a fast call to a slot.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pytho
n test_sys.,
"test_compact_freelists self.assert_(r[0][2] > 100, r[0][2])".
Also, test_docxmlrpc hasn't been happy. One of the tests isn't getting the
exact response string it expected. Any ideas what is causing this?
Raymond
___
P
tions/60708-1.txn': No space left on device
> --
>
> I've tried it a few times over the last 5-10 minutes and got the same
> error each time.
I got the same a few times last night.
Raymond
___
Python-Dev mailing
).
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
y3.0 docs have the new signature (same as
the old one but it no longer accepts a cmp function and to prevent
accidents keyword arguments are required). I'm not sure where else
to document it.
> Does it come up in -3 warnings?
It doesn't, but it wouldn't be ha
def mrange(minvec, maxvec=None):
if maxvec is None:
maxvec = minvec
minvec = [0] * len(maxvec)
vec = list(minvec)
unitpos = len(vec) - 1
maxunit = maxvec[unitpos]
_tuple = tuple
while 1:
if vec[unitpos] == maxunit:
i = unitpos
_package__', '_time',
'deque', 'heapq']
>>> Queue.__all__
['Empty', 'Full', 'Queue', 'PriorityQueue', 'LifoQueue']
I like the second one better.
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]
>> Should dir(module) use __all__ when defined?
[GvR]
> It's not consistent with what dir() of a class or instance does though.
>
> -1.
Perhaps there is another solution. Have dir() exclude objects
which are modules. For example, dir(logging) would exclude
package will need to wait for 3.0 to
use the except/as form :-(
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
ner cases
(like handling empty matches or speeding-up badly
designed regexes). Those bug reports and rfes are
valid and should be left open unless a module author
decides that re's won't support the request.
Raymond
___
Python-Dev maili
[Eric Smith]
> I'm going to work on backporting PEP 3127, specifically
>the hex, oct(), and bin() builtins.
IMO, these should not be backported. They are strongly
associated with 3.0's new literal syntax. They don't
don't really fit in with 2.6 and don't make 2.6
ut the API.
He was thrown-off by some of the entries in dir(logging).
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%
ill create a confused mess, IMO.
We should draw the line on Py3.0 backports whenever
the two different models would be conflated
(i.e. str/unicode vs bytes/text or 0123 vs 0o123).
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
701 - 800 of 1495 matches
Mail list logo
