Re: [Python-Dev] Compiling Python with Intel compiler?
On Tue, 14 Jun 2005, "Martin v. Löwis" wrote: > Guido van Rossum wrote: >> Intel has a free (as in beer) C compiler for Linux. A friend of mine >> is involved in its production and marketing. He would like to see how >> "his" compiler does on Python -- does it work at all, and is there a >> speedup? > > There is a bug report on this compiler: python.org/sf/1162001 > There is also a patch, python.org/sf/1162023 which works around > the bug. I don't like the work-around, because it assumes that the > compiler binary is called "icc", however, it might be called just > "cc" on some installations. I submitted this bug, patch, and the c.l.p posting and thank Martin for his help with them all. Martin's reservations on the workaround are correct but I can't make more time right now to fix autoconf "properly." To be honest, if icc were more gcc-compatible and returned an error code for -OPT:Olimit=0, that would obviate the need for any patch to Python. I never published these results before but here's what I found in terms of performance (full results available on request): $ python pybench.py -s icc-python -c fedora-python | tail -n 4 Average round time:3677.00 ms -15.95% *) measured against: fedora-python (rounds=10, warp=20) $ python pybench.py -s icc-xN-python -c fedora-python | tail -n 4 Average round time:3911.00 ms -10.61% *) measured against: fedora-python (rounds=10, warp=20) fedora-python: Python 2.4/GCC 3.4.2 20041017 from python.org yum repository icc-python: Python 2.4/icc (8.1) -pthread -fno-strict-aliasing -DNDEBUG -O3 icc-python-xN: Python2.4/icc (8.1) -pthread -fno-strict-aliasing -DNDEBUG -O3 -xN Intel Pentium 4 2.66GHz; 512 KB cache; 507644 kB RAM; Linux 2.6.11-1.14_FC3 While a 16% speedup is nothing to sneeze at, I felt I wasted a lot of time dealing with incompatibilities with extension modules and libcprts.so, and so I no longer run it on my desktop. I do use it for heavy computes on our compute farm when I'm not using extension modules. [Guido] > I think that if someone puts some time in this, they should get a > free Intel T-shirt. I'll accept a free Intel T-shirt if one is offered but I'll probably pass it on to our long-suffering sysadmins who have spent even more time dealing with icc, yet remain evangelists for it. Since this was my first message to python-dev, I think the custom is to introduce myself. I'm a PhD student at the University of Cambridge studying computational biology. I've been using Python for the last three years and have loved almost every minute of it. I've written sequence alignment algorithms in Pyrex, glue to genome database APIs in Jython, and a whole lot of other stuff using CPython. We run Python on a 1145-CPU compute farm that consists of Alpha/Tru64 and Intel/Linux boxes. -- Michael Hoffman <[EMAIL PROTECTED]> European Bioinformatics Institute ___ 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] Pre-PEP: The "bytes" object
[Neil Schemenauer] >> @classmethod >> def fromhex(self, data): >> data = re.sub(r'\s+', '', data) >> return bytes(binascii.unhexlify(data)) [Jason Orendorff] > If it's to be a classmethod, I guess that should be "return self( > binascii.unhexlify(data))". Am I the only one who finds the use of "self" on a classmethod to be incredibly confusing? Can we please follow PEP 8 and use "cls" instead? -- Michael Hoffman <[EMAIL PROTECTED]> European Bioinformatics Institute ___ 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] iterator API in Py3.0
Another nice thing about having a next() built-in is that it makes getting the first item of a generator expression a lot more elegant, IMHO. I think this: next(item for item in items if item > 3) is a lot clearer than this: (item for item in items if item > 3).next() or alternatives that would break this into multiple statements. [inspired by a recent python-list question] -- Michael Hoffman <[EMAIL PROTECTED]> European Bioinformatics Institute ___ 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] Adding the 'path' module (was Re: Some RFE for review)
On Sun, 26 Jun 2005, Phillip J. Eby wrote: > * drop getcwd(); it makes no sense on a path instance Personally I use path.getcwd() as a class method all the time. It makes as much sense as fromkeys() does on a dict instance, which is technically possible but non-sensical. > And, assuming these file-content methods are kept: > > * path.bytes() -> path.get_file_bytes() > * path.write_bytes() -> path.set_file_bytes() and path.append_file_bytes() > * path.text() -> path.get_file_text() > * path.write_text()-> path.set_file_text() and path.append_file_text() > * path.lines() -> path.get_file_lines() > * path.write_lines() -> path.set_file_lines() and path.append_file_lines() I don't know how often these are used. I don't use them myself. I am mainly interested in this module so that I don't have to use os.path anymore. Reinhold Birkenfeld wrote: > One more issue is open: the one of naming. As "path" is already the > name of a module, what would the new object be called to avoid > confusion? pathobj? objpath? Path? I would argue for Path. It fits with the recent cases of: from sets import Set from decimal import Decimal -- Michael Hoffman <[EMAIL PROTECTED]> European Bioinformatics Institute ___ 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] Adding the 'path' module (was Re: Some RFE for review)
On Sun, 26 Jun 2005, Phillip J. Eby wrote: > At 08:19 PM 6/26/2005 +0100, Michael Hoffman wrote: >> On Sun, 26 Jun 2005, Phillip J. Eby wrote: >> >>> * drop getcwd(); it makes no sense on a path instance >> >> Personally I use path.getcwd() as a class method all the time. It >> makes as much sense as fromkeys() does on a dict instance, which is >> technically possible but non-sensical. > > It's also duplication with os.path; I'm -1 on creating a new staticmethod > for it. os.getcwd() returns a string, but path.getcwd() returns a new path object. Almost everything in path is a duplication of os.path--the difference is that the path methods start and end with path objects. -- Michael Hoffman <[EMAIL PROTECTED]> European Bioinformatics Institute ___ 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] Adding the 'path' module (was Re: Some RFE for review)
On Mon, 27 Jun 2005, Phillip J. Eby wrote:
> At 08:20 AM 6/27/2005 +0100, Michael Hoffman wrote:
>> os.getcwd() returns a string, but path.getcwd() returns a new path
>> object.
>
> In that case, I'd expect it to be 'path.fromcwd()' or 'path.cwd()'; i.e. a
> constructor classmethod by analogy with 'dict.fromkeys()' or
> 'datetime.now()'. 'getcwd()' looks like it's getting a property of a path
> instance, and doesn't match stdlib conventions for constructors.
>
> So, +1 as long as it's called cwd() or something better (i.e. clearer
> and/or more consistent with stdlib constructor conventions).
+1 on cwd().
-1 on making this the default constructor. Essentially the default
constructor returns a path object that will reflect the CWD at the
time that further instance methods are called.
path.cwd() will return a path object that reflects the path at the
time of construction.
This example may be instructive:
>>> from path import path
>>> import os
>>>
>>> default_path = path()
>>> getcwd_path = path.getcwd()
>>> default_path.abspath()
path('/home/hoffman')
>>> getcwd_path.abspath()
path('/home/hoffman')
>>>
>>> os.chdir("etc")
>>> default_path.abspath()
path('/home/hoffman/etc')
>>> getcwd_path.abspath()
path('/home/hoffman')
Unfortunately only some of the methods work on paths created with the
default constructor:
>>> path().listdir()
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/site-packages/path.py", line 297, in listdir
names = os.listdir(self)
OSError: [Errno 2] No such file or directory: ''
Is there support to have all of the methods work when the path is the
empty string? Among other benefits, this would mean that sys.path
could be turned into useful path objects with a simple list
comprehension.
--
Michael Hoffman <[EMAIL PROTECTED]>
European Bioinformatics Institute
___
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] Adding the 'path' module (was Re: Some RFEforreview)
On Wed, 29 Jun 2005, Tony Meyer wrote: > Maybe this has already been answered somewhere (although I don't > recall seeing it, and it's not in the sourceforge tracker) but has > anyone asked Jason Orendorff what his opinion about this (including > the module in the stdlib) is? I e-mailed Jason earlier this week before submitting the RFE. He said that "I'd like to see path (or something like it) in the standard library." He also said he didn't have time to write a PEP at the moment, but that I should feel free to do so. As for me, I'm happy for Reinhold to do it if he wants. -- Michael Hoffman <[EMAIL PROTECTED]> European Bioinformatics Institute ___ 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] partition() (was: Remove str.find in 3.0?)
[Shane Hathaway writes about the existence of both module-level functions and object methods to do the same regex operations] > Apparently Python believes TMTOWTDI is the right practice here. ;-) > See search, match, split, findall, finditer, sub, and subn: > > http://docs.python.org/lib/node114.html > http://docs.python.org/lib/re-objects.html Dare I ask whether the uncompiled versions should be considered for removal in Python 3.0? *puts on his asbestos jacket* -- Michael Hoffman <[EMAIL PROTECTED]> European Bioinformatics Institute ___ 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] Replacement for print in Python 3.0
On Thu, 1 Sep 2005, Jack Diederich wrote: > On Thu, Sep 01, 2005 at 11:12:57PM +0200, Fredrik Lundh wrote: >> yeah, real programmers don't generate output. >> > I'd say: > yeah, real programmers don't generate output _to stdout_ > > sockets, GUI widgets, buffers? sure. stdout? Almost never. Almost every program I write produces its output mainly to stdout. And I probably use print half the time to produce this output (the rest is done mostly with csv). GUI widgets? Who needs 'em? -- Michael Hoffman <[EMAIL PROTECTED]> European Bioinformatics Institute ___ 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] Directory for packages maintained outside the core (was Re: ElementTree - Why not part of the core?)
[Hye-Shik Chang] >> I think "contrib" is somewhat conventional for the purpose. [Steve Holden] > Indeed, but conventionally *all* code in the Python core is contributed, > and I think we need a name that differentiates externally-maintained > packages from the contributions that are integrated into the core and > maintained as part of it. The same could be said of a lot of other projects that use the "contrib" convention. I have a much better idea of what "contrib" means than "kits" or "external." -- Michael Hoffman <[EMAIL PROTECTED]> European Bioinformatics Institute ___ 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] PEP 8 updates/clarifications
[Ian Bickling] >> stdlib, external modules, internal modules seems like enough >> ordering to me. [Jim Fulton] > Personally, I don't find the stdlib/external distinction to be useful. It's useful because it allows one to quickly see all the prerequisites need to be installed in one place. -- Michael Hoffman <[EMAIL PROTECTED]> European Bioinformatics Institute ___ 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] PEP 8 updates/clarifications
[Jim Fulton] >>> Personally, I don't find the stdlib/external distinction to be useful. [Michael Hoffman] >> It's useful because it allows one to quickly see all the prerequisites >> need to be installed in one place. [Jim Fulton] > Sure, if you only have one module, and if your module doesn't do any > dynamic imports, and if the things your importing don't have dependencies, > and ... > > I think it would be simpler to have a formal dependency system. More useful, yes, for all the reasons you listed. The fact that people are still working on a formal dependency system, however, indicates that it is not simpler. -- Michael Hoffman <[EMAIL PROTECTED]> European Bioinformatics Institute ___ 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] PEP 8 updates/clarifications, function/method style
[Wolfgang] > Or should we switch to camelCase with lowercase first letter ? > As most other Languages prefer this (Java, C#, C++, ...) They also use curly braces instead of indentation to indicate block structure. Maybe we should switch to that too. -- Michael Hoffman <[EMAIL PROTECTED]> European Bioinformatics Institute ___ 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] The path module PEP
[Ian Bickling] > I'm personally +1 on /. I think people who think it is confusing are > giving a knee-jerk reaction. It's very easy to tell the difference > between file-related code and math-related code, and / is currently only > used for math. In contrast, + is used for concatenation and addition, > and these are far more ambiguous from context -- but still it doesn't > cause that many problems. I was initially -0 on / but I have found it quite useful and a lot simpler than a lot of joinpath()s over time. So +1 on / for me. -- Michael Hoffman <[EMAIL PROTECTED]> European Bioinformatics Institute ___ 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] The path module PEP
[Tony Meyer] > It would be great (and save a lot of rehashing) if you could go over > the python-dev discussion and add the relevant parts (for example, > whether to include the __div__ hack) to the PEP: > > <http://mail.python.org/pipermail/python-dev/2005-June/054439.html> In particular the points about Path being able to be a drop-in replacement for str/unicode are useful ones, and explain the use of joinpath() etc. It is really useful that I can use a Path anywhere I might have used an str and not have to worry about the conversions. -- Michael Hoffman <[EMAIL PROTECTED]> European Bioinformatics Institute ___ 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] The path module PEP
[Charles Cazabon] > It screams "magic" in a very un-Pythonic (and possibly very > Perl-like) way. I'm not aware of any other part of the standard > library grossly abusing standard operators in this way. I think the use of the modulo operator for string substitution is pretty comparable, despite it being in the interpreter rather than in the stdlib. And some of us have come to love that, too. -- Michael Hoffman <[EMAIL PROTECTED]> European Bioinformatics Institute ___ 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] The path module PEP
[Thomas Wouters] >> This issue has been brought up before when people were discussing the >> path module. I think the consensus is that, while the inheritance >> isn't pure, practicality beats purity. It would require to big changes >> to Python and would break to much existing code to not extend string. > > This is my only problem with the PEP. It's all very nice that subclassing > from string makes it easier not to break things, but subclassing implies a > certain relationship. This is the soul of arguing for purity's sake when practicality would dictate something else. If you remove the basestring superclass, then you remove the ability to use path objects as a drop-in replacement for any path string right now. You will either have to use str(pathobj) or carefully check that the function/framework you are passing the path to does not use isinstance() or any of the string methods that are now gone. http://groups.google.com/group/comp.lang.python/browse_thread/thread/1f5bcb67c4c73f15 -- Michael Hoffman <[EMAIL PROTECTED]> European Bioinformatics Institute ___ 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] The path module PEP
[Thomas Wouters] >>> [Subclassing string] is my only problem with the PEP. It's all very nice >>> that subclassing from string makes it easier not to break things, but >>> subclassing implies a certain relationship. [Michael Hoffman] >> This is the soul of arguing for purity's sake when practicality would >> dictate something else. [Thomas Wouters] > If we're going to argue that point, I don't believe this is the practicality > that the 'zen of python' talks about. Practicality is the argument for > 'print', and for requiring the ':' before suites, and for some of the > special cases in the Python syntax and module behaviour. It isn't about the > implementation. The argument to subclass string is, as far as I can tell, > only the ease of implementation and the ease of transition. Nothing in the > old thread convinced me otherwise, either. I've never seen Guido go for an > implementation-practical solution just because he couldn't be arsed to do > the work to get a conceptually-practical solution. And subclassing string > isn't conceptually-practical at all. I don't understand what "conceptually-practical" is or how it differs from "conceptually pure" which is what it seems that you're looking for. It's not hard to give Path a has-a relationship to basestring instead of an is-a relationship, so it really doesn't save much in terms of implementation. >> If you remove the basestring superclass, then you remove the ability >> to use path objects as a drop-in replacement for any path string right >> now. You will either have to use str(pathobj) or carefully check that >> the function/framework you are passing the path to does not use >> isinstance() or any of the string methods that are now gone. > > More to the point, you will have to carefully check whether the > function/framework will use the Path object in a way the Path object can > handle. There's already discussion about whether certain methods should be > 'disabled', in Path objects, or whether they should be doing something > conceptually different. Yes, and I think all of this discussion is focused on conceptual purity and misses one of the big wins of the Path module for current users--it can be trivially used anywhere where a str is expected today. If you're going to start deciding that certain str methods should be disabled for some reason, then it shouldn't be a str subclass, because it will no longer behave like string-plus. In previous discussions, string methods were identified that one programmer thought would not be useful on a path, but others disagreed. Disabling methods serves no useful purpose, except to shorten dir(). I've been using path.py for some time, and I can tell you that it would be a lot less useful if it no longer behaved like string-plus. -- Michael Hoffman <[EMAIL PROTECTED]> European Bioinformatics Institute ___ 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
