Re: [Python-Dev] accept the wheel PEPs 425, 426, 427
On Wed, Oct 24, 2012 at 7:04 AM, Ronald Oussoren wrote:
>
> On 18 Oct, 2012, at 19:29, Daniel Holth wrote:
>
>> I'd like to submit the Wheel PEPs 425 (filename metadata), 426
>> (Metadata 1.3), and 427 (wheel itself) for acceptance. The format has
>> been stable since May and we are preparing a patch to support it in
>> pip, but we need to earn consensus before including it in the most
>> widely used installer.
>
> PEP 425:
>
> * "The version is py_version_nodot. CPython gets away with no dot, but if one
> is needed the underscore _ is used instead"
>
>I don't particularly like replacing dots by underscores. That needed
> because you use the dot character in compressed tag sets, but why not use a
> comma to separate items in the compressed tag set?
>
> * "The platform tag is simply distutils.util.get_platform() with all hyphens
> - and periods . replaced with underscore _."
>
>Why the replacement? The need for replacement could be avoided by using a
> different separator between elements of a tag (for example "~" or "+"), and
> furthermore the platform tag is at a know
>location, and hence the use of hyphens in the platform tag is harmless
> (use "python_tag, abi_tag, platform_tag = tag.split('-', 2)" to split the tag
> into its elements.
>
> * "compressed tag sets"
>
>Using '"," instead of "." to separate elements of the tag set takes away
> the need to replace dots in tag elements, and seems more natural to me (you'd
> also use comma to separate the elements
>when you write them down in prose or python code.
I can't get excited about changing the convention. The
hyphen-to-underscore folding and - separated file parts is the same as
what setuptools uses. _ folding for . as well in the compat tags? It
may not be beautiful but it is very unlikely to cause ambiguity.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] accept the wheel PEPs 425, 426, 427
On 31 Oct, 2012, at 13:38, Daniel Holth wrote:
> On Wed, Oct 24, 2012 at 7:04 AM, Ronald Oussoren
> wrote:
>>
>> On 18 Oct, 2012, at 19:29, Daniel Holth wrote:
>>
>>> I'd like to submit the Wheel PEPs 425 (filename metadata), 426
>>> (Metadata 1.3), and 427 (wheel itself) for acceptance. The format has
>>> been stable since May and we are preparing a patch to support it in
>>> pip, but we need to earn consensus before including it in the most
>>> widely used installer.
>>
>> PEP 425:
>>
>> * "The version is py_version_nodot. CPython gets away with no dot, but if
>> one is needed the underscore _ is used instead"
>>
>> I don't particularly like replacing dots by underscores. That needed
>> because you use the dot character in compressed tag sets, but why not use a
>> comma to separate items in the compressed tag set?
>>
>> * "The platform tag is simply distutils.util.get_platform() with all hyphens
>> - and periods . replaced with underscore _."
>>
>> Why the replacement? The need for replacement could be avoided by using a
>> different separator between elements of a tag (for example "~" or "+"), and
>> furthermore the platform tag is at a know
>> location, and hence the use of hyphens in the platform tag is harmless
>> (use "python_tag, abi_tag, platform_tag = tag.split('-', 2)" to split the
>> tag into its elements.
>>
>> * "compressed tag sets"
>>
>> Using '"," instead of "." to separate elements of the tag set takes away
>> the need to replace dots in tag elements, and seems more natural to me
>> (you'd also use comma to separate the elements
>> when you write them down in prose or python code.
>
> I can't get excited about changing the convention. The
> hyphen-to-underscore folding and - separated file parts is the same as
> what setuptools uses. _ folding for . as well in the compat tags? It
> may not be beautiful but it is very unlikely to cause ambiguity.
Beauty is also important.
BTW. Setuptools does not fold '-' to underscore in the tag:
xs_image-1.0-py2.7-linux-x86_64.egg
This would be "xs_image-1.0-cp27-cp27-linux_x86_64.whl" in your scheme (a
binary package for CPython 2.7, platform is Linux x86_64). Replacing characters
is especially ugly on OSX, compare "xs_image-1.0-cp27-cp27-macosx_10_3_fat.whl"
and "xs_image-1.0-cp27-cp27-macosx-10.3-fat.whl".
As I've written before, it is not necessary to replace characters in the
platform tag because it is the last part of the filename anyway.
Ronald
___
Python-Dev mailing list
[email protected]
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: Issue #15478: Fix test_os on Windows (os.chown is missing)
On Tue, Oct 30, 2012 at 6:07 PM, victor.stinner wrote: > http://hg.python.org/cpython/rev/01cc9fb52887 > changeset: 80068:01cc9fb52887 > user:Victor Stinner > date:Wed Oct 31 01:04:10 2012 +0100 > summary: > Issue #15478: Fix test_os on Windows (os.chown is missing) > > files: > Lib/test/test_os.py | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > > diff --git a/Lib/test/test_os.py b/Lib/test/test_os.py > --- a/Lib/test/test_os.py > +++ b/Lib/test/test_os.py > @@ -2069,7 +2069,6 @@ > funcs = [ > (os.chdir,), > (os.chmod, 0o777), > -(os.chown, 0, 0), > (os.lchown, 0, 0), > (os.listdir,), > (os.lstat,), > @@ -2081,6 +2080,8 @@ > (os.truncate, 0), > (os.unlink,), > ] > +if hasattr(os, "chown"): > +funcs.append((os.chown, 0, 0)) > if sys.platform == "win32": > funcs.extend(( > (os._getfullpathname,), Also missing on Windows is os.lchown. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Segmentaion fault with wrongly set PYTHONPATH on Windows
On Tue, Oct 23, 2012 at 2:39 AM, Stephen J. Turnbull < [email protected]> wrote: > > So it shuts down abnormally. That's what an abort means, in > programming as in rocket launches. Users should be scared if this > happens; somebody really screwed up. (Unless it's themselves, and > then they only have themselves to blame.) > > > The error message could be > > improved though. Right now I get: > > > > E:\>python > > Fatal Python error: Py_Initialize: unable to load the file system codec > > ImportError: No module named 'encodings' > > > > This could be improved to: > > > > Fatal Python error: Py_Initialize: unable to find module named > 'encodings' > > in 'C:\' > > That may be an improvement. But in that case it might be worth > explaining where "C:\" came from (in this case PYTHONHOME, I guess?) > Good idea. Fatal Python error: Py_Initialize: unable to find module named 'encodings' in PYTHONHOME ('C:\') ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Sign of bytes
Hi, I wonder why Python uses signed chars for bytes http://docs.python.org/2/library/ctypes.html#ctypes.c_byte This is a Java thing, but Java doesn't have unsigned types at all http://en.wikipedia.org/wiki/Criticism_of_Java#Unsigned_integer_types Windows implements BYTE as unsigned char, and it is in the same line as WORD, DWORD etc. The way you look at memory contents in assembly. byte type is also unsigned in .NET platform for all languages implementes, and also has a sbyte counterpart. When working with bytes in decimal system it is much more convenient to operate with strictly positive values than with -128 - 127 (or is it -127 to 128?) -- anatoly t. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sign of bytes
The thing that made me wonder is here - http://bugs.python.org/issue16376 When I inspect contents of Windows structures, I get negative values that are not present in MSDN. -- anatoly t. On Wed, Oct 31, 2012 at 7:44 PM, anatoly techtonik wrote: > Hi, > > I wonder why Python uses signed chars for bytes > http://docs.python.org/2/library/ctypes.html#ctypes.c_byte > > This is a Java thing, but Java doesn't have unsigned types at all > http://en.wikipedia.org/wiki/Criticism_of_Java#Unsigned_integer_types > > Windows implements BYTE as unsigned char, and it is in the same line as > WORD, DWORD etc. The way you look at memory contents in assembly. > > byte type is also unsigned in .NET platform for all languages implementes, > and also has a sbyte counterpart. > > When working with bytes in decimal system it is much more convenient to > operate with strictly positive values than with -128 - 127 (or is it -127 > to 128?) > > > -- > anatoly t. > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sign of bytes
On 2012-10-31, at 18:44 , anatoly techtonik wrote: > I wonder why Python uses signed chars for bytes > http://docs.python.org/2/library/ctypes.html#ctypes.c_byte That's not Python, that's ctypes. struct[0] has no "bytes" it uses "char" for everything. If I had to guess, it would be because "char" is already an unsigned char in ctypes, "signed_char" is way too long, "schar" looks like dog vomit and there was no point in aliasing "byte" to "char. Which left "byte" free for "signed char". [0] http://docs.python.org/2/library/struct.html#format-characters ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Improve error message "UnboundLocalError: local variable referenced before assignment"
Here is the code: ---[cut]- DEBUG = [] FONT_NAMES = [] def names(): if len(DEBUG): print(len(DEBUG)) if len(FONT_NAMES): print(len(FONT_NAMES)) if len(FONT_NAMES)==0: FONT_NAMES = "query()" names() ---[cut]- Here is the output: Traceback (most recent call last): File "globalocal.py", line 13, in names() File "globalocal.py", line 8, in names if len(FONT_NAMES): UnboundLocalError: local variable 'FONT_NAMES' referenced before assignment As you may see there is inconsistency between handling of line 6 - "if len(DEBUG):" and line 8 - "if len(FONT_NAMES):". This is very magical and hard to troubleshoot. I wonder if this message can be improved with a pointer to the concept on when global variables become local? -- anatoly t. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improve error message "UnboundLocalError: local variable referenced before assignment"
On Wed, 31 Oct 2012 21:57:28 +0200, anatoly techtonik wrote: > Here is the code: > > ---[cut]- > > DEBUG = [] > FONT_NAMES = [] > > def names(): > if len(DEBUG): > print(len(DEBUG)) > if len(FONT_NAMES): > print(len(FONT_NAMES)) > if len(FONT_NAMES)==0: > FONT_NAMES = "query()" > > names() > ---[cut]- > > Here is the output: > > Traceback (most recent call last): > File "globalocal.py", line 13, in > names() > File "globalocal.py", line 8, in names > if len(FONT_NAMES): > UnboundLocalError: local variable 'FONT_NAMES' referenced before assignment > > > As you may see there is inconsistency between handling of line 6 - > "if len(DEBUG):" and line 8 - "if len(FONT_NAMES):". This is very magical > and hard to troubleshoot. I wonder if this message can be improved with a > pointer to the concept on when global variables become local? There is no inconsistency here. Only FONT_NAMES is assigned a value in the local scope. "local variable referenced before assignment" *is* a pointer to the concept of when global variables become local...perhaps there is a better wording, do you have a suggestion? --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sign of bytes
2012/10/31 anatoly techtonik : > I wonder why Python uses signed chars for bytes > http://docs.python.org/2/library/ctypes.html#ctypes.c_byte c_int is signed, c_uint is unsigned. similarly c_byte is signed, and c_ubyte is unsigned. > Windows implements BYTE as unsigned char, and it is in the same line as > WORD, DWORD etc. The way you look at memory contents in assembly. In this case you should use ctypes.wintypes.BYTE ... which is unfortunately defined as c_byte! This is the bug :-( -- Amaury Forgeot d'Arc ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improve error message "UnboundLocalError: local variable referenced before assignment"
This post would have been more appropriate on python-list than python-dev. But to answer your implied questions... On 10/31/2012 3:57 PM, anatoly techtonik wrote: Here is the code: ---[cut]- DEBUG = [] FONT_NAMES = [] This line has nothing to do with the behavior of the function that follows. The error message would be the name if it were deleted. def names(): if len(DEBUG): print(len(DEBUG)) if len(FONT_NAMES): print(len(FONT_NAMES)) if len(FONT_NAMES)==0: FONT_NAMES = "query()" This makes FONT_NAMES a local name *everywhere* within names. names() ---[cut]- Here is the output: Traceback (most recent call last): File "globalocal.py", line 13, in names() File "globalocal.py", line 8, in names if len(FONT_NAMES): UnboundLocalError: local variable 'FONT_NAMES' referenced before assignment As you may see there is inconsistency between handling of line 6 - "if len(DEBUG):" and line 8 - "if len(FONT_NAMES):". No there is not. This is very magical and hard to troubleshoot. Names (not 'variables') within a function are deterministically classified at compile time as local, nonlocal, or global according to declarations and usage *within the function*. This classification has nothing to do with names in other namespaces and is done independently of other namespaces. The rules are described in the manuals. I wonder if this message can be improved with a pointer to the concept on when global variables become local? This never happens. Global names stay global (until deleted). They may be masked by a local name with the same spelling (as in your example), but that is a different issue. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] 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: Issue #15478: Fix test_os on Windows (os.chown is missing)
Hi, 2012/10/31 Jeremy Kloth : > On Tue, Oct 30, 2012 at 6:07 PM, victor.stinner > wrote: >> http://hg.python.org/cpython/rev/01cc9fb52887 >> changeset: 80068:01cc9fb52887 >> user:Victor Stinner >> date:Wed Oct 31 01:04:10 2012 +0100 >> summary: >> Issue #15478: Fix test_os on Windows (os.chown is missing) >> >> (...) > > Also missing on Windows is os.lchown. Fixed, but there were also more errors introduced by #15478. test_os should now pass again on Windows. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improve error message "UnboundLocalError: local variable referenced before assignment"
On 01/11/12 06:57, anatoly techtonik wrote: [...] UnboundLocalError: local variable 'FONT_NAMES' referenced before assignment As you may see there is inconsistency between handling of line 6 - "if len(DEBUG):" and line 8 - "if len(FONT_NAMES):". This is very magical and hard to troubleshoot. I wouldn't call it an inconsistency, because the rules for deciding whether something is treated as local or global is consistently applied to all functions and variables. I would use the word "difference" instead -- there is a difference between line 6 and line 8 because there is a difference between DEBUG (global) and FONT_NAMES (local). As to whether this is "magical" behaviour, I suppose in some sense it is, but if so, it is more like a light sprinkling of pixie dust rather than full-blown dark voodoo magic. I wonder if this message can be improved with a pointer to the concept on when global variables become local? If you have a suggestion for an improved message, please tell us. Or raise an issue on the bug tracker. -- Steven ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improve error message "UnboundLocalError: local variable referenced before assignment"
On 10/31/2012 4:28 PM, R. David Murray wrote: "local variable referenced before assignment" *is* a pointer to the concept of when global variables become local...perhaps there is a better wording, do you have a suggestion? The current wording is an exact, concise, description of the problem. Rather than tinkering with the wording, I think a more general solution might be a new HOWTO: Understanding exception messages. It could have alphabetically sorted entries for exceptions and messages that people find problematic. UnboundLocalError local variable referenced before assignment Problem: You used a local name 'x' in an expression before you assigned it a value. So the interpreter could not compute the value of the expression. Remember that assignment makes a name local unless it is declared global or nonlocal. Remedy: If you intend 'x' to refer to a glocal or nonlocal name, add the necessary global or nonlocal declaration. If you intend -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improve error message "UnboundLocalError: local variable referenced before assignment"
On Thu, Nov 1, 2012 at 12:20 PM, Terry Reedy wrote: > The current wording is an exact, concise, description of the problem. Rather > than tinkering with the wording, I think a more general solution might be a > new HOWTO: Understanding exception messages. It could have alphabetically > sorted entries for exceptions and messages that people find problematic. > > UnboundLocalError > > local variable referenced before assignment > ... > Remedy: If you intend 'x' to refer to a glocal or nonlocal name, add the > necessary global or nonlocal declaration. If you intend +1. Can this be tied in with help(UnboundLocalError) perhaps? At the moment, that produces a huge screed of details that aren't particularly helpful to a novice (all its methods etc), and only a one-line explanation "Local name referenced but not bound to a value.". If that could be shortened and expanded on, it'd be a logical place to point people. "You got an error you don't understand? Go to the interactive interpreter and type help(NameOfError) - that should tell you what it is." ChrisA ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improve error message "UnboundLocalError: local variable referenced before assignment"
On 10/31/2012 9:20 PM, Terry Reedy wrote: On 10/31/2012 4:28 PM, R. David Murray wrote: "local variable referenced before assignment" *is* a pointer to the concept of when global variables become local...perhaps there is a better wording, do you have a suggestion? The current wording is an exact, concise, description of the problem. Rather than tinkering with the wording, I think a more general solution might be a new HOWTO: Understanding exception messages. It could have alphabetically sorted entries for exceptions and messages that people find problematic. UnboundLocalError local variable referenced before assignment Problem: You used a local name 'x' in an expression before you assigned it a value. So the interpreter could not compute the value of the expression. Remember that assignment makes a name local unless it is declared global or nonlocal. Remedy: If you intend 'x' to refer to a glocal or nonlocal name, add the necessary global or nonlocal declaration. If you intend 'x' to be local, rearrange your code to give it a value before you use it. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
