Neal Norwitz schrieb:
> By private, I mean internal only to python and don't need to prefix
> their identifiers with Py and are subject to change without backwards
> compatibility. Include/graminit.h is one example of what I mean.
> Some others are: bitset.h, grammar.h, opcode.h, metagrammar.h,
>
On 1/3/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Neal Norwitz schrieb:
> > Wow, I didn't realize I was that much of a broken record. :-)
> > I don't even remember talking to Thomas about it, only Guido. I
> > definitely would like to see all private header files clearly denoted
> > by the
Neal Norwitz schrieb:
> Wow, I didn't realize I was that much of a broken record. :-)
> I don't even remember talking to Thomas about it, only Guido. I
> definitely would like to see all private header files clearly denoted
> by their name or directory.
What is a private header file, and does Pyt
The current schedule looks like it's shaping up to be:
Wed, Jan 24 for 2.5.1c1
Wed Jan 31 for 2.5.1
It would be great if you could comment on some of the bug reports
below. I think several already have patches/suggested fixes.
These looks like they would be nice to fix::
http://python.org/
On 1/3/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>
>
> On 1/3/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 1/3/07, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> > > On Wednesday 03 January 2007 11:06, Martin v. Löwis wrote:
> > > > In #1626545, Anton Tropashko requests that object.
On 1/3/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Thomas Wouters schrieb:
> (Only for header
> files that should really be internal, of course, not ones that are
> oft-used outside the core.)
Which are these?
Mostly structmember.h and structseq.h, less often code.h, compile.h,
frameobj
On 3-Jan-2007, at 23:17 , Gregory P. Smith wrote:
> +1 on using the python/*.h subdirectory.
I'm a bit concerned about the "python/*.h": could it cause trouble in
combination with Apple's framework naming convention (#include
magically gets the header out of the
quicktime framework) and
On Wed, Jan 03, 2007 at 02:54:34PM -0500, Barry Warsaw wrote:
> On Jan 3, 2007, at 2:29 PM, Martin v. L?wis wrote:
>
> > Guido van Rossum schrieb:
> >> Maybe this should be done in a more systematic fashion? E.g. by
> >> giving all "internal" header files a "py_" prefix?
> >
> > Yet another alte
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 3, 2007, at 2:29 PM, Martin v. Löwis wrote:
> Guido van Rossum schrieb:
>> Maybe this should be done in a more systematic fashion? E.g. by
>> giving
>> all "internal" header files a "py_" prefix?
>
> Yet another alternative would be to move a
Thomas Wouters schrieb:
> (Only for header
> files that should really be internal, of course, not ones that are
> oft-used outside the core.)
Which are these?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailm
On 1/3/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Guido van Rossum schrieb:
> Maybe this should be done in a more systematic fashion? E.g. by giving
> all "internal" header files a "py_" prefix?
Yet another alternative would be to move all such header files into a
py/ directory, so you wo
On Wednesday 03 January 2007 14:29, Martin v. Löwis wrote:
> Yet another alternative would be to move all such header files into a
> py/ directory, so you would refer to them as
>
> #include "py/object.h"
>
> Any preferences?
None here; the goal is the only part I care about.
-Fred
--
Guido van Rossum schrieb:
> Maybe this should be done in a more systematic fashion? E.g. by giving
> all "internal" header files a "py_" prefix?
Yet another alternative would be to move all such header files into a
py/ directory, so you would refer to them as
#include "py/object.h"
Any preferenc
>> > In #1626545, Anton Tropashko requests that object.h should be
>> > renamed, because it causes conflicts with other software.
...
Guido> Maybe this should be done in a more systematic fashion? E.g. by
Guido> giving all "internal" header files a "py_" prefix?
Grand Renaming,
On Wednesday 03 January 2007 12:38, Guido van Rossum wrote:
> Maybe this should be done in a more systematic fashion? E.g. by giving
> all "internal" header files a "py_" prefix?
Even better.
+42
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mai
On 1/3/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 1/3/07, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> On Wednesday 03 January 2007 11:06, Martin v. Löwis wrote:
> > In #1626545, Anton Tropashko requests that object.h should be
> > renamed, because it causes conflicts with other sof
On 1/3/07, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> On Wednesday 03 January 2007 11:06, Martin v. Löwis wrote:
> > In #1626545, Anton Tropashko requests that object.h should be
> > renamed, because it causes conflicts with other software.
> >
> > I would like to comply with this requests
On Wednesday 03 January 2007 11:06, Martin v. Löwis wrote:
> In #1626545, Anton Tropashko requests that object.h should be
> renamed, because it causes conflicts with other software.
>
> I would like to comply with this requests for 2.6, assuming there
> shouldn't be many problems with existin
In #1626545, Anton Tropashko requests that object.h should be
renamed, because it causes conflicts with other software.
I would like to comply with this requests for 2.6, assuming there
shouldn't be many problems with existing software as object.h
shouldn't be included directly, anyway.
What do y
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 3, 2007, at 6:07 AM, M.-A. Lemburg wrote:
> Regarding application specific package setups:
>
> In my experience it's better to have an application specific
> sys.path setup function that manages this, rather than trying
> to manipulate PYTHONPA
On 2007-01-03 00:35, Barry Warsaw wrote:
> On Jan 2, 2007, at 5:41 PM, M.-A. Lemburg wrote:
>
>> Note that as side-effect of this it becomes a lot harder to manipulate
>> PYTHONPATH to trick Python into loading a standard module from a
>> non-standard location, improving security and robustness of
21 matches
Mail list logo
