[issue46714] Python 3.10 - Users (except from the one who installed) not able to see python in add remove programs.

[Steve Dower]

Steve Dower  added the comment:

Thanks. This is being tracked in issue25166, and is waiting on a fix from our 
installer toolset, who have previously indicated that they're not interested in 
fixing it, but wouldn't rule it out in their next major version.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Windows All Users installation places uninstaller in user 
profile

___
Python tracker 
<https://bugs.python.org/issue46714>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46714] Python 3.10 - Users (except from the one who installed) not able to see python in add remove programs.

[richd]

New submission from richd :

Experiencing the same issue as reported in https://bugs.python.org/issue31011

When Python is deployed using an enterprise solution, Python is not displayed 
in Programs and Features.

Examples:
1. Using PSExec as System to install Python 3.10.x, logged in users will not 
see Python installed. The Python launcher does appear however.

2. Deployment of Python through SCCM has the same behavior, where logged in 
users do not see the installed Python version in Programs and Features.

--
components: Windows
messages: 413022
nosy: paul.moore, richd, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python 3.10 - Users (except from the one who installed) not able to see 
python in add remove programs.
type: behavior
versions: Python 3.10

___
Python tracker 
<https://bugs.python.org/issue46714>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31011] Users (except from the one who installed) not able to see python in add remove programs.

[Irit Katriel]

Irit Katriel  added the comment:

3.6 is no longer maintained. Please create a new issue if you are seeing this 
problem on a current version (>= 3.9).

--
nosy: +iritkatriel
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Who wrote Py_UNREACHABLE?

[Barry Scott]

> On 2 Jan 2022, at 16:17, Marco Sulla  wrote:
> 
> #if defined(RANDALL_WAS_HERE)
> #  define Py_UNREACHABLE() \
>Py_FatalError( \
>"If you're seeing this, the code is in what I thought was\n" \
>"an unreachable state.\n\n" \
>"I could give you advice for what to do, but honestly, why\n" \
>"should you trust me?  I clearly screwed this up.  I'm writing\n" \
>"a message that should never appear, yet I know it will\n" \
>"probably appear someday.\n\n" \
>"On a deep level, I know I'm not up to this task.\n" \
>"I'm so sorry.\n" \
>"https://xkcd.com/2200;)
> #elif defined(Py_DEBUG)
> #  define Py_UNREACHABLE() \
>Py_FatalError( \
>"We've reached an unreachable state. Anything is possible.\n" \
>"The limits were in our heads all along. Follow your dreams.\n" \
>"https://xkcd.com/2200;)

use git blame to find out the commit then use git log to read the commit 
message.

Barry


> 
> etc
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who wrote Py_UNREACHABLE?

[Chris Angelico]

On Mon, Jan 3, 2022 at 3:19 AM Marco Sulla  wrote:
>
> #if defined(RANDALL_WAS_HERE)
> #  define Py_UNREACHABLE() \
> Py_FatalError( \
> "If you're seeing this, the code is in what I thought was\n" \
> "an unreachable state.\n\n" \
> "I could give you advice for what to do, but honestly, why\n" \
> "should you trust me?  I clearly screwed this up.  I'm writing\n" \
> "a message that should never appear, yet I know it will\n" \
> "probably appear someday.\n\n" \
> "On a deep level, I know I'm not up to this task.\n" \
> "I'm so sorry.\n" \
> "https://xkcd.com/2200;)
> #elif defined(Py_DEBUG)
> #  define Py_UNREACHABLE() \
> Py_FatalError( \
> "We've reached an unreachable state. Anything is possible.\n" \
> "The limits were in our heads all along. Follow your dreams.\n" \
> "https://xkcd.com/2200;)
>
> etc

Zachary Ware, 2019-09-12, commit #3ab614
https://github.com/python/cpython/pull/16032

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Who wrote Py_UNREACHABLE?

[Marco Sulla]

#if defined(RANDALL_WAS_HERE)
#  define Py_UNREACHABLE() \
Py_FatalError( \
"If you're seeing this, the code is in what I thought was\n" \
"an unreachable state.\n\n" \
"I could give you advice for what to do, but honestly, why\n" \
"should you trust me?  I clearly screwed this up.  I'm writing\n" \
"a message that should never appear, yet I know it will\n" \
"probably appear someday.\n\n" \
"On a deep level, I know I'm not up to this task.\n" \
"I'm so sorry.\n" \
"https://xkcd.com/2200;)
#elif defined(Py_DEBUG)
#  define Py_UNREACHABLE() \
Py_FatalError( \
"We've reached an unreachable state. Anything is possible.\n" \
"The limits were in our heads all along. Follow your dreams.\n" \
"https://xkcd.com/2200;)

etc
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue41105] Add some extra content check in configure process for some empty header file who has been deprecated by glibc

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Rather of using AC_COMPILE_IFELSE() in configure.ac, would not be easier to use 
#ifdef in the C file?

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41105] Add some extra content check in configure process for some empty header file who has been deprecated by glibc

[Christian Heimes]

Christian Heimes  added the comment:

The configure script is auto-generated from configure.ac. Any chance must be 
applied to configure.ac.

We could replace the AC_CHECK_HEADERS() for stropt.h with a more elaborate 
AC_COMPILE_IFELSE() block that checks for presence of I_PUSH.

Could you please report the issue to your Linux vendor, too? The empty file 
seems to break Open Group Unix 98 standard.

--
nosy: +christian.heimes

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41105] Add some extra content check in configure process for some empty header file who has been deprecated by glibc

[Andrei Kulakov]

Andrei Kulakov  added the comment:

I think adding this code in the `configure` script may fix it:

as_ac_Header=`$as_echo "ac_cv_header_stropts.h" | $as_tr_sh`
ac_fn_c_check_header_mongrel "$LINENO" "stropts.h" "$as_ac_Header" 
"$ac_includes_default"
if eval test \"x\$"$as_ac_Header"\" = x"yes" && [ -s stropts.h ]; then :
  cat >>confdefs.h <<_ACEOF
#define `$as_echo "HAVE_stropts.h" | $as_tr_cpp` 1
_ACEOF
fi

here: 
https://github.com/akulakov/cpython/blob/8f24b7dbcbd83311dad510863d8cb41f0e91b464/configure#L8144

.. but I wasn't able to test it. I have a MacOS system and for me even with a 
non-empty stropts.h, configure does not pick it up.

--
nosy: +andrei.avk

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31011] Users (except from the one who installed) not able to see python in add remove programs.

[Irit Katriel]

Change by Irit Katriel :


--
components: +Windows -Installation
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41105] Add some extra content check in configure process for some empty header file who has been deprecated by glibc

[Diego Alonso]

Diego Alonso  added the comment:

Yes, I have the same problem. The empty file is needed to avoid compilation 
errors in certain builds, but in this case it creates an error...

--
nosy: +etale-cohomology

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41105] Add some extra content check in configure process for some empty header file who has been deprecated by glibc

[Jiachen Yang]

Change by Jiachen Yang :


--
nosy: +Jiachen Yang

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41105] Add some extra content check in configure process for some empty header file who has been deprecated by glibc

[lilydjwg]

Change by lilydjwg :


--
nosy: +lilydjwg

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41105] Add some extra content check in configure process for some empty header file who has been deprecated by glibc

[Manjusaka]

Change by Manjusaka :


--
title: Add some extra content check  for some who has been deprecated by glibc 
-> Add some extra content check  in configure process for some empty header 
file who has been deprecated by glibc

___
Python tracker 
<https://bugs.python.org/issue41105>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41105] Add some extra content check for some who has been deprecated by glibc

[Manjusaka]

Manjusaka  added the comment:

Here's the reference

https://sourceware.org/legacy-ml/libc-alpha/2019-08/msg00029.html

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41105] Add some extra content check for some who has been deprecated by glibc

[Manjusaka]

New submission from Manjusaka :

Hello everyone

When I try to compile the code from the master branch on my Manjaro, one of the 
Linux system based on the Arch and based on the glibc-2.31 && gcc-10.1.0 . the 
compiler show me that the fcntl module has been failed to be compiled

Here's the message 

/home/manjusaka/Documents/project/cpython/Modules/fcntlmodule.c:618:33: error: 
‘I_PUSH’ undeclared (first use in this function)
  618 | if (PyModule_AddIntMacro(m, I_PUSH)) return -1;
  | ^~
./Include/modsupport.h:146:67: note: in definition of macro 
‘PyModule_AddIntMacro’
  146 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
  |   ^
/home/manjusaka/Documents/project/cpython/Modules/fcntlmodule.c:618:33: note: 
each undeclared identifier is reported only once for each function it appears in
  618 | if (PyModule_AddIntMacro(m, I_PUSH)) return -1;
  | ^~
./Include/modsupport.h:146:67: note: in definition of macro 
‘PyModule_AddIntMacro’
  146 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
  |   ^
/home/manjusaka/Documents/project/cpython/Modules/fcntlmodule.c:619:33: error: 
‘I_POP’ undeclared (first use in this function)
  619 | if (PyModule_AddIntMacro(m, I_POP)) return -1;
  | ^
./Include/modsupport.h:146:67: note: in definition of macro 
‘PyModule_AddIntMacro’
  146 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
  |   ^
/home/manjusaka/Documents/project/cpython/Modules/fcntlmodule.c:620:33: error: 
‘I_LOOK’ undeclared (first use in this function); did you mean ‘F_LOCK’?
  620 | if (PyModule_AddIntMacro(m, I_LOOK)) return -1;
  | ^~


I have figured out the reason because the stropts.h has been deprecated since 
the glic-2.30, but some of the distribution of Linux keep an empty file on the 
/usr/include, so the configure process will recognize stropts.h is existed and 
open HAVE_STROPTS_H flag.

So should we add an extra content check in the configure process to avoid the 
empty file problem?

--
components: Build
messages: 372254
nosy: Manjusaka
priority: normal
severity: normal
status: open
title: Add some extra content check  for some who has been deprecated by glibc
type: compile error
versions: Python 3.10, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue41105>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40132] Mechanism to control who owns package names on PyPI?

[Terry J. Reedy]

Terry J. Reedy  added the comment:

PyPI is a separate project from CPython and has its own repository, tracker, 
and developers.

--
nosy: +terry.reedy
resolution:  -> third party
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40132] Mechanism to control who owns package names on PyPI?

[ChrisRands]

ChrisRands  added the comment:

Thanks Rémi, I missed that in PEP 541. I am still concerned that PyPI may 
become saturated with unmaintained packages (it is already common that one's 
preferred package name is taken). However, the guidance is already clear, and I 
guess anything stronger, like revoking unmaintained/unused packages, would be 
difficult to police fairly

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40132] Mechanism to control who owns package names on PyPI?

[Rémi Lapeyre]

Rémi Lapeyre  added the comment:

Hi Chris, this is explicitly forbidden in the Terms of use of Pypi and the PEP 
451 at https://www.python.org/dev/peps/pep-0541/#invalid-projects:


> Invalid projects

> A project published on the Package Index meeting ANY of the following is 
> considered invalid and will be removed from the Index:

[...]

> project is malware (designed to exploit or harm systems or users);

[...]

> project is name squatting (package has no functionality or is empty);

--
nosy: +remi.lapeyre

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40132] Mechanism to control who owns package names on PyPI?

[ChrisRands]

New submission from ChrisRands :

Not sure if this is the right place to mention this (apologies if not). 
Naturally, package names are unique so when you run `pip install package-name` 
there is no ambiguity. However, this means that package names are limited and 
potentially valuable. Already there were some malicious users typo squatting 
famous package names (https://www.nbu.gov.sk/skcsirt-sa-20170909-pypi/), now 
fixed, but I'm more referring to the more general issue.

My guess is, if python continues to grow in popularity, it is only a matter of 
time before some unhelpful folks decide to reserve generic package names 
(common words etc.) and there is a market for selling PyPI package names (like 
the situation with domain names now). Personally, I'm not sure this would be 
good for the python community, but I don't know if there is (or could be) any 
solutions?

--
messages: 365454
nosy: ChrisRands
priority: normal
severity: normal
status: open
title: Mechanism to control who owns package names on PyPI?

___
Python tracker 
<https://bugs.python.org/issue40132>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: [Python-Dev] [WARNING] Some users who downloaded the Python 3.5.8 .xz tarball got the wrong version

[Michael]

On 31/10/2019 00:17, Larry Hastings wrote:
>
>
> Due to awkward CDN caching, some users who downloaded the source code
> tarballs of Python 3.5.8 got a preliminary version instead of the
> final version.  As best as we can tell, this only affects the .xz
> release; there are no known instances of users downloading an
> incorrect version of the .tgz file.
>
> If you downloaded "Python-3.5.8.tar.xz" during the first twelve hours
> of its release, you might be affected.  It's easy to determine this
> for yourself.  The file size (15,382,140 bytes) and MD5 checksum
> (4464517ed6044bca4fc78ea9ed086c36) published on the release page have
> always matched the correct version.  Also, the GPG signature file will
> only report a "Good signature" for the correct .xz file (using "gpg
> --verify").
>
> What's the difference between the two?  The only difference is that
> the final version also merges a fix for Python issue tracker #38243:
>
> https://bugs.python.org/issue38243
>
> The fix adds a call to "html.escape" at a judicious spot, line 896 in
> Lib/xmlrpc/server.py.  The only other changes are one new test, to
> ensure this new code is working, and an entry in the NEWS file.  You
> can see the complete list of changes here:
>
> https://github.com/python/cpython/pull/16516/files
>
> What should you do?  It's up to you.
>
>   * If you and your users aren't using the XMLRPC library built in to
> Python, you don't need to worry about which version of 3.5.8 you
> downloaded.
>   * If you downloaded the .tgz tarball or the Git repo, you already
> have the correct version.
>   * If you downloaded the xz file and want to make sure you have the
> fix, check the MD5 sum, and if it's wrong download a fresh copy
> (and make sure that one matches the known good MD5 sum!).
>
> To smooth over this whole sordid mess, I plan to make a 3.5.9 release
> in the next day or so.  It'll be identical to the 3.5.8 release; its
> only purpose is to ensure that all users have the same updated source
> code, including the fix for #38243.
>
>
> Sorry for the mess, everybody,
>
a) "Congratulations" on the 3.5.8 release

b) excellent solution - to up the release number!

c) Thanks!!

>
> //arry/
>
>
> ___
> Python-Dev mailing list -- python-...@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-...@python.org/message/OYNQS2BZYABXACBRHBHV4RCEPQU5R6EP/
> Code of Conduct: http://python.org/psf/codeofconduct/




signature.asc
Description: OpenPGP digital signature
--
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/

Support the Python Software Foundation:
http://www.python.org/psf/donations/

Re: [Python-Dev] [WARNING] Some users who downloaded the Python 3.5.8 .xz tarball got the wrong version

[Michael]

On 31/10/2019 00:17, Larry Hastings wrote:
>
>
> Due to awkward CDN caching, some users who downloaded the source code
> tarballs of Python 3.5.8 got a preliminary version instead of the
> final version.  As best as we can tell, this only affects the .xz
> release; there are no known instances of users downloading an
> incorrect version of the .tgz file.
>
> If you downloaded "Python-3.5.8.tar.xz" during the first twelve hours
> of its release, you might be affected.  It's easy to determine this
> for yourself.  The file size (15,382,140 bytes) and MD5 checksum
> (4464517ed6044bca4fc78ea9ed086c36) published on the release page have
> always matched the correct version.  Also, the GPG signature file will
> only report a "Good signature" for the correct .xz file (using "gpg
> --verify").
>
> What's the difference between the two?  The only difference is that
> the final version also merges a fix for Python issue tracker #38243:
>
> https://bugs.python.org/issue38243
>
> The fix adds a call to "html.escape" at a judicious spot, line 896 in
> Lib/xmlrpc/server.py.  The only other changes are one new test, to
> ensure this new code is working, and an entry in the NEWS file.  You
> can see the complete list of changes here:
>
> https://github.com/python/cpython/pull/16516/files
>
> What should you do?  It's up to you.
>
>   * If you and your users aren't using the XMLRPC library built in to
> Python, you don't need to worry about which version of 3.5.8 you
> downloaded.
>   * If you downloaded the .tgz tarball or the Git repo, you already
> have the correct version.
>   * If you downloaded the xz file and want to make sure you have the
> fix, check the MD5 sum, and if it's wrong download a fresh copy
> (and make sure that one matches the known good MD5 sum!).
>
> To smooth over this whole sordid mess, I plan to make a 3.5.9 release
> in the next day or so.  It'll be identical to the 3.5.8 release; its
> only purpose is to ensure that all users have the same updated source
> code, including the fix for #38243.
>
>
> Sorry for the mess, everybody,
>
a) "Congratulations" on the 3.5.8 release

b) excellent solution - to up the release number!

c) Thanks!!

>
> //arry/
>
>
> ___
> Python-Dev mailing list -- python-...@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-...@python.org/message/OYNQS2BZYABXACBRHBHV4RCEPQU5R6EP/
> Code of Conduct: http://python.org/psf/codeofconduct/




signature.asc
Description: OpenPGP digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

[WARNING] Some users who downloaded the Python 3.5.8 .xz tarball got the wrong version

[Larry Hastings]

Due to awkward CDN caching, some users who downloaded the source code 
tarballs of Python 3.5.8 got a preliminary version instead of the final 
version.  As best as we can tell, this only affects the .xz release; 
there are no known instances of users downloading an incorrect version 
of the .tgz file.


If you downloaded "Python-3.5.8.tar.xz" during the first twelve hours of 
its release, you might be affected.  It's easy to determine this for 
yourself.  The file size (15,382,140 bytes) and MD5 checksum 
(4464517ed6044bca4fc78ea9ed086c36) published on the release page have 
always matched the correct version.  Also, the GPG signature file will 
only report a "Good signature" for the correct .xz file (using "gpg 
--verify").


What's the difference between the two?  The only difference is that the 
final version also merges a fix for Python issue tracker #38243:


   https://bugs.python.org/issue38243

The fix adds a call to "html.escape" at a judicious spot, line 896 in 
Lib/xmlrpc/server.py.  The only other changes are one new test, to 
ensure this new code is working, and an entry in the NEWS file.  You can 
see the complete list of changes here:


   https://github.com/python/cpython/pull/16516/files

What should you do?  It's up to you.

 * If you and your users aren't using the XMLRPC library built in to
   Python, you don't need to worry about which version of 3.5.8 you
   downloaded.
 * If you downloaded the .tgz tarball or the Git repo, you already have
   the correct version.
 * If you downloaded the xz file and want to make sure you have the
   fix, check the MD5 sum, and if it's wrong download a fresh copy (and
   make sure that one matches the known good MD5 sum!).

To smooth over this whole sordid mess, I plan to make a 3.5.9 release in 
the next day or so.  It'll be identical to the 3.5.8 release; its only 
purpose is to ensure that all users have the same updated source code, 
including the fix for #38243.



Sorry for the mess, everybody,


//arry/

--
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/

   Support the Python Software Foundation:
   http://www.python.org/psf/donations/

[WARNING] Some users who downloaded the Python 3.5.8 .xz tarball got the wrong version

[Larry Hastings]

Due to awkward CDN caching, some users who downloaded the source code 
tarballs of Python 3.5.8 got a preliminary version instead of the final 
version.  As best as we can tell, this only affects the .xz release; 
there are no known instances of users downloading an incorrect version 
of the .tgz file.


If you downloaded "Python-3.5.8.tar.xz" during the first twelve hours of 
its release, you might be affected.  It's easy to determine this for 
yourself.  The file size (15,382,140 bytes) and MD5 checksum 
(4464517ed6044bca4fc78ea9ed086c36) published on the release page have 
always matched the correct version.  Also, the GPG signature file will 
only report a "Good signature" for the correct .xz file (using "gpg 
--verify").


What's the difference between the two?  The only difference is that the 
final version also merges a fix for Python issue tracker #38243:


   https://bugs.python.org/issue38243

The fix adds a call to "html.escape" at a judicious spot, line 896 in 
Lib/xmlrpc/server.py.  The only other changes are one new test, to 
ensure this new code is working, and an entry in the NEWS file.  You can 
see the complete list of changes here:


   https://github.com/python/cpython/pull/16516/files

What should you do?  It's up to you.

 * If you and your users aren't using the XMLRPC library built in to
   Python, you don't need to worry about which version of 3.5.8 you
   downloaded.
 * If you downloaded the .tgz tarball or the Git repo, you already have
   the correct version.
 * If you downloaded the xz file and want to make sure you have the
   fix, check the MD5 sum, and if it's wrong download a fresh copy (and
   make sure that one matches the known good MD5 sum!).

To smooth over this whole sordid mess, I plan to make a 3.5.9 release in 
the next day or so.  It'll be identical to the 3.5.8 release; its only 
purpose is to ensure that all users have the same updated source code, 
including the fix for #38243.



Sorry for the mess, everybody,


//arry/

--
https://mail.python.org/mailman/listinfo/python-list

[issue33320] Clarify who can add the "skip issue" label on GitHub

[Andrés Delfino]

Change by Andrés Delfino :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33320] Clarify who can add the "skip issue" label on GitHub

[Andrés Delfino]

Andrés Delfino  added the comment:

This is the PR: https://github.com/python/devguide/pull/359

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33320] Clarify who can add the "skip issue" label on GitHub

[Andrés Delfino]

Change by Andrés Delfino :


--
pull_requests:  -6242

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33320] Clarify who can add the "skip issue" label on GitHub

[Andrés Delfino]

Change by Andrés Delfino :


--
keywords: +patch
pull_requests: +6242
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33320] Clarify who can add the "skip issue" label on GitHub

[Andrés Delfino]

New submission from Andrés Delfino <adelf...@gmail.com>:

IMHO, the wording of https://devguide.python.org/pullrequest/ is somewhat 
confusing regarding the "skip issue" label.

I thought that I (with no commit access) should add the label, but, as far I 
understand, that is a responsibility of developers with commit access.

The PR offers a wording to clarify this.

--
assignee: docs@python
components: Documentation
messages: 315512
nosy: adelfino, docs@python
priority: normal
severity: normal
status: open
title: Clarify who can add the "skip issue" label on GitHub
type: enhancement

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33320>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Increasing the diversity of people who write Python

[Marko Rauhamaa]

Christian Gollwitzer :
> Am 28.11.17 um 20:24 schrieb wxjmfa...@gmail.com:
>> 00FF LETTRE MINUSCULE LATINE Y TRÉMA
>
> WTF is this? The character is correctly called
> "LATIN SMALL LETTER Y WITH DIAERESIS". There is no non-ASCII character
> in this description. Of course, if I translated the Unicode mapping to
> Polish, there would be an even larger number of non-ASCII letters -
> but what good would that be for an IT standard, if the identifiers
> were written in different languages?

The ISO/IEC standards are issued in many languages. French and English
have the strongest footing; French is maybe slightly more primary than
English.

http://www.iec.ch/tcnews/restricted/2009june/Directives-IECSup-Ed5-1.pdf>


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python

[Christian Gollwitzer]

Am 28.11.17 um 20:24 schrieb wxjmfa...@gmail.com:

Le mardi 28 novembre 2017 04:44:51 UTC+1, Rustom Mody a écrit :

...

Unicode codepoint names are (evidently) ALLCAPS-ASCII



Are you sure ? ;-)


; Standard Unicode 10.0.0 ou
;   Norme internationale ISO/CEI 10646:2017

...

00FFLETTRE MINUSCULE LATINE Y TRÉMA


WTF is this? The character is correctly called
"LATIN SMALL LETTER Y WITH DIAERESIS". There is no non-ASCII character 
in this description. Of course, if I translated the Unicode mapping to 
Polish, there would be an even larger number of non-ASCII letters - but 
what good would that be for an IT standard, if the identifiers were 
written in different languages?


Christian
--
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python

[Chris Angelico]

On Wed, Nov 29, 2017 at 3:44 PM, Gregory Ewing
 wrote:
> Chris Angelico wrote:
>>
>> Heh, you mean the term "Windows key"? It's not appropriate on
>> keyboards that don't have an actual Windows logo on it. There are
>> other names for it, but I figured the easiest way was to describe its
>> location :D
>
>
> That doesn't work for all keyboards, though. The one I'm using
> right now doesn't have any key between the left alt and left
> control keys. (It does have another key just to the right of
> the alt key that might have roughly analogous functionality in
> some circumstances.)
>

Yeah, which is why it's completely configurable. I was just saying
which key *I* use, on my particular layout.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python

[Gregory Ewing]

Chris Angelico wrote:

Heh, you mean the term "Windows key"? It's not appropriate on
keyboards that don't have an actual Windows logo on it. There are
other names for it, but I figured the easiest way was to describe its
location :D


That doesn't work for all keyboards, though. The one I'm using
right now doesn't have any key between the left alt and left
control keys. (It does have another key just to the right of
the alt key that might have roughly analogous functionality in
some circumstances.)

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)

[Thomas Jollans]

On 2017-11-24 17:41, Skip Montanaro wrote:
> Perhaps for my next computer I should choose a
> non-ASCII keyboard option when configuring it.
> 
> Skip
> 

I'm quite fond of the US international keyboard layout. It lets you type
most Latin-lettered languages with relative ease (including, obviously,
the few accented letters used in English). It's conveniently available
(and almost identical) on all (major) operating systems, but alas
Windows only has a dead-keys variant built in. (But I believe you can
download a no-dead-keys variant somewhere)

It's nice because (with a no-dead-keys version) unless you press AltGr,
everything's the same as with a traditional US keyboard (which is not
entirely suitable for the English language on its own).

On Windows machines I only use occasionally (and may not have admin
rights on) I tend to set up both "US" and "US international" keyboard
layouts and switch between them depending on what I'm typing. It's not
ideal, but it's better than either programming being a pain in the arse
(with all the dead keys) or not being able to type natural-language
words properly.

-- 
Thomas Jollans
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python

[Tim Golden]

On 28/11/2017 08:41, Paul Moore wrote:

On 27 November 2017 at 19:05, Paul Moore  wrote:

On 27 November 2017 at 18:13, Skip Montanaro  wrote:

If you have a Windows key, you can assign it to be
the Compose key.


Would this be true on a machine running Windows? My work environment
has me developing on Linux, with a Windows desktop. It's not clear to
me that any sort of xmodmap shennanigans would work. Won't Windows
itself always gobble up that key?


Programs can access the Windows key. IIRC, there is a utility that
provides compose-key functionality on Windows. I can't recall the name
right now and it's on my other PC, not this one, but I'll try to
remember to post the name tomorrow...


WinCompose was the program - https://github.com/samhocevar/wincompose


And, if you wanted a Python-y solution:

http://timgolden.me.uk/python/win32_how_do_i/catch_system_wide_hotkeys.html

TJG
--
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)

[Paul Moore]

On 27 November 2017 at 19:05, Paul Moore  wrote:
> On 27 November 2017 at 18:13, Skip Montanaro  wrote:
>>> If you have a Windows key, you can assign it to be
>>> the Compose key.
>>
>> Would this be true on a machine running Windows? My work environment
>> has me developing on Linux, with a Windows desktop. It's not clear to
>> me that any sort of xmodmap shennanigans would work. Won't Windows
>> itself always gobble up that key?
>
> Programs can access the Windows key. IIRC, there is a utility that
> provides compose-key functionality on Windows. I can't recall the name
> right now and it's on my other PC, not this one, but I'll try to
> remember to post the name tomorrow...

WinCompose was the program - https://github.com/samhocevar/wincompose

Paul
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)

[Rustom Mody]

On Monday, November 27, 2017 at 10:49:35 PM UTC+5:30, Skip Montanaro wrote:
> > I strongly suspect that any recent emacs will have M-x insert-char
> > (earlier it was called ucs-insert) default bound C-x 8 RET (yeah thats 
> > clunky)
> > which will accept at the minibuffer input
> 
> I tried C-x 8 e acute TAB
> 
> and was prompted with "E-acute". I don't know why it would have
> capitalized the "e". 

Unicode codepoint names are (evidently) ALLCAPS-ASCII

Still, I plowed ahead and hit RET
> 
> which yielded an "Invalid character" message in the minibuffer.

Unicode is a million+ codepoints
Hundred thousand+ of which are assigned
This means that (as an analogy) emacs is fishing around in a 100,000 line file
which contains lines like
LATIN SMALL LETTER A:a:0x61
LATIN CAPITAL LETTER A:A:0x41
DIGIT ONE:1:0x31
... 100,000 such lines… one of which is
LATIN SMALL LETTER E WITH ACUTE:é:0xe9

[Just now fishing around I find its worse than that C-u C-x = tells me:

  character: é (displayed as é) (codepoint 233, #o351, #xe9)
  name: LATIN SMALL LETTER E WITH ACUTE
  old-name: LATIN SMALL LETTER E ACUTE
  general-category: Ll (Letter, Lowercase)

So those hundred thousand chars can have multiple names!!
And that constitutes the search space
]

So now coming to your attempt:

[ Writing this mail, Ive finally done:
(global-set-key (kbd "") 'insert-char)
which allows me to use F9 instead of the clunky C-x 8 RET
I'll assume that binding following
]

If I type
F9*e acuteTAB
I get 121 possibilities:

CANADIAN SYLLABICS FINAL DOUBLE ACUTE (ᐥ)
COMBINING DOTTED ACUTE ACCENT (᷁)
COMBINING DOUBLE ACUTE ACCENT (̋)
CYRILLIC CAPITAL LETTER U WITH DOUBLE ACUTE (Ӳ)
CYRILLIC SMALL LETTER U WITH DOUBLE ACUTE (ӳ)
DEVANAGARI ACUTE ACCENT (॔) DOUBLE ACUTE ACCENT (˝)
GREEK UPSILON WITH ACUTE AND HOOK SYMBOL (ϓ)
LATIN CAPITAL LETTER A ACUTE (Á)
LATIN CAPITAL LETTER A WITH ACUTE (Á)
LATIN CAPITAL LETTER A WITH BREVE AND ACUTE (Ắ)
LATIN CAPITAL LETTER A WITH CIRCUMFLEX AND ACUTE (Ấ)
LATIN CAPITAL LETTER A WITH RING ABOVE AND ACUTE (Ǻ)
LATIN CAPITAL LETTER AE WITH ACUTE (Ǽ)
LATIN CAPITAL LETTER C ACUTE (Ć)
LATIN CAPITAL LETTER C WITH ACUTE (Ć)
LATIN CAPITAL LETTER C WITH CEDILLA AND ACUTE (Ḉ)
LATIN CAPITAL LETTER E ACUTE (É)
LATIN CAPITAL LETTER E WITH ACUTE (É)
LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND ACUTE (Ế)
LATIN CAPITAL LETTER E WITH MACRON AND ACUTE (Ḗ)
LATIN CAPITAL LETTER G WITH ACUTE (Ǵ)
LATIN CAPITAL LETTER I ACUTE (Í)
LATIN CAPITAL LETTER I WITH ACUTE (Í)
LATIN CAPITAL LETTER I WITH DIAERESIS AND ACUTE (Ḯ)
LATIN CAPITAL LETTER K WITH ACUTE (Ḱ)
LATIN CAPITAL LETTER L ACUTE (Ĺ)
LATIN CAPITAL LETTER L WITH ACUTE (Ĺ)
LATIN CAPITAL LETTER M WITH ACUTE (Ḿ)
LATIN CAPITAL LETTER N ACUTE (Ń)
LATIN CAPITAL LETTER N WITH ACUTE (Ń)
LATIN CAPITAL LETTER O ACUTE (Ó)
LATIN CAPITAL LETTER O DOUBLE ACUTE (Ő)
LATIN CAPITAL LETTER O WITH ACUTE (Ó)
LATIN CAPITAL LETTER O WITH CIRCUMFLEX AND ACUTE (Ố)
LATIN CAPITAL LETTER O WITH DOUBLE ACUTE (Ő)
LATIN CAPITAL LETTER O WITH HORN AND ACUTE (Ớ)
LATIN CAPITAL LETTER O WITH MACRON AND ACUTE (Ṓ)
LATIN CAPITAL LETTER O WITH STROKE AND ACUTE (Ǿ)
LATIN CAPITAL LETTER O WITH TILDE AND ACUTE (Ṍ)
LATIN CAPITAL LETTER P WITH ACUTE (Ṕ)
LATIN CAPITAL LETTER R ACUTE (Ŕ)
LATIN CAPITAL LETTER R WITH ACUTE (Ŕ)
LATIN CAPITAL LETTER S ACUTE (Ś)
LATIN CAPITAL LETTER S WITH ACUTE (Ś)
LATIN CAPITAL LETTER S WITH ACUTE AND DOT ABOVE (Ṥ)
LATIN CAPITAL LETTER U ACUTE (Ú)
LATIN CAPITAL LETTER U DIAERESIS ACUTE (Ǘ)
LATIN CAPITAL LETTER U DOUBLE ACUTE (Ű)
LATIN CAPITAL LETTER U WITH ACUTE (Ú)
LATIN CAPITAL LETTER U WITH DIAERESIS AND ACUTE (Ǘ)
LATIN CAPITAL LETTER U WITH DOUBLE ACUTE (Ű)
LATIN CAPITAL LETTER U WITH HORN AND ACUTE (Ứ)
LATIN CAPITAL LETTER U WITH TILDE AND ACUTE (Ṹ)
LATIN CAPITAL LETTER W WITH ACUTE (Ẃ)
LATIN CAPITAL LETTER Y ACUTE (Ý)
LATIN CAPITAL LETTER Y WITH ACUTE (Ý)
LATIN CAPITAL LETTER Z ACUTE (Ź)
LATIN CAPITAL LETTER Z WITH ACUTE (Ź)
LATIN SMALL LETTER A ACUTE (á)
LATIN SMALL LETTER A WITH ACUTE (á)
LATIN SMALL LETTER A WITH BREVE AND ACUTE (ắ)
LATIN SMALL LETTER A WITH CIRCUMFLEX AND ACUTE (ấ)
LATIN SMALL LETTER A WITH RING ABOVE AND ACUTE (ǻ)
LATIN SMALL LETTER AE WITH ACUTE (ǽ)
LATIN SMALL LETTER C ACUTE (ć)
LATIN SMALL LETTER C WITH ACUTE (ć)
LATIN SMALL LETTER C WITH CEDILLA AND ACUTE (ḉ)
LATIN SMALL LETTER E ACUTE (é)
LATIN SMALL LETTER E WITH ACUTE (é)
LATIN SMALL LETTER E WITH CIRCUMFLEX AND ACUTE (ế)
LATIN SMALL LETTER E WITH MACRON AND ACUTE (ḗ)
LATIN SMALL LETTER G WITH ACUTE (ǵ)
LATIN SMALL LETTER I ACUTE (í)
LATIN SMALL LETTER I WITH ACUTE (í)
LATIN SMALL LETTER I WITH DIAERESIS AND ACUTE (ḯ)
LATIN SMALL LETTER K WITH ACUTE (ḱ)
LATIN SMALL LETTER L ACUTE (ĺ)
LATIN SMALL LETTER L WITH ACUTE (ĺ)
LATIN SMALL LETTER M WITH ACUTE (ḿ)
LATIN SMALL LETTER N ACUTE (ń)
LATIN SMALL LETTER N WITH ACUTE (ń)
LATIN SMALL LETTER O ACUTE (ó)
LATIN SMALL LETTER O DOUBLE ACUTE (ő)
LATIN SMALL LETTER O WITH ACUTE (ó)
LATIN SMALL LETTER O WITH CIRCUMFLEX AND ACUTE (ố)
LATIN SMALL LETTER O WITH DOUBLE ACUTE 

Re: Increasing the diversity of people who write Python

[Mikhail V]

On Mon, Nov 27, 2017 at 8:09 PM, Alexandre Brault  wrote:
> A quick Google search turned up WinCompose. It defaults to Right-Alt for
> its compose key, but that's configurable
>
> On 2017-11-27 02:05 PM, Paul Moore wrote:
>> On 27 November 2017 at 18:13, Skip Montanaro  
>> wrote:
 If you have a Windows key, you can assign it to be
 the Compose key.
>>> Would this be true on a machine running Windows? My work environment
>>> has me developing on Linux, with a Windows desktop. It's not clear to
>>> me that any sort of xmodmap shennanigans would work. Won't Windows
>>> itself always gobble up that key?
>> Programs can access the Windows key. IIRC, there is a utility that
>> provides compose-key functionality on Windows. I can't recall the name
>> right now and it's on my other PC, not this one, but I'll try to
>> remember to post the name tomorrow...
>>
>> Paul


On Windows people usually use AHK (Autohotkey).
It is a programming language, so you can do anything you
want. For example, here is a script that converts two
characters to the left of current cursor position:
if it is "e" followed by apostrophe then it replaces it with é,

;---
#NoEnv
SendMode Input
SetWorkingDir %A_ScriptDir%

parse_clip(str) {
firstchar := substr(str, 1,1)
lastchar := substr(str, 2,2)
if  (lastchar = "'") {
if (firstchar = "e") {
Send, {raw}é
}
if (firstchar = "a") {
Send, {raw}á
}
}
else {
Send, {right}
}
}


Esc:: ExitApp

!c::
clipboard := ""
Send, {Shift down}{left}{left}{Shift up}
Send, ^c
Clipwait, 1
gettext := clipboard
parse_clip(gettext)
return

;---

So here the command is bound to Alt-C,
it selects two previus chars (shift+arrow commands), copies to clipboard
and parses the contents. It works system-wide, but
can be programmed to specific app as well.
Best thing is, you can program it youself as you like.
However if you want to program with AHK,
be prepared to invest time, it is not the easiest
programming language out there, only built-ins
probably more than hundred, so better not try to code without
syntax highlighting :)
.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was:

[nospam . Rustom Mody]

On Monday, November 27, 2017 at 8:07:47 PM UTC+5:30, Chris Angelico wrote:
> On Tue, Nov 28, 2017 at 1:25 AM, Rustom Mody wrote:
> > You could go one step more sophisticated and use TeX-input method
> > (C-x RET C-\)
> > After which \'e will collapse as ÄC
> > â £Yeah ok but how the ^)*^$# am I to remember the mantra \'e?!â Ø you may
ask
> > Trueâ | So as you rightly do,
> > - pick it up from google
> > - put emacs into tex input mode
> > - paste from google into emacs
> > - place point on the new char and type C-u C-x =
> >   Among other things emacs will helpfully inform you (among other things)
> >   to input: type "\'{e}" or "\'e" with TeX input method
>
> Which is closely related to the Compose key input method that I use.
> First, you assign a key on your keyboard to be Compose (at least on
> all my systems, there isn't one by default); I use the key between
> left Ctrl and left Alt.

Ha Ha So you wont speak the unspeakable?â¿!â¡

I also have my compose set (to Capslock) And I entered those chars above with
C?? and C!! where C is Capslock

I most frequently use that for âçÆ (C=>) âåÆ (C->) â1 (C^1) âéü (C_1) etc One
can find other goodies at /usr/share/X11/locale/en_US.UTF-8/Compose

I didn't start with mentioning that to Skip because his basic requirement (as I
 got it) was that
- input method should be OS-neutral
- emacs can be assumed

And so the only OS-non-neutrality that I am aware of is that sometimes Alt
works as Meta (gui-emacsen) and sometimes not terminal/text emacsen (typically,
 though I believe some ppl successfully tweak this also) And so M-x can mean
Alt-x (chord) or ESC-x (sequence) and a few such anomalies But beyond that
emacsen should be same for all OSes (modulo versions)

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python

[Alexandre Brault]

A quick Google search turned up WinCompose. It defaults to Right-Alt for
its compose key, but that's configurable


On 2017-11-27 02:05 PM, Paul Moore wrote:
> On 27 November 2017 at 18:13, Skip Montanaro  wrote:
>>> If you have a Windows key, you can assign it to be
>>> the Compose key.
>> Would this be true on a machine running Windows? My work environment
>> has me developing on Linux, with a Windows desktop. It's not clear to
>> me that any sort of xmodmap shennanigans would work. Won't Windows
>> itself always gobble up that key?
> Programs can access the Windows key. IIRC, there is a utility that
> provides compose-key functionality on Windows. I can't recall the name
> right now and it's on my other PC, not this one, but I'll try to
> remember to post the name tomorrow...
>
> Paul

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was:

[nospam . Rustom Mody]

On Friday, November 24, 2017 at 10:11:24 PM UTC+5:30, Skip Montanaro wrote:
> > Because if I already can't understand the words, it will be more useful
> > to me to be able to type them reliably at a keyboard, for replication,
> > search, discussion with others about the code, etc.
>
> I am probably not alone in my Americo-centric world where I can't even
> easily type accented Latin-1 characters. I happen to be using Linux as
> I type this, but type at a Windows keyboard at work (ugh) and have
> long been a user of Macs (still have one or two at home). Might the
> problem be further multiplied by the number of different ways I have
> of entering text? Would Emacs running on Linux, but displaying on
> Windows be different than Chrome running directly on Linux?

I strongly suspect that any recent emacs will have M-x insert-char (earlier it
was called ucs-insert) default bound C-x 8 RET (yeah thats clunky) which will
accept at the minibuffer input

At which point the hex for ÄC which is e9 can be entered â ö yeah its
unreasonable to expect to remember that! Its more reasonable to remember that
that is an e acute; And e itself is a latin lower case letter All of which
becomes entering (in the minibuffer) LATIN SMALL LETTER E ACUTE
- upper case not required; emacs will upcase it for you
- And will also provide some tab/star expansion help
ie *letter e acuteTAB
expands to
LATIN *L LETTER E ACUTE
Further TAB-prodding will give you these choices LATIN CAPITAL LETTER E ACUTE
(Äë)   LATIN CAPITAL LETTER E WITH ACUTE (Äë)
LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND ACUTE (áº1)
LATIN CAPITAL LETTER E WITH MACRON AND ACUTE (á,û)
LATIN SMALL LETTER E ACUTE (ÄC) LATIN SMALL LETTER E WITH ACUTE (ÄC)
LATIN SMALL LETTER E WITH CIRCUMFLEX AND ACUTE (ế)
LATIN SMALL LETTER E WITH MACRON AND ACUTE (á,ù)

You could go one step more sophisticated and use TeX-input method (C-x RET C-\)
After which \'e will collapse as ÄC
â £Yeah ok but how the ^)*^$# am I to remember the mantra \'e?!â Ø you may ask
Trueâ | So as you rightly do,
- pick it up from google
- put emacs into tex input mode
- paste from google into emacs
- place point on the new char and type C-u C-x =
  Among other things emacs will helpfully inform you (among other things)
  to input: type "\'{e}" or "\'e" with TeX input method

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was:

[nospam . Paul Moore]

On 27 November 2017 at 18:13, Skip Montanaro  wrote:
>> If you have a Windows key, you can assign it to be
>> the Compose key.
>
> Would this be true on a machine running Windows? My work environment
> has me developing on Linux, with a Windows desktop. It's not clear to
> me that any sort of xmodmap shennanigans would work. Won't Windows
> itself always gobble up that key?

Programs can access the Windows key. IIRC, there is a utility that provides
compose-key functionality on Windows. I can't recall the name right now and
it's on my other PC, not this one, but I'll try to remember to post the name
tomorrow...

Paul

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was:

[nospam . Chris Angelico]

On Tue, Nov 28, 2017 at 5:13 AM, Skip Montanaro
 wrote:
>> If you have a Windows key, you can assign it to be
>> the Compose key.
>
> Would this be true on a machine running Windows? My work environment
> has me developing on Linux, with a Windows desktop. It's not clear to
> me that any sort of xmodmap shennanigans would work. Won't Windows
> itself always gobble up that key?

Now that, I can't tell you about. As mentioned, the specific system I was using
 was provided by X11, so it wouldn't work on anything else. (Don't know about
Wayland; I think it might have an equivalent.) For other window managers, you'd
 have to find some alternative.

ChrisA

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was:

[nospam . Skip Montanaro]

> I strongly suspect that any recent emacs will have M-x insert-char
> (earlier it was called ucs-insert) default bound C-x 8 RET (yeah thats
clunky)
> which will accept at the minibuffer input

I tried C-x 8 e acute TAB

and was prompted with "E-acute". I don't know why it would have capitalized the
 "e". Still, I plowed ahead and hit RET

which yielded an "Invalid character" message in the minibuffer.

Skip

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was:

[nospam . Chris Angelico]

On Tue, Nov 28, 2017 at 1:55 AM, Rustom Mody  wrote:
> On Monday, November 27, 2017 at 8:07:47 PM UTC+5:30, Chris Angelico wrote:
>> On Tue, Nov 28, 2017 at 1:25 AM, Rustom Mody wrote:
>> > You could go one step more sophisticated and use TeX-input method
>> > (C-x RET C-\)
>> > After which \'e will collapse as ÄC
>> > â £Yeah ok but how the ^)*^$# am I to remember the mantra \'e?!â Ø you may
ask
>> > Trueâ | So as you rightly do,
>> > - pick it up from google
>> > - put emacs into tex input mode
>> > - paste from google into emacs
>> > - place point on the new char and type C-u C-x =
>> >   Among other things emacs will helpfully inform you (among other things)
>> >   to input: type "\'{e}" or "\'e" with TeX input method
>>
>> Which is closely related to the Compose key input method that I use.
>> First, you assign a key on your keyboard to be Compose (at least on
>> all my systems, there isn't one by default); I use the key between
>> left Ctrl and left Alt.
>
> Ha Ha So you wont speak the unspeakable?â¿!â¡

Heh, you mean the term "Windows key"? It's not appropriate on keyboards that
don't have an actual Windows logo on it. There are other names for it, but I
figured the easiest way was to describe its location :D

But yes, that key. If you have a Windows key, you can assign it to be the
Compose key. Or, of course, you could redefine left control, so that Ctrl-X is
with the right key and Compose-X is with the left one. Or any other key you
like.

ChrisA

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was:

[nospam . Skip Montanaro]

> If you have a Windows key, you can assign it to be
> the Compose key.

Would this be true on a machine running Windows? My work environment has me
developing on Linux, with a Windows desktop. It's not clear to me that any sort
 of xmodmap shennanigans would work. Won't Windows itself always gobble up that
 key?

Skip

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was:

[nospam . Chris Angelico]

On Tue, Nov 28, 2017 at 1:25 AM, Rustom Mody  wrote:
> You could go one step more sophisticated and use TeX-input method
> (C-x RET C-\)
> After which \'e will collapse as ÄC
> â £Yeah ok but how the ^)*^$# am I to remember the mantra \'e?!â Ø you may
ask
> Trueâ | So as you rightly do,
> - pick it up from google
> - put emacs into tex input mode
> - paste from google into emacs
> - place point on the new char and type C-u C-x =
>   Among other things emacs will helpfully inform you (among other things)
>   to input: type "\'{e}" or "\'e" with TeX input method

Which is closely related to the Compose key input method that I use. First, you
 assign a key on your keyboard to be Compose (at least on all my systems, there
 isn't one by default); I use the key between left Ctrl and left Alt. Then you
have certain key sequences available that involve holding Compose and pressing
something, and then pressing something else. In the same way that you might
press Ctrl-X, Q to do something, you could press Compose-T, M to produce âäø.
Sounds complicated, but it's not. It's right enough. All your accented letters
can be created with Compose-accent, letter - eg Compose-apostrophe, e => ÄC, or
 Compose-backtick, a => Ä .

Not sure what systems that's supported on. I use Debian GNU/Linux with Xfce; I
believe the Compose key handling is all done by X11, so it should be fairly
widely available at least on Linux-derived systems.

ChrisA

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)

[Paul Moore]

On 27 November 2017 at 18:13, Skip Montanaro  wrote:
>> If you have a Windows key, you can assign it to be
>> the Compose key.
>
> Would this be true on a machine running Windows? My work environment
> has me developing on Linux, with a Windows desktop. It's not clear to
> me that any sort of xmodmap shennanigans would work. Won't Windows
> itself always gobble up that key?

Programs can access the Windows key. IIRC, there is a utility that
provides compose-key functionality on Windows. I can't recall the name
right now and it's on my other PC, not this one, but I'll try to
remember to post the name tomorrow...

Paul
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)

[Skip Montanaro]

> If you have a Windows key, you can assign it to be
> the Compose key.

Would this be true on a machine running Windows? My work environment
has me developing on Linux, with a Windows desktop. It's not clear to
me that any sort of xmodmap shennanigans would work. Won't Windows
itself always gobble up that key?

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)

[Chris Angelico]

On Tue, Nov 28, 2017 at 5:13 AM, Skip Montanaro
 wrote:
>> If you have a Windows key, you can assign it to be
>> the Compose key.
>
> Would this be true on a machine running Windows? My work environment
> has me developing on Linux, with a Windows desktop. It's not clear to
> me that any sort of xmodmap shennanigans would work. Won't Windows
> itself always gobble up that key?

Now that, I can't tell you about. As mentioned, the specific system I
was using was provided by X11, so it wouldn't work on anything else.
(Don't know about Wayland; I think it might have an equivalent.) For
other window managers, you'd have to find some alternative.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)

[Chris Angelico]

On Tue, Nov 28, 2017 at 1:55 AM, Rustom Mody  wrote:
> On Monday, November 27, 2017 at 8:07:47 PM UTC+5:30, Chris Angelico wrote:
>> On Tue, Nov 28, 2017 at 1:25 AM, Rustom Mody wrote:
>> > You could go one step more sophisticated and use TeX-input method
>> > (C-x RET C-\)
>> > After which \'e will collapse as é
>> > “Yeah ok but how the ^)*^$# am I to remember the mantra \'e?!” you may ask
>> > True… So as you rightly do,
>> > - pick it up from google
>> > - put emacs into tex input mode
>> > - paste from google into emacs
>> > - place point on the new char and type C-u C-x =
>> >   Among other things emacs will helpfully inform you (among other things)
>> >   to input: type "\'{e}" or "\'e" with TeX input method
>>
>> Which is closely related to the Compose key input method that I use.
>> First, you assign a key on your keyboard to be Compose (at least on
>> all my systems, there isn't one by default); I use the key between
>> left Ctrl and left Alt.
>
> Ha Ha So you wont speak the unspeakable?¿!¡

Heh, you mean the term "Windows key"? It's not appropriate on
keyboards that don't have an actual Windows logo on it. There are
other names for it, but I figured the easiest way was to describe its
location :D

But yes, that key. If you have a Windows key, you can assign it to be
the Compose key. Or, of course, you could redefine left control, so
that Ctrl-X is with the right key and Compose-X is with the left one.
Or any other key you like.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)

[Skip Montanaro]

> I strongly suspect that any recent emacs will have M-x insert-char
> (earlier it was called ucs-insert) default bound C-x 8 RET (yeah thats clunky)
> which will accept at the minibuffer input

I tried C-x 8 e acute TAB

and was prompted with "E-acute". I don't know why it would have
capitalized the "e". Still, I plowed ahead and hit RET

which yielded an "Invalid character" message in the minibuffer.

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)

[Rustom Mody]

On Monday, November 27, 2017 at 8:07:47 PM UTC+5:30, Chris Angelico wrote:
> On Tue, Nov 28, 2017 at 1:25 AM, Rustom Mody wrote:
> > You could go one step more sophisticated and use TeX-input method
> > (C-x RET C-\)
> > After which \'e will collapse as é
> > “Yeah ok but how the ^)*^$# am I to remember the mantra \'e?!” you may ask
> > True… So as you rightly do,
> > - pick it up from google
> > - put emacs into tex input mode
> > - paste from google into emacs
> > - place point on the new char and type C-u C-x =
> >   Among other things emacs will helpfully inform you (among other things)
> >   to input: type "\'{e}" or "\'e" with TeX input method
> 
> Which is closely related to the Compose key input method that I use.
> First, you assign a key on your keyboard to be Compose (at least on
> all my systems, there isn't one by default); I use the key between
> left Ctrl and left Alt. 

Ha Ha So you wont speak the unspeakable?¿!¡

I also have my compose set (to Capslock)
And I entered those chars above with C?? and C!! where C is Capslock

I most frequently use that for ⇒ (C=>) → (C->) ¹ (C^1) ₁ (C_1) etc
One can find other goodies at /usr/share/X11/locale/en_US.UTF-8/Compose

I didn't start with mentioning that to Skip because his basic requirement
(as I got it) was that
- input method should be OS-neutral
- emacs can be assumed

And so the only OS-non-neutrality that I am aware of is that sometimes
Alt works as Meta (gui-emacsen) and sometimes not terminal/text emacsen 
(typically, though I believe some ppl successfully tweak this also)
And so M-x can mean Alt-x (chord) or ESC-x (sequence) and a few such anomalies
But beyond that emacsen should be same for all OSes (modulo versions)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)

[Chris Angelico]

On Tue, Nov 28, 2017 at 1:25 AM, Rustom Mody  wrote:
> You could go one step more sophisticated and use TeX-input method
> (C-x RET C-\)
> After which \'e will collapse as é
> “Yeah ok but how the ^)*^$# am I to remember the mantra \'e?!” you may ask
> True… So as you rightly do,
> - pick it up from google
> - put emacs into tex input mode
> - paste from google into emacs
> - place point on the new char and type C-u C-x =
>   Among other things emacs will helpfully inform you (among other things)
>   to input: type "\'{e}" or "\'e" with TeX input method

Which is closely related to the Compose key input method that I use.
First, you assign a key on your keyboard to be Compose (at least on
all my systems, there isn't one by default); I use the key between
left Ctrl and left Alt. Then you have certain key sequences available
that involve holding Compose and pressing something, and then pressing
something else. In the same way that you might press Ctrl-X, Q to do
something, you could press Compose-T, M to produce ™. Sounds
complicated, but it's not. It's right enough. All your accented
letters can be created with Compose-accent, letter - eg
Compose-apostrophe, e => é, or Compose-backtick, a => à.

Not sure what systems that's supported on. I use Debian GNU/Linux with
Xfce; I believe the Compose key handling is all done by X11, so it
should be fairly widely available at least on Linux-derived systems.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)

[Rustom Mody]

On Friday, November 24, 2017 at 10:11:24 PM UTC+5:30, Skip Montanaro wrote:
> > Because if I already can't understand the words, it will be more useful
> > to me to be able to type them reliably at a keyboard, for replication,
> > search, discussion with others about the code, etc.
> 
> I am probably not alone in my Americo-centric world where I can't even
> easily type accented Latin-1 characters. I happen to be using Linux as
> I type this, but type at a Windows keyboard at work (ugh) and have
> long been a user of Macs (still have one or two at home). Might the
> problem be further multiplied by the number of different ways I have
> of entering text? Would Emacs running on Linux, but displaying on
> Windows be different than Chrome running directly on Linux? 

I strongly suspect that any recent emacs will have M-x insert-char
(earlier it was called ucs-insert) default bound C-x 8 RET (yeah thats clunky)
which will accept at the minibuffer input

At which point the hex for é which is e9 can be entered — yeah its unreasonable 
to expect to remember that!
Its more reasonable to remember that that is an e acute; 
And e itself is a latin lower case letter
All of which becomes entering (in the minibuffer)
LATIN SMALL LETTER E ACUTE
- upper case not required; emacs will upcase it for you
- And will also provide some tab/star expansion help
ie *letter e acuteTAB 
expands to
LATIN *L LETTER E ACUTE
Further TAB-prodding will give you these choices
LATIN CAPITAL LETTER E ACUTE (É)LATIN CAPITAL LETTER E WITH ACUTE (É)
LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND ACUTE (Ế)
LATIN CAPITAL LETTER E WITH MACRON AND ACUTE (Ḗ)
LATIN SMALL LETTER E ACUTE (é)  LATIN SMALL LETTER E WITH ACUTE (é)
LATIN SMALL LETTER E WITH CIRCUMFLEX AND ACUTE (ế)
LATIN SMALL LETTER E WITH MACRON AND ACUTE (ḗ)

You could go one step more sophisticated and use TeX-input method
(C-x RET C-\)
After which \'e will collapse as é
“Yeah ok but how the ^)*^$# am I to remember the mantra \'e?!” you may ask
True… So as you rightly do, 
- pick it up from google
- put emacs into tex input mode
- paste from google into emacs
- place point on the new char and type C-u C-x =
  Among other things emacs will helpfully inform you (among other things)
  to input: type "\'{e}" or "\'e" with TeX input method
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)

[Rustom Mody]

On Friday, November 24, 2017 at 10:52:47 PM UTC+5:30, Rick Johnson wrote:
> Furthermore, if we are to march headlong onto the glorious
> battlefields of diversity and equality…

Obligatory viewing for those who underappreciate diversity, equality and such

https://youtu.be/Zh3Yz3PiXZw

[My old colleague, a numerical analyst pointed out to me today that the 
'correct 
answer' is not twenty two thousand but twenty million two thousand]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)

[Andrew Z]

Thank you Rick for well thought out argument.



On Nov 24, 2017 12:44, "Rick Johnson" <rantingrickjohn...@gmail.com> wrote:

> On Thursday, November 23, 2017 at 9:57:12 PM UTC-6, Ben Finney wrote:
> [...]
> > This is a necessary consequence of increasing the diversity
> > of people able to program in Python: people will express
> > ideas originating in their own language, in Python code.
> > For that diversity to increase, we English-fluent folk will
> > necessarily become a smaller proportion of the programming
> > community than we are today. That might be uncomfortable
> > for us, but it is a necessary adaptation the community
> > needs to undergo.
>
> Will your heroic crusade to bring equality to the shire also
> include Python standard library modules written in languages
> other than English? If so, then you'll need to contact
> Guido, as PEP8 will require some editing.
>
> Speaking of GvR...
>
> And even if you did managed to bring multilingualism to
> Python scripts and std-lib modules, wouldn't such
> "diversity" be merely symbolic?
>
> Hmm, because, when we consider the make-up of pydev (aka:
> nothing but English speaking dudes) we realize that there
> really isn't any diversity at all. At least, not where it
> matters. (aka: where the decision are being made)
>
> Furthermore, if we are to march headlong onto the glorious
> battlefields of diversity and equality, for the sake of all
> else, then, why should Guido's position be off limits? I
> mean, sure, he may a brilliant man. But he's surely not the
> most brilliant man on this planet, is he?
>
> And with that liberating thought in mind, may i offer an
> excerpt, for your intellectual consumption, from one of the
> most famous documents of all time?
>
> (emphasis mine)
>
> "Prudence, indeed, will dictate that governments long
> established should not be changed for light and transient
> causes; and accordingly, all experience hath shewn, that
> [humankind] are more disposed to _suffer_ while evils are
> _sufferable_, than to right themselves by abolishing the
> forms to which they are "accustomed"; but when a ~long~
> train of abuses and usurpations, pursuing invariably the
> same object, evinces a _design_ to reduce them under
> absolute *DESPOTISM* -- It is their *RIGHT*! It is their
> *DUTY*! -- to throw off such government and to provide new
> guards for their future security"
>
> ...Declaration of Independence: July 4, 1776
>
> I'm of the opinion that diversity is fine, so long as you
> don't make the fatal mistake of "lopping off your nose to
> spite your face".
>
> Take, for example, the accommodations our societies offer
> for handicapped people -- from wheel chair ramps, to
> reserved front-row parking spaces, to widened doorways,
> etc... -- these accommodations do *NOT*, in any way,
> undermine the accessability of healthy people who also utilize
> these same public spaces. In fact, the worst consequence of
> these accommodations might be that you and i must walk a few
> more steps from our car to the market.
>
> Big deal!
>
> But what you are suggesting is not so much an
> _accommodation_, as it is a fundamental fissure in our
> ability to communicate, one that will fracture the community
> far more than it is today. It would be as foolish as
> mandating that everyone must have their legs lopped-off, so
> that all will be "equal".
>
> Yes, diversity is great! But only when it welcomes outsiders
> without undermining the practical cohesiveness of the wider
> community. And if the result of your little "inclusivity
> project" is merely the replacement of N domestic community
> members with N foreign community members, foreigners who's
> regional dialects will muck-up the communication process,
> then it seems to me that what you have gained is merely a
> fulfillment of your _own_ emotional needs, at the expense of
> all.
>
> In conclusion.
>
> While a wise student of knowledge recognizes that:
>
> (1) social groups who have waxed into a homogenous block
> actually undermine themselves, because they lack the
> essential diversity of ideas required to see beyond the
> walls of their own "box", and the confirmation bias that
> infests such societies, will ensure that such a community is
> an evolutionary dead end.
>
> The same student _also_ recognizes that:
>
> (2) a society which resembles a jig-saw-puzzle dumped
> haphazardly on the floor, lacks the essential _cohesiveness_
> required to maintain a strong sense of _community_, a sense
> which allows multiple individuals to work towards a common
> goal, in manner this is both practical and efficient.
>
> Something to think about.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python

[Richard Damon]

On 11/24/17 12:35 PM, Skip Montanaro wrote:

I find it it interesting that the primary reason to want to limit the
character set to ASCII is people thinking that it would make it hard for
*them* to read/use the code, but no thought about how much harder it makes
it on the original author/team to write code that is easily understood by
THEM.

I think you misunderstood my post. For that I apologize that I wasn't clear.

I was only pointing out that there is a ton of inertia based on the
long dominance of ASCII (and before that EBCDIC) and its downstream
effects on computer entry systems. I know that there are likely
semi-reasonable ways to enter accented characters on my keyboard, but
they are unknown to me, and will likely be different on the different
systems I use, so I've not bothered to learn any of them.

One thing which occurred to me as I was typing my earlier message, but
which I failed to include... I wonder if when you go to Dell (for
example) to configure a computer, you can easily specify a non-ASCII
keyboard for a machine destined for delivery to the US. Maybe it's
trivial, but maybe it's just enough more difficult (slows delivery,
costs a few bucks more, which of the alternatives should you choose?)
that people think, "Ah hell, might as well just go with the ASCII
keyboard."

I'm clearly in the old fart camp at this point. Perhaps American
software engineers half my age aren't afflicted by my career-long
biases.

Skip

I doubt I am 1/2 your age (are you 120 yet?). The keyboard I normally 
use would be very hard to use for foreign characters, but I do 
understand that if I wanted to, I could easily get a keyboard designed 
for use in any other language. Some would take some training to learn 
how to use (like a Chinese keyboard).


The fact that I was pointing out is that the fact that people are 
arguing that because *THEY* would have difficulty working with a code 
base (that they likely would never actually need access to) is a good 
reason from preventing others, who already HAVE the needed 
hardware/training from being able to make the code more readable to them.


As far as the basic ability to enter arbitrary characters,  most OSes 
have a generic entry method (like windows ALT-numbers method) and I 
think most have a character selector app to add arbitrary characters to 
the clipboard. Yes, this may not be very convenient for a lot of use but 
is possible. Also, it is generally possible to select an alternate 
keyboard map for your keyboard to enter other characters, you then just 
need to know (or have printed) the new mapping of the keyboard. It helps 
if you do this to have learned the new mapping, and how to touch type on 
that keyboard. Generally you can also get Keyboard Stickers to place on 
your keyboard if you are a hunt and pecker typist.


--
Richard Damon

--
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)

[Skip Montanaro]

> I find it it interesting that the primary reason to want to limit the
> character set to ASCII is people thinking that it would make it hard for
> *them* to read/use the code, but no thought about how much harder it makes
> it on the original author/team to write code that is easily understood by
> THEM.

I think you misunderstood my post. For that I apologize that I wasn't clear.

I was only pointing out that there is a ton of inertia based on the
long dominance of ASCII (and before that EBCDIC) and its downstream
effects on computer entry systems. I know that there are likely
semi-reasonable ways to enter accented characters on my keyboard, but
they are unknown to me, and will likely be different on the different
systems I use, so I've not bothered to learn any of them.

One thing which occurred to me as I was typing my earlier message, but
which I failed to include... I wonder if when you go to Dell (for
example) to configure a computer, you can easily specify a non-ASCII
keyboard for a machine destined for delivery to the US. Maybe it's
trivial, but maybe it's just enough more difficult (slows delivery,
costs a few bucks more, which of the alternatives should you choose?)
that people think, "Ah hell, might as well just go with the ASCII
keyboard."

I'm clearly in the old fart camp at this point. Perhaps American
software engineers half my age aren't afflicted by my career-long
biases.

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)

[Rick Johnson]

On Thursday, November 23, 2017 at 9:57:12 PM UTC-6, Ben Finney wrote:
[...]
> This is a necessary consequence of increasing the diversity
> of people able to program in Python: people will express
> ideas originating in their own language, in Python code.
> For that diversity to increase, we English-fluent folk will
> necessarily become a smaller proportion of the programming
> community than we are today. That might be uncomfortable
> for us, but it is a necessary adaptation the community
> needs to undergo.

Will your heroic crusade to bring equality to the shire also
include Python standard library modules written in languages
other than English? If so, then you'll need to contact
Guido, as PEP8 will require some editing.

Speaking of GvR... 

And even if you did managed to bring multilingualism to
Python scripts and std-lib modules, wouldn't such
"diversity" be merely symbolic?

Hmm, because, when we consider the make-up of pydev (aka:
nothing but English speaking dudes) we realize that there
really isn't any diversity at all. At least, not where it
matters. (aka: where the decision are being made)

Furthermore, if we are to march headlong onto the glorious
battlefields of diversity and equality, for the sake of all
else, then, why should Guido's position be off limits? I
mean, sure, he may a brilliant man. But he's surely not the
most brilliant man on this planet, is he?

And with that liberating thought in mind, may i offer an
excerpt, for your intellectual consumption, from one of the
most famous documents of all time?

(emphasis mine)

"Prudence, indeed, will dictate that governments long
established should not be changed for light and transient
causes; and accordingly, all experience hath shewn, that
[humankind] are more disposed to _suffer_ while evils are
_sufferable_, than to right themselves by abolishing the
forms to which they are "accustomed"; but when a ~long~
train of abuses and usurpations, pursuing invariably the
same object, evinces a _design_ to reduce them under
absolute *DESPOTISM* -- It is their *RIGHT*! It is their
*DUTY*! -- to throw off such government and to provide new
guards for their future security"

...Declaration of Independence: July 4, 1776

I'm of the opinion that diversity is fine, so long as you
don't make the fatal mistake of "lopping off your nose to
spite your face".

Take, for example, the accommodations our societies offer
for handicapped people -- from wheel chair ramps, to
reserved front-row parking spaces, to widened doorways,
etc... -- these accommodations do *NOT*, in any way,
undermine the accessability of healthy people who also utilize
these same public spaces. In fact, the worst consequence of
these accommodations might be that you and i must walk a few
more steps from our car to the market.

Big deal!

But what you are suggesting is not so much an
_accommodation_, as it is a fundamental fissure in our
ability to communicate, one that will fracture the community
far more than it is today. It would be as foolish as
mandating that everyone must have their legs lopped-off, so
that all will be "equal".

Yes, diversity is great! But only when it welcomes outsiders
without undermining the practical cohesiveness of the wider
community. And if the result of your little "inclusivity
project" is merely the replacement of N domestic community
members with N foreign community members, foreigners who's
regional dialects will muck-up the communication process,
then it seems to me that what you have gained is merely a
fulfillment of your _own_ emotional needs, at the expense of
all.

In conclusion. 

While a wise student of knowledge recognizes that:

(1) social groups who have waxed into a homogenous block
actually undermine themselves, because they lack the
essential diversity of ideas required to see beyond the
walls of their own "box", and the confirmation bias that
infests such societies, will ensure that such a community is
an evolutionary dead end.

The same student _also_ recognizes that:

(2) a society which resembles a jig-saw-puzzle dumped
haphazardly on the floor, lacks the essential _cohesiveness_
required to maintain a strong sense of _community_, a sense
which allows multiple individuals to work towards a common
goal, in manner this is both practical and efficient.

Something to think about.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)

[Richard Damon]

On 11/24/17 11:41 AM, Skip Montanaro wrote:

Because if I already can't understand the words, it will be more useful
to me to be able to type them reliably at a keyboard, for replication,
search, discussion with others about the code, etc.

I am probably not alone in my Americo-centric world where I can't even
easily type accented Latin-1 characters. I happen to be using Linux as
I type this, but type at a Windows keyboard at work (ugh) and have
long been a user of Macs (still have one or two at home). Might the
problem be further multiplied by the number of different ways I have
of entering text? Would Emacs running on Linux, but displaying on
Windows be different than Chrome running directly on Linux? I will
make a wild-ass guess and suggest that maybe, just maybe, those three
major system types have different ways of typing accented characters.
Consequently, I've never even tried to learn any of them. On the rare
instance where I need to type an accented character, such as when
typing Marc-André Lemburg's name properly, I ask Google for "accented
e" and copy/paste an instance.

That's a PITA, but worth it on the few occasions where I need it
today. I suppose I would have to break down and learn how to properly
enter such text should I need to Romanized text which might contain
cedillas, accents and other diacritical marks...

This is all not to suggest the goal isn't worth striving for, just
that there exists a huge barrier - in the form of ASCII and its
limiting effect on computer keyboard entry - to attaining Unicode
identifier Nirvana. Perhaps for my next computer I should choose a
non-ASCII keyboard option when configuring it.

Skip


I find it it interesting that the primary reason to want to limit the 
character set to ASCII is people thinking that it would make it hard for 
*them* to read/use the code, but no thought about how much harder it 
makes it on the original author/team to write code that is easily 
understood by THEM. Yes, code intended to be used by the broad community 
would be best to adhere to the community standard (and the community 
style guide should, if it doesn't already, have a rule about this). Code 
intended for internal usage is best to be as well understood by that 
group as possible.


Some also bring up some of the issues with similar glyphs, as if we 
don't already have issues with things like 0 and O, 1 and l and I 
(depending on the font you use). This mostly comes down to 
self-inflicted pain, which can mostly be relieved with a style rule to 
avoid multi-language identifiers, perhaps checked with a special 
'linter'. Since Python is white space sensitive, we already have the 
issue with the distinction between space and tab, which isn't normally 
obvious in many text editors (Though I suspect many Python programmers 
have their editors configured to largely avoid the issue).


--
Richard Damon

--
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)

[Skip Montanaro]

> Because if I already can't understand the words, it will be more useful
> to me to be able to type them reliably at a keyboard, for replication,
> search, discussion with others about the code, etc.

I am probably not alone in my Americo-centric world where I can't even
easily type accented Latin-1 characters. I happen to be using Linux as
I type this, but type at a Windows keyboard at work (ugh) and have
long been a user of Macs (still have one or two at home). Might the
problem be further multiplied by the number of different ways I have
of entering text? Would Emacs running on Linux, but displaying on
Windows be different than Chrome running directly on Linux? I will
make a wild-ass guess and suggest that maybe, just maybe, those three
major system types have different ways of typing accented characters.
Consequently, I've never even tried to learn any of them. On the rare
instance where I need to type an accented character, such as when
typing Marc-André Lemburg's name properly, I ask Google for "accented
e" and copy/paste an instance.

That's a PITA, but worth it on the few occasions where I need it
today. I suppose I would have to break down and learn how to properly
enter such text should I need to Romanized text which might contain
cedillas, accents and other diacritical marks...

This is all not to suggest the goal isn't worth striving for, just
that there exists a huge barrier - in the form of ASCII and its
limiting effect on computer keyboard entry - to attaining Unicode
identifier Nirvana. Perhaps for my next computer I should choose a
non-ASCII keyboard option when configuring it.

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)

[Thomas Jollans]

On 24/11/17 05:45, Andrew Z wrote:
> I have hard time seeing the benefits of this "necessity" , just
> unreasonable  overcomplications for the name of "diversity".

What complications?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)

[Andrew Z]

I have hard time seeing the benefits of this "necessity" , just
unreasonable  overcomplications for the name of "diversity".




On Nov 23, 2017 22:57, "Ben Finney" <ben+pyt...@benfinney.id.au> wrote:

> Ian Kelly <ian.g.ke...@gmail.com> writes:
>
> > On Thu, Nov 23, 2017 at 1:04 PM, Karsten Hilbert
> > <karsten.hilb...@gmx.net> wrote:
> > > Using function arguments written in Thai script ?
> > >
> > > Understanding, let alone being able to read, code written in Arabic
> > > ?
> >
> > People are going to write code in Arabic whether you like it or not,
> > because not everybody speaks English, and not everybody who does
> > *wants* to use it.
>
> This is, I think, a good reason to allow Unicode identifiers (at least,
> those Unicode subsets which encode writing systems of languages) as
> programming-language identifiers.
>
> > Now, would you prefer to read code where the variable names are
> > written in Arabic script, or where the variable names are still in
> > Arabic but transliterated to Latin characters?
>
> (On the – evidently correct, in Karsten's case and mine – assumption
> that the reader does not understand Arabic script.)
>
> I've thought about this, and if the quesition is which would *I* prefer,
> the answer is I'd prefer the identifiers transliterated to the Latin
> (English-writing) characters.
>
> Because if I already can't understand the words, it will be more useful
> to me to be able to type them reliably at a keyboard, for replication,
> search, discussion with others about the code, etc.
>
> Set against that, though, I want the preferences of *others* to be taken
> into consideration also. And there are many more people who do not
> natively write English/Latin characters, that I want to feel welcome in
> the Python community.
>
> So it's a good thing that my own reading preference *does not* have
> weight in this matter. I'm not the primary audience for code identifiers
> written in Arabic script, so my preference should matter less than those
> who understand it.
>
> > Either way, you're not going to be able to understand it, so I'm not
> > sure why it makes a difference to you.
>
> I hope you can see that it can simultaneously make a difference – I
> would definitely prefer to read Latin-writing identifiers – while also
> being a lesser consideration that should not outweigh the benefits of
> allowing non-Latin-script identifiers.
>
> > If Arabic characters are allowed however, then it might be of use to
> > the people who are going to code in Arabic anyway. And if it isn't,
> > then they have the option not to use it either.
>
> This is a necessary consequence of increasing the diversity of people
> able to program in Python: people will express ideas originating in
> their own language, in Python code.
>
> For that diversity to increase, we English-fluent folk will necessarily
> become a smaller proportion of the programming community than we are
> today. That might be uncomfortable for us, but it is a necessary
> adaptation the community needs to undergo.
>
> --
>  \ “In any great organization it is far, far safer to be wrong |
>   `\  with the majority than to be right alone.” —John Kenneth |
> _o__)Galbraith, 1989-07-28 |
> Ben Finney
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)

[Ben Finney]

Ian Kelly <ian.g.ke...@gmail.com> writes:

> On Thu, Nov 23, 2017 at 1:04 PM, Karsten Hilbert
> <karsten.hilb...@gmx.net> wrote:
> > Using function arguments written in Thai script ?
> >
> > Understanding, let alone being able to read, code written in Arabic
> > ?
>
> People are going to write code in Arabic whether you like it or not,
> because not everybody speaks English, and not everybody who does
> *wants* to use it.

This is, I think, a good reason to allow Unicode identifiers (at least,
those Unicode subsets which encode writing systems of languages) as
programming-language identifiers.

> Now, would you prefer to read code where the variable names are
> written in Arabic script, or where the variable names are still in
> Arabic but transliterated to Latin characters?

(On the – evidently correct, in Karsten's case and mine – assumption
that the reader does not understand Arabic script.)

I've thought about this, and if the quesition is which would *I* prefer,
the answer is I'd prefer the identifiers transliterated to the Latin
(English-writing) characters.

Because if I already can't understand the words, it will be more useful
to me to be able to type them reliably at a keyboard, for replication,
search, discussion with others about the code, etc.

Set against that, though, I want the preferences of *others* to be taken
into consideration also. And there are many more people who do not
natively write English/Latin characters, that I want to feel welcome in
the Python community.

So it's a good thing that my own reading preference *does not* have
weight in this matter. I'm not the primary audience for code identifiers
written in Arabic script, so my preference should matter less than those
who understand it.

> Either way, you're not going to be able to understand it, so I'm not
> sure why it makes a difference to you.

I hope you can see that it can simultaneously make a difference – I
would definitely prefer to read Latin-writing identifiers – while also
being a lesser consideration that should not outweigh the benefits of
allowing non-Latin-script identifiers.

> If Arabic characters are allowed however, then it might be of use to
> the people who are going to code in Arabic anyway. And if it isn't,
> then they have the option not to use it either.

This is a necessary consequence of increasing the diversity of people
able to program in Python: people will express ideas originating in
their own language, in Python code.

For that diversity to increase, we English-fluent folk will necessarily
become a smaller proportion of the programming community than we are
today. That might be uncomfortable for us, but it is a necessary
adaptation the community needs to undergo.

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

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue31011] Users (except from the one who installed) not able to see python in add remove programs.

[Debarshi Goswami]

Changes by Debarshi Goswami :


--
nosy: +manddy221

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31011] Users (except from the one who installed) not able to see python in add remove programs.

[Debarshi Goswami]

New submission from Debarshi Goswami:

When Python (64 bit) is installed for all users from an admin account on 
Windows, it gets installed correctly for all users , but it does not appear in 
add remove program for users other than one who installed it.


Command used : python-3.6.1-amd64.exe /quiet InstallAllUsers=1 PrependPath=1 
TargetDir=C:\apps\Python36

Work around: Repair the installation by launching Python installer again.

--
components: Installation
messages: 298965
nosy: Debarshi.Goswami
priority: normal
severity: normal
status: open
title: Users (except from the one who installed) not  able to see python in add 
remove programs.
type: behavior
versions: Python 3.6

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31011>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Developers Who Use Spaces Make More Money!

[alister]

On Thu, 15 Jun 2017 21:11:41 -0600, Ian Kelly wrote:

> On Thu, Jun 15, 2017 at 8:51 PM, Larry Martell 
> wrote:
>> On Thu, Jun 15, 2017 at 6:35 PM, Christopher Reimer
>>  wrote:
>>> One commentator on a tech website admonished programmers for wasting
>>> time by pressing the space bar four times instead of using tab. O_o
>>
>> Not in vi with
>>
>> set autoindent set expandtab
> 
> Or in any halfway-decent editor with reasonable indentation settings.

indeed if your editor can deal with something this simple i dread to 
think how much more time wasting will be caused by all of its other 
inefficiencies



-- 
Instead, people would take pains to tell her that beauty was only
skin-deep, as if a man ever fell for an attractive pair of kidneys.
(Maskerade)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Developers Who Use Spaces Make More Money!

[Ian Kelly]

On Thu, Jun 15, 2017 at 8:51 PM, Larry Martell  wrote:
> On Thu, Jun 15, 2017 at 6:35 PM, Christopher Reimer
>  wrote:
>> One commentator on a tech website admonished programmers for wasting time by 
>> pressing the space bar four times instead of using tab. O_o
>
> Not in vi with
>
> set autoindent
> set expandtab

Or in any halfway-decent editor with reasonable indentation settings.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Developers Who Use Spaces Make More Money!

[Larry Martell]

On Thu, Jun 15, 2017 at 6:35 PM, Christopher Reimer
 wrote:
>> On Jun 15, 2017, at 3:24 PM, jlada...@itu.edu wrote:
>>
>> This is hilarious, I have to share:
>>
>> https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/
>>
>> Thanks to Guido for making us all richer!
>
> One commentator on a tech website admonished programmers for wasting time by 
> pressing the space bar four times instead of using tab. O_o

Not in vi with

set autoindent
set expandtab
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Developers Who Use Spaces Make More Money!

[Steve D'Aprano]

On Fri, 16 Jun 2017 08:42 am, Chris Angelico wrote:

> On Fri, Jun 16, 2017 at 8:24 AM,  <jlada...@itu.edu> wrote:
>> This is hilarious, I have to share:
>>
>>
https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/
>>
>> Thanks to Guido for making us all richer!
> 
> Bah, that's just noise. There may appear to be a small difference
> between those who use tabs and those who use spaces, but look at the
> numbers: whichever one you use, you're going to make FAR more money
> than people who don't use any whitespace in their code.

Oh man... can you imagine how much money there is to be made by eliminating all
non-whitespace from your code?

http://progopedia.com/language/whitespace/




-- 
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: Developers Who Use Spaces Make More Money!

[Christopher Reimer]

> On Jun 15, 2017, at 3:24 PM, jlada...@itu.edu wrote:
> 
> This is hilarious, I have to share:
> 
> https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/
> 
> Thanks to Guido for making us all richer!

One commentator on a tech website admonished programmers for wasting time by 
pressing the space bar four times instead of using tab. O_o

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Developers Who Use Spaces Make More Money!

[Chris Angelico]

On Fri, Jun 16, 2017 at 8:24 AM,  <jlada...@itu.edu> wrote:
> This is hilarious, I have to share:
>
> https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/
>
> Thanks to Guido for making us all richer!

Bah, that's just noise. There may appear to be a small difference
between those who use tabs and those who use spaces, but look at the
numbers: whichever one you use, you're going to make FAR more money
than people who don't use any whitespace in their code.

Search your feelings, you know this to be true...

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Developers Who Use Spaces Make More Money!

[jladasky]

This is hilarious, I have to share:

https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/

Thanks to Guido for making us all richer!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to run self-contained Python scripts who don't need Python installation?

[Akira Li]

"Juan C."  writes:

> I need to run some Python 3.6.0 scripts on the users' machines (W7 and
> W10) in an enterprise environment, but I can't install Python on those
> machines. I tried looking for those "py to exe", but sadly they don't
> support Python 3.6.0.

I've tried PyInstaller (development version) and it works with Python 3.6:

  $ py -3.6 -m pip install 
https://github.com/pyinstaller/pyinstaller/archive/develop.zip

From
https://www.reddit.com/r/Python/comments/6fpr70/how_do_i_distribute_a_py_file_and_its/


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to run self-contained Python scripts who don't need Python installation?

[Michael Torrie]

On 06/08/2017 07:40 PM, Juan C. wrote:
> 2. I'd like to create a simple BAT to run my Python script, so there
> would be only 2 things (a 'dist' folder with everything and a run.bat
> to make it clear what should be run), for example:

Sure you can. You just have to do it like this (untested; I haven't used
Windows in many years):

@echo off

start %~dp0dist\python-3.6.0-embed-win32\python.exe %~dp0dist\app.py %*

I think %* expands to all the commandline parameters, apparently
excluding %0, which would be the command name itself.





-- 
https://mail.python.org/mailman/listinfo/python-list

How to run self-contained Python scripts who don't need Python installation?

[Juan C.]

I need to run some Python 3.6.0 scripts on the users' machines (W7 and
W10) in an enterprise environment, but I can't install Python on those
machines. I tried looking for those "py to exe", but sadly they don't
support Python 3.6.0. Then I found out about "Windows x86/x86-64
embeddable zip file" that Python.org made available since 3.5.0, and I
thought it would be the right thing for my case.

I have some questions regarding embeddable Python:

1. How can I install custom modules using pip?

2. I'd like to create a simple BAT to run my Python script, so there
would be only 2 things (a 'dist' folder with everything and a run.bat
to make it clear what should be run), for example:
@echo off
start %~dp0dist\python-3.6.0-embed-win32\python.exe %~dp0dist\app.py

The issue is that I can't parse args to app.py in this case. How would
that be possible? In the example above, if Python was fully installed,
I would give a file as argument to app.py, generally clicking and
dragging the file into the app.py icon so that it would start.

3. Is there a better approach for my case other than embedded Python?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Text-mode apps (Was :Who are the "spacists"?)

[Mikhail V]

On 3 April 2017 at 19:55, Steve D'Aprano <steve+pyt...@pearwood.info> wrote:

> I didn't see you calling out Rick for his prejudice against those who aren't
> American, his absurd belief that "most" people are satisfied with ASCII,

Hmm... that is interesting.
Everyone has some beliefs...
If I make a bit more on-topic question:
What is "satisfied" with ASCII, or what is
"we need Unicode", where and what for?
What is your "satisfaction" with Unicode?

For me it is a font, where images given
numbers, ok, then we need obviosly to
look at it,  e.g.  if you make a codec.

So you are just stating the fact that font files
store them in this order and a txt file in Notepad
will show them in correct order?
hmm... I just thought you have some idea,
e.g. what glyphs you adore esthetically
or find especially useful in your life.

Which of some 40 images that are needed for _you_
to represent speech and numbers, you find
IDK, appealing or annoying, or what?

In typesetting, I find annoying caps inculsion, too
little space between sentences and not so good separator
character design, some flaws in letter design.
For development purposes I would need some
glyphs for non-printable characters, ok
few glyphs more.

Tak zachem _nuzhen_ Unikod ?
Rasskazhi chto-nibud interesnoe.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Text-mode apps (Was :Who are the "spacists"?)

[cwrseckford]

On Saturday, 1 April 2017 17:01:03 UTC+1, Steve D'Aprano  wrote:
> On Sat, 1 Apr 2017 12:17 pm, Rick Johnson wrote:
> 
> > Most people just quietly change the filename and move on
> 
> 
> There are over a billion people in China, almost a billion more in India,
> about 140 million people in Russia, nearly 130 million people in Japan, 250
> million in Indonesia, about 290 million native Arabic speakers, and even 9
> million speakers of Hebrew.
> 
> If you think that all these people, and hundreds of millions more, will
> just "quietly change the filename" to ASCII because you're too lazy,
> self-centred and arrogant to move on from 1963, then you truly are an
> example of the Ugly American.
> 

Try to get your cliches straight.  The "Ugly American" was the good guy, in 
contrast to the good-looking, smooth-talking State Department types who were 
the baddies.

But hey, experience tells us that anyone ugly must automatically be wicked, not 
so?

Will
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Text-mode apps (Was :Who are the "spacists"?)

[Rick Johnson]

On Sunday, April 2, 2017 at 3:49:43 PM UTC-5, Gene Heskett wrote:
> On Sunday 02 April 2017 12:26:40 Steve D'Aprano wrote:
> > On Sun, 2 Apr 2017 04:41 pm, Terry Reedy wrote:
> > > On 4/1/2017 12:00 PM, Steve D'Aprano wrote:
> > > > 
> > > > example of the Ugly American.
> > > 
> > > As an American I resent your promotion and perpetuation
> > > of an ugly ethno-centric stereotype.
> >
> > I'm glad you didn't try to describe it as a *unfair* or
> > *unjustified* stereotype, because (let's face it) after
> > November 8th 2016, that simply wouldn't fly.
> 
> While I too detest that label, I will have to admit that I
> am one of the conservatives, believing our Constitution and
> Bill of Rights have been used as TP by the "establishment"
> over the last 65+ years, who enabled that surprise. 

Saying what you just said, in _this_ group at least, can
bring some nasty rebukes. And not because it is wrong, no,
but because the proggie-bots will accuse you of being (1) a
racist opining for the return of slavery, (2) a homophobic
who would throw people from rooftops, (3) a bigot, (4)
something else that is equally "bad", or (5) all of the
above.

Hopefully though, like me, you're undeterred by lies and
slander because your skin is thicker than that of the
average grape. As for me, i do not want america society to
return to 1950, no, i want to american _ideals_ to return to
July 4, 1776. And this time we would: "get it right". The
first order of business would be to re-write the
constitution in a manner that will remove the subtle
semantical errors that have caused so much trouble for these
last 200+ years. Starting with the Declaration of
Independence. 

(emphasis *MINE*!)

  "When in the course of human events, it becomes
  *NECESSARY* for one people to dissolve the political bands
  which have connected them with another, and to assume
  among the powers of the earth the *SEPARATE* and *EQUAL*
  station to which the laws of nature and of [the natural
  processes that] *ENTITLE* them, a decent respect to the
  [reputation] of [humankind] requires that they should
  declare the causes which impel them to the separation."
  
  "We hold these truths to be self-evident, that all
  [people] are created equal, that they are endowed by their
  [existence] with certain unalienable rights: that among
  these are life, liberty and the pursuit of happiness. --
  that to *SECURE* these rights, governments are instituted
  among [people], deriving their just powers from the
  *CONSENT* of the governed, -- That whenever any form of
  government becomes destructive of these ends, it is the
  *RIGHT* of the people to alter or to abolish it, and to
  institute new government, laying its foundation on such
  *PRINCIPLES* and organizing its powers in such *FORM*, as
  to them shall seem most likely to effect their safety and
  happiness."
  
  "Prudence, indeed, will dictate that governments long
  established should *NOT* be changed for _light_ and
  _transient_ causes; and accordingly, all experience hath
  shewn, that [humankind] are more disposed to suffer while
  evils are "sufferable", than to right themselves by
  abolishing the forms to which they are "accustomed". But
  when a *LNG* train of abuses and usurpations pursuing
  invariably the same [*GOALS* -- to achieve an absolute
  despotism --], it is their *RIGHT*, it is their *DUTY*, to
  throw off such government and to provide new guards for
  their future security. -- Such has been the patient
  sufferance of these [people]; and such is now the
  *NECESSITY* which constrains them to alter their former
  systems of government. The history of the present [United
  States Of America] is a history of repeated injuries and
  usurpations [-- and quite frankly, a charade of vile
  hypocrisy! --], all having in direct object the
  establishment of an absolute tyranny over these [people].
  To prove this, let facts be submitted to a candid world."

  [List of modern grievances snipped for bandwidth]
  

Simply removing all the misogynist references and
patriarchal terms is a good start. But what is important to
realize, is that, removing these mistakes does not undermine
the intent of this document, no, it merely broadens and
purifies that intent. The fact is, this document has caused
a social transformation that has reverberated around the
world.

(Rhetorically i ask...)

What _is_ "life, liberty, and the pursuit of happiness"? 

Is it merely the monotone words of a random child standing
on a random grade-school stage reenacting the events of our
forefathers for the sake of mere "cute spectacle"? Or is it
something more? -- I believe it be. -- I believe it to be
one of the most *PROFOUND* realizations of social justice
that the human mind has *EVER* conceiv

Re: Text-mode apps (Was :Who are the "spacists"?)

[Chris Angelico]

On Tue, Apr 4, 2017 at 10:13 AM, Rick Johnson
 wrote:
> D'Aprano, are you still stewing because Donald J Trump
> spanked Hillary's jumbo sized bottom like an unruly
> stepchild? You poor widdle partisian hack. I almost feel
> sorry for you.
>
> [snip massively long political rant]

Alright, can the politics please be taken off list? I believe the
appropriate newsgroup for this drivel is comp.lang./dev/null.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Text-mode apps (Was :Who are the "spacists"?)

[Mark -]

On Sunday, April 2, 2017 at 11:26:50 AM UTC-5, Steve D'Aprano wrote:


On Sun, 2 Apr 2017 04:41 pm, Terry Reedy wrote:


On 4/1/2017 12:00 PM, Steve D'Aprano wrote:


example of the Ugly American.


As an American I resent your promotion and perpetuation of an ugly
ethno-centric stereotype.


I'm glad you didn't try to describe it as a *unfair* or *unjustified*
stereotype, because (let's face it) after November 8th 2016, that
simply wouldn't fly.


D'Aprano, are you still stewing because Donald J Trump spanked




Hear hear


--
https://mail.python.org/mailman/listinfo/python-list

Re: Text-mode apps (Was :Who are the "spacists"?)

[Rick Johnson]

On Sunday, April 2, 2017 at 11:26:50 AM UTC-5, Steve D'Aprano wrote:
> On Sun, 2 Apr 2017 04:41 pm, Terry Reedy wrote:
> > On 4/1/2017 12:00 PM, Steve D'Aprano wrote:
> > 
> > > example of the Ugly American.
> > 
> > As an American I resent your promotion and perpetuation of
> > an ugly ethno-centric stereotype.
> 
> I'm glad you didn't try to describe it as a *unfair* or
> *unjustified* stereotype, because (let's face it) after
> November 8th 2016, that simply wouldn't fly.

D'Aprano, are you still stewing because Donald J Trump
spanked Hillary's jumbo sized bottom like an unruly
stepchild? You poor widdle partisian hack. I almost feel
sorry for you.

Heck, Trump has to be the most crass and unstatesmanlike
candidate to ever run for the american presidency -- well,
certainly in my lifetime -- so it should have been the
surest win in history for Hillary (or should i say "HER-"?),
but even with the mainstream media planted firmly in her
pocket; Bill Clinton's endless charms; a grotesque
prosession of hollywood celebs, and Obama on the campaign
trail -- she folded like lawn chair! How pathetic. Not to
mention that the democratic party cheated Burnie Sanders. (i
wonder if he's "feelin' the burn"?)

Of course, in their hubris, the Dems put all their chips on
the same old tired "game of firsts" crapola, thinking the
emotional sleight of hand was enough to clinch them the
white house, but fortunately (for america), somebody at the
DNC forgot to tell the Dem leaders that america is getting
*SICK* and *TIRED* of the emotional games.

We only want two types of candidates now: (1) those who are
highly qualified non-partisans, or (2) those who will burn
the old orders to the ground! With Trump, we got the latter.
But as bad a Trump is, he's better than the "business as
usual" we get from Repuke-I-Cans and Demon-Rats.

But Steven, you're not even an american are you? Nope!
You're just another Brit with a stick jambed firmly up his
butt waddling around lecturing Americans about how terrible
we are, but have you ever stopped to consider your own
nation's horrendous history?

  TIP OF THE DAY: "Great Britain" is the imperialist empire
  previously known as "England".

Now sod-off to your local library so you can catch up on,
say, the last umpteen centuries of English tyranny and
global colonization. Oh, and, please note that people who
live in glass houses would be wise not to start a stone
throwing war. just FYI, old buddy. *wink*

> Not all Americans, perhaps not even a majority or a
> plurality, are Ugly Americans, but there are enough of them
> to screw it up for everyone else.

There are bad apples in every bunch; every nation; every
group. Stupidity and ignorance are ubiquitous traits and are
fairly evenly distributed around the globe. So enough with
America bashing already. We Americans are no more guilty of
hate and intolerance than any other nation or peoples on
this planet. Heck, we've only existed for just over 200
years, yet many polmics and media types would have the world
believe that hate and intolerance didn't exist in this
universe until July 4, 1776.

And when has _any_ reigning power in human history ever
acted in a 100% benevolent manner? Hmm? (At least, any one
that matters, that is). If we read our history books, we
would come to the conclusion that tyranny is the natural
order of our human society, and, more evidence of universal
laws in action. Therefore, only through perpetual conflict
can we keep tyranny at bay. For instance, it's not as if we
could tell ol' Henry the Eighth: "You know what Henry... you
can be a real horse's arse!" -- to which he would
"supposedly" reply -- "Indeed. I think i am. And uh, thank
you for the healthy criticism" -- NOT! It is more likely
that anyone who dared critize the king would win a free all-
expense-paid trip to the tower of London, a most horrific
place with a most notorious reputation for cruelty. But the
English had quite a knack for cruelty, eh Steven? Hmm,
remind me again, ol' boy, how many wives did King Henry the
VIII have executed for their "supposed" infidelity? Of
course, there are rumours that one of the executions did not
go as "cleanly" as planned. My observation is that the
botched nature of that execution was a feature, not a bug.
But depravity has been the SOP for centuries in "Merry ol'
England", eh chap?

> It's an ugly stereotype, not because it is a stereotype,
> but because it embodies a set of ugly attitudes and
> behaviours.

Your feeble attempts to legitimize your American bashing are
deplorable at best. For once in your life, Steven, admit
that you're filled with hate and apologize for it. If you
don't like America, fine, don't come here. Is that so
difficult for you? *WHO* we elect and *HOW* we live our
lives is none of your damned business.

Re: Text-mode apps (Was :Who are the "spacists"?)

[Rick Johnson]

On Saturday, April 1, 2017 at 9:32:17 PM UTC-5, MRAB wrote:
> Sometimes he mentions MUDs, sometimes he mentions Pike, but at least he 
> doesn't rant.

I have not even _begun_ to rant. Yet...

-- 
https://mail.python.org/mailman/listinfo/python-list

OFF-TOPIC Bigotry on the list [was Re: Text-mode apps (Was :Who are the "spacists"?)]

[Steve D'Aprano]

On Mon, 3 Apr 2017 08:31 am, Terry Reedy wrote:

[...]
> I refrained because it would be off-topic and a diversion from my point:
> all bigotry is inappropriate here on this list, 

Indeed it is not appropriate. But calling out bigotry is not itself bigotry.

I hope you agree with that.

If not, that leaves you with some deeply Unfortunate Implications.

Suppose you are right, and merely calling out "Ranting Rick" for his bigoted
attitude makes me an anti-American bigot. Then by *you* calling *me* out
for bigotry, that makes you equally a bigot. And so the only way to avoid
being a bigot is... to do nothing in the face of bigotry.

I didn't see you calling out Rick for his prejudice against those who aren't
American, his absurd belief that "most" people are satisfied with ASCII, or
his claim that the rest of the world don't need file names in their native
languages because the "majority" (his word) of them are illiterate. Do you
think those attitudes should be left unchallenged?

(In fairness, Rick doesn't say that the *entire* rest of the world is mostly
illiterate. He only includes China, India, Russia, Japan, Indonesia,
Arab-speakers, and Israel. So a bit less than half the world.)


> including anti-Americanism.

When have I demonstrated prejudice against Americans merely for being
American?

I stand by my comment to Rick. It is *his behaviour and attitude* which
makes him an example of the stereotype, not the fact that he is an
American.

Of course all people are unique, and all stereotypes are incomplete. People
are not their stereotype, and I'm sure that Rick is a wonderful and unique
person in his own way. Perhaps he loves animals and donates his time to
working in shelters for the homeless.

But nevertheless people do behave in stereotypical ways, and we've seen Rick
do exactly that. Insensitive to cultural differences, dismissive of those
who aren't American, ignorant of everything outside of the borders of the
US, and arrogantly certain that the American way is not just the best way
but the only way. And *wilfully* so. This is not just an isolated incident
from Rick, a mere momentary lapse. He has been expressing these sorts of
attitudes for years.


> (I actually think raw bigoty is inappropriate everywhere.  While there
> are places to discuss the relative average beauty and niceness of
> various groups of people, this is not one of them.  Even comparisons of
> computer languages is not the main focus of this list.)

I'm not discussing the "relative average beauty and niceness of various
groups of people". That's absurd. I'm discussing the behaviour and
attitudes demonstrated by one specific individual.


[...]
> Yesterday, Chris Angelico, I believe it was, asked someone to stop
> including anti-Jew messages in posts here.  So I asked the same of you
> regarding your anti-American expression.

Can you really not tell the difference between criticism of an individual
American for the views he expresses, and a blanket attack on all Americans
merely for being American?



>> Not all Americans, perhaps not even a majority or a plurality, are Ugly
>> Americans, but there are enough of them to screw it up for everyone else.
> 
> Shall we discuss Ugly Australians, or whatever the appropriate epithet
> would be?

If one of them turns up and starts expressing those views, absolutely.


>> It's an ugly stereotype, not because it is a stereotype, but because it
>  > embodies a set of ugly attitudes and behaviours.
> 
> I am sure I have seen similar things written by various other people
> justifying their prejudices.

As have I. Are you judging *me* by *their* behaviour?



-- 
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: Text-mode apps (Was :Who are the "spacists"?)

[Terry Reedy]

On 4/2/2017 12:26 PM, Steve D'Aprano wrote:

On Sun, 2 Apr 2017 04:41 pm, Terry Reedy wrote:


On 4/1/2017 12:00 PM, Steve D'Aprano wrote:


example of the Ugly American.


As an American I resent your promotion and perpetuation of an ugly
ethno-centric stereotype.


I'm glad you didn't try to describe it as a *unfair* or *unjustified*


I refrained because it would be off-topic and a diversion from my point: 
all bigotry is inappropriate here on this list, including anti-Americanism.


(I actually think raw bigoty is inappropriate everywhere.  While there 
are places to discuss the relative average beauty and niceness of 
various groups of people, this is not one of them.  Even comparisons of 
computer languages is not the main focus of this list.)



stereotype, because (let's face it) after November 8th 2016, that simply
wouldn't fly.


The 'Ugly American' meme is at least 60 years old.  National bigotry is 
as old as nations.


Yesterday, Chris Angelico, I believe it was, asked someone to stop 
including anti-Jew messages in posts here.  So I asked the same of you 
regarding your anti-American expression.



Not all Americans, perhaps not even a majority or a plurality, are Ugly
Americans, but there are enough of them to screw it up for everyone else.


Shall we discuss Ugly Australians, or whatever the appropriate epithet 
would be?



It's an ugly stereotype, not because it is a stereotype, but because it

> embodies a set of ugly attitudes and behaviours.

I am sure I have seen similar things written by various other people 
justifying their prejudices.



--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Text-mode apps (Was :Who are the "spacists"?)

[Gene Heskett]

On Sunday 02 April 2017 12:26:40 Steve D'Aprano wrote:

> On Sun, 2 Apr 2017 04:41 pm, Terry Reedy wrote:
> > On 4/1/2017 12:00 PM, Steve D'Aprano wrote:
> >> example of the Ugly American.
> >
> > As an American I resent your promotion and perpetuation of an ugly
> > ethno-centric stereotype.
>
> I'm glad you didn't try to describe it as a *unfair* or *unjustified*
> stereotype, because (let's face it) after November 8th 2016, that
> simply wouldn't fly.

While I too detest that label, I will have to admit that I am one of the 
conservatives, believing our Constitution and Bill of Rights have been 
used as TP by the "establishment" over the last 65+ years, who enabled 
that surprise.

Wash., DC has been turned into a polluted swamp that needed drained and 
cleaned up, and the Donald was the only one that wasn't part of the same 
old, same old, bull crap establishment, and with enough money to run.

However, I'll be the first to admit I am less than impressed with his 
efforts vis-a-vis global warming. He, I suspect, will be a 1 term 
president unless he starts listening to the technical people's warnings.

I'd also make the prediction that the 2020 winner will _not_ be from the 
establishment. Maybe not even from the two party system. I am hoping 
that this will cause all (surviving) parties to do some navel gazing, 
and contemplating not how to enrich the constituent businesses they own 
under the table, but maybe, actually work for the common good. Taking 
money completely out of the equation would be one way, but you could 
hear the gored oxen that would wound fatally clear out to Pluto, without 
a radio.

Human avarice being what it is, whether I'll live long enough to see that 
happen isn't up to me. At 82, it doesn't look like near as big a chance 
as it did when I was 60.
>
> Not all Americans, perhaps not even a majority or a plurality, are
> Ugly Americans, but there are enough of them to screw it up for
> everyone else.
>
Generally, I try to stay out of the Ugly camp. Then I look in the mirror 
and know its hopeless. :(

[...]

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Text-mode apps (Was :Who are the "spacists"?)

[Steve D'Aprano]

On Sun, 2 Apr 2017 04:41 pm, Terry Reedy wrote:

> On 4/1/2017 12:00 PM, Steve D'Aprano wrote:
> 
>> example of the Ugly American.
> 
> As an American I resent your promotion and perpetuation of an ugly
> ethno-centric stereotype.

I'm glad you didn't try to describe it as a *unfair* or *unjustified*
stereotype, because (let's face it) after November 8th 2016, that simply
wouldn't fly.

Not all Americans, perhaps not even a majority or a plurality, are Ugly
Americans, but there are enough of them to screw it up for everyone else.

It's an ugly stereotype, not because it is a stereotype, but because it
embodies a set of ugly attitudes and behaviours.



-- 
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: Text-mode apps (Was :Who are the "spacists"?)

[Chris Angelico]

On Sun, Apr 2, 2017 at 9:12 PM, bartc  wrote:
> But people, when unrestrained, will /always/ want to do something that may
> not be practical. For example, why bother with the separate concepts
> 'filename' and 'file'; just have the file contents /as/ the filename! If
> there are no limits on how long a filename is or what characters it can
> have, then people will take advantage.
>

This is possible. It's called a "content-based file system", and it's
the basis of tools like git, for example. But it's not the entire
solution; you still need some way to tell a program which blob to
react to.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Text-mode apps (Was :Who are the "spacists"?)

[bartc]

On 01/04/2017 22:35, Marko Rauhamaa wrote:

Chris Angelico :


there is no way within Python to have a string that can represent two
strings, which is what directory separators do.


Really? Try:

   >>> repr(("a", "b"))
   "('a', 'b')"

There! A string that represents two strings.

Note, however, that Python programs generally don't restrict themselves
to expressing objects via strings. There are even objects with no string
representation at all.

A pathname is a list of strings. Python could naturally express it as
just that:

  [ "usr", "bin", "python3" ]


I'm not really proposing any change to the status quo. What's done is
done. However, I do think it is awkward to ban one particular, very
common character while allowing all the rest.


Space is quite common as well, especially in titles of things chosen by 
non-technical users. That also needs special treatment.


There are quite a few other characters with special meanings that people 
might want to use. It's not just stroke.


But people, when unrestrained, will /always/ want to do something that 
may not be practical. For example, why bother with the separate concepts 
'filename' and 'file'; just have the file contents /as/ the filename! If 
there are no limits on how long a filename is or what characters it can 
have, then people will take advantage.


Or they will want to use the full path of one file, as the part of the 
filename of another; is each "/" a separator, or part of the embedded path?


Anyway, I'm sure out of the million unicode characters, there must be 
something that /looks/ like a stroke, but isn't a stroke. Just to add to 
the confusion.



--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Text-mode apps (Was :Who are the "spacists"?)

[Marko Rauhamaa]

Christian Gollwitzer :

> Am 01.04.17 um 19:38 schrieb Steve D'Aprano:
>> Next: convince keyboard manufacturers to move the caret from SHIFT-6
>> to a plain, unshifted key. Buggared if I'm going to hit shift every
>> time I want to use an absolute path...
>
> ...which is reality for a lot more people than you might think. On a
> German keyboard, / is Shift-7. Same for \ {} [] which require
> carpal-tunneling combinations with the right Alt key "Alt Gr".
> Especially bad are shortcutrs like Ctrl+\ which appear in some
> software.

Same with the Finnish keyboard. It's a crime against ergonomy. That's
why I have remapped my keyboard for my personal needs (languages,
programming).


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Text-mode apps (Was :Who are the "spacists"?)

[Christian Gollwitzer]

Am 01.04.17 um 19:38 schrieb Steve D'Aprano:

^home^steve^document.txt


I'm sure I'd get used to it in a few years...

Next: convince keyboard manufacturers to move the caret from SHIFT-6 to a
plain, unshifted key. Buggared if I'm going to hit shift every time I want
to use an absolute path...


...which is reality for a lot more people than you might think. On a 
German keyboard, / is Shift-7. Same for \ {} [] which require 
carpal-tunneling combinations with the right Alt key "Alt Gr". 
Especially bad are shortcutrs like Ctrl+\ which appear in some software.


Christian

--
https://mail.python.org/mailman/listinfo/python-list

Re: Text-mode apps (Was :Who are the "spacists"?)

[Chris Angelico]

On Sun, Apr 2, 2017 at 4:41 PM, Terry Reedy  wrote:
> On 4/1/2017 12:00 PM, Steve D'Aprano wrote:
>
>> example of the Ugly American.
>
>
> As an American I resent your promotion and perpetuation of an ugly
> ethno-centric stereotype.

There are ugly Americans and there are non-ugly Americans. Rick is a
prime example of the former.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Text-mode apps (Was :Who are the "spacists"?)

[Terry Reedy]

On 4/1/2017 12:00 PM, Steve D'Aprano wrote:


example of the Ugly American.


As an American I resent your promotion and perpetuation of an ugly 
ethno-centric stereotype.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Text-mode apps (Was :Who are the "spacists"?)

[Steve D'Aprano]

On Sun, 2 Apr 2017 12:42 pm, Rick Johnson wrote:

> On Saturday, April 1, 2017 at 9:18:14 PM UTC-5, Steve D'Aprano wrote:
> [...]
>> Even India has a literacy rate of 74%, which is not far off
>> the functional literacy rate in the US of 86%.
>>
>> http://www.huffingtonpost.com/2013/09/06/illiteracy-rate_n_3880355.html
> 
> And your source is the HuffPo? Seriously? 

No. My sources are the National Assessment of Adult Literacy, and the U.S.
Department of Education. HuffPo is just the middle man reporting the facts.

Hint: in the HuffPo article, you will see underlined phrases. These are
called "hyperlinks", or just "links", and clicking on some of them will
take you to the original source of the data.



>> The necessary encoding exists. Its called Unicode.
> 
> Great. Now let the evolutionary forces of the free market
> decide if it will live or die. Why do you feel compelled to
> intervene in this natural process?

I'm just as much a part of the "evolutionary forces of the free market" as
you. If you're allowed to complain about people using Unicode and loudly
rant about how its not necessary, I'm allowed to disagree.




-- 
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: Text-mode apps (Was :Who are the "spacists"?)

[Michael Torrie]

On 04/01/2017 08:18 PM, Steve D'Aprano wrote:
>> And yet America continues to be emulated by 100% of the world.
> 
> Well, at least 100% of the world that you know of. Which isn't saying much.

I plonked RR a long time ago, but this little doozie requires a reply!
Having just traveled half way across the globe to two different
continents last month, I can say very clearly that those places do not
wish to or strive to emulate the US.  Especially lately with the
current, unprecedented level of belligerence emanating from its highest
office.  And certainly not in language... The countries I visited are
extremely proud of their languages and cultures.  Anyway, just wow.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Text-mode apps (Was :Who are the "spacists"?)

[Rick Johnson]

On Saturday, April 1, 2017 at 9:18:14 PM UTC-5, Steve D'Aprano wrote:
[...]
> Even India has a literacy rate of 74%, which is not far off
> the functional literacy rate in the US of 86%.
>
> http://www.huffingtonpost.com/2013/09/06/illiteracy-rate_n_3880355.html

And your source is the HuffPo? Seriously? With that in mind,
i think i'll wander on over to the TIOBE index and gawk at
the python position for a while. Gawd knows that google
searches and spam hits are the only true test for judging
the worthiness of programming language.

> The necessary encoding exists. Its called Unicode.

Great. Now let the evolutionary forces of the free market
decide if it will live or die. Why do you feel compelled to
intervene in this natural process?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Text-mode apps (Was :Who are the "spacists"?)

[MRAB]

On 2017-04-02 02:38, Rick Johnson wrote:

On Saturday, April 1, 2017 at 3:08:20 PM UTC-5, Mikhail V wrote:

On 1 April 2017 at 06:38, Rick Johnson  wrote:
> On Thursday, March 30, 2017 at 9:14:54 AM UTC-5, Steve D'Aprano wrote:

> > - and making band names look ǨØØĻ and annoy old fuddy-
> > duddies.
>
> So now we've even included graffiti artists in our little
> "inclusivity project". My, my... we are so _not_ mean!

Lol :)  First we'll wait for Unicode version with table-
drawing character for all possible corner styles and line
weights, and monospaced legible Arabic for Chris' MUDs.


Urm, don't mention MUDs around Chris. That's like a dog
whistle to him. He could go on and on for hours yelping
about them. To be honest, between his MUD ramblings and his
incessant plugging of the Pike language, i don't know which
is worse @_@.

But we tolerate Chris.


[snip]

Sometimes he mentions MUDs, sometimes he mentions Pike, but at least he 
doesn't rant.


--
https://mail.python.org/mailman/listinfo/python-list

Re: Text-mode apps (Was :Who are the "spacists"?)

[Steve D'Aprano]

On Sun, 2 Apr 2017 09:11 am, Rick Johnson wrote:

> The majority of the populations you reference are
> illiterate.

/face-palm

The majority of Chinese and Japanese are illiterate. Really?

Even India has a literacy rate of 74%, which is not far off the functional
literacy rate in the US of 86%.

http://www.huffingtonpost.com/2013/09/06/illiteracy-rate_n_3880355.html

(I know I'm comparing apples with oranges. But when 14% of the adult
population can *effectively* not read, despite being educated in the
wealthiest economy in the world, you don't get to point the finger at
other, poorer, countries and nations for their literacy problems.)


You're entitled to your own opinions, you're not entitled to your own facts.
Until you learn some actual facts, instead of the prejudices and self-
serving ignorance that you are currently operating on, your opinions are
based on fantasy, and you alternate between laughably obnoxious and just
obnoxious.


> Then create whatever encodings you so desire and then STFU about it.

The necessary encoding exists. Its called Unicode.


> Go request an audience from your beloved Queen Mother

My "beloved" Queen Mother? Oh dear, you really don't know me very well.

Besides, the old girl died in 2002.


> And yet America continues to be emulated by 100% of the world.

Well, at least 100% of the world that you know of. Which isn't saying much.



-- 
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: Text-mode apps (Was :Who are the "spacists"?)

[Rick Johnson]

On Saturday, April 1, 2017 at 3:08:20 PM UTC-5, Mikhail V wrote:
> On 1 April 2017 at 06:38, Rick Johnson <rantingrickjohn...@gmail.com> wrote:
> > On Thursday, March 30, 2017 at 9:14:54 AM UTC-5, Steve D'Aprano wrote:
>
> > > - and making band names look ǨØØĻ and annoy old fuddy-
> > > duddies.
> >
> > So now we've even included graffiti artists in our little
> > "inclusivity project". My, my... we are so _not_ mean!
>
> Lol :)  First we'll wait for Unicode version with table-
> drawing character for all possible corner styles and line
> weights, and monospaced legible Arabic for Chris' MUDs.

Urm, don't mention MUDs around Chris. That's like a dog
whistle to him. He could go on and on for hours yelping
about them. To be honest, between his MUD ramblings and his
incessant plugging of the Pike language, i don't know which
is worse @_@.

But we tolerate Chris.

In fact, noticing that Pike is statically typed, i'm
beginning to wonder if Chris may have poured pike oil in
GvR's ear thereby convincing him to introduce type-hints.

Whaddaya got next Chris, braces?

But the more i think about it, the more i realize the _true_
culprit of this type-hints conundrum may just be the Go
language. Sure, Ruby was the "classic foe", however, Ruby
was never a _real_ threat to Python. And not because Ruby
was an inferior language, but because Ruby did not
outshine Python. For both of their natural lives, Ruby and
Python have existed in their own little nitches, and so,
neither became an existential threat to the other. But then,
Google's pet language named "Go" arrived on the scene, and
now we had a statically typed compiled language with many of
the sugary syntactical features and intuitive structural
architecture of Python scripts. Go is basically an evolution
of Python, and when Guido first noticed Go he became
intimidated and then frightened, and so, hastily decided he
had to compete with it. And since he knew that true static
typing would be impossible in Python, he made the compromise
of implementing "type-hints". And so, now the entire
community has been saddled with this type-hints mess, just
because a few of his peers at Google-plex decided to give
Go, well, a go.

Our emotions can be powerful opponents. Sometimes, so
powerful, that even the wise cannot control them. Of course,
this is the same man who proudly claimed (when asked in an
interview if he would take a flight in a aeroplane that was
controlled by a dynamic language such as Python), "Yes!". Of
course, with the caveat that he would be allowed to "write
all the code himself".

But what kind person would make such a foolish claim?

And whether this loose thinking was a matter of overwhelming
emotions or just pure stupidity, has been hotly debated by
many people in community ever since. But, as for me, i don't
think the man is stupid -- no, the Python language stands as
a testament to his intellectual prowess -- however, my
observations have led me to believe that he's unable to
control his emotions. In fact, he is a man ruled by
emotions. His famously foolish and braggadocious claim
exposes a deeply inflated sense of his own abilities brought
to the surface by powerful feelings of superiority over
others. He believes himself infallible. Could this be a
result of malignant narcissism? Megalomania? Possibly all
the above sprinkled lightly with sadistic tendencious? Who
knows...

I'm not sure if our dear leader has conceded to the foolish
nature of his famous "Python Drone Idea", but what i am sure
of, is that the existence of type-hints is evidence of his
emotions (once again!) overriding his rational mind and
causing him to make a poor decision.

Last time it was pride.

This time it is jealously.

What will it be next time?

He is a man who is unable to be humble in the reality of his
own accomplishments, and unable to concede that his
intellectual powers are merely that of a mortal. Powers that
are subject to fallibility and stubborn headedness. Powers
that cannot reach full potential unless they are
supplemented by a strong and open community.

This realization is for me, and many in this fine community,
both sad and terrifying. It is as though we are witnessing a
beloved relative slowly drift away into the clutches of
dementia. Racked with horrific pain and dehumanized by the
embarrassing bouts of incontinence. And we are powerless to
do anything to stop it. And although we'd rather hold our
noses and look away, we cannot. It is a strange irony that
we are forced by a "sense of duty" to become unwilling
spectators to this downward spiral.
-- 
https://mail.python.org/mailman/listinfo/python-list