Re: [Python-Dev] slight inconsistency in svn checkin email subject lines
> And while we're at it, could you remove the "commit of" too? IMHO it > just obscures the real content of the subject. +1 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] slight inconsistency in svn checkin email subject lines
Martin v. Löwis wrote: > [...] > commit_subject_prefix = [Python-checkins] commit of > > [...] > > Anyway, I just killed the "[Python-checkins]" part from the prefix > (expecting that mailman would add it, anyway), and regenerated > the r41848 commit message, and it seem that worked this time. And while we're at it, could you remove the "commit of" too? IMHO it just obscures the real content of the subject. 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] buildbot
> "Martin" == Martin v Löwis <[EMAIL PROTECTED]> writes: Martin> Stephen J. Turnbull wrote: >> Sure, Python can be expected to do much better than random port >> maintainers, but Discussions with the port maintainers makes it >> hard to blame them. Martin> Well, it's the same attitude that Fredrik Lundh just critized. Martin> It's ok for a port maintainer to say "I don't have any energy to Martin> fix it myself" (although I would hope he still says "patches Martin> will be accepted"). It's not ok for a port maintainer to say Martin> "it's not a bug - just upgrade your system". It *is* a bug for Martin> Python to emit warnings on "major platforms" (PEP 7). Thank you. I was beginning to think I was going crazy. 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] buildbot
Bob Ippolito wrote: > Clearly, but that still doesn't answer the question of who's going to > do it. Writing two code paths with availability macros and all the > testing involved is a whole lot of work to fix a harmless warning on > older versions of the OS. If it actually caused a problem I'm sure > someone would go through the trouble, but in this case it's probably > not worth the effort. I can fully understand that it is not worth your effort (it isn't worth mine, either). However, if Skip (or somebody else) wanted to fix it, I wouldn't mind. So I wouldn't agree to "not worth the effort". Regards, Martin ___ 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] buildbot
On Jan 3, 2006, at 3:12 PM, Martin v. Löwis wrote: > Bob Ippolito wrote: >> Who's going to bother? > > It violates PEP 7, unless you argue that OS X/gcc is not > a "major compiler". Clearly, but that still doesn't answer the question of who's going to do it. Writing two code paths with availability macros and all the testing involved is a whole lot of work to fix a harmless warning on older versions of the OS. If it actually caused a problem I'm sure someone would go through the trouble, but in this case it's probably not worth the effort. -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] Including zlib...
[EMAIL PROTECTED] wrote: > Martin checked in zlib to the Python svn repository. Are we really sure > that including zlib is the only path to whatever it is that it achieves? If > security holes in zlib turn up (they have in the past), new Python releases > will have to be released quickly. As Tim explains: this change doesn't change anything wrt. having to rerelease. On Unix, nothing changes because the included zlib isn't used (but, personally, I would accept contributions of a patch to use it if there is no platform zlib). On Windows, nothing changes really because now you have to update python24.dll, instead of updating zlib.pyd - either requires a recompilation of the Python sources. Regards, Martin ___ 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] buildbot
Bob Ippolito wrote: > Who's going to bother? It violates PEP 7, unless you argue that OS X/gcc is not a "major compiler". Regards, Martin ___ 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] buildbot
Stephen J. Turnbull wrote: > Sure, Python can be expected to do much better than random port > maintainers, but Discussions with the port maintainers makes it > hard to blame them. Well, it's the same attitude that Fredrik Lundh just critized. It's ok for a port maintainer to say "I don't have any energy to fix it myself" (although I would hope he still says "patches will be accepted"). It's not ok for a port maintainer to say "it's not a bug - just upgrade your system". It *is* a bug for Python to emit warnings on "major platforms" (PEP 7). Also, it would be good if PEP 11 was considered before breaking platforms. If some version of the system is not supported anymore, fine - but *atleast* that should be mentioned in PEP 11, and better, the process suggested in PEP 11 should be followed. Regards, Martin ___ 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] slight inconsistency in svn checkin email subject lines
Neal Norwitz wrote: > I looked into this briefly. I saw something like: > > if prefix: > subject = prefix + ' ' + self.subject > else: > subject = self.subject Hmm - this shouldn't matter: There is only a single prefix defined, in [defaults]: commit_subject_prefix = [Python-checkins] commit of There is no other occurrence of that string in any other spelling elsewhere, and neither of the "commit of" part. So if prefix was empty, the entire "commit of" should be absent. Anyway, I just killed the "[Python-checkins]" part from the prefix (expecting that mailman would add it, anyway), and regenerated the r41848 commit message, and it seem that worked this time. So I still suspect this to be a mailman bug. There is just too much Python code involved in delivering Python commit messages :-) Regards, Martin ___ 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] [Python-checkins] commit of r41906 - python/branches/ssize_t/Objects/obmalloc.c
Tim Peters wrote:
> If it's expedient, that's fine for now. I'd like to help fix it "for
> real", but time is a problem for now. In a week or two I may have
> more to give to this. Would probably also like to change the dict
> object's ma_{fill,used,mask} members to Py_ssize_t (while other people
> don't seem to do this much, I routinely write first-stab programs
> where a single dict blows more than 2GB of VM ;-)).
Yes, I just noticed I mostly ignored dicts so far; that should also
be part of the final patch.
Regards,
Martin
___
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] slight inconsistency in svn checkin email subject lines
On 1/3/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > I tried to, but couldn't. I'll be sending the mailer.py and mailer.conf > files in a private mail. I can't see anything wrong in that code. > > Perhaps mailman is adding the spaces? I looked into this briefly. I saw something like: if prefix: subject = prefix + ' ' + self.subject else: subject = self.subject My guess is that there needs to be stripping for prefix and self.subject. I don't know the code well, but that's all I could come up with. I didn't see any extra spaces in mailer.conf IIRC. n ___ 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] slight inconsistency in svn checkin email subject lines
Trent Mick wrote: > I don't have access to that box. Is this a machine used for maintaining > the pydotorg stuff? Yes, it's also www.python.org (but not mail.python.org) > Or would it be easier > for you the fix this little inconsistency... or have me make a bug on SF > and assign to you (or someone else)? I tried to, but couldn't. I'll be sending the mailer.py and mailer.conf files in a private mail. I can't see anything wrong in that code. Perhaps mailman is adding the spaces? Regards, Martin ___ 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] [Python-checkins] commit of r41906 - python/branches/ssize_t/Objects/obmalloc.c
[Tim]
> >>Modified: python/branches/ssize_t/Objects/obmalloc.c
> [...]
>> This checkin should be reverted for now.
[Martin]
> Not sure whether you've noticed this is "just" on the ssize_t branch.
Right, I noticed.
> Without this patch, it is not possible to allocate 4GiB or more for
> a string object in debug mode, which kind of defeated my attempts to
> test that.
>
> I certainly plan to remove all XXX marks I have introduced in that
> branch before suggesting to integrate it back into the trunk.
>
> So "for now", I would prefer to keep it, and only revert it if
> I have a complete fix.
If it's expedient, that's fine for now. I'd like to help fix it "for
real", but time is a problem for now. In a week or two I may have
more to give to this. Would probably also like to change the dict
object's ma_{fill,used,mask} members to Py_ssize_t (while other people
don't seem to do this much, I routinely write first-stab programs
where a single dict blows more than 2GB of VM ;-)).
> ...
___
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] [Python-checkins] commit of r41906 - python/branches/ssize_t/Objects/obmalloc.c
Tim Peters wrote: >>Modified: python/branches/ssize_t/Objects/obmalloc.c [...] > This checkin should be reverted for now. Not sure whether you've noticed this is "just" on the ssize_t branch. Without this patch, it is not possible to allocate 4GiB or more for a string object in debug mode, which kind of defeated my attempts to test that. I certainly plan to remove all XXX marks I have introduced in that branch before suggesting to integrate it back into the trunk. So "for now", I would prefer to keep it, and only revert it if I have a complete fix. > It's in > _PyObject_DebugMalloc, and at present the layout of the extra debug > info in a PYMALLOC_DEBUG build is hard-coded to use 4-byte fields, no > matter what sizeof(size_t) may be. One of the extra fields recorded > in a PYMALLOC_DEBUG build is the number of bytes requested, and at > present it's simply not capable of recording a value that doesn't fit > in 4 bytes. Well, AFAICT, it "works" even if it records only records the lower 4 bytes of the requested size. Upon freeing, it just won't put enough DEADBYTEs in, which I cannot see having further unfortunate consequences (except that it won't diagnose errors as good anymore as it could). > Even after (if ever ;-)) this is changed to support recording 8-byte > values on a box where sizeof(size_t) == 8, the "total < nbytes" part > of the test would still be appropriate: PyObject_DebugMalloc requests > more memory (`total`) than the user asked for (`nbytes`), and the > computation of `total` may have overflowed. That's what "total < > nbytes" is checking, and that's the right way to spell the overflow > check on any box. Certainly; I did not mean to completely disable this test. Regards, Martin ___ 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] Including zlib...
Hear, hear. Er On 1/3/06, Tim Peters <[EMAIL PROTECTED]> wrote: > [Guido] > > OK. As long a typical Unix build still links with whatever shared zlib > > is present on the box I'm fine with this. > > [Guido] > >>> Hear, hear. > > [Skip] > ... > > [Tim] > ... > I figure that if we keep this conversation going long enough, we can > eventually shame Guido out of top-posting before it becomes a habit > ;-). Here, here! Google has already taught him bad habits. :-) n ___ 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] Including zlib...
[Guido] > OK. As long a typical Unix build still links with whatever shared zlib > is present on the box I'm fine with this. [Guido] >>> Hear, hear. [Skip] Martin checked in zlib to the Python svn repository. Are we really sure that including zlib is the only path to whatever it is that it achieves? If security holes in zlib turn up (they have in the past), new Python releases will have to be released quickly. [Tim] >> Martin & Thomas Heller proposed it here about two weeks ago: >> >> http://mail.python.org/pipermail/python-dev/2005-December/058873.html >> >> It's pimarily for the benefit of py2exe on Windows. AFAICT, he didn't >> change Python's treatment of zlib on non-Windows boxes; on Windows >> zlib is now compiled in to the core DLL. I figure that if we keep this conversation going long enough, we can eventually shame Guido out of top-posting before it becomes a habit ;-). ___ 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] Including zlib...
OK. As long a typical Unix build still links with whatever shared zlib is present on the box I'm fine with this. --Guido On 1/3/06, Tim Peters <[EMAIL PROTECTED]> wrote: > [Guido] > > Hear, hear. > > [Skip] > >> Martin checked in zlib to the Python svn repository. Are we really sure > >> that including zlib is the only path to whatever it is that it achieves? > >> If > >> security holes in zlib turn up (they have in the past), new Python releases > >> will have to be released quickly. > > Martin & Thomas Heller proposed it here about two weeks ago: > > http://mail.python.org/pipermail/python-dev/2005-December/058873.html > > It's pimarily for the benefit of py2exe on Windows. AFAICT, he didn't > change Python's treatment of zlib on non-Windows boxes; on Windows > zlib is now compiled in to the core DLL. > ___ > 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 > -- --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] Including zlib...
[Guido] > Hear, hear. [Skip] >> Martin checked in zlib to the Python svn repository. Are we really sure >> that including zlib is the only path to whatever it is that it achieves? If >> security holes in zlib turn up (they have in the past), new Python releases >> will have to be released quickly. Martin & Thomas Heller proposed it here about two weeks ago: http://mail.python.org/pipermail/python-dev/2005-December/058873.html It's pimarily for the benefit of py2exe on Windows. AFAICT, he didn't change Python's treatment of zlib on non-Windows boxes; on Windows zlib is now compiled in to the core DLL. ___ 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] buildbot
[EMAIL PROTECTED] writes: > I delayed upgrading from 10.2 for awhile and was given the same > "advice". I was further told (check the mac sig archives) that "you'd > be able to stick with 10.3 for much longer" because new apps wouldn't > need to require 10.4. So I upgraded. Now you're telling me that it's > somehow "obsolete" and that I should upgrade because "we can't be > bothered to fix a compiler warning"? Python supports much older > versions of other platforms. What makes Mac OSX so special in this > regard? There are 10.1 and 10.2 boxes in the sourceforge compile farm which could probably used for testing. Thomas ___ 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] Including zlib...
Hear, hear. On 1/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Martin checked in zlib to the Python svn repository. Are we really sure > that including zlib is the only path to whatever it is that it achieves? If > security holes in zlib turn up (they have in the past), new Python releases > will have to be released quickly. -- --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] slight inconsistency in svn checkin email subject lines
[Martin v. Loewis wrote] > Trent Mick wrote: > > Is this intentional? If not, could someone point me to where the svn > > trigger scripts are maintained so I could poke around for a fix? (Or > > just fix it themselves. :) > > It was not my intention. They are in > dinsdale.python.org:/data/repos/projects I don't have access to that box. Is this a machine used for maintaining the pydotorg stuff? Do you want me in that "club"? Or would it be easier for you the fix this little inconsistency... or have me make a bug on SF and assign to you (or someone else)? Thanks, 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] a quit that actually quits
> class _Quitter(str):
> def __call__(self): raise SystemExit
> quit = _Quitter('The quit command. Type "quit()" to exit')
> exit = _Quitter('The exit command. Type "exit()" to exit')
I think you meant
class _Quitter(str):
def __call__(self): raise SystemExit
quit = _Quitter('The quit command. Type "quit()" to quit')
exit = _Quitter('The exit command. Type "exit()" to exit')
:-)
--
g
___
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] buildbot
On Jan 3, 2006, at 7:46 AM, [EMAIL PROTECTED] wrote: > Bob> The easy fix is to upgrade your OS. I don't think anyone > is going > Bob> to bother with the preprocessor hackery necessary to make > that > Bob> (harmless) warning go away on older versions of the OS. > > Excuse me, but this really pisses me off. I delayed upgrading from > 10.2 for > awhile and was given the same "advice". I was further told (check > the mac > sig archives) that "you'd be able to stick with 10.3 for much longer" > because new apps wouldn't need to require 10.4. So I upgraded. > Now you're > telling me that it's somehow "obsolete" and that I should upgrade > because > "we can't be bothered to fix a compiler warning"? Python supports > much > older versions of other platforms. What makes Mac OSX so special > in this > regard? The compiler warning is harmless. It's probably about 10 lines of code and an hour of testing to fix it, then you'd need to backport to 2.4, etc. Also, in order to do it properly you need to have access to older versions of the OS in order to see the warning and test to make sure you didn't break anything. Who's going to bother? It's just not practical to fix something that isn't broken. The thing that makes Mac OS X "special" is that there don't seem to be Python developers who are both knowledgeable and willing to make sure everything works on all versions of the OS. Since you seem to care, why don't you take up the task? -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] [Python-checkins] commit of r41880 - python/trunk/Python/Python-ast.c
[Jeremy Hylton] >> I think this solution is better. It's relatively rare for people to >> change the ast definition, so for most purposes these should be static >> files. [Martin v. Löwis] > Interestingly enough, I found yesterday that Python-ast.c did change for > me, even though I had not touched the AST grammar at all. Assuming > somebody forgot to commit this file, I just did. > > I now investigated where this change originated from, and it was this > commit > > r41812 | tim.peters | 2005-12-26 00:18:31 +0100 (Mo, 26 Dez 2005) | 2 lines > > Whitespace normalization. > > This indicates two problems: apparently, the whitespace normalization > also normalizes string literals; not sure whether this is a good idea > or not. reindent.py never leaves a hard tab character behind, or a line with trailing whitespace. Those are features, because they're invisible, and _someone's_ editor is going to destroy either or both of those sooner or later anyway. No core code should rely on them (inside string literals or not). I don't believe that asdl_c.py requires either hard tab characters or trailing whitespace on lines (both of which reindent.py replaced/removed), and reindent.py's output is a fixed-point for reindent.py, so those shouldn't happen again (unless/until someone sticks hard tabs or trailing whitespace into asdl_c.py again). If someone is really keen to have hard tab characters inside the CODE strings written by this file, then "the right" way to do that is to use \t escapes inside the triple-quoted strings (instead of using embedded hard tab characters). > Furthermore, people should be made aware that something > deserves their attention when they find that Python-ast.c has changed > for them (but I guess Tim never saw Python-ast.c change, because this > build step isn't executed on Windows). I can do better than guess about that ;-) ___ 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] [Python-checkins] commit of r41906 - python/branches/ssize_t/Objects/obmalloc.c
> Author: martin.v.loewis
> Date: Tue Jan 3 14:16:53 2006
> New Revision: 41906
>
> Modified:
>python/branches/ssize_t/Objects/obmalloc.c
> Log:
> Disable 32-bit size limitation for 64-bit mode.
>
>
> Modified: python/branches/ssize_t/Objects/obmalloc.c
> ==
> --- python/branches/ssize_t/Objects/obmalloc.c (original)
> +++ python/branches/ssize_t/Objects/obmalloc.c Tue Jan 3 14:16:53 2006
> @@ -1005,6 +1005,8 @@
>
> bumpserialno();
> total = nbytes + 16;
> +#if SIZEOF_SIZE_T < 8
> + /* XXX do this check only on 32-bit machines */
> if (total < nbytes || (total >> 31) > 1) {
> /* overflow, or we can't represent it in 4 bytes */
> /* Obscure: can't do (total >> 32) != 0 instead, because
> @@ -1013,6 +1015,7 @@
>size_t is an unsigned type. */
> return NULL;
> }
> +#endif
This checkin should be reverted for now. It's in
_PyObject_DebugMalloc, and at present the layout of the extra debug
info in a PYMALLOC_DEBUG build is hard-coded to use 4-byte fields, no
matter what sizeof(size_t) may be. One of the extra fields recorded
in a PYMALLOC_DEBUG build is the number of bytes requested, and at
present it's simply not capable of recording a value that doesn't fit
in 4 bytes.
Even after (if ever ;-)) this is changed to support recording 8-byte
values on a box where sizeof(size_t) == 8, the "total < nbytes" part
of the test would still be appropriate: PyObject_DebugMalloc requests
more memory (`total`) than the user asked for (`nbytes`), and the
computation of `total` may have overflowed. That's what "total <
nbytes" is checking, and that's the right way to spell the overflow
check on any box.
___
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] API changes
Jeremy Hylton <[EMAIL PROTECTED]> writes: > On 1/3/06, Thomas Heller <[EMAIL PROTECTED]> wrote: >> Jeremy Hylton <[EMAIL PROTECTED]> writes: >> > On 1/3/06, Thomas Heller <[EMAIL PROTECTED]> wrote: >> >> The ast-branch merge apparently changed some formerly public functions >> >> to macros. The two that I found out about are PyRun_SimpleString and >> >> PyRun_InteractiveLoop, I have not checked if there are more or not. >> >> >> >> This breaks apps which dynamically link at runtime to the Python dll >> >> (the latest py2exe does this). >> >> > The intent was to provide binary compatibility, but redirect all newly >> > linked code to the newer variants. We did this correctly for >> > PyParser_SimpleParseFile and PyParser_SimpleParseString, but didn't do >> > it for the rest of the changed functions. Can you file a bug report? >> > (Or just fix the ones that bother you.) >> >> I'm not sure I understand the 'we did this correctly for ...'. >> PyParser_SimpleParseFile is a function in 2.4, and a macro in 2.5. > > There's a function by the same name at the end of pythonrun.c. > Nothing in the Python core should link to it, but it's still available > for third-party code. Now we can mark PyParser_SimpleParseFile as > deprecated remove it in some future release. I see. I doesn't help on Windows, though, since the functions are not declared DL_EXPORT(). All in all, I'm unsure if it is worth fixing this - maybe it would be better to change py2exe. Thomas ___ 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] API changes
On 1/3/06, Thomas Heller <[EMAIL PROTECTED]> wrote: > Jeremy Hylton <[EMAIL PROTECTED]> writes: > > On 1/3/06, Thomas Heller <[EMAIL PROTECTED]> wrote: > >> The ast-branch merge apparently changed some formerly public functions > >> to macros. The two that I found out about are PyRun_SimpleString and > >> PyRun_InteractiveLoop, I have not checked if there are more or not. > >> > >> This breaks apps which dynamically link at runtime to the Python dll > >> (the latest py2exe does this). > >> > >> Was this change intentional, or can it be reverted? > >> > >> Thanks, > >> > >> Thomas > >> > > > The intent was to provide binary compatibility, but redirect all newly > > linked code to the newer variants. We did this correctly for > > PyParser_SimpleParseFile and PyParser_SimpleParseString, but didn't do > > it for the rest of the changed functions. Can you file a bug report? > > (Or just fix the ones that bother you.) > > > > We ought to update the docs, too. > > I'm not sure I understand the 'we did this correctly for ...'. > PyParser_SimpleParseFile is a function in 2.4, and a macro in 2.5. There's a function by the same name at the end of pythonrun.c. Nothing in the Python core should link to it, but it's still available for third-party code. Now we can mark PyParser_SimpleParseFile as deprecated remove it in some future release. Jeremy ___ 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] API changes
Jeremy Hylton <[EMAIL PROTECTED]> writes: > On 1/3/06, Thomas Heller <[EMAIL PROTECTED]> wrote: >> The ast-branch merge apparently changed some formerly public functions >> to macros. The two that I found out about are PyRun_SimpleString and >> PyRun_InteractiveLoop, I have not checked if there are more or not. >> >> This breaks apps which dynamically link at runtime to the Python dll >> (the latest py2exe does this). >> >> Was this change intentional, or can it be reverted? >> >> Thanks, >> >> Thomas >> > The intent was to provide binary compatibility, but redirect all newly > linked code to the newer variants. We did this correctly for > PyParser_SimpleParseFile and PyParser_SimpleParseString, but didn't do > it for the rest of the changed functions. Can you file a bug report? > (Or just fix the ones that bother you.) > > We ought to update the docs, too. I'm not sure I understand the 'we did this correctly for ...'. PyParser_SimpleParseFile is a function in 2.4, and a macro in 2.5. Thomas ___ 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] buildbot
> "skip" == skip <[EMAIL PROTECTED]> writes: Bob> The easy fix is to upgrade your OS. I don't think anyone is going Bob> to bother with the preprocessor hackery necessary to make that Bob> (harmless) warning go away on older versions of the OS. skip> Excuse me, but this really pisses me off. Oh, c'mon, Skip. I'm a Panther hold-out, too, but this is just a (soi-disant harmless) warning. Have you tried to build anything from DarwinPorts recently? I have at least 20 modified PortFiles plus at least two patched source files because they can't be bothered to make sure things _build_ on Panther, let alone eliminate warnings. Sure, Python can be expected to do much better than random port maintainers, but Discussions with the port maintainers makes it hard to blame them. They say the development environment has changed enormously---you really need multiple systems because of significant changes in the standard headers, it's nowhere near enough to just keep a couple or six versions of GCC around. And you need multiple dev environments, because Xcode 1.5 doesn't cut it on Tiger, and Xcode 2.x doesn't work at all on Panther. Yes, it would be nice to make the warnings go away, but in view of all that, is it something to get one's shorts in a knot about? -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ 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] API changes
The intent was to provide binary compatibility, but redirect all newly linked code to the newer variants. We did this correctly for PyParser_SimpleParseFile and PyParser_SimpleParseString, but didn't do it for the rest of the changed functions. Can you file a bug report? (Or just fix the ones that bother you.) We ought to update the docs, too. Jeremy On 1/3/06, Thomas Heller <[EMAIL PROTECTED]> wrote: > The ast-branch merge apparently changed some formerly public functions > to macros. The two that I found out about are PyRun_SimpleString and > PyRun_InteractiveLoop, I have not checked if there are more or not. > > This breaks apps which dynamically link at runtime to the Python dll > (the latest py2exe does this). > > Was this change intentional, or can it be reverted? > > Thanks, > > Thomas > > ___ > 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/jeremy%40alum.mit.edu > ___ 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] buildbot
On 3-jan-2006, at 16:46, [EMAIL PROTECTED] wrote: > > Bob> The easy fix is to upgrade your OS. I don't think anyone > is going > Bob> to bother with the preprocessor hackery necessary to make > that > Bob> (harmless) warning go away on older versions of the OS. > > Excuse me, but this really pisses me off. I delayed upgrading from > 10.2 for > awhile and was given the same "advice". I was further told (check > the mac > sig archives) that "you'd be able to stick with 10.3 for much longer" > because new apps wouldn't need to require 10.4. So I upgraded. > Now you're > telling me that it's somehow "obsolete" and that I should upgrade > because > "we can't be bothered to fix a compiler warning"? Python supports > much > older versions of other platforms. What makes Mac OSX so special > in this > regard? This is a completely harmless warning, but I agree it is annoying that older versions of the OS are neglected. At least for me, supporting older versions of OSX is hard. Both my system at work and my private system run 10.4 by default, which means I'll have to reboot and leave my normal work environment to work on older versions. Thanks to the age of my machines "older versions" is limited to 10.3.0 or later, neither machine can boot 10.2. Ronald > > 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/ > ronaldoussoren%40mac.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
[Python-Dev] API changes
The ast-branch merge apparently changed some formerly public functions to macros. The two that I found out about are PyRun_SimpleString and PyRun_InteractiveLoop, I have not checked if there are more or not. This breaks apps which dynamically link at runtime to the Python dll (the latest py2exe does this). Was this change intentional, or can it be reverted? Thanks, Thomas ___ 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] buildbot
Bob> The easy fix is to upgrade your OS. I don't think anyone is going Bob> to bother with the preprocessor hackery necessary to make that Bob> (harmless) warning go away on older versions of the OS. Excuse me, but this really pisses me off. I delayed upgrading from 10.2 for awhile and was given the same "advice". I was further told (check the mac sig archives) that "you'd be able to stick with 10.3 for much longer" because new apps wouldn't need to require 10.4. So I upgraded. Now you're telling me that it's somehow "obsolete" and that I should upgrade because "we can't be bothered to fix a compiler warning"? Python supports much older versions of other platforms. What makes Mac OSX so special in this regard? 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
[Python-Dev] Including zlib...
Martin checked in zlib to the Python svn repository. Are we really sure that including zlib is the only path to whatever it is that it achieves? If security holes in zlib turn up (they have in the past), new Python releases will have to be released quickly. 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] mac memory leaks
On 3 Jan 2006, at 08:58, Neal Norwitz wrote: > I had a friend run regrtest -L on Mac OSX a while ago. There are > several memory leaks which still appear to be an issue. There are a > bunch of leaks reported from putenv which I'm not sure how to fix > > The attached patch should correct one of the problems. Can someone > with a Mac test it? I'll add to SF later if I don't get a response. > > n > -- > > I'm not sure about how to fix these or if they are real problems: > > Leak: 0x02541470 size=368 instance of 'NSCFData' > Call stack: call_function | ici_ICFindPrefHandle | ICFindPrefHandle | > OpaqueICInstance::FindPrefHandle(ICKeyInfo const&, unsigned long*, > char**) | OpaqueICInstance::GetPref(ICKeyInfo const&, long, void*, > long*, unsigned long*) | OpaqueICInstance::GetPrefCore(ICKeyInfo > const&, long, void*, long*, unsigned long*) | > OpaqueICInstance::LazyLoad() | ICCFPrefWrapper::ContainsPrefs() | > ICCFPrefWrapper::GetPrefDictionary() | fetchXMLValue | > _loadXMLDomainIfStale | _CFPropertyListCreateFromXMLData | > __CFTryParseBinaryPlist | __CFBinaryPlistCreateObject | > __CFBinaryPlistCreateObject | __CFBinaryPlistCreateObject | > __CFBinaryPlistCreateObject | __CFBinaryPlistCreateObject | > __CFDataInit | _CFRuntimeCreateInstance | CFAllocatorAllocate This is somewhere down in the Internet Config builtin module, which would point to the webbrowser library module. My guess is that it's a singleton leak. > > Leak: 0x02506640 size=256 > Call stack: call_function | do_call | PyObject_Call | parser_st2tuple > | node2tuple | node2tuple | node2tuple | node2tuple | node2tuple | > node2tuple | node2tuple | node2tuple | node2tuple | node2tuple | > node2tuple | node2tuple | node2tuple | node2tuple | node2tuple | > node2tuple | node2tuple | node2tuple | node2tuple | node2tuple | > node2tuple | PyTuple_New | _PyObject_GC_NewVar | _PyObject_GC_Malloc | > PyObject_Malloc | new_arena No idea. There don't seem to be any mac-specific modules involved... > Leak: 0x0118ad10 size=80 > Call stack: call_function | AE_AECreateDesc | AECreateDesc | operator > new(unsigned long) Hmm, the first candidates here would be test_aepack and test_scriptpackages, but neither one has an obvious leak (on cursory inspection). And actually, if there was a leak problem in either I would expect more than one AEDesc to be leaked. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ 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] [Python-checkins] commit of r41880 - python/trunk/Python/Python-ast.c
On Mon, 2006-01-02 at 15:16 -0800, Neal Norwitz wrote: > On 1/2/06, Barry Warsaw <[EMAIL PROTECTED]> wrote: > > I think we have a fundamental problem with Python-ast.c and > > Python-ast.h. These files should not be both auto-generated and checked > > into Subversion. > > I agree with the problem statement. > > > The general rule should be that no file that is ever generated can be > > checked into Subversion. Probably the right approach is to check in a > > template file that will not get removed by a distclean, and modify the > > build process to generate Python-ast.* from those template files. > > I'm not sure about your proposed solution, though. > > There's a bootstrapping issue. Python-ast.[ch] are generated by a > python 2.2+ script. /f created a bug report if only 2.1 is available. > > The Python-ast.[ch] should probably not be removed by distclean. This > is similar to configure. Would that make you happy? What else would > improve the current situation? > > If you go the template route, you would just copy the files. That > doesn't seem to gain anything. The solution I use is to never have anything auto-generated in CVS/SVN, but have "make dist" generate and include anything needed for bootstrapping in the distribution tarball (or whatever). Doing "make distclean" should delete enough to bring you back to a freshly extracted distribution tarball, and "make maintainer-clean" should delete all auto-generated files to bring you back to a clean CVS/SVN checkout. I tend to include quite a few generated files in the distribution tarball that are not in CVS/RCS. Things like ChangeList (generated by cvs2cl), all the autotools autogen'ed files, generated datafiles, etc. This way your source distributions don't have any bootstrap problems, but you also don't have any auto-generated files in CVS/SVN and the problems they create. It does however mean that a fresh CVS/SVN checkout does have additional build requirements above and beyond building from a source distribution. -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ ___ 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] [Python-checkins] commit of r41880 - python/trunk/Python/Python-ast.c
Jeremy Hylton wrote: > I think this solution is better. It's relatively rare for people to > change the ast definition, so for most purposes these should be static > files. Interestingly enough, I found yesterday that Python-ast.c did change for me, even though I had not touched the AST grammar at all. Assuming somebody forgot to commit this file, I just did. I now investigated where this change originated from, and it was this commit r41812 | tim.peters | 2005-12-26 00:18:31 +0100 (Mo, 26 Dez 2005) | 2 lines Whitespace normalization. This indicates two problems: apparently, the whitespace normalization also normalizes string literals; not sure whether this is a good idea or not. Furthermore, people should be made aware that something deserves their attention when they find that Python-ast.c has changed for them (but I guess Tim never saw Python-ast.c change, because this build step isn't executed on Windows). Regards, Martin ___ 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] buildbot
Neal Norwitz wrote: > If adding a slave for the trunk: [...] > If adding a slave for the 2.4 branch: Currently, branches are not supported, because buildbot is somewhat limited. When I get a solution for this problem, I plan to have all buildbots build both the trunk and the 2.4 branch; such builds would only be initiated whenever something is committed on the branch. > To ensure buildbot is started on reboot: > >(crontab -l | egrep -v '^#' ; echo "@reboot /usr/bin/buildbot start > $DIR") | crontab - AFAICT, this assumes Vixie cron, which is fine for Linux, but I don't think it would work on, say, Solaris (atleast I couldn't find anything in the documentation of Solaris cron that suggests "@reboot" lines are supported). Regards, Martin ___ 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
