headers
Neal Norwitz | 12 Jan 2003 20:04

Re: Parallel pyc construction

On Sun, Jan 12, 2003 at 10:10:25AM -0800, Paul F Dubois wrote:
> Thanks to everyone who has tried to help me with this problem. I will try to
> make a command line option for this.

I have already uploaded a patch on the SF bug/feature request.  Feel
free to use it.  Anybody want to review it?

        http://python.org/sf/602345

There is a patch for 2.3 as well as 2.2.

Neal
Permalink | Reply | 0 comments |
headers
Mark Hammond | 13 Jan 2003 00:59
Picon
Favicon
Gravatar

RE: Re: Extension modules, Threading, and the GIL

[David Abrahams]

> I can't really imagine what you're suggesting here.  Code samples
> help.

OK :)  Here is some code demonstrating my "pluggable" idea, but working
backwards <wink>.

(Please don't pick on the names, or where I will need to pass a param, or
where I forgot to cast, etc <wink>)

First, let's assume we come up with a high-level API similar to:

/*** Python "auto-thread-state" API ***/

typedef void *PyATS_HANDLE;

/* Get's a "cookie" for use in all subsequent auto-thread-state
   calls.  Generally called once per application/extension.
   Not strictly necessary, but a vehicle to abstract
   PyInterpreterState should people care enough.
*/
PyATS_HANDLE PyAutoThreadState_Init();

/* Ensure we have Python ready to rock.  This is the "slow" version
   that assumes nothing about Python's state, other than the handle
   is valid.
*/
int PyAutoThreadState_Ensure(PyATS_HANDLE);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Peters | 13 Jan 2003 05:30
Picon

RE: Broken strptime in Python 2.3a1 & CVS

[Brett Cannon]
> OK, so I read the Open Group's specification and it had squat for default
> value info

Read it again:  the notion of "default value" makes no sense for the C
strptime(), because a struct tm* is both input to and output from the C
version of this function.  The caller is responsible for setting up the
defaults they want in the struct tm passed *to* strptime().  The Python
strptime doesn't work that way (no timetuple is passed on), which makes the
"default values" issue more intense in the Python version.

> (unless what they provide online is not as detailed as what
> members have access to).

Nope, that's all there is.

> So I logged into a Solaris machine with 2.1.1 and ran
> ``time.strptime('January', '%B')`` and got
> (1900, 1, 0, 0, 0, 0, 6, 1, 0)
> (which is strange because the day of the week for 1900-01-01

The timetuple you got back on Solaris is for the senseless "day" 1900-01-00:
tm_mday is 1-based, not 0-based.

> is Monday, not Sunday;

But if 1900-01-00 *were* a real day <wink>, it would be a Sunday.

> must be rolling back a day since the day is 0?  But then the Julian day
> value is wrong).
(Continue reading)

Permalink | Reply | 27 comments |
headers
Brett Cannon | 13 Jan 2003 07:03
Picon

RE: Broken strptime in Python 2.3a1 & CVS

[Tim Peters]

> [Brett Cannon]
> > OK, so I read the Open Group's specification and it had squat for default
> > value info
>
> Read it again:  the notion of "default value" makes no sense for the C
> strptime(), because a struct tm* is both input to and output from the C
> version of this function.  The caller is responsible for setting up the
> defaults they want in the struct tm passed *to* strptime().  The Python
> strptime doesn't work that way (no timetuple is passed on), which makes the
> "default values" issue more intense in the Python version.
>

And the reason I set values to -1 in the first place is because the Python
docs say that there is no guarantee as to what will be returned.  Why
chouldn't they had added this function to ISO C?

> > (unless what they provide online is not as detailed as what
> > members have access to).
>
> Nope, that's all there is.
>

Figures.

[stuff about how lacking the "standards" are for the C implementation]
> It's hard to know what Kevin was suggesting -- he was mostly appealing to
> emperors that turn out to have no clothes <wink>.
>
(Continue reading)

Permalink | Reply | 17 comments |
headers
Kevin Jacobs | 13 Jan 2003 12:38

RE: Broken strptime in Python 2.3a1 & CVS

On Sun, 12 Jan 2003, Tim Peters wrote:
> > But otherwise I am fine with it defaulting to 1900-01-00 as Kevin seems
> > to be suggesting.
> 
> It's hard to know what Kevin was suggesting -- he was mostly appealing to
> emperors that turn out to have no clothes <wink>.

;)

I was appealing to the Linux, Tru64Unix, IRIX, and Solaris emperors, all
naked, then.

> > and then calculate the Julian day and day of the week?  That way the
> > default values will be valid *and* not mess up ``time.mktime()``?
> 
> Kevin is the only one with a real use case here so far, and he needs to
> define what he wants with more rigor.  It may or may not turn out to be
> feasible to implement that, whatever it is.

My first e-mail did just that.  I want

  def round_trip(n):
    strftime('%m/%d/%Y', localtime(mktime(strptime(n, '%m/%d/%Y')))

  assert n == round_trip(n)

when n is a valid date value.  This is my major use-case, since the lack of
being able to round-trip date values breaks all of our financial tracking
applications in _very_ ugly ways.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Michael Hudson | 13 Jan 2003 14:59
Favicon

Re: Trouble with Python 2.3a1

David Abrahams <dave <at> boost-consulting.com> writes:

> The output below shows that in 2.3a1, that module prefix string is
> discarded in favor of the name of the module which imports the
> extension module.

Look at revision 2.194 of Objects/typeobject.c.  I changed some stuff
in this area, but am far too fuzzy headed today to work out if it's
likely to have affected you in this case...

Cheers,
M.

--

-- 
  I have no disaster recovery plan for black holes, I'm afraid.  Also
  please be aware that if it one looks imminent I will be out rioting
  and setting fire to McDonalds (always wanted to do that) and
  probably not reading email anyway.                     -- Dan Barlow
Permalink | Reply | 0 comments |
headers
M.-A. Lemburg | 13 Jan 2003 16:02

Interop between datetime and mxDateTime

I'd like to make mxDateTime and datetime in Python 2.3
cooperate.

Looking at the datetime.h file, it seems that
the C API isn't all that fleshed out yet. Will this happen
before 2.3b1 ?

Related to this: I wonder why datetime is not a normal
Python object which lives in Objects/ ?!

Finally, the datetime objects don't seem to provide any
means of letting binary operations with other types
succeed. Coercion or mixed type operations are not
implemented. When will this happen ?

Thanks,
--

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
_______________________________________________________________________
eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,...
Python Consulting:                               http://www.egenix.com/
Python Software:                    http://www.egenix.com/files/python/
Permalink | Reply | 26 comments |
headers
Guido van Rossum | 13 Jan 2003 16:31
Favicon

Failures compiling ossaudiodev.c

I get errors compiling ossaudiodev.c on a Mandrake 8.1 system:

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I.
-I/home/guido/projects/python/dist/src/./Include -I/usr/local/include
-I/home/guido/projects/python/dist/src/Include
-I/home/guido/projects/python/dist/src/linux -c
/home/guido/projects/python/dist/src/Modules/ossaudiodev.c -o build/temp.linux-i686-2.3/ossaudiodev.o
/home/guido/projects/python/dist/src/Modules/ossaudiodev.c: In function `initossaudiodev':
/home/guido/projects/python/dist/src/Modules/ossaudiodev.c:965: `AFMT_AC3' undeclared (first
use in this function)
/home/guido/projects/python/dist/src/Modules/ossaudiodev.c:965: (Each undeclared identifier is
reported only once
/home/guido/projects/python/dist/src/Modules/ossaudiodev.c:965: for each function it appears in.)
/home/guido/projects/python/dist/src/Modules/ossaudiodev.c:1008: `SNDCTL_DSP_BIND_CHANNEL'
undeclared (first use in this function)
/home/guido/projects/python/dist/src/Modules/ossaudiodev.c:1012:
`SNDCTL_DSP_GETCHANNELMASK' undeclared (first use in this function)

--Guido van Rossum (home page: http://www.python.org/~guido/)
Permalink | Reply | 0 comments |
headers
Neal Norwitz | 13 Jan 2003 16:41

_Py_QnewFlag


This comment is in Include/pydebug.h:

/* _XXX Py_QnewFlag should go away in 2.3.  It's true iff -Qnew is passed,
  on the command line, and is used in 2.2 by ceval.c to make all "/" divisions
  true divisions (which they will be in 2.3). */

Is this comment correct?

Neal
Permalink | Reply | 1 comment |
headers
Guido van Rossum | 13 Jan 2003 16:49
Favicon

Re: Interop between datetime and mxDateTime

> I'd like to make mxDateTime and datetime in Python 2.3
> cooperate.

Me too.

There was a proposal long ago that all datetime-like objects should
implement a timetuple() method.  Perhaps we should revive that?
datetime does implement this.

> Looking at the datetime.h file, it seems that
> the C API isn't all that fleshed out yet. Will this happen
> before 2.3b1 ?

I think that datetime.h is in fact entirely private to the module.

> Related to this: I wonder why datetime is not a normal
> Python object which lives in Objects/ ?!

No single reason.  Some reasons I can think of:

- There's a pure Python implementation that can be used with Python
  2.2 (probably even earlier versions)

- It's not that essential to most code, so it seems appropriate to
  have to import it

- I didn't want this to be seen as "growing the language"

- It's still very young
(Continue reading)

Permalink | Reply | 24 comments |

Gmane