Python-ideas April 2010

python-ideas@python.org

56 participants
27 discussions

by cool-RR

Just something small that I thought of, and I haven't thought about this deeply at all, so maybe this is way wrong. But: What about adding a `Reversable` next to all the `Iterable` and `Container` and stuff? (Please `cc` any replies to me, I'm not getting mail from this list.) Ram.

10 years, 7 months

math.fsum: summing multiple running sums at once

by Ilya Shlyakhter

A suggestion: extend math.fsum to accept an iterable that yields tuples of floats, and returns a tuple of sums. This would permit summing multiple running sums at once (e.g. keeping both a sum and a sum-of-squares for computing standard deviation from an iterable), or summing a stream of complex numbers. An alternative would be to make an object-oriented version of fsum that has a method for adding a number to the sum; then an array of such objects could be used to sum multiple iterables simultaneously. It would also be good if other methods based on fsum were included in the standard library, e.g. for accurately computing the mean and stddev of an iterable. Thanks, ilya

10 years, 7 months

why has itertools.imap other semantics as the bultin map?

by Mathias Panzenböck

See: >>> map(None,['a','b'],[]) [('a', None), ('b', None)] >>> list(imap(None,['a','b'],[])) [] Why is that? I propose that imap should work like map (except from being a generator, of course). System Info: Python 2.6.2 (r262:71600, Jan 25 2010, 18:46:47) [GCC 4.4.2 20091222 (Red Hat 4.4.2-20)] on linux2 -panzi

10 years, 7 months

Why no sign function?

by cool-RR

This was probably discussed a lot. Why is there no simple `sign` function in Python, like in the math module or something? I mean one that tells you the sign of a number. Ram.

10 years, 7 months

Re: [Python-ideas] Anaphoric if

by Jess Austin

On Fri, Apr 23, 2010 at 3:47 PM, Andrey Fedorov <anfedorov(a)gmail.com> wrote: > I imagine this has been covered before, but somehow my Google-foo is > failing. What are people's opinions about having an anaphoric-if syntax > sugar like: > > if foo() as x: > ... x > > > meaning > > x = foo() > if x: > ... x > I like this, and I'd like for it to be in python, although I don't think it will be widely supported because it only saves one line, and the idiom it replaces isn't very common. [Which facts didn't prevent the adoption of '@' decorator syntax, but I digress...] A question for the sake of completeness: would the following: if not foo() as x: ... x mean this: x = foo() if not x: ... x cheers, Jess

10 years, 7 months

Anaphoric if

by Andrey Fedorov

I imagine this has been covered before, but somehow my Google-foo is failing. What are people's opinions about having an anaphoric-if syntax sugar like: if foo() as x: ... x meaning x = foo() if x: ... x ? I do this a lot, and it seems very un-Pythonically verbose to repeat "x" (especially when a longer variable name is appropriate). Cheers, Andrey

10 years, 7 months

Re: [Python-ideas] Anaphoric if

by Bruce Leban

def anaphor(x): return (x,) if x else () for foo in anaphor(bar): ... --- Bruce (via android) On Apr 23, 2010 4:18 PM, "Chris Rebert" <pyideas(a)rebertia.com> wrote: On Fri, Apr 23, 2010 at 1:47 PM, Andrey Fedorov <anfedorov(a)gmail.com> wrote: > I imagine this has be... Master Yoda had me google "python-ideas if assignment", which was fruitful: [Python-ideas] Inline assignment expression: http://mail.python.org/pipermail/python-ideas/2009-March/003423.html Post in same thread summarizing rejection reasons: http://mail.python.org/pipermail/python-ideas/2009-March/003440.html Cheers, Chris -- The moratorium makes this pointless anyways. http://blog.rebertia.com _______________________________________________ Python-ideas mailing list Python-ideas(a)python.org ht...

10 years, 7 months

Re: [Python-ideas] Small enhancement to os.path.splitext

by Bruce Leban

Also note that there are really THREE variations: Case sensitive (Unix/mac normally) Case preserving (windows normally) Case insensitive (some legacy fs) IMHO gcc treating .c and .C is annoying. I usually get .JPG instead of .jpg when windows apps pick the extension for me. Also annoying. Notwithstanding that you can't do case insensitive compare without knowing the file system locale otherwise .GIF != .gif. So this is a mess. Furthermore it's not just extensions. Some names are conventionally case sensitive. And if I write #include "foo.h" and have foo.h and FOO.h you better get the right one. If I'm filtering unsafe filetypes are .EXE and .PL unsafe? Probably most useful is to provide access to fs locale and case sensitivety mode and leave rest for now. --- Bruce (via android) On Apr 23, 2010 4:49 AM, "Paul Moore" <p.f.moore(a)gmail.com> wrote: On 23 April 2010 12:34, Lie Ryan <lie.1296(a)gmail.com> wrote: > On 04/23/10 17:50, Paul Moore wrote: ... :-) Good point. Which I guess boils down to saying that if there's no consensus, then nothing should be added to the stdlib (which is a conclusion I'm happy with). Paul. _______________________________________________ Python-ideas mailing list Python-ideas(a)python.org ht...

10 years, 7 months

Re: [Python-ideas] Small enhancement to os.path.splitext

by Paul Moore

Sorry, should have gone to the list. On 23 April 2010 01:53, Greg Ewing <greg.ewing(a)canterbury.ac.nz> wrote: > I still don't think you can decide based on the file > system behaviour. What if the user creates his files on > a case-insensitive system and then copies them to a > case-sensitive one or vice versa? The intended meaning > of the extensions doesn't suddenly change when that > happens. I don't know if you actually use case insensitive filenames regularly (an odd question that, in "normal life" I'd immediately assume 99.99% of people I meet use Windows, but on this list, I tend to assume most people use Unix/Linux or Mac - sorry if my assumption's mistaken) but personally, as a Windows user, I try to keep filename case the way I want it, but I'd tend to double check if moving files to a case sensitive system. But - and this is the key point here for me - the filenames I *type* at the command line often don't match the case on the filesystem (because I'm too lazy to hit the shift key when I know it doesn't matter, for example) and so my expectations very much are based on filesystem case sensitivity, and what's more, it's what I type that's unreliable. As far as I am concerned, any behaviour that relies on filenames differing only in case being handled differently is wrong on Windows. (Yes, that includes gcc's behaviour). All programs should work case insensitively in all cases when dealing with files. Simple. That's my view as a Windows user. I rationalise it as being based on the case sensitivity of the filesystem, but I'll admit I have no experience with using case sensitive filesystems on Windows (for all practical purposes, they don't exist). I also have limited experience with Unix, and all my Unix experience is in situations where all the filesystems are case sensitive. So arguably, my position is Unix == case sensitive, Windows = case insensitive, and a simple switch on sys.platform would work for me. But desktop Linux systems need to deal with such things as FAT32-formatted USB disks, Samba filesystems, etc. And I have no good intuition on how they should be handled. So I fall back on my original rationalisation, that the filesystem behaviour is what matters. So to summarise: * Case sensitivity behaviour determined by host OS would work for me * But it "feels" wrong * Case sensitive everywhere is completely wrong (as it ignores Windows users' expectations) * Choosing a default based on filesystem behaviour is logical, but hard, and there may be no real requirement for it Also, making the user choose every time (for example, GNU find with its -name and -iname options) is not a helpful or portable approach (e.g., I want find . -name *.sql to find all SQL scripts, regardless of platform). Cross-platform tools with a strong focus on file and filename semantics (for example, DVCSs such as Mercurial) have specialist needs, and probably should always write custom code. But for "quick" scripts, something in the standard library which made doing the "right" thing easy would be a huge help. Paul

10 years, 7 months

Re: [Python-ideas] Small enhancement to os.path.splitext

by Bruce Leban

When would you know in advance you want 2 parts? Compare file.tar.gz to backup.2010.04.20.tar. I'd think the usual case would be split if gz or zip or...: split again --- Bruce (via android) On Apr 20, 2010 8:36 AM, "Tarek Ziadé" <ziade.tarek(a)gmail.com> wrote: Hello Currently, os.path.splitext will split a string giving you the piece behind the last dot: >>> os.path.splitext('file.tar.gz') ('file.tar', '.gz') In some cases, what we really want is the two last parts when splitting on the dots (like in my example). What about providing an extra argument to be able to grab more than one dot ? >>> os.path.splitext('file.tar.gz', numext=2) ('file', '.tar.gz') If numext > numbers of dots, it will just split after the first dot: >>> os.path.splitext('file.tar', numext=2) ('file', '.tar') What do you think ? Regards Tarek -- Tarek Ziadé | http://ziade.org _______________________________________________ Python-ideas mailing list Python-ideas(a)python.org http://mail.python.org/mailman/listinfo/python-ideas

10 years, 7 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Python-ideas April 2010