Re: [Python-Dev] HAVE_FSTAT?

2013-06-05 Thread Hossein

Hi. My 2 cents about this: (well I'm only a noob)

I had this problem; I don't know about other people's environment, but 
my environment's problem was that it was actually not POSIX-compliant: 
it didn't have other file functions as well, but anyway the `fstat` 
error is the FIRST error you get when you compile in such environments, 
so people as unaware as me think the problem is with fstat only.


Anyway I think if you are going to remove anything, you should think in 
terms of POSIX-compliancy of the target system. Removing HAVE_FSTAT 
might be fine (as user can easily write his own version of the function 
and have it included into the python's sources), but if you instead 
provide the user with the ability to use his custom functions when POSIX 
one's aren't available, it would help make python compile on even more 
platforms. Sorry if this last one was off-topic.


Best regards.
___
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] HAVE_FSTAT?

2013-05-19 Thread Antoine Pitrou
On Mon, 20 May 2013 01:09:19 +1000
Nick Coghlan  wrote:
> On Mon, May 20, 2013 at 12:51 AM, Antoine Pitrou  wrote:
> > On Sun, 19 May 2013 07:47:14 -0700 (PDT)
> > "Guido van Rossum"  wrote:
> >> Fake values would probably cause hard to debug problems. It's a long 
> >> standing Python tradition not to offer low level APIs that the platform 
> >> doesn't have.
> >
> > I meant the platform, not Python.
> 
> For CPython derivatives like PyMite, it can help to get things to compile.

It's not a CPython derivative.

Regards

Antoine.


> 
> Perhaps rather than dropping it, we can just replace all the complex
> fallback code with code that triggers 'RuntimeError("Operation
> requires fstat, which is not available on this platform")'.
> 
> Derivatives that support fstat-free platforms will have a clear place
> to put their custom code, but we get the simpler assumption of fstat
> always being available for the code paths we care about (and can
> reasonably test).
> 
> Cheers,
> Nick.
> 
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia

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

2013-05-19 Thread Nick Coghlan
On Mon, May 20, 2013 at 12:51 AM, Antoine Pitrou  wrote:
> On Sun, 19 May 2013 07:47:14 -0700 (PDT)
> "Guido van Rossum"  wrote:
>> Fake values would probably cause hard to debug problems. It's a long 
>> standing Python tradition not to offer low level APIs that the platform 
>> doesn't have.
>
> I meant the platform, not Python.

For CPython derivatives like PyMite, it can help to get things to compile.

Perhaps rather than dropping it, we can just replace all the complex
fallback code with code that triggers 'RuntimeError("Operation
requires fstat, which is not available on this platform")'.

Derivatives that support fstat-free platforms will have a clear place
to put their custom code, but we get the simpler assumption of fstat
always being available for the code paths we care about (and can
reasonably test).

Cheers,
Nick.

--
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] HAVE_FSTAT?

2013-05-19 Thread Antoine Pitrou
On Sun, 19 May 2013 07:47:14 -0700 (PDT)
"Guido van Rossum"  wrote:
> Fake values would probably cause hard to debug problems. It's a long standing 
> Python tradition not to offer low level APIs that the platform doesn't have.

I meant the platform, not Python.

Regards

Antoine.


> —
> Sent from Mailbox
> 
> On Sun, May 19, 2013 at 5:20 AM, Antoine Pitrou 
> wrote:
> 
> > On Sun, 19 May 2013 10:08:39 +0200
> > Charles-François Natali  wrote:
> >> 2013/5/17 Antoine Pitrou :
> >> >
> >> > Hello,
> >> >
> >> > Some pieces of code are still guarded by:
> >> > #ifdef HAVE_FSTAT
> >> >   ...
> >> > #endif
> >> >
> >> > I would expect all systems to have fstat() these days. It's pretty
> >> > basic POSIX, and even Windows has had it for ages. Shouldn't we simply
> >> > make those code blocks unconditional? It would avoid having to maintain
> >> > unused fallback paths.
> >> 
> >> I was sure I'd seen a post/bug report about this:
> >> http://bugs.python.org/issue12082
> >> 
> >> The OP was trying to build Python on an embedded platform without fstat().
> > Ah, right. Ok, judging by the answers I'm being consistent in my
> > opinions :-)
> > I still wonder why an embedded platform can't provide at least some
> > emulation of fstat(), even by returning fake values. Not providing
> > such a basic function must break a lot of existing third-party software.
> > Regards
> > Antoine.
> > ___
> > Python-Dev mailing list
> > Python-Dev@python.org
> > http://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe: 
> > http://mail.python.org/mailman/options/python-dev/guido%40python.org

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

2013-05-19 Thread Guido van Rossum
Fake values would probably cause hard to debug problems. It's a long standing 
Python tradition not to offer low level APIs that the platform doesn't have.
—
Sent from Mailbox

On Sun, May 19, 2013 at 5:20 AM, Antoine Pitrou 
wrote:

> On Sun, 19 May 2013 10:08:39 +0200
> Charles-François Natali  wrote:
>> 2013/5/17 Antoine Pitrou :
>> >
>> > Hello,
>> >
>> > Some pieces of code are still guarded by:
>> > #ifdef HAVE_FSTAT
>> >   ...
>> > #endif
>> >
>> > I would expect all systems to have fstat() these days. It's pretty
>> > basic POSIX, and even Windows has had it for ages. Shouldn't we simply
>> > make those code blocks unconditional? It would avoid having to maintain
>> > unused fallback paths.
>> 
>> I was sure I'd seen a post/bug report about this:
>> http://bugs.python.org/issue12082
>> 
>> The OP was trying to build Python on an embedded platform without fstat().
> Ah, right. Ok, judging by the answers I'm being consistent in my
> opinions :-)
> I still wonder why an embedded platform can't provide at least some
> emulation of fstat(), even by returning fake values. Not providing
> such a basic function must break a lot of existing third-party software.
> Regards
> Antoine.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/guido%40python.org___
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] HAVE_FSTAT?

2013-05-19 Thread Antoine Pitrou
On Sun, 19 May 2013 10:08:39 +0200
Charles-François Natali  wrote:
> 2013/5/17 Antoine Pitrou :
> >
> > Hello,
> >
> > Some pieces of code are still guarded by:
> > #ifdef HAVE_FSTAT
> >   ...
> > #endif
> >
> > I would expect all systems to have fstat() these days. It's pretty
> > basic POSIX, and even Windows has had it for ages. Shouldn't we simply
> > make those code blocks unconditional? It would avoid having to maintain
> > unused fallback paths.
> 
> I was sure I'd seen a post/bug report about this:
> http://bugs.python.org/issue12082
> 
> The OP was trying to build Python on an embedded platform without fstat().

Ah, right. Ok, judging by the answers I'm being consistent in my
opinions :-)

I still wonder why an embedded platform can't provide at least some
emulation of fstat(), even by returning fake values. Not providing
such a basic function must break a lot of existing third-party software.

Regards

Antoine.
___
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] HAVE_FSTAT?

2013-05-19 Thread Charles-François Natali
2013/5/17 Antoine Pitrou :
>
> Hello,
>
> Some pieces of code are still guarded by:
> #ifdef HAVE_FSTAT
>   ...
> #endif
>
> I would expect all systems to have fstat() these days. It's pretty
> basic POSIX, and even Windows has had it for ages. Shouldn't we simply
> make those code blocks unconditional? It would avoid having to maintain
> unused fallback paths.

I was sure I'd seen a post/bug report about this:
http://bugs.python.org/issue12082

The OP was trying to build Python on an embedded platform without fstat().

cf
___
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] HAVE_FSTAT?

2013-05-18 Thread Antonio Cavallo
I've had a quick look with grep -R HAVE_ * | egrep '[.]c:'.

Modules/posixmodule.c has HAVE_UTIME_H and it might be standard libc on all 
posix platforms.

Objects/obmalloc.c has HAVE_MMAP… but I guess that's fine given other platforms 
might not have such facility. 

Depending on the granularity (on a per platform or per feature) probably yes, 
there aren't many left.

I hope this helps


On 17 May 2013, at 16:56, Antoine Pitrou  wrote:

> On Fri, 17 May 2013 09:15:29 -0500
> Skip Montanaro  wrote:
>>> Some pieces of code are still guarded by:
>>> #ifdef HAVE_FSTAT
>>>  ...
>>> #endif
>> 
>> Are there other guards for similarly common libc functions?
> 
> I don't think so. Someone should take a look though :-)
> 
> Regards
> 
> Antoine.
> ___
> 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/a.cavallo%40cavallinux.eu

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

2013-05-17 Thread Antoine Pitrou
On Fri, 17 May 2013 09:15:29 -0500
Skip Montanaro  wrote:
> > Some pieces of code are still guarded by:
> > #ifdef HAVE_FSTAT
> >   ...
> > #endif
> 
> Are there other guards for similarly common libc functions?

I don't think so. Someone should take a look though :-)

Regards

Antoine.
___
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] HAVE_FSTAT?

2013-05-17 Thread Skip Montanaro
> Some pieces of code are still guarded by:
> #ifdef HAVE_FSTAT
>   ...
> #endif

Are there other guards for similarly common libc functions?  If so,
perhaps each one should be removed in a series of change sets, one per
guard.

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] HAVE_FSTAT?

2013-05-17 Thread Benjamin Peterson
2013/5/17 Antoine Pitrou :
>
> Hello,
>
> Some pieces of code are still guarded by:
> #ifdef HAVE_FSTAT
>   ...
> #endif
>
> I would expect all systems to have fstat() these days. It's pretty
> basic POSIX, and even Windows has had it for ages. Shouldn't we simply
> make those code blocks unconditional? It would avoid having to maintain
> unused fallback paths.

+1

(Maybe Snakebite has such an exotic system, though?) :)



--
Regards,
Benjamin
___
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] HAVE_FSTAT?

2013-05-17 Thread Antoine Pitrou

Hello,

Some pieces of code are still guarded by:
#ifdef HAVE_FSTAT
  ...
#endif

I would expect all systems to have fstat() these days. It's pretty
basic POSIX, and even Windows has had it for ages. Shouldn't we simply
make those code blocks unconditional? It would avoid having to maintain
unused fallback paths.

Regards

Antoine.


___
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