Re: [Python-Dev] [Python-checkins] cpython: Optimize string slicing to use the new API

2011-10-05 Thread Martin v. Löwis

I see this as a micro-optimization. IMO we should *not* rely on these
assumptions because we cannot expect that all developers of third party
modules will be able to write perfect code, and some (lazy developers!)
may prefer to use a fixed maximum character (e.g. 0x).


Hmm. I'd like to declare that it is incorrect usage of the API, only 
allowing maxchar to be at the next boundary (i.e. 127, 255, 65536,

larger).

There are always cases of incorrect usage of all API. For example,
not filling out a list entirely (i.e. leaving NULL in some fields)
may also cause strange results.

Users will need to learn what the API is. At the first approximation,
maxchar should be the true maximum character.


To be able to rely on such assumption, we have to make sure that strings
are in canonical forms (always check before using a string?).


No, we don't need that: garbage in, garbage out. If people use the API
incorrectly, they will get incorrect results. It's useful to have checks
in debug mode, but that's the most that people should reasonably expect.

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] Using PEP384 Stable ABI for the lzma extension module

2011-10-05 Thread Martin v. Löwis

Not sure what you are using it for. If you need to extend the buffer
in case it is too small, there is absolutely no way this could work
without copies in the general case because of how computers use
address space. Even _PyBytes_Resize will copy the data.


That's not a given. Depending on the memory allocator, a copy can be
avoided. That's why the str += str hack is much more efficient under
Linux than Windows, AFAIK.


Even Linux will have to copy a block on realloc in certain cases, no?

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] Using PEP384 Stable ABI for the lzma extension module

2011-10-05 Thread Antoine Pitrou
Le mercredi 05 octobre 2011 à 18:12 +0200, Martin v. Löwis a écrit :
  Not sure what you are using it for. If you need to extend the buffer
  in case it is too small, there is absolutely no way this could work
  without copies in the general case because of how computers use
  address space. Even _PyBytes_Resize will copy the data.
 
  That's not a given. Depending on the memory allocator, a copy can be
  avoided. That's why the str += str hack is much more efficient under
  Linux than Windows, AFAIK.
 
 Even Linux will have to copy a block on realloc in certain cases, no?

Probably so. How often is totally unknown to me :)

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] Using PEP384 Stable ABI for the lzma extension module

2011-10-05 Thread Toshio Kuratomi
On Wed, Oct 05, 2011 at 06:14:08PM +0200, Antoine Pitrou wrote:
 Le mercredi 05 octobre 2011 à 18:12 +0200, Martin v. Löwis a écrit :
   Not sure what you are using it for. If you need to extend the buffer
   in case it is too small, there is absolutely no way this could work
   without copies in the general case because of how computers use
   address space. Even _PyBytes_Resize will copy the data.
  
   That's not a given. Depending on the memory allocator, a copy can be
   avoided. That's why the str += str hack is much more efficient under
   Linux than Windows, AFAIK.
  
  Even Linux will have to copy a block on realloc in certain cases, no?
 
 Probably so. How often is totally unknown to me :)
 
http://www.gnu.org/software/libc/manual/html_node/Changing-Block-Size.html

It depends on whether there's enough free memory after the buffer you
currently have allocated.  I suppose that this becomes a question of what
people consider the general case :-)

-Toshio


pgpCHlc9jDncJ.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] Using PEP384 Stable ABI for the lzma extension module

2011-10-05 Thread Antoine Pitrou
On Wed, 5 Oct 2011 09:38:10 -0700
Toshio Kuratomi a.bad...@gmail.com wrote:
 On Wed, Oct 05, 2011 at 06:14:08PM +0200, Antoine Pitrou wrote:
  Le mercredi 05 octobre 2011 à 18:12 +0200, Martin v. Löwis a écrit :
Not sure what you are using it for. If you need to extend the buffer
in case it is too small, there is absolutely no way this could work
without copies in the general case because of how computers use
address space. Even _PyBytes_Resize will copy the data.
   
That's not a given. Depending on the memory allocator, a copy can be
avoided. That's why the str += str hack is much more efficient under
Linux than Windows, AFAIK.
   
   Even Linux will have to copy a block on realloc in certain cases, no?
  
  Probably so. How often is totally unknown to me :)
  
 http://www.gnu.org/software/libc/manual/html_node/Changing-Block-Size.html
 
 It depends on whether there's enough free memory after the buffer you
 currently have allocated.  I suppose that this becomes a question of what
 people consider the general case :-)

But under certain circumstances (if a large block is requested), the
allocator uses mmap(), no? In which case mremap() should allow to
resize without copying anything.

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] [Python-checkins] cpython: Document requierements of Unicode kinds

2011-10-05 Thread Terry Reedy



On 10/5/2011 1:43 PM, victor.stinner wrote:

http://hg.python.org/cpython/rev/055174308822
changeset:   72699:055174308822
user:Victor Stinnervictor.stin...@haypocalc.com
date:Wed Oct 05 01:31:05 2011 +0200
summary:
   Document requierements of Unicode kinds

files:
   Include/unicodeobject.h |  24 
   1 files changed, 20 insertions(+), 4 deletions(-)


diff --git a/Include/unicodeobject.h b/Include/unicodeobject.h
--- a/Include/unicodeobject.h
+++ b/Include/unicodeobject.h
@@ -288,10 +288,26 @@
  unsigned int interned:2;
  /* Character size:

-   PyUnicode_WCHAR_KIND (0): wchar_t*
-   PyUnicode_1BYTE_KIND (1): Py_UCS1*
-   PyUnicode_2BYTE_KIND (2): Py_UCS2*
-   PyUnicode_4BYTE_KIND (3): Py_UCS4*
+   - PyUnicode_WCHAR_KIND (0):
+
+ * character type = wchar_t (16 or 32 bits, depending on the
+   platform)
+
+   - PyUnicode_1BYTE_KIND (1):
+
+ * character type = Py_UCS1 (8 bits, unsigned)
+ * if ascii is 1, at least one character must be in range
+   U+80-U+FF, otherwise all characters must be in range U+00-U+7F


Given that 1==True, this looks backwards.


+
+   - PyUnicode_2BYTE_KIND (2):
+
+ * character type = Py_UCS2 (16 bits, unsigned)
+ * at least one character must be in range U+0100-U+1


/U+1/U+/ ?

Terry
___
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] What it takes to change a single keyword.

2011-10-05 Thread Francisco Martin Brugue

Just Info on the links:

http://docs.python.org/devguide/compiler.html provides info on how it
all hangs together).


Those:

[1] http://docs.python.org/devguide/compiler.html#id3Skip Montanaro’s 
Peephole Optimizer Paper 
(http://www.foretec.com/python/workshops/1998-11/proceedings/papers/montanaro/montanaro.html)


[Wang97] http://docs.python.org/devguide/compiler.html#id2Daniel C. 
Wang, Andrew W. Appel, Jeff L. Korn, and Chris S. Serra. The Zephyr 
Abstract Syntax Description Language. 
http://www.cs.princeton.edu/%7Edanwang/Papers/dsl97/dsl97.html In 
Proceedings of the Conference on Domain-Specific Languages, pp. 213–227, 
1997.



are a 404

Cheers,

francis




___
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] What it takes to change a single keyword.

2011-10-05 Thread Brett Cannon
Please file a bug about the dead links so we can fix/remove them.

On Wed, Oct 5, 2011 at 13:29, Francisco Martin Brugue 
francisco.mar...@web.de wrote:

 Just Info on the links:

  
 http://docs.python.org/**devguide/compiler.htmlhttp://docs.python.org/devguide/compiler.htmlprovides
  info on how it
 all hangs together).


 Those:

 [1] 
 http://docs.python.org/**devguide/compiler.html#id3http://docs.python.org/devguide/compiler.html#id3
 **Skip Montanaro’s Peephole Optimizer Paper (http://www.foretec.com/**
 python/workshops/1998-11/**proceedings/papers/montanaro/**montanaro.htmlhttp://www.foretec.com/python/workshops/1998-11/proceedings/papers/montanaro/montanaro.html
 )

 [Wang97] 
 http://docs.python.org/**devguide/compiler.html#id2http://docs.python.org/devguide/compiler.html#id2
 **Daniel C. Wang, Andrew W. Appel, Jeff L. Korn, and Chris S. Serra. The
 Zephyr Abstract Syntax Description Language. 
 http://www.cs.princeton.edu/%**7Edanwang/Papers/dsl97/dsl97.**htmlhttp://www.cs.princeton.edu/%7Edanwang/Papers/dsl97/dsl97.html
 In Proceedings of the Conference on Domain-Specific Languages, pp. 213–227,
 1997.


 are a 404

 Cheers,

 francis





 __**_
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/**mailman/listinfo/python-devhttp://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
 brett%40python.orghttp://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] Heads up: Apple llvm gcc 4.2 miscompiles PEP 393

2011-10-05 Thread Guido van Rossum
Is anyone on this thread interested in other weird Mac bugs? I had a
user complaining that on their Mac, with Python 2.5.6 from macports,
2**63 was a negative number! That sounds like a compiler bug to me...

http://code.google.com/p/appengine-ndb-experiment/issues/detail?id=65
(details about the versions involved are in comment 6)

-- 
--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] Heads up: Apple llvm gcc 4.2 miscompiles PEP 393

2011-10-05 Thread Ned Deily
In article 
cap7+vjkxsnjwwxd1algom1krupbtcshiwawzko1gpqadnhw...@mail.gmail.com,
 Guido van Rossum gu...@python.org wrote:
 Is anyone on this thread interested in other weird Mac bugs? I had a
 user complaining that on their Mac, with Python 2.5.6 from macports,
 2**63 was a negative number! That sounds like a compiler bug to me...
 
 http://code.google.com/p/appengine-ndb-experiment/issues/detail?id=65
 (details about the versions involved are in comment 6)

Thanks for the pointer.  That looks like a duplicate of Issue11149 (and 
Issue12701).  Another manifestation of this was reported in Issue13061 
which also originated from MacPorts.  I'll remind them that the 
configure change is likely needed for all Pythons.  It's still safest to 
stick with good old gcc-4.2 on OS X at the moment.

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


Re: [Python-Dev] Heads up: Apple llvm gcc 4.2 miscompiles PEP 393

2011-10-05 Thread Guido van Rossum
Thanks! More proof that debugging crosses *all* abstractions...

On Wed, Oct 5, 2011 at 4:05 PM, Ned Deily n...@acm.org wrote:
 In article
 cap7+vjkxsnjwwxd1algom1krupbtcshiwawzko1gpqadnhw...@mail.gmail.com,
  Guido van Rossum gu...@python.org wrote:
 Is anyone on this thread interested in other weird Mac bugs? I had a
 user complaining that on their Mac, with Python 2.5.6 from macports,
 2**63 was a negative number! That sounds like a compiler bug to me...

 http://code.google.com/p/appengine-ndb-experiment/issues/detail?id=65
 (details about the versions involved are in comment 6)

 Thanks for the pointer.  That looks like a duplicate of Issue11149 (and
 Issue12701).  Another manifestation of this was reported in Issue13061
 which also originated from MacPorts.  I'll remind them that the
 configure change is likely needed for all Pythons.  It's still safest to
 stick with good old gcc-4.2 on OS X at the moment.

 --
  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/guido%40python.org




-- 
--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] [Python-checkins] cpython: Document requierements of Unicode kinds

2011-10-05 Thread Victor Stinner
Le mercredi 5 octobre 2011 21:25:22, Terry Reedy a écrit :
  +   - PyUnicode_1BYTE_KIND (1):
  +
  + * character type = Py_UCS1 (8 bits, unsigned)
  + * if ascii is 1, at least one character must be in range
  +   U+80-U+FF, otherwise all characters must be in range
  U+00-U+7F
 
 Given that 1==True, this looks backwards.

I changed the doc to:

PyUnicode_1BYTE_KIND (1):

 * character type = Py_UCS1 (8 bits, unsigned)
 * if ascii is set, all characters must be in range
   U+-U+007F, otherwise at least one character must be in range
   U+0080-U+00FF

Is it better?

  +   - PyUnicode_2BYTE_KIND (2):
  +
  + * character type = Py_UCS2 (16 bits, unsigned)
  + * at least one character must be in range U+0100-U+1
 
 /U+1/U+/ ?

Oops, correct. I fixed the doc, thanks for the review.

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] cpython (3.2): Issue #11956: Skip test_import.test_unwritable_directory on FreeBSD when run as

2011-10-05 Thread Cameron Simpson
On 04Oct2011 20:44, Charles-Fran�ois Natali cf.nat...@gmail.com wrote:
|  summary:
|Issue #11956: Skip test_import.test_unwritable_directory on FreeBSD when
| 
|run as
|  root (directory permissions are ignored).
| 
|  The same directory permission semantics apply to other (all?)
|  BSD-derived systems, not just FreeBSD.  For example, the test still
|  fails in the same way on OS X when run via sudo.
| 
| 
| Thanks, I didn't know: I only noticed this on the FreeBSD buildbots (I
| guess OS-X buildbots don't run as root). Note that it does behave as
| expected on Linux (note the use of quotation marks, I'm not sure
| whether this behavior is authorized by POSIX).
| I changed the test to skip when the effective UID is 0, regardless of
| the OS, to stay on the safe side.

I'd have expect this test to fail on _any_ UNIX system if run as root.
Root's allowed to write to stuff! Any stuff! About the only permission
with any effect on root is the eXecute bit for the exec call, to prevent
blindly running random data files.

Equally, why on earth are you running tests as root!?!?!?!?! Madness.
It's as bad as compiling stuff as root etc etc. A bad idea all around,
securitywise.

Especially, I would think, a builtbot. Oh, let's fetch some shiny new
code and run it as the system superuser.

I know this post sounds shouty, but I've just reread it a few times and
still cannot bring myself to tone it down.

Cheers,
-- 
Cameron Simpson c...@zip.com.au DoD#743
http://www.cskk.ezoshosting.com/cs/

If he's not one thing, he's another.- Buckaroo Banzai
___
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] cpython (3.2): Issue #11956: Skip test_import.test_unwritable_directory on FreeBSD when run as

2011-10-05 Thread Antoine Pitrou
On Thu, 6 Oct 2011 10:55:07 +1100
Cameron Simpson c...@zip.com.au wrote:
 
 Equally, why on earth are you running tests as root!?!?!?!?! Madness.
 It's as bad as compiling stuff as root etc etc. A bad idea all around,
 securitywise.
 
 Especially, I would think, a builtbot. Oh, let's fetch some shiny new
 code and run it as the system superuser.

Said buildbot probably runs in a VM.

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


[Python-Dev] New stringbench benchmark results

2011-10-05 Thread Victor Stinner
Hi,

I optimized unicodeobject.c a little bit more where I saw major performance 
regressions from Python 3.2 to 3.3 using stringbench. Here are new results: 
see attachments. Example of tests where Python 3.3 is much slower:

A.join([Bob]*100)): 2.11 = 0.92
(C+AB*300).rfind(CA): 0.57 = 1.03
(A + (Z*128*1024)).replace(A, BB, 1): 0.25 = 0.50

The rfind case is really strange: the code between Python 3.2 and 3.3 is 
exactly the same. Even in Python 3.2: rfind looks twice faster than find:

(AB*300+C).find(BC) (*1000) : 1.21
(C+AB*300).rfind(CA) (*1000) : 0.57

stringbench is ASCII only, I expect worse performance with non-ASCII 
characters. Python 3.3 is now faster for pure ASCII (faster than other kinds 
of Unicode string).

Hopefuly, Python 3.3 is faster in some stringbench tests, sometimes 2 times 
faster ;-)

Victor
stringbench v2.0
3.3.0a0 (default:341c3002ffb2, Oct  6 2011, 01:52:36) 
[GCC 4.6.0 20110603 (Red Hat 4.6.0-10)]
2011-10-06 01:53:06.975247
bytes   unicode
(in ms) (in ms) %   comment
== case conversion -- dense
0.401.5925.2(WHERE IN THE WORLD IS CARMEN SAN DEIGO?*10).lower() 
(*1000)
0.421.5527.3(where in the world is carmen san deigo?*10).upper() 
(*1000)
== case conversion -- rare
0.531.4935.8(Where in the world is Carmen San Deigo?*10).lower() 
(*1000)
0.441.5528.5(wHERE IN THE WORLD IS cARMEN sAN dEIGO?*10).upper() 
(*1000)
== concat 20 strings of words length 4 to 15
1.251.4486.8s1+s2+s3+s4+...+s20 (*1000)
== concat two strings
0.060.0792.5Andrew+Dalke (*1000)
== count AACT substrings in DNA example
1.271.3296.5dna.count(AACT) (*10)
== count newlines
0.530.51103.3   ...text.with.2000.newlines.count(\n) (*10)
== early match, single character
0.110.1289.2(A*1000).find(A) (*1000)
0.310.03887.7   A in A*1000 (*1000)
0.110.1290.7(A*1000).index(A) (*1000)
0.130.1494.4(A*1000).partition(A) (*1000)
0.120.1390.3(A*1000).rfind(A) (*1000)
0.120.1391.3(A*1000).rindex(A) (*1000)
0.120.1394.7(A*1000).rpartition(A) (*1000)
0.280.27102.0   (A*1000).rsplit(A, 1) (*1000)
0.290.28103.4   (A*1000).split(A, 1) (*1000)
== early match, two characters
0.110.1390.5(AB*1000).find(AB) (*1000)
0.310.04799.5   AB in AB*1000 (*1000)
0.110.1389.2(AB*1000).index(AB) (*1000)
0.150.1697.9(AB*1000).partition(AB) (*1000)
0.120.1490.0(AB*1000).rfind(AB) (*1000)
0.120.1392.8(AB*1000).rindex(AB) (*1000)
0.140.1593.3(AB*1000).rpartition(AB) (*1000)
0.310.30101.4   (AB*1000).rsplit(AB, 1) (*1000)
0.320.32101.0   (AB*1000).split(AB, 1) (*1000)
== endswith multiple characters
0.130.1396.1Andrew.endswith(Andrew) (*1000)
== endswith multiple characters - not!
0.130.12108.4   Andrew.endswith(Anders) (*1000)
== endswith single character
0.130.1394.9Andrew.endswith(w) (*1000)
== formatting a string type with a dict
N/A 0.520.0 The %(k1)s is %(k2)s the 
%(k3)s.%{k1:x,k2:y,k3:z,} (*1000)
== join empty string, with 1 character sep
N/A 0.040.0 A.join() (*100)
== join empty string, with 5 character sep
N/A 0.040.0 ABCDE.join() (*100)
== join list of 100 words, with 1 character sep
1.102.1152.3A.join([Bob]*100)) (*1000)
== join list of 100 words, with 5 character sep
1.162.2950.9ABCDE.join([Bob]*100)) (*1000)
== join list of 26 characters, with 1 character sep
0.310.6051.3A.join(list(ABC..Z)) (*1000)
== join list of 26 characters, with 5 character sep
0.340.6056.5ABCDE.join(list(ABC..Z)) (*1000)
== join string with 26 characters, with 1 character sep
N/A 1.230.0 A.join(ABC..Z) (*1000)
== join string with 26 characters, with 5 character sep
N/A 1.210.0 ABCDE.join(ABC..Z) (*1000)
== late match, 100 characters
8.888.52104.1   s=ABC*33; ((s+D)*500+s+E).find(s+E) (*100)
3.483.5398.5s=ABC*33; ((s+D)*500+E+s).find(E+s) (*100)
5.335.28100.9   s=ABC*33; (s+E) in ((s+D)*300+s+E) (*100)
8.888.60103.2   s=ABC*33; ((s+D)*500+s+E).index(s+E) (*100)
9.249.24100.0   s=ABC*33; ((s+D)*500+s+E).partition(s+E) (*100)
7.867.61103.4   s=ABC*33; (E+s+(D+s)*500).rfind(E+s) (*100)
1.761.9888.9s=ABC*33; (s+E+(D+s)*500).rfind(s+E) (*100)
7.677.53101.9   s=ABC*33; (E+s+(D+s)*500).rindex(E+s) (*100)
7.887.74101.9   s=ABC*33; (E+s+(D+s)*500).rpartition(E+s) (*100)
8.228.22100.0   s=ABC*33; (E+s+(D+s)*500).rsplit(E+s, 1) (*100)
9.129.09100.3   s=ABC*33; ((s+D)*500+s+E).split(s+E, 1) (*100)
== late match, two characters
1.191.16103.1   (AB*300+C).find(BC) (*1000)
1.181.18  

Re: [Python-Dev] [Python-checkins] cpython: Document requierements of Unicode kinds

2011-10-05 Thread Terry Reedy

On 10/5/2011 7:53 PM, Victor Stinner wrote:

Le mercredi 5 octobre 2011 21:25:22, Terry Reedy a écrit :

+   - PyUnicode_1BYTE_KIND (1):
+
+ * character type = Py_UCS1 (8 bits, unsigned)
+ * if ascii is 1, at least one character must be in range
+   U+80-U+FF, otherwise all characters must be in range
U+00-U+7F


Given that 1==True, this looks backwards.


I changed the doc to:

PyUnicode_1BYTE_KIND (1):

  * character type = Py_UCS1 (8 bits, unsigned)
  * if ascii is set, all characters must be in range
U+-U+007F, otherwise at least one character must be in range
U+0080-U+00FF

Is it better?


yes


+   - PyUnicode_2BYTE_KIND (2):
+
+ * character type = Py_UCS2 (16 bits, unsigned)
+ * at least one character must be in range U+0100-U+1


/U+1/U+/ ?


Oops, correct. I fixed the doc, thanks for the review.


Glad I could help with that, even though not the code details.

--
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] cpython (3.2): Issue #11956: Skip test_import.test_unwritable_directory on FreeBSD when run as

2011-10-05 Thread Terry Reedy

On 10/5/2011 8:07 PM, Antoine Pitrou wrote:

On Thu, 6 Oct 2011 10:55:07 +1100
Cameron Simpsonc...@zip.com.au  wrote:


Equally, why on earth are you running tests as root!?!?!?!?! Madness.
It's as bad as compiling stuff as root etc etc. A bad idea all around,
securitywise.

Especially, I would think, a builtbot. Oh, let's fetch some shiny new
code and run it as the system superuser.


Said buildbot probably runs in a VM.


A different perspective is that running buildbot tests as root does not 
reflect the experience of non-root users. It seems some tests need to be 
run both ways just for correctness testing.


--
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] cpython (3.2): Issue #11956: Skip test_import.test_unwritable_directory on FreeBSD when run as

2011-10-05 Thread Cameron Simpson
On 05Oct2011 21:33, Terry Reedy tjre...@udel.edu wrote:
| On 10/5/2011 8:07 PM, Antoine Pitrou wrote:
| On Thu, 6 Oct 2011 10:55:07 +1100 Cameron Simpsonc...@zip.com.au  wrote:
| Equally, why on earth are you running tests as root!?!?!?!?! Madness.
| It's as bad as compiling stuff as root etc etc. A bad idea all around,
| securitywise.
| 
| Especially, I would think, a builtbot. Oh, let's fetch some shiny new
| code and run it as the system superuser.
| 
| Said buildbot probably runs in a VM.

Which gets post validated from outside via some magic sanity test?
Which gets wiped and rerun from a clean image for the next build?

| A different perspective is that running buildbot tests as root does
| not reflect the experience of non-root users. It seems some tests
| need to be run both ways just for correctness testing.

Surely VERY FEW tests need to be run as root, and they need careful
consideration. The whole thing (build, full test suite) should
not run as root.

Am I really the only person who feels unease about this scenario?

Cheers,
-- 
Cameron Simpson c...@zip.com.au DoD#743
http://www.cskk.ezoshosting.com/cs/

Observing the first balloon ascent in Paris, [Ben] Franklin heard a scoffer
ask, What good is it?  He spoke for a generation of scientists in
his retort, What good is a newly born infant? - John F. Kasson
___
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] cpython (3.2): Issue #11956: Skip test_import.test_unwritable_directory on FreeBSD when run as

2011-10-05 Thread Stephen J. Turnbull
Cameron Simpson writes:

  Am I really the only person who feels unease about this scenario?

No, you are not alone.

Though in practice with all the Welcome, Cracker! boxes out there,
one more less-secure-than-it-could-be VM probably doesn't matter all
that much.  More important to Python is Terry's point that running as
root is not the normal scenario for most users, so the buildbot client
should be set up to run as root only for tests that are specifically
intended to test running as root (or as a separate run from the
normal unprivileged user test suite).
___
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