Re: [Python-Dev] any support for a methodcaller HOF?
Nick Coghlan wrote: > That's like saying "it's not the same because '(x*x def (x)' creates a > function while '(x*x for x in seq)' creates a generator-iterator". > Well, > naturally - if the expression didn't do something different, what > would be the > point in having it? ;-) Naturally. I just wanted to point out it's a beast of another kind, so like syntax may not be a good idea. > The parallel I'm trying to draw is at the syntactic level, not the > semantic. > I'm quite aware that the semantics will be very different ;) > >> Yours is >> >> f = lambda x: x*x >> >> and it will die by Guido hand... > > In the short term, probably. I'm hoping that the progressive > accumulation of > workarounds like itemgetter, attrgetter and partial (and Alex's > suggestion of > 'methodcaller') and the increasing use of function arguments for > things like > sorting and the itertools module will eventually convince Guido that > deferring > expressions is a feature that needs to be *fixed* rather than > discarded entirely. Then how about nameless function/method definition: def (x): ... usual body ... produces an unnamed method object and def spam(x): is just spam = def (x): ... while our beloved eggs(lambda x: x*x) would become eggs(def(x): return x*x) --eric ___ 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
Re: [Python-Dev] Octal literals
Bengt Richter wrote: >>The typical way of processing incoming ints in C is through >>PyArg_ParseTuple, which already has the code to coerce long->int >>(which in turn may raise an exception for a range violation). >> >>So for typical C code, 0x8004 is a perfect bit mask in Python 2.4. > > Ok, I'll take your word that 'k' coercion takes no significant time for longs > vs ints. I didn't say that 'k' takes no significant time for longs vs ints. In fact, I did not make any performance claims. I don't know what the relative performance is. > Well, I was visualizing having a homogeneous bunch of bit mask > definitions all as int type if they could fit. I can't express > them all in hex as literals without some processing. That got me started ;-) I still can't see *why* you want to do that. Just write them as hex literals the way you expect it to work, and it typically will work just fine. Some of these literals are longs, some are ints, but there is no need to worry about this. It will all work just fine. > BTW, is long mandatory for all implementations? Is there a doc that > defines minimum features for a conforming Python implementation? The Python language reference is typically considered as a specification of what Python is. There is no "minimal Python" specification: you have to do all of it. Regards, Martin ___ 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
Re: [Python-Dev] any support for a methodcaller HOF?
Eric Nieuwland wrote: > Then how about nameless function/method definition: > def (x): > ... usual body ... Hell no. If I want to write a real function, I already have perfectly good syntax for that in the form of a def statement. I want to *increase* the conceptual (and pedagogical) difference between deferred expressions and real functions, not reduce it. There's a reason I try to use the term 'deferred expression' for lambda rather than 'anonymous function'. Even if lambdas are *implemented* as normal function objects, they're a conceptually different beast as far as I'm concerned - a function is typically about factoring out a piece of common code to be used in multiple places, while a lambda is about defining *here* and *now* an operation that is to be carried out *elsewhere* and possibly *later* (e.g., sorting and predicate arguments are defined at the call site but executed in the function body, callbacks are defined when registered but executed when the relevant event occurs). > produces an unnamed method object > and > def spam(x): > > is just > spam = def (x): > ... Except that it wouldn't be - the name used in a def statement has special status that a normal variable name does not (e.g. the function knows about its real name, but nothing about the aliases given to it by assignment statements). > while our beloved > eggs(lambda x: x*x) > would become > eggs(def(x): return x*x) I personally believe this fascination with "we want to be able to include a suite inside an expression" has been a major contributor to Guido's irritation with the whole concept of anonymous functions. That may just be me projecting my own feelings though - every time I try to start a discussion about getting a clean deferred expression syntax, at least one part of the thread will veer off onto the topic of embedded suites. IMO, if what you want to do is complex enough that you can't write it using a single expression, then giving it a name and a docstring would probably make the code more comprehensible anyway. Generator expressions allow a generator to be embedded only if it is simple enough to be written using a single expression in the body of the loop. Lambda does the same thing for functions, but for some reason people seem to love the flexibility provided by genexps, while many think the exact same restriction in lambda is a problem that needs "fixing". Maybe once PEP 308 has been implemented, some of that griping will go away, as it will then be possible to cleanly embed conditional logic inside an expression (and hence inside a lambda). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
Re: [Python-Dev] any support for a methodcaller HOF?
Nick Coghlan wrote: > Hell no. If I want to write a real function, I already have perfectly good > syntax for that in the form of a def statement. I want to *increase* the > conceptual (and pedagogical) difference between deferred expressions and real > functions, not reduce it. There's a reason I try to use the term 'deferred > expression' for lambda rather than 'anonymous function'. Even if lambdas are > *implemented* as normal function objects, they're a conceptually different > beast as far as I'm concerned - a function is typically about factoring out a > piece of common code to be used in multiple places, while a lambda is about > defining *here* and *now* an operation that is to be carried out *elsewhere* > and possibly *later* (e.g., sorting and predicate arguments are defined at > the > call site but executed in the function body, callbacks are defined when > registered but executed when the relevant event occurs). Hmm. A function also defines *here* and *now* an operation to be carried out *elsewhere* and *later*. > Generator expressions allow a generator to be embedded only if it is simple > enough to be written using a single expression in the body of the loop. > Lambda > does the same thing for functions, but for some reason people seem to love > the > flexibility provided by genexps, while many think the exact same restriction > in lambda is a problem that needs "fixing". Maybe once PEP 308 has been > implemented, some of that griping will go away, as it will then be possible > to > cleanly embed conditional logic inside an expression (and hence inside a > lambda). I believe that usage of a keyword with the name of a Greek letter also contributes to people considering something broken. Regards, Martin ___ 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
Re: [Python-Dev] any support for a methodcaller HOF?
Martin v. Löwis wrote: > Hmm. A function also defines *here* and *now* an operation to be carried > out *elsewhere* and *later*. Agreed, but when I use a lambda, I almost always have a *specific* elsewhere in mind (such as a sorting operation or a callback registration). With named functions, that isn't usually the case - I'll either be returning the function from a factory function or decorator (allowing the caller to do whatever they want with it), or I'll be storing the function in a module or class namespace where any code that needs to use it can retrieve it later. Local utility functions occupy a middle ground - their usage is localised to one function or class definition, but they aren't necessarily defined just for one particular use. Using them more than once is a clear sign that they're worth naming, and the occasional need to name a complex single-use function seems a worthwhile trade-off when compared to trying to permit that complexity to be embedded inside an expression. >> Generator expressions allow a generator to be embedded only if it is simple >> enough to be written using a single expression in the body of the loop. >> Lambda >> does the same thing for functions, but for some reason people seem to love >> the >> flexibility provided by genexps, while many think the exact same restriction >> in lambda is a problem that needs "fixing". Maybe once PEP 308 has been >> implemented, some of that griping will go away, as it will then be possible >> to >> cleanly embed conditional logic inside an expression (and hence inside a >> lambda). > > I believe that usage of a keyword with the name of a Greek letter also > contributes to people considering something broken. Aye, I agree there are serious problems with the current syntax. All I'm trying to say above is that I don't believe the functionality itself is broken. At last count, Guido's stated preference was to ditch the functionality entirely for Py3k, so unless he says something to indicate he's changed his mind, we'll simply need to continue with proposing functions like methodcaller() as workarounds for its absence... Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
Re: [Python-Dev] Path PEP and the division operator
I won't even look at the PEP as long as it uses / or // (or any other operator) for concatenation. On 2/3/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > I was tinkering with something today, and wondered whether it would cause > fewer objections if the PEP used the floor division operator (//) to combine > path fragments, instead of the true division operator? > > The parallel to directory separators is still there, but the syntax isn't tied > quite so strongly to the Unix path separator. > > Cheers, > Nick. > > -- > Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia > --- > http://www.boredomandlaziness.org > ___ > 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/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] Path PEP and the division operator
On 2/4/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I won't even look at the PEP as long as it uses / or // (or any other > operator) for concatenation. That's good, because it doesn't. :) http://www.python.org/peps/pep-0355.html -- mvh Björn ___ 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
Re: [Python-Dev] Path PEP and the division operator
BJörn Lindqvist wrote: > On 2/4/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> I won't even look at the PEP as long as it uses / or // (or any other >> operator) for concatenation. > > That's good, because it doesn't. :) http://www.python.org/peps/pep-0355.html My mistake - that's been significantly updated since I last read it. I should have known better, though, as I think I was one of the people advocating use of the constructor instead of an operator. . . Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
Re: [Python-Dev] Path PEP and the division operator
BJörn Lindqvist <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > On 2/4/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> I won't even look at the PEP as long as it uses / or // (or any other >> operator) for concatenation. > > That's good, because it doesn't. :) > http://www.python.org/peps/pep-0355.html > No, but it does say that / may be reintroduced 'if the BFDL so desires'. I hope that doesn't mean the BDFL may be overruled. :^) I'm not convinced by the rationale given why atime,ctime,mtime and size are methods rather than properties but I do find this PEP much more agreeable than the last time I looked at it. ___ 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
Re: [Python-Dev] any support for a methodcaller HOF?
Martin v. Löwis wrote: > I believe that usage of a keyword with the name of a Greek letter also > contributes to people considering something broken. QOTW! ;-) --eric ___ 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
Re: [Python-Dev] any support for a methodcaller HOF?
Nick Coghlan wrote: >> I believe that usage of a keyword with the name of a Greek letter also >> contributes to people considering something broken. > > Aye, I agree there are serious problems with the current syntax. All > I'm > trying to say above is that I don't believe the functionality itself > is broken. Lambda is not broken, it's restricted to single calculation and therefore of limited use. Although I wasn't too serious (should had added more signs of that), an anonymous 'def' would allow to use the full power of method definition. > At last count, Guido's stated preference was to ditch the functionality > entirely for Py3k, so unless he says something to indicate he's > changed his > mind, we'll simply need to continue with proposing functions like > methodcaller() as workarounds for its absence... Yep, we'll just have to learn to live without it. :-( / ;-) --eric ___ 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
[Python-Dev] Path PEP: some comments
Hello,
my comments on the Path PEP:
- Many methods contain the word 'path' in them. I suppose this is to help
transition from the old library to the new library. But in the context of a
new Python user, I don't think that Path.abspath() is optimal. Path.abs()
looks better. Maybe it's not so fundamental to have exactly the same names
of the old library, especially when thinking of future? If I rearrange my
code to use Path, I can as well rename methods to something more sound at
the same time.
- Why having a basename() and a .namebase property? Again for backward
compatibility? I guess we can live with the property only.
- The operations that return list of files have confusing names. Something
more orthogonal could be: list, listdirs, listfiles / walk, walkdirs,
walkfiles. Where, I guess, the first triplet does not recurse into subdirs
while the second does. glob() could be dropped (as someone else proposed).
- ctime() is documented to be unportable: it has different semantics on UNIX
and Windows. I believe the class should abstract from these details. One
solution is to rip it off and forget about it. Another is to provide two
different functions which have a fixed semantic (and possibly available only
a subset of the operating systems / file systems).
- remove() and unlink() are duplicates, I'd drop one (unlink() has a more
arcane name).
- mkdir+makedirs and rmdir+removedirs are confusing and could use some
example. I believe it's enough to have a single makedir() (which is
recursive by default) and a single remove() (again recursive by default, and
could work with both files and directories). rmtree() should go for the same
reason (duplicated).
- Whatever function we comes out with for removing trees, it should have a
force=True flag to mimic "rm -rf". That is, it should try to remove
read-only files as well. I saw so many times people writing their own
rmtree_I_mean_it() wrapper which uses the onerror callback to change the
permissions. That's so unpythonic for such a common task.
- copy/copy2/copyfile mean the same to me. copy2() is really a bad name
though, I'd use copy(stats=True).
- My own feeling on the controversial split() vs splitpath() is that split()
is always wrong for paths so I don't see nothing fundamentally wrong in
overwriting it. I don't expect to find existing code (using strings for
path) calling split() on a path. split("/") might be common though, and in
fact my proposal is to overwrite the zero-argument split() giving it the
meaning of split("/").
- I'm missing read(), write(), readlines() and bytes() from the original
Path class. When I have a Path() that points to a file, it's pretty common
to read from it. Those functions were handy because they were saving much
obvious code:
for L in Path("foo.txt").readlines():
print L,
===>
f = open(Path("foo.txt"), "rU")
try:
for L in f:
print L
finally:
f.close()
- Since we're at it, we could also move part of "fileinput" into Path. For
instance, why not have a replacelines() method:
import fileinput
for L in fileinput.FileInput("foo.txt", inplace=True, backup=True):
print "(modified) " + L,
>
for L in Path("foo.txt").replacelines(backup=True):
print "(modified) " + L,
Thanks for working on this!
--
Giovanni Bajo
___
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
Re: [Python-Dev] Path PEP: some comments
At 08:35 PM 2/4/2006 +0100, Giovanni Bajo wrote: >- ctime() is documented to be unportable: it has different semantics on UNIX >and Windows. I believe the class should abstract from these details. Note that this is the opposite of normal Python policy: Python does not attempt to create cross-platform abstractions, but instead chooses to expose platform differences. The Path class shouldn't abstract this any more than the original *path modules do. > One >solution is to rip it off and forget about it. Another is to provide two >different functions which have a fixed semantic (and possibly available only >a subset of the operating systems / file systems). Keep in mind that to properly replace os.path, each of the various *path modules will need their own Path variant to support foreign path manipulation. For example, one can use posixpath.join() right now on Windows to manipulate Posix paths, and ntpath.join() to do the reverse on Unix. So there is already going to have to be a Path class for each os anyway - and they will all need to be simultaneously usable. Note that this is a big difference from the Path implementation currently in circulation, which is limited to processing the native OS's paths. The PEP also currently doesn't address this point at all; it should probably mention that each of the posixpath, ntpath, macpath, etc. modules will each need to include a Path implementation. Whether this should be made available as os.Path or os.path.Path is the only open question; the latter of course would be automatic by simply adding a Path implementation to each of the *path modules. ___ 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
[Python-Dev] Path PEP -- a couple of typos.
Here are a couple of simple-minded fixes for the PEP.
Near the bottom of "Replacing older functions with the Path class":
>fname = Path("Python2.4.tar.gz")
>base, ext = fname.namebase, fname.extx
Surely this should be:
base, ext = fname.namebase, fname.ext
>lib_dir = "/lib"
>libs = glob.glob(os.path.join(lib_dir, "*s.o"))
>==>
>lib_dir = Path("/lib")
>libs = lib_dir.files("*.so")
Probably that should be:
...
libs = glob.glob(os.path.join(lib_dir, "*.so"))
...
--Scott David Daniels
[EMAIL PROTECTED]
___
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
Re: [Python-Dev] Path PEP: some comments
Phillip J. Eby <[EMAIL PROTECTED]> wrote: >> - ctime() is documented to be unportable: it has different semantics >> on UNIX and Windows. I believe the class should abstract from these >> details. > > Note that this is the opposite of normal Python policy: Python does > not attempt to create cross-platform abstractions, but instead > chooses to expose platform differences. The Path class > shouldn't abstract this > any more than the original *path modules do. I don't follow. One thing is to provide an interface which totally abstracts from low-level details. Another is to provide a function which holds different results depending on the operating system. I'm fine to have different functions available for different purposes on different platforms, I'm not fine with having a single function which does different things. Do you have any other example? Giovanni Bajo ___ 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
Re: [Python-Dev] Path PEP and the division operator
Duncan Booth wrote: > I'm not convinced by the rationale given why atime,ctime,mtime and size are > methods rather than properties but I do find this PEP much more agreeable > than the last time I looked at it. A better rationale for doing it is that all of them may raise IOException. It's rude for properties to do that, so it's better to make them methods instead. That was a general guideline that came up the first time adding Path was proposed - if the functionality involved querying or manipulating the actual filesystem (and therefore potentially raising IOError), then it should be a method. If the operation related solely to the string representation, then it could be a property. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
Re: [Python-Dev] any support for a methodcaller HOF?
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hell no. If I want to write a real function, I already have perfectly > good > syntax for that in the form of a def statement. I want to *increase* the > conceptual (and pedagogical) difference between deferred expressions and > real > functions, not reduce it. Mathematically, a function is a function. Expressions and statements are two syntaxes for composing functions to create/define new functions. A few languages use just one or the other. Python intentionally uses both. But I think making an even bigger deal of surface syntax is exactly the wrong movement, especially pedagogically. Terry Jan Reedy ___ 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
Re: [Python-Dev] Path PEP: some comments
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Note that this is the opposite of normal Python policy: Python does not > attempt to create cross-platform abstractions, but instead chooses to > expose platform differences. I had the opposite impression about Python -- that it generally masks such differences. Overall, I see it as a cross-platform abstraction. The requirement that ints be at least 32 bits masked the difference between 16-bit int and 32-bit int platforms, in a way that C did/does not. I am pretty sure that Tim Peters has said that he would welcome better uniformity in binary float computations, but that he won't do the work needed. The decimal package attempts to completely mask the underlying platform. Cross-platform guis, whether written in Python or just accessible from Python, also mask differences. The os module has names like sep and pathsep precisely so people can more easily write platform independent code. And so on. ___ 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
Re: [Python-Dev] any support for a methodcaller HOF?
Terry Reedy wrote: > "Nick Coghlan" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> Hell no. If I want to write a real function, I already have perfectly >> good >> syntax for that in the form of a def statement. I want to *increase* the >> conceptual (and pedagogical) difference between deferred expressions and >> real >> functions, not reduce it. > > Mathematically, a function is a function. Expressions and statements are > two syntaxes for composing functions to create/define new functions. A few > languages use just one or the other. Python intentionally uses both. But > I think making an even bigger deal of surface syntax is exactly the wrong > movement, especially pedagogically. I guess I misstated myself slightly - I've previously advocated re-using the 'def' keyword, so there are obviously parallels I want to emphasize. I guess my point is that expressions are appropriate sometimes, functions are appropriate other times, and it *is* possible to give reasonably simple guidelines as to which one is most appropriate when (one consumer->deferred expression, multiple consumers->named function). I see it as similar to the choice of whether to use a generator function or generator expression in a given situation. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
