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)
Michael Hoffman wrote: 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. +1. Reinhold -- Mail address is perfectly valid! ___ 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] Some RFE for review
Reinhold Birkenfeld wrote: 1152248: In order to read records separated by something other than newline, file objects should either support an additional parameter (the separator) to (x)readlines(), or gain an additional method which does this. Review: The former is a no-go, I think, because what is read won't be lines. The latter is further complicating the file interface, so I would follow the principle that not every 3-line function should be builtin. As Douglas Alan's sample implementation (and his second attempt [1]) show, getting this right (and reasonably efficient) is actually a non-trivial exercise. Leveraging the existing xreadlines infrastructure is an idea worth considering. I think it's worth leaving this one open, and see if someone comes up with a patch (obviously, this was my opinion from the start, or I wouldn't have raised the RFE in response to Douglas's query!) Cheers, Nick. [1] http://mail.python.org/pipermail/python-list/2005-February/268547.html -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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] Some RFE for review
On 6/27/05, Nick Coghlan [EMAIL PROTECTED] wrote: As Douglas Alan's sample implementation (and his second attempt [1]) show, getting this right (and reasonably efficient) is actually a non-trivial exercise. Leveraging the existing xreadlines infrastructure is an idea worth considering. I think it's worth leaving this one open, and see if someone comes up with a patch (obviously, this was my opinion from the start, or I wouldn't have raised the RFE in response to Douglas's query!) As a more general approach, would it be worth considering an addition to itertools which took an iterator which generated blocks of items, and split them on a subsequence? It's a generalisation of the basic pattern here, and would be able to encapsulate the fiddly what if a separator overlaps a block split logic without locking it down to string manipulation... Or does that count as overgeneralisation? Paul. ___ 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] Some RFE for review
[Paul Moore on readline getting a record separator argument] As a more general approach, would it be worth considering an addition to itertools which took an iterator which generated blocks of items, and split them on a subsequence? Nope. Assign responsibility to the class that has all of the relevant knowledge (API for retrieving blocks, type of the retrieved data, how EOF is detected, etc). It's a generalisation of the basic pattern here, and would be able to encapsulate the fiddly what if a separator overlaps a block split logic without locking it down to string manipulation... How do you build, scan, and extract the buffer in a type independent manner? Are there any use cases for non-string data buffers, a stream of integers or somesuch? Raymond ___ 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)
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). ___ 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)
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). You're right. +1 for calling it fromcwd(). With that settled, should I rewrite the module? Should I write a PEP? Reinhold -- Mail address is perfectly valid! ___ 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] subprocess.call() and stdin
Stuart Bishop writes: When I invoke subprocess.call(), I often want to ensure that the subprocess' stdin is closed. This ensures it will die if the subprocess attempts to read from stdin rather than block. This could be done if the subprocess.call() helper closes the input if stdin=subprocess.PIPE, which may be the only sane way to handle this argument (I can't think of any use cases for spawning a subprocess with an input stream that nothing can write too). +0.5. I agree that if you pass stdin=subprocess.PIPE to subprocess.call() that the current behavior of having the child process block forever is totally useless. I have little reason to prefer assume an empty input over let subprocess.call() raise an exception if stdin==subprocess.PIPE -- but if I take your word for it that this is a common need, then that's one good reason. It could also be done by adding a subprocess.CLOSED constant, which if passed to Popen causes a new closed file descriptor to be given to the subprocess. -1. It is easy enough to create a closed FD to read from... why complicate the API? -- Michael Chermside ___ 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)
At 05:10 PM 6/27/2005 +0200, Reinhold Birkenfeld wrote: 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). You're right. +1 for calling it fromcwd(). I'm leaning slightly towards .cwd() for symmetry with datetime.now(), but not enough to argue about it if nobody has objections to fromcwd(). With that settled, should I rewrite the module? Should I write a PEP? I think the only questions remaining open are where to put it and what to call the class. I think we should put it in os.path, such that 'from os.path import path' gives you the path class for your platform, and using one of the path modules directly (e.g. 'from posixpath import path') gives you the specific platform's version. This is useful because sometimes you need to manipulate paths that are foreign to your current OS. For example, the distutils and other packages sometimes use POSIX paths for input and then convert them to local OS paths. Also, POSIX path objects would be useful for creating or parsing the path portion of many kinds of URLs, and I have often used functions from posixpath for that myself. As for a PEP, I doubt a PEP is really required for something this simple; I have never seen anyone say, no, we shouldn't have this in the stdlib. I think it would be more important to write reference documentation and a complete test suite. By the way, it also occurs to me that for the sake of subclassability, the methods should not return 'path(somestr)' when creating new objects, but instead use self.__class__(somestr). ___ 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] Possible C API problem?
Hello,
I was asking about a problem I was having over on the C++-python list,
and they suggested I report it here as a possible Python problem.
I was getting bus errors with a C module I was linking to, so factored
it down too a very small example that reproduced the problem. Here it
is:
#include Python.h
static double gfSumChiSquare = 123.0;
static PyObject *
getSumChiSquare(PyObject *self, PyObject *args){
return Py_BuildValue(d, gfSumChiSquare);
}
static PyMethodDef SimMethods[] = {
{getSumChiSquare, getSumChiSquare, METH_NOARGS, Return
fSumChiSquare},
{NULL, NULL, 0, NULL}/* Sentinel */
};
PyMODINIT_FUNC
inittestfloat(void)
{
(void) Py_InitModule(testfloat, SimMethods);
}
That caused a bus error 100% of the time when I simply imported the
module into Python and called getSumChiSquare(), i.e.:
import testfloat
testfloat.getSumChiSquare()
However, the problem seems to go away if I use METH_VARARGS, and parse
the non-existent args with
PyArg_ParseTuple:
#include Python.h
static double gfSumChiSquare = 123.0;
static PyObject *
getSumChiSquare(PyObject *self, PyObject *args){
if (!PyArg_ParseTuple(args, , NULL))
return NULL;
return Py_BuildValue(d, gfSumChiSquare);
}
static PyMethodDef SimMethods[] = {
{getSumChiSquare, getSumChiSquare, METH_VARARGS, Return
fSumChiSquare},
{NULL, NULL, 0, NULL}/* Sentinel */
};
PyMODINIT_FUNC
inittestfloat(void)
{
(void) Py_InitModule(testfloat, SimMethods);
}
This approach seems to work reliably -- at least variations I've tried
haven't caused a bus error. But I haven't been able to discern an
explanation from the docs as to why this would be better. The docs say
that both METH_VARARGS and METH_NOARGS expect a PyCFunction. So if I am
calling the function with no arguments, why can't I use METH_NOARGS and
skip the call to PyArg_ParseTuple?
Could it be that this is a python bug? Or am I doing something wrong?
Note: this is using Python 2.3 on OS X:
Python 2.3 (#1, Sep 13 2003, 00:49:11)
Thanks in advance for any help or insight you can give,
Gary
--
Gary Robinson
CTO
Emergent Music, LLC
[EMAIL PROTECTED]
207-942-3463
Company: http://www.goombah.com
Blog:http://www.garyrobinson.net
___
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] Decimal floats as default (was: discussion aboutPEP239 and 240)
Fredrik Johansson writes: In either case, compatibility can be ensured by allowing both n-digit decimal and hardware binary precision for floats, settable via a float context. Perhaps you can show me a design (or working code) that proves me wrong, but I don't believe that such a design could be made compatible with the existing Decimal module... certainly while continuing to maintain compatibility with the Cowlinshaw specification. There is the alternative of providing decimal literals by using separate decimal and binary float base types If, by this, you mean adding a binary float context modeled after the Decimal float context and providing access to the underlying FP flags and traps and generally enhancing the use of binary FP, then I think it's a great idea. It's probably impossible to write in a cross-platform manner (because C supplies support for binary FP but does not offer access to the flags and traps), but this is one of those few cases where it's worth using platform-and-compiler specific code. Of course, someone still has to step forward and offer to code it. -- Michael Chermside ___ 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] Some RFE for review
On 6/27/05, Nick Coghlan [EMAIL PROTECTED] wrote: Reinhold Birkenfeld wrote: 1152248: In order to read records separated by something other than newline, file objects should either support an additional parameter (the separator) to (x)readlines(), or gain an additional method which does this. Review: The former is a no-go, I think, because what is read won't be lines. The latter is further complicating the file interface, so I would follow the principle that not every 3-line function should be builtin. As Douglas Alan's sample implementation (and his second attempt [1]) show, getting this right (and reasonably efficient) is actually a non-trivial exercise. Leveraging the existing xreadlines infrastructure is an idea worth considering. Do you mean the existing xreadlines infrustructure that no longer exists since 2.4 ? :-) An infrastructure that could be leveraged is the readahead buffer used by the file object's line iterator. Oren ___ 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] Decimal floats as default (was: discussion aboutPEP239 and 240)
On Mon, Jun 27, 2005, Michael Chermside wrote: If, by this, you mean adding a binary float context modeled after the Decimal float context and providing access to the underlying FP flags and traps and generally enhancing the use of binary FP, then I think it's a great idea. It's probably impossible to write in a cross-platform manner (because C supplies support for binary FP but does not offer access to the flags and traps), but this is one of those few cases where it's worth using platform-and-compiler specific code. Of course, someone still has to step forward and offer to code it. ...and document and maintain it. That's always been the sticky part, along with the requirement that this degrade gracefully when the platform-specific code doesn't exist. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng. ___ 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)
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). What about have it just be the default empty constructor? assert path.Path() == os.getcwd() \ or path.Path() == os.getcwdu() Dunno if that causes other weirdnesses with the API, though. Trent -- Trent Mick [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] Adding the 'path' module (was Re: Some RFE for review)
Phillip J. Eby wrote: At 09:26 PM 6/26/2005 -0400, Bob Ippolito wrote: On Jun 26, 2005, at 8:54 PM, Phillip J. Eby wrote: At 12:22 AM 6/27/2005 +0200, Dörwald Walter wrote: Phillip J. Eby wrote: I'm also not keen on the fact that it makes certain things properties whose value can change over time; i.e. ctime/mtime/ atime and size really shouldn't be properties, but rather methods. I think ctime, mtime and atime should be (or return) datetime.datetime objects instead of integer timestamps. With what timezone? I don't think that can be done portably and unambiguously, so I'm -1 on that. That makes no sense, timestamps aren't any better, Sure they are, if what you want is a timestamp. In any case, the most common use case I've seen for mtime and friends is just comparing against a previous value, or the value on another file, so it doesn't actually matter most of the time what the type of the value is. I find timestamp values to be somewhat opaque. So all things being equal, I'd prefer datetime objects. and datetime objects have no time zone set by default anyway. datetime.fromtimestamp(time.time()) gives you the same thing as datetime.now(). In which case, it's also easy enough to get a datetime if you really want one. I personally would rather do that than complicate the use cases where a datetime isn't really needed. (i.e. most of the time, at least in my experience) We should have one uniform way of representing time in Python. IMHO datetime objects are the natural choice. Bye, Walter Dörwald ___ 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)
At 08:24 PM 6/27/2005 +0100, Michael Hoffman wrote: 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. Only if we make the default argument to path() be os.curdir, which isn't a bad idea. Unfortunately only some of the methods work on paths created with the default constructor: path().listdir() Traceback (most recent call last): File stdin, 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: '' This wouldn't be a problem if the default constructor arg were os.curdir (i.e. '.' for most platforms) instead of an empty string. 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. Ugh. sys.path entries are not path objects, nor should they be. PEP 302 (implemented in Python 2.3 and up) allows sys.path to contain any strings you like, as interpreted by objects in sys.path_hooks. Programs that assume only filesystem paths appear in sys.path will break in the presence of PEP 302-sanctioned import hooks. ___ 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)
We're getting enough discussion about various aspects of Jason's path module that perhaps a PEP is warranted. All this discussion on python-dev is just going to get lost. Skip ___ 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] Possible C API problem?
Gary Robinson [EMAIL PROTECTED] writes: That caused a bus error 100% of the time when I simply imported the module into Python and called getSumChiSquare(), i.e.: import testfloat testfloat.getSumChiSquare() It doesn't for me (CVS HEAD, OS X Panther). Could it be that this is a python bug? Or am I doing something wrong? Note: this is using Python 2.3 on OS X: Python 2.3 (#1, Sep 13 2003, 00:49:11) Thanks in advance for any help or insight you can give, Have you, you know, tried to debug the situation yourself? If you have gcc installed, you probably have gdb installed too... Cheers, mwh -- You can lead an idiot to knowledge but you cannot make him think. You can, however, rectally insert the information, printed on stone tablets, using a sharpened poker.-- Nicolai -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html ___ 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)
At 03:45 PM 6/27/2005 -0500, Skip Montanaro wrote: We're getting enough discussion about various aspects of Jason's path module that perhaps a PEP is warranted. All this discussion on python-dev is just going to get lost. AFAICT, the only unresolved issue outstanding is a compromise or Pronouncement regarding the atime/ctime/mtime members' datatype. This is assuming, of course, that making the empty path be os.curdir doesn't receive any objections, and that nobody strongly prefers 'path.fromcwd()' over 'path.cwd()' as the alternate constructor name. Apart from these fairly minor issues, there is a very short to-do list, small enough to do an implementation patch in an evening or two. Documentation might take a similar amount of time after that; mostly it'll be copy-paste from the existing os.path docs, though. As for the open issues, if we can't reach some sane compromise about atime/ctime/mtime, I'd suggest just providing the stat() method and let people use stat().st_mtime et al. Alternately, I'd be okay with creating last_modified(), last_accessed(), and created_on() methods that return datetime objects, as long as there's also atime()/mtime()/ctime() methods that return timestamps. ___ 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] Possible C API problem?
Michael Hudson wrote: Gary Robinson [EMAIL PROTECTED] writes: ... bus error 100% of the time ...: We've boiled it down pretty far, and I've sent him off to the mac-python folks (looks gcc-compilerish to me, or maybe fallout from slight changes in C function call semantics). --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] Some RFE for review
Oren Tirosh wrote: An infrastructure that could be leveraged is the readahead buffer used by the file object's line iterator. That's the infrastructure I meant. I was just being sloppy with my terminology ;) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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] Possible C API problem?
It doesn't for me (CVS HEAD, OS X Panther). Note sure what you mean CVS HEAD, you mean the latest python from cvs? 2.4? I'm still using the Apple python, which is straight 2.3. Have you, you know, tried to debug the situation yourself? If you have gcc installed, you probably have gdb installed too... It's been around 7 years since I've used C, I've forgotten virtually everything I may have known about gdb, I've never worked with the C-python API before... meanwhile there is intense time pressure to get the next release of our product (http://www.goombah.com) ready. So it's just not practical for me to take that on myself now. I'm hoping to get some help from other pythonistas where someone will say -- yes, it's getting a bus error for so-and-so reason, and if you do it this other way, you'll be fine... Thanks, Gary -- Gary Robinson CTO Emergent Music, LLC [EMAIL PROTECTED] 207-942-3463 Company: http://www.goombah.com Blog:http://www.garyrobinson.net On Mon, 27 Jun 2005 21:56:44 +0100, Michael Hudson wrote: Gary Robinson [EMAIL PROTECTED] writes: That caused a bus error 100% of the time when I simply imported the module into Python and called getSumChiSquare(), i.e.: import testfloat testfloat.getSumChiSquare() It doesn't for me (CVS HEAD, OS X Panther). Could it be that this is a python bug? Or am I doing something wrong? Note: this is using Python 2.3 on OS X: Python 2.3 (#1, Sep 13 2003, 00:49:11) Thanks in advance for any help or insight you can give, Have you, you know, tried to debug the situation yourself? If you have gcc installed, you probably have gdb installed too... Cheers, mwh ___ 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] Possible C API problem?
Gary Robinson wrote: It's been around 7 years since I've used C, I've forgotten virtually everything I may have known about gdb, I've never worked with the C-python API before... meanwhile there is intense time pressure to get the next release of our product (http://www.goombah.com) ready. So it's just not practical for me to take that on myself now. I'm hoping to get some help from other pythonistas where someone will say -- yes, it's getting a bus error for so-and-so reason, and if you do it this other way, you'll be fine... Well, it appears you have a workaround (METH_VARARGS) so I'd suggest using that for now, and raise a bug report at SourceForge http://sourceforge.net/tracker/?group_id=5470atid=105470. Tim Delaney ___ 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] Possible C API problem?
On Jun 27, 2005, at 6:48 PM, Delaney, Timothy (Tim) wrote: Gary Robinson wrote: It's been around 7 years since I've used C, I've forgotten virtually everything I may have known about gdb, I've never worked with the C-python API before... meanwhile there is intense time pressure to get the next release of our product (http://www.goombah.com) ready. So it's just not practical for me to take that on myself now. I'm hoping to get some help from other pythonistas where someone will say -- yes, it's getting a bus error for so-and-so reason, and if you do it this other way, you'll be fine... Well, it appears you have a workaround (METH_VARARGS) so I'd suggest using that for now, and raise a bug report at SourceForge http://sourceforge.net/tracker/?group_id=5470atid=105470. You should also test on Python 2.4.1 and/or Python 2.3.5. A bug report against Python 2.3.0 isn't very useful if it's a bug that's already been resolved. -bob ___ 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, 2005-06-27 at 14:25, Phillip J. Eby wrote: [...] As for the open issues, if we can't reach some sane compromise about atime/ctime/mtime, I'd suggest just providing the stat() method and let people use stat().st_mtime et al. Alternately, I'd be okay with creating last_modified(), last_accessed(), and created_on() methods that return datetime objects, as long as there's also atime()/mtime()/ctime() methods that return timestamps. +1 for atime/mtime/ctime being timestamps -1 for redundant duplicates that return DateTimes +1 for a stat() method (there is lots of other goodies in a stat). -- Donovan Baarda [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] Adding the 'path' module (was Re: Some RFE for review)
Andrew Durdin: While we'ew discussing outstanding issues: In a related discussion of the path module on c.l.py, Thomas Heller pointed out that the path module doesn't correctly handle unicode paths: ... Here is a patch that avoids failure when paths can not be represented in a single 8 bit encoding. It adds a _cwd variable in the initialisation and then calls this rather than os.getcwd. I sent the patch to Jason as well. _base = str _cwd = os.getcwd try: if os.path.supports_unicode_filenames: _base = unicode _cwd = os.getcwdu except AttributeError: pass #... def getcwd(): Return the current working directory as a path object. return path(_cwd()) Neil ___ 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
