Skip Montanaro wrote:
> I say backport. If people were trying to call os.access with unicode
filenames it would have been failing and they were either avoiding unicode
filenames as a result or working around it some other way. I can't see how
making os.access work with unicode filenames is going
Martin v. Löwis wrote:
Skip Montanaro wrote:
> I say backport. If people were trying to call os.access with unicode
filenames it would have been failing and they were either avoiding
unicode
filenames as a result or working around it some other way. I can't
see how
making os.access work with u
Not sure this is pertinent but anyway: "any" and "all" are often used
as variable names. "all" especially often and then almost always as a
list of something. It would not be good to add "all" to the list of
words to watch out for. Also, "all" is usually thought of as a list of
(all) things. In my
M.-A. Lemburg wrote:
The question is whether it would encourage conditional work-arounds.
-1. That only makes the code more complicated.
You misunderstand. I'm not proposing that the work-around is added
to Python. I'm saying that Python *users* might introduce such
work-arounds to their code.
+1
On Fri, 11 Mar 2005 11:30:38 +0100, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> Not sure this is pertinent but anyway: "any" and "all" are often used
> as variable names. "all" especially often and then almost always as a
> list of something. It would not be good to add "all" to the list of
> word
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
The question is whether it would encourage conditional work-arounds.
-1. That only makes the code more complicated.
You misunderstand. I'm not proposing that the work-around is added
to Python. I'm saying that Python *users* might introduce such
work-a
On Fri, 11 Mar 2005, Paul Moore wrote:
> > Not sure this is pertinent but anyway: "any" and "all" are often used
> > as variable names. "all" especially often and then almost always as a
> > list of something. It would not be good to add "all" to the list of
> > words to watch out for. Also, "all"
Peter Astrand wrote:
On Fri, 11 Mar 2005, Paul Moore wrote:
Not sure this is pertinent but anyway: "any" and "all" are often used
as variable names. "all" especially often and then almost always as a
list of something. It would not be good to add "all" to the list of
words to watch out for. Also
And why not use the names already in use in numarray/Numeric ?
They are called "sometrue" and "alltrue" ... IMHO, it explicits more
what it means :
alltrue(i<5 for i in l)
sometrue(i<5 for i in l)
Another point is: as I agree there is already a huge lot of builtins,
shouldn't it be in some m
[Martin v. Löwis]
> I'd like to encourage feedback on whether the Windows installer works
> for people. It replaces the VBScript part in the MSI package with native
> code, which ought to drop the dependency on VBScript, but might
> introduce new incompatibilities.
[Tim Peters]
> Worked fine here.
Peter Astrand wrote:
Personally, I think Python has too many builtins already.
A suggestion was made on c.l.p a while back to have a specific module dedicated
to reductive operations. That is, just as itertools is oriented towards
manipulating iterables and creating iterators, this module would b
Anthony Baxter wrote:
On Thursday 10 March 2005 17:29, Raymond Hettinger wrote:
Or the implementation can have a switch to choose between keep-first
logic or replace logic.
The latter seems a bit odd to me. The key position would be determined
by the first encountered while the value would be dete
[ Pierre Barbier de Reuille ]:
They are called "sometrue" and "alltrue" ... IMHO, it explicits more
what it means :
alltrue(i<5 for i in l)
sometrue(i<5 for i in l)
+1
[ from a comment in GvR's blog ]
> > Why not,
> > if True in (x > 42 for x in S):
> > instead of "any" and why not
> > if not
Rodrigo Dias Arruda Senra wrote:
OFF-TOPIC:
It is curious though that we choose to read an *implicit*
True in [all(), any()] instead of an implicit False.
Actually, I think it's predicate logic's fault:
if p(x) for any x then conclusion 1
if q(x) for all x then conclusion 2
Cheers,
Nick.
--
Nic
> Even though you can use them as variables (and shadow the builtins), you
> will still get warnings from "pychecker".
So?
> The code will also be harder to
> read: When you see "all" in the middle of some code, you don't know if
> it's referring to the builtin or a variable.
Yes you do. Builtin
On Fri, 11 Mar 2005 07:19:56 -0800, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
> > Personally, I think Python has too many builtins already.
>
> It has fewer than most dynamic languages; and remember that I'm
> trading product(), any(), all() for reduce(), map() and filter().
> There are others s
Here's my take on the key issues brought up:
Alternative names anytrue(), alltrue(): before I posted to my blog I
played with these names (actually anyTrue(), allTrue(), anyFalse(),
allFalse()). But I realized (1) any() and all() read much better in
their natural context (an if statement), and the
On Thu, 2005-03-10 at 23:46, Glyph Lefkowitz wrote:
> That way instead of multi-line "except NameError" tests all over the
> place you can simply have one-liner boilerplate for every module in your
> project:
>
> 'from py24compat import *'
>
> Easy to grep/sed for when you're ready to st
Nick Coghlan wrote:
> Raymond Hettinger wrote:
>> Decorators like this should preserve information about the underlying
>> function:
>>
>>
>>>def deprecated(func):
>>>"""This is a decorator which can be used to mark functions
>>>as deprecated. It will result in a warning being
Guido van Rossum wrote:
> See my blog: http://www.artima.com/forums/flat.jsp?forum=106&thread=98196
>
> Do we even need a PEP or is there a volunteer who'll add any() and all() for
> me?
There is an interesting proposal in the forum:
"""
He proposes that
[x in list if x > 0]
(which is current
On Fri, 2005-03-11 at 06:43, Peter Astrand wrote:
> Even though you can use them as variables (and shadow the builtins), you
> will still get warnings from "pychecker". The code will also be harder to
> read: When you see "all" in the middle of some code, you don't know if
> it's referring to the
> BTW I definitely expect having to defend removing
> map/filter/reduce/lambda with a PEP; that's much more controversial
> because it's *removing* something and hence by definition breaking
> code.
I suspect that lambda will be the only bone of contention. The reduce()
function can be moved to
Raymond Hettinger wrote:
BTW I definitely expect having to defend removing
map/filter/reduce/lambda with a PEP; that's much more controversial
because it's *removing* something and hence by definition breaking
code.
+1 on the PEP
-1 on removing those tools - breaks too much code.
I suspect that la
On Fri, 2005-03-11 at 12:18, Raymond Hettinger wrote:
> I suspect that lambda will be the only bone of contention. The reduce()
> function can be moved to the functional module. The map() and filter()
> functions are already covered by the itertools module.
I'm fine seeing reduce() eventually g
On Fri, 2005-03-11 at 12:40, M.-A. Lemburg wrote:
> While I'm no fan of lambdas either, the removal would break too
> much code (e.g. I have 407 hits in the code base I use regularly
> alone).
We /are/ talking Python 3000 here, right? I'm expecting all manner of
code breakage in moving from Pyth
On Mar 11, 2005, at 17:28, Guido van Rossum wrote:
PS in the blog responses, a problem with sum() was pointed out --
unless you use the second argument, it will only work for numbers. Now
Why is that a *problem*? It solves the "end case (if the sequence is
empty" which you mention for any() and a
[Alex]
> If you're considering revisions to sum's design, my suggestion would
be
> to find a way to let the user tell sum to use a more accurate approach
> when summing floats.
FWIW, when accuracy is an issue, I use:
sum(sorted(data, key=abs))
Raymond
__
On Mar 11, 2005, at 18:18, Raymond Hettinger wrote:
str.join() is still the best practice for string concatenation.
...except you actually need unicode.join if the strings are of that
kind. Fortunately, ''.join intrinsically compensates:
>>> x=[u'\u0fe0']*2
>>> ''.join(x)
u'\u0fe0\u0fe0'
*withou
On Fri, 11 Mar 2005 19:48:45 +0100, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Which reminds me -- could we have a methodcaller relative to attrgetter
> and itemgetter? "Sort a list of strings in a case-insensitive way"
> would become *SO* easy with sort(dalist, key=methodcaller('lower'))...
> can
Barry:
> Ping's suggested list comprehension abbreviation, i.e.:
>[x in seq if x] == [x for x in seq if x]
> might help.
Note that the last x shouldn't have to be x.
[x in seq if f(x)]
is by far my most common syntax error, and
[x for x in seq if f(x)]
is always what I want in
On Mar 11, 2005, at 19:39, Raymond Hettinger wrote:
[Alex]
If you're considering revisions to sum's design, my suggestion would
be
to find a way to let the user tell sum to use a more accurate approach
when summing floats.
FWIW, when accuracy is an issue, I use:
sum(sorted(data, key=abs))
...and
Guido van Rossum:
> Whether to segregate these into a separate module: they are really a
> very small amount of syntactic sugat, and I expect that in most cases,
> instead of importing that module (which totally makes me lose my
> context while editing) I would probably just write the extra line t
On Fri, 2005-03-11 at 14:29, Jim Jewett wrote:
> Is that so bad?
>
> If you plan to use them often, then
>
> from itertools import any, every
+1
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing l
[Guido van Rossum]
> But I realized (1) any() and all() read much better in their natural
> context (an if statement), and there's no confusion there;
I do not think builtins should read good in some statement contexts and
bad in the others, or designed to be legible in only a few contexts.
This
Jim Jewett wrote:
Guido van Rossum:
[Why any() and all() shouldn't need to be imported.]
Is that so bad?
If you plan to use them often, then
from itertools import any, every
is reasonable. If you only use them once and weren't expecting it
(and want your imports at the top) ... well how awful
I would like to get some feedback on a proposal to introduce
smalltalk/ruby-like "code blocks" to python. Code blocks are, among other
things, a clean way to solve the "acquire/release" problem [1][2]. This
proposal also touches on some of the problems PEP 288 [3] deals with.
The best discuss
On Mar 11, 2005, at 2:02 PM, Steven Bethard wrote:
On Fri, 11 Mar 2005 19:48:45 +0100, Alex Martelli <[EMAIL PROTECTED]>
wrote:
Which reminds me -- could we have a methodcaller relative to
attrgetter
and itemgetter? "Sort a list of strings in a case-insensitive way"
would become *SO* easy with s
[Alex]
> > FWIW, when accuracy is an issue, I use:
> >
> >sum(sorted(data, key=abs))
>
> ...and you may still lose a LOT of accuracy that way:-(.
>
> Raymond, you technically reviewed the 2nd ed Cookbook -- don't you
> recall the sidebar about why partials are the RIGHT way to do
> summations
http://mail.python.org/pipermail/python-checkins/2005-March/045185.html
Note that I also could not build PyWin32 against 2.4.1c1 and I suspect
this was the same problem. (Still checking to see if this change fixes
the PyWin32 build for me.) In any case, this change should also make it
to the tru
[Trent Mick]
> http://mail.python.org/pipermail/python-checkins/2005-March/045185.html
>
> Note that I also could not build PyWin32 against 2.4.1c1 and I suspect
> this was the same problem. (Still checking to see if this change fixes
> the PyWin32 build for me.)
Be sure to speak up if it doesn't
Bob> try:
Bob> set
Bob> except NameError:
Bob> from sets import Set as set
Bob> You don't need the rest.
Sure, but then pychecker bitches about a statement that appears to have no
effect. ;-)
Skip
___
Python-Dev mailing
On Mar 11, 2005, at 2:26 PM, Skip Montanaro wrote:
Bob> try:
Bob> set
Bob> except NameError:
Bob> from sets import Set as set
Bob> You don't need the rest.
Sure, but then pychecker bitches about a statement that appears to
have no
effect. ;-)
Well then fix PyChecker t
[Trent Mick wrote]
>
> http://mail.python.org/pipermail/python-checkins/2005-March/045185.html
>
> Note that I also could not build PyWin32 against 2.4.1c1 and I suspect
> this was the same problem. (Still checking to see if this change fixes
> the PyWin32 build for me.
> ...
It doesn't. Investi
Guido van Rossum wrote:
Here's my take on the key issues brought up:
Alternative names anytrue(), alltrue(): before I posted to my blog I
played with these names (actually anyTrue(), allTrue(), anyFalse(),
allFalse()). But I realized (1) any() and all() read much better in
their natural context (an
Jim Jewett wrote:
Note that the last x shouldn't have to be x.
[x in seq if f(x)]
is by far my most common syntax error, and
[x for x in seq if f(x)]
is always what I want instead.
That 'x in seq' bit still shouts "containment" to me rather than iteration,
though.
Perhaps repurposing '
Hi,
Win32com generates Python-files for use with com interfaces, using the
make-py.py utility.
The generated files are OK with Python2.3.5
The generated files crash the Python interpreter with Python 2.4
Under Python 2.4.1c1, They give a syntax error!?
The files unfortunately are very big, ne
Barry Warsaw wrote:
On Fri, 2005-03-11 at 12:18, Raymond Hettinger wrote:
Lambda will be more difficult. Eric Raymond adapted an anti-gun control
slogan and said "you can pry lambda out of my cold dead hands." A bunch
of folks will sorely miss the ability to create anonymous functions on
the fly.
Anthony Baxter <[EMAIL PROTECTED]> writes:
> On Thursday 10 March 2005 03:48, Fred L. Drake, Jr. wrote:
>> > RCS file: /cvsroot/python/python/dist/src/Lib/idlelib/idlever.py,v
>> > -IDLE_VERSION = "1.1.1"
>> > +IDLE_VERSION = "1.1.1c1"
>>
>> Shouldn't this progress from 1.1.1 to 1.1.2c1? Other
[Trent Mick wrote]
> [Trent Mick wrote]
> >
> > http://mail.python.org/pipermail/python-checkins/2005-March/045185.html
> >
> > Note that I also could not build PyWin32 against 2.4.1c1 and I suspect
> > this was the same problem. (Still checking to see if this change fixes
> > the PyWin32 build f
[Trent Mick]
> Investigation has turned up that I cannot keep my Python trees straight.
> That patch *does* fix building PyWin32 against 2.4.1c1.
Good! Please send a check for US$1000.00 to the PSF by Monday .
___
Python-Dev mailing list
Python-Dev@pyth
> Win32com generates Python-files for use with com interfaces,
> using the make-py.py utility.
>
> The generated files are OK with Python2.3.5
>
> The generated files crash the Python interpreter with Python 2.4
>
> Under Python 2.4.1c1, They give a syntax error!?
>
> The files unfortunately a
On Mar 4, 2005, at 23:55, Brett C. wrote:
Evan uploaded the newest version (@ http://www.python.org/sf/1123430)
and he says it is "complete".
I should point out (very late! It's been a busy couple of weeks) that I
fully expect that there may be some issues with the patch that will
arise when it
FYI, there are a lot of ways to do accurate fp summation, but in
general people worry about it too much (except for those who don't
worry about it at all -- they're _really_ in trouble <0.5 wink>).
One clever way is to build on that whenever |x| and |y| are within a
factor of 2 of each other, x+y
[Tim Peters]
...
> One clever way is to build on that whenever |x| and |y| are within a
> factor of 2 of each other, x+y is exact in 754 arithmetic.
Ack, I'm fried. Forget that, it's wrong. The correct statement is
that x-y is always exact whenever x and y are within a factor of two
of each othe
Reinhold Birkenfeld wrote:
Nick Coghlan wrote:
A utility method on function objects could simplify this:
newFunc.update_info(func)
+1. This is really good for 90% of all decorator uses. But maybe a
better name should be found, perhaps "update_meta".
I like "update_meta"
Patch against current CVS
On Sat, 12 Mar 2005 15:31:03 +1300, Tony Meyer <[EMAIL PROTECTED]> wrote:
> > Win32com generates Python-files for use with com interfaces,
> > using the make-py.py utility.
> >
> > The generated files are OK with Python2.3.5
> >
> > The generated files crash the Python interpreter with Python 2.4
>
Brian Sabbey <[EMAIL PROTECTED]> wrote:
> I would like to get some feedback on a proposal to introduce
> smalltalk/ruby-like "code blocks" to python. Code blocks are, among other
> things, a clean way to solve the "acquire/release" problem [1][2]. This
> proposal also touches on some of the pr
Hello Folks,
I've been lurking here for several months. I've been using Python for
several years for prototyping fun. And I'm one of the architects of
its extensive use in research, engineering development, and testing on
a large, commercial speech-recognition system. I know a lot about
modelin
Jim Jewett wrote:
Guido van Rossum:
Whether to segregate these into a separate module: they are really a
very small amount of syntactic sugat, and I expect that in most cases,
instead of importing that module (which totally makes me lose my
context while editing) I would probably just write the ex
59 matches
Mail list logo
