[Python-Dev] C99 code in the Python core?

2008-07-05 Thread Mark Dickinson 
I have a general question and a specific question.  First the general one:

(1) When is it okay to use C99 code in the Python core?  More particularly,
is it considered acceptable to use widely-implemented library functions that
are specified in C99 but not ANSI C, or widely-implemented features that
are new to C99?

Or is C99 code now acceptable pretty much anywhere?  If so, should
PEP 7 be updated?  It currently says: """Use ANSI/ISO standard C
(the 1989 version of the standard)."""

I think there are some C99 features that still aren't implemented
everywhere, even on major platforms.  (Examples are the inverse hyperbolic
trig functions in math.h.)

And the specific question:

(2) Is it okay to use the '%a' format specifier for sprintf, sscanf and friends.
Are there major platforms where this isn't implemented?  (Using
'%a' would make the issue implementation much simpler.)

Mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] C99 code in the Python core?

2008-07-05 Thread Matthieu Brucher 
2008/7/5 Mark Dickinson <[EMAIL PROTECTED]>:
> I have a general question and a specific question.  First the general one:
>
> (1) When is it okay to use C99 code in the Python core?  More particularly,
> is it considered acceptable to use widely-implemented library functions that
> are specified in C99 but not ANSI C, or widely-implemented features that
> are new to C99?
>
> Or is C99 code now acceptable pretty much anywhere?  If so, should
> PEP 7 be updated?  It currently says: """Use ANSI/ISO standard C
> (the 1989 version of the standard)."""
>
> I think there are some C99 features that still aren't implemented
> everywhere, even on major platforms.  (Examples are the inverse hyperbolic
> trig functions in math.h.)

Hi,

I don't think that C99 is not supported by Visual Studio and there are
no plan for Microsoft to do so.

Matthieu
-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] C99 code in the Python core?

2008-07-05 Thread Martin v. Löwis 
> (1) When is it okay to use C99 code in the Python core?  More particularly,
> is it considered acceptable to use widely-implemented library functions that
> are specified in C99 but not ANSI C, or widely-implemented features that
> are new to C99?

[C99 is also ANSI C, IIUC. ANSI has adopted ISO/IEC 9899:1999 as a U.S.
 national standard.]

It's ok to use functions of the C99 standard library if you have a
configure test and a fall-back implementation, or if you know that the
function is available on all systems we care about.

> Or is C99 code now acceptable pretty much anywhere?

No. As others have pointed out, Microsoft still hasn't implemented in
Visual C.

> If so, should
> PEP 7 be updated?  It currently says: """Use ANSI/ISO standard C
> (the 1989 version of the standard)."""

No.

> (2) Is it okay to use the '%a' format specifier for sprintf, sscanf and 
> friends.
> Are there major platforms where this isn't implemented?  (Using
> '%a' would make the issue implementation much simpler.)

It's implemented in VS 2008, see

http://msdn.microsoft.com/en-us/library/hf4y5e3w.aspx

On the other hand, people still might try to run Python on older
versions of Solaris, such as Solaris 2.6 (which was released 1997).
I don't know when Solaris' CRT first started to support this.

I'd add a configure test, and, at run-time, raise an exception
if the C library doesn't support it yet somebody tries to use it.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] Second betas tomorrow

2008-07-05 Thread Gregory P. Smith 
On Tue, Jul 1, 2008 at 8:29 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:

> On Jul 1, 2008, at 10:42 PM, Benjamin Peterson wrote:
>
>> On Tue, Jul 1, 2008 at 8:44 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>>
>>> On Jul 1, 2008, at 7:27 PM, Brett Cannon wrote:
>>>

 Is a Google Calendar kept by anyone that lists stuff like planned
 release dates, etc.?

>>>
>>>
>>> http://www.google.com/calendar/ical/b6v58qvojllt0i6ql654r1vh00%40group.calendar.google.com/public/basic.ics
>>>
>>
>> Can I get the non-iCal version?
>>
>
>
> http://www.google.com/calendar/feeds/b6v58qvojllt0i6ql654r1vh00%40group.calendar.google.com/public/basic
>
>
> http://www.google.com/calendar/embed?src=b6v58qvojllt0i6ql654r1vh00%40group.calendar.google.com&ctz=America/New_York
>
> - -Barry
>
>
And for anyone who hasn't already figured it out.. you can just add
[EMAIL 
PROTECTED]as
a friend in your existing google calendar to see the release schedule
calendar alongside your own.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] bytearray and array.array are not thread-safe

2008-07-05 Thread Antoine Pitrou 

Hello,

Short story: bytearray and array.array by construction allow user code to
reallocate their internal memory buffer. But a raw pointer to the said buffer
can also be obtained by another thread, and used after releasing the GIL (for
CPU-intensive operations like compression). As a consequence, the interpreter
crashes.

Was it envisioned? I see no warning in the docs for the array.array type
(although it has been there for quite some time).

See http://bugs.python.org/issue3139 (reported by Amaury)

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bytearray and array.array are not thread-safe

2008-07-05 Thread Martin v. Löwis 
> Short story: bytearray and array.array by construction allow user code to
> reallocate their internal memory buffer. But a raw pointer to the said buffer
> can also be obtained by another thread, and used after releasing the GIL (for
> CPU-intensive operations like compression). As a consequence, the interpreter
> crashes.
> 
> Was it envisioned? 

I guess this wasn't considered. For t#, there is a comment from
Travis that it really shouldn't release the buffer yet, but it does,
anyway.

I propose that new codes s*, t*, w* are added, and that s#,t#,w# refuses
objects which implement a releasebuffer procedure (alternatively, s# etc
might be removed altogether right away). Users of s* then need to pass
in a Py_Buffer view pointer that gets filled, and need to explicitly
release the buffer. For convenience, it might help if the Py_buffer
structure includes a borrowed PyObject* to the underlying object, along
with a PyBuffer_Release procedure/macro.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

2008-07-05 Thread Grig Gheorghiu 
On Thu, Jun 26, 2008 at 8:18 AM,  <[EMAIL PROTECTED]> wrote:
> Today on planetpython.org, Doug Hellman announced the June issue of Python
> magazine.  The cover story this month is about Pybots, "the fantastic
> automation system that has been put in place to make sure new releases of
> Python software are as robust and stable as possible".
>
> Last week, there was a "beta" release of Python which, according to the
> community buildbots, cannot run any existing python software.  Normally I'd
> be complaining here about Twisted, but in fact Twisted is doing relatively
> well right now; only 80 failing tests.  Django apparently cannot even be
> imported.
>
> The community buildbots have been in a broken state for months now[1]. I've
> been restraining myself from whinging about this, but now that it's getting
> close to release, it's time to get these into shape, or it's time to get rid
> of them.

Hi all,

Sorry for not replying sooner, I was on vacation when this thread
started and I only got back in town yesterday.

To bring my $0.02 to this discussion: the Pybots 'community buildbots'
turned out largely to be a failure. Why? Because there was never
really a 'community' around it, especially a community of project
leaders who would be interested in the state of their projects' tests.
All the machines donated for the Pybots farm belong to people who just
happen to be interested in given projects, but are not really the
leaders of those projects. The only project who constantly stayed on
top of the buildbot status was Twisted, represented by JP Calderone
(although even there the tests were running on my machine, and not on
a machine contributed by the Twisted folks.)

I still haven't given up, and I hope this thread will spur project
leaders into donating time, or resources, to the Pybots project. It
has been my bitter observation about the Open Source world that people
just LOVE to get stuff for free. As soon as you mention more
involvement from them in the form of time, money, hardware resources,
etc., the same brave proponents of cool things to be done are nowhere
to be found.

To come back to this thread, I don't think it's reasonable to expect
the Python core developers to be that interested in the status of the
community buildbots. It is again up to the project leaders to step up
to the plate, donate machines to Pybots, and stay on top of any
breakages that result from Python core checkins. It seems to me that
the Python core developers have always responded promptly and
favorably to reports of breakages coming from the Pybots farm.

Grig
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Packing and unpacking integers

2008-07-05 Thread Josiah Carlson 
A few years ago (yes, it's been that long), I proposed adding a new
format code to struct that would pack integers as strings, similar to
the 's' format code.  In particular, struct.pack('>60G', v) would be a
60-byte big-endian unsigned integer as a string.  The feature request
is http://bugs.python.org/issue1023290 .

Shortly thereafter, it was decided that it wouldn't become a struct
format code, but instead would find itself as part of binhex.  Raymond
Hettinger was supposed to write the function a couple years ago for, I
believe, Python 2.4 .  It never happened.  It still hasn't happened
for Python 2.5 or 2.6 .

I believe there is still a need for packing integers as strings and
unpacking strings as integers, more specifically, offering to Python
an interface to _PyLong_FromByteArray() and _PyLong_AsByteArray().  I
would be happy to write the functionality and unittests this coming
week for 2.6 and 3.0 if I get the ok.  If not, I can write it for 2.7
and 3.1 .

 - Josiah
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com