Re: Python Error message
GBANE FETIGUE writes: > ... > I am running a python script to run some CURL commands, and return the > response which is the applicationId and the versionId. I was able to do it. > Now the versionId value supposed to be used on the second CURL as a value of > the applications key which is an array. but it doesn't work.I 'll post the > error after running the command as well as the script. It seems like I have > an error somewhere because the curl works manually if i run. > > ec2-user@ip-172-31-21-77 playbooks]$ python mmc-uploader.py > ... > Final response...HTTP Status 415 - class=" > line">type Status reportmessage > description The server refused this request because > the request entity is in a format not supported by the reque > sted resource for the requested method.Apache > Tomcat/8.0.26 What you see here is *not* a Python error message but an error message from the server you have contacted. It tells you: "The server refused this request because the request entity is in a format not supported by the requested resource for the requested method." This means, that in constructing your request you made some error - regarding the "format" (which may mean the "Content-Type") for the request "entity" (which may mean the request body). I would check the service description to find out about what "format" is expected and what the term "entity" means. Then I would check the "curl" documentation to find out how to meet those expectations. -- https://mail.python.org/mailman/listinfo/python-list
Re: make an object read only
On 05/08/2016 01:03, Lawrence D’Oliveiro wrote: objects after the save method has been used. The user had mixed results :( As GvR has said: “we’re all consenting adults here”. In other words, we”re capable of coping with the consequences of our actions. agreed :) -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
Re: make an object read only
Op 05-08-16 om 02:03 schreef Lawrence D’Oliveiro: > On Wednesday, August 3, 2016 at 3:13:01 AM UTC+12, Robin Becker wrote: >> A reportlab user found he was doing the wrong thing by calling >> canvas.save repeatedly, our documentation says you should not use Canvas >> objects after the save method has been used. The user had mixed results :( > As GvR has said: “we’re all consenting adults here”. No we are not. GvR only uses this when his desired level of protection is lower than others. If the other's desired level of protection is lower than GvR's the all consenting adults goes down the drain. > In other words, we”re capable of coping with the consequences of our actions. Which doesn't support anything. Python has features that makes it in some situations easier to cope with those consequences than when that feature wouldn't be present. So there is nothing wrong in argueing for a feature that would do the same. -- Antoon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Win32 API in pywin32
On 05/08/2016 00:57, Lawrence D’Oliveiro wrote: On Friday, August 5, 2016 at 11:50:28 AM UTC+12, jj0ge...@gmail.com wrote: According to Python.org Mark Hammond has an Add-on (pywin32) that supports Win32 and COM. Are people still using Win32? I thought Windows went 64-bit years ago. Win32 refers to both 32-bit and 64-bit APIs. Apart from which, Win64 will still run 32-bit applications. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Win32 API in pywin32
On Fri, 5 Aug 2016, 02:23 Lawrence D’Oliveiro, wrote: > On Friday, August 5, 2016 at 12:06:23 PM UTC+12, Igor Korot wrote: > > > > On Thu, Aug 4, 2016 at 4:57 PM, Lawrence D’Oliveiro wrote: > >> On Friday, August 5, 2016 at 11:50:28 AM UTC+12, jj0ge...@gmail.com > wrote: > >>> According to Python.org Mark Hammond has an Add-on (pywin32) that > >>> supports Win32 and COM. > >> > >> Are people still using Win32? I thought Windows went 64-bit years ago. > The API is still called Win32 (fun fact: on 64 bit windows C:\Windows\System32 actually contains the 64 bit system (binaries & libraries). The 32 bit equivalents live in a dir called SysWOW64 (stands for Windows on Win64 or something) and get mapped to their regular locations for any 32 bit processes. That's right, 64 bit libraries live in System32 and 32 bits in SysWOW64 :) )* > This is the question about Win API calls > > > > Thank you. > > This is a Python group. > And the question was about using the Windows API in Python. Not sure what point you're trying to make here. > You’re welcome. > ... * anyone from Microsoft listening and want to offer an explanation (don't worry, I don't think anyone expects it to be good :D)? -- https://mail.python.org/mailman/listinfo/python-list
Pompem Exploit and Vulnerability Finder Tool v0.2.0 Python 3.5
Hello, I would like to share with you my personal project, Pompem. https://github.com/rfunix/Pompem/ I hope you enjoy it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Win32 API in pywin32
On Fri, Aug 5, 2016 at 11:58 AM, Matt Wheeler wrote: > On Fri, 5 Aug 2016, 02:23 Lawrence D’Oliveiro, > wrote: > >> On Friday, August 5, 2016 at 12:06:23 PM UTC+12, Igor Korot wrote: >> > >> > On Thu, Aug 4, 2016 at 4:57 PM, Lawrence D’Oliveiro wrote: >> >> On Friday, August 5, 2016 at 11:50:28 AM UTC+12, jj0ge...@gmail.com >> wrote: >> >>> According to Python.org Mark Hammond has an Add-on (pywin32) that >> >>> supports Win32 and COM. >> >> >> >> Are people still using Win32? I thought Windows went 64-bit years ago. >> > > The API is still called Win32 (fun fact: on 64 bit windows > C:\Windows\System32 actually contains the 64 bit system (binaries & > libraries). The 32 bit equivalents live in a dir called SysWOW64 (stands > for Windows on Win64 or something) and get mapped to their regular > locations for any 32 bit processes. That's right, 64 bit libraries live in > System32 and 32 bits in SysWOW64 :) )* Officially the name is the "Windows API" (or WinAPI; hence Python's _winapi module). It was "formerly called the Win32 API" [1]. That said, referring to it as Win32 is so pervasive in Microsoft's own documentation, among developers, and in the API itself that the old name isn't going anywhere. The system directory and many DLLs retain the "32" suffix in the 64-bit system in order to ease porting 32-bit programs that used hard-coded paths. I don't know all of the compatibility problems and constraints (and pressure from important customers) that they faced, so I won't pointlessly criticize this decision that was made over 15 years ago. As to the name WOW64 for the 32-bit subsystem, the Microsoft devs (or marketing department?) who named it apparently don't think like most people, as evidenced by the many complaints about the name. They should have realized that WOW64 suggests it's a 64-bit system, not "Windows [32-bit] on Windows 64-bit". [1]: https://msdn.microsoft.com/en-us/library/hh920508 -- https://mail.python.org/mailman/listinfo/python-list
Python slang
I have a simple curiosity: why Python has much keywords, and some builtin types and methods, that are different from the other languages? What is the rationale? I'm referring to: * `except` instead of `catch` * `raise` instead of `throw` * `self` instead of `this` (I know, it's not enforced, but it's a de facto standard and some IDEs like PyDev gives you an error if you declare a non-static method without `self` as first parameter) * `dict` instead of `map` * `list.append()` instead of `list.push()` * `str.strip()` instead of `str.trim()` * `True`, `False` and None instead of `true`, `false` and `none` (they seems classes) * and furthermore much abbreviation, like `str` instead of `string` and `len()` instead of `length()`, that seems to contrast with the readability goal of Python. I don't ask about `None` instead of `null` because I suppose here it's a matter of disambiguation (null, in many languages, is not equal to null). -- https://mail.python.org/mailman/listinfo/python-list
Re: Python slang
On Sat, Aug 6, 2016 at 8:00 AM, Marco Sulla via Python-list wrote: > I have a simple curiosity: why Python has much keywords, and some > builtin types and methods, that are different from the other > languages? What is the rationale? This isn't slang; it's jargon, perhaps, but "slang" implies an unofficial form of use. "Python slang" might include the myriad references to "spam" throughout the code and docs, and other Monty Pythonisms. But that aside, these are great questions to ask. As some people put it: "Why is it so?". > I'm referring to: > * `except` instead of `catch` Not sure. Python does seem to be roughly unique in this. > * `raise` instead of `throw` Quite a few other languages talk about raising exceptions rather than throwing them. Those would be the two most common terms, I think. > * `self` instead of `this` (I know, it's not enforced, but it's a de > facto standard and some IDEs like PyDev gives you an error if you > declare a non-static method without `self` as first parameter) Smalltalk and friends also use "self", so again, this would be the other common word for the parameter. > * `dict` instead of `map` "map" has many other meanings (most notably the action wherein you call a function on every member of a collection to produce another collection). > * `list.append()` instead of `list.push()` Better description of what it does, IMO. It's adding something to the end of the list - appending to the list. > * `str.strip()` instead of `str.trim()` Another case where both words are in common use. > * `True`, `False` and None instead of `true`, `false` and `none` (they > seems classes) This one, I've no idea about. Why have "bool" as the type, and "True" and "False" as the instances? I think the built-in types have their names grandfathered in from when they were factory functions, but that doesn't explain the capitalized instances. (And the type of None is NoneType, just to confuse the matter further.) > * and furthermore much abbreviation, like `str` instead of `string` > and `len()` instead of `length()`, that seems to contrast with the > readability goal of Python. Brevity can improve clarity, if it is obtained without the expense of accuracy. In the same vein, Python has one-character symbols instead of "add" and "divide". There's a balance to be struck; bitwise Or has a symbol, but short-circuiting boolean Or has a word. > I don't ask about `None` instead of `null` because I suppose here it's > a matter of disambiguation (null, in many languages, is not equal to > null). None isn't really like null, but it sometimes does the job that null does in other languages. It isn't a "non-object"; it's an object, same as any other, that happens to be a falsey singleton. Given that C's NULL pointer isn't the same as SQL's NULL nor ASCII's NUL, having a Python null that's different again wouldn't help. So yes, it's disambiguation; this is not the same thing as null. Hope that helps a bit! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python slang
On Sat, Aug 6, 2016 at 9:21 AM, Marco Sulla wrote: > I want to clarify that when I say "different from the other > languages", I mean "different from the most used languages", that in > my mind are C/C++, C#, Java, PHP and Javascript, mainly. > Ah, well, that's because those are all one family of languages. If instead you were familiar with four LISPy languages, you'd have a completely different set of expectations. > I agree it's not hard to understand that `str` is the string type and > `len()` is the function that gives you the length, even if you don't > know Python (and it's shorter to type...) But it's hard to remember, > in particular if you code also in other languages. When I come back to > Python, I always ends to write `somelist.length` instead of > `len(somelist)`, some arcane words come out my mouth and a little > fairy dies. > You open your mouth and a fairy dies hmm. Can I offer you a breath mint? :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python slang
On Sat, 6 Aug 2016 08:00 am, Marco Sulla wrote:
> I have a simple curiosity: why Python has much keywords, and some
> builtin types and methods, that are different from the other
> languages? What is the rationale?
You should ask those other languages. Which languages do you have in mind?
> I'm referring to:
> * `except` instead of `catch`
Because this isn't a game of "catch the ball". They're called "exceptions",
not "catchions". You *try* something, and if an *exception* happens, the
except block runs.
In English, without any abbreviations:
try doing this:
code block
except if a TypeError occurs, do this code:
exception handler
> * `raise` instead of `throw`
Because this isn't a game of catch.
> * `self` instead of `this` (I know, it's not enforced, but it's a de
> facto standard and some IDEs like PyDev gives you an error if you
> declare a non-static method without `self` as first parameter)
Because "this" is a stupid name.
In English, we refer to ourselves in the first person as I, me, myself, and
sometimes "self", never as "this". One can say "this one has a hat", for
example, but it sounds weird, like something the Borg would say about a
specific Borg unit.
> * `dict` instead of `map`
Because "map" is a piece of paper showing a visual representation of a
territory, and a dict (dictionary) is a set of words (the keys) followed by
their definitions (the values).
> * `list.append()` instead of `list.push()`
You don't push onto a list, you push onto a stack. You append to a list.
> * `str.strip()` instead of `str.trim()`
Because "trim" is a stupid name for stripping whitespace from the ends of a
string. When you trim hair or a plant, you unconditionally cut it and make
it shorter. If strings had a "trim" method, it should look like this:
def trim(self, distance):
return self[distance:-distance]
and similar for left-trim and right-trim.
> * `True`, `False` and None instead of `true`, `false` and `none` (they
> seems classes)
You'd have to ask other languages why they use 'true', 'false' and 'none'
(they seem like ordinary variables).
> * and furthermore much abbreviation, like `str` instead of `string`
> and `len()` instead of `length()`, that seems to contrast with the
> readability goal of Python.
Just because something is short doesn't make it less readable. According to
Wolfram Alpha, the average length of words in English is 5.1 characters:
http://www.wolframalpha.com/input/?i=average+english+word+length
but of the ten most common words themselves, nine are of three or fewer
characters:
"the of to and a in is it you that"
> I don't ask about `None` instead of `null` because I suppose here it's
> a matter of disambiguation (null, in many languages, is not equal to
> null).
Really? Which languages? That's not true in Pascal, C, Ruby or Javascript.
In Pascal, nil = nil:
[steve@ando pascal]$ cat nil_equal.p
program main(input, output);
var
a,b: ^integer;
begin
a := nil;
b := nil;
writeln(a = b);
end.
[steve@ando pascal]$ gpc nil_equal.p
[steve@ando pascal]$ ./a.out
True
In C, nul == nul:
[steve@ando c]$ cat null_equal.c
#include
int main()
{
int *a = NULL;
int *b = NULL;
printf("%d\n", a==b);
return 0;
}
[steve@ando c]$ gcc null_equal.c
[steve@ando c]$ ./a.out
1
In Ruby, nil == nil:
irb(main):001:0> a = nil
=> nil
irb(main):002:0> b = nil
=> nil
irb(main):003:0> a == b
=> true
In Javascript, null == null:
js> a = null
null
js> b = null
null
js> a == b
true
I'd like to know what are these "many" languages where null != null.
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python slang
On Sat, Aug 6, 2016 at 11:14 AM, Steven D'Aprano wrote: >> I don't ask about `None` instead of `null` because I suppose here it's >> a matter of disambiguation (null, in many languages, is not equal to >> null). > > Really? Which languages? That's not true in Pascal, C, Ruby or Javascript. > SQL (shown here with PostgreSQL's CLI): rosuav=> \pset null NULL Null display is "NULL". rosuav=> select NULL = NULL; ?column? -- NULL (1 row) But SQL's NULL is a cross between C's NULL, IEEE's NaN, Cthulhu, and Emrakul. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python slang
On Sat, 6 Aug 2016 08:31 am, Chris Angelico wrote: > On Sat, Aug 6, 2016 at 8:00 AM, Marco Sulla via Python-list > wrote: [...] >> I'm referring to: >> * `except` instead of `catch` > > Not sure. Python does seem to be roughly unique in this. Delphi does uses the same terminology. Standard Pascal is too old and doesn't support exceptions, but newer variants that do seem to use some form of "except". >> * `raise` instead of `throw` > > Quite a few other languages talk about raising exceptions rather than > throwing them. Those would be the two most common terms, I think. Indeed. >> * `self` instead of `this` (I know, it's not enforced, but it's a de >> facto standard and some IDEs like PyDev gives you an error if you >> declare a non-static method without `self` as first parameter) > > Smalltalk and friends also use "self", so again, this would be the > other common word for the parameter. Out of the 23 languages listed by Wikipedia here: https://en.wikipedia.org/wiki/Comparison_of_programming_languages_%28object-oriented_programming%29#Special_variables I see: 10 use "self" 10 use "this" 3 use "me" 1 uses "current" (that adds to 24 because Xojo can use either self or me). That's only a tiny sample of languages in the world. I expect that there will be significantly more variation if you expand the list, but that "self" and "this" will remain the two most popular choices. [...] >> * `True`, `False` and None instead of `true`, `false` and `none` (they >> seems classes) > > This one, I've no idea about. Why have "bool" as the type, and "True" > and "False" as the instances? I think the built-in types have their > names grandfathered in from when they were factory functions, but that > doesn't explain the capitalized instances. (And the type of None is > NoneType, just to confuse the matter further.) Read the PEP: https://www.python.org/dev/peps/pep-0285/ 3) Should the constants be called 'True' and 'False' (similar to None) or 'true' and 'false' (as in C++, Java and C99)? => True and False. Most reviewers agree that consistency within Python is more important than consistency with other languages. >> I don't ask about `None` instead of `null` because I suppose here it's >> a matter of disambiguation (null, in many languages, is not equal to >> null). On the same Wikipedia page as above, I count: 10 languages using "null" 7 using "nil" 1 each using "initial", "void", "none", "nothing", "nullptr", "undef", "undefined" -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Installing Python 2.7 for all users on SLES 11
On Thursday, August 4, 2016 at 8:54:35 PM UTC-7, Bo Stone wrote: > I installed Python 2.7 on SLES 11 box that previously was running Python 2.6. > To do so I used a script described in this post > (http://stackoverflow.com/a/11371726/135946) and run it as a root user. > Everything went well but when it was done I discovered few issues: > > 1. No symbolic links were created and no path updated so I had to manually > update the path to link to the new installation bin directory > /opt/python2.7/bin > 2. Everything runs good until I switch from root to the normal user at which > point Python shell runs but some modules I installed such as PyYAML are > missing. Again, these are OK when I run Python as root > 3. As a regular user I'm not able to run pip, easy_install and wheel. For pip > I get "ImportError: No module named pkg_resources" > > This question is also posted to Stackoverflow here: > http://stackoverflow.com/q/38749809/135946 The Stackoverflow question has now 100 points bounty -- https://mail.python.org/mailman/listinfo/python-list
Re: Python slang
On Sat, Aug 6, 2016 at 11:55 AM, Steven D'Aprano wrote: >>> * `True`, `False` and None instead of `true`, `false` and `none` (they >>> seems classes) >> >> This one, I've no idea about. Why have "bool" as the type, and "True" >> and "False" as the instances? I think the built-in types have their >> names grandfathered in from when they were factory functions, but that >> doesn't explain the capitalized instances. (And the type of None is >> NoneType, just to confuse the matter further.) > > Read the PEP: > > https://www.python.org/dev/peps/pep-0285/ > > 3) Should the constants be called 'True' and 'False' (similar to >None) or 'true' and 'false' (as in C++, Java and C99)? > > => True and False. > >Most reviewers agree that consistency within Python is more >important than consistency with other languages. > That answers the question about True and False, but not about None, which started the question. Why are instances capitalized here? Is it simply a matter of grandfathering in, with no specific decision? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python slang
On Fri, Aug 5, 2016, at 20:14, Dennis Lee Bieber wrote: > .push() tends to make this one think "stack" and not general purpose > list. It's a bit unusual to have .pop() without a matching .push(). -- https://mail.python.org/mailman/listinfo/python-list
Re: Python slang
On Sat, Aug 6, 2016 at 12:46 PM, Random832 wrote: > On Fri, Aug 5, 2016, at 20:14, Dennis Lee Bieber wrote: >> .push() tends to make this one think "stack" and not general purpose >> list. > > It's a bit unusual to have .pop() without a matching .push(). balloon.inflate() balloon.pop() ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python slang
On Saturday, August 6, 2016 at 8:16:36 AM UTC+5:30, Random832 wrote: > On Fri, Aug 5, 2016, at 20:14, Dennis Lee Bieber wrote: > > .push() tends to make this one think "stack" and not general purpose > > list. > > It's a bit unusual to have .pop() without a matching .push(). True… OTOH I tend to think of push (and pop) imperatively Whereas append (and maybe relatives starting cdr) are declarative [But that’s just me] -- https://mail.python.org/mailman/listinfo/python-list
Differences between \N escapes and unicodedata
Not all Unicode codepoints are supported by unicodedata.name(), but
they are supported in \N escapes and unicodedata.lookup. Is there a
reason for this?
Normally, you can do this:
>>> "\N{GREEK SMALL LETTER OMEGA}"
'ω'
>>> unicodedata.name(_)
'GREEK SMALL LETTER OMEGA'
But check this out:
>>> unicodedata.lookup("CHARACTER TABULATION")
'\t'
>>> "\N{CHARACTER TABULATION}"
'\t'
>>> unicodedata.name(_)
Traceback (most recent call last):
File "", line 1, in
ValueError: no such name
>>> unicodedata.lookup("NULL")
'\x00'
>>> "\N{NULL}"
'\x00'
>>> unicodedata.name(_)
Traceback (most recent call last):
File "", line 1, in
ValueError: no such name
Tested on 3.4, 3.5, and 3.6. Extremely odd.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python slang
On Sat, 6 Aug 2016 10:13 am, Chris Angelico wrote: > On Sat, Aug 6, 2016 at 9:21 AM, Marco Sulla > wrote: >> I want to clarify that when I say "different from the other >> languages", I mean "different from the most used languages", that in >> my mind are C/C++, C#, Java, PHP and Javascript, mainly. >> > > Ah, well, that's because those are all one family of languages. If > instead you were familiar with four LISPy languages, you'd have a > completely different set of expectations. Furthermore, that's only six languages out of, what, a couple of thousand known programming languages? And even languages clearly in the C family, like Objective-C, D, Swift, Java and Go, can end up using quite different syntax and execution models. It amuses me when people know a handful of languages, all clearly derived from each other, and think that's "most" languages. That's like somebody who knows Dutch, Afrikaans and German[1] being surprised that Russian, Cantonese, Hebrew and Vietnamese don't follow the same language rules as "most languages". >> I agree it's not hard to understand that `str` is the string type and >> `len()` is the function that gives you the length, even if you don't >> know Python (and it's shorter to type...) But it's hard to remember, >> in particular if you code also in other languages. When I come back to >> Python, I always ends to write `somelist.length` instead of >> `len(somelist)`, some arcane words come out my mouth and a little >> fairy dies. The obvious solution to that is that those other languages should replace their various list.length, collection.size, group.len, etc methods with a single function, like Python does. Why Python uses a len() function rather than a length/size/len/whatever method: http://effbot.org/pyfaq/why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list.htm [1] Low German, of course, not High German, the same branch of German which lead to Anglo-Saxon and hence to English. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python slang
On 8/5/2016 6:00 PM, Marco Sulla via Python-list wrote: I have a simple curiosity: why Python has much keywords, and some builtin types and methods, that are different from the other languages? What is the rationale? I'm referring to: * `except` instead of `catch` Python partly takes its cue from English. 'Try do this, except if it does not work, do that instead.' Catch? makes no sense in this respect. * `raise` instead of `throw` When you talk with people, do you raise an objection, or throw one? Admittedly, some people throw tantrums ;-)/ * `dict` instead of `map` A python dict is much more similar to a real world dictionary than a paper map. * `list.append()` instead of `list.push()` Lists are not just stacks. I got a bit of flack for proposing the addition of list.pop, long after list.append, to make them more usable as stacks. Append is definitely the command language word for adding something to the end of a sequence. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Python slang
On Sat, Aug 6, 2016 at 1:10 PM, Steven D'Aprano wrote: > It amuses me when people know a handful of languages, all clearly derived > from each other, and think that's "most" languages. That's like somebody > who knows Dutch, Afrikaans and German[1] being surprised that Russian, > Cantonese, Hebrew and Vietnamese don't follow the same language rules > as "most languages". Until you meet something different, though, you don't realize how similar they all are to each other. You're too busy noticing how different they are to see how similar they are. If all you know is English, you think that British English and American English are very different, and Australian English is nothing but slang. And then you meet one of the languages you list above, or even just another Western European language (all the same letters you know, but maybe one or two more, like ø or å, and possibly some diacriticals), and suddenly all English is one language, and even dialects of low Scots become sufficiently similar that you can read them. Once you know C, Python, LISP, Perl, and at least one assembly language, you can understand a lot of code. Correction. You can understand a lot of programming languages. I would call myself highly fluent in Python, but I still come across code that makes me go "WAT?"... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Differences between \N escapes and unicodedata
On Sat, Aug 6, 2016 at 3:13 AM, Chris Angelico wrote:
unicodedata.lookup("NULL")
> '\x00'
"\N{NULL}"
> '\x00'
unicodedata.name(_)
> Traceback (most recent call last):
> File "", line 1, in
> ValueError: no such name
>
> Tested on 3.4, 3.5, and 3.6. Extremely odd.
U+ has a legacy name and alias names in the standard, but no primary name:
http://www.unicode.org/Public/8.0.0/ucd/UnicodeData.txt
http://www.unicode.org/Public/8.0.0/ucd/NameAliases.txt
lookup() includes the aliases from the private use area where Python
maps them (U+F - U+F01CB), and of course maps it back to the
correct character code.
For the following I hacked unicodedata.name() to allow returning names
for the alias range. Notice that there are multiple aliases for a
given character, straight from the above-mentioned NameAliases
database.
>>> names = [unicodedata.name(chr(i)) for i in range(0xf, 0xf01cb)]
>>> print(*textwrap.wrap(', '.join(names[:80])), sep='\n')
NULL, NUL, START OF HEADING, SOH, START OF TEXT, STX, END OF TEXT,
ETX, END OF TRANSMISSION, EOT, ENQUIRY, ENQ, ACKNOWLEDGE, ACK, ALERT,
BEL, BACKSPACE, BS, CHARACTER TABULATION, HORIZONTAL TABULATION, HT,
TAB, LINE FEED, NEW LINE, END OF LINE, LF, NL, EOL, LINE TABULATION,
VERTICAL TABULATION, VT, FORM FEED, FF, CARRIAGE RETURN, CR, SHIFT
OUT, LOCKING-SHIFT ONE, SO, SHIFT IN, LOCKING-SHIFT ZERO, SI, DATA
LINK ESCAPE, DLE, DEVICE CONTROL ONE, DC1, DEVICE CONTROL TWO, DC2,
DEVICE CONTROL THREE, DC3, DEVICE CONTROL FOUR, DC4, NEGATIVE
ACKNOWLEDGE, NAK, SYNCHRONOUS IDLE, SYN, END OF TRANSMISSION BLOCK,
ETB, CANCEL, CAN, END OF MEDIUM, EOM, SUBSTITUTE, SUB, ESCAPE, ESC,
INFORMATION SEPARATOR FOUR, FILE SEPARATOR, FS, INFORMATION SEPARATOR
THREE, GROUP SEPARATOR, GS, INFORMATION SEPARATOR TWO, RECORD
SEPARATOR, RS, INFORMATION SEPARATOR ONE, UNIT SEPARATOR, US, SP,
DELETE, DEL
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python slang
On Fri, Aug 5, 2016 at 10:12 PM Chris Angelico wrote: > That answers the question about True and False, but not about None, > which started the question. Why are instances capitalized here? Is it > simply a matter of grandfathering in, with no specific decision? > When people ask me why the core classes are lowercased, I joke that it's following Hamming's thought that "true greatness" is when your name is spelled all lower case [0]. Great things are capitalized, like Counter, but truly great things are lowercased, like dict. BTW, this leads me to the thought that someone should edit Wikipedia to properly lowercase "hamming window". [0] "You and Your Research" (http://www.paulgraham.com/hamming.html) -- https://mail.python.org/mailman/listinfo/python-list
Re: Python slang
On Sat, Aug 6, 2016 at 2:10 AM, Chris Angelico wrote: > That answers the question about True and False, but not about None, > which started the question. Why are instances capitalized here? Is it > simply a matter of grandfathering in, with no specific decision? Using CamelCase for the single-instance (singleton) objects -- None, NotImplemented, and Ellipsis -- highlights their special nature, i.e. that we check for them by identity. "not_implemented" would look like just another local variable. I wish that NotImplemented had been made a keyword, just like None, True, and False. I see no value in being able to assign to this name. It invites confusion. For Ellipsis we at least have `...`. -- https://mail.python.org/mailman/listinfo/python-list
