On Tue, Nov 9, 2010 at 04:07, R. David Murray wrote:
> On Mon, 08 Nov 2010 18:10:17 -0600, Ron Adam wrote:
> > def _private_api():
> > #
> > # Isn't it a good practice to use comments here?
> > #
> > ...
>
> IMO, no.
>
>
FWIW, I agree completely. Docstrings are a part of Pyth
On 11/08/2010 10:26 PM, Nick Coghlan wrote:
On Tue, Nov 9, 2010 at 11:18 AM, Ron Adam 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 uncha
On Tue, Nov 9, 2010 at 1:28 PM, Alexander Belopolsky
wrote:
> On Mon, Nov 8, 2010 at 2:58 PM, Brett Cannon 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.
Indeed. I've now recommended Ron do exactly t
On 11/08/2010 07:18 PM, Brett Cannon wrote:
On Mon, Nov 8, 2010 at 16:10, Ron Adam 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 anything else.
On Tue, Nov 9, 2010 at 11:18 AM, Ron Adam 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 lot more
> ch
On Mon, Nov 8, 2010 at 2:58 PM, Brett Cannon 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
___
Python-Dev mailing l
On Mon, 08 Nov 2010 18:10:17 -0600, Ron Adam wrote:
> def _private_api():
> #
> # Isn't it a good practice to use comments here?
> #
> ...
IMO, no.
--
R. David Murray www.bitdance.com
___
Python-
On 12:50 am, gu...@python.org wrote:
On Mon, Nov 8, 2010 at 3:55 PM, Glyph Lefkowitz
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
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 user
On Tue, Nov 09, 2010 at 11:46:59AM +1100, Ben Finney wrote:
> Ron Adam 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 interpret
On Mon, Nov 8, 2010 at 4:46 PM, Ben Finney wrote:
> Ron Adam 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()’,
On Mon, Nov 8, 2010 at 16:10, Ron Adam 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 docum
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 3:55 PM, Glyph Lefkowitz 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 the sense of
> 'inst
Ron Adam 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’, and mo
Bobby Impollonia writes:
> On Mon, Nov 8, 2010 at 2:07 PM, Raymond Hettinger
> 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 at least declare the parts that are
>
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 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, wrote:
>>> On 09:25 pm, br...@python.org wrote:
On Mon, Nov 8, 2010 at 13:03, wrote:
>
> On 07:58 pm, br...@python.org wrote:
>>>
>
On Mon, Nov 8, 2010 at 3:26 PM, Bobby Impollonia wrote:
> On Mon, Nov 8, 2010 at 2:07 PM, Raymond Hettinger
> 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
On Mon, Nov 8, 2010 at 2:07 PM, Raymond Hettinger
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 APIs, or are they p
2010/11/8 James Y Knight :
> 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
>>
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 bet
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, docstr
On 09:57 pm, br...@python.org wrote:
On Mon, Nov 8, 2010 at 13:45, wrote:
On 09:25 pm, br...@python.org wrote:
On Mon, Nov 8, 2010 at 13:03, � 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.
> 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
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 inte
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
On Mon, Nov 8, 2010 at 13:36, Ron Adam wrote:
>
>
> On 11/08/2010 01:58 PM, Brett Cannon wrote:
>>
>> On Mon, Nov 8, 2010 at 09:20, Alexander Belopolsky
>> wrote:
>>>
>>> Was: [issue2001] Pydoc interactive browsing enhancement
>>>
>>> On Sun, Nov 7, 2010 at 9:17 AM, Nick Coghlan
>>> wrote:
>>>
On Mon, Nov 8, 2010 at 13:45, wrote:
> On 09:25 pm, br...@python.org wrote:
>>
>> On Mon, Nov 8, 2010 at 13:03, 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 const
On 11/08/2010 01:58 PM, Brett Cannon wrote:
On Mon, Nov 8, 2010 at 09:20, Alexander Belopolsky
wrote:
Was: [issue2001] Pydoc interactive browsing enhancement
On Sun, Nov 7, 2010 at 9:17 AM, Nick Coghlan wrote:
..
I'd actually started typing out the command to commit this before it finall
On 09:25 pm, br...@python.org wrote:
On Mon, Nov 8, 2010 at 13:03, 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 indefi
On Mon, Nov 8, 2010 at 13:03, 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 don't even know
Jeroen Ruigrok van der Werven 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
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,
On Nov 8, 2010, at 11:28 AM, Alexander Belopolsky wrote:
> On Mon, Nov 8, 2010 at 7:09 AM, Michael Foord
> 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/?
Michael's instinct to
On Mon, Nov 8, 2010 at 09:20, Alexander Belopolsky
wrote:
> Was: [issue2001] Pydoc interactive browsing enhancement
>
> On Sun, Nov 7, 2010 at 9:17 AM, Nick Coghlan wrote:
> ..
>>
>> I'd actually started typing out the command to commit this before it finally
>> clicked that the patch changes pu
On Mon, Nov 8, 2010 at 7:09 AM, Michael Foord 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 or some other package
On Mon, Nov 8, 2010 at 04:09, Michael Foord 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 project but I be
On Mon, Nov 8, 2010 at 1:39 PM, Michael Foord 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. However, as far
as I kn
On Mon, Nov 8, 2010 at 1:39 PM, Michael Foord 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. However, as far
as I
On Mon, Nov 8, 2010 at 12:35 PM, Michael Foord
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 be fixed in a function you
On Mon, Nov 8, 2010 at 12:35 PM, Michael Foord
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?
___
Python-Dev mailing list
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 Coghlan wrote:
..
I'd actually started typing out the command to commit this before it finally
clicked that the patch changes public
APIs of the pyd
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 publi
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 running
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 --wi
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 ther
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 orde
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 python
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 python
Was: [issue2001] Pydoc interactive browsing enhancement
On Sun, Nov 7, 2010 at 9:17 AM, Nick Coghlan 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 ways. Sure, they aren
On Mon, 08 Nov 2010 17:02:24 +0100, 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 (especially consider
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/08/2010 04:42 AM, Lennart Regebro wrote:
> 2010/10/28 Kristján Valur Jónsson :
>> 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 m
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
c
[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 wa
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,
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).
Current
> 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/
>> 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 w
>> 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
-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 fir
-On [20101108 00:36], David Bolen (db3l@gmail.com) wrote:
>Victor Stinner 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 by default
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:
http://sou
On Mon, Nov 8, 2010 at 10:09 AM, "Martin v. Löwis" 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 start bashi
On Sun, Nov 7, 2010 at 13:15, Dirkjan Ochtman 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
___
Python-Dev mailing
On Mon, Nov 8, 2010 at 7:05 PM, Jeroen Ruigrok van der Werven
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 semaphore issue
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 th
On Wed, Oct 27, 2010 at 12:36, Antoine Pitrou wrote:
> On Wed, 27 Oct 2010 10:13:12 +0800
> Kristján Valur Jónsson wrote:
>> Although 2.7 has the new buffer interface and memoryview
>> objects, these are widely not accepted in the built in modules.
>
> That's true, and slightly unfortunate. It co
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 situa
2010/10/28 Kristján Valur Jónsson :
> 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 must it be that
-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
> 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
http://mail.py
73 matches
Mail list logo
