That is true, however it doesn't help you: the hook takes its configuration
from the hgrc file, so you can configure exactly one host:port to send
changes to.
Ah, ok.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
-On [20101107 12:52], Nick Coghlan (ncogh...@gmail.com) wrote:
This sounds like a great place to start. Perhaps focus on one or two
of the less common platforms first (e.g. FreeBSD 7 has been hitting a
few semaphore issues lately).
Nick, do you have some pointers for this? I am one of those BSD
2010/10/28 Kristján Valur Jónsson krist...@ccpgames.com:
Hello all.
So, python 2.7 is in bugfix only mode. ‘trunk’ is off limit. So, where
does one make improvements to the distinguished, and still very much alive,
2.x series of Python?
The answer would seem to be “one doesn’t”. But
Hi David,
Valery, I would advise you to submit the patch to bugs.python.org when
it comes back up. Patches posted to this mailing list will in general
just get forgotten.
done:
http://bugs.python.org/issue10351
http://bugs.python.org/issue10352
Albeit, as I can already see the situation
On Wed, Oct 27, 2010 at 12:36, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 27 Oct 2010 10:13:12 +0800
Kristján Valur Jónsson krist...@ccpgames.com wrote:
Although 2.7 has the new buffer interface and memoryview
objects, these are widely not accepted in the built in modules.
That's
All,
I was about to commit the patch for issue 2001 (the improvements to
the pydoc web server and the removal of the Tk GUI) when I realised
that pydoc.serve() and pydoc.gui() are technically public standard
library APIs (albeit undocumented ones).
Currently the patch switches serve() to start
On Mon, Nov 8, 2010 at 7:05 PM, Jeroen Ruigrok van der Werven
asmo...@in-nomine.org wrote:
-On [20101107 12:52], Nick Coghlan (ncogh...@gmail.com) wrote:
This sounds like a great place to start. Perhaps focus on one or two
of the less common platforms first (e.g. FreeBSD 7 has been hitting a
few
On Sun, Nov 7, 2010 at 13:15, Dirkjan Ochtman dirk...@ochtman.nl wrote:
Yeah, Martin has things for buildbot worked out. Notes about this are
in the hg.python.org/pymigr repository.
I meant Georg here, of course. Sorry, Georg!
Cheers,
Dirkjan
___
On Mon, Nov 8, 2010 at 10:09 AM, Martin v. Löwis mar...@v.loewis.de wrote:
Luckily, the problems that we faced 2.5 years ago when I came up with
the idea of Snakebite are still just as ever present today ;-)
Is this bashing of existing infrastructure really necessary?
People (like me) might
Hello all,
Now that unittest has test discovery, Mark Roddy has been working on
resurrecting the old GUI test runner (using Tkinter):
https://bitbucket.org/markroddy/unittestgui
This was part of the original pyunit project but I believe it was never
part of the standard library:
-On [20101108 00:36], David Bolen (db3l@gmail.com) wrote:
Victor Stinner victor.stin...@haypocalc.com writes:
Well, I think the SYSV semaphores are either less limited or at least
more adjustable. They've certainly been around longer in FreeBSD.
The POSIX semaphore support is not enabled
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/11/10 13:55, Nick Coghlan wrote:
Under -We, PyErr_Warn raises an exception rather than printing to
stdout. That exception is clobbered by the immediately following call
to PyErr_Clear.
Since you *only* hit that branch under -We in the first
New Revision: 86276
Log:
Fix #10252 again (hopefully definitely). Patch by Brian Curtin.
It seems this and previous fixes should be backported to 2.7.
Certainly. I was waiting on buildbot feedback before doing it.
Regards
___
Python-Dev
It seems this and previous fixes should be backported to 2.7.
Perhaps there should be a 'backport 2.7' keyword to check on issues that
might be but have not been.
The “Your issues” list is very helpful and works well for me. This bug
is still open and assigned to me (and opened in my web
Author: hirokazu.yamamoto
New Revision: 86300
Log:
Issue #6317: Now winsound.PlaySound only accepts unicode with MvL's approval.
Modified: python/branches/py3k/Misc/NEWS
==
--- python/branches/py3k/Misc/NEWS
On 11:44 am, ncogh...@gmail.com wrote:
All,
I was about to commit the patch for issue 2001 (the improvements to
the pydoc web server and the removal of the Tk GUI) when I realised
that pydoc.serve() and pydoc.gui() are technically public standard
library APIs (albeit undocumented ones).
On Nov 8, 2010, at 4:42 AM, Lennart Regebro wrote:
Except for making releases that start backporting Python 3 features
and breaking backwards compatibility gradually (which may or may not
be a good idea) I don't see the point. There isn't much to do when it
comes to improving the language, and
[Martin]
It's rather a matter of agreeing when moving forward: IMO, mere style
changes, code cleanup etc shouldn't be applied to the bug fix branches,
as their only purpose is to provide bug fixes for existing users.
[Terry]
The omission of the deletion from the 5/5 revision was a bug in
Hi Nick,
If there is no enormous difficulty in maintaining compatibility, I think
the usual deprecation process should be followed. We don’t know who is
using pydoc as a library, so let’s play safe and not risk breaking their
code (especially considering that it must not have been easy to write
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/08/2010 04:42 AM, Lennart Regebro wrote:
2010/10/28 Kristján Valur Jónsson krist...@ccpgames.com:
Hello all.
So, python 2.7 is in bugfix only mode. ‘trunk’ is off limit. So, where
does one make improvements to the distinguished, and
Am 08.11.2010 17:02, schrieb Éric Araujo:
Hi Nick,
If there is no enormous difficulty in maintaining compatibility, I think
the usual deprecation process should be followed. We don’t know who is
using pydoc as a library, so let’s play safe and not risk breaking their
code (especially
On Mon, 08 Nov 2010 17:02:24 +0100, mer...@netwok.org wrote:
If there is no enormous difficulty in maintaining compatibility, I think
the usual deprecation process should be followed. We donât know who is
using pydoc as a library, so letâs play safe and not risk breaking their
code
Was: [issue2001] Pydoc interactive browsing enhancement
On Sun, Nov 7, 2010 at 9:17 AM, Nick Coghlan rep...@bugs.python.org wrote:
..
I'd actually started typing out the command to commit this before it finally
clicked that the patch changes public
APIs of the pydoc module in incompatible
Was: [issue2001] Pydoc interactive browsing enhancement
[snip...]
This suggests that trace.find_strings() should probably be preserved
or properly deprecated. If this is the case, should we fix bugs in
it? Note that it currently has a bug because it ignores the coding
cookie when opening
Was: [issue2001] Pydoc interactive browsing enhancement
[snip...]
This suggests that trace.find_strings() should probably be preserved
or properly deprecated. If this is the case, should we fix bugs in
it? Note that it currently has a bug because it ignores the coding
cookie when opening
Le lundi 08 novembre 2010 à 18:46 +0100, Sébastien Sablé a écrit :
xlc: 1501-216 (W) command option - -qmaxmem=18000 is not recognized -
passed to ld
Is -qmaxmem really necessary to build Python?
If so, you could try passing it in CFLAGS.
However running 2 different slaves per host in order
On Mon, Nov 08, 2010 at 06:50:32PM +0100, Antoine Pitrou wrote:
However running 2 different slaves per host in order to distinguish xlc
and gcc would be OK; though I would appreciate if they could run
sequentially rather than in parallel as that would limit the host load.
If there are
Hi Antoine,
I tried to provide command lines arguments to configure instead of
environment variables with:
configureFlags = [--with-pydebug, --without-computed-gotos,
CC=xlc, 'OPT=-O2 -qmaxmem=18000']
But that would fail: on the slave, configure would run like that:
./configure
On 05:50 pm, solip...@pitrou.net wrote:
Le lundi 08 novembre 2010 � 18:46 +0100, S�bastien Sabl� a �crit :
xlc: 1501-216 (W) command option - -qmaxmem=18000 is not recognized -
passed to ld
Is -qmaxmem really necessary to build Python?
If so, you could try passing it in CFLAGS.
However
On 11/08/2010 09:12 AM, exar...@twistedmatrix.com wrote:
On 11:44 am, ncogh...@gmail.com wrote:
All,
I was about to commit the patch for issue 2001 (the improvements to
the pydoc web server and the removal of the Tk GUI) when I realised
that pydoc.serve() and pydoc.gui() are technically
On 11/8/2010 12:20 PM, Alexander Belopolsky wrote:
Was: [issue2001] Pydoc interactive browsing enhancement
On Sun, Nov 7, 2010 at 9:17 AM, Nick Coghlanrep...@bugs.python.org wrote:
..
I'd actually started typing out the command to commit this before it finally
clicked that the patch changes
On Mon, Nov 8, 2010 at 12:35 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
..
If you deprecate it then you don't *have* to fix bugs in it. If we know it
is used then we can't remove it without deprecation.
What about the maintenance branch?
___
On Mon, Nov 8, 2010 at 12:35 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
..
If you deprecate it then you don't *have* to fix bugs in it. If we know it
is used then we can't remove it without deprecation.
What about the maintenance branch?
So you have a bug in the module that can only
On Mon, Nov 8, 2010 at 1:39 PM, Michael Foord fuzzy...@voidspace.org.uk wrote:
..
So you have a bug in the module that can only be fixed in a function you
want to deprecate?
No, I have a bug in a function that I want to deprecate. You said I
don't need to fix it if I add a deprecation warning.
On Mon, Nov 8, 2010 at 1:39 PM, Michael Foordfuzzy...@voidspace.org.uk wrote:
..
So you have a bug in the module that can only be fixed in a function you
want to deprecate?
No, I have a bug in a function that I want to deprecate. You said I
don't need to fix it if I add a deprecation
On Mon, Nov 8, 2010 at 04:09, Michael Foord mich...@voidspace.org.uk wrote:
Hello all,
Now that unittest has test discovery, Mark Roddy has been working on
resurrecting the old GUI test runner (using Tkinter):
https://bitbucket.org/markroddy/unittestgui
This was part of the original pyunit
On Mon, Nov 8, 2010 at 7:09 AM, Michael Foord mich...@voidspace.org.uk wrote:
..
I'd like to propose adding [unittestgui] to Python in Tools/ and am
volunteering to
maintain it.
Why not adding it under Lib/unittest/? I think Tools/ is a less
attractive location for most users than say PyPI
On Mon, Nov 8, 2010 at 09:20, Alexander Belopolsky
belopol...@users.sourceforge.net wrote:
Was: [issue2001] Pydoc interactive browsing enhancement
On Sun, Nov 7, 2010 at 9:17 AM, Nick Coghlan rep...@bugs.python.org wrote:
..
I'd actually started typing out the command to commit this before
On Nov 8, 2010, at 11:28 AM, Alexander Belopolsky wrote:
On Mon, Nov 8, 2010 at 7:09 AM, Michael Foord mich...@voidspace.org.uk
wrote:
..
I'd like to propose adding [unittestgui] to Python in Tools/ and am
volunteering to
maintain it.
Why not adding it under Lib/unittest/?
On 07:58 pm, br...@python.org wrote:
I don't think a strict don't remove without deprecation policy is
workable. �For example, is trace.rx_blank constant part of the trace
module API that needs to be preserved indefinitely? �I don't even know
if it is possible to add a deprecation warning to it,
Jeroen Ruigrok van der Werven asmo...@in-nomine.org writes:
-On [20101108 00:36], David Bolen (db3l@gmail.com) wrote:
Well, I think the SYSV semaphores are either less limited or at least
more adjustable. They've certainly been around longer in FreeBSD.
The POSIX semaphore support
On Mon, Nov 8, 2010 at 13:03, exar...@twistedmatrix.com wrote:
On 07:58 pm, br...@python.org wrote:
I don't think a strict don't remove without deprecation policy is
workable. For example, is trace.rx_blank constant part of the trace
module API that needs to be preserved indefinitely? I
On 09:25 pm, br...@python.org wrote:
On Mon, Nov 8, 2010 at 13:03, exar...@twistedmatrix.com wrote:
On 07:58 pm, br...@python.org wrote:
I don't think a strict don't remove without deprecation policy is
workable. �For example, is trace.rx_blank constant part of the trace
module API that
On 11/08/2010 01:58 PM, Brett Cannon wrote:
On Mon, Nov 8, 2010 at 09:20, Alexander Belopolsky
belopol...@users.sourceforge.net wrote:
Was: [issue2001] Pydoc interactive browsing enhancement
On Sun, Nov 7, 2010 at 9:17 AM, Nick Coghlanrep...@bugs.python.org wrote:
..
I'd actually started
On Mon, Nov 8, 2010 at 13:45, exar...@twistedmatrix.com wrote:
On 09:25 pm, br...@python.org wrote:
On Mon, Nov 8, 2010 at 13:03, exar...@twistedmatrix.com wrote:
On 07:58 pm, br...@python.org wrote:
I don't think a strict don't remove without deprecation policy is
workable. For
On Mon, Nov 8, 2010 at 13:36, Ron Adam r...@ronadam.com wrote:
On 11/08/2010 01:58 PM, Brett Cannon wrote:
On Mon, Nov 8, 2010 at 09:20, Alexander Belopolsky
belopol...@users.sourceforge.net wrote:
Was: [issue2001] Pydoc interactive browsing enhancement
On Sun, Nov 7, 2010 at 9:17 AM,
On Nov 8, 2010, at 11:58 AM, Brett Cannon wrote:
I think we need to, as a group, decide how to handle undocumented APIs
that don't have a leading underscore: they get treated just the same
as the documented APIs, or are they private regardless and thus we can
change them at our whim?
To
Ron Adam wrote:
My understanding is that anything with an actual docstring is part of
the public API.
I frequently add docstrings to _private functions. Just because it is
private doesn't mean I don't want documentation for it, and it is very
handy for running doctests.
Yes, I test my
Author: r.david.murray
New Revision: 86327
Log: #10321: Add support for sending binary DATA and Message objects to
smtplib
Modified: python/branches/py3k/Doc/includes/email-mime.py
==
# Send the email via our
On 09:57 pm, br...@python.org wrote:
On Mon, Nov 8, 2010 at 13:45, exar...@twistedmatrix.com wrote:
On 09:25 pm, br...@python.org wrote:
On Mon, Nov 8, 2010 at 13:03, �exar...@twistedmatrix.com wrote:
On 07:58 pm, br...@python.org wrote:
I don't think a strict don't remove without
On 11/8/2010 4:36 PM, Ron Adam wrote:
My understanding is that anything with an actual docstring is part of
the public API. Any thing with a leading underscore is private.
When the trace module was written, the rule seems to have been more
like: docs (but no docstrings) for public API,
On 11/8/2010 2:58 PM, Brett Cannon wrote:
I think we need to, as a group, decide how to handle undocumented APIs
that don't have a leading underscore: they get treated just the same
as the documented APIs, or are they private regardless and thus we can
change them at our whim?
How about in
2010/11/8 James Y Knight f...@fuhm.net:
On Nov 8, 2010, at 4:42 AM, Lennart Regebro wrote:
Except for making releases that start backporting Python 3 features
and breaking backwards compatibility gradually (which may or may not
be a good idea) I don't see the point. There isn't much to do when
On Mon, Nov 8, 2010 at 2:07 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Nov 8, 2010, at 11:58 AM, Brett Cannon wrote:
I think we need to, as a group, decide how to handle undocumented APIs
that don't have a leading underscore: they get treated just the same
as the documented
On Nov 8, 2010, at 2:35 PM, exar...@twistedmatrix.com wrote:
On 09:57 pm, br...@python.org wrote:
On Mon, Nov 8, 2010 at 13:45, exar...@twistedmatrix.com wrote:
On 09:25 pm, br...@python.org wrote:
On Mon, Nov 8, 2010 at 13:03, exar...@twistedmatrix.com wrote:
On 07:58 pm,
On 11/08/2010 04:01 PM, Brett Cannon wrote:
My understanding is that anything with an actual docstring is part of the
public API. Any thing with a leading underscore is private.
That's a bad rule. Why shouldn't I be able to document something that
is not meant for the public so that fellow
On Mon, Nov 8, 2010 at 3:26 PM, Bobby Impollonia bob...@gmail.com wrote:
On Mon, Nov 8, 2010 at 2:07 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Nov 8, 2010, at 11:58 AM, Brett Cannon wrote:
I think we need to, as a group, decide how to handle undocumented APIs
that don't
Bobby Impollonia bob...@gmail.com writes:
On Mon, Nov 8, 2010 at 2:07 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
To start with, it doesn't hurt for a maintainer to add an __all__
entry and to only document the parts of the API we think need to be
exposed. That way, we can
Ron Adam r...@ronadam.com writes:
def _publicly_documented_private_api():
Not sure why you would want to do this
instead of using comments.
...
Because the docstring is available at the interpreter via ‘help()’, and
because it's automatically available to ‘doctest’,
On Mon, Nov 8, 2010 at 3:55 PM, Glyph Lefkowitz gl...@twistedmatrix.com wrote:
This seems like a pretty clear case of practicality beats purity. Not only
has nobody complained about deprecatedModuleAttribute, but there are tons of
things which show up in sys.modules that aren't modules in
On 11/08/2010 05:44 AM, Nick Coghlan wrote:
All,
I was about to commit the patch for issue 2001 (the improvements to
the pydoc web server and the removal of the Tk GUI) when I realised
that pydoc.serve() and pydoc.gui() are technically public standard
library APIs (albeit undocumented ones).
On Mon, Nov 8, 2010 at 16:10, Ron Adam r...@ronadam.com wrote:
On 11/08/2010 04:01 PM, Brett Cannon wrote:
My understanding is that anything with an actual docstring is part of the
public API. Any thing with a leading underscore is private.
That's a bad rule. Why shouldn't I be able to
On Mon, Nov 8, 2010 at 4:46 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Ron Adam r...@ronadam.com writes:
def _publicly_documented_private_api():
Not sure why you would want to do this
instead of using comments.
...
Because the docstring is available at the
On Tue, Nov 09, 2010 at 11:46:59AM +1100, Ben Finney wrote:
Ron Adam r...@ronadam.com writes:
def _publicly_documented_private_api():
Not sure why you would want to do this
instead of using comments.
...
Because the docstring is available at the interpreter
On Monday 08 November 2010 13:23:33 Jeroen Ruigrok van der Werven wrote:
The POSIX semaphore support is not enabled by default in FreeBSD 7, so
I added loader.conf stuff to load them (as part of issue7272).
It is enabled by default on FreeBSD 8 at least.
Ok, but I suppose that many users use
On 12:50 am, gu...@python.org wrote:
On Mon, Nov 8, 2010 at 3:55 PM, Glyph Lefkowitz
gl...@twistedmatrix.com wrote:
This seems like a pretty clear case of practicality beats purity.
Not only has nobody complained about deprecatedModuleAttribute, but
there are tons of things which show up in
On Mon, 08 Nov 2010 18:10:17 -0600, Ron Adam r...@ronadam.com wrote:
def _private_api():
#
# Isn't it a good practice to use comments here?
#
...
IMO, no.
--
R. David Murray www.bitdance.com
On Mon, Nov 8, 2010 at 2:58 PM, Brett Cannon br...@python.org wrote:
..
But that doesn't mean we can't go through, fix up our names, and
deprecate the old public names; that's fair game in my book.
+1
See http://bugs.python.org/issue10371
___
On Tue, Nov 9, 2010 at 11:18 AM, Ron Adam r...@ronadam.com wrote:
What do you think about adding a new _pydoc3.py module along with a
pydoc3.py loader module with a basic user api. The number 3, so that it
match's python3.x.
We can then keep the old pydoc.py unchanged and be free to make a
On 11/08/2010 07:18 PM, Brett Cannon wrote:
On Mon, Nov 8, 2010 at 16:10, Ron Adamr...@ronadam.com wrote:
def _private_api():
#
# Isn't it a good practice to use comments here?
#
...
That is ugly. I already hate doing that for unittest, I'm not about to
champion that for
On Tue, Nov 9, 2010 at 1:28 PM, Alexander Belopolsky
belopol...@users.sourceforge.net wrote:
On Mon, Nov 8, 2010 at 2:58 PM, Brett Cannon br...@python.org wrote:
..
But that doesn't mean we can't go through, fix up our names, and
deprecate the old public names; that's fair game in my book.
On 11/08/2010 10:26 PM, Nick Coghlan wrote:
On Tue, Nov 9, 2010 at 11:18 AM, Ron Adamr...@ronadam.com wrote:
What do you think about adding a new _pydoc3.py module along with a
pydoc3.py loader module with a basic user api. The number 3, so that it
match's python3.x.
We can then keep the
On Tue, Nov 9, 2010 at 04:07, R. David Murray rdmur...@bitdance.com wrote:
On Mon, 08 Nov 2010 18:10:17 -0600, Ron Adam r...@ronadam.com wrote:
def _private_api():
#
# Isn't it a good practice to use comments here?
#
...
IMO, no.
FWIW, I agree completely.
73 matches
Mail list logo
