Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

[Guido van Rossum]

On 6/27/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:

> I think the only questions remaining open are where to put it and what to
> call the class.

Whoa! Do we really need a completely different mechanism for doing the
same stuff we can already do? The path module seems mostly useful for
folks coming from Java who are used to the Java Path class. With the
massive duplication of functionality we should also consider what to
recommend for the future: will the old os.path module be deprecated,
or are we going to maintain both alternatives forever? (And what about
all the duplication with the os module itself, like the cwd()
constructor?) Remember TOOWTDI.

> 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.

Aargh! Call it anything except path. Having two things nested inside
each other with the same name is begging for confusion forever. We
have a few of these in the stdlib now (StringIO, UserDict etc.) and
they were MISTAKES.

> 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.

Right. That's why posixpath etc. always exists, not only when os.name
== "posix".

> 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.

"No, we shouldn't have this in the stdlib."

At least, not without more motivation than "it gets high praise".

> 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).

Clearly it needs a PEP.

-- 
--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] Decimal floats as default (was: discussion aboutPEP239 and 240)

[Facundo Batista]

On 6/27/05, Fredrik Johansson <[EMAIL PROTECTED]> wrote:

> The context (as I envision it) would not be just a "binary float
> context", but a universal float context that lets you choose between
> binary and decimal precision at run time.

You mean something like this?

>>> from __future__ import new_float_behaviour
>>> 1.1
1.1
>>> import sys
>>> sys.float_context.binary = True
>>> 1.1
1.1001

I don't see why this couldn't be done. The default will be use decimal
fp, and you can switch to binary fp if you need silicon-speed (unless,
of course, you have decimal-on-silicon).

In decimal mode, the context will be a full one, in binary mode, it's
not mandatory to allow access to fpu flags, it could be just like now.

.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
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)

[Neil Hodgson]

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

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

[Donovan Baarda]

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]

On 6/28/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> 
> 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.

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:

| I have never used the path module before, although I've heard good
| things about it.  But, it seems to have problems with unicode pathnames,
| at least on windows:
| 
| C:\>mkdir späm
| 
| C:\späm>py24
| Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32
| Type "help", "copyright", "credits" or "license" for more information.
| >>> from path import path
| >>> path.getcwd()
| 
| Traceback (most recent call last):
|   File "", line 1, in ?
|   File "C:\TSS5\components\_Pythonlib\path.py", line 97, in getcwd
| return path(os.getcwd())
| UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in position
5: ordinal not in range(128)

He suggests a possible fix in his message:
http://mail.python.org/pipermail/python-list/2005-June/287372.html
http://groups-beta.google.com/group/comp.lang.python/msg/b3795a2a0c52b93f
___
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?

[Bob Ippolito]

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
> .

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] Possible C API problem?

[Delaney, Timothy (Tim)]

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
.

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?

[Gary Robinson]

> 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] Some RFE for review

[Nick Coghlan]

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?

[Scott David Daniels]

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] Adding the 'path' module (was Re: Some RFE for review)

[Phillip J. Eby]

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]

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)

[Skip Montanaro]

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] Adding the 'path' module (was Re: Some RFE for review)

[Phillip J. Eby]

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 "", 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)

[Phillip J. Eby]

At 08:52 PM 6/27/2005 +0200, Walter Dörwald wrote:
>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.

Their opaqueness is actually one of the reasons I prefer them.  :)


> >>  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.

Um, counting the various datetime variants (date, time, datetime), 
timestamps (float and long), and time tuples, Python has 6 ways now.  The 
type chosen for a given API is largely dependent on the *source* of the 
time value.  And the value supplied by most existing OS-level Python APIs 
is either a long or a float.

However, there's also a practicality-beats-purity issue here; using a 
datetime produces an otherwise-unnecessary dependency on the datetime 
module for users of this functionality, despite use cases for an actual 
datetime value being very infrequent.  Date arithmetic on file timestamps 
that can't be trivially done in terms of seconds is rare, as is display of 
file timestamps.  None of these use cases will be significantly harmed by 
having to use datetime.fromtimestamp(); they will probably be importing 
datetime already.  What I don't want is for simple scripts to need to 
import datetime (even indirectly by way of the path class) just to get easy 
access to stat() values.

___
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]

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] Decimal floats as default (was: discussion aboutPEP239 and 240)

[Fredrik Johansson]

On 6/27/05, Michael Chermside <[EMAIL PROTECTED]> wrote:
> 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.

Are you thinking of any particular problem?

> > 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.

The context (as I envision it) would not be just a "binary float
context", but a universal float context that lets you choose between
binary and decimal precision at run time.

A context for Python's current float type would be a nice idea by
itself, though.

> 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.

I agree.

--Fredrik
___
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)

[Walter Dörwald]

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)

[Trent Mick]

> >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] Decimal floats as default (was: discussion aboutPEP239 and 240)

[Aahz]

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] Some RFE for review

[Oren Tirosh]

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)

[Michael Chermside]

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

[Python-Dev] Possible C API problem?

[Gary Robinson]

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 
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 
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] Adding the 'path' module (was Re: Some RFE for review)

[Phillip J. Eby]

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

Re: [Python-Dev] subprocess.call() and stdin

[Michael Chermside]

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)

[Reinhold Birkenfeld]

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] Adding the 'path' module (was Re: Some RFE for review)

[Phillip J. Eby]

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] Some RFE for review

[Raymond Hettinger]

[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] Some RFE for review

[Paul Moore]

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

[Nick Coghlan]

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] Adding the 'path' module (was Re: Some RFE for review)

[Reinhold Birkenfeld]

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] Adding the 'path' module (was Re: Some RFE for review)

[Michael Hoffman]

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