Re: [Python-Dev] Stable buildbots

[Ned Deily]

In article <30929.1289879...@parc.com>, Bill Janssen  
wrote:

> Both the Tiger buildbots are suddenly failing 3.x on test_cmd_line.
> Looking at the changes since the last success, I can't see anything
> which would obviously affect that...  Any suspects?

It appears to be a duplicate of Issue8458.  Playing with it again, it 
seems to be a race condition: sometimes I see all three failures you 
reported, sometimes just one, sometimes none.  Again, only on 10.4 
(Tiger), not 10.5 or 10.6.  But the 10.4 machine I'm using is by far the 
slowest of the three so it is possible that could be a factor.  Perhaps 
a race condition with cleaning up the p2c pipe from a previous run?

> Here's what's failing:
> 
> ==
> ERROR: test_run_code (test.test_cmd_line.CmdLineTest)
> --
> Traceback (most recent call last):
>   File 
>   "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_cmd_line.py"
>   , line 95, in test_run_code
> assert_python_failure('-c')
>   File 
>   "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py"
>   , line 55, in assert_python_failure
> return _assert_python(False, *args, **env_vars)
>   File 
>   "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py"
>   , line 29, in _assert_python
> env=env)
>   File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/subprocess.py", 
>   line 683, in __init__
> self.stdin = io.open(p2cwrite, 'wb', bufsize)
> OSError: [Errno 9] Bad file descriptor
> 
> ==
> ERROR: test_run_module (test.test_cmd_line.CmdLineTest)
> --
> Traceback (most recent call last):
>   File 
>   "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_cmd_line.py"
>   , line 72, in test_run_module
> assert_python_failure('-m')
>   File 
>   "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py"
>   , line 55, in assert_python_failure
> return _assert_python(False, *args, **env_vars)
>   File 
>   "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py"
>   , line 29, in _assert_python
> env=env)
>   File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/subprocess.py", 
>   line 683, in __init__
> self.stdin = io.open(p2cwrite, 'wb', bufsize)
> OSError: [Errno 9] Bad file descriptor
> 
> ==
> ERROR: test_version (test.test_cmd_line.CmdLineTest)
> --
> Traceback (most recent call last):
>   File 
>   "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_cmd_line.py"
>   , line 48, in test_version
> rc, out, err = assert_python_ok('-V')
>   File 
>   "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py"
>   , line 48, in assert_python_ok
> return _assert_python(True, *args, **env_vars)
>   File 
>   "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py"
>   , line 29, in _assert_python
> env=env)
>   File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/subprocess.py", 
>   line 683, in __init__
> self.stdin = io.open(p2cwrite, 'wb', bufsize)
> OSError: [Errno 9] Bad file descriptor

-- 
 Ned Deily,
 n...@acm.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

[Python-Dev] [RELEASED] Python 3.2 alpha 4

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm happy to announce the
fourth and (this time really) final alpha preview release of Python 3.2.

Python 3.2 is a continuation of the efforts to improve and stabilize the
Python 3.x line.  Since the final release of Python 2.7, the 2.x line
will only receive bugfixes, and new features are developed for 3.x only.

Since PEP 3003, the Moratorium on Language Changes, is in effect, there
are no changes in Python's syntax and built-in types in Python 3.2.
Development efforts concentrated on the standard library and support for
porting code to Python 3.  Highlights are:

* numerous improvements to the unittest module
* PEP 3147, support for .pyc repository directories
* PEP 3149, support for version tagged dynamic libraries
* an overhauled GIL implementation that reduces contention
* many consistency and behavior fixes for numeric operations
* countless fixes regarding string/unicode issues; among them full
  support for a bytes environment (filenames, environment variables)
* a sysconfig module to access configuration information
* a pure-Python implementation of the datetime module
* additions to the shutil module, among them archive file support
* improvements to pdb, the Python debugger

For an extensive list of changes in 3.2, see Misc/NEWS in the Python
distribution.

To download Python 3.2 visit:

 http://www.python.org/download/releases/3.2/

3.2 documentation can be found at:

 http://docs.python.org/3.2/

Please consider trying Python 3.2 with your code and reporting any bugs
you may notice to:

 http://bugs.python.org/


Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAkzij74ACgkQN9GcIYhpnLCbtwCgi4whRruM0Oi6yfgjVclYErFa
OJcAn0U8UBBsQBFyGcnKJRbls6B+guQ2
=Vuqf
-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] [RELEASED] Python 3.2 alpha 4

[Paul Moore]

(Copying to the list, sorry Georg for the duplicate)

On 16 November 2010 14:05, Georg Brandl  wrote:
> On behalf of the Python development team, I'm happy to announce the
> fourth and (this time really) final alpha preview release of Python 3.2.

PEP 3148 (Futures) is noted in the PEP as going into 3.2, It also
seems to be in the release.

Should it not be added to the "What's new in 3.2" document and the
release announcements? It's a fairly significant feature.

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

[Alexander Belopolsky]

What this thread has shown is that there is no consensus on what
public names are and what rules should be followed when changing names
that can be imported from a module.  I have opened an issue at
http://bugs.python.org/issue10434 to address this.  My vote is to
adopt the definition spelled out in the language reference, copy it to
the library manual and add some discussion of the deprecation
policies.

I also have a similar question about C API.  Here, in absence of
__all__, the answer should be clear: all symbols in public header
files should start with either _Py_ or Py_ and those that start with
Py_ are public.   The question is what should be done with names that
start with Py_, but are not documented?  Can we add an underscore to
those names?  If so, should a (deprecated) alias be made available?
Should they be documented as deprecated?

I think these questions can only be answered on a case by case bases
which choices being:

1. Document.
2. Document as deprecated.
3. Document as deprecated, add underscore prefix and retain a deprecated alias.
4. Add an underscore prefix.

The specific set of names that I would like to consider is the
following from unicode.h.  I am marking with (*) the names that I
think should be documented and with (D) those that should be
deprecated:

PyUnicode_GetMax
PyUnicode_Resize (*)
PyUnicode_InternImmortal
PyUnicode_FromOrdinal (*)
PyUnicode_GetDefaultEncoding (D)
PyUnicode_AsDecodedObject
PyUnicode_AsDecodedUnicode
PyUnicode_AsEncodedObject
PyUnicode_AsEncodedUnicode
PyUnicode_BuildEncodingMap
PyUnicode_EncodeDecimal (*)
PyUnicode_Append (*)
PyUnicode_AppendAndDel (*)
PyUnicode_Partition (*)
PyUnicode_RPartition (*)
PyUnicode_RSplit (*)
PyUnicode_IsIdentifier (*)
Py_UNICODE_strlen
Py_UNICODE_strcpy
Py_UNICODE_strcat
Py_UNICODE_strncpy
Py_UNICODE_strcmp
Py_UNICODE_strncmp
Py_UNICODE_strchr
Py_UNICODE_strrchr


On Sat, Nov 13, 2010 at 7:12 AM, Giampaolo Rodolà  wrote:
> +1 on everything.
>
> 2010/11/11 Alexander Belopolsky :
>> 2010/11/11 Michael Foord :
>> ..
 You mean runtime automation, e.g. creating __all__ on the fly omitting
 underscored names?

>>> Writing code to generate a __all__ that duplicates the default behaviour
>>> seems redundant to me.
>>>
>>
>> FWIW, I like having __all__ at the top of the module.  It feels like a
>> table of contents at the start of a chapter.  In some cases it may
>> also serve as an optimization when len(__all__) is much smaller than
>> len(__dict__).  I also don't like _ prefix to become an exclusive
>> means to express privateness.
>>
>> I think the current definition of "public names" is a good one and
>> just needs to be made more visible in the docs.  If the module defines
>> __all__, that should be the ultimate answer to what is public in that
>> module.   (Users should learn to use help(module) instead of
>> dir(module) for API discovery.)   If __all__ is not defined in the
>> module, I think it is good to introduce it after a careful review of
>> what it should contain.  And __all__ should never contain names that
>> start with _.
>> ___
>> 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/g.rodola%40gmail.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

[Michael Foord]

On 16/11/2010 15:16, Alexander Belopolsky wrote:

What this thread has shown is that there is no consensus on what
public names are and what rules should be followed when changing names
that can be imported from a module.  I have opened an issue at
http://bugs.python.org/issue10434 to address this.  My vote is to
adopt the definition spelled out in the language reference, copy it to
the library manual and add some discussion of the deprecation
policies.



Whilst the definition in the reference manual is fine it only covers 
module level public APIs (which I realise is your particular concern) it 
doesn't cover whether a module in a package is public and doesn't cover 
class members. The rules for these follow as a natural extension, but if 
we are going to bother codifying the rules (which I think is good given 
the confusion) then it is worth covering these cases.


I posted a suggested wording in an earlier message:

http://mail.python.org/pipermail/python-dev/2010-November/105476.html

We could also note that existing modules that don't follow these rules 
will generally follow the deprecation rules for "accidentally public" 
names, but that this will be decided on a case-by-case basis and that 
names *obviously* never intended to be public may be changed if it is 
believed that they aren't (or really shouldn't be) in use.


All the best,

Michael Foord


I also have a similar question about C API.  Here, in absence of
__all__, the answer should be clear: all symbols in public header
files should start with either _Py_ or Py_ and those that start with
Py_ are public.   The question is what should be done with names that
start with Py_, but are not documented?  Can we add an underscore to
those names?  If so, should a (deprecated) alias be made available?
Should they be documented as deprecated?

I think these questions can only be answered on a case by case bases
which choices being:

1. Document.
2. Document as deprecated.
3. Document as deprecated, add underscore prefix and retain a deprecated alias.
4. Add an underscore prefix.

The specific set of names that I would like to consider is the
following from unicode.h.  I am marking with (*) the names that I
think should be documented and with (D) those that should be
deprecated:

PyUnicode_GetMax
PyUnicode_Resize (*)
PyUnicode_InternImmortal
PyUnicode_FromOrdinal (*)
PyUnicode_GetDefaultEncoding (D)
PyUnicode_AsDecodedObject
PyUnicode_AsDecodedUnicode
PyUnicode_AsEncodedObject
PyUnicode_AsEncodedUnicode
PyUnicode_BuildEncodingMap
PyUnicode_EncodeDecimal (*)
PyUnicode_Append (*)
PyUnicode_AppendAndDel (*)
PyUnicode_Partition (*)
PyUnicode_RPartition (*)
PyUnicode_RSplit (*)
PyUnicode_IsIdentifier (*)
Py_UNICODE_strlen
Py_UNICODE_strcpy
Py_UNICODE_strcat
Py_UNICODE_strncpy
Py_UNICODE_strcmp
Py_UNICODE_strncmp
Py_UNICODE_strchr
Py_UNICODE_strrchr


On Sat, Nov 13, 2010 at 7:12 AM, Giampaolo Rodolà  wrote:

+1 on everything.

2010/11/11 Alexander Belopolsky:

2010/11/11 Michael Foord:
..

You mean runtime automation, e.g. creating __all__ on the fly omitting
underscored names?


Writing code to generate a __all__ that duplicates the default behaviour
seems redundant to me.


FWIW, I like having __all__ at the top of the module.  It feels like a
table of contents at the start of a chapter.  In some cases it may
also serve as an optimization when len(__all__) is much smaller than
len(__dict__).  I also don't like _ prefix to become an exclusive
means to express privateness.

I think the current definition of "public names" is a good one and
just needs to be made more visible in the docs.  If the module defines
__all__, that should be the ultimate answer to what is public in that
module.   (Users should learn to use help(module) instead of
dir(module) for API discovery.)   If __all__ is not defined in the
module, I think it is good to introduce it after a careful review of
what it should contain.  And __all__ should never contain names that
start with _.
___
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/g.rodola%40gmail.com




--

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/lis

Re: [Python-Dev] Breaking undocumented API

[M.-A. Lemburg]

Alexander Belopolsky wrote:
> What this thread has shown is that there is no consensus on what
> public names are and what rules should be followed when changing names
> that can be imported from a module.  I have opened an issue at
> http://bugs.python.org/issue10434 to address this.  My vote is to
> adopt the definition spelled out in the language reference, copy it to
> the library manual and add some discussion of the deprecation
> policies.
> 
> I also have a similar question about C API.  Here, in absence of
> __all__, the answer should be clear: all symbols in public header
> files should start with either _Py_ or Py_ and those that start with
> Py_ are public.   The question is what should be done with names that
> start with Py_, but are not documented?  Can we add an underscore to
> those names?  If so, should a (deprecated) alias be made available?
> Should they be documented as deprecated?
> 
> I think these questions can only be answered on a case by case bases
> which choices being:
> 
> 1. Document.
> 2. Document as deprecated.
> 3. Document as deprecated, add underscore prefix and retain a deprecated 
> alias.
> 4. Add an underscore prefix.
> 
> The specific set of names that I would like to consider is the
> following from unicode.h.  I am marking with (*) the names that I
> think should be documented and with (D) those that should be
> deprecated:
> 
> PyUnicode_GetMax
> PyUnicode_Resize (*)
> PyUnicode_InternImmortal
> PyUnicode_FromOrdinal (*)
> PyUnicode_GetDefaultEncoding (D)
> PyUnicode_AsDecodedObject
> PyUnicode_AsDecodedUnicode
> PyUnicode_AsEncodedObject
> PyUnicode_AsEncodedUnicode
> PyUnicode_BuildEncodingMap
> PyUnicode_EncodeDecimal (*)
> PyUnicode_Append (*)
> PyUnicode_AppendAndDel (*)
> PyUnicode_Partition (*)
> PyUnicode_RPartition (*)
> PyUnicode_RSplit (*)
> PyUnicode_IsIdentifier (*)
> Py_UNICODE_strlen
> Py_UNICODE_strcpy
> Py_UNICODE_strcat
> Py_UNICODE_strncpy
> Py_UNICODE_strcmp
> Py_UNICODE_strncmp
> Py_UNICODE_strchr
> Py_UNICODE_strrchr

For Unicode, unicodeobject.h defines which APIs are private or not.
APIs which don't appear in the header file are either private or
need to be added to the header file (but I don't think there are
any in this category).

All APIs in the header that do not appear in the documentation,
should be added there as well. unicodeobject.h already provides
documentation for most of the APIs you've listed above (except some
new ones that were added later on).

One API I'm not sure about is PyUnicode_AppendAndDel(). It's somewhat
obscure and given that we already have PyUnicode_Concat(), I think
it should be made private and eventually dropped.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 16 2010)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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 Tue, Nov 16, 2010 at 7:16 AM, Alexander Belopolsky
 wrote:
> What this thread has shown is that there is no consensus on what
> public names are and what rules should be followed when changing names
> that can be imported from a module.  I have opened an issue at
> http://bugs.python.org/issue10434 to address this.  My vote is to
> adopt the definition spelled out in the language reference, copy it to
> the library manual and add some discussion of the deprecation
> policies.

Hm. Apart from the specific semantics assigned by the language to
single and double leading (and trailing) underscores, I still think
this belongs in a style guide, not in the library manual. When reading
the library manual, one should always assume that undocumented
features are subject to change at any time.

When writing library code, one should of course be much more
conservative, and guidelines for contributors are needed to ensure
that in the future we won't repeat the mistakes of the past (mostly my
own mistakes :-).

> I also have a similar question about C API.  Here, in absence of
> __all__, the answer should be clear: all symbols in public header
> files should start with either _Py_ or Py_ and those that start with
> Py_ are public.   The question is what should be done with names that
> start with Py_, but are not documented?  Can we add an underscore to
> those names?  If so, should a (deprecated) alias be made available?
> Should they be documented as deprecated?

Even more care should be taken here, since breakage is harder to fix,
especially in 3rd party code that needs to be compatible with a wide
range of Python versions.

The good news here is that the intended rule is very clear:

- *no* symbols that don't start with Py_ or _Py_ (unless there's a
technical reason why it can't be named that way)
- public == Py_
- private == _Py_

> I think these questions can only be answered on a case by case bases

Right!

> which choices being:
>
> 1. Document.
> 2. Document as deprecated.
> 3. Document as deprecated, add underscore prefix and retain a deprecated 
> alias.
> 4. Add an underscore prefix.
>
> The specific set of names that I would like to consider is the
> following from unicode.h.  I am marking with (*) the names that I
> think should be documented and with (D) those that should be
> deprecated:
>
> PyUnicode_GetMax
> PyUnicode_Resize (*)
> PyUnicode_InternImmortal
> PyUnicode_FromOrdinal (*)
> PyUnicode_GetDefaultEncoding (D)
> PyUnicode_AsDecodedObject
> PyUnicode_AsDecodedUnicode
> PyUnicode_AsEncodedObject
> PyUnicode_AsEncodedUnicode
> PyUnicode_BuildEncodingMap
> PyUnicode_EncodeDecimal (*)
> PyUnicode_Append (*)
> PyUnicode_AppendAndDel (*)
> PyUnicode_Partition (*)
> PyUnicode_RPartition (*)
> PyUnicode_RSplit (*)
> PyUnicode_IsIdentifier (*)
> Py_UNICODE_strlen
> Py_UNICODE_strcpy
> Py_UNICODE_strcat
> Py_UNICODE_strncpy
> Py_UNICODE_strcmp
> Py_UNICODE_strncmp
> Py_UNICODE_strchr
> Py_UNICODE_strrchr

I'll leave this to others more familiar with the Unicode code; I would
recommend being fairly conservative though since these have been
around for a long time.

-- 
--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] Stable buildbots

[Bill Janssen]

Ned Deily  wrote:

> In article <30929.1289879...@parc.com>, Bill Janssen  
> wrote:
> 
> > Both the Tiger buildbots are suddenly failing 3.x on test_cmd_line.
> > Looking at the changes since the last success, I can't see anything
> > which would obviously affect that...  Any suspects?
> 
> It appears to be a duplicate of Issue8458.  Playing with it again, it 
> seems to be a race condition: sometimes I see all three failures you 
> reported, sometimes just one, sometimes none.  Again, only on 10.4 
> (Tiger), not 10.5 or 10.6.  But the 10.4 machine I'm using is by far the 
> slowest of the three so it is possible that could be a factor.

Good thought.  It's also the slowest of my buildbots -- dual 1GHz PPC.

> Perhaps a race condition with cleaning up the p2c pipe from a previous run?
> 
> > Here's what's failing:
> > 
> > ==
> > ERROR: test_run_code (test.test_cmd_line.CmdLineTest)
> > --
> > Traceback (most recent call last):
> >   File 
> >   
> > "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_cmd_line.py"
> >   , line 95, in test_run_code
> > assert_python_failure('-c')
> >   File 
> >   
> > "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py"
> >   , line 55, in assert_python_failure
> > return _assert_python(False, *args, **env_vars)
> >   File 
> >   
> > "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py"
> >   , line 29, in _assert_python
> > env=env)
> >   File 
> > "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/subprocess.py", 
> >   line 683, in __init__
> > self.stdin = io.open(p2cwrite, 'wb', bufsize)
> > OSError: [Errno 9] Bad file descriptor
> > 
> > ==
> > ERROR: test_run_module (test.test_cmd_line.CmdLineTest)
> > --
> > Traceback (most recent call last):
> >   File 
> >   
> > "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_cmd_line.py"
> >   , line 72, in test_run_module
> > assert_python_failure('-m')
> >   File 
> >   
> > "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py"
> >   , line 55, in assert_python_failure
> > return _assert_python(False, *args, **env_vars)
> >   File 
> >   
> > "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py"
> >   , line 29, in _assert_python
> > env=env)
> >   File 
> > "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/subprocess.py", 
> >   line 683, in __init__
> > self.stdin = io.open(p2cwrite, 'wb', bufsize)
> > OSError: [Errno 9] Bad file descriptor
> > 
> > ==
> > ERROR: test_version (test.test_cmd_line.CmdLineTest)
> > --
> > Traceback (most recent call last):
> >   File 
> >   
> > "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_cmd_line.py"
> >   , line 48, in test_version
> > rc, out, err = assert_python_ok('-V')
> >   File 
> >   
> > "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py"
> >   , line 48, in assert_python_ok
> > return _assert_python(True, *args, **env_vars)
> >   File 
> >   
> > "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py"
> >   , line 29, in _assert_python
> > env=env)
> >   File 
> > "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/subprocess.py", 
> >   line 683, in __init__
> > self.stdin = io.open(p2cwrite, 'wb', bufsize)
> > OSError: [Errno 9] Bad file descriptor
> 
> -- 
>  Ned Deily,
>  n...@acm.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/bill%40janssen.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

[exarkun]

On 03:48 pm, gu...@python.org wrote:

On Tue, Nov 16, 2010 at 7:16 AM, Alexander Belopolsky
 wrote:

What this thread has shown is that there is no consensus on what
public names are and what rules should be followed when changing names
that can be imported from a module. �I have opened an issue at
http://bugs.python.org/issue10434 to address this. �My vote is to
adopt the definition spelled out in the language reference, copy it to
the library manual and add some discussion of the deprecation
policies.


Hm. Apart from the specific semantics assigned by the language to
single and double leading (and trailing) underscores, I still think
this belongs in a style guide, not in the library manual. When reading
the library manual, one should always assume that undocumented
features are subject to change at any time.


I don't think it belongs only in PEP 8 (that's "a style guide" you're 
referring to, correct?).  It needs to be front and center.  This is 
information that every single user of the stdlib needs in order to use 
the stdlib correctly.


Imagine trying to use a dictionary without knowing about alphabetical 
ordering.  Or driving a car without knowing what lane markers indicate.


No matter how many times we discuss this policy on this list (I know 
it's come up here before), the majority of python users still won't 
learn about it.


PEP 8 isn't nearly visible enough, either.  Whatever the rule is, it 
needs to be presented with the information itself.  If the rule is that 
things not documented in the library manual have no compatibility 
guarantees, then all of the means of getting documentation *other* than 
looking at the library manual need to indicate this somehow 
(alternatively, the information shouldn't be duplicated, but I doubt 
I'll convince anyone of that).


Here's a stupid proposal.  What if the top of pydoc output said (for 
stdlib modules only) "The library manual is the canonical reference. 
Refer to it before using APIs you find in this documentation."  Still 
inconvenient, but inconvenient is better than secret/impossible.


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] [RELEASED] Python 3.2 alpha 4

[Raymond Hettinger]

On Nov 16, 2010, at 7:05 AM, Paul Moore wrote:
> 
> PEP 3148 (Futures) is noted in the PEP as going into 3.2, It also
> seems to be in the release.
> 
> Should it not be added to the "What's new in 3.2" document and the
> release announcements? It's a fairly significant feature.

I'll update the whatsnew document before the beta goes out.


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] [RELEASED] Python 3.2 alpha 4

[Raymond Hettinger]

On Nov 16, 2010, at 7:05 AM, Paul Moore wrote:
> 
> PEP 3148 (Futures) is noted in the PEP as going into 3.2, It also
> seems to be in the release.
> 
> Should it not be added to the "What's new in 3.2" document and the
> release announcements? It's a fairly significant feature.

I'll update the whatsnew document before the beta goes out.


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

[Antoine Pitrou]

On Tue, 16 Nov 2010 16:34:54 -
exar...@twistedmatrix.com wrote:
> 
> Imagine trying to use a dictionary without knowing about alphabetical 
> ordering.

You mean an ordered dictionary, right?



___
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 Tue, Nov 16, 2010 at 10:38 AM, M.-A. Lemburg  wrote:
..
> One API I'm not sure about is PyUnicode_AppendAndDel(). It's somewhat
> obscure and given that we already have PyUnicode_Concat(), I think
> it should be made private and eventually dropped.
>

What about PyUnicode_GetMax()?  Isn't that supposed to be
Py_UNICODE_GETMAX()?  Or better still Py_UNICODE_MAXORDINAL?
___
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

[Łukasz Langa]

Am 16.11.2010 18:06, schrieb Antoine Pitrou:

On Tue, 16 Nov 2010 16:34:54 -
exar...@twistedmatrix.com wrote:

Imagine trying to use a dictionary without knowing about alphabetical
ordering.

You mean an ordered dictionary, right?


He meant the ones with actual paper pages.
___
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 16/11/2010 17:16, Łukasz Langa wrote:

Am 16.11.2010 18:06, schrieb Antoine Pitrou:

On Tue, 16 Nov 2010 16:34:54 -
exar...@twistedmatrix.com wrote:

Imagine trying to use a dictionary without knowing about alphabetical
ordering.

You mean an ordered dictionary, right?


He meant the ones with actual paper pages.


But given that we are particularly talking about how to handle 
undocumented APIs, a more apropos comparison would be to ask how 
dictionary readers are supposed to look up words that aren't in the 
dictionary...


This is why I think it *is* a style issue for developers - the more 
important decision is codifying how we decide what words need to go in 
the dictionary (to continue to torture the analogy).


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

[exarkun]

On 05:21 pm, fuzzy...@voidspace.org.uk wrote:

On 16/11/2010 17:16, 1ukasz Langa wrote:

Am 16.11.2010 18:06, schrieb Antoine Pitrou:

On Tue, 16 Nov 2010 16:34:54 -
exar...@twistedmatrix.com wrote:
Imagine trying to use a dictionary without knowing about 
alphabetical

ordering.

You mean an ordered dictionary, right?


He meant the ones with actual paper pages.


But given that we are particularly talking about how to handle 
undocumented APIs, a more apropos comparison would be to ask how 
dictionary readers are supposed to look up words that aren't in the 
dictionary...


No, this isn't an appropriate comparison.  The dictionary was an example 
of something that presents information but is very hard to use without 
knowing the rules.


We're not talking about undocumented APIs.  We're talking about APIs 
that are documented somewhere other than in the library manual.


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

[M.-A. Lemburg]

Alexander Belopolsky wrote:
> On Tue, Nov 16, 2010 at 10:38 AM, M.-A. Lemburg  wrote:
> ..
>> One API I'm not sure about is PyUnicode_AppendAndDel(). It's somewhat
>> obscure and given that we already have PyUnicode_Concat(), I think
>> it should be made private and eventually dropped.
>>
> 
> What about PyUnicode_GetMax()?  Isn't that supposed to be
> Py_UNICODE_GETMAX()?  Or better still Py_UNICODE_MAXORDINAL?

Traditionally, all uppercase symbols refer to macros, whereas
the mixed case ones refer to functions.

Now, we can't use a macro for this, since the information has
to be available as callable in order to applications or extensions
to use it (without recompile).

Regarding the name: PyUnicode_MaxOrdinal() would certainly
have been better.

BTW: I'm not really happy about the Py_UNICODE_ prefix for functions
in unicodeobject.h, but I guess it's too late to change those.
It would be better to stick to one prefix for Unicode related
APIs, i.e. "PyUnicode_".

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 16 2010)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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

[Georg Brandl]

Am 16.11.2010 18:06, schrieb Antoine Pitrou:
> On Tue, 16 Nov 2010 16:34:54 -
> exar...@twistedmatrix.com wrote:
>> 
>> Imagine trying to use a dictionary without knowing about alphabetical 
>> ordering.
> 
> You mean an ordered dictionary, right?

That one's a sorted dictionary, 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] Breaking undocumented API

[Alexander Belopolsky]

On Tue, Nov 16, 2010 at 1:06 PM, M.-A. Lemburg  wrote:
..
> Now, we can't use a macro for [PyUnicode_GetMax()], since the information has
> to be available as callable in order to applications or extensions
> to use it (without recompile).
>

.. but it *is* a macro resolving to either PyUnicodeUCS2_GetMax or
PyUnicodeUCS4_GetMax.  What is the scenario when may want to change
what PyUnicodeUCS?_GetMax return and have extensions pick up the
change without a recompile? UCS2 case will certainly never change
since it is already 0x.  Is it possible that USC4 will be expanded
beyond 0x10?  Note that we can have both a macro and a function
version.  This is fairly standard practice in Python C-API.
___
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] Mercurial Schedule

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Is there any updated mercurial schedule?.

Any impact related with the new 3.2 schedule (three weeks offset)?

- -- 
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/

iQCVAwUBTOLPj5lgi5GaxT1NAQKM4gQAnL+pDmsc8PjPYCdCMf50pe6NwUs60D54
O3t8IgtbQJi9HqL5KJIJ99ZYlBOzze0lCy25NWNmnSrt6ISoU3IuTe7SUJ24iWKH
T4x9MzRog5eIfa7z37aCJiIfvRJV4Q2drL4C6U1VFSji13EpknkGXefvyNToc+OX
IDSM9ESZmGc=
=vSL9
-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] Breaking undocumented API

[Alexander Belopolsky]

On Tue, Nov 16, 2010 at 1:06 PM, M.-A. Lemburg  wrote:
..
> BTW: I'm not really happy about the Py_UNICODE_ prefix for functions
> in unicodeobject.h, but I guess it's too late to change those.
> It would be better to stick to one prefix for Unicode related
> APIs, i.e. "PyUnicode_".

I don't have a problem with this.  It makes sense that functions that
operate on PyUnicode objects start with PyUnicode_ and those that
operate on Py_UNICODE ordinals start with Py_UNICODE_.  Of course,
PyUnicode should have been named PyUnicodeObject and Py_UNICODE should
have been named Py_wchar_t, but that's a different story.
___
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

[M.-A. Lemburg]

Alexander Belopolsky wrote:
> On Tue, Nov 16, 2010 at 1:06 PM, M.-A. Lemburg  wrote:
> ..
>> Now, we can't use a macro for [PyUnicode_GetMax()], since the information has
>> to be available as callable in order to applications or extensions
>> to use it (without recompile).
>>
> 
> .. but it *is* a macro resolving to either PyUnicodeUCS2_GetMax or
> PyUnicodeUCS4_GetMax.

That doesn't count :-) It's only a trick to prevent external code
from using the wrong Unicode APIs.

There still is a real function behind the renaming.

> What is the scenario when may want to change
> what PyUnicodeUCS?_GetMax return and have extensions pick up the
> change without a recompile? 

If an extensions uses the stable ABI, it will want to know
whether the interpreter was built for UCS2 or UCS4 (even if
it doesn't use the Unicode APIs directly).

> UCS2 case will certainly never change
> since it is already 0x.  Is it possible that USC4 will be expanded
> beyond 0x10? 

Well, the Unicode Consortium decided to not go beyond 0x10,
but then you never know... when they started out on the quest,
16 bits appeared more than enough, but they found out relatively
quickly that the Asian scripts had enough code points to easily
fill that space.

Once space is available, it tends to get used sooner or later :-)

> Note that we can have both a macro and a function
> version.  This is fairly standard practice in Python C-API.

Sure, but what for ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 16 2010)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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 Tue, Nov 16, 2010 at 1:57 PM, M.-A. Lemburg  wrote:
..
>> Note that we can have both a macro and a function
>> version.  This is fairly standard practice in Python C-API.
>
> Sure, but what for ?
>

Mostly just for consistency with the other macros:

http://docs.python.org/dev/py3k/c-api/unicode.html#unicode-character-properties

Wait, these actually map to C functions as well.  So this is just a
naming issue.
___
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/16/2010 10:16 AM, Alexander Belopolsky wrote:

What this thread has shown is that there is no consensus on what
public names are and what rules should be followed when changing names
that can be imported from a module.


Nor is their any consensus on the use of __all__ in the stdlib, with 
opinion ranging from never to sometimes to always.


I do not have any opinions on the particular solution adopted, but 
appreciate your persistence in pushing to *some* solution. It would be 
nice to add 'Cleanly separated public and private APIs' to the list of 
3.x features.


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

[M.-A. Lemburg]

Alexander Belopolsky wrote:
> On Tue, Nov 16, 2010 at 1:57 PM, M.-A. Lemburg  wrote:
> ..
>>> Note that we can have both a macro and a function
>>> version.  This is fairly standard practice in Python C-API.
>>
>> Sure, but what for ?
>>
> 
> Mostly just for consistency with the other macros:
> 
> http://docs.python.org/dev/py3k/c-api/unicode.html#unicode-character-properties
> 
> Wait, these actually map to C functions as well.  So this is just a
> naming issue.

As said: the UCS2/4 name mangling doesn't count fall under the
macro naming scheme, since it's done transparently and with a
different reasoning in mind, than when you decide to use a macro
to access some object detail, or want to avoid repetition. This
trick was also added after the original APIs had already been documented
for a while, so there was no way to change their names anymore.

The various ctype functions use macro names for historic
reasons: they were directed to different functions and/or
inline code depending on a configuration switch. This is now
gone, since the lib C ctype functions were locale aware and
often implemented things a little differently than the Python
ctype tables.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 16 2010)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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] PyUnicode_GetMax() and PyUnicode_FromOrdinal() Was: Breaking undocumented API

[Alexander Belopolsky]

On Tue, Nov 16, 2010 at 1:57 PM, M.-A. Lemburg  wrote:
> Alexander Belopolsky wrote:
>> On Tue, Nov 16, 2010 at 1:06 PM, M.-A. Lemburg  wrote:
>> ..
>>> Now, we can't use a macro for [PyUnicode_GetMax()], since the information 
>>> has
>>> to be available as callable in order to applications or extensions
>>> to use it (without recompile).
>>>
>>
>> .. but it *is* a macro resolving to either PyUnicodeUCS2_GetMax or
>> PyUnicodeUCS4_GetMax.
>
> That doesn't count :-) It's only a trick to prevent external code
> from using the wrong Unicode APIs.
>
> There still is a real function behind the renaming.
>
>> What is the scenario when may want to change
>> what PyUnicodeUCS?_GetMax return and have extensions pick up the
>> change without a recompile?
>
> If an extensions uses the stable ABI, it will want to know
> whether the interpreter was built for UCS2 or UCS4 (even if
> it doesn't use the Unicode APIs directly).
>
>> UCS2 case will certainly never change
>> since it is already 0x.  Is it possible that USC4 will be expanded
>> beyond 0x10?
>
> Well, the Unicode Consortium decided to not go beyond 0x10,
> but then you never know... when they started out on the quest,
> 16 bits appeared more than enough, but they found out relatively
> quickly that the Asian scripts had enough code points to easily
> fill that space.
>
> Once space is available, it tends to get used sooner or later :-)
>
>> Note that we can have both a macro and a function
>> version.  This is fairly standard practice in Python C-API.
>
> Sure, but what for ?

Note that PyUnicode_FromOrdinal()  is documented (in unicodeobject.h)
as follows without a reference to PyUnicode_GetMax():

"""
   Create a Unicode Object from the given Unicode code point ordinal.

   The ordinal must be in range(0x1) on narrow Python builds
   (UCS2), and range(0x11) on wide builds (UCS4). A ValueError is
   raised in case it is not.
"""

The actual implementation actually checks UCS4 range only.

if (ordinal < 0 || ordinal > 0x10) {
PyErr_SetString(PyExc_ValueError,
"chr() arg not in range(0x11)");
return NULL;
}

This actually looks like a bug:

>>> len(chr(0x10))
2

(on a USC2 build.)

Also, I think PyUnicode_FromOrdinal()  should take Py_UNICODE argument
rather than int.
___
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] PyUnicode_GetMax() and PyUnicode_FromOrdinal() Was: Breaking undocumented API

[M.-A. Lemburg]

Alexander Belopolsky wrote:
> On Tue, Nov 16, 2010 at 1:57 PM, M.-A. Lemburg  wrote:
>> Alexander Belopolsky wrote:
>>> On Tue, Nov 16, 2010 at 1:06 PM, M.-A. Lemburg  wrote:
>>> ..
 Now, we can't use a macro for [PyUnicode_GetMax()], since the information 
 has
 to be available as callable in order to applications or extensions
 to use it (without recompile).

>>>
>>> .. but it *is* a macro resolving to either PyUnicodeUCS2_GetMax or
>>> PyUnicodeUCS4_GetMax.
>>
>> That doesn't count :-) It's only a trick to prevent external code
>> from using the wrong Unicode APIs.
>>
>> There still is a real function behind the renaming.
>>
>>> What is the scenario when may want to change
>>> what PyUnicodeUCS?_GetMax return and have extensions pick up the
>>> change without a recompile?
>>
>> If an extensions uses the stable ABI, it will want to know
>> whether the interpreter was built for UCS2 or UCS4 (even if
>> it doesn't use the Unicode APIs directly).
>>
>>> UCS2 case will certainly never change
>>> since it is already 0x.  Is it possible that USC4 will be expanded
>>> beyond 0x10?
>>
>> Well, the Unicode Consortium decided to not go beyond 0x10,
>> but then you never know... when they started out on the quest,
>> 16 bits appeared more than enough, but they found out relatively
>> quickly that the Asian scripts had enough code points to easily
>> fill that space.
>>
>> Once space is available, it tends to get used sooner or later :-)
>>
>>> Note that we can have both a macro and a function
>>> version.  This is fairly standard practice in Python C-API.
>>
>> Sure, but what for ?
> 
> Note that PyUnicode_FromOrdinal()  is documented (in unicodeobject.h)
> as follows without a reference to PyUnicode_GetMax():
> 
> """
>Create a Unicode Object from the given Unicode code point ordinal.
> 
>The ordinal must be in range(0x1) on narrow Python builds
>(UCS2), and range(0x11) on wide builds (UCS4). A ValueError is
>raised in case it is not.
> """
>
> The actual implementation actually checks UCS4 range only.
> 
> if (ordinal < 0 || ordinal > 0x10) {
>   PyErr_SetString(PyExc_ValueError,
> "chr() arg not in range(0x11)");
> return NULL;
> }
> 
> This actually looks like a bug:
> 
 len(chr(0x10))
> 2
> 
> (on a USC2 build.)

Yes, it's a documentation bug. I guess someone forgot to update
the comment in unicodeobject.h after the change to have chr()/unichr()
return a 2-char string instead of a 1-char string for non-BMP
code points.

> Also, I think PyUnicode_FromOrdinal()  should take Py_UNICODE argument
> rather than int.

No, an ordinal is a number, not a typed value. We have
PyUnicode_FromUnicode() to create strings from Py_UNICODE*
arrays.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 16 2010)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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 bug week-end : 20-21 November

[Rodrigo Bernardo Pimentel]

On 26 October 2010 18:04, Georg Brandl  wrote:
> Am 26.10.2010 19:53, schrieb Brett Cannon:
>> Can whomever has edit access to the Python Google Calendar add this?
>
> Done.

The Bug Weekend is still up, right? I don't see mention of it at
http://wiki.python.org/moin/PythonBugDay (and when I tried to log in
to edit, I got "A problem occurred in a Python script." - now, I
thought no problems ever occurred on Python scripts! ;)).



    rbp
--
 http://isnomore.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] PyUnicode_GetMax() and PyUnicode_FromOrdinal() Was: Breaking undocumented API

[Alexander Belopolsky]

On Tue, Nov 16, 2010 at 3:06 PM, M.-A. Lemburg  wrote:
..
> len(chr(0x10))
>> 2
>>
>> (on a USC2 build.)
>
> Yes, it's a documentation bug. I guess someone forgot to update
> the comment in unicodeobject.h after the change to have chr()/unichr()
> return a 2-char string instead of a 1-char string for non-BMP
> code points.

Same problem in reST doc for chr(i):

"""
chr(i)

Return the string of one character whose Unicode codepoint is the
integer i. For example, chr(97) returns the string 'a'. This is the
inverse of ord(). The valid range for the argument depends how Python
was configured – it may be either UCS2 [0..0x] or UCS4
[0..0x10]. ValueError will be raised if i is outside that range.
""" http://docs.python.org/dev/py3k/library/functions.html?chr

And in ord(c):

"""
ord(c)

Given a string of length one, return an integer representing the
Unicode code point of the character. For example, ord('a') returns the
integer 97 and ord('\u2020') returns 8224. This is the inverse of
chr().

If the argument length is not one, a TypeError will be raised. (If
Python was built with UCS2 Unicode, then the character’s code point
must be in the range [0..65535] inclusive; otherwise the string length
is two!)
""" http://docs.python.org/dev/py3k/library/functions.html#ord
___
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 bug week-end : 20-21 November

[Georg Brandl]

Am 16.11.2010 21:15, schrieb Rodrigo Bernardo Pimentel:
> On 26 October 2010 18:04, Georg Brandl  wrote:
>> Am 26.10.2010 19:53, schrieb Brett Cannon:
>>> Can whomever has edit access to the Python Google Calendar add this?
>>
>> Done.
> 
> The Bug Weekend is still up, right? I don't see mention of it at
> http://wiki.python.org/moin/PythonBugDay (and when I tried to log in
> to edit, I got "A problem occurred in a Python script." - now, I
> thought no problems ever occurred on Python scripts! ;)).

Yeah, somebody (Antoine?) should update that wiki page...

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

[Ben Finney]

exar...@twistedmatrix.com writes:

> On 03:48 pm, gu...@python.org wrote:
> >Hm. Apart from the specific semantics assigned by the language to
> >single and double leading (and trailing) underscores, I still think
> >this belongs in a style guide, not in the library manual.
>
> I don't think it belongs only in PEP 8 (that's "a style guide" you're
> referring to, correct?).

I don't know about Guido, but I'd be −1 on suggestions to add more
normative information to PEP 7, PEP 8, PEP 257, or any other established
style guide PEP. I certainly don't want to have to keep going back to
the same documents frequently just to see if the set of recommendations
I already know has changed recently.

Rather, I took Guido's mention of “this belongs in a style guide” as
suggesting a *new* style guide. Perhaps one that explicitly obsoletes an
existing one or perhaps not; either way, the updated normative
recommendations are in a new document with a new name, so that one knows
whether one has already read it.

> It needs to be front and center. This is information that every single
> user of the stdlib needs in order to use the stdlib correctly.

True enough. This is information that goes beyond a style guide for
writers, and into conventions that API users need to know also.

-- 
 \ “I went to the museum where they had all the heads and arms |
  `\  from the statues that are in all the other museums.” —Steven |
_o__)   Wright |
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

[Fred Drake]

On Tue, Nov 16, 2010 at 4:31 PM, Ben Finney  wrote:
> I don't know about Guido, but I'd be -1 on suggestions to add more
> normative information to PEP 7, PEP 8, PEP 257, or any other established
> style guide PEP. I certainly don't want to have to keep going back to
> the same documents frequently just to see if the set of recommendations
> I already know has changed recently.

Agreed.

Many style guides are written as extensions of PEP 8 in particular.
This has already bitten the Zope community, which was developing style
beyond what was even written in it's own extension, only to have PEP 8
change out from under it in a contrary manner.

Lessons we learned:

- If you refer to someone else's documents, refer to specific versions.
  References can be updated explicitly if desired.

- If you have even an advisory point of style, write it down in the style
  guide, so people who read the foundational documents you referred to
  without version information will be aware of the expectations.

Otherwise, you may as well not have one.


  -Fred

--
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
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 Tue, Nov 16, 2010 at 8:34 AM,   wrote:
> On 03:48 pm, gu...@python.org wrote:
>>
>> On Tue, Nov 16, 2010 at 7:16 AM, Alexander Belopolsky
>>  wrote:
>>>
>>> What this thread has shown is that there is no consensus on what
>>> public names are and what rules should be followed when changing names
>>> that can be imported from a module.  I have opened an issue at
>>> http://bugs.python.org/issue10434 to address this.  My vote is to
>>> adopt the definition spelled out in the language reference, copy it to
>>> the library manual and add some discussion of the deprecation
>>> policies.
>>
>> Hm. Apart from the specific semantics assigned by the language to
>> single and double leading (and trailing) underscores, I still think
>> this belongs in a style guide, not in the library manual. When reading
>> the library manual, one should always assume that undocumented
>> features are subject to change at any time.
>
> I don't think it belongs only in PEP 8 (that's "a style guide" you're
> referring to, correct?).  It needs to be front and center.  This is
> information that every single user of the stdlib needs in order to use the
> stdlib correctly.

That depends on what methods you're imagining "every single user" is
using to find out what the API *is*.

In my experience there are many ways people do this:

- by reading the source

- by reading the official docs

- by trial and error

- inspection of objects (e.g. dir())

- using help()

- by reading pydoc output collected on some website (or local disk)

- by following tutorials

- by reading books containing reference documentation generated by 3rd
party authors

Most people do several of those things. (Personally, I learned about
many APIs by creating them. But I'm probably an exception. :-)

> No matter how many times we discuss this policy on this list (I know it's
> come up here before), the majority of python users still won't learn about
> it.

Agreed. And adding a disclaimer to help() or pydoc output won't make
much of a difference, I expect.

> PEP 8 isn't nearly visible enough, either.  Whatever the rule is, it needs
> to be presented with the information itself.  If the rule is that things not
> documented in the library manual have no compatibility guarantees, then all
> of the means of getting documentation *other* than looking at the library
> manual need to indicate this somehow (alternatively, the information
> shouldn't be duplicated, but I doubt I'll convince anyone of that).

Assuming people actually read the disclaimers.

> Here's a stupid proposal.  What if the top of pydoc output said (for stdlib
> modules only) "The library manual is the canonical reference. Refer to it
> before using APIs you find in this documentation."  Still inconvenient, but
> inconvenient is better than secret/impossible.

Personally I think it would be sufficient if the disclaimer was at the
top of the library reference itself. That's certainly enough from a
legalistic "I told you so" POV and I doubt that we'll be able to move
the POV of what people actually use...

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

[Alexander Belopolsky]

On Tue, Nov 16, 2010 at 4:31 PM, Ben Finney  wrote:
..
> I don't know about Guido, but I'd be -1 on suggestions to add more
> normative information to PEP 7, PEP 8, PEP 257, or any other established
> style guide PEP. I certainly don't want to have to keep going back to
> the same documents frequently just to see if the set of recommendations
> I already know has changed recently.
>
> Rather, I took Guido's mention of "this belongs in a style guide" as
> suggesting a *new* style guide. Perhaps one that explicitly obsoletes an
> existing one or perhaps not; either way, the updated normative
> recommendations are in a new document with a new name, so that one knows
> whether one has already read it.
>

+1

Numbered PEPs, while well-known to old-timers, are really odd place
for newcomers to find a style guide.  This really should be a separate
part at the top level of docs.python.org.  Note that we already have a
documentation style guide under "Documenting Python."   Maybe we
should reuse this slot and have say "Python Development" part which
will put together PEP 7, PEP 8 and documentation "Style Guide" in one
convenient package.

This, however, is a much bigger project than what I had in mind when I
started this thread.
___
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]

I created http://bugs.python.org/issue10435 to follow up on unicode C
API issues.

On Tue, Nov 16, 2010 at 10:38 AM, M.-A. Lemburg  wrote:
> Alexander Belopolsky wrote:
>> What this thread has shown is that there is no consensus on what
>> public names are and what rules should be followed when changing names
>> that can be imported from a module.  I have opened an issue at
>> http://bugs.python.org/issue10434 to address this.  My vote is to
>> adopt the definition spelled out in the language reference, copy it to
>> the library manual and add some discussion of the deprecation
>> policies.
>>
>> I also have a similar question about C API.  Here, in absence of
>> __all__, the answer should be clear: all symbols in public header
>> files should start with either _Py_ or Py_ and those that start with
>> Py_ are public.   The question is what should be done with names that
>> start with Py_, but are not documented?  Can we add an underscore to
>> those names?  If so, should a (deprecated) alias be made available?
>> Should they be documented as deprecated?
>>
>> I think these questions can only be answered on a case by case bases
>> which choices being:
>>
>> 1. Document.
>> 2. Document as deprecated.
>> 3. Document as deprecated, add underscore prefix and retain a deprecated 
>> alias.
>> 4. Add an underscore prefix.
>>
>> The specific set of names that I would like to consider is the
>> following from unicode.h.  I am marking with (*) the names that I
>> think should be documented and with (D) those that should be
>> deprecated:
>>
>> PyUnicode_GetMax
>> PyUnicode_Resize (*)
>> PyUnicode_InternImmortal
>> PyUnicode_FromOrdinal (*)
>> PyUnicode_GetDefaultEncoding (D)
>> PyUnicode_AsDecodedObject
>> PyUnicode_AsDecodedUnicode
>> PyUnicode_AsEncodedObject
>> PyUnicode_AsEncodedUnicode
>> PyUnicode_BuildEncodingMap
>> PyUnicode_EncodeDecimal (*)
>> PyUnicode_Append (*)
>> PyUnicode_AppendAndDel (*)
>> PyUnicode_Partition (*)
>> PyUnicode_RPartition (*)
>> PyUnicode_RSplit (*)
>> PyUnicode_IsIdentifier (*)
>> Py_UNICODE_strlen
>> Py_UNICODE_strcpy
>> Py_UNICODE_strcat
>> Py_UNICODE_strncpy
>> Py_UNICODE_strcmp
>> Py_UNICODE_strncmp
>> Py_UNICODE_strchr
>> Py_UNICODE_strrchr
>
> For Unicode, unicodeobject.h defines which APIs are private or not.
> APIs which don't appear in the header file are either private or
> need to be added to the header file (but I don't think there are
> any in this category).
>
> All APIs in the header that do not appear in the documentation,
> should be added there as well. unicodeobject.h already provides
> documentation for most of the APIs you've listed above (except some
> new ones that were added later on).
>
> One API I'm not sure about is PyUnicode_AppendAndDel(). It's somewhat
> obscure and given that we already have PyUnicode_Concat(), I think
> it should be made private and eventually dropped.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source  (#1, Nov 16 2010)
 Python/Zope Consulting and Support ...        http://www.egenix.com/
 mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
> 
>
> ::: Try our new mxODBC.Connect Python Database Interface for free ! 
>
>
>   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>           Registered at Amtsgericht Duesseldorf: HRB 46611
>               http://www.egenix.com/company/contact/
>
___
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 16, 2010, at 4:49 PM, Guido van Rossum wrote:

>> PEP 8 isn't nearly visible enough, either.  Whatever the rule is, it needs
>> to be presented with the information itself.  If the rule is that things not
>> documented in the library manual have no compatibility guarantees, then all
>> of the means of getting documentation *other* than looking at the library
>> manual need to indicate this somehow (alternatively, the information
>> shouldn't be duplicated, but I doubt I'll convince anyone of that).
> 
> Assuming people actually read the disclaimers.

I don't think it necessarily needs to be presented as a disclaimer.  There will 
always be people who just ignore part of the information presented, but the 
message could be something along the lines of "Here's some basic documentation, 
but it might be out-of-date or incomplete.  You can find a better reference at 
."  If it's easy to click on the link, I 
think a lot of people will click on it.  Especially since the library reference 
really _is_ more helpful than the docstrings, for the standard library.

(IMHO, dir()'s semantics are so weird that it should emit a warning too, like 
"looking for docs?  please use help()".)

___
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] Mercurial Schedule

[Georg Brandl]

Am 16.11.2010 19:38, schrieb Jesus Cea:
> Is there any updated mercurial schedule?.
> 
> Any impact related with the new 3.2 schedule (three weeks offset)?

I've been trying to contact Dirkjan and ask; generally, I don't
see much connection to the 3.2 schedule (with the exception that
the final migration day should not be a release day.)

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