Re: [Python-Dev] Snakebite, buildbot and low hanging fruit -- feedback wanted! (Was Re: SSH access against buildbot boxes)

[Martin v. Löwis]

> 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.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Snakebite, buildbot and low hanging fruit -- feedback wanted! (Was Re: SSH access against buildbot boxes)

[Jeroen Ruigrok van der Werven]

-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 Python
users/coders and would like to resolve any issues.

By default FreeBSD 7, at least, has limits on semaphores and the likes, but
those can be expanded.

-- 
Jeroen Ruigrok van der Werven  / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Hypocrisy is the homage which vice pays to virtue...
___
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] Continuing 2.x

[Lennart Regebro]

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 way?

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 there is a moratorium anyway.
Improvements in the standard library can be more easily done in
external libraries anyway, and then you can release the improved
libraries for everything from Python 2.4 and forwards if you like.

So it can be done, but the question is "Why?"

--
Lennart Regebro, Colliberty: http://www.colliberty.com/
Telephone: +48 691 268 328
___
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] bugs.python.org not responding (Was: rlcompleter -- auto-complete dictionary keys (+ tests))

[Valery Khamenya]

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 with changes in 2.x trunk isn't
much simple.
I hope the patch won't go forgotten. (After all we here still rely very much
on 2.x)

regards,
Valery.
___
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] new buffer in python2.7

[Lennart Regebro]

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 could be a reason for
> switching to 3.1/3.2 :-)

It's rather a reason against it, as it makes supporting both Python 2
and Python 3 harder.
However, fixing this in 2.7 just means that you need to support 2.7x
or later only, so it's not a good solution.
I think using compatibility types is a better solution. I suggested
something like that for inclusion in "six", but it was softly
rejected. :-)

Something like this, for example. It's a str in Python2 and a Bytes in
Python3, but it extends both classes with a consistent interface.
Improvements, comments and ideas are welcome.

bites.py:

import sys
if sys.version < '3':
class Bites(str):
def __new__(cls, value):
if isinstance(value[0], int):
# It's a list of integers
value = ''.join([chr(x) for x in value])
return super(Bites, cls).__new__(cls, value)

def itemint(self, index):
return ord(self[index])

def iterint(self):
for x in self:
yield ord(x)
else:

class Bites(bytes):
def __new__(cls, value):
if isinstance(value, str):
# It's a unicode string:
value = value.encode('ISO-8859-1')
return super(Bites, cls).__new__(cls, value)

def itemint(self, x):
return self[x]

def iterint(self):
for x in self:
yield x


-- 
Lennart Regebro: http://regebro.wordpress.com/
Python 3 Porting: http://python3porting.com/
+33 661 58 14 64
___
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] Backward incompatible API changes in the pydoc module

[Nick Coghlan]

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 the new server
implementation and gui() to start the server and open a browser window
for it.

It occurred to me that, despite the "it's an application" feel to the
pydoc web server APIs, it may be a better idea to leave the two
existing functions alone (aside from adding DeprecationWarning), and
using new private function names to start the new server and the web
browser.

Is following the standard deprecation procedure the better course
here, or am I being overly paranoid?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] Snakebite, buildbot and low hanging fruit -- feedback wanted! (Was Re: SSH access against buildbot boxes)

[Nick Coghlan]

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 issues lately).
>
> Nick, do you have some pointers for this? I am one of those BSD Python
> users/coders and would like to resolve any issues.
>
> By default FreeBSD 7, at least, has limits on semaphores and the likes, but
> those can be expanded.

Possibly a bad example on my part, since David and Victor actually
seem to be making reasonable progress in tracking down the problem:
http://mail.python.org/pipermail/python-dev/2010-November/105334.html

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] Snakebite, buildbot and low hanging fruit -- feedback wanted! (Was Re: SSH access against buildbot boxes)

[Dirkjan Ochtman]

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 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] Snakebite, buildbot and low hanging fruit -- feedback wanted! (Was Re: SSH access against buildbot boxes)

[Nick Coghlan]

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 bashing about vaporware and how
> a bird in the hand is worth two in the bush. Cooperate, don't
> confront.

I don't believe the comment was meant to be a slight on the efforts of
the current infrastructure maintainers.

I took Trent's message as referring to the problems Giampaolo
mentioned in the original post (i.e. the ability to grant buildbot
access in an easy-to-use way to existing core developers without
burdening every buildbot operator with decisions as to who they can
trust with access to their buildbot). Buildbot (and similar tools) are
fine for what they do, but there are some problems like this that they
don't even *try* to solve (because they aren't software problems -
they're dependent on physical infrastructure).

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] GUI test runner tool

[Michael Foord]

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://sourceforge.net/projects/pyunit/

Here's a screenshot of what it looks like:

http://skitch.com/fuzzyman/dhu9r/pyunit

I'd like to propose adding it to Python in Tools/ and am volunteering to 
maintain it. If the answer is "not yet" that is fine as it can go into 
unittest2 first. Mark has updated it to work with test discovery and 
added support for configuring test discovery in the same way as you can 
from the command line. It is a nice tool for those new to writing tests 
who aren't yet familiar with the command line or prefer a GUI.


In its basic form you simply pick a directory and unittestgui will 
discover and run all the tests it finds. It would be nice if it provided 
more diagnostic information on tests it ran (clicking through test 
results) but these can be added later.


All the best,

Michael Foord

--

http://www.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.

___
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] "Too many open files" errors on "x86 FreeBSD 7.2 3.x" buildbot

[Jeroen Ruigrok van der Werven]

-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 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.
Looking through the repository it seems 7-STABLE has it enabled by default
as well in the GENERIC kernel (the standard one it boots with after its
first install). It seems this was added for 7.3 and onward. So 7.2 and
before need an "options P1003_1B_SEMAPHORES" added to their kernel at least.
The SYSV options are already present in the entire 7.x line.

>> It looks like it is possible to tune semaphore limits on FreeBSD, without 
>> recompiling the kernel, by using boot loader option (kern.ipc.sem* options). 
>> But ask the FreeBSD user to tune its boot loader options to use the 
>> concurrent.futures module is not pratical :-)

PostgreSQL installations via ports as well as its documentation instruct the
FreeBSD user to tweak kern.ipc settings.

>Yeah, I guess the key question is if changing the limit is just needed
>to get around an artifact of the test process (which I'm willing to do
>for the buildbot), or if it would be needed to be able to use the
>regular modules in practice.  If the latter, I doubt too many users
>are going to jump through such hoops, particularly if it needs a
>kernel rebuild, so we may need to make other choices in terms of
>support under FreeBSD.

Almost every FreeBSD user I know of compiles a new kernel. It's just one of
those BSD things that every user goes through.

>I'm also not entirely sure just what is the limiting factor.  I think
>the kern.ipc.sem* options are for the SYSV semaphores, not POSIX, though
>some of them do have a similar limit.  Some are adjustable by sysctl,
>others by loader.conf.

kern.ipc is about System V IPC. As you indicate later on, p1003_1b is the
POSIX related IPC sysctl tree.
The three semaphore settings semmni, semmns, and semmnu are only tweakable
via loader.conf.

>The references I found were talking about a limit set explicitly
>(#define SEM_MAX) in the kernel source (uipc_sem.c) which exports its
>value (at least in 7.2) via the sysctl p1003_1b.sem_nsems_max, which
>is read-only.  I got the impression they weren't adjustable even in
>loader.conf, but haven't actually tried it yet myself.
>
>It may be different in 8.x, but one email thread I found indicated
>that the changes proposed to make the POSIX limits adjustable didn't
>make the 8.1 cut (current release), though might make it in the next
>8.x release.

After checking the repository I saw that there were MFCs (Merge From
Current, backport) to 8-STABLE prior to the 8.1 release for dynamic
tweaking.

On my 8.1 machine:

nexus% sudo sysctl -w p1003_1b.sem_nsems_max=31
p1003_1b.sem_nsems_max: 30 -> 32

7.x is hardlocked at the moment unless someone manually edits the file to up
the SEM_MAX define. The same goes for FreeBSD 8.0.

-- 
Jeroen Ruigrok van der Werven  / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Nothing yet from nothing ever came...
___
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] Help with warnings not being raised

[Jesus Cea]

-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 place, a
> second call to PyErr_WriteUnraisable should get the error to actually
> print out.

Excellent explanation, Nick. Thanks.

Patched in r86317. Up-ported to upcoming pybsddb 5.1.1.

PS: Bugs.python.org is still down.

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTNf0HZlgi5GaxT1NAQKSEwQAov31uECPVCEjxP7bns9VH4bz0HzXaAV7
VUeMxt8snK6/o6d8IowdoAGNR4MiSAkY0ww8IG9QQ/9919FMBD3kZs1+JNRcTWu3
RLN2kLvE6g+reV+M6tRqnMYwuxXiq4MhBgZZrnB6DA//buIbjOaLTVcL6ABDEMVc
ULj2g0TN0mA=
=h6DP
-END PGP SIGNATURE-
___
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] r86276 - python/branches/py3k/Lib/distutils/cygwinccompiler.py

[Éric Araujo]

>> 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 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] r86276 - python/branches/py3k/Lib/distutils/cygwinccompiler.py

[Éric Araujo]

>> 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 browser,
incidentally), so I don’t fear I’ll forget it.  This new keyword would
IMO be redundant with existing fields (status:open + version:2.7).

(The once-existing 26backport was entirely different if I recall
correctly, it was used to tag 3.x features to be added to 2.x.)

Regards

___
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] r86300 - in python/branches/py3k: Misc/NEWS PC/winsound.c

[Éric Araujo]

> 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(original)
> +++ python/branches/py3k/Misc/NEWSSun Nov  7 15:29:26 2010
> @@ -251,6 +251,8 @@
>  Extension Modules
>  -
>  
> +- Issue #6317: Now winsound.PlaySound only accepts unicode.
> +
>  - Issue #6317: Now winsound.PlaySound can accept non ascii filename.

Shouldn’t that be only one entry?

Regards

___
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] Backward incompatible API changes in the pydoc module

[exarkun]

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).

Currently the patch switches serve() to start the new server
implementation and gui() to start the server and open a browser window
for it.

It occurred to me that, despite the "it's an application" feel to the
pydoc web server APIs, it may be a better idea to leave the two
existing functions alone (aside from adding DeprecationWarning), and
using new private function names to start the new server and the web
browser.

Is following the standard deprecation procedure the better course
here, or am I being overly paranoid?


Following the deprecation procedure here sounds awesome to me.  Thanks 
for considering it, I hope you'll choose to go that way.


Jean-Paul
___
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] Continuing 2.x

[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
> comes to improving the language, and there is a moratorium anyway.
> Improvements in the standard library can be more easily done in
> external libraries anyway, and then you can release the improved
> libraries for everything from Python 2.4 and forwards if you like.
> 
> So it can be done, but the question is "Why?"

To keep the batteries included?

James
___
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] r86264 - python/branches/release27-maint/Lib/distutils/sysconfig.py

[Éric Araujo]

[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 that
>> revision. If the removal of OS9 support was documented (announced),
>> which I presume it was, then one could consider any visible trace
>> remaining to be a bug.

FTR, it was documented in PEP 11 as removed in 2.4 (but not in 2.4’s
whatsnew).

> Well, the question is: can anything break due to the code removal.
> In principle, stuff *could* break even by a function that is supposedly
> unused, and had supposedly been removed. The problem is that a
> supposedly-unused function actually might be used somewhere, in some
> context unrelated to its intended usage.

It’s known that people do modify distutils.sysconfig._config_vars, a
private dictionary; I can imagine some really contrived example of code
using _init_mac, the function I removed, to set sysconfig values for Mac
OS 9 in 2.7 code.  1% chance, I guess.

>> Perhaps the policy on code cleanup should be a bit more liberal for 2.7
>> *because* it will be maintained for several years and *because* there is
>> no newer 2.x branch to apply changes to.
> 
> You mean, it's ok to break stuff with no gain in 2.7 bug fix releases?

I don’t think Terry was suggesting breakages, just other kinds of
cleanup.  In this particular case, I think now that I should have
followed distutils policy (which is less liberal that the rest of the
stdlib).  If there are no arguments against it this week, I will revert
the commit.

Regards

___
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] Backward incompatible API changes in the pydoc module

[É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 considering that it must not have been easy to write
code extending pydoc :).

BTW, doesn’t the process start with PendingDeprecationWarnings, then
DeprecationWarnings?

Regards

___
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] Continuing 2.x

[Tres Seaver]

-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 much alive,
>> 2.x series of Python?
>>
>> The answer would seem to be “one doesn’t”.  But must it be that way?
> 
> 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 there is a moratorium anyway.
> Improvements in the standard library can be more easily done in
> external libraries anyway, and then you can release the improved
> libraries for everything from Python 2.4 and forwards if you like.
> 
> So it can be done, but the question is "Why?"

The OP has existing patches to contribute which the core python-dev team
consider "not-a-bugfix", and hence not acceptable for the 2.7 branch.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzYIgUACgkQ+gerLs4ltQ4i1QCfVwDdlkd9tGj6ayKBq3xpiHAW
fIYAoNwDx35RfC5VYEyVjhJBbCxrqfXk
=bnTg
-END PGP SIGNATURE-

___
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] Backward incompatible API changes in the pydoc module

[Georg Brandl]

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 considering that it must not have been easy to write
> code extending pydoc :).
> 
> BTW, doesn’t the process start with PendingDeprecationWarnings, then
> DeprecationWarnings?

PendingDeprecationWarnings only make sense for larger changes, especially
now that bot Pending and normal DeprecationWarnings are silent by default.
See PEP 387 (which is only a draft though).

Georg

___
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] Backward incompatible API changes in the pydoc module

[R. David Murray]

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 considering that it must not have been easy to write
> code extending pydoc :).
> 
> BTW, doesn’t the process start with PendingDeprecationWarnings, then
> DeprecationWarnings?

No, PendingDeprecationWarning was something used when we wanted a
default-silent deprecation warning for a while before doing an
actual deprecation.  Now that deprecation warnings are silent
by default we'll probably never need PendingDeprecationWarning ever
again :)

--David
___
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] Breaking undocumented API

[Alexander Belopolsky]

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't documented, 
> but the fact they aren't protected
> by an underscore means I'm not comfortable with the idea of removing them or 
> radically change their functionality
> without going through a deprecation period first.
>

I have a similar issue with the trace module and would appreciate some
guidance on this as well.  The trace module documented API includes
just the Trace class, but the module defines several helper functions
and classes  that do not start with a leading underscore and are not
excluded from * imports by __all__.  (There is no trace.__all__.)

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, but
CoverageResults._blank_re would certainly be a better place for it.

The functions I have specific need to modify (See
http://bugs.python.org/issue10342) are trace.find_strings(), and
find_executable_linenos().  The functions take module's file name, but
I need to make them to take the module object in order to be able to
deal with modules that have custom loaders.

The trace.find_strings() function is clearly internal.  It's name does
not even reflect what it does (finding docstring locations), so it was
never intended for use outside of the trace module.  However, google
code search reveals that people do use it and other functions in their
code.

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 source file.  Should this be fixed?

I freely admit that I have more questions than answers, so I would
like to hear from a wider audience.
___
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] Breaking undocumented API

[Michael Foord]

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 source file.  Should this be fixed?

I freely admit that I have more questions than answers, so I would
like to hear from a wider audience.


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.


If the function is no longer needed but we want to exclude it from the 
public API, you could create a new function in the module, with a 
leading underscore name, fix the bugs in that and deprecate the old name.


Alternatively you could make the old name an alias for the new one with 
a deprecation warning applied. That way the old name does get the 
bugfixes but is still deprecated.


Michael


___
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/fuzzyman%40voidspace.org.uk



--

http://www.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.

___
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] Breaking undocumented API

[Michael Foord]

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 source file.  Should this be fixed?

I freely admit that I have more questions than answers, so I would
like to hear from a wider audience.


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.


If the function is no longer needed but we want to exclude it from the 
public API, you could create a new function in the module, with a 
leading underscore name, fix the bugs in that and deprecate the old name.




Sorry, this meant to say "if the function is *still needed* (internally 
to the module) but we want to exclude it from the API"...


This would be a good approach to clarifying the public API of standard 
library modules. At least that way we could work towards a consistent 
policy.


All the best,

Michael

Alternatively you could make the old name an alias for the new one 
with a deprecation warning applied. That way the old name does get the 
bugfixes but is still deprecated.


Michael


___
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/fuzzyman%40voidspace.org.uk






--

http://www.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.

___
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 for AIX

[Antoine Pitrou]

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 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 two separate slaves, I can't think of any simple way to run
builds sequentially. Perhaps you can assign both of them to a single CPU
(assuming AIX allows that).

Regards

Antoine.


___
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 for AIX

[C. Titus Brown]

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 two separate slaves, I can't think of any simple way to run
> builds sequentially. Perhaps you can assign both of them to a single CPU
> (assuming AIX allows that).

You can specify a slave lock to do this, in buildbot:

http://buildbot.net/buildbot/docs/0.8.1/Interlocks.html

One the neat things that a master/slave system like buildbot provides...

cheers,
--titus
-- 
C. Titus Brown, c...@msu.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 for AIX

[Sébastien Sablé]

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 --with-pydebug --without-computed-gotos CC=xlc OPT="-O2 
-qmaxmem=18000"


And the compilation would give some error like that:
	xlc -c  "-O2 -qmaxmem=18000" -O2 -O2  -I. -IInclude -I./Include 
-I/home/cis/.buildbot/support-buildbot/include 
-I/home/cis/.buildbot/support-buildbot/include/ncurses 
-I/home/cis/.buildbot/support-buildbot/include 
-I/home/cis/.buildbot/support-buildbot/include/ncurses  -DPy_BUILD_CORE 
-o Modules/python.o ./Modules/python.c
xlc: 1501-216 (W) command option - -qmaxmem=18000 is not recognized - 
passed to ld



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.


regards

--
Sébastien Sablé


Le 28/10/2010 16:45, Antoine Pitrou a écrit :

On Fri, 15 Oct 2010 17:38:47 +0200
Sébastien Sablé  wrote:


Could you please take a look at those modifications in master.cfg,
provide me some password for the bot slaves and apply the corrections in
those issues?


About the master.cfg modifications: there should be no need for
separate environment variables. Instead, you should be able to specify
them as command-line arguments to ./configure, e.g.:

["--with-pydebug", "--without-computed-gotos", "CC=xlc",
  'OPT="-O2 -qmaxmem=18000"']

Can you check this works for you?

Also, there's no need to complicate the buildbot naming procedure.
You should be able to run several buildslaves on a single machine,
provided we give you separate credentials: one per compiler type.

Regards

Antoine.


___
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/sable%40users.sourceforge.net


___
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 for AIX

[exarkun]

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 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 two separate slaves, I can't think of any simple way to 
run
builds sequentially. Perhaps you can assign both of them to a single 
CPU

(assuming AIX allows that).


A master lock will allow this.  Although just having a single slave and 
using a slave lock would be simpler.


Jean-Paul
___
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] Backward incompatible API changes in the pydoc module

[Ron Adam]

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 public standard
library APIs (albeit undocumented ones).

Currently the patch switches serve() to start the new server
implementation and gui() to start the server and open a browser window
for it.

It occurred to me that, despite the "it's an application" feel to the
pydoc web server APIs, it may be a better idea to leave the two
existing functions alone (aside from adding DeprecationWarning), and
using new private function names to start the new server and the web
browser.

Is following the standard deprecation procedure the better course
here, or am I being overly paranoid?


Following the deprecation procedure here sounds awesome to me. Thanks
for considering it, I hope you'll choose to go that way.


I want to be clear on what isn't changing.

All of the help() function features that python depends on and any of the 
code that is required for that is staying the same.


All of the static html document generating features and code that depend on 
that, is staying the same.  These static pages do not depend on any parts 
of pydoc after they are generated.


Those are the parts that are most likely to be used in other applications 
as well.



The new changes only effect the interactive browsing mode. The tk search 
box was removed.  By doing that, it enabled the browser interface, to be 
used on systems that don't have tk installed.


The html web server was rewritten and a search feature was added so that 
you can do the same searches in the web browser that you did in the tk 
search box.


Do you (or anyone) know of any programs that access pydocs tk search 
window, or it's server parts directly?  The server was so specific and 
included very specific pydoc html code, so it would have been very 
difficult for it to be used for anything else.  Any thoughts?


I think the main issues Nick is concerned with is the functions and options 
used to start pydoc in the interactive mode.


Cheers,
   Ron

___
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] Breaking undocumented API

[Terry Reedy]

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 pydoc module in incompatible ways. Sure, they aren't documented, 
but the fact they aren't protected
by an underscore means I'm not comfortable with the idea of removing them or 
radically change their functionality
without going through a deprecation period first.



I have a similar issue with the trace module and would appreciate some
guidance on this as well.  The trace module documented API includes
just the Trace class, but the module defines several helper functions
and classes  that do not start with a leading underscore and are not
excluded from * imports by __all__.  (There is no trace.__all__.)


The trace module *appears* to be an ancient module written at a time 
(fictional or actual) when there was no '_' and '__all__' convention and 
only a loose 'public' == documented convention. The undocumented 
public-looking private stuff is a huge mess that Eli and I intentionally 
passed over in our July/August patch documenting (and fixing) the public 
stuff. I hope we included everything that should be public.


In order to warn about constants getting renamed or moved, is it 
possible to issue an off-by-default warning on module import, something like
"Trace is an ancient module with public names for many undocumented 
private constants and functions. Use of these is deprecated. See lib doc 
for more."


--
Terry Jan Reedy

___
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] Breaking undocumented API

[Alexander Belopolsky]

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
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] Breaking undocumented API

[Michael Foord]

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 
want to deprecate?


It depends what approach you are taking in 3.2. If you are creating a 
new private function, in which you will fix the bug, but keeping an 
alias around to the old name so that you can deprecate it - then merely 
fixing the bug in the maintenance branch should be fine.


(If you're deprecating the function because it is unneeded then you 
don't need to fix bugs in the maintenance branch either - I guess no-one 
would complain if you did though.)


Michael

--

http://www.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.

___
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] Breaking undocumented API

[Alexander Belopolsky]

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 know, deprecation warnings are not backported  to maintenance
branches while bug fixes are.  So the specific question is: there is a
bug in trace.find_strings() - should it be fixed in 3.1-maint?
___
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] Breaking undocumented API

[Michael Foord]

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 know, deprecation warnings are not backported  to maintenance
branches while bug fixes are.  So the specific question is: there is a
bug in trace.find_strings() - should it be fixed in 3.1-maint?

My opinion would be:

* No we don't backport the deprecation warning
* No we don't need to fix the bug

Others may disagree. (Logic being that we won't fix the bug in 3.2, if 
we fixed it in 2.7 then we would have to fix it in 3.2. Therefore we 
shouldn't fix in 2.7.)


Michael



--

http://www.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.

___
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] GUI test runner tool

[Brett Cannon]

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 believe it was never part
> of the standard library:
>
> http://sourceforge.net/projects/pyunit/
>
> Here's a screenshot of what it looks like:
>
> http://skitch.com/fuzzyman/dhu9r/pyunit
>
> I'd like to propose adding it to Python in Tools/ and am volunteering to
> maintain it.

Does that mean upgrading it as well? =) For instance it would be great
to get it to use ttk so it looks a bit sharper, supports skipped tests
and expected failures, and dream-of-dreams ties into regrtest so you
can just check boxes instead of passing a ton of CLI flags.

> If the answer is "not yet" that is fine as it can go into
> unittest2 first. Mark has updated it to work with test discovery and added
> support for configuring test discovery in the same way as you can from the
> command line. It is a nice tool for those new to writing tests who aren't
> yet familiar with the command line or prefer a GUI.

I personally have no problem with it going into tools as long as it
can also be used to run the tests in the stdlib. Just don't put it in
Demos/ . =)

-Brett

>
> In its basic form you simply pick a directory and unittestgui will discover
> and run all the tests it finds. It would be nice if it provided more
> diagnostic information on tests it ran (clicking through test results) but
> these can be added later.
>
> All the best,
>
> Michael Foord
>
> --
>
> http://www.voidspace.org.uk/
>
> READ CAREFULLY. By accepting and reading this email you agree,
> on behalf of your employer, to release me from all obligations
> and waivers arising from any and all NON-NEGOTIATED agreements,
> licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
> confidentiality, non-disclosure, non-compete and acceptable use
> policies (”BOGUS AGREEMENTS”) that I have entered into with your
> employer, its partners, licensors, agents and assigns, in
> perpetuity, without prejudice to my ongoing rights and privileges.
> You further represent that you have the authority to release me
> from any BOGUS AGREEMENTS on behalf of your employer.
>
> ___
> 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/brett%40python.org
>
___
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] GUI test runner tool

[Alexander Belopolsky]

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
repository.  Tools/ is for stuff that is primarily of interest to
python developers, not python users.  OS vendors are less likely to
install packages in Tools/ in a user-visible place than they are a
popular 3rd-party package.
___
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] Breaking undocumented API

[Brett Cannon]

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 public
>> APIs of the pydoc module in incompatible ways. Sure, they aren't documented, 
>> but the fact they aren't protected
>> by an underscore means I'm not comfortable with the idea of removing them or 
>> radically change their functionality
>> without going through a deprecation period first.
>>
>
> I have a similar issue with the trace module and would appreciate some
> guidance on this as well.  The trace module documented API includes
> just the Trace class, but the module defines several helper functions
> and classes  that do not start with a leading underscore and are not
> excluded from * imports by __all__.  (There is no trace.__all__.)

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?

>
> 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, but
> CoverageResults._blank_re would certainly be a better place for it.

The deprecation policy obviously cannot apply to module-level attributes.

>
> The functions I have specific need to modify (See
> http://bugs.python.org/issue10342) are trace.find_strings(), and
> find_executable_linenos().  The functions take module's file name, but
> I need to make them to take the module object in order to be able to
> deal with modules that have custom loaders.
>
> The trace.find_strings() function is clearly internal.  It's name does
> not even reflect what it does (finding docstring locations), so it was
> never intended for use outside of the trace module.  However, google
> code search reveals that people do use it and other functions in their
> code.
>
> 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 source file.  Should this be fixed?
>
> I freely admit that I have more questions than answers, so I would
> like to hear from a wider audience.

The main reason I have said that non-underscore names should be
properly deprecated (assuming they are not contained in an
underscored-named module) is that dir() and help() do not distinguish.
If you are perusing a module from the interpreter prompt you have no
way to know whether something is public or private if it lacks an
underscore. Is it reasonable to assume that any API found through
dir() or help() must be checked with the official docs before you can
consider using it, even if you have no explicit need to read the
official docs?

I (unfortunately) say no, which is why I have argued that
non-underscored names need to be properly deprecated. This obviously
places a nasty burden on us, though, so I don't like taking this
position. Unless we can make it clearly known through help() or
something that the official docs must be checked to know what can and
cannot be reliably used I don't think it is reasonable to force users
to not be able to rely on help() (we should probably change help() to
print a big disclaimer for anything with a leading underscore,
though).

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.
___
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] GUI test runner tool

[Raymond Hettinger]

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 put it in Tools is good one.
GUI preferences and support varies among users and environments.
Also, any given GUI runner is just one of many possible solutions
and there is no reason to commit to one.  Better to add something
to Tools, post an ASPN recipe, or list a package on PyPI.

If you need it to be more visible, we can always give it a mention
in the docs.  Though we might want to mention more full featured
tools like Hudson.

Remember, the standard library is where code goes to die ;-)


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] Breaking undocumented API

[exarkun]

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, but
CoverageResults._blank_re would certainly be a better place for it.


The deprecation policy obviously cannot apply to module-level 
attributes.


I'm not sure why this is.  Can you elaborate?


The main reason I have said that non-underscore names should be
properly deprecated (assuming they are not contained in an
underscored-named module) is that dir() and help() do not distinguish.
If you are perusing a module from the interpreter prompt you have no
way to know whether something is public or private if it lacks an
underscore. Is it reasonable to assume that any API found through
dir() or help() must be checked with the official docs before you can
consider using it, even if you have no explicit need to read the
official docs?

I (unfortunately) say no, which is why I have argued that
non-underscored names need to be properly deprecated. This obviously
places a nasty burden on us, though, so I don't like taking this
position. Unless we can make it clearly known through help() or
something that the official docs must be checked to know what can and
cannot be reliably used I don't think it is reasonable to force users
to not be able to rely on help() (we should probably change help() to
print a big disclaimer for anything with a leading underscore,
though).

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

Jean-Paul
___
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] "Too many open files" errors on "x86 FreeBSD 7.2 3.x" buildbot

[David Bolen]

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 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.
> Looking through the repository it seems 7-STABLE has it enabled by default
> as well in the GENERIC kernel (the standard one it boots with after its
> first install). It seems this was added for 7.3 and onward. So 7.2 and
> before need an "options P1003_1B_SEMAPHORES" added to their kernel at least.
> The SYSV options are already present in the entire 7.x line.

My use of "enabled" may not have been the best word choice since I
didn't mean to imply a kernel option.

I'm still using GENERIC on the 7.2 buildbot, so I didn't need to
recompile the kernel in that release either.  The issue was that the
POSIX semaphore module wasn't loaded by default (something I thought
only changed in 8.x), so the buildbot currently has a 'sem_load="YES"'
loader.conf entry to ensure that's done.

-- David

___
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] Breaking undocumented API

[Brett Cannon]

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
>>> if it is possible to add a deprecation warning to it, but
>>> CoverageResults._blank_re would certainly be a better place for it.
>>
>> The deprecation policy obviously cannot apply to module-level attributes.
>
> I'm not sure why this is.  Can you elaborate?

There is no way to directly trigger a DeprecationWarning for an
attribute. We can still document it, but there is just no way to
programmatically enforce it.

-Brett

>>
>> The main reason I have said that non-underscore names should be
>> properly deprecated (assuming they are not contained in an
>> underscored-named module) is that dir() and help() do not distinguish.
>> If you are perusing a module from the interpreter prompt you have no
>> way to know whether something is public or private if it lacks an
>> underscore. Is it reasonable to assume that any API found through
>> dir() or help() must be checked with the official docs before you can
>> consider using it, even if you have no explicit need to read the
>> official docs?
>>
>> I (unfortunately) say no, which is why I have argued that
>> non-underscored names need to be properly deprecated. This obviously
>> places a nasty burden on us, though, so I don't like taking this
>> position. Unless we can make it clearly known through help() or
>> something that the official docs must be checked to know what can and
>> cannot be reliably used I don't think it is reasonable to force users
>> to not be able to rely on help() (we should probably change help() to
>> print a big disclaimer for anything with a leading underscore,
>> though).
>>
>> 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
>
> Jean-Paul
>
___
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] Breaking undocumented API

[exarkun]

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 indefinitely?  I don't even 
know

if it is possible to add a deprecation warning to it, but
CoverageResults._blank_re would certainly be a better place for it.


The deprecation policy obviously cannot apply to module-level 
attributes.


I'm not sure why this is. �Can you elaborate?


There is no way to directly trigger a DeprecationWarning for an
attribute. We can still document it, but there is just no way to
programmatically enforce it.


What about `deprecatedModuleAttribute` 
() 
or zope.deprecation 
() which inspired 
it?


Jean-Paul
___
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] Breaking undocumented API

[Ron Adam]

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 finally 
clicked that the patch changes public
APIs of the pydoc module in incompatible ways. Sure, they aren't documented, 
but the fact they aren't protected
by an underscore means I'm not comfortable with the idea of removing them or 
radically change their functionality
without going through a deprecation period first.



I have a similar issue with the trace module and would appreciate some
guidance on this as well.  The trace module documented API includes
just the Trace class, but the module defines several helper functions
and classes  that do not start with a leading underscore and are not
excluded from * imports by __all__.  (There is no trace.__all__.)


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?


My understanding is that anything with an actual docstring is part of the 
public API.  Any thing with a leading underscore is private.


And to a lesser extent, objects with out docstrings, but have comments 
instead or nothing, may change, so don't depend on them.  Thankfully most 
things do have docstrings.




I freely admit that I have more questions than answers, so I would
like to hear from a wider audience.


The main reason I have said that non-underscore names should be
properly deprecated (assuming they are not contained in an
underscored-named module) is that dir() and help() do not distinguish.
If you are perusing a module from the interpreter prompt you have no
way to know whether something is public or private if it lacks an
underscore. Is it reasonable to assume that any API found through
dir() or help() must be checked with the official docs before you can
consider using it, even if you have no explicit need to read the
official docs?

I (unfortunately) say no, which is why I have argued that
non-underscored names need to be properly deprecated. This obviously
places a nasty burden on us, though, so I don't like taking this
position. Unless we can make it clearly known through help() or
something that the official docs must be checked to know what can and
cannot be reliably used I don't think it is reasonable to force users
to not be able to rely on help() (we should probably change help() to
print a big disclaimer for anything with a leading underscore,
though).


+1 on the help disclaimer for objects with leading underscores.

Currently help() does not see comments when they are used in place of a 
docstring.  I think it would be easy to have help notate things with no 
docstrings as "Warning: Undocumented . Use at your own risk."


At first, it would probably have a nice side effect of getting any public 
API's documented with doc strings. (if they aren't already.)




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.


I agree.


It may also be useful to clarify that importing some "utility" modules is 
not recommended because they may be changed more often and may not follow 
the standard process.  Would something like the following work, but still 
allow for importing if the exception is caught with a try except?


if __name__ == "__main__":
main()
else:
raise ImportWarning("This is utility module and may be changed.")

Cheers,
  Ron
___
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] Breaking undocumented API

[Brett Cannon]

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 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, but
> CoverageResults._blank_re would certainly be a better place for it.

 The deprecation policy obviously cannot apply to module-level
 attributes.
>>>
>>> I'm not sure why this is.  Can you elaborate?
>>
>> There is no way to directly trigger a DeprecationWarning for an
>> attribute. We can still document it, but there is just no way to
>> programmatically enforce it.
>
> What about `deprecatedModuleAttribute`
> ()
> or zope.deprecation
> () which inspired it?

Just checked the code and it looks like it substitutes the module for
some proxy object? To begin that break subclass checks. After that I
don't know the ramifications without really digging into the
ModuleType code.
___
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] Breaking undocumented API

[Brett Cannon]

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:
>>> ..

 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't
 documented, but the fact they aren't protected
 by an underscore means I'm not comfortable with the idea of removing
 them or radically change their functionality
 without going through a deprecation period first.

>>>
>>> I have a similar issue with the trace module and would appreciate some
>>> guidance on this as well.  The trace module documented API includes
>>> just the Trace class, but the module defines several helper functions
>>> and classes  that do not start with a leading underscore and are not
>>> excluded from * imports by __all__.  (There is no trace.__all__.)
>>
>> 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?
>
> 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 developers know what the
heck should be going on in the code?

>
> And to a lesser extent, objects with out docstrings, but have comments
> instead or nothing, may change, so don't depend on them.  Thankfully most
> things do have docstrings.
>
>
>>> I freely admit that I have more questions than answers, so I would
>>> like to hear from a wider audience.
>>
>> The main reason I have said that non-underscore names should be
>> properly deprecated (assuming they are not contained in an
>> underscored-named module) is that dir() and help() do not distinguish.
>> If you are perusing a module from the interpreter prompt you have no
>> way to know whether something is public or private if it lacks an
>> underscore. Is it reasonable to assume that any API found through
>> dir() or help() must be checked with the official docs before you can
>> consider using it, even if you have no explicit need to read the
>> official docs?
>>
>> I (unfortunately) say no, which is why I have argued that
>> non-underscored names need to be properly deprecated. This obviously
>> places a nasty burden on us, though, so I don't like taking this
>> position. Unless we can make it clearly known through help() or
>> something that the official docs must be checked to know what can and
>> cannot be reliably used I don't think it is reasonable to force users
>> to not be able to rely on help() (we should probably change help() to
>> print a big disclaimer for anything with a leading underscore,
>> though).
>
> +1 on the help disclaimer for objects with leading underscores.
>
> Currently help() does not see comments when they are used in place of a
> docstring.  I think it would be easy to have help notate things with no
> docstrings as "Warning: Undocumented . Use at your own risk."
>
> At first, it would probably have a nice side effect of getting any public
> API's documented with doc strings. (if they aren't already.)
>
>
>> 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.
>
> I agree.
>
>
> It may also be useful to clarify that importing some "utility" modules is
> not recommended because they may be changed more often and may not follow
> the standard process.  Would something like the following work, but still
> allow for importing if the exception is caught with a try except?
>
> if __name__ == "__main__":
>    main()
> else:
>    raise ImportWarning("This is utility module and may be changed.")

Sure it would work, but that doesn't make it pleasant to use. It
already breaks how warnings are typically handled by raising it
instead of calling warnings.warn(). Plus I'm now supposed to
try/except certain imports? That's messy. At that point we are coding
in visibility rules instead of following convention and that doesn't
sit well with me.

-Brett

>
> Cheers,
>  Ron
>
> ___
> 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/brett%40python.org
>
___
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] Breaking undocumented API

[Raymond Hettinger]

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 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 intended to be public on a go-forward 
basis.

For the most part, the non-underscored parts of the API shouldn't be changed 
"at our whim".  Some sense needs to be applied to the decision.  Google's code 
search is great for showing how people actually have used a module in real 
world code.  If that shows that people are accessing and/or changing an 
attribute, it probably needs to remain exposed.   In the absence of a code 
search, good guesses can be made about what someone might reasonably and 
usefully be accessing (i.e. glob0 isn't likely).   The goal is to improve the 
standard library while minimizing breakage, and that will involve trade-offs 
depending on what is being changed.

IIRC, we've been trying to get away from deprecations because they're so 
disruptive.  For example, when the pprint rewrite is finally ready, if there is 
an incompatible API change, I expect that a new clean class will be offered, 
but that the old will be left in-place so that tons of existing code won't 
break).  Likewise, with the unittest clean-ups, I'm expecting that Michael will 
introduce aliases when fixing-up mis-named methods, rather than break code that 
uses the existing names.

my-two-cents,


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] Breaking undocumented API

[Steven D'Aprano]

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 internal functions *wink*

The convention I use is:

* If __all__ exists, anything in that is public.
* Anything not listed in __all__ but without a leading underscore is 
public, but not part of the module's API; e.g. utility functions, 
imported modules, globals (but hopefully not too many of the last). That 
means I don't expect you to use it, but you can if you want.
* Anything with a _private name is internal use only. That includes 
modules. Any attribute of a private object is also private.


If a class is flagged as private, _MyClass, you wouldn't expect that 
_MyClass.attribute were public just because the attribute name wasn't 
also flagged with an underscore. So why treat _module.name as public?




+1 on the help disclaimer for objects with leading underscores.


I don't know that it will be that useful, but I don't think it will help 
that much. +0.


Currently help() does not see comments when they are used in place of a 
docstring.  I think it would be easy to have help notate things with no 
docstrings as "Warning: Undocumented . Use at your own risk."


I wouldn't like that. I don't think that "no docstring" = "undocumented" 
-- the documentation might exist somewhere else.


Besides, I don't think that help() should start misidentifying public 
objects as private if you run it under python -OO.



It may also be useful to clarify that importing some "utility" modules 
is not recommended because they may be changed more often and may not 
follow the standard process.  Would something like the following work, 
but still allow for importing if the exception is caught with a try except?


if __name__ == "__main__":
main()
else:
raise ImportWarning("This is utility module and may be changed.")


There's no way for the imported module to know what module is importing 
it, is there? Because the API I'd much prefer is:


safe_modules = [a, b, c, d]  # List of modules allowed to import me.
if calling_module not in safe_modules:
warning.warn("private module, are you sure you want to do this?")



--
Steven

___
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] r86327 - in python/branches/py3k: Doc/includes/email-mime.py Doc/includes/email-simple.py Doc/library/smtplib.rst Doc/whatsnew/3.2.rst Lib/smtplib.py Lib/test/test_s

[Éric Araujo]

> 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 own SMTP server.
>  s = smtplib.SMTP()
> -s.sendmail(me, family, msg.as_string())
> +s.sendmail(msg)
>  s.quit()

If I’m not mistaken, you’re giving a message object to a method that
only accepts str or bytes.  That line should read s.send_message(msg).

Regards

___
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] Breaking undocumented API

[exarkun]

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.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, but
CoverageResults._blank_re would certainly be a better place for 
it.


The deprecation policy obviously cannot apply to module-level
attributes.


I'm not sure why this is. �Can you elaborate?


There is no way to directly trigger a DeprecationWarning for an
attribute. We can still document it, but there is just no way to
programmatically enforce it.


What about `deprecatedModuleAttribute`
()
or zope.deprecation
() which 
inspired it?


Just checked the code and it looks like it substitutes the module for
some proxy object? To begin that break subclass checks. After that I
don't know the ramifications without really digging into the
ModuleType code.


That could be fixed if ModuleType allowed subclassing. :)

For what it's worth, no one has complained about problems caused by 
`deprecatedModuleAttribute`, but we've only been using it for about two 
and a half years.


Jean-Paul
___
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] Breaking undocumented API

[Terry Reedy]

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, docstrings (but no doc 
mention) for private stuff. Eli and I fixed the first part.


--
Terry Jan Reedy

___
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] Breaking undocumented API

[Terry Reedy]

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 between: deprecate as if private, but do so much more 
freely that we would for public stuff. I think this is what you actually 
propose. We might deprecate faster too.



The main reason I have said that non-underscore names should be
properly deprecated (assuming they are not contained in an
underscored-named module) is that dir() and help() do not distinguish.
If you are perusing a module from the interpreter prompt you have no
way to know whether something is public or private if it lacks an
underscore. Is it reasonable to assume that any API found through
dir() or help() must be checked with the official docs before you can
consider using it, even if you have no explicit need to read the
official docs?

I (unfortunately) say no, which is why I have argued that
non-underscored names need to be properly deprecated. This obviously
places a nasty burden on us, though, so I don't like taking this


Completely naive question: Is there anything that could be automated to 
reduce the burden?



position. Unless we can make it clearly known through help() or
something that the official docs must be checked to know what can and
cannot be reliably used I don't think it is reasonable to force users
to not be able to rely on help() (we should probably change help() to
print a big disclaimer for anything with a leading underscore,
though).

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.


--
Terry Jan Reedy

___
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] Continuing 2.x

[Lennart Regebro]

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
>> comes to improving the language, and there is a moratorium anyway.
>> Improvements in the standard library can be more easily done in
>> external libraries anyway, and then you can release the improved
>> libraries for everything from Python 2.4 and forwards if you like.
>>
>> So it can be done, but the question is "Why?"
>
> To keep the batteries included?

But they'll only be included in > 2.7, which won't be used much, which
defeats the purpose of including those batteries.

--
Lennart Regebro, Colliberty: http://www.colliberty.com/
Telephone: +48 691 268 328
___
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] Breaking undocumented API

[Bobby Impollonia]

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 private regardless and thus we can
>> change them at our whim?
>
> 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 intended to be public on a 
> go-forward basis.

This does hurt because anyone who was relying on "import *" to get a
name which is now omitted from __all__ is going to upgrade and find
their program failing with NameErrors. This is a backwards compatible
change and shouldn't happen without a deprecation warning first.
___
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] Breaking undocumented API

[Glyph Lefkowitz]

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:
>>> 
>>> 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, but
>>> CoverageResults._blank_re would certainly be a better place for it.
>> 
>> The deprecation policy obviously cannot apply to module-level
>> attributes.
> 
> I'm not sure why this is.  Can you elaborate?
 
 There is no way to directly trigger a DeprecationWarning for an
 attribute. We can still document it, but there is just no way to
 programmatically enforce it.
>>> 
>>> What about `deprecatedModuleAttribute`
>>> ()
>>> or zope.deprecation
>>> () which inspired it?
>> 
>> Just checked the code and it looks like it substitutes the module for
>> some proxy object? To begin that break subclass checks. After that I
>> don't know the ramifications without really digging into the
>> ModuleType code.
> 
> That could be fixed if ModuleType allowed subclassing. :)
> 
> For what it's worth, no one has complained about problems caused by 
> `deprecatedModuleAttribute`, but we've only been using it for about two and a 
> half years.

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 
'instances of ModuleType'.  The Twisted reactor, for example, is an instance, 
and we've been doing *that* for about 10 years with no complaints.

___
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] Breaking undocumented API

[Ron Adam]

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 developers know what the
heck should be going on in the code?


You can use comments instead of a docstring.

Here are the possible cases concerned with the subject.  I'm using 
functions here for these examples, but this also applies to other objects.



def public_api():
""" Should always have a nice docstring. """
...


def _private_api():
#
# Isn't it a good practice to use comments here?
#
...


def _publicly_documented_private_api():
"""  Not sure why you would want to do this
 instead of using comments.
"""
...


def undocumented_public_api():
...


def _undocumented_private_api():
...


Out of these, the two that are problematic are the 
_publicly_documented_private_api() and the undocumented_public_api().


The _publicly_documented_private_api() is a problem because people *will* 
use it even though it has a leading underscore.  Especially those who are 
new to python.


The undocumented_public_api() wouldn't be a problem if all private api's 
used leading  underscore, but for older modules, it isn't always clear what 
the intention was.  Was it undocumented because the programmer simply 
forgot, or was it intended to be a private api?





It may also be useful to clarify that importing some "utility" modules is
not recommended because they may be changed more often and may not follow
the standard process.  Would something like the following work, but still
allow for importing if the exception is caught with a try except?

if __name__ == "__main__":
main()
else:
raise ImportWarning("This is utility module and may be changed.")


Sure it would work, but that doesn't make it pleasant to use. It
already breaks how warnings are typically handled by raising it
instead of calling warnings.warn(). Plus I'm now supposed to
try/except certain imports? That's messy. At that point we are coding
in visibility rules instead of following convention and that doesn't
sit well with me.


No, you're not suppose to try/except imports.  That's the point.

You can do that, only if you really want to abuse the intended purpose of a 
module that isn't meant to be imported in the first place.  If someone 
wants to do that, it isn't a problem.  They are well aware of the risks if 
they do it.  (This is just one option and probably one that isn't thought 
out very well.)


Brett, I'm sure you can up with a better alternative.   ;-)

Cheers,
  Ron





___
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] Breaking undocumented API

[Guido van Rossum]

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 get treated just the same
>>> as the documented APIs, or are they private regardless and thus we can
>>> change them at our whim?
>>
>> 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 intended to be public on a 
>> go-forward basis.
>
> This does hurt because anyone who was relying on "import *" to get a
> name which is now omitted from __all__ is going to upgrade and find
> their program failing with NameErrors. This is a backwards compatible
> change and shouldn't happen without a deprecation warning first.

Given that import * is generally frowned upon you can't make a blanket
statement like this without referring to the specifics of the name
being considered for removal. In fact, for any proposed change the
risk and reward need to be weighed properly. If the risk is "someone's
code could break if they used some undocumented API" it is useful to
estimate the probability that this would happen and that somebody
would care (rather than just fixing their code and moving on). Many
factors go into such an estimate. Just one example would be if we knew
of usage of the offending name in code that could reasonably be
assumed to be widely copied or distributed -- in such cases we should
move very carefully indeed no matter how "officially undocumented"
something is.

I don't want to go into the specifics of the trace module (even if I
wrote it, it's too long ago to remember, nor can I recall using it)
but I do want to warn about the dangers of applying simplifying rules
mindlessly.

-- 
--Guido van Rossum (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] Breaking undocumented API

[Ben Finney]

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
> > intended to be public on a go-forward basis.
>
> This does hurt because anyone who was relying on "import *" to get a
> name which is now omitted from __all__ is going to upgrade and find
> their program failing with NameErrors. This is a backwards compatible
> change and shouldn't happen without a deprecation warning first.

It also introduces a (perhaps small, but clearly non-zero) maintenance
burden: the name of an object must be added, changed, and removed not
only where it is defined, but also in the ‘__all__’ entry.

This burden is avoided when using the spelling of the name itself as the
indicator for exposure in the API.

-- 
 \ “In any great organization it is far, far safer to be wrong |
  `\  with the majority than to be right alone.” —John Kenneth |
_o__)Galbraith, 1989-07-28 |
Ben Finney

___
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] Breaking undocumented API

[Ben Finney]

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 most of the other
good reasons for docstrings.

> The _publicly_documented_private_api() is a problem because people
> *will* use it even though it has a leading underscore. Especially
> those who are new to python.

That isn't an argument against docstrings, since the problem you
describe isn't dependent on the presence or absence of docstrings.

-- 
 \ “I wish there was a knob on the TV to turn up the intelligence. |
  `\  There's a knob called ‘brightness’ but it doesn't work.” |
_o__) —Eugene P. Gallagher |
Ben Finney

___
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] Breaking undocumented API

[Guido van Rossum]

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 
> 'instances of ModuleType'.  The Twisted reactor, for example, is an instance, 
> and we've been doing *that* for about 10 years with no complaints.

But the Twisted universe is only a subset of the Python universe. The
Python stdlib needs to move more carefully.

-- 
--Guido van Rossum (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] Backward incompatible API changes in the pydoc module

[Ron Adam]

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).

Currently the patch switches serve() to start the new server
implementation and gui() to start the server and open a browser window
for it.

It occurred to me that, despite the "it's an application" feel to the
pydoc web server APIs, it may be a better idea to leave the two
existing functions alone (aside from adding DeprecationWarning), and
using new private function names to start the new server and the web
browser.

Is following the standard deprecation procedure the better course
here, or am I being overly paranoid?


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 
changes to the _pydoc3.py file without having to be even a little paranoid.


Cheers,
   Ron

___
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] Breaking undocumented API

[Brett Cannon]

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 document something that
>> is not meant for the public so that fellow developers know what the
>> heck should be going on in the code?
>
> You can use comments instead of a docstring.
>
> Here are the possible cases concerned with the subject.  I'm using functions
> here for these examples, but this also applies to other objects.
>
>
> def public_api():
>    """ Should always have a nice docstring. """
>    ...
>
>
> 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.

It would also lead to essentially requiring a docstrings for
everything that is public whether someone wants to bother to writing a
docstring or not. I don't think we should be suggesting that a
docstring be required either.

>
>
> def _publicly_documented_private_api():
>    """  Not sure why you would want to do this
>         instead of using comments.
>    """
>    ...
>
>
> def undocumented_public_api():
>    ...
>
>
> def _undocumented_private_api():
>    ...
>
>
> Out of these, the two that are problematic are the
> _publicly_documented_private_api() and the undocumented_public_api().
>
> The _publicly_documented_private_api() is a problem because people *will*
> use it even though it has a leading underscore.  Especially those who are
> new to python.
>
> The undocumented_public_api() wouldn't be a problem if all private api's
> used leading  underscore, but for older modules, it isn't always clear what
> the intention was.  Was it undocumented because the programmer simply
> forgot, or was it intended to be a private api?
>
>
>
>>> It may also be useful to clarify that importing some "utility" modules is
>>> not recommended because they may be changed more often and may not follow
>>> the standard process.  Would something like the following work, but still
>>> allow for importing if the exception is caught with a try except?
>>>
>>> if __name__ == "__main__":
>>>    main()
>>> else:
>>>    raise ImportWarning("This is utility module and may be changed.")
>>
>> Sure it would work, but that doesn't make it pleasant to use. It
>> already breaks how warnings are typically handled by raising it
>> instead of calling warnings.warn(). Plus I'm now supposed to
>> try/except certain imports? That's messy. At that point we are coding
>> in visibility rules instead of following convention and that doesn't
>> sit well with me.
>
> No, you're not suppose to try/except imports.  That's the point.
>
> You can do that, only if you really want to abuse the intended purpose of a
> module that isn't meant to be imported in the first place.  If someone wants
> to do that, it isn't a problem.  They are well aware of the risks if they do
> it.  (This is just one option and probably one that isn't thought out very
> well.)
>
> Brett, I'm sure you can up with a better alternative.   ;-)

But I don't want to have to do that in the stdlib by remembering what
modules I should or should not import. This is just as much about
developer burden on core devs as it is making sure we don't yank the
rug out from underneath users.
___
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] Breaking undocumented API

[Guido van Rossum]

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()’, and
> because it's automatically available to ‘doctest’, and most of the other
> good reasons for docstrings.
>
>> The _publicly_documented_private_api() is a problem because people
>> *will* use it even though it has a leading underscore. Especially
>> those who are new to python.
>
> That isn't an argument against docstrings, since the problem you
> describe isn't dependent on the presence or absence of docstrings.

+1

-- 
--Guido van Rossum (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] Breaking undocumented API

[Toshio Kuratomi]

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 interpreter via ‘help()’, and
> because it's automatically available to ‘doctest’, and most of the other
> good reasons for docstrings.
> 
> > The _publicly_documented_private_api() is a problem because people
> > *will* use it even though it has a leading underscore. Especially
> > those who are new to python.
> 
> That isn't an argument against docstrings, since the problem you
> describe isn't dependent on the presence or absence of docstrings.
> 
Just wanted to expand a bit here:  as a general practice, you may be
involved in a project where the _private_api() is not intended by people
outside of the project but is intended to be used in multiple places within
the project.  If you have different people working on those different areas,
it can be very useful for them to be able to use help(_private_api) on the
other functions from within the interpreter shell.

-Toshio


pgpG39YJbm42M.pgp
Description: PGP signature
___
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] "Too many open files" errors on "x86 FreeBSD 7.2 3.x" buildbot

[Victor Stinner]

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 older versions.

> PostgreSQL installations via ports as well as its documentation instruct
> the FreeBSD user to tweak kern.ipc settings.

I found some informations about SysV semaphores on FreeBSD in a Firebird 
patch, which means that Firebird uses SysV semaphores on FreeBSD :-) (at least 
in Debian/kFreeBSD).

> Almost every FreeBSD user I know of compiles a new kernel. It's just one of
> those BSD things that every user goes through.

If #10348 is implemented, FreeBSD users will be able to use the 
multiprocessing module without having to recompile their kernel. The question 
is more who would like to implement SysV semaphores in Python :-) I don't know 
anything about these semaphores.

http://bugs.python.org/issue10348

Victor
___
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] Breaking undocumented API

[exarkun]

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 
modules in the sense of 'instances of ModuleType'.  The Twisted 
reactor, for example, is an instance, and we've been doing *that* for 
about 10 years with no complaints.


But the Twisted universe is only a subset of the Python universe. The
Python stdlib needs to move more carefully.


I think that Twisted developers are pretty careful to consider the 
consequences of changes they make to Twisted.  We have an explicit, 
documented backwards compatibility policy, for example.  We also have 
mandatory code review for all changes, with a documented set of 
guidelines outlining the minimum things a reviewer should be 
considering.


I wonder if there are any actual technical arguments to be made against 
something like `deprecatedModuleAttribute`?


Also, it turns out that ModuleType can be subclassed these days.

Jean-Paul
___
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] Breaking undocumented API

[R. David Murray]

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-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] Breaking undocumented API

[Alexander Belopolsky]

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 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] Backward incompatible API changes in the pydoc module

[Nick Coghlan]

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
> changes to the _pydoc3.py file without having to be even a little paranoid.

I think changing the behaviour of the pydoc command line app is a fine
idea - it's only the pydoc.serve and pydoc.gui functions that are
worrying me. As I noted on the tracker issue, there's a reasonably
clean way to do this, even given the coupling between the 3.1 GUI app
and server: leave the existing serve() and gui() functions alone
(aside from adding DeprecationWarning), and add your new
implementation as a parallel private API.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] Breaking undocumented API

[Ron Adam]

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.


Ugly?  I suppose it's a matter of what you are used to.



It would also lead to essentially requiring a docstrings for
everything that is public whether someone wants to bother to writing a
docstring or not. I don't think we should be suggesting that a
docstring be required either.


I can see where that would be overly strict in an application or script 
made with python.


But it seems odd to me, to have undocumented api's in a programming 
language.  If it's being replaced with something else, the doc string can 
say that.  A null string is also a valid doc string if you just need a 
place holder until someone gets to it.






Brett, I'm sure you can up with a better alternative.   ;-)


But I don't want to have to do that in the stdlib by remembering what
modules I should or should not import. This is just as much about
developer burden on core devs as it is making sure we don't yank the
rug out from underneath users.


Yes, I agree.  But how to best do 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] Breaking undocumented API

[Nick Coghlan]

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 that for the pydoc patch.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] Backward incompatible API changes in the pydoc module

[Ron Adam]

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 unchanged and be free to make a lot more
changes to the _pydoc3.py file without having to be even a little paranoid.


I think changing the behaviour of the pydoc command line app is a fine
idea - it's only the pydoc.serve and pydoc.gui functions that are
worrying me. As I noted on the tracker issue, there's a reasonably
clean way to do this, even given the coupling between the 3.1 GUI app
and server: leave the existing serve() and gui() functions alone
(aside from adding DeprecationWarning), and add your new
implementation as a parallel private API.


Ok, I guess that's what needs to be done then.  I can try to do it over the 
next few days, and will probably need a bit more advise on how to add in 
the depreciation warnings.  Or if you want to go ahead and do it, I'm more 
than OK with that.


Thanks for the help on this.  I do appreciate it.

Cheers,
   Ron

___
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] Breaking undocumented API

[Eli Bendersky]

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 Python I don't see a
reason to leave out for "non-public" code. They're convenient in the
beginning of functions and we all are used to seeing them there. IDE's use
them to display helpful "tooltips" on functions, and so on.


Eli
___
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