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
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 mind it
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
words to watch
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
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 is usually
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, all
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(i5 for i in l)
sometrue(i5 for i in l)
Another point is: as I agree there is already a huge lot of builtins,
shouldn't it be in some module
[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
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
[ Pierre Barbier de Reuille ]:
They are called sometrue and alltrue ... IMHO, it explicits more
what it means :
alltrue(i5 for i in l)
sometrue(i5 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 False in (x 42
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 stop
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 emmitted
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 the
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
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
[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'
*without*
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))
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 list
[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 discussion
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
[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? I was SO
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
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 list
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 to
[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.
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
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,
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? Otherwise it's moving
[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 for me.
...
[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 wink.
___
Python-Dev mailing list
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
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
I believe
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 problems
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
42 matches
Mail list logo
