On Apr 4, 2006, at 8:01 AM, Jeremy Hylton wrote:
> On 4/4/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
>> import collections
>> def tally(seq):
>> d = collections.defaultdict(int)
>> for item in seq:
>> d[item] += 1
>> ret
On 4/4/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Alex]
> > This is quite general and simple at the same time: for example, it
> > was proposed originally to answer some complaint about any and all
> > giving no indication of the count of true/false items:
>
ld have to be distorted to ensure
they can't raise -- better to let them raise if they must, and allow
catching the expected exception(s), somewhat like this example.
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
On Apr 4, 2006, at 10:53 PM, Jess Austin wrote:
> Alex wrote:
>> import collections
>> def tally(seq):
>> d = collections.defaultdict(int)
>> for item in seq:
>> d[item] += 1
>> return dict(d)
>
> I'll stop l
l.etree. The module and class are still called
ElementTree, though.
Alex
___
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
if decimals become the Py3k
default), q'123/54' for rationals (today's gmpy.mpq('123/54') or other
implementations), etc. Ideas which have little to do with i18n,
mostly. It's exactly because of the broad impact of such a mechanism
(and, inevitably, the pos
sly posits that Macs "must" have PPC processors (which
has been false for many months and was not posited in alpha-1, which
compiled fine here). Too tired to look more into this (having just
driven back from a week's vacation in the Grand Canyon), but I will
next week
numbers.
GMP is covered by LGPL, so must any such derivative work (presumably
ruling it out for embedding in Python's core itself). That being
said, as gmpy's author, I'd be enthusiastically happy to mentor
anybody who wants to work on gmpy or other multiprecision arithmetic
e measurements on a variety of
platforms, ..., are all important part of a project that, assuming
success, it's scheduled to become a core part of Python 2.6, after
all.
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
?
I'm quite confident that the concept of "derived work" would not apply
if gmpy.so only accessed a gmp.so (or other kinds of dynamic
libraries), but I fear the connection is stronger than that, so,
prudently, I'm assuming the "derived work" status until further
notic
gt;> build Python with free tools :-(
> [...]
>
> Actually, it's apparently still there, just at a different URL.
> Somebody posted the new URL on c.l.py a day or two back (Alex
> Martelli started the thread, IIRC). I'm off to the dentist, no
> time to Google fo
ython and extensions. However, by the same
token I cannot really gauge how stable and solid VS 2005 is -- if as
current Windows experts you think it's still inferior to VS 2003,
then that's a very big point against it.
Alex
___
Python-D
en superceded.
Yeah, that does sound like a normal commercial policy. If we want
some compiler to be available "forever", we have to choose one that
we can get permission to redistribute, and host it somewhere ourselves.
Alex
___
Python-
may be, it's still most definitely worth asking,
so that everything doesn't suddenly break the instant MS wants to
withdraw the URLs that currently still work. Also, we'd need the
ability to redistribute the 1.1 SDK, as the 2.0 one seems to lack the
key msvcrt.lib for
e
we should just repurpose that bit of Twisted?-)
I don't think this is feasible for 2.5 (too late in the cycle to add
major new stuff, IMHO), but it's well worth it for 2.6 (again IMHO).
Alex
___
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
signs to
that name rather than to an indexing thereof).
That being said, having to write x[()]=23 explicitly (rather than
x[]=23) wouldn't perturb me overmuch, personally -- so, I don't see a
need to rush this at the last minute into 2.5 beta (rather than
letting t
Numeric.Float64 instead -- an
ancient wart of Numeric, of course. Still, Numeric and its
descendants are "the" way in Python to get multi-dimensional arrays,
since the stdlib's array module only supports one-dimensional ones,
and lists are not arrays.
Alex
__
w
reworded to point out that this is not in fact a problem for the
module's current default random number generator? Opinions welcome!
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Un
On Jun 10, 2006, at 1:08 PM, Josiah Carlson wrote:
> Josiah Carlson <[EMAIL PROTECTED]> wrote:
>>
>> Alex Martelli <[EMAIL PROTECTED]> wrote:
>>>
>>> ...claims:
>>>
>>> Note that for even rather small len(x), the total number of
> case == X:
> case < X:
> case is X:
> case isinstance X:
>
> since I'm -1 on all those, no matter how nicely they align.
Agreed on the generalizations, but allowing (just) "case == X" and
"case in S" looks more readable to me than "case X&
What about doing it with a per-thread-timeout in TLS (overriding the
global one if a thread does have it set in its TLS)? Not as clean,
but perhaps far easier to implement than patching dozens of
modules/functions/classes to provide timeout= options everywhere...
Alex
On 7/5/06, Guido van
In Italian that would be DBAV (Dittatore benevolo a vita)...;-)
Alex
On 7/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Frank> That said, I still regard Samuele Pedroni as the ultimate
> Frank> authority on Jython and give him pretty much full veto p
e is automated delegation
obtained by having getattr(foo, 'bar') look through a chain of objects
(essentially the __mro__) until an attribute named 'bar' is found in
one of those objects, plus a few minor but useful side effects, e.g.
on isinstance and issubclass, and the catchin
On Nov 17, 2005, at 12:46 PM, Brett Cannon wrote:
...
>> alloca?
>>
>> (duck)
>>
>
> But how widespread is its support (e.g., does Windows have it)?
Yep, spelled with a leading underscore:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
vcli
alloca and to malloc/free elsewhere -- this
would keep the sources just as cluttered, but still speed things up
where feasible. E.g., on my iBook, a silly benchmark just freeing
and allocating 80,000 hunks of 1000 bytes takes 13ms with alloca, 57
wit
On 11/30/05, Matthew F. Barnes <[EMAIL PROTECTED]> wrote:
...
> I'm curious if anything like this has been proposed in the past. If so,
> could someone kindly point me to any relevant mailing list threads?
PEP 342, already accepted and found at
http://python.org/peps/pep-0342.html , covers rel
icular bit of confusion.
...while I use 'mcl' for the same purpose (seems closer to me in
spirit to 'cls' than 'meta' would be); Guido said he liked that, at
the time (a couple of years ago) when he was following a talk of mine
on metaclasses where I introduced this conv
-remember, pair of choices such as cls and meta. Perhaps
Guido can Pronounce one way or another and set the subdiscussion to
rest...
Alex
___
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
disk
image" within a single file), native to MacOSX, that can be used in
Linux (and I believe in some other Unix variants) by mounting the file
as a "loop device" (there's all sort of niggling issues, such as the
need to be root to do so, but perhaps there might be workarounds...).
ntage, along any plane, since the
genexp fits so snugly right there inside the any/all's parentheses.
What am I missing?
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
; pred(seq[2]) and ...
...and also the equivalent of all(pred(s) for s in seq) -- which is
exactly my problem: I don't like redundant good ways of expressing
identical tasks. The genexp will often be more compact, whenever the
'pred' requires a def, a lambda, or someth
t;, which differently from English "a couple" ALWAYS, not just
sometimes, implies exactly two items; so I can't base myself on
analogies with my own mothertongue;-).
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
eneralization means a complicated implementation, by all
means let's scrap it, but if implementation is roughly as easy, it
may be worth considering to avoid making a too-special "special
case" (or maybe not, but brainstorming means never having to say
you're sorry;-).
don't
mean "half a dozen times right after each other with nothing
in-between" (sorry for the ambiguous phrasing), but "numerous times,
repeatedly in the course of an interactive interpreter session".
Alex
___
Python-Dev mailing
od thing it's spelled in full only in one obscure church register
and an even obscurer "Italian Register of Gentry", because I even
feel it an imposition to have to spell out my legal first name
"Alessandro" in some documents (it's that way in my passport, alas
ential base* classes for as long as it
takes for the dust to settle
I'll be happy to draft a PEP if needed (and just as happy to
eventually provide an implementation patch if the PEP's accepted),
but wanted to doublecheck on the general issue first!
Alex
__
On Jan 16, 2006, at 7:53 AM, Guido van Rossum wrote:
> On 1/15/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
>> Now, today, I have _again_ been bit by the lack of basenumber (by a
>> bug of mine, fixed by adding decimal.Decimal to a long tuple of
>> classes to be passed
On Jan 16, 2006, at 2:01 PM, Martin v. Lรถwis wrote:
> Alex Martelli wrote:
>> I can't find a PEP describing this restriction of basestring, and I
>> don't see why a coder who needs to implement another kind of
>> character string shouldn't subclass basestring
d it's awkward to explain
why it's not!-). I'll be happy to propose a patch if the BDFL
blesses this, but I don't even think it's worth a PEP... it's an
inexplicable though long-standing omission (given the argumentative
nature of this crowd I know I'll get pus
can
> be passed to str().
Identically the same situation as for int: the base argument is only
accepted if the first argument is a str (not a float, etc). Just the
same way, the base argument to str will only be accepted if the first
argument is an int (not a float, etc).
Alex
___
On 1/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 1/16/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> > Is it finally time in Python 2.5 to allow the "obvious" use of, say,
> > str(5,2) to give '101', just the converse of the way int(&#
On 1/17/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Alex, I think you're missing a point here: what you are looking
> for is an interface, not a base class - simply because the
I expect numbers to support arithmetic operators, &c -- no need for
basenumber to "spe
ntage of specifying it as an argument to base, rather than
just string-concatenating it?
Apart from that quibble, the base function appears to cover all the
use cases for my proposed str-with-base, so, since it appears to
attract less arguments, I'm definitely +1 on it.
Alex
__
is a great way to get my blood steaming." --
>> GvR
>
> Ya know, you don't *have* to use his software. For example, python
> could stop supporting readline and support libedit instead.
In Py3k this should indeed be considered; I don't think it can be
within Python 2.
above, while the original (nested for-loops) is pretty rigid. And
the inputfrom generator doesn't look too complicated either:
def inputfrom(iterators):
for iterator in iterators:
for item in iterator:
if (yield item) is not None:
y
(==on IBM's
online store, called APL2!-).
> > Accordingly,Guido rejected the braced notation for set comprehensions.
> > See: http://www.python.org/peps/pep-0218.html
>
> "...however, the issue could be revisited for Python 3000 (see PEP 3000)."
> So I'm
caller
...? This would allow removal of even more lambdas.
I'll be glad to write a PEP, but I first want to check whether the
Python-Dev crowd would just blast it out of the waters, in which case
I may save writing it...
Alex
___
Python-Dev mail
On Feb 3, 2006, at 1:36 AM, Michael Hudson wrote:
> Alex Martelli <[EMAIL PROTECTED]> writes:
>
>> I was recently reviewing a lot of the Python 2.4 code I have written,
>> and I've noticed one thing: thanks to the attrgetter and itemgetter
>> functions in module
/attrgetter/methodcaller: they allow deferred
> execution
> using a syntax which is not equivalent to that of immediate execution.
I understand your worry re the syntax issue. So what about Michael
Hudson's "placeholder class" idea, where X[1] returns the callable
When teaching some programming to total newbies, a common frustration
is how to explain why a==b is False when a and b are floats computed
by different routes which ``should'' give the same results (if
arithmetic had infinite precision). Decimals can help, but another
approach I've found u
just like dict(), tuple(), list(), str(), int(), float(), bool(),
complex() -- each type, called without args, returns an instance F of
that type such that "bool(F) is False" holds (meaning len(F)==0 for
container types, F==0 for number types).
Alex
__
dunno 'bout
complex, I'd be happy either way), and Python's typesystem would
finally start being nice and cleanly organized instead of
grand-prarie-level flat ...!-)
Alex
___
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 true.
>
> Yes, that's a big help. I was a bit concerned that this would have no
> utility for numbers with large magnitude. Alex, given your focus on
> Python readability, I'm a bit surprised you didn't write this to start
> with!
As I said, I was just copying
be carefully extracted that (given suitable volunteers to
maintain it in the future) might fit in the standard library, but [a]
that extraction is not going to be a simple or fast job, and [b] I
suspect that the minimum sensible subset would still be much larger
(and richer / more powerful) than asyn
point is that I don't think
we want every Python-coded sequence to have to call x.__index__()
instead.
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/
f maps (e.g. builtin /
per-module / lexically nested, or whatever) if that's what it takes to
warm you to it -- I just think it would be over-engineering it, since
in practice the global-on-all-modules map would cover by far most
usage (both for "blessed" protocols that come with Pyt
It has at least one anti-champion. I think it is a horrible idea
> and would
> like to see it rejected in a way that brings finality. If needed,
> I can
> elaborate in a separate thread.
Could you please do that? I'd like to understand all of your
objections. Thanks!
A
s merits.
The problem is that I found no mention of this behavior in the docs.
P.S. tested in 2.5 through 3.0 and PyPy
Thanks.
--
Alex.
___
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
Thanks!
On Fri, Mar 19, 2010 at 16:05, Michael Foord wrote:
> On 19/03/2010 12:46, Alex A. Naanou wrote:
>>
>> [snip...]
>>>>>
>>>>> class C(object):
>>>>>
>>
>> ... ย ย def __radd__(self, other):
>&
e += [1]
P.S. the attachment is runnable version of the above code...
--
Thanks!
Alex.
___
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 knew this was a feature!!!
features such as these should be fixed! %)
On Sat, Mar 3, 2012 at 03:38, R. David Murray wrote:
> On Sat, 03 Mar 2012 03:06:33 +0400, "Alex A. Naanou"
> wrote:
>> Hi everyone,
>>
>> Just stumbled on a fun little thing:
to assert is not the relation to the
dict class but the support of the mapping protocol
thanks.
--
Alex.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailm
have used NFC rather than NFKC. Not sure if it's too late to fix
this "oops" in future Python versions.
Alex
On Sun, Nov 14, 2021 at 9:17 AM Christopher Barker
wrote:
> On Sat, Nov 13, 2021 at 2:03 PM wrote:
>
>> def ๐๐ฎ๐๐๐():
>>
>> try:
>>
hat this is a problem and is interested in solving it, but
getting it prioritized will require folks to A) speak up saying they want
it done B) test the underlying API to verify that it actually solves the
problem.
Alex
On Sun, Dec 11, 2022 at 1:54 PM Tiziano Zito wrote:
>
> On Sat 10 Dec, 17
301 - 364 of 364 matches
Mail list logo
