From benjamin at python.org  Tue May  1 00:09:55 2018
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 30 Apr 2018 21:09:55 -0700
Subject: [RELEASE] Python 2.7.15
Message-ID: <1525147795.1134689.1356448000.51663AA1@webmail.messagingengine.com>

Greetings,
I'm pleased to announce the immediate availability of Python 2.7.15, the latest bug fix release in the senescent Python 2.7 series.

Source and binary downloads may be found on python.org:

     https://www.python.org/downloads/release/python-2715/

Bugs should be reported to https://bugs.python.org/

The source tarball contains a complete changelog in the Misc/NEWS file. The only change since the release candidate is a fix for undefined C behavior that newer compilers (including GCC 8) have started to exploit.

Users of the macOS binaries should note that all python.org macOS installers now ship with a builtin copy of OpenSSL. Additionally, there is a new additional installer variant for macOS 10.9+ that includes a built-in version of Tcl/Tk 8.6. See the installer README for more information.

Happy May,
Benjamin
2.7 release manager


From hasan.diwan at gmail.com  Tue May  1 00:45:17 2018
From: hasan.diwan at gmail.com (Hasan Diwan)
Date: Mon, 30 Apr 2018 21:45:17 -0700
Subject: [Python-Dev] [RELEASE] Python 2.7.15
In-Reply-To: <1525147795.1134689.1356448000.51663AA1@webmail.messagingengine.com>
References: <1525147795.1134689.1356448000.51663AA1@webmail.messagingengine.com>
Message-ID: <CAP+bYWBAo38GW2ptjsmBs=OEbHuxEdksP3qrfdOuV6V633ENHA@mail.gmail.com>

Congrats to all involved! -- H

On 30 April 2018 at 21:09, Benjamin Peterson <benjamin at python.org> wrote:

> Greetings,
> I'm pleased to announce the immediate availability of Python 2.7.15, the
> latest bug fix release in the senescent Python 2.7 series.
>
> Source and binary downloads may be found on python.org:
>
>      https://www.python.org/downloads/release/python-2715/
>
> Bugs should be reported to https://bugs.python.org/
>
> The source tarball contains a complete changelog in the Misc/NEWS file.
> The only change since the release candidate is a fix for undefined C
> behavior that newer compilers (including GCC 8) have started to exploit.
>
> Users of the macOS binaries should note that all python.org macOS
> installers now ship with a builtin copy of OpenSSL. Additionally, there is
> a new additional installer variant for macOS 10.9+ that includes a built-in
> version of Tcl/Tk 8.6. See the installer README for more information.
>
> Happy May,
> Benjamin
> 2.7 release manager
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> hasan.diwan%40gmail.com
>



-- 
OpenPGP:
https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1
If you wish to request my time, please do so using
http://bit.ly/hd1ScheduleRequest.
Si vous voudrais faire connnaisance, allez a
http://bit.ly/hd1ScheduleRequest.

<https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1>Sent
from my mobile device
Envoye de mon portable


From youta.t at gmail.com  Tue May  1 01:20:44 2018
From: youta.t at gmail.com (Youta TAKAOKA)
Date: Tue, 01 May 2018 05:20:44 +0000
Subject: The perils of multiple Pythons
In-Reply-To: <0001HW.20982B1501EAD33814CCE32CF@news.individual.net>
References: <CAPTjJmr62yRN=EvXNp0XrDkPj73Ow2O_ptu9fqk4ePO96KgGFQ@mail.gmail.com>
 <mailman.6.1525108653.2789.python-list@python.org>
 <0001HW.20982B1501EAD33814CCE32CF@news.individual.net>
Message-ID: <CACs-FcB2XRn=NrZaiK=L770qwsVMFVFZzpaOZaSHs3ph2uN8BQ@mail.gmail.com>

I am using pipenv...

http://docs.pipenv.org/en/latest/

It has bootstrap probrem.
pyenv solves it, but windows is NOT a first-class citizen for pyenv.

2018?5?1?(?) 14:00 Percival John Hackworth <pjh at nanoworks.com>:

> On 30-Apr-2018, Chris Angelico wrote
> (in article<mailman.6.1525108653.2789.python-list at python.org>):
>
> > https://xkcd.com/1987/
> >
> > So.... take-away is: On a Mac, just use Homebrew.
> >
> > (Cue the angry hordes telling me how wrong I am.)
> >
> > ChrisA
>
> This comic is talking about python on his Mac installed via home brew.
>
> I chose to keep the 2.[67] versions installed with the base install and
> install the V3 versions from the Python web site. They install in
> /Library/Frameworks/Python.
>
> https://www.python.org/downloads/
>
> I could have also used the 2.7.15 version on that site, but I'll keep with
> the 2.7.10 that's part of the base install of 10.10. I deleted the
> versions
> installed by port and homebrew so all the cruft is gone.
>
> Then I upgraded pip from the ancient version to 10.0.1 using easy_install.
> python3 and and python3.6 are soft links to the /Library/Frameworks
> version.
> My /etc/paths.d/python3 config file adds /Library/Frameworks to the global
> path, but I think that's MacOS specific.
>
> There's more than one way to do this, but it's for a personal machine, not
> a
> global environment that multiple developers will use, so YMMV.
>
> --
> DeeDee, don't press that button! DeeDee! NO! Dee...
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>


From dieter at handshake.de  Tue May  1 02:09:29 2018
From: dieter at handshake.de (dieter)
Date: Tue, 01 May 2018 08:09:29 +0200
Subject: permission denied when installing tensorflow on centos 7
References: <CAN_spzg_xqT2T1Xcirf+cpgycM+rW6bbkjJAus01vka8-WG3wQ@mail.gmail.com>
Message-ID: <87wown29gm.fsf@handshake.de>

joseph pareti <joepareti54 at gmail.com> writes:
> here are details on my attempt:
> ...
> [joepareti54 at xxx tensorflow_tmpdir]$ pip3 install --upgrade virtualenv >>
> step3.txt 2>&1
> [joepareti54 at xxx tensorflow_tmpdir]$ cat step3.txt
> Collecting virtualenv
>   Downloading
> https://files.pythonhosted.org/packages/ed/ea/e20b5cbebf45d3096e8138ab74eda139595d827677f38e9dd543e6015bdf/virtualenv-15.2.0-py2.py3-none-any.whl
> (2.6MB)
> Installing collected packages: virtualenv
> Exception:
> Traceback (most recent call last):
> ...
>   File "/anaconda/envs/py35/lib/python3.5/shutil.py", line 115, in copyfile
>     with open(dst, 'wb') as fdst:
> PermissionError: [Errno 13] Permission denied:
> '/anaconda/envs/py35/lib/python3.5/site-packages/virtualenv.py'

It looks as it would try to overwrite an existing (write protected)
"virtualenv.py". Likely, it should not do that.

You could try to work around this problem by allowing to overwrite
"virtualenv.py" (and maybe other files as well) --> "chmod" command.



From ijaz786besanttech at gmail.com  Tue May  1 05:42:52 2018
From: ijaz786besanttech at gmail.com (ijazz jazz)
Date: Tue, 1 May 2018 02:42:52 -0700 (PDT)
Subject: Python Training in Bangalore
Message-ID: <9ad66a72-ed82-4a37-9207-c351c5c4cdff@googlegroups.com>

Besant Technologies Provides Best Python Training Courses in Marathahalli, BTM Layout , Rajajinagar & Jaya Nagar at Bangalore. We train the students from basic level to advanced concepts with real time environment.

https://www.besanttechnologies.com/training-courses/python-training-institute-in-bangalore


From tritium-list at sdamon.com  Tue May  1 05:58:14 2018
From: tritium-list at sdamon.com (Alex Walters)
Date: Tue, 1 May 2018 05:58:14 -0400
Subject: [Python-Dev] [RELEASE] Python 2.7.15
In-Reply-To: <1525147795.1134689.1356448000.51663AA1@webmail.messagingengine.com>
References: <1525147795.1134689.1356448000.51663AA1@webmail.messagingengine.com>
Message-ID: <4a04a01d3e132$ec45fb20$c4d1f160$@sdamon.com>

I've gotten some mixed signals on the status of this release, notably from
the BDFL:

https://twitter.com/gvanrossum/status/991170064417153025
"Python 2.7.15 released -- the last 2.7 release!" (and a link to this
thread)

I was under the impression that 2.7 was being supported until 2020.  If this
is the final release of 2.7, what would "support" constitute?  My assumption
was that the final release of 2.7 would be sometime in 2020 (or much closer
to 2020 than 19 months).

> -----Original Message-----
> From: Python-Dev <python-dev-bounces+tritium-
> list=sdamon.com at python.org> On Behalf Of Benjamin Peterson
> Sent: Tuesday, May 1, 2018 12:10 AM
> To: python-list at python.org; python-announce at python.org; python-
> dev at python.org
> Subject: [Python-Dev] [RELEASE] Python 2.7.15
> 
> Greetings,
> I'm pleased to announce the immediate availability of Python 2.7.15, the
> latest bug fix release in the senescent Python 2.7 series.
> 
> Source and binary downloads may be found on python.org:
> 
>      https://www.python.org/downloads/release/python-2715/
> 
> Bugs should be reported to https://bugs.python.org/
> 
> The source tarball contains a complete changelog in the Misc/NEWS file.
The
> only change since the release candidate is a fix for undefined C behavior
that
> newer compilers (including GCC 8) have started to exploit.
> 
> Users of the macOS binaries should note that all python.org macOS
installers
> now ship with a builtin copy of OpenSSL. Additionally, there is a new
> additional installer variant for macOS 10.9+ that includes a built-in
version of
> Tcl/Tk 8.6. See the installer README for more information.
> 
> Happy May,
> Benjamin
> 2.7 release manager
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/tritium-
> list%40sdamon.com



From guido at python.org  Tue May  1 10:35:05 2018
From: guido at python.org (Guido van Rossum)
Date: Tue, 1 May 2018 07:35:05 -0700
Subject: [Python-Dev] [RELEASE] Python 2.7.15
In-Reply-To: <4a04a01d3e132$ec45fb20$c4d1f160$@sdamon.com>
References: <1525147795.1134689.1356448000.51663AA1@webmail.messagingengine.com>
 <4a04a01d3e132$ec45fb20$c4d1f160$@sdamon.com>
Message-ID: <CAP7+vJ+wjr+CvDy-ENG2+91HzYHW-dkzUEvqsqKLM9bDoSFMhw@mail.gmail.com>

Simple. I misread "latest" for "last" and was hopeful that no new bugs
would need to be fixed between now and 2020. I will post a correction on
Twitter now.

On Tue, May 1, 2018 at 2:58 AM, Alex Walters <tritium-list at sdamon.com>
wrote:

> I've gotten some mixed signals on the status of this release, notably from
> the BDFL:
>
> https://twitter.com/gvanrossum/status/991170064417153025
> "Python 2.7.15 released -- the last 2.7 release!" (and a link to this
> thread)
>
> I was under the impression that 2.7 was being supported until 2020.  If
> this
> is the final release of 2.7, what would "support" constitute?  My
> assumption
> was that the final release of 2.7 would be sometime in 2020 (or much closer
> to 2020 than 19 months).
>
> > -----Original Message-----
> > From: Python-Dev <python-dev-bounces+tritium-
> > list=sdamon.com at python.org> On Behalf Of Benjamin Peterson
> > Sent: Tuesday, May 1, 2018 12:10 AM
> > To: python-list at python.org; python-announce at python.org; python-
> > dev at python.org
> > Subject: [Python-Dev] [RELEASE] Python 2.7.15
> >
> > Greetings,
> > I'm pleased to announce the immediate availability of Python 2.7.15, the
> > latest bug fix release in the senescent Python 2.7 series.
> >
> > Source and binary downloads may be found on python.org:
> >
> >      https://www.python.org/downloads/release/python-2715/
> >
> > Bugs should be reported to https://bugs.python.org/
> >
> > The source tarball contains a complete changelog in the Misc/NEWS file.
> The
> > only change since the release candidate is a fix for undefined C behavior
> that
> > newer compilers (including GCC 8) have started to exploit.
> >
> > Users of the macOS binaries should note that all python.org macOS
> installers
> > now ship with a builtin copy of OpenSSL. Additionally, there is a new
> > additional installer variant for macOS 10.9+ that includes a built-in
> version of
> > Tcl/Tk 8.6. See the installer README for more information.
> >
> > Happy May,
> > Benjamin
> > 2.7 release manager
> > _______________________________________________
> > Python-Dev mailing list
> > Python-Dev at python.org
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe: https://mail.python.org/mailman/options/python-dev/tritium-
> > list%40sdamon.com
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)


From bill at baddogconsulting.com  Tue May  1 11:00:12 2018
From: bill at baddogconsulting.com (Bill Deegan)
Date: Tue, 1 May 2018 11:00:12 -0400
Subject: [Python-Dev] [RELEASE] Python 2.7.15
In-Reply-To: <CAP7+vJ+wjr+CvDy-ENG2+91HzYHW-dkzUEvqsqKLM9bDoSFMhw@mail.gmail.com>
References: <1525147795.1134689.1356448000.51663AA1@webmail.messagingengine.com>
 <4a04a01d3e132$ec45fb20$c4d1f160$@sdamon.com>
 <CAP7+vJ+wjr+CvDy-ENG2+91HzYHW-dkzUEvqsqKLM9bDoSFMhw@mail.gmail.com>
Message-ID: <CAEyG4CH1Q4+87mWDBOYqrE=wyZO5Z3e9z6T7YzGJax04V+uC+w@mail.gmail.com>

Is it possible to get the release notes included on the download page(s)?

On Tue, May 1, 2018 at 10:35 AM, Guido van Rossum <guido at python.org> wrote:

> Simple. I misread "latest" for "last" and was hopeful that no new bugs
> would need to be fixed between now and 2020. I will post a correction on
> Twitter now.
>
> On Tue, May 1, 2018 at 2:58 AM, Alex Walters <tritium-list at sdamon.com>
> wrote:
>
> > I've gotten some mixed signals on the status of this release, notably
> from
> > the BDFL:
> >
> > https://twitter.com/gvanrossum/status/991170064417153025
> > "Python 2.7.15 released -- the last 2.7 release!" (and a link to this
> > thread)
> >
> > I was under the impression that 2.7 was being supported until 2020.  If
> > this
> > is the final release of 2.7, what would "support" constitute?  My
> > assumption
> > was that the final release of 2.7 would be sometime in 2020 (or much
> closer
> > to 2020 than 19 months).
> >
> > > -----Original Message-----
> > > From: Python-Dev <python-dev-bounces+tritium-
> > > list=sdamon.com at python.org> On Behalf Of Benjamin Peterson
> > > Sent: Tuesday, May 1, 2018 12:10 AM
> > > To: python-list at python.org; python-announce at python.org; python-
> > > dev at python.org
> > > Subject: [Python-Dev] [RELEASE] Python 2.7.15
> > >
> > > Greetings,
> > > I'm pleased to announce the immediate availability of Python 2.7.15,
> the
> > > latest bug fix release in the senescent Python 2.7 series.
> > >
> > > Source and binary downloads may be found on python.org:
> > >
> > >      https://www.python.org/downloads/release/python-2715/
> > >
> > > Bugs should be reported to https://bugs.python.org/
> > >
> > > The source tarball contains a complete changelog in the Misc/NEWS file.
> > The
> > > only change since the release candidate is a fix for undefined C
> behavior
> > that
> > > newer compilers (including GCC 8) have started to exploit.
> > >
> > > Users of the macOS binaries should note that all python.org macOS
> > installers
> > > now ship with a builtin copy of OpenSSL. Additionally, there is a new
> > > additional installer variant for macOS 10.9+ that includes a built-in
> > version of
> > > Tcl/Tk 8.6. See the installer README for more information.
> > >
> > > Happy May,
> > > Benjamin
> > > 2.7 release manager
> > > _______________________________________________
> > > Python-Dev mailing list
> > > Python-Dev at python.org
> > > https://mail.python.org/mailman/listinfo/python-dev
> > > Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> tritium-
> > > list%40sdamon.com
> >
> > _______________________________________________
> > Python-Dev mailing list
> > Python-Dev at python.org
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> > guido%40python.org
> >
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> --
> https://mail.python.org/mailman/listinfo/python-list
>


From rshepard at appl-ecosys.com  Tue May  1 12:06:31 2018
From: rshepard at appl-ecosys.com (Rich Shepard)
Date: Tue, 1 May 2018 09:06:31 -0700 (PDT)
Subject: venv: make installed modules visible
Message-ID: <alpine.LNX.2.20.1805010900030.3539@salmo.appl-ecosys.com>

   Activating venv and trying to run the project Python tells me it cannot
find the wxPython4 modules:

Traceback (most recent call last):
   File "./openEDMS.py", line 12, in <module>
     import wx
ModuleNotFoundError: No module named 'wx'

   I've read the Python3 venv standard library doc page (section 28.3)
without seeing how to make installed modules (such as wxPython, psycopg2,
and SQLAlchemy visible in the virtual environment. I suspect that EnvBuilder
is involved but I'm not seeing how to apply this class ... if that's how
modules are made visible in the venv.

   A clue is needed.

Rich


From p.f.moore at gmail.com  Tue May  1 13:13:20 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 1 May 2018 18:13:20 +0100
Subject: venv: make installed modules visible
In-Reply-To: <alpine.LNX.2.20.1805010900030.3539@salmo.appl-ecosys.com>
References: <alpine.LNX.2.20.1805010900030.3539@salmo.appl-ecosys.com>
Message-ID: <CACac1F-_5FUhc0_9Ji=SPv7HBkBkzESP_Pk6-508qNXjp=LtGQ@mail.gmail.com>

On 1 May 2018 at 17:06, Rich Shepard <rshepard at appl-ecosys.com> wrote:
>   Activating venv and trying to run the project Python tells me it cannot
> find the wxPython4 modules:
>
> Traceback (most recent call last):
>   File "./openEDMS.py", line 12, in <module>
>     import wx
> ModuleNotFoundError: No module named 'wx'
>
>   I've read the Python3 venv standard library doc page (section 28.3)
> without seeing how to make installed modules (such as wxPython, psycopg2,
> and SQLAlchemy visible in the virtual environment. I suspect that EnvBuilder
> is involved but I'm not seeing how to apply this class ... if that's how
> modules are made visible in the venv.
>
>   A clue is needed.

Maybe you need  --system-site-packages?

Paul


From phennings at gmail.com  Tue May  1 13:28:06 2018
From: phennings at gmail.com (phennings at gmail.com)
Date: Tue, 1 May 2018 10:28:06 -0700 (PDT)
Subject: Python 2.7.15 Windows MSI removes previous 2.7.x binaries?
Message-ID: <4bfc19e2-6777-449a-bf7f-32c16a3a54c3@googlegroups.com>

I downloaded the 64-bit Windows MSI for Python 2.7.15 and upon finishing the installation, I noted that prior Python installs had effectively been removed, only leaving a Lib and Scripts folder in the directory to which said prior version had been installed.  For what it's worth, it appears this is only true if I install for 'All users' rather than for 'just this user'.

I can't find anything in the release notes, docs or on this mailing list that describes the motivation for doing this.  I personally find that having multiple versions installed on Windows is very helpful for being able to target distribution version for the purposes of constructing virtualenvs.

Can anyone say whether this is intended behavior?


From p.f.moore at gmail.com  Tue May  1 13:48:48 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 1 May 2018 18:48:48 +0100
Subject: Python 2.7.15 Windows MSI removes previous 2.7.x binaries?
In-Reply-To: <4bfc19e2-6777-449a-bf7f-32c16a3a54c3@googlegroups.com>
References: <4bfc19e2-6777-449a-bf7f-32c16a3a54c3@googlegroups.com>
Message-ID: <CACac1F_EbUOLki7kvB+pA9193X160_C0u=Hu1K0_K-gEU43wTw@mail.gmail.com>

It's intended behaviour (to my knowledge). Or at least, we don't
intend for people to install two different patch versions in parallel
(at least not with the official installers). I thought this behaviour
was always the case. It may be related to the installer technology
involved, though, so it may have changed when we switched to wix.

You're right it doesn't seem like the details are well documented. It
might be worth raising a docs bug on bugs.python.org asking for the
details to be clarified.
Paul

On 1 May 2018 at 18:28,  <phennings at gmail.com> wrote:
> I downloaded the 64-bit Windows MSI for Python 2.7.15 and upon finishing the installation, I noted that prior Python installs had effectively been removed, only leaving a Lib and Scripts folder in the directory to which said prior version had been installed.  For what it's worth, it appears this is only true if I install for 'All users' rather than for 'just this user'.
>
> I can't find anything in the release notes, docs or on this mailing list that describes the motivation for doing this.  I personally find that having multiple versions installed on Windows is very helpful for being able to target distribution version for the purposes of constructing virtualenvs.
>
> Can anyone say whether this is intended behavior?
> --
> https://mail.python.org/mailman/listinfo/python-list


From tmrsg11 at gmail.com  Tue May  1 13:57:54 2018
From: tmrsg11 at gmail.com (C W)
Date: Tue, 1 May 2018 13:57:54 -0400
Subject: In numpy, why is it ok to do matrix.mean(),
 but not ok to do matrix.median()?
Message-ID: <CAE2FW2=+mxDDHD7mjboveKLBWHELYRos8vi5tQmgEDnpuKoyLQ@mail.gmail.com>

Hello everyone,

In numpy, why is it ok to do matrix.mean(), but not ok to do
matrix.median()? To me, they are two of many summary statistics. So, why
median() is different?

Here's an example code,

import numpy as np
matrix = np.array([[1, 2, 3], [4, 5, 6], [7, 8, 9]])

# find the mean
np.mean(matrix)      # ok
matrix.mean()          # ok

# find the median
np.median(matrixA)  # ok
matrix.median()        # throws error message


Also, why have two of the same thing: np.mean(matrix) and matrix.mean()?
When to use which one?

The documentation below looks almost identical! What am I missing here?
[1] Median documentation:
https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.median.html
[2] Mean documentation:
https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.mean.html


Thank you so much,

M


From elchino at cnn.cn  Tue May  1 14:27:24 2018
From: elchino at cnn.cn (ElChino)
Date: Tue, 1 May 2018 20:27:24 +0200
Subject: Todays XKCD
Message-ID: <pcabic$fhu$1@dont-email.me>

Spot on!

https://imgs.xkcd.com/comics/python_environment.png
https://xkcd.com/1987/


From rshepard at appl-ecosys.com  Tue May  1 14:33:51 2018
From: rshepard at appl-ecosys.com (Rich Shepard)
Date: Tue, 1 May 2018 11:33:51 -0700 (PDT)
Subject: venv: make installed modules visible
In-Reply-To: <CACac1F-_5FUhc0_9Ji=SPv7HBkBkzESP_Pk6-508qNXjp=LtGQ@mail.gmail.com>
References: <alpine.LNX.2.20.1805010900030.3539@salmo.appl-ecosys.com>
 <CACac1F-_5FUhc0_9Ji=SPv7HBkBkzESP_Pk6-508qNXjp=LtGQ@mail.gmail.com>
Message-ID: <alpine.LNX.2.20.1805011132270.3539@salmo.appl-ecosys.com>

On Tue, 1 May 2018, Paul Moore wrote:

> Maybe you need  --system-site-packages?

Paul,

   Thank you. I changed pyvenv.cfg to 'include-system-site-packages = true'.

Regards,

Rich


From rshepard at appl-ecosys.com  Tue May  1 14:39:43 2018
From: rshepard at appl-ecosys.com (Rich Shepard)
Date: Tue, 1 May 2018 11:39:43 -0700 (PDT)
Subject: venv: make installed modules visible
In-Reply-To: <589hed5srq1o7ftgh63vb4rdhjoudh2j76@4ax.com>
References: <alpine.LNX.2.20.1805010900030.3539@salmo.appl-ecosys.com>
 <589hed5srq1o7ftgh63vb4rdhjoudh2j76@4ax.com>
Message-ID: <alpine.LNX.2.20.1805011139100.3539@salmo.appl-ecosys.com>

On Tue, 1 May 2018, Dennis Lee Bieber wrote:

> 	Did you miss:

Dennis,

   Yes, I did.

Mea culpa,

Rich


From tjreedy at udel.edu  Tue May  1 14:42:34 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 1 May 2018 14:42:34 -0400
Subject: Python 2.7.15 Windows MSI removes previous 2.7.x binaries?
In-Reply-To: <CACac1F_EbUOLki7kvB+pA9193X160_C0u=Hu1K0_K-gEU43wTw@mail.gmail.com>
References: <4bfc19e2-6777-449a-bf7f-32c16a3a54c3@googlegroups.com>
 <CACac1F_EbUOLki7kvB+pA9193X160_C0u=Hu1K0_K-gEU43wTw@mail.gmail.com>
Message-ID: <pcacao$iph$1@blaine.gmane.org>

On 5/1/2018 1:48 PM, Paul Moore wrote:
> It's intended behaviour (to my knowledge). Or at least, we don't
> intend for people to install two different patch versions in parallel
> (at least not with the official installers). I thought this behaviour
> was always the case. It may be related to the installer technology
> involved, though, so it may have changed when we switched to wix.
> 
> You're right it doesn't seem like the details are well documented. It
> might be worth raising a docs bug on bugs.python.org asking for the
> details to be clarified.
> Paul
> 
> On 1 May 2018 at 18:28,  <phennings at gmail.com> wrote:
>> I downloaded the 64-bit Windows MSI for Python 2.7.15 and upon finishing the installation, I noted that prior Python installs had effectively been removed, only leaving a Lib and Scripts folder in the directory to which said prior version had been installed.  For what it's worth, it appears this is only true if I install for 'All users' rather than for 'just this user'.

I believe the installer warns that it overwrites previous releases of 
the same x.y version.

>> I can't find anything in the release notes, docs or on this mailing list that describes the motivation for doing this.  I personally find that having multiple versions installed on Windows is very helpful for being able to target distribution version for the purposes of constructing virtualenvs.
>>
>> Can anyone say whether this is intended behavior?
>> --
>> https://mail.python.org/mailman/listinfo/python-list


-- 
Terry Jan Reedy



From kwpolska at gmail.com  Tue May  1 15:19:34 2018
From: kwpolska at gmail.com (Chris Warrick)
Date: Tue, 01 May 2018 19:19:34 +0000
Subject: venv: make installed modules visible
In-Reply-To: <CACac1F-_5FUhc0_9Ji=SPv7HBkBkzESP_Pk6-508qNXjp=LtGQ@mail.gmail.com>
References: <alpine.LNX.2.20.1805010900030.3539@salmo.appl-ecosys.com>
 <CACac1F-_5FUhc0_9Ji=SPv7HBkBkzESP_Pk6-508qNXjp=LtGQ@mail.gmail.com>
Message-ID: <CAMw+j7KrfirL8r6bDnyy0UEF7FWQrcw0EmW6182SLp8M5uvraA@mail.gmail.com>

On Tue, 1 May 2018 at 19:15, Paul Moore <p.f.moore at gmail.com> wrote:
> Maybe you need  --system-site-packages?

DO NOT use this option. The entire point of a virtualenv is to be separate
from both other environments and the system Python site-packages.

The correct way to handle this is to install the modules using the
virtualenv?s pip.

-- 
Chris Warrick <https://chriswarrick.com/>
PGP: 5EAAEA16


From tjol at tjol.eu  Tue May  1 15:38:31 2018
From: tjol at tjol.eu (Thomas Jollans)
Date: Tue, 1 May 2018 21:38:31 +0200
Subject: In numpy, why is it ok to do matrix.mean(), but not ok to do
 matrix.median()?
In-Reply-To: <CAE2FW2=+mxDDHD7mjboveKLBWHELYRos8vi5tQmgEDnpuKoyLQ@mail.gmail.com>
References: <CAE2FW2=+mxDDHD7mjboveKLBWHELYRos8vi5tQmgEDnpuKoyLQ@mail.gmail.com>
Message-ID: <eb8d116d-e2bc-93dd-bb29-a1c66bb91558@tjol.eu>

On 01/05/18 19:57, C W wrote:
> matrix.median()        # throws error message

READ error messages. At the very least, quote error messages when asking
questions somewhere like here. There I was, wondering why the numpy docs
didn't mention ndarray.median when you were clearly using it...

Anyway,

> Hello everyone,
> 
> In numpy, why is it ok to do matrix.mean(), but not ok to do
> matrix.median()? To me, they are two of many summary statistics. So, why
> median() is different?

First, this is how it's different: the method ndarray.median simply does
not exist.

Now, of course, most numpy functions don't have method versions, so
there's nothing special about median here. However, as you quite rightly
point out, median would be "a good fit".

As with most things that are "a bit odd" about numpy this probably boils
to "historical reasons".

numpy mostly goes back to an earlier package called "Numeric". Numeric's
array did not have methods like mean(). Early (anno 2005) numpy also
incorporated features from a package called "numarray"; one of these
features were array methods like ".mean". numarray did not have a
.median method, though it *did* have a function numarray.mlab.median. So
far, so good. ndarray.mean *must* exist for compatibility reasons,
ndarray.median need not.

So why not add it later? Other methods have been added, after all. Well,
for starters, "who cares?". Most of numpy is functions; the methods are
nice, but not that important. The other obstacle is that numpy.median is
implemented in Python, not in C. For historical reasons?, it has to stay
that way. They tried to change it in 2014, but that broke some other
packages...


> 
> Here's an example code,
> 
> import numpy as np
> matrix = np.array([[1, 2, 3], [4, 5, 6], [7, 8, 9]])
> 
> # find the mean
> np.mean(matrix)      # ok
> matrix.mean()          # ok
> 
> # find the median
> np.median(matrixA)  # ok

> 
> 
> Also, why have two of the same thing: np.mean(matrix) and matrix.mean()?
> When to use which one?
> 
> The documentation below looks almost identical! What am I missing here?
> [1] Median documentation:
> https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.median.html
> [2] Mean documentation:
> https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.mean.html
> 
> 
> Thank you so much,
> 
> M
> 



From tmrsg11 at gmail.com  Tue May  1 22:22:51 2018
From: tmrsg11 at gmail.com (C W)
Date: Tue, 1 May 2018 22:22:51 -0400
Subject: In numpy, why is it ok to do matrix.mean(),
 but not ok to do matrix.median()?
In-Reply-To: <eb8d116d-e2bc-93dd-bb29-a1c66bb91558@tjol.eu>
References: <CAE2FW2=+mxDDHD7mjboveKLBWHELYRos8vi5tQmgEDnpuKoyLQ@mail.gmail.com>
 <eb8d116d-e2bc-93dd-bb29-a1c66bb91558@tjol.eu>
Message-ID: <CAE2FW2mbZpk0=HTgowvh8J4CRsaJMP2b8LBPupjvRLkyH5vimQ@mail.gmail.com>

It's interesting how mean() can be implemented, but median() will break
other packages.

So, the default way in numpy is to use functions, not methods?

When I first learned Python, I was told to create an object and to play
around, there are methods for that object. List has list methods, tuple has
tuple methods, etc.

Now, the default way in numpy is to use function instead of methods? I'm
confused. What happened to object-oriented programming?

Thanks,

-M




On Tue, May 1, 2018 at 3:38 PM, Thomas Jollans <tjol at tjol.eu> wrote:

> On 01/05/18 19:57, C W wrote:
> > matrix.median()        # throws error message
>
> READ error messages. At the very least, quote error messages when asking
> questions somewhere like here. There I was, wondering why the numpy docs
> didn't mention ndarray.median when you were clearly using it...
>
> Anyway,
>
> > Hello everyone,
> >
> > In numpy, why is it ok to do matrix.mean(), but not ok to do
> > matrix.median()? To me, they are two of many summary statistics. So, why
> > median() is different?
>
> First, this is how it's different: the method ndarray.median simply does
> not exist.
>
> Now, of course, most numpy functions don't have method versions, so
> there's nothing special about median here. However, as you quite rightly
> point out, median would be "a good fit".
>
> As with most things that are "a bit odd" about numpy this probably boils
> to "historical reasons".
>
> numpy mostly goes back to an earlier package called "Numeric". Numeric's
> array did not have methods like mean(). Early (anno 2005) numpy also
> incorporated features from a package called "numarray"; one of these
> features were array methods like ".mean". numarray did not have a
> .median method, though it *did* have a function numarray.mlab.median. So
> far, so good. ndarray.mean *must* exist for compatibility reasons,
> ndarray.median need not.
>
> So why not add it later? Other methods have been added, after all. Well,
> for starters, "who cares?". Most of numpy is functions; the methods are
> nice, but not that important. The other obstacle is that numpy.median is
> implemented in Python, not in C. For historical reasons?, it has to stay
> that way. They tried to change it in 2014, but that broke some other
> packages...
>
>
> >
> > Here's an example code,
> >
> > import numpy as np
> > matrix = np.array([[1, 2, 3], [4, 5, 6], [7, 8, 9]])
> >
> > # find the mean
> > np.mean(matrix)      # ok
> > matrix.mean()          # ok
> >
> > # find the median
> > np.median(matrixA)  # ok
>
> >
> >
> > Also, why have two of the same thing: np.mean(matrix) and matrix.mean()?
> > When to use which one?
> >
> > The documentation below looks almost identical! What am I missing here?
> > [1] Median documentation:
> > https://docs.scipy.org/doc/numpy-1.14.0/reference/
> generated/numpy.median.html
> > [2] Mean documentation:
> > https://docs.scipy.org/doc/numpy-1.14.0/reference/
> generated/numpy.mean.html
> >
> >
> > Thank you so much,
> >
> > M
> >
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>


From rosuav at gmail.com  Tue May  1 22:37:12 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 2 May 2018 12:37:12 +1000
Subject: In numpy, why is it ok to do matrix.mean(),
 but not ok to do matrix.median()?
In-Reply-To: <CAE2FW2mbZpk0=HTgowvh8J4CRsaJMP2b8LBPupjvRLkyH5vimQ@mail.gmail.com>
References: <CAE2FW2=+mxDDHD7mjboveKLBWHELYRos8vi5tQmgEDnpuKoyLQ@mail.gmail.com>
 <eb8d116d-e2bc-93dd-bb29-a1c66bb91558@tjol.eu>
 <CAE2FW2mbZpk0=HTgowvh8J4CRsaJMP2b8LBPupjvRLkyH5vimQ@mail.gmail.com>
Message-ID: <CAPTjJmo=pgMOTW+HThgmv_cNaKcLVmpHU6sYO9tH9HFndaB3Ow@mail.gmail.com>

On Wed, May 2, 2018 at 12:22 PM, C W <tmrsg11 at gmail.com> wrote:
> It's interesting how mean() can be implemented, but median() will break
> other packages.
>
> So, the default way in numpy is to use functions, not methods?
>
> When I first learned Python, I was told to create an object and to play
> around, there are methods for that object. List has list methods, tuple has
> tuple methods, etc.
>
> Now, the default way in numpy is to use function instead of methods? I'm
> confused. What happened to object-oriented programming?

Even outside of numpy, a lot of Python uses functions, not methods.
One good reason for this is that a function can accept a wide variety
of data types as its argument; for instance, len() accepts many
things, not just lists. Some things are done with methods, others with
stand-alone functions. There are design choices each way.

ChrisA


From chris at withers.org  Wed May  2 03:13:39 2018
From: chris at withers.org (Chris Withers)
Date: Wed, 2 May 2018 08:13:39 +0100
Subject: testfixtures 6.0.2 released - important bug fix!
Message-ID: <5b830e40-0714-7aeb-8c0d-4aafbe74fa67@withers.org>

Hi All,

I'm afraid I've found quite a serious regression in the 6.x series of 
testfixtures releases:

Objects that had neither __dict__ nor __slots__ would always be 
considered equal by compare().
I hit this comparing datetimes, but this would also affect types 
provides by extensions in other languages such as C or C++.
This did not affect built-in types such as dict, set, tuple and list as 
they have specific comparers provided that were not affects.

I've released 6.0.2 to fix this and would urge anyone using 6.0.0 or 
6.0.1 to upgrade as soon as possible.

The package is on PyPI and a full list of all the links to docs, issue 
trackers and the like can be found here:

https://github.com/Simplistix/testfixtures

Any questions, please do ask on the Testing in Python list or on the 
Simplistix open source mailing list...

cheers,

Chris


From zljubisic at gmail.com  Wed May  2 06:24:23 2018
From: zljubisic at gmail.com (zljubisic at gmail.com)
Date: Wed, 2 May 2018 03:24:23 -0700 (PDT)
Subject: Passing all pandas DataFrame columns to function as separate
 parameters
In-Reply-To: <mailman.25.1524838777.19235.python-list@python.org>
References: <477a8f26-fbcb-449b-bdd5-1a54573ba1de@googlegroups.com>
 <3ed51a3f-d90f-a16d-aca1-d8bf682aa1cf@tjol.eu>
 <mailman.25.1524838777.19235.python-list@python.org>
Message-ID: <7399e771-5f05-4f37-b8f8-450168cef150@googlegroups.com>

Thomas, thank you very very much, this was exactly what I needed.
Thanks again and best regards.


From jorge.conrado at cptec.inpe.br  Wed May  2 10:08:40 2018
From: jorge.conrado at cptec.inpe.br (jorge.conrado at cptec.inpe.br)
Date: Wed, 02 May 2018 11:08:40 -0300
Subject: Masking using shapefiles
Message-ID: <a33e146003023441ff0ddda9571d462c@cptec.inpe.br>



  Hi,

  I'm trying to make a mask using a shapefile of Brazil using the 
examplE:

  http://basemaptutorial.readthedocs.io/en/latest/clip.html


  I run my script and I had the messages:

  Traceback (most recent call last):
   File "mascarapy2.py", line 7, in <module>
     from osgeo import gdal
   File 
"/home/conrado/anaconda3/lib/python2.7/site-packages/osgeo/__init__.py", 
line 21, in <module>
     _gdal = swig_import_helper()
   File 
"/home/conrado/anaconda3/lib/python2.7/site-packages/osgeo/__init__.py", 
line 17, in swig_import_helper
     _mod = imp.load_module('_gdal', fp, pathname, description)
ImportError: 
/home/conrado/anaconda3/lib/python2.7/site-packages/osgeo/../../.././libkea.so.1.4.7: 
undefined symbol: 
_ZN2H56H5FileC1ERKSsjRKNS_17FileCreatPropListERKNS_15FileAccPropListE


    Please, what can I do to solve this.

    Thanks,

    Conrado


From nad at python.org  Wed May  2 20:16:25 2018
From: nad at python.org (Ned Deily)
Date: Wed, 2 May 2018 20:16:25 -0400
Subject: [RELEASE] Python 3.7.0b4, final 3.7 beta, now available for testing
Message-ID: <82F6CAB9-4144-4937-B73B-914AD6518173@python.org>

Python 3.7.0b4 is the final beta preview of Python 3.7, the next feature
release of Python. Beta releases are intended to give you the
opportunity to test new features and bug fixes and to prepare your
projects to support the new feature release. We strongly encourage you
to test your projects with 3.7 during the beta phase and report issues
found to bugs.python.org as soon as possible. While the release is
feature complete entering the beta phase, it is possible that features
may be modified or, in rare cases, deleted up until the start of the
release candidate phase. Please keep in mind that this is a preview
release and its use is not recommended for production environments.
Attention macOS users: there is now a new installer variant for macOS
10.9+ that includes a built-in version of Tcl/Tk 8.6. This variant is
expected to become the default version when 3.7.0 releases. Check it out!

The next preview release will be the release candidate and is planned
for 2018-05-21 followed by the official release of 3.7.0, planned for
2018-06-15. You can find Python 3.7.0b4 and more information here:

https://www.python.org/downloads/release/python-370b4/

--
  Ned Deily
  nad at python.org -- []



From tmrsg11 at gmail.com  Wed May  2 20:39:48 2018
From: tmrsg11 at gmail.com (C W)
Date: Wed, 2 May 2018 20:39:48 -0400
Subject: In numpy, why is it ok to do matrix.mean(),
 but not ok to do matrix.median()?
In-Reply-To: <CAPTjJmo=pgMOTW+HThgmv_cNaKcLVmpHU6sYO9tH9HFndaB3Ow@mail.gmail.com>
References: <CAE2FW2=+mxDDHD7mjboveKLBWHELYRos8vi5tQmgEDnpuKoyLQ@mail.gmail.com>
 <eb8d116d-e2bc-93dd-bb29-a1c66bb91558@tjol.eu>
 <CAE2FW2mbZpk0=HTgowvh8J4CRsaJMP2b8LBPupjvRLkyH5vimQ@mail.gmail.com>
 <CAPTjJmo=pgMOTW+HThgmv_cNaKcLVmpHU6sYO9tH9HFndaB3Ow@mail.gmail.com>
Message-ID: <CAE2FW2mMnG-jqMPQ7PRi=3p32S67ErhLQEmRtyhiC_Ln5RogBg@mail.gmail.com>

Thanks, Chris. That makes sense. The len() example is great!

On Tue, May 1, 2018 at 10:37 PM, Chris Angelico <rosuav at gmail.com> wrote:

> On Wed, May 2, 2018 at 12:22 PM, C W <tmrsg11 at gmail.com> wrote:
> > It's interesting how mean() can be implemented, but median() will break
> > other packages.
> >
> > So, the default way in numpy is to use functions, not methods?
> >
> > When I first learned Python, I was told to create an object and to play
> > around, there are methods for that object. List has list methods, tuple
> has
> > tuple methods, etc.
> >
> > Now, the default way in numpy is to use function instead of methods? I'm
> > confused. What happened to object-oriented programming?
>
> Even outside of numpy, a lot of Python uses functions, not methods.
> One good reason for this is that a function can accept a wide variety
> of data types as its argument; for instance, len() accepts many
> things, not just lists. Some things are done with methods, others with
> stand-alone functions. There are design choices each way.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>


From mahanamad at gmail.com  Wed May  2 23:28:53 2018
From: mahanamad at gmail.com (Maha)
Date: Wed, 2 May 2018 20:28:53 -0700 (PDT)
Subject: pyOpt Error on Tutorial 1
Message-ID: <68100548-e9b9-4f39-b357-e478cef51960@googlegroups.com>

I am trying to run pyOpt tutorial located at http://www.pyopt.org/tutorial.html.
It will display the Objective function but the line
slsqp = pyOpt.SLSQP()
gives the following error.
AttributeError: 'module' object has no attribute 'SLSQP'

It is installed on the following folder
C:\Python27\pyOpt-1.2.0\pyOpt\pySLSQP

could you please tell me why this is not available in the environment. 


From joepareti54 at gmail.com  Thu May  3 09:06:48 2018
From: joepareti54 at gmail.com (joseph pareti)
Date: Thu, 3 May 2018 15:06:48 +0200
Subject: syntax error (?) on ubuntu
Message-ID: <CAN_spzjUo=xCHrxhiNApLmPR1+2faExGtR-1Z0EnVKoQzSixEg@mail.gmail.com>

$ python tf_simple.py

/anaconda/envs/py35/lib/python3.5/site-packages/h5py/__init__.py:36:
FutureWarning: Conversion of the second argument of issubdtype from `float`
to `np.floating` is deprecated. In future, it will be treated as
`np.float64 == np.dtype(float).type`.
  from ._conv import register_converters as _register_converters
Traceback (most recent call last):
  File "tf_simple.py", line 29, in <module>
    import uniio
  File "../tools/uniio.py", line 132
    if(PY3K): ID = ID.decode("utf-8")
                                     ^
TabError: inconsistent use of tabs and spaces in indentation


From joel.goldstick at gmail.com  Thu May  3 09:11:15 2018
From: joel.goldstick at gmail.com (Joel Goldstick)
Date: Thu, 3 May 2018 09:11:15 -0400
Subject: syntax error (?) on ubuntu
In-Reply-To: <CAN_spzjUo=xCHrxhiNApLmPR1+2faExGtR-1Z0EnVKoQzSixEg@mail.gmail.com>
References: <CAN_spzjUo=xCHrxhiNApLmPR1+2faExGtR-1Z0EnVKoQzSixEg@mail.gmail.com>
Message-ID: <CAPM-O+wYMRwphg9LAoWTpT5Pp1QeRMVwunpPxyhPvRB=S5iXSg@mail.gmail.com>

On Thu, May 3, 2018 at 9:06 AM, joseph pareti <joepareti54 at gmail.com> wrote:
> $ python tf_simple.py
>
> /anaconda/envs/py35/lib/python3.5/site-packages/h5py/__init__.py:36:
> FutureWarning: Conversion of the second argument of issubdtype from `float`
> to `np.floating` is deprecated. In future, it will be treated as
> `np.float64 == np.dtype(float).type`.
>   from ._conv import register_converters as _register_converters
> Traceback (most recent call last):
>   File "tf_simple.py", line 29, in <module>
>     import uniio
>   File "../tools/uniio.py", line 132
>     if(PY3K): ID = ID.decode("utf-8")
>                                      ^
> TabError: inconsistent use of tabs and spaces in indentation
> --
> https://mail.python.org/mailman/listinfo/python-list

Check to see if you have a tab after the colon in the last line.  You
must use colons or spaces, but not both

-- 
Joel Goldstick
http://joelgoldstick.com/blog
http://cc-baseballstats.info/stats/birthdays


From joepareti54 at gmail.com  Thu May  3 11:53:20 2018
From: joepareti54 at gmail.com (joseph pareti)
Date: Thu, 3 May 2018 17:53:20 +0200
Subject: ImportError: cannot import name _remove_dead_weakref
Message-ID: <CAN_spzg61xpkpuVYcR+BNg61LyMi=x-UHkBQCP1LmU5c6nV+Uw@mail.gmail.com>

on an Ubuntu VM with :


   1. Linux JP-Paid-UBUNTU-DSVM 4.13.0-1014-azure
   2. Python 3.5.4 :: Anaconda custom (64-bit)

$ manta manta_genSimData.py
Loading script 'manta_genSimData.py'
Traceback (most recent call last):

skipping some details

...
File "/anaconda/lib/python2.7/weakref.py", line 14, in <module>
    from _weakref import (
*ImportError: cannot import name _remove_dead_weakref*
Script finished.


From rosuav at gmail.com  Thu May  3 13:15:03 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 4 May 2018 03:15:03 +1000
Subject: ImportError: cannot import name _remove_dead_weakref
In-Reply-To: <CAN_spzg61xpkpuVYcR+BNg61LyMi=x-UHkBQCP1LmU5c6nV+Uw@mail.gmail.com>
References: <CAN_spzg61xpkpuVYcR+BNg61LyMi=x-UHkBQCP1LmU5c6nV+Uw@mail.gmail.com>
Message-ID: <CAPTjJmr3uYYT3omaB+TdtrYutjMs3iN_xkZX0axeyVAbEqR5_g@mail.gmail.com>

On Fri, May 4, 2018 at 1:53 AM, joseph pareti <joepareti54 at gmail.com> wrote:
> on an Ubuntu VM with :
>
>
>    1. Linux JP-Paid-UBUNTU-DSVM 4.13.0-1014-azure
>    2. Python 3.5.4 :: Anaconda custom (64-bit)
>
> $ manta manta_genSimData.py
> Loading script 'manta_genSimData.py'
> Traceback (most recent call last):
>
> skipping some details
>
> ...
> File "/anaconda/lib/python2.7/weakref.py", line 14, in <module>
>     from _weakref import (
> *ImportError: cannot import name _remove_dead_weakref*
> Script finished.

Somehow, the details you're skipping include jumping from a Python
3.5.4 into a Python 2.7's standard library. Check your Anaconda
settings and see if you have something bizarre going on with your
PYTHONPATH.

ChrisA


From duane.kaufman at gmail.com  Thu May  3 14:21:19 2018
From: duane.kaufman at gmail.com (TheSeeker)
Date: Thu, 3 May 2018 11:21:19 -0700 (PDT)
Subject: Problems with pip (Windows 10)
Message-ID: <90aedf6a-874e-4cd6-a0d9-c1867454529d@googlegroups.com>

Dear All,

Within the past week I have run into a problem with pip on my work machine (Windows 10, x64, Python 3.6) where pip errors like so:

C:\>c:\Python36\Scripts\pip install --trusted-host pypi.org --trusted-host pypi.python.org --trusted-host files.pythonhosted.org --no-color --default-timeout=100 pint
Collecting pint
  Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ProtocolError('Connection aborted.', ConnectionResetError(10054, 'An existing connection was forcibly closed by the remote host', None, 10054, None))': /packages/1e/40/6938f7d544eef208a8183c2c80624289e8a4f4e0aea43f4658b9527077de/Pint-0.8.1.tar.gz
  Retrying (Retry(total=3, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ProtocolError('Connection aborted.', ConnectionResetError(10054, 'An existing connection was forcibly closed by the remote host', None, 10054, None))': /packages/1e/40/6938f7d544eef208a8183c2c80624289e8a4f4e0aea43f4658b9527077de/Pint-0.8.1.tar.gz
  Retrying (Retry(total=2, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ProtocolError('Connection aborted.', ConnectionResetError(10054, 'An existing connection was forcibly closed by the remote host', None, 10054, None))': /packages/1e/40/6938f7d544eef208a8183c2c80624289e8a4f4e0aea43f4658b9527077de/Pint-0.8.1.tar.gz
  Retrying (Retry(total=1, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ProtocolError('Connection aborted.', ConnectionResetError(10054, 'An existing connection was forcibly closed by the remote host', None, 10054, None))': /packages/1e/40/6938f7d544eef208a8183c2c80624289e8a4f4e0aea43f4658b9527077de/Pint-0.8.1.tar.gz
  Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ProtocolError('Connection aborted.', ConnectionResetError(10054, 'An existing connection was forcibly closed by the remote host', None, 10054, None))': /packages/1e/40/6938f7d544eef208a8183c2c80624289e8a4f4e0aea43f4658b9527077de/Pint-0.8.1.tar.gz
Could not install packages due to an EnvironmentError: HTTPSConnectionPool(host='files.pythonhosted.org', port=443): Max retries exceeded with url: /packages/1e/40/6938f7d544eef208a8183c2c80624289e8a4f4e0aea43f4658b9527077de/Pint-0.8.1.tar.gz (Caused by ProtocolError('Connection aborted.', ConnectionResetError(10054, 'An existing connection was forcibly closed by the remote host', None, 10054, None)))

C:\>c:\Python36\Scripts\pip --version
pip 10.0.1 from c:\python36\lib\site-packages\pip-10.0.1-py3.6.egg\pip (python 3.6)

The only thing I have changed is I upgraded to Windows 10 version 1803. 
pip had been working before that point, but my place of work might have changed things as well from a network perspective.

Has anyone else seen something like this?

Sincerely,
Duane


From ned at nedbatchelder.com  Thu May  3 14:23:05 2018
From: ned at nedbatchelder.com (Ned Batchelder)
Date: Thu, 3 May 2018 14:23:05 -0400
Subject: syntax error (?) on ubuntu
In-Reply-To: <CAPM-O+wYMRwphg9LAoWTpT5Pp1QeRMVwunpPxyhPvRB=S5iXSg@mail.gmail.com>
References: <CAN_spzjUo=xCHrxhiNApLmPR1+2faExGtR-1Z0EnVKoQzSixEg@mail.gmail.com>
 <CAPM-O+wYMRwphg9LAoWTpT5Pp1QeRMVwunpPxyhPvRB=S5iXSg@mail.gmail.com>
Message-ID: <54ae622e-2540-6bac-e529-60d78724dcdc@nedbatchelder.com>

On 5/3/18 9:11 AM, Joel Goldstick wrote:
> On Thu, May 3, 2018 at 9:06 AM, joseph pareti <joepareti54 at gmail.com> wrote:
>> $ python tf_simple.py
>>
>> /anaconda/envs/py35/lib/python3.5/site-packages/h5py/__init__.py:36:
>> FutureWarning: Conversion of the second argument of issubdtype from `float`
>> to `np.floating` is deprecated. In future, it will be treated as
>> `np.float64 == np.dtype(float).type`.
>>    from ._conv import register_converters as _register_converters
>> Traceback (most recent call last):
>>    File "tf_simple.py", line 29, in <module>
>>      import uniio
>>    File "../tools/uniio.py", line 132
>>      if(PY3K): ID = ID.decode("utf-8")
>>                                       ^
>> TabError: inconsistent use of tabs and spaces in indentation
>> --
>> https://mail.python.org/mailman/listinfo/python-list
> Check to see if you have a tab after the colon in the last line.  You
> must use colons or spaces, but not both
>

/tabs/ or spaces.

--Ned.


From boblatest at yahoo.com  Thu May  3 15:47:37 2018
From: boblatest at yahoo.com (Robert Latest)
Date: 3 May 2018 19:47:37 GMT
Subject: Weird side effect of default parameter
Message-ID: <fl17apFk5kbU1@mid.individual.net>

Hello,

I don't understand the behavior of the code below. Why does the dict property
"a" of both objects contain the same keys? This is only if "a=dict" is in
the initializer. If I put self.a = dict() into the init function, I get two
separate dicts



class Foo(object):
    def __init__(self, x, a=dict()):
        self.x = x
        self.a = a
        self.a[x] = x


c = Foo(1)
d = Foo(2)

print(c.__dict__)
print(d.__dict__)


robert


From joepareti54 at gmail.com  Thu May  3 16:10:49 2018
From: joepareti54 at gmail.com (joseph pareti)
Date: Thu, 3 May 2018 22:10:49 +0200
Subject: ImportError: cannot import name _remove_dead_weakref
In-Reply-To: <CAPTjJmr3uYYT3omaB+TdtrYutjMs3iN_xkZX0axeyVAbEqR5_g@mail.gmail.com>
References: <CAN_spzg61xpkpuVYcR+BNg61LyMi=x-UHkBQCP1LmU5c6nV+Uw@mail.gmail.com>
 <CAPTjJmr3uYYT3omaB+TdtrYutjMs3iN_xkZX0axeyVAbEqR5_g@mail.gmail.com>
Message-ID: <CAN_spzhxhfx7=BJvLmxmjTjqY4sVDFOL01zOsc1KT7adtH8keA@mail.gmail.com>

please excuse my full python ignorance, however if I set PYTHONPTAH as
shown below, then the results are quite different than before:

$ echo $PYTHONPATH
/backupdata/anaconda/lib/python2.7/
$ python tf_train_pressure.py
Fatal Python error: Py_Initialize: Unable to get the locale encoding
  File "/backupdata/anaconda/lib/python2.7/encodings/__init__.py", line 124
    raise CodecRegistryError,\
                            ^
SyntaxError: invalid syntax

Current thread 0x00007f2b4459f700 (most recent call first):
Aborted (core dumped)


2018-05-03 19:15 GMT+02:00 Chris Angelico <rosuav at gmail.com>:

> On Fri, May 4, 2018 at 1:53 AM, joseph pareti <joepareti54 at gmail.com>
> wrote:
> > on an Ubuntu VM with :
> >
> >
> >    1. Linux JP-Paid-UBUNTU-DSVM 4.13.0-1014-azure
> >    2. Python 3.5.4 :: Anaconda custom (64-bit)
> >
> > $ manta manta_genSimData.py
> > Loading script 'manta_genSimData.py'
> > Traceback (most recent call last):
> >
> > skipping some details
> >
> > ...
> > File "/anaconda/lib/python2.7/weakref.py", line 14, in <module>
> >     from _weakref import (
> > *ImportError: cannot import name _remove_dead_weakref*
> > Script finished.
>
> Somehow, the details you're skipping include jumping from a Python
> 3.5.4 into a Python 2.7's standard library. Check your Anaconda
> settings and see if you have something bizarre going on with your
> PYTHONPATH.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>


From rosuav at gmail.com  Thu May  3 16:13:55 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 4 May 2018 06:13:55 +1000
Subject: ImportError: cannot import name _remove_dead_weakref
In-Reply-To: <CAN_spzhxhfx7=BJvLmxmjTjqY4sVDFOL01zOsc1KT7adtH8keA@mail.gmail.com>
References: <CAN_spzg61xpkpuVYcR+BNg61LyMi=x-UHkBQCP1LmU5c6nV+Uw@mail.gmail.com>
 <CAPTjJmr3uYYT3omaB+TdtrYutjMs3iN_xkZX0axeyVAbEqR5_g@mail.gmail.com>
 <CAN_spzhxhfx7=BJvLmxmjTjqY4sVDFOL01zOsc1KT7adtH8keA@mail.gmail.com>
Message-ID: <CAPTjJmqUg8=+VzgxNsiA=PeUfXxWd4_gVvKpKQGV2x7hfLxmCw@mail.gmail.com>

On Fri, May 4, 2018 at 6:10 AM, joseph pareti <joepareti54 at gmail.com> wrote:
> please excuse my full python ignorance, however if I set PYTHONPTAH as shown
> below, then the results are quite different than before:
>
> $ echo $PYTHONPATH
> /backupdata/anaconda/lib/python2.7/
> $ python tf_train_pressure.py
> Fatal Python error: Py_Initialize: Unable to get the locale encoding
>   File "/backupdata/anaconda/lib/python2.7/encodings/__init__.py", line 124
>     raise CodecRegistryError,\
>                             ^
> SyntaxError: invalid syntax
>
> Current thread 0x00007f2b4459f700 (most recent call first):
> Aborted (core dumped)
>

Somewhere, you have a mismatch of versions. Make sure you're using the
same Python version for everything. You have some Python 2.7 messing
up your 3.5.

ChrisA


From gherron at digipen.edu  Thu May  3 16:14:55 2018
From: gherron at digipen.edu (Gary Herron)
Date: Thu, 3 May 2018 13:14:55 -0700
Subject: Weird side effect of default parameter
In-Reply-To: <fl17apFk5kbU1@mid.individual.net>
References: <fl17apFk5kbU1@mid.individual.net>
Message-ID: <7ae89986-1942-70bb-5ba5-4484f0108f2a@digipen.edu>

This is a well known feature of Python.?? It's a very common "gotcha" to 
new Python programmers.

Google "Mutable default parameters in Python" for long list of 
explanations and fixes.

In short, don't use a mutable object as a default parameter.


Gary Herron



On 05/03/2018 12:47 PM, python-list at python.org wrote:
> Hello,
>
> I don't understand the behavior of the code below. Why does the dict property
> "a" of both objects contain the same keys? This is only if "a=dict" is in
> the initializer. If I put self.a = dict() into the init function, I get two
> separate dicts
>
>
>
> class Foo(object):
>      def __init__(self, x, a=dict()):
>          self.x = x
>          self.a = a
>          self.a[x] = x
>
>
> c = Foo(1)
> d = Foo(2)
>
> print(c.__dict__)
> print(d.__dict__)
>
>
> robert

-- 
Dr. Gary Herron
Professor of Computer Science
DigiPen Institute of Technology
(425) 895-4418



From dieter at handshake.de  Fri May  4 01:55:09 2018
From: dieter at handshake.de (dieter)
Date: Fri, 04 May 2018 07:55:09 +0200
Subject: ImportError: cannot import name _remove_dead_weakref
References: <CAN_spzg61xpkpuVYcR+BNg61LyMi=x-UHkBQCP1LmU5c6nV+Uw@mail.gmail.com>
 <CAPTjJmr3uYYT3omaB+TdtrYutjMs3iN_xkZX0axeyVAbEqR5_g@mail.gmail.com>
 <CAN_spzhxhfx7=BJvLmxmjTjqY4sVDFOL01zOsc1KT7adtH8keA@mail.gmail.com>
 <CAPTjJmqUg8=+VzgxNsiA=PeUfXxWd4_gVvKpKQGV2x7hfLxmCw@mail.gmail.com>
Message-ID: <877eokrmma.fsf@handshake.de>

Chris Angelico <rosuav at gmail.com> writes:
> ...
> Somewhere, you have a mismatch of versions. Make sure you're using the
> same Python version for everything. You have some Python 2.7 messing
> up your 3.5.

I have had similar problems. In my case, an active "PYTHONPATH" envvar
was responsible -- "unset"ting this envar has resolved the problem for me.



From joepareti54 at gmail.com  Fri May  4 03:26:26 2018
From: joepareti54 at gmail.com (joseph pareti)
Date: Fri, 4 May 2018 09:26:26 +0200
Subject: ImportError: cannot import name _remove_dead_weakref
In-Reply-To: <877eokrmma.fsf@handshake.de>
References: <CAN_spzg61xpkpuVYcR+BNg61LyMi=x-UHkBQCP1LmU5c6nV+Uw@mail.gmail.com>
 <CAPTjJmr3uYYT3omaB+TdtrYutjMs3iN_xkZX0axeyVAbEqR5_g@mail.gmail.com>
 <CAN_spzhxhfx7=BJvLmxmjTjqY4sVDFOL01zOsc1KT7adtH8keA@mail.gmail.com>
 <CAPTjJmqUg8=+VzgxNsiA=PeUfXxWd4_gVvKpKQGV2x7hfLxmCw@mail.gmail.com>
 <877eokrmma.fsf@handshake.de>
Message-ID: <CAN_spzjbCsBM4o=zTEQfT=2SyKLJ4N+rThgn94o5xpW8GyiJMw@mail.gmail.com>

thank you for the advice: depending on the value of PYTHONPATH (version
2.7, 3.5, or unset), tensorflow stops with 3 different error traps

2018-05-04 7:55 GMT+02:00 dieter <dieter at handshake.de>:

> Chris Angelico <rosuav at gmail.com> writes:
> > ...
> > Somewhere, you have a mismatch of versions. Make sure you're using the
> > same Python version for everything. You have some Python 2.7 messing
> > up your 3.5.
>
> I have had similar problems. In my case, an active "PYTHONPATH" envvar
> was responsible -- "unset"ting this envar has resolved the problem for me.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>


From steve+comp.lang.python at pearwood.info  Fri May  4 08:26:24 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 4 May 2018 12:26:24 +0000 (UTC)
Subject: Weird side effect of default parameter
References: <fl17apFk5kbU1@mid.individual.net>
Message-ID: <pchjhf$f9u$1@blaine.gmane.org>

On Thu, 03 May 2018 19:47:37 +0000, Robert Latest via Python-list wrote:

> Hello,
> 
> I don't understand the behavior of the code below. Why does the dict
> property "a" of both objects contain the same keys? This is only if
> "a=dict" is in the initializer. If I put self.a = dict() into the init
> function, I get two separate dicts


Python function default values use *early binding*: the default parameter 
is evaluated, ONCE, when the function is defined, and that value is used 
each time it is needed.

The opposite is *late binding*: the default parameter is not evaluated 
until it is actually needed, and then re-evaluated each time it is needed.

Both approaches have their pros and cons, but early binding is better as 
the language supported feature, since it is easy to build late binding 
for yourself:

    def __init__(self, x, a=None):
        if a is None:
            a = dict()
        self.x = x
        self.a = a
        self.a[x] = x


whereas if the language used late binding, it would be really difficult 
to build early binding on top of it.

The interaction between early-binding defaults and mutable values like 
lists and dicts is a well-known "gotcha" (or at least, it is well-known 
to those of us who have come across it before). It is even a FAQ:

https://docs.python.org/dev/faq/programming.html#why-are-default-values-
shared-between-objects


See also: http://www.effbot.org/zone/default-values.htm



-- 
Steve



From steve+comp.lang.python at pearwood.info  Fri May  4 09:01:44 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 4 May 2018 13:01:44 +0000 (UTC)
Subject: itemgetter with default arguments
Message-ID: <pchljn$f9u$2@blaine.gmane.org>

A re-occurring feature request is to add a default to itemgetter and 
attrgetter. For example, we might say:

from operator import itemgetter
f = itemgetter(1, 6, default="spam")  # proposed feature
f("Hello World!")  # returns ('e', 'W')
f("Hello")         # returns ('e', 'spam')


Two senior developers have rejected this feature, saying that we should 
just use a lambda instead.

I might be slow today, but I cannot see how to write a clear, obvious, 
efficient lambda that provides functionality equivalent to itemgetter 
with a default value.

Putting aside the case where itemgetter takes multiple indexes, how about 
the single index case? How could we get that functionality using a lambda 
which is simple and obvious enough to use on the fly as needed, and 
reasonably efficient?

Here are the specifications:

* you must use lambda, not def;

* the lambda must take a single function, the sequence you want to
  extract an item from;

* you can hard-code the index in the body of the lambda;

* you can hard-code the default value in the body of the lambda;

* if sequence[index] exists, return that value;

* otherwise return the default value;

* it should support both positive and negative indices.

Example: given an index of 2 and a default of "spam":

    (lambda seq: ... )("abcd") returns "c"

    (lambda seq: ... )("") returns "spam"


I might be missing something horribly obvious, but I can't see how to do 
this using a lambda. I tried using slicing:

    seq[index:index+1]

which will return either an empty slice or a one-item slice, but that 
didn't help me. I feel I'm missing something either obvious, or something 
impossible, and I don't know which.

(This isn't a code-golf problem. I care more about being able to do it at 
all, than about doing it in the minimum number of characters.)



-- 
Steve



From tjol at tjol.eu  Fri May  4 09:27:02 2018
From: tjol at tjol.eu (Thomas Jollans)
Date: Fri, 4 May 2018 15:27:02 +0200
Subject: itemgetter with default arguments
In-Reply-To: <pchljn$f9u$2@blaine.gmane.org>
References: <pchljn$f9u$2@blaine.gmane.org>
Message-ID: <507a5e5c-ebfc-c371-9cb0-5e94bbcb7b6a@tjol.eu>

On 2018-05-04 15:01, Steven D'Aprano wrote:
> A re-occurring feature request is to add a default to itemgetter and 
> attrgetter. For example, we might say:
> 
> from operator import itemgetter
> f = itemgetter(1, 6, default="spam")  # proposed feature
> f("Hello World!")  # returns ('e', 'W')
> f("Hello")         # returns ('e', 'spam')
> 
> 
> Two senior developers have rejected this feature, saying that we should 
> just use a lambda instead.
> 
> I might be slow today, but I cannot see how to write a clear, obvious, 
> efficient lambda that provides functionality equivalent to itemgetter 
> with a default value.
> 
> Putting aside the case where itemgetter takes multiple indexes, how about 
> the single index case? How could we get that functionality using a lambda 
> which is simple and obvious enough to use on the fly as needed, and 
> reasonably efficient?
> 
> Here are the specifications:
> 
> * you must use lambda, not def;
> 
> * the lambda must take a single function, the sequence you want to
>   extract an item from;
> 
> * you can hard-code the index in the body of the lambda;
> 
> * you can hard-code the default value in the body of the lambda;
> 
> * if sequence[index] exists, return that value;
> 
> * otherwise return the default value;
> 
> * it should support both positive and negative indices.
> 
> Example: given an index of 2 and a default of "spam":
> 
>     (lambda seq: ... )("abcd") returns "c"
> 
>     (lambda seq: ... )("") returns "spam"

Like this?

>>> spamgetter = (lambda seq, i=2, fallback="spam":
...                  seq[i] if abs(i) < len(seq) or i == -len(seq)
...                  else fallback)
>>> spamgetter("abcd", i=-4)
'a'
>>> spamgetter("abcd")
'c'
>>> spamgetter("")
'spam'
>>>


Making this work for sequences AND dict-like objects is more difficult...


> 
> 
> I might be missing something horribly obvious, but I can't see how to do 
> this using a lambda. I tried using slicing:
> 
>     seq[index:index+1]
> 
> which will return either an empty slice or a one-item slice, but that 
> didn't help me. I feel I'm missing something either obvious, or something 
> impossible, and I don't know which.
> 
> (This isn't a code-golf problem. I care more about being able to do it at 
> all, than about doing it in the minimum number of characters.)
> 
> 
> 




From antoon.pardon at vub.be  Fri May  4 09:27:16 2018
From: antoon.pardon at vub.be (Antoon Pardon)
Date: Fri, 4 May 2018 15:27:16 +0200
Subject: itemgetter with default arguments
In-Reply-To: <pchljn$f9u$2@blaine.gmane.org>
References: <pchljn$f9u$2@blaine.gmane.org>
Message-ID: <1bd1165d-c71f-474f-0fc7-9b47bdf76a4b@vub.be>

On 04-05-18 15:01, Steven D'Aprano wrote:
> A re-occurring feature request is to add a default to itemgetter and 
> attrgetter. For example, we might say:
>
> from operator import itemgetter
> f = itemgetter(1, 6, default="spam")  # proposed feature
> f("Hello World!")  # returns ('e', 'W')
> f("Hello")         # returns ('e', 'spam')
>
>
> Two senior developers have rejected this feature, saying that we should 
> just use a lambda instead.
>
> I might be slow today, but I cannot see how to write a clear, obvious, 
> efficient lambda that provides functionality equivalent to itemgetter 
> with a default value.
>
> Putting aside the case where itemgetter takes multiple indexes, how about 
> the single index case? How could we get that functionality using a lambda 
> which is simple and obvious enough to use on the fly as needed, and 
> reasonably efficient?
>
> Here are the specifications:
>
> * you must use lambda, not def;
>
> * the lambda must take a single function, the sequence you want to
>   extract an item from;
>
> * you can hard-code the index in the body of the lambda;
>
> * you can hard-code the default value in the body of the lambda;
>
> * if sequence[index] exists, return that value;
>
> * otherwise return the default value;
>
> * it should support both positive and negative indices.
>
> Example: given an index of 2 and a default of "spam":
>
>     (lambda seq: ... )("abcd") returns "c"
>
>     (lambda seq: ... )("") returns "spam"
>
>
> I might be missing something horribly obvious, but I can't see how to do 
> this using a lambda. I tried using slicing:
>
>     seq[index:index+1]
>
> which will return either an empty slice or a one-item slice, but that 
> didn't help me. I feel I'm missing something either obvious, or something 
> impossible, and I don't know which.
>
> (This isn't a code-golf problem. I care more about being able to do it at 
> all, than about doing it in the minimum number of characters.)

This seems to work:

f = (lambda seq: (list(seq) + 3 * ["spam"])[2])



From ian.g.kelly at gmail.com  Fri May  4 11:17:14 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Fri, 4 May 2018 09:17:14 -0600
Subject: itemgetter with default arguments
In-Reply-To: <pchljn$f9u$2@blaine.gmane.org>
References: <pchljn$f9u$2@blaine.gmane.org>
Message-ID: <CALwzid=NA=xb+e49zWHqD9reHtY8cDv2Nu64mWDEZuCnYTPFsQ@mail.gmail.com>

On Fri, May 4, 2018 at 7:01 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> Here are the specifications:
>
> * you must use lambda, not def;

Why? This seems like an arbitrary constraint.

> * the lambda must take a single function, the sequence you want to
>   extract an item from;
>
> * you can hard-code the index in the body of the lambda;
>
> * you can hard-code the default value in the body of the lambda;
>
> * if sequence[index] exists, return that value;
>
> * otherwise return the default value;
>
> * it should support both positive and negative indices.
>
> Example: given an index of 2 and a default of "spam":
>
>     (lambda seq: ... )("abcd") returns "c"
>
>     (lambda seq: ... )("") returns "spam"

def itemgetter2(*items, default):
    return lambda seq: tuple(get_default(seq, item, default) for item in items)

def get_default(seq, item, default):
    try:
        return seq[item]
    except (IndexError, KeyError):
        return default

py> f = itemgetter2(1, 6, default="spam")
py> f("Hello World!")
('e', 'W')
py> f("Hello!")
('e', 'spam')


From rosuav at gmail.com  Fri May  4 11:46:04 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 5 May 2018 01:46:04 +1000
Subject: itemgetter with default arguments
In-Reply-To: <CALwzid=NA=xb+e49zWHqD9reHtY8cDv2Nu64mWDEZuCnYTPFsQ@mail.gmail.com>
References: <pchljn$f9u$2@blaine.gmane.org>
 <CALwzid=NA=xb+e49zWHqD9reHtY8cDv2Nu64mWDEZuCnYTPFsQ@mail.gmail.com>
Message-ID: <CAPTjJmrTEvg_QwT-HqNpYncUe5eVxVSFspwnYK4ecRpztcmOgw@mail.gmail.com>

On Sat, May 5, 2018 at 1:17 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Fri, May 4, 2018 at 7:01 AM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> Here are the specifications:
>>
>> * you must use lambda, not def;
>
> Why? This seems like an arbitrary constraint.
>
> def itemgetter2(*items, default):
>     return lambda seq: tuple(get_default(seq, item, default) for item in items)
>
> def get_default(seq, item, default):
>     try:
>         return seq[item]
>     except (IndexError, KeyError):
>         return default
>
> py> f = itemgetter2(1, 6, default="spam")
> py> f("Hello World!")
> ('e', 'W')
> py> f("Hello!")
> ('e', 'spam')

PEP 463 wants to say hello.

ChrisA


From steve+comp.lang.python at pearwood.info  Fri May  4 13:04:31 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 4 May 2018 17:04:31 +0000 (UTC)
Subject: itemgetter with default arguments
References: <pchljn$f9u$2@blaine.gmane.org>
 <CALwzid=NA=xb+e49zWHqD9reHtY8cDv2Nu64mWDEZuCnYTPFsQ@mail.gmail.com>
Message-ID: <pci3qv$17g$1@blaine.gmane.org>

On Fri, 04 May 2018 09:17:14 -0600, Ian Kelly wrote:

> On Fri, May 4, 2018 at 7:01 AM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> Here are the specifications:
>>
>> * you must use lambda, not def;
> 
> Why? This seems like an arbitrary constraint.

You'll have to ask the two core devs. In my post, in the part you 
deleted, I wrote:

    Two senior developers have rejected this feature, saying 
    that we should just use a lambda instead.


My guess is that they were thinking that there's no need to complicate 
itemgetter for this use-case when it is just as easy to write up a quick 
lambda to do the job.

For what it's worth, your itemgetter2() is about 1600% slower on my 
computer than the real thing. I know I didn't specify speed as a 
requirement, but I mention it because on the bug tracker, the importance 
of keeping itemgetter fast is stressed.




-- 
Steve



From skip.montanaro at gmail.com  Fri May  4 15:54:45 2018
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Fri, 04 May 2018 19:54:45 +0000
Subject: Tk covering the entire screen
Message-ID: <CANc-5UyDNC2P+7ghEAyf7vqiMovUjyxsZi3CUKrpm4x1BWwzSQ@mail.gmail.com>

I have a little typing watcher (buggy as can be, nearly 20 years old):

https://github.com/smontanaro/python-bits/tree/master/watch

It does the trick most of the time, so I ignore the bugs for the most part.

I had to drag it out last week after my wrists started flairing up again. I
moved it to Py3, and was running it on Linux, but as my desktop machine at
work is Windows, I think it was a bit blind to my activity in Windows-only
applications.

So, I revisited it on Windows. My cover window is a Tk Frame with width and
height defined like so:

    (w, h) = (self.winfo_screenwidth(), self.winfo_screenheight())

Unfortunately, I have three screens, so should have been using

    (w, h) = (self.winfo_vrootwidth(), self.winfo_vrootheight())

Those calls yield the correct values for w and h (5760 x 1200), but when
the watcher tells me it's time to rest, the covering frame only blanks the
middle and right hand screens. The left hand screen remains uncovered. (I
can't run it under Python 3 on Windows for various reasons, so am running
it with 2.7.14 via an Anaconda build.)

I suspect this is a Tk issue as much as anything, but this is the only
place I know to ask Tk questions. Any ideas?

Thx,

Skip


From skip.montanaro at gmail.com  Fri May  4 16:15:18 2018
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Fri, 04 May 2018 20:15:18 +0000
Subject: Tk covering the entire screen
In-Reply-To: <CANc-5UyDNC2P+7ghEAyf7vqiMovUjyxsZi3CUKrpm4x1BWwzSQ@mail.gmail.com>
References: <CANc-5UyDNC2P+7ghEAyf7vqiMovUjyxsZi3CUKrpm4x1BWwzSQ@mail.gmail.com>
Message-ID: <CANc-5Uz6d7-VZLgw+BXJvS3bxRQ-RcwU0fFnu1VYZjdhKh5azA@mail.gmail.com>

I forgot to mention that when running on Linux (displaying back on
Windows), the Python 3 version (3.6.4, Tk 8.6) does cover all three
screens. The Windows Python 2.7.14 version with Tk 8.5 has problems.


From ian.g.kelly at gmail.com  Fri May  4 16:38:54 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Fri, 4 May 2018 14:38:54 -0600
Subject: itemgetter with default arguments
In-Reply-To: <pci3qv$17g$1@blaine.gmane.org>
References: <pchljn$f9u$2@blaine.gmane.org>
 <CALwzid=NA=xb+e49zWHqD9reHtY8cDv2Nu64mWDEZuCnYTPFsQ@mail.gmail.com>
 <pci3qv$17g$1@blaine.gmane.org>
Message-ID: <CALwzid=aN==j9Ogau8t-1M5YiO9sLdrpsXJRWp_oY8gM+_n+-w@mail.gmail.com>

On Fri, May 4, 2018 at 11:04 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Fri, 04 May 2018 09:17:14 -0600, Ian Kelly wrote:
>
>> On Fri, May 4, 2018 at 7:01 AM, Steven D'Aprano
>> <steve+comp.lang.python at pearwood.info> wrote:
>>> Here are the specifications:
>>>
>>> * you must use lambda, not def;
>>
>> Why? This seems like an arbitrary constraint.
>
> You'll have to ask the two core devs. In my post, in the part you
> deleted, I wrote:
>
>     Two senior developers have rejected this feature, saying
>     that we should just use a lambda instead.
>
>
> My guess is that they were thinking that there's no need to complicate
> itemgetter for this use-case when it is just as easy to write up a quick
> lambda to do the job.

I saw that. I just don't understand why the solution should require a
lambda just because that was the word used by a couple of core devs.

> For what it's worth, your itemgetter2() is about 1600% slower on my
> computer than the real thing. I know I didn't specify speed as a
> requirement, but I mention it because on the bug tracker, the importance
> of keeping itemgetter fast is stressed.

The real thing is written in C.


From tjol at tjol.eu  Fri May  4 19:34:14 2018
From: tjol at tjol.eu (Thomas Jollans)
Date: Sat, 5 May 2018 01:34:14 +0200
Subject: itemgetter with default arguments
In-Reply-To: <CALwzid=aN==j9Ogau8t-1M5YiO9sLdrpsXJRWp_oY8gM+_n+-w@mail.gmail.com>
References: <pchljn$f9u$2@blaine.gmane.org>
 <CALwzid=NA=xb+e49zWHqD9reHtY8cDv2Nu64mWDEZuCnYTPFsQ@mail.gmail.com>
 <pci3qv$17g$1@blaine.gmane.org>
 <CALwzid=aN==j9Ogau8t-1M5YiO9sLdrpsXJRWp_oY8gM+_n+-w@mail.gmail.com>
Message-ID: <038a8e6e-4d69-23d8-9cd1-373b96976531@tjol.eu>

On 04/05/18 22:38, Ian Kelly wrote:
> On Fri, May 4, 2018 at 11:04 AM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> On Fri, 04 May 2018 09:17:14 -0600, Ian Kelly wrote:
>>
>>> On Fri, May 4, 2018 at 7:01 AM, Steven D'Aprano
>>> <steve+comp.lang.python at pearwood.info> wrote:
>>>> Here are the specifications:
>>>>
>>>> * you must use lambda, not def;
>>>
>>> Why? This seems like an arbitrary constraint.
>>
>> You'll have to ask the two core devs. In my post, in the part you
>> deleted, I wrote:
>>
>>     Two senior developers have rejected this feature, saying
>>     that we should just use a lambda instead.
>>
>>
>> My guess is that they were thinking that there's no need to complicate
>> itemgetter for this use-case when it is just as easy to write up a quick
>> lambda to do the job.
> 
> I saw that. I just don't understand why the solution should require a
> lambda just because that was the word used by a couple of core devs.
> 
>> For what it's worth, your itemgetter2() is about 1600% slower on my
>> computer than the real thing. I know I didn't specify speed as a
>> requirement, but I mention it because on the bug tracker, the importance
>> of keeping itemgetter fast is stressed.
> 
> The real thing is written in C.
> 

Is it though?

https://github.com/python/cpython/blob/a1fc949b5ab8911a803eee691e6eea55cec43eeb/Lib/operator.py#L265


From steve+comp.lang.python at pearwood.info  Fri May  4 22:15:22 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sat, 5 May 2018 02:15:22 +0000 (UTC)
Subject: itemgetter with default arguments
References: <pchljn$f9u$2@blaine.gmane.org>
 <1bd1165d-c71f-474f-0fc7-9b47bdf76a4b@vub.be>
Message-ID: <pcj43p$16m$1@blaine.gmane.org>

On Fri, 04 May 2018 15:27:16 +0200, Antoon Pardon wrote:

>> I might be slow today, but I cannot see how to write a clear, obvious,
>> efficient lambda that provides functionality equivalent to itemgetter
>> with a default value.
[...]

> This seems to work:
> 
> f = (lambda seq: (list(seq) + 3 * ["spam"])[2])

Yep, I'm definitely slow today. Thanks for that.


Of course, it's also pretty slow, nearly as slow as me :-) On my 
computer, it was about 2000% slower than itemgetter using a moderate 
sized list (100 items).




-- 
Steve



From steve+comp.lang.python at pearwood.info  Fri May  4 22:26:44 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sat, 5 May 2018 02:26:44 +0000 (UTC)
Subject: itemgetter with default arguments
References: <pchljn$f9u$2@blaine.gmane.org>
 <507a5e5c-ebfc-c371-9cb0-5e94bbcb7b6a@tjol.eu>
Message-ID: <pcj4p4$16m$2@blaine.gmane.org>

On Fri, 04 May 2018 15:27:02 +0200, Thomas Jollans wrote:

>>>> spamgetter = (lambda seq, i=2, fallback="spam":
> ...                  seq[i] if abs(i) < len(seq) or i == -len(seq) 
> ...                  else fallback)
>>>> spamgetter("abcd", i=-4)
> 'a'
>>>> spamgetter("abcd")
> 'c'
>>>> spamgetter("")
> 'spam'


Doh! Obvious in hindsight. Thanks.

And on my computer, it's only 125% slower than itemgetter.


> Making this work for sequences AND dict-like objects is more
> difficult...

Indeed. At least with dicts you can call .get(). I don't think it is 
necessary to have the one lambda handle both sequence and dict cases. 
Surely when calling it you know whether or not you are looking at a 
sequence or a mapping.



-- 
Steve



From steve+comp.lang.python at pearwood.info  Fri May  4 23:29:27 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sat, 5 May 2018 03:29:27 +0000 (UTC)
Subject: itemgetter with default arguments
References: <pchljn$f9u$2@blaine.gmane.org>
 <CALwzid=NA=xb+e49zWHqD9reHtY8cDv2Nu64mWDEZuCnYTPFsQ@mail.gmail.com>
 <pci3qv$17g$1@blaine.gmane.org>
 <CALwzid=aN==j9Ogau8t-1M5YiO9sLdrpsXJRWp_oY8gM+_n+-w@mail.gmail.com>
Message-ID: <pcj8en$16m$3@blaine.gmane.org>

On Fri, 04 May 2018 14:38:54 -0600, Ian Kelly wrote:

> On Fri, May 4, 2018 at 11:04 AM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
[...]

>> My guess is that they were thinking that there's no need to complicate
>> itemgetter for this use-case when it is just as easy to write up a
>> quick lambda to do the job.
> 
> I saw that. I just don't understand why the solution should require a
> lambda just because that was the word used by a couple of core devs.

If it were up to me, the solution wouldn't require anything beyond 
itemgetter *wink*

In practice, we don't often use itemgetter like this:

f = itemgetter(2)
result = f(alist)

since we could just say result = alist[2] instead. I think the main use-
case for itemgetter is as a sort key:

alist.sort(key=itemgetter(2))

or perhaps even map (although this will be obsoleted somewhat by list 
comprehensions):

results = map(itemgetter(2), alist)

The point being, in these cases, it is inconvenient to have to define a 
function ahead of time. Hence, a lambda would be the right solution:

alist.sort(key=lambda item: ...)

rather than having to define the key function ahead of time.


-- 
Steve



From sharan.basappa at gmail.com  Sat May  5 00:12:49 2018
From: sharan.basappa at gmail.com (Sharan Basappa)
Date: Fri, 4 May 2018 21:12:49 -0700 (PDT)
Subject: Plot not working
Message-ID: <e9a0e1ef-6500-4347-a4cc-a56b57492863@googlegroups.com>

I am new to Python and using it to learn machine learning.

Below is a sample program I am running to plot IRIS data set.
The code runs but no plot comes up. I am not sure what the issue is with the code.

# Imports
from matplotlib import pyplot as plt
from sklearn.datasets import load_iris
import numpy as np

# load the data with load_iris from sklearn
data = load_iris()
features = data['data']
feature_names = data['feature_names']
target = data['target']

#print("features\n",features)
#print("feature names\n",feature_names)
#print("target\n",target);
#print("data\n",data)

for t,marker,c in zip(range(3),">ox","rgb"):
    # plot each class on its own to get different colored markers
    plt.scatter(features[target == t,0],
                features[target == t,1],
                marker=marker,
                c=c)


From john_ladasky at sbcglobal.net  Sat May  5 01:28:58 2018
From: john_ladasky at sbcglobal.net (John Ladasky)
Date: Fri, 4 May 2018 22:28:58 -0700 (PDT)
Subject: Plot not working
In-Reply-To: <e9a0e1ef-6500-4347-a4cc-a56b57492863@googlegroups.com>
References: <e9a0e1ef-6500-4347-a4cc-a56b57492863@googlegroups.com>
Message-ID: <ad6ec08f-2cfb-47e9-87eb-153c3e4d2fb1@googlegroups.com>

On Friday, May 4, 2018 at 9:13:02 PM UTC-7, Sharan Basappa wrote:
> I am new to Python and using it to learn machine learning.
> 
> Below is a sample program I am running to plot IRIS data set.
> The code runs but no plot comes up. I am not sure what the issue is with the code.
> 
> # Imports
> from matplotlib import pyplot as plt
> from sklearn.datasets import load_iris
> import numpy as np
> 
> # load the data with load_iris from sklearn
> data = load_iris()
> features = data['data']
> feature_names = data['feature_names']
> target = data['target']
> 
> #print("features\n",features)
> #print("feature names\n",feature_names)
> #print("target\n",target);
> #print("data\n",data)
> 
> for t,marker,c in zip(range(3),">ox","rgb"):
>     # plot each class on its own to get different colored markers
>     plt.scatter(features[target == t,0],
>                 features[target == t,1],
>                 marker=marker,
>                 c=c)

Try adding a call to plt.show() at the end.


From sharan.basappa at gmail.com  Sat May  5 02:05:20 2018
From: sharan.basappa at gmail.com (Sharan Basappa)
Date: Fri, 4 May 2018 23:05:20 -0700 (PDT)
Subject: Plot not working
In-Reply-To: <ad6ec08f-2cfb-47e9-87eb-153c3e4d2fb1@googlegroups.com>
References: <e9a0e1ef-6500-4347-a4cc-a56b57492863@googlegroups.com>
 <ad6ec08f-2cfb-47e9-87eb-153c3e4d2fb1@googlegroups.com>
Message-ID: <9a614a0f-d088-42b2-a39b-e2c54ebd2e41@googlegroups.com>

On Saturday, 5 May 2018 10:59:13 UTC+5:30, John Ladasky  wrote:
> On Friday, May 4, 2018 at 9:13:02 PM UTC-7, Sharan Basappa wrote:
> > I am new to Python and using it to learn machine learning.
> > 
> > Below is a sample program I am running to plot IRIS data set.
> > The code runs but no plot comes up. I am not sure what the issue is with the code.
> > 
> > # Imports
> > from matplotlib import pyplot as plt
> > from sklearn.datasets import load_iris
> > import numpy as np
> > 
> > # load the data with load_iris from sklearn
> > data = load_iris()
> > features = data['data']
> > feature_names = data['feature_names']
> > target = data['target']
> > 
> > #print("features\n",features)
> > #print("feature names\n",feature_names)
> > #print("target\n",target);
> > #print("data\n",data)
> > 
> > for t,marker,c in zip(range(3),">ox","rgb"):
> >     # plot each class on its own to get different colored markers
> >     plt.scatter(features[target == t,0],
> >                 features[target == t,1],
> >                 marker=marker,
> >                 c=c)
> 
> Try adding a call to plt.show() at the end.

Thanks a lot. That was the issue


From storchaka at gmail.com  Sat May  5 03:03:05 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sat, 5 May 2018 10:03:05 +0300
Subject: Tk covering the entire screen
In-Reply-To: <CANc-5UyDNC2P+7ghEAyf7vqiMovUjyxsZi3CUKrpm4x1BWwzSQ@mail.gmail.com>
References: <CANc-5UyDNC2P+7ghEAyf7vqiMovUjyxsZi3CUKrpm4x1BWwzSQ@mail.gmail.com>
Message-ID: <pcjkr5$inj$2@blaine.gmane.org>

04.05.18 22:54, Skip Montanaro ????:
> I suspect this is a Tk issue as much as anything, but this is the only
> place I know to ask Tk questions. Any ideas?

There is more specific place for Tkinter questions:

https://mail.python.org/mailman/listinfo/tkinter-discuss



From storchaka at gmail.com  Sat May  5 03:04:25 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sat, 5 May 2018 10:04:25 +0300
Subject: Tk covering the entire screen
In-Reply-To: <CANc-5Uz6d7-VZLgw+BXJvS3bxRQ-RcwU0fFnu1VYZjdhKh5azA@mail.gmail.com>
References: <CANc-5UyDNC2P+7ghEAyf7vqiMovUjyxsZi3CUKrpm4x1BWwzSQ@mail.gmail.com>
 <CANc-5Uz6d7-VZLgw+BXJvS3bxRQ-RcwU0fFnu1VYZjdhKh5azA@mail.gmail.com>
Message-ID: <pcjktl$inj$3@blaine.gmane.org>

04.05.18 23:15, Skip Montanaro ????:
> I forgot to mention that when running on Linux (displaying back on
> Windows), the Python 3 version (3.6.4, Tk 8.6) does cover all three
> screens. The Windows Python 2.7.14 version with Tk 8.5 has problems.

Try to upgrade to 2.7.15. It should be shipped with Tk 8.6.



From dieter at handshake.de  Sat May  5 03:12:15 2018
From: dieter at handshake.de (dieter)
Date: Sat, 05 May 2018 09:12:15 +0200
Subject: ImportError: cannot import name _remove_dead_weakref
References: <CAN_spzg61xpkpuVYcR+BNg61LyMi=x-UHkBQCP1LmU5c6nV+Uw@mail.gmail.com>
 <CAPTjJmr3uYYT3omaB+TdtrYutjMs3iN_xkZX0axeyVAbEqR5_g@mail.gmail.com>
 <CAN_spzhxhfx7=BJvLmxmjTjqY4sVDFOL01zOsc1KT7adtH8keA@mail.gmail.com>
 <CAPTjJmqUg8=+VzgxNsiA=PeUfXxWd4_gVvKpKQGV2x7hfLxmCw@mail.gmail.com>
 <877eokrmma.fsf@handshake.de>
 <CAN_spzjbCsBM4o=zTEQfT=2SyKLJ4N+rThgn94o5xpW8GyiJMw@mail.gmail.com>
Message-ID: <87a7tetw34.fsf@handshake.de>

joseph pareti <joepareti54 at gmail.com> writes:
> thank you for the advice: depending on the value of PYTHONPATH (version
> 2.7, 3.5, or unset), tensorflow stops with 3 different error traps

"PYTHONPATH" usually is used when you have private Python modules
not installed at the standard place. Nowadays, you can use
a so called "virtual environment" for your local installations.
Look whether "virtualenv" (or "venv") is installed in your environment.
It can be used to create a virtual environment.
Then install your own modules in this virtual environment --
ensuring not to mix things for Python 2 and Python 3.
Finally unset "PYTHONPATH" and run your Python in the virtual environment.



From sharan.basappa at gmail.com  Sat May  5 03:20:26 2018
From: sharan.basappa at gmail.com (Sharan Basappa)
Date: Sat, 5 May 2018 00:20:26 -0700 (PDT)
Subject: ipython install
Message-ID: <337a7b81-23fc-4a57-b2dd-0914033a6b3c@googlegroups.com>

I am trying to install ipython. I already have python installed.

When I type "pip install ipython" I get the following messages:

Requirement already satisfied: setuptools>=18.5 in d:\users\sharanb\appdata\local\programs\python\python36-32\lib\site-packages (from ipython)
Requirement already satisfied: jedi>=0.10 in d:\users\sharanb\appdata\roaming\python\python36\site-packages (from ipython)
Requirement already satisfied: colorama; sys_platform == "win32" in d:\users\sharanb\appdata\roaming\python\python36\site-packages (from ipython)
Requirement already satisfied: decorator in d:\users\sharanb\appdata\roaming\python\python36\site-packages (from ipython)
Requirement already satisfied: traitlets>=4.2 in d:\users\sharanb\appdata\roaming\python\python36\site-packages (from ipython)

After this, when I type ipython on command prompt, I don't get anything on my windows.

Am I making any mistakes installing ipython?


From storchaka at gmail.com  Sat May  5 03:31:17 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sat, 5 May 2018 10:31:17 +0300
Subject: itemgetter with default arguments
In-Reply-To: <pci3qv$17g$1@blaine.gmane.org>
References: <pchljn$f9u$2@blaine.gmane.org>
 <CALwzid=NA=xb+e49zWHqD9reHtY8cDv2Nu64mWDEZuCnYTPFsQ@mail.gmail.com>
 <pci3qv$17g$1@blaine.gmane.org>
Message-ID: <pcjmg2$d9$1@blaine.gmane.org>

04.05.18 20:04, Steven D'Aprano ????:
> On Fri, 04 May 2018 09:17:14 -0600, Ian Kelly wrote:
>> On Fri, May 4, 2018 at 7:01 AM, Steven D'Aprano
>> <steve+comp.lang.python at pearwood.info> wrote:
>>> Here are the specifications:
>>>
>>> * you must use lambda, not def;
>>
>> Why? This seems like an arbitrary constraint.
> 
> You'll have to ask the two core devs. In my post, in the part you
> deleted, I wrote:
> 
>      Two senior developers have rejected this feature, saying
>      that we should just use a lambda instead.
> 
> 
> My guess is that they were thinking that there's no need to complicate
> itemgetter for this use-case when it is just as easy to write up a quick
> lambda to do the job.

I prefer using local functions instead of lambdas, but in many concrete 
cases it is possible to use a lambda.

Consider a concrete example. You need to sort a list of 2- or 3- element 
tuples by the first and third items (third items are strings if 
presented). itemgetter(0, 2) doesn't work because some tuples has only 2 
items. But you can use the following lambdas:

     lambda t: (t[0], t[2] if len(t) > 2 else '')

     lambda t: (t[0], t[2]) if len(t) > 2 else (t[0],)

     lambda t: (t[0], (t + ('',))[2])

     lambda t: t[:1] + t[2:]

The second and the forth options support also the case when there is no 
natural minimal value for third items (e.g. for negative integers) or if 
you want to order 2-tuples before 3-tuples with empty third item and the 
same first item. This isn't possible with itemgetter with default arguments.

If 2-tuples are pretty rare, it may be more efficient to use the 
following function:

     def sortkey(t):
         try:
             return t[0], t[2]
         except IndexError:
             return t[0],



From __peter__ at web.de  Sat May  5 03:33:37 2018
From: __peter__ at web.de (Peter Otten)
Date: Sat, 05 May 2018 09:33:37 +0200
Subject: itemgetter with default arguments
References: <pchljn$f9u$2@blaine.gmane.org>
Message-ID: <pcjmkj$c4g$1@blaine.gmane.org>

Steven D'Aprano wrote:

> A re-occurring feature request is to add a default to itemgetter and
> attrgetter. For example, we might say:
> 
> from operator import itemgetter
> f = itemgetter(1, 6, default="spam")  # proposed feature
> f("Hello World!")  # returns ('e', 'W')
> f("Hello")         # returns ('e', 'spam')
> 
> 
> Two senior developers have rejected this feature, saying that we should
> just use a lambda instead.
> 
> I might be slow today, but I cannot see how to write a clear, obvious,
> efficient lambda that provides functionality equivalent to itemgetter
> with a default value.
> 
> Putting aside the case where itemgetter takes multiple indexes, how about
> the single index case? How could we get that functionality using a lambda
> which is simple and obvious enough to use on the fly as needed, and
> reasonably efficient?
> 
> Here are the specifications:
> 
> * you must use lambda, not def;
> 
> * the lambda must take a single function, the sequence you want to
>   extract an item from;
> 
> * you can hard-code the index in the body of the lambda;
> 
> * you can hard-code the default value in the body of the lambda;
> 
> * if sequence[index] exists, return that value;
> 
> * otherwise return the default value;
> 
> * it should support both positive and negative indices.
> 
> Example: given an index of 2 and a default of "spam":
> 
>     (lambda seq: ... )("abcd") returns "c"
> 
>     (lambda seq: ... )("") returns "spam"
> 
> 
> I might be missing something horribly obvious, but I can't see how to do
> this using a lambda. I tried using slicing:
> 
>     seq[index:index+1]
> 
> which will return either an empty slice or a one-item slice, but that
> didn't help me. I feel I'm missing something either obvious, or something
> impossible, and I don't know which.
> 
> (This isn't a code-golf problem. I care more about being able to do it at
> all, than about doing it in the minimum number of characters.)

I think you have established that there is no straight-forward way to write 
this as a lambda. But is adding a default to itemgetter the right 
conclusion?

If there were an exception-catching decorator you could write

f = catch(IndexError, "spam")(itemgetter(2))


>>> from operator import itemgetter
>>> def catch(exc, default):
...     def deco(f):
...         def catcher(*args, **kw):
...             try: return f(*args, **kw)
...             except exc: return default
...         return catcher
...     return deco
... 
>>> f = catch((IndexError, KeyError), "spam")(itemgetter(1))
>>> f("abc")
'b'
>>> f("")
'spam'
>>> f(dict(a=1))
'spam'
>>> f({1: "ham"})
'ham'

This may be useful for other applications:

>>> g = catch(ZeroDivisionError, "#error")(lambda x: 1/x)
>>> g(2)
0.5
>>> g(0)
'#error'




From steve+comp.lang.python at pearwood.info  Sat May  5 05:24:25 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sat, 5 May 2018 09:24:25 +0000 (UTC)
Subject: itemgetter with default arguments
References: <pchljn$f9u$2@blaine.gmane.org> <pcjmkj$c4g$1@blaine.gmane.org>
Message-ID: <pcjt89$16m$4@blaine.gmane.org>

On Sat, 05 May 2018 09:33:37 +0200, Peter Otten wrote:

> I think you have established that there is no straight-forward way to
> write this as a lambda.

What I *mostly* established was that I was having a "cannot brain, I have 
the dumb" day, because the solution with ternary if was obvious in 
hindsight:

    lambda x: x[3] if len(x) > 4 else "MISSING"


nevertheless, I still think that making this a feature of itemgetter and 
attrgetter is worthwhile.


> But is adding a default to itemgetter the right conclusion?

I think so, but others (including Raymond Hettinger and Serhiy Storchaka) 
don't. Even when they're clearly and obviously wrong, as in this case 
*wink*, I don't think we should just dismiss their objection without 
careful thought.



-- 
Steve



From steve+comp.lang.python at pearwood.info  Sat May  5 05:25:34 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sat, 5 May 2018 09:25:34 +0000 (UTC)
Subject: ipython install
References: <337a7b81-23fc-4a57-b2dd-0914033a6b3c@googlegroups.com>
Message-ID: <pcjtae$16m$5@blaine.gmane.org>

On Sat, 05 May 2018 00:20:26 -0700, Sharan Basappa wrote:

> After this, when I type ipython on command prompt, I don't get anything
> on my windows.

You don't get *anything*? Not even an error?



-- 
Steve



From steve+comp.lang.python at pearwood.info  Sat May  5 05:59:31 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sat, 5 May 2018 09:59:31 +0000 (UTC)
Subject: itemgetter with default arguments
References: <pchljn$f9u$2@blaine.gmane.org>
 <CALwzid=NA=xb+e49zWHqD9reHtY8cDv2Nu64mWDEZuCnYTPFsQ@mail.gmail.com>
 <pci3qv$17g$1@blaine.gmane.org> <pcjmg2$d9$1@blaine.gmane.org>
Message-ID: <pcjva3$16m$6@blaine.gmane.org>

On Sat, 05 May 2018 10:31:17 +0300, Serhiy Storchaka wrote:

> Consider a concrete example. You need to sort a list of 2- or 3- element
> tuples by the first and third items (third items are strings if
> presented). itemgetter(0, 2) doesn't work because some tuples has only 2
> items. But you can use the following lambdas:

    lambda t: t[0:3:2]

should also work.


>      lambda t: (t[0], t[2] if len(t) > 2 else '')
>      lambda t: (t[0], t[2]) if len(t) > 2 else (t[0],)
>      lambda t: (t[0], (t + ('',))[2])
>      lambda t: t[:1] + t[2:]

So which of these is the "One Obvious Way"?


> The second and the forth options support also the case when there is no
> natural minimal value for third items (e.g. for negative integers) or if
> you want to order 2-tuples before 3-tuples with empty third item and the
> same first item. This isn't possible with itemgetter with default
> arguments.

Nobody suggests that itemgetter is a magic wand that ought to solve every 
imaginable problem. There will always be sufficiently complex examples 
where you have to write your own key function.

-- 
Steve



From sharan.basappa at gmail.com  Sat May  5 06:09:18 2018
From: sharan.basappa at gmail.com (Sharan Basappa)
Date: Sat, 5 May 2018 03:09:18 -0700 (PDT)
Subject: ipython install
In-Reply-To: <mailman.7.1525512738.31762.python-list@python.org>
References: <337a7b81-23fc-4a57-b2dd-0914033a6b3c@googlegroups.com>
 <pcjtae$16m$5@blaine.gmane.org>
 <mailman.7.1525512738.31762.python-list@python.org>
Message-ID: <d81bde76-acb1-4ec6-8ad4-2d135b03f752@googlegroups.com>

On Saturday, 5 May 2018 15:02:33 UTC+5:30, Steven D'Aprano  wrote:
> On Sat, 05 May 2018 00:20:26 -0700, Sharan Basappa wrote:
> 
> > After this, when I type ipython on command prompt, I don't get anything
> > on my windows.
> 
> You don't get *anything*? Not even an error?
> 
> 
> 
> -- 
> Steve

like typical behaviour when you don't have the application installed on your computer, it actually open up a browser and gives results for ipython using bing


From sharan.basappa at gmail.com  Sat May  5 06:13:23 2018
From: sharan.basappa at gmail.com (Sharan Basappa)
Date: Sat, 5 May 2018 03:13:23 -0700 (PDT)
Subject: ipython install
In-Reply-To: <d81bde76-acb1-4ec6-8ad4-2d135b03f752@googlegroups.com>
References: <337a7b81-23fc-4a57-b2dd-0914033a6b3c@googlegroups.com>
 <pcjtae$16m$5@blaine.gmane.org>
 <mailman.7.1525512738.31762.python-list@python.org>
 <d81bde76-acb1-4ec6-8ad4-2d135b03f752@googlegroups.com>
Message-ID: <bf4b0c43-b1a9-4d26-ae47-484109700513@googlegroups.com>

On Saturday, 5 May 2018 15:39:32 UTC+5:30, Sharan Basappa  wrote:
> On Saturday, 5 May 2018 15:02:33 UTC+5:30, Steven D'Aprano  wrote:
> > On Sat, 05 May 2018 00:20:26 -0700, Sharan Basappa wrote:
> > 
> > > After this, when I type ipython on command prompt, I don't get anything
> > > on my windows.
> > 
> > You don't get *anything*? Not even an error?
> > 
> > 
> > 
> > -- 
> > Steve
> 
> like typical behaviour when you don't have the application installed on your computer, it actually open up a browser and gives results for ipython using bing

by the way, i listed all the installed modules and don't see ipython at all.
I see the following:


autoexpand          imaplib             re                  winreg
autoreload          imghdr              redirector          winsound
base64              imp                 replace             wsgiref
bdb                 importlib           reprlib             xdrlib
binascii            inspect             requests            xml
binhex              io                  rlcompleter         xmlrpc
bisect              iomenu              rmagic              xxsubtype
bleach              ipaddress           rpc                 zipapp
boto                ipykernel           rstrip              zipfile
boto3               ipykernel_launcher  run                 zipimport
botocore            ipython_genutils    runpy               zlib
browser             ipywidgets          runscript           zmq
builtins            itertools           s3transfer          zoomheight
bz2                 jedi                sched               zzdummy


From sharan.basappa at gmail.com  Sat May  5 07:25:50 2018
From: sharan.basappa at gmail.com (Sharan Basappa)
Date: Sat, 5 May 2018 04:25:50 -0700 (PDT)
Subject: write to file
Message-ID: <22b11b9d-49b5-4967-a208-7c6ed3d65f90@googlegroups.com>

In my program, I have print statements for debugging.
However, these are cluttering the display. So, I am trying to save
these to a file but somehow I cant seem to get it correct.

For example, the following are the print statement in my program:
print("target_names\n",target_names)

To print to a file, I have opened the file using - fh = open("ML_PY_2.log","w+")
Beyond this, I see that fh.write has to be used but most of the examples I see only show how strings are saved.

Can I get input how to covert the above print statement to save into the file?

Thanks in advance


From breamoreboy at gmail.com  Sat May  5 07:51:12 2018
From: breamoreboy at gmail.com (Mark Lawrence)
Date: Sat, 5 May 2018 12:51:12 +0100
Subject: write to file
In-Reply-To: <22b11b9d-49b5-4967-a208-7c6ed3d65f90@googlegroups.com>
References: <22b11b9d-49b5-4967-a208-7c6ed3d65f90@googlegroups.com>
Message-ID: <pck5nd$3q3$1@blaine.gmane.org>

On 05/05/18 12:25, Sharan Basappa wrote:
> In my program, I have print statements for debugging.
> However, these are cluttering the display. So, I am trying to save
> these to a file but somehow I cant seem to get it correct.

Use the logging module https://docs.python.org/3/library/logging.html 
for debugging, it's far easier in the longer term.

> 
> For example, the following are the print statement in my program:
> print("target_names\n",target_names)
> 
> To print to a file, I have opened the file using - fh = open("ML_PY_2.log","w+")
> Beyond this, I see that fh.write has to be used but most of the examples I see only show how strings are saved.
> 
> Can I get input how to covert the above print statement to save into the file?

You'll need to do some string formatting.  Take your pick from :-

The old but still heavilly used C style 
https://docs.python.org/3/library/stdtypes.html#old-string-formatting

The new style 
https://docs.python.org/3/library/string.html#format-string-syntax

If you have Python 3.6 f-strings

> 
> Thanks in advance
> 

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence



From storchaka at gmail.com  Sat May  5 08:16:50 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sat, 5 May 2018 15:16:50 +0300
Subject: itemgetter with default arguments
In-Reply-To: <pcjva3$16m$6@blaine.gmane.org>
References: <pchljn$f9u$2@blaine.gmane.org>
 <CALwzid=NA=xb+e49zWHqD9reHtY8cDv2Nu64mWDEZuCnYTPFsQ@mail.gmail.com>
 <pci3qv$17g$1@blaine.gmane.org> <pcjmg2$d9$1@blaine.gmane.org>
 <pcjva3$16m$6@blaine.gmane.org>
Message-ID: <pck77f$9s4$1@blaine.gmane.org>

05.05.18 12:59, Steven D'Aprano ????:
> On Sat, 05 May 2018 10:31:17 +0300, Serhiy Storchaka wrote:
>> Consider a concrete example. You need to sort a list of 2- or 3- element
>> tuples by the first and third items (third items are strings if
>> presented). itemgetter(0, 2) doesn't work because some tuples has only 2
>> items. But you can use the following lambdas:
> 
>      lambda t: t[0:3:2]
> 
> should also work.

Right, this works in this special case (for tuples and 2-items key). You 
can even utilize itemgetter()!

      itemgetter(slice(0, 3, 2))

>>       lambda t: (t[0], t[2] if len(t) > 2 else '')
>>       lambda t: (t[0], t[2]) if len(t) > 2 else (t[0],)
>>       lambda t: (t[0], (t + ('',))[2])
>>       lambda t: t[:1] + t[2:]
> 
> So which of these is the "One Obvious Way"?

Depending on the details of the problem and the background of the 
author, the first or the second options can be the most obvious way. Or 
any other.

>> The second and the forth options support also the case when there is no
>> natural minimal value for third items (e.g. for negative integers) or if
>> you want to order 2-tuples before 3-tuples with empty third item and the
>> same first item. This isn't possible with itemgetter with default
>> arguments.
> 
> Nobody suggests that itemgetter is a magic wand that ought to solve every
> imaginable problem. There will always be sufficiently complex examples
> where you have to write your own key function.

Right. And it looks to me, that the case in which you want to use 
itemgetter with default arguments is the case where you have to write 
your own key function.



From steve+comp.lang.python at pearwood.info  Sat May  5 09:27:36 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sat, 5 May 2018 13:27:36 +0000 (UTC)
Subject: write to file
References: <22b11b9d-49b5-4967-a208-7c6ed3d65f90@googlegroups.com>
Message-ID: <pckbg7$16m$7@blaine.gmane.org>

On Sat, 05 May 2018 04:25:50 -0700, Sharan Basappa wrote:

> In my program, I have print statements for debugging. However, these are
> cluttering the display. So, I am trying to save these to a file but
> somehow I cant seem to get it correct.

There are lots of way to solve this problem.

The best way is to use the logging module. Here are a couple of 
introductions to it:

https://docs.python.org/3/howto/logging.html#logging-basic-tutorial

https://pymotw.com/3/logging/index.html

and there are many more:

https://duckduckgo.com/?q=python+logging+tutorial


but we can start with something much simpler, just using print.

You have already run:

    fh = open("ML_PY_2.log","w+")

at the start of your program, now call print:

    print("target_names:",target_names, file=fh)

Finally, at the end of your program, call:

    fh.close()


-- 
Steve



From ian.g.kelly at gmail.com  Sat May  5 10:17:42 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Sat, 5 May 2018 08:17:42 -0600
Subject: itemgetter with default arguments
In-Reply-To: <038a8e6e-4d69-23d8-9cd1-373b96976531@tjol.eu>
References: <pchljn$f9u$2@blaine.gmane.org>
 <CALwzid=NA=xb+e49zWHqD9reHtY8cDv2Nu64mWDEZuCnYTPFsQ@mail.gmail.com>
 <pci3qv$17g$1@blaine.gmane.org>
 <CALwzid=aN==j9Ogau8t-1M5YiO9sLdrpsXJRWp_oY8gM+_n+-w@mail.gmail.com>
 <038a8e6e-4d69-23d8-9cd1-373b96976531@tjol.eu>
Message-ID: <CALwzidnWD-sWR1SuEW8y9uEt=REZa2r2Be-XNZ7ohy_AWett6A@mail.gmail.com>

On Fri, May 4, 2018 at 5:34 PM, Thomas Jollans <tjol at tjol.eu> wrote:
> On 04/05/18 22:38, Ian Kelly wrote:
>> The real thing is written in C.
>>
>
> Is it though?
>
> https://github.com/python/cpython/blob/a1fc949b5ab8911a803eee691e6eea55cec43eeb/Lib/operator.py#L265

It is. First, notice the docstring of that module says, "This is the
pure Python implementation of the module." Second, notice that near
the bottom of the file is this code:

try:
    from _operator import *
except ImportError:
    pass
else:
    from _operator import __doc__

The implementation actually used by CPython is here:

https://github.com/python/cpython/blob/a1fc949b5ab8911a803eee691e6eea55cec43eeb/Modules/_operator.c#L402

The pure Python version exists to be shared by other Python
implementations that don't support C extensions.


From sharan.basappa at gmail.com  Sat May  5 11:45:39 2018
From: sharan.basappa at gmail.com (Sharan Basappa)
Date: Sat, 5 May 2018 08:45:39 -0700 (PDT)
Subject: write to file
In-Reply-To: <mailman.10.1525526998.31762.python-list@python.org>
References: <22b11b9d-49b5-4967-a208-7c6ed3d65f90@googlegroups.com>
 <pckbg7$16m$7@blaine.gmane.org>
 <mailman.10.1525526998.31762.python-list@python.org>
Message-ID: <b5e113b9-20f5-4995-a2e0-d74305e43bdf@googlegroups.com>

On Saturday, 5 May 2018 19:00:12 UTC+5:30, Steven D'Aprano  wrote:
> On Sat, 05 May 2018 04:25:50 -0700, Sharan Basappa wrote:
> 
> > In my program, I have print statements for debugging. However, these are
> > cluttering the display. So, I am trying to save these to a file but
> > somehow I cant seem to get it correct.
> 
> There are lots of way to solve this problem.
> 
> The best way is to use the logging module. Here are a couple of 
> introductions to it:
> 
> https://docs.python.org/3/howto/logging.html#logging-basic-tutorial
> 
> https://pymotw.com/3/logging/index.html
> 
> and there are many more:
> 
> https://duckduckgo.com/?q=python+logging+tutorial
> 
> 
> but we can start with something much simpler, just using print.
> 
> You have already run:
> 
>     fh = open("ML_PY_2.log","w+")
> 
> at the start of your program, now call print:
> 
>     print("target_names:",target_names, file=fh)
> 
> Finally, at the end of your program, call:
> 
>     fh.close()
> 
> 
> -- 
> Steve

Steve,

Thanks a lot. I have actually tried print with file handle as a parameter (the last option). I see that the file is created but nothing is logged. So, I assumed, I am doing something incorrect.
Anyway, I will try this again and let you know how it goes.


From steve+comp.lang.python at pearwood.info  Sat May  5 12:10:42 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sat, 5 May 2018 16:10:42 +0000 (UTC)
Subject: Why is calling eval so slow?
Message-ID: <pckl22$16m$8@blaine.gmane.org>

I understand that calling eval() on a string is going to be slow, since 
the string has to be parsed, compiled, and then executed.

But why is it so slow when called on function __code__ objects and pre-
compiled byte-code?


Here are the tests I ran:

# calling a regular function
python3.5 -m timeit -s "f = lambda: 99" "f()"
# evaluating a function code object
python3.5 -m timeit -s "f = (lambda: 99).__code__" "eval(f)"
# estimate the overhead of the eval name lookup
python3.5 -m timeit "eval"
# evaluating a pre-compiled byte-code object
python3.5 -m timeit -s "f = compile('99', '', 'eval')" "eval(f)"
# evaluating a string
python3.5 -m timeit "eval('99')"


And the results on my computer:

# call a regular function
1000000 loops, best of 3: 0.245 usec per loop
# evaluate the function __code__ object
1000000 loops, best of 3: 1.16 usec per loop
# overhead of looking up "eval"
10000000 loops, best of 3: 0.11 usec per loop


which means it takes four times longer to execute the code object alone, 
compared to calling the function object which executes the code object.

Why so slow?


# evaluate the pre-compiled byte-code
1000000 loops, best of 3: 1.13 usec per loop
# parse, compile and evaluate a string
10000 loops, best of 3: 23.5 usec per loop

That one, at least, makes perfect sense to me :-)



-- 
Steve



From steve+comp.lang.python at pearwood.info  Sat May  5 12:14:40 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sat, 5 May 2018 16:14:40 +0000 (UTC)
Subject: write to file
References: <22b11b9d-49b5-4967-a208-7c6ed3d65f90@googlegroups.com>
 <pckbg7$16m$7@blaine.gmane.org>
 <mailman.10.1525526998.31762.python-list@python.org>
 <b5e113b9-20f5-4995-a2e0-d74305e43bdf@googlegroups.com>
Message-ID: <pckl9f$16m$9@blaine.gmane.org>

On Sat, 05 May 2018 08:45:39 -0700, Sharan Basappa wrote:

> Thanks a lot. I have actually tried print with file handle as a
> parameter (the last option). I see that the file is created but nothing
> is logged.

That could be a file buffer issue. Nothing will actually be written to 
the disk until either the buffer is full, or you close the file. Try 
calling fh.flush() from time to time, or use:

    print(msg, file=fh, flush=True)


although things may be different on Windows. (For example, you may not be 
able to open the file while it is still open in Python.)



-- 
Steve



From joepareti54 at gmail.com  Sat May  5 12:20:09 2018
From: joepareti54 at gmail.com (joseph pareti)
Date: Sat, 5 May 2018 18:20:09 +0200
Subject: ImportError: cannot import name _remove_dead_weakref
In-Reply-To: <87a7tetw34.fsf@handshake.de>
References: <CAN_spzg61xpkpuVYcR+BNg61LyMi=x-UHkBQCP1LmU5c6nV+Uw@mail.gmail.com>
 <CAPTjJmr3uYYT3omaB+TdtrYutjMs3iN_xkZX0axeyVAbEqR5_g@mail.gmail.com>
 <CAN_spzhxhfx7=BJvLmxmjTjqY4sVDFOL01zOsc1KT7adtH8keA@mail.gmail.com>
 <CAPTjJmqUg8=+VzgxNsiA=PeUfXxWd4_gVvKpKQGV2x7hfLxmCw@mail.gmail.com>
 <877eokrmma.fsf@handshake.de>
 <CAN_spzjbCsBM4o=zTEQfT=2SyKLJ4N+rThgn94o5xpW8GyiJMw@mail.gmail.com>
 <87a7tetw34.fsf@handshake.de>
Message-ID: <CAN_spzigTELMbZfXOHFG36tHAUT4y2CMGx1-92779uX0upVSiA@mail.gmail.com>

thanks for the hint, virtualenv looks like an interesting option, however
in my case I need to rely on several components that are already installed
in the VM in Azure, including tensorflow, etc.
If I use virtualenv, do I  need to start from scratch?

In addition, I am not sure this will solve my problem: all I have seen is
that the error code changes depending on the PYTHONPATH value. Perhaps it
is a bug in the application code?

2018-05-05 9:12 GMT+02:00 dieter <dieter at handshake.de>:

> joseph pareti <joepareti54 at gmail.com> writes:
> > thank you for the advice: depending on the value of PYTHONPATH (version
> > 2.7, 3.5, or unset), tensorflow stops with 3 different error traps
>
> "PYTHONPATH" usually is used when you have private Python modules
> not installed at the standard place. Nowadays, you can use
> a so called "virtual environment" for your local installations.
> Look whether "virtualenv" (or "venv") is installed in your environment.
> It can be used to create a virtual environment.
> Then install your own modules in this virtual environment --
> ensuring not to mix things for Python 2 and Python 3.
> Finally unset "PYTHONPATH" and run your Python in the virtual environment.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>


From brgrt2 at gmail.com  Sat May  5 12:57:19 2018
From: brgrt2 at gmail.com (T Berger)
Date: Sat, 5 May 2018 09:57:19 -0700 (PDT)
Subject: Meaning of abbreviated terms
Message-ID: <4f2a7e16-1b4d-4852-bc56-2d0b07c72209@googlegroups.com>

What does the "p" in "plist" stand for?
Is there a python glossary that spells out the meanings of abbreviated terms?


From storchaka at gmail.com  Sat May  5 13:11:28 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sat, 5 May 2018 20:11:28 +0300
Subject: Why is calling eval so slow?
In-Reply-To: <pckl22$16m$8@blaine.gmane.org>
References: <pckl22$16m$8@blaine.gmane.org>
Message-ID: <pckoft$g85$1@blaine.gmane.org>

05.05.18 19:10, Steven D'Aprano ????:
> # calling a regular function
> python3.5 -m timeit -s "f = lambda: 99" "f()"
> # evaluating a function code object
> python3.5 -m timeit -s "f = (lambda: 99).__code__" "eval(f)"
> # estimate the overhead of the eval name lookup
> python3.5 -m timeit "eval"
> # evaluating a pre-compiled byte-code object
> python3.5 -m timeit -s "f = compile('99', '', 'eval')" "eval(f)"
> # evaluating a string
> python3.5 -m timeit "eval('99')"
> 
> 
> And the results on my computer:
> 
> # call a regular function
> 1000000 loops, best of 3: 0.245 usec per loop
> # evaluate the function __code__ object
> 1000000 loops, best of 3: 1.16 usec per loop
> # overhead of looking up "eval"
> 10000000 loops, best of 3: 0.11 usec per loop
> 
> 
> which means it takes four times longer to execute the code object alone,
> compared to calling the function object which executes the code object.
> 
> Why so slow?

1. Add an overhead of calling eval(), not just looking up its name. It 
is comparable with a time of calling a simple lambda.
2. Add an overhead of getting the globals dict and creating a locals dict.

$ python3.6 -m timeit -s "f = lambda: 99" "f()"
10000000 loops, best of 3: 0.0658 usec per loop
$ python3.6 -m timeit -s "f = (lambda: 99).__code__" "eval(f)"
1000000 loops, best of 3: 0.282 usec per loop
$ python3.6 -m timeit "eval"
10000000 loops, best of 3: 0.0226 usec per loop
$ python3.6 -m timeit -s "f = (lambda: 99).__code__; g = {}" "eval(f, g)"
10000000 loops, best of 3: 0.165 usec per loop

0.0658*2 + 0.0226 = 0.1542. It is comparable with 0.165.



From tjreedy at udel.edu  Sat May  5 14:25:29 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 5 May 2018 14:25:29 -0400
Subject: ipython install
In-Reply-To: <d81bde76-acb1-4ec6-8ad4-2d135b03f752@googlegroups.com>
References: <337a7b81-23fc-4a57-b2dd-0914033a6b3c@googlegroups.com>
 <pcjtae$16m$5@blaine.gmane.org>
 <mailman.7.1525512738.31762.python-list@python.org>
 <d81bde76-acb1-4ec6-8ad4-2d135b03f752@googlegroups.com>
Message-ID: <pcksqo$vhh$1@blaine.gmane.org>

On 5/5/2018 6:09 AM, Sharan Basappa wrote:
> On Saturday, 5 May 2018 15:02:33 UTC+5:30, Steven D'Aprano  wrote:
>> On Sat, 05 May 2018 00:20:26 -0700, Sharan Basappa wrote:
>>
>>> After this, when I type ipython on command prompt, I don't get anything
>>> on my windows.
>>
>> You don't get *anything*? Not even an error?
>>
>>
>>
>> -- 
>> Steve
> 
> like typical behaviour when you don't have the application installed on your computer, it actually open up a browser and gives results for ipython using bing

I have not seen Command Prompt do that on Win 10 or any other Windows.

C:\Users\Terry>ipython
'ipython' is not recognized as an internal or external command,
operable program or batch file.

Maybe you have some malware that wraps Command Prompt.


-- 
Terry Jan Reedy



From python at mrabarnett.plus.com  Sat May  5 18:45:21 2018
From: python at mrabarnett.plus.com (MRAB)
Date: Sat, 5 May 2018 23:45:21 +0100
Subject: Meaning of abbreviated terms
In-Reply-To: <4f2a7e16-1b4d-4852-bc56-2d0b07c72209@googlegroups.com>
References: <4f2a7e16-1b4d-4852-bc56-2d0b07c72209@googlegroups.com>
Message-ID: <fe18b054-255e-1fcb-fde7-1d88697711a3@mrabarnett.plus.com>

On 2018-05-05 17:57, T Berger wrote:
> What does the "p" in "plist" stand for?
> Is there a python glossary that spells out the meanings of abbreviated terms?
> 
"plist" is "property list". It's listed in the Python documentation.


From steve+comp.lang.python at pearwood.info  Sat May  5 22:29:03 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sun, 6 May 2018 02:29:03 +0000 (UTC)
Subject: Why is calling eval so slow?
References: <pckl22$16m$8@blaine.gmane.org> <pckoft$g85$1@blaine.gmane.org>
Message-ID: <pclp9f$16m$10@blaine.gmane.org>

On Sat, 05 May 2018 20:11:28 +0300, Serhiy Storchaka wrote:

>> Why so slow?
> 
> 1. Add an overhead of calling eval(), not just looking up its name. It
> is comparable with a time of calling a simple lambda. 2. Add an overhead
> of getting the globals dict and creating a locals dict.
[...]

Ah, that makes sense.

So presumably the fastest way to run some code in Python is to put it 
into a function and call the function, rather than playing with eval or 
exec, right?



Thanks.



-- 
Steve



From songofacandy at gmail.com  Sun May  6 00:53:48 2018
From: songofacandy at gmail.com (INADA Naoki)
Date: Sun, 06 May 2018 04:53:48 +0000
Subject: ImportError: cannot import name _remove_dead_weakref
In-Reply-To: <CAN_spzigTELMbZfXOHFG36tHAUT4y2CMGx1-92779uX0upVSiA@mail.gmail.com>
References: <CAN_spzg61xpkpuVYcR+BNg61LyMi=x-UHkBQCP1LmU5c6nV+Uw@mail.gmail.com>
 <CAPTjJmr3uYYT3omaB+TdtrYutjMs3iN_xkZX0axeyVAbEqR5_g@mail.gmail.com>
 <CAN_spzhxhfx7=BJvLmxmjTjqY4sVDFOL01zOsc1KT7adtH8keA@mail.gmail.com>
 <CAPTjJmqUg8=+VzgxNsiA=PeUfXxWd4_gVvKpKQGV2x7hfLxmCw@mail.gmail.com>
 <877eokrmma.fsf@handshake.de>
 <CAN_spzjbCsBM4o=zTEQfT=2SyKLJ4N+rThgn94o5xpW8GyiJMw@mail.gmail.com>
 <87a7tetw34.fsf@handshake.de>
 <CAN_spzigTELMbZfXOHFG36tHAUT4y2CMGx1-92779uX0upVSiA@mail.gmail.com>
Message-ID: <CAEfz+TyoqS14Qn7L5kaufb1a1YOJ2eJDnXAwX5DhRmP04U0v9A@mail.gmail.com>

On Sun, May 6, 2018 at 1:22 AM joseph pareti <joepareti54 at gmail.com> wrote:

> thanks for the hint, virtualenv looks like an interesting option, however
> in my case I need to rely on several components that are already installed
> in the VM in Azure, including tensorflow, etc.
> If I use virtualenv, do I  need to start from scratch?

> In addition, I am not sure this will solve my problem: all I have seen is
> that the error code changes depending on the PYTHONPATH value. Perhaps it
> is a bug in the application code?


Unlikely.
You didn't paste different errors.  No one can say right answer.


From storchaka at gmail.com  Sun May  6 00:58:12 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sun, 6 May 2018 07:58:12 +0300
Subject: Why is calling eval so slow?
In-Reply-To: <pclp9f$16m$10@blaine.gmane.org>
References: <pckl22$16m$8@blaine.gmane.org> <pckoft$g85$1@blaine.gmane.org>
 <pclp9f$16m$10@blaine.gmane.org>
Message-ID: <pcm1t1$89e$1@blaine.gmane.org>

06.05.18 05:29, Steven D'Aprano ????:
> On Sat, 05 May 2018 20:11:28 +0300, Serhiy Storchaka wrote:
> 
>>> Why so slow?
>>
>> 1. Add an overhead of calling eval(), not just looking up its name. It
>> is comparable with a time of calling a simple lambda. 2. Add an overhead
>> of getting the globals dict and creating a locals dict.
> [...]
> 
> Ah, that makes sense.
> 
> So presumably the fastest way to run some code in Python is to put it
> into a function and call the function, rather than playing with eval or
> exec, right?

Right. And advanced implementations, like PyPy can apply optimizations 
in this case.

Maybe putting code into an operator implementation will be even faster 
because of getting rid of the part of the overhead of calling a 
functions. Didn't check this.



From sharan.basappa at gmail.com  Sun May  6 01:10:24 2018
From: sharan.basappa at gmail.com (Sharan Basappa)
Date: Sat, 5 May 2018 22:10:24 -0700 (PDT)
Subject: write to file
In-Reply-To: <mailman.13.1525537039.31762.python-list@python.org>
References: <22b11b9d-49b5-4967-a208-7c6ed3d65f90@googlegroups.com>
 <pckbg7$16m$7@blaine.gmane.org>
 <mailman.10.1525526998.31762.python-list@python.org>
 <b5e113b9-20f5-4995-a2e0-d74305e43bdf@googlegroups.com>
 <pckl9f$16m$9@blaine.gmane.org>
 <mailman.13.1525537039.31762.python-list@python.org>
Message-ID: <3272abe2-d7f8-4883-993b-f82f3b16c1c2@googlegroups.com>

On Saturday, 5 May 2018 21:47:33 UTC+5:30, Steven D'Aprano  wrote:
> On Sat, 05 May 2018 08:45:39 -0700, Sharan Basappa wrote:
> 
> > Thanks a lot. I have actually tried print with file handle as a
> > parameter (the last option). I see that the file is created but nothing
> > is logged.
> 
> That could be a file buffer issue. Nothing will actually be written to 
> the disk until either the buffer is full, or you close the file. Try 
> calling fh.flush() from time to time, or use:
> 
>     print(msg, file=fh, flush=True)
> 
> 
> although things may be different on Windows. (For example, you may not be 
> able to open the file while it is still open in Python.)
> 
> 
> 
> -- 
> Steve

Steve,

I agree that flushing could be an issue but I assume when the program closes, buffered data should be  flushed even if I am explicitly flushing. This I did not see happening. Probably, I have to spend some additional time.


From sharan.basappa at gmail.com  Sun May  6 01:11:39 2018
From: sharan.basappa at gmail.com (Sharan Basappa)
Date: Sat, 5 May 2018 22:11:39 -0700 (PDT)
Subject: write to file
In-Reply-To: <mailman.0.1525538138.28519.python-list@python.org>
References: <22b11b9d-49b5-4967-a208-7c6ed3d65f90@googlegroups.com>
 <pck5nd$3q3$1@blaine.gmane.org>
 <mailman.0.1525538138.28519.python-list@python.org>
Message-ID: <f84a39c8-eb4b-4091-bc5d-abc256bc7e37@googlegroups.com>

On Saturday, 5 May 2018 22:05:53 UTC+5:30, Mark Lawrence  wrote:
> On 05/05/18 12:25, Sharan Basappa wrote:
> > In my program, I have print statements for debugging.
> > However, these are cluttering the display. So, I am trying to save
> > these to a file but somehow I cant seem to get it correct.
> 
> Use the logging module https://docs.python.org/3/library/logging.html 
> for debugging, it's far easier in the longer term.
> 
> > 
> > For example, the following are the print statement in my program:
> > print("target_names\n",target_names)
> > 
> > To print to a file, I have opened the file using - fh = open("ML_PY_2.log","w+")
> > Beyond this, I see that fh.write has to be used but most of the examples I see only show how strings are saved.
> > 
> > Can I get input how to covert the above print statement to save into the file?
> 
> You'll need to do some string formatting.  Take your pick from :-
> 
> The old but still heavilly used C style 
> https://docs.python.org/3/library/stdtypes.html#old-string-formatting
> 
> The new style 
> https://docs.python.org/3/library/string.html#format-string-syntax
> 
> If you have Python 3.6 f-strings
> 
> > 
> > Thanks in advance
> > 
> 
> -- 
> My fellow Pythonistas, ask not what our language can do for you, ask
> what you can do for our language.
> 
> Mark Lawrence

Mark,
Thanks a lot. I will take a look at logging module. I have used logger module in perl which really takes out a lot of coding effort


From rosuav at gmail.com  Sun May  6 01:17:57 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sun, 6 May 2018 15:17:57 +1000
Subject: write to file
In-Reply-To: <3272abe2-d7f8-4883-993b-f82f3b16c1c2@googlegroups.com>
References: <22b11b9d-49b5-4967-a208-7c6ed3d65f90@googlegroups.com>
 <pckbg7$16m$7@blaine.gmane.org>
 <mailman.10.1525526998.31762.python-list@python.org>
 <b5e113b9-20f5-4995-a2e0-d74305e43bdf@googlegroups.com>
 <pckl9f$16m$9@blaine.gmane.org>
 <mailman.13.1525537039.31762.python-list@python.org>
 <3272abe2-d7f8-4883-993b-f82f3b16c1c2@googlegroups.com>
Message-ID: <CAPTjJmp2MPU2uit1doyVSSU7BMi01L72ZU1svdjRCdGqq5gehA@mail.gmail.com>

On Sun, May 6, 2018 at 3:10 PM, Sharan Basappa <sharan.basappa at gmail.com> wrote:
> On Saturday, 5 May 2018 21:47:33 UTC+5:30, Steven D'Aprano  wrote:
>> On Sat, 05 May 2018 08:45:39 -0700, Sharan Basappa wrote:
>>
>> > Thanks a lot. I have actually tried print with file handle as a
>> > parameter (the last option). I see that the file is created but nothing
>> > is logged.
>>
>> That could be a file buffer issue. Nothing will actually be written to
>> the disk until either the buffer is full, or you close the file. Try
>> calling fh.flush() from time to time, or use:
>>
>>     print(msg, file=fh, flush=True)
>>
>>
>> although things may be different on Windows. (For example, you may not be
>> able to open the file while it is still open in Python.)
>>
>>
>>
>> --
>> Steve
>
> Steve,
>
> I agree that flushing could be an issue but I assume when the program closes, buffered data should be  flushed even if I am explicitly flushing. This I did not see happening. Probably, I have to spend some additional time.
> --

Can you post a complete (but preferably small) example of a program
that creates a file but doesn't properly write to it?

ChrisA


From sharan.basappa at gmail.com  Sun May  6 12:28:16 2018
From: sharan.basappa at gmail.com (Sharan Basappa)
Date: Sun, 6 May 2018 09:28:16 -0700 (PDT)
Subject: write to file
In-Reply-To: <mailman.7.1525583880.28519.python-list@python.org>
References: <22b11b9d-49b5-4967-a208-7c6ed3d65f90@googlegroups.com>
 <pckbg7$16m$7@blaine.gmane.org>
 <mailman.10.1525526998.31762.python-list@python.org>
 <b5e113b9-20f5-4995-a2e0-d74305e43bdf@googlegroups.com>
 <pckl9f$16m$9@blaine.gmane.org>
 <mailman.13.1525537039.31762.python-list@python.org>
 <3272abe2-d7f8-4883-993b-f82f3b16c1c2@googlegroups.com>
 <CAPTjJmp2MPU2uit1doyVSSU7BMi01L72ZU1svdjRCdGqq5gehA@mail.gmail.com>
 <mailman.7.1525583880.28519.python-list@python.org>
Message-ID: <04619c43-d8e6-4c91-91e7-00903beafcfa@googlegroups.com>

On Sunday, 6 May 2018 10:48:12 UTC+5:30, Chris Angelico  wrote:
> On Sun, May 6, 2018 at 3:10 PM, Sharan Basappa <sharan.basappa at gmail.com> wrote:
> > On Saturday, 5 May 2018 21:47:33 UTC+5:30, Steven D'Aprano  wrote:
> >> On Sat, 05 May 2018 08:45:39 -0700, Sharan Basappa wrote:
> >>
> >> > Thanks a lot. I have actually tried print with file handle as a
> >> > parameter (the last option). I see that the file is created but nothing
> >> > is logged.
> >>
> >> That could be a file buffer issue. Nothing will actually be written to
> >> the disk until either the buffer is full, or you close the file. Try
> >> calling fh.flush() from time to time, or use:
> >>
> >>     print(msg, file=fh, flush=True)
> >>
> >>
> >> although things may be different on Windows. (For example, you may not be
> >> able to open the file while it is still open in Python.)
> >>
> >>
> >>
> >> --
> >> Steve
> >
> > Steve,
> >
> > I agree that flushing could be an issue but I assume when the program closes, buffered data should be  flushed even if I am explicitly flushing. This I did not see happening. Probably, I have to spend some additional time.
> > --
> 
> Can you post a complete (but preferably small) example of a program
> that creates a file but doesn't properly write to it?
> 
> ChrisA

Thanks, Everyone. I was probably making some mistake.
I re-checked again and added file handle to the prints.
Everything works fine.

Below is the code ...

# Imports
from matplotlib import pyplot as plt
from sklearn.datasets import load_iris
import numpy as np
import pickle

fh = open("ML_PY_2.log","w+")
        
# load the data with load_iris from sklearn
data = load_iris()
features = data['data']
feature_names = data['feature_names']
target = data['target']
target_names = data['target_names']
labels = target_names[target]
plength = features[:,2]

# use numpy operations to get setosa features
is_setosa = (labels == 'setosa')
# this the important step
max_setosa = plength[is_setosa].max()
min_non_setosa = plength[~is_setosa].min()

print("data\n",data,file=fh)
print("target\n",target, file=fh)
print("target_names\n",target_names,file=fh)
print("labels\n",labels,file=fh)
print("is_setosa\n",is_setosa,file=fh)
print("plength\n",plength,file=fh)

print('maximum of setosa: {0}.'.format(max_setosa))
print('minimum of others: {0}.'.format(min_non_setosa))

fh.close()


From skip.montanaro at gmail.com  Sun May  6 19:47:44 2018
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Sun, 06 May 2018 23:47:44 +0000
Subject: Tk covering the entire screen
In-Reply-To: <pcjktl$inj$3@blaine.gmane.org>
References: <CANc-5UyDNC2P+7ghEAyf7vqiMovUjyxsZi3CUKrpm4x1BWwzSQ@mail.gmail.com>
 <CANc-5Uz6d7-VZLgw+BXJvS3bxRQ-RcwU0fFnu1VYZjdhKh5azA@mail.gmail.com>
 <pcjktl$inj$3@blaine.gmane.org>
Message-ID: <CANc-5Ux51iRfF7GbvUNA_eY_JietNkHBfoz-A7CuvK73J-2DCQ@mail.gmail.com>

> Try to upgrade to 2.7.15. It should be shipped with Tk 8.6.

Thanks. I'm using an internal (to work) Anaconda distro at work. Hopefully
it will update soon.

Skip


From dieter at handshake.de  Mon May  7 01:44:26 2018
From: dieter at handshake.de (dieter)
Date: Mon, 07 May 2018 07:44:26 +0200
Subject: ImportError: cannot import name _remove_dead_weakref
References: <CAN_spzg61xpkpuVYcR+BNg61LyMi=x-UHkBQCP1LmU5c6nV+Uw@mail.gmail.com>
 <CAPTjJmr3uYYT3omaB+TdtrYutjMs3iN_xkZX0axeyVAbEqR5_g@mail.gmail.com>
 <CAN_spzhxhfx7=BJvLmxmjTjqY4sVDFOL01zOsc1KT7adtH8keA@mail.gmail.com>
 <CAPTjJmqUg8=+VzgxNsiA=PeUfXxWd4_gVvKpKQGV2x7hfLxmCw@mail.gmail.com>
 <877eokrmma.fsf@handshake.de>
 <CAN_spzjbCsBM4o=zTEQfT=2SyKLJ4N+rThgn94o5xpW8GyiJMw@mail.gmail.com>
 <87a7tetw34.fsf@handshake.de>
 <CAN_spzigTELMbZfXOHFG36tHAUT4y2CMGx1-92779uX0upVSiA@mail.gmail.com>
Message-ID: <87muxcdnph.fsf@handshake.de>

joseph pareti <joepareti54 at gmail.com> writes:
> thanks for the hint, virtualenv looks like an interesting option, however
> in my case I need to rely on several components that are already installed
> in the VM in Azure, including tensorflow, etc.
> If I use virtualenv, do I  need to start from scratch?

"virtualenv" has an option which makes the Python packages
installed in the "parent" Python installation available in
the created virtual environment. The "parent" Python installation
is determined by the Python you call "virtualenv" with.
Typically, it is a system Python installation. This way, you
can make your system Python modules and packages available
in your created virtual environment.


> In addition, I am not sure this will solve my problem: all I have seen is
> that the error code changes depending on the PYTHONPATH value. Perhaps it
> is a bug in the application code?

Likely, this alone will not solve your problem -- it might only help
you with a solution.

You have provided detailed error information only in your initial post.
Someone looked at those details and noticed that parts of a
Python 3 and of a Python 2 installation where involved -- which is
a very bad sign. You must ensure that only either Python 2 or Python 3
parts are used by your application - not a mix of both.

In a typical setup, Python 2 and Python 3 installations are well
separated -- not in your case, however. A set "PYTHONPATH"
can cause those installations to interfere with one another.

You reported that unsetting "PYTHONPATH" has changed the observed
behaviour. This indicates, that in your environment, "PYTHONPATH" is
set. A virtual environment is a tool to avoid the need to set
"PYTHONPATH" (which easily confuses setups with both Python 2 and
Python 3 installations).


>From what you describe, I conclude that in your case the "PYTHONPATH"
setting is important for your application.
For a quick fix, I would investigate for which Python version
this setting was designed for and then use this Python version for
your application.

However, as far as we know up to now, your environment has
both Python 2 and Python 3 installed -- and in such an environment,
a (quite) "global" "PYTHONPATH" setting can lead to surprises.
Using "virtualenv"s can avoid the use of "PYTHONPATH"
(another way would be to use a shell wrapper for the applications which sets
"PYTHONPATH" appropriately and then calls the application; then,
you would no longer need a "global" "PYTHONPATH").



From antoon.pardon at vub.be  Mon May  7 03:56:49 2018
From: antoon.pardon at vub.be (Antoon Pardon)
Date: Mon, 7 May 2018 09:56:49 +0200
Subject: itemgetter with default arguments
In-Reply-To: <pcjmkj$c4g$1@blaine.gmane.org>
References: <pchljn$f9u$2@blaine.gmane.org> <pcjmkj$c4g$1@blaine.gmane.org>
Message-ID: <e2773802-b4af-0518-f307-e88d8916a551@vub.be>

On 05-05-18 09:33, Peter Otten wrote:
> I think you have established that there is no straight-forward way to write 
> this as a lambda. But is adding a default to itemgetter the right 
> conclusion?
>
> If there were an exception-catching decorator you could write
>
> f = catch(IndexError, "spam")(itemgetter(2))

I think your catch function would be a usefull addition, but I don't see
it solving this problem once we use itemgetter te get multiple entries.

-- 
Antoon.



From mal at europython.eu  Mon May  7 05:34:38 2018
From: mal at europython.eu (M.-A. Lemburg)
Date: Mon, 7 May 2018 11:34:38 +0200
Subject: EuroPython 2018: Call for Proposals (CFP) is open
Message-ID: <6873cb6c-7d31-c0b7-66ec-388ffda01ece@europython.eu>

We?re looking for proposals on every aspect of Python: programming
from novice to advanced levels, applications and frameworks, or how
you have been involved in introducing Python into your
organization. EuroPython is a community conference and we are eager to
hear about your experience.


       * https://ep2018.europython.eu/en/call-for-proposals/ *


Please also forward this Call for Proposals to anyone that you feel
may be interested.


Important Notice: New Conference Layout
---------------------------------------

Please note that the conference layout has changed compared to
previous years, the main conference (talks) is now only three days:

* Monday and Tuesday:
    trainings, workshops and Beginners? Day only
* Wednesday, Thursday, Friday:
    talks, panels, posters, helpdesks, open sessions, etc.
    (no trainings!)


Submit your proposal
--------------------

       * https://ep2018.europython.eu/en/call-for-proposals/ *

	    Submissions will be open until Sunday, May 20.

Given the compact timing this year, one should not bet on an
extension, please submit your proposals as early as possible - also to
reduce work load of the reviewers. Thank you.

Presenting at EuroPython
------------------------

We will accept a broad range of presentations, from reports on
academic and commercial projects to tutorials and case studies. As
long as the presentation is interesting and potentially useful to the
Python community, it will be considered for inclusion in the program.

Can you show something new and useful? Can you show the attendees how
to: use a module? Explore a Python language feature? Package an
application? If so, please consider submitting a talk.

Submission types
----------------

* Regular Talk / approx. 110 slots
* Trainings / 12 slots.
* Panels
* Interactive
* Posters / 15 slots
* Helpdesk / 6 slots

Tracks
------

You may suggest your submission for a track. Tracks are groups of
talks, covering the same domain (e.g. Django), all in the same room in
a row. You may choose one of these specialized domains / tracks:

* Business Track (running a business, being a freelancer)
* DevOps
* Django Track
* Educational Track
* General Python
* Hardware/IoT Track
* PyData Track
* Science Track
* Web Track

PyData EuroPython 2018
----------------------

As usual, there will be a PyData track at this year?s
conference.

The PyData track is run in cooperation with NumFocus and
the PyData Edinburgh meetup.

Discounts for Content Contributors
----------------------------------

Since EuroPython is a not-for-profit community conference, it is not
possible to pay out rewards for talks or trainings.

For talks, posters, help desk and organizing a panels or interactive
sessions we will give out a 25% discount coupon valid for one
conference ticket.

Trainers will receive a 100% discount coupon for both a conference
ticket and a training pass to compensate for the longer preparation
time.

More details
------------

Since there's a lot more detail to how the CFP works, please check the
CFP page for additional information:

       * https://ep2018.europython.eu/en/call-for-proposals/ *


Enjoy,
--
EuroPython 2018 Team
https://ep2018.europython.eu/
https://www.europython-society.org/


PS: Please forward or retweet to help us reach all interested parties:
https://twitter.com/europython/status/993418719756996608
Thanks.



From r-yan14 at mails.tsinghua.edu.cn  Mon May  7 08:29:05 2018
From: r-yan14 at mails.tsinghua.edu.cn (ruiyan)
Date: Mon, 7 May 2018 20:29:05 +0800 (GMT+08:00)
Subject: use python to log to a remote supercomputer and transfer files
Message-ID: <7b33fae7.69ba.1633a93a6ff.Coremail.r-yan14@mails.tsinghua.edu.cn>

Hello everyone, 


I need to conduct massive simulation computations using a software called 'lammps' on a remote supercomputer whose operating system is Linux every day. It's extremely annoying to log to the remote supercomputer,  upload files to and download files from the supercomputer using WinSCP and Putty on my windows desktop computer. I want to know whether it is possible to write some scripts and let python do these things for me, i.e., I want to log to the remote supercomputer automatically, upload and download files with a simple hit in python (of course with the files specified). Is this possible? If it is possible, which packages do I need? 


Thanks and best wishes,


Rui 

From boblatest at yahoo.com  Mon May  7 11:05:58 2018
From: boblatest at yahoo.com (Robert Latest)
Date: 7 May 2018 15:05:58 GMT
Subject: Weird side effect of default parameter
References: <fl17apFk5kbU1@mid.individual.net> <pchjhf$f9u$1@blaine.gmane.org>
 <mailman.66.1525436927.2789.python-list@python.org>
Message-ID: <flb8amFr0p7U1@mid.individual.net>

Steven D'Aprano wrote:
> Python function default values use *early binding*: the default parameter 
> is evaluated, ONCE, when the function is defined, and that value is used 
> each time it is needed.

Thanks, "early binding" was the clue I was missing.

robert


From __peter__ at web.de  Mon May  7 11:45:26 2018
From: __peter__ at web.de (Peter Otten)
Date: Mon, 07 May 2018 17:45:26 +0200
Subject: itemgetter with default arguments
References: <pchljn$f9u$2@blaine.gmane.org> <pcjmkj$c4g$1@blaine.gmane.org>
 <e2773802-b4af-0518-f307-e88d8916a551@vub.be>
Message-ID: <pcps6p$jiu$1@blaine.gmane.org>

Antoon Pardon wrote:

> On 05-05-18 09:33, Peter Otten wrote:
>> I think you have established that there is no straight-forward way to
>> write this as a lambda. But is adding a default to itemgetter the right
>> conclusion?
>>
>> If there were an exception-catching decorator you could write
>>
>> f = catch(IndexError, "spam")(itemgetter(2))
> 
> I think your catch function would be a usefull addition, but I don't see
> it solving this problem once we use itemgetter te get multiple entries.

Good catch()

;)

The obvious way, expressing the n-tuple case in terms of the solution for 
scalars

>>> f = lambda items: tuple(catch(IndexError, "spam")(itemgetter(i))(items) 
for i in (2, 1, 5))
>>> >>> f("abc")
('c', 'b', 'spam')

is a bit too complex to inline -- and also inefficient. You'd be tempted to 
factor out the repetetive parts

>>> f = lambda items, gets=[catch(IndexError, "spam")(itemgetter(i)) for i 
in (2, 1, 5)]: tuple(get(items) for get in gets)
>>> f("abc")
('c', 'b', 'spam')

and thus make it even less readable.

That said -- grepping my code I'm a bit surprised to find only

17 itemgetter(0)
 9 itemgetter(1)
 1 itemgetter(1, 0)
 1 itemgetter(*indices)

Checking /usr/lib/python3/dist-packages it looks like the situation is 
similar. I conclude that the most useful addition to the operator module 
would be

first = itemgetter(0)
second = itemgetter(1)




From sharan.basappa at gmail.com  Mon May  7 12:53:45 2018
From: sharan.basappa at gmail.com (Sharan Basappa)
Date: Mon, 7 May 2018 09:53:45 -0700 (PDT)
Subject: Module, Package
Message-ID: <7854fb75-4887-49a9-ac17-9d1a2951a801@googlegroups.com>

I am a bit confused between module and package in Python.
Does a module contain package or vice versa?
When we import something in Python, do we import a module or a package?

Thanks


From python at mrabarnett.plus.com  Mon May  7 13:38:08 2018
From: python at mrabarnett.plus.com (MRAB)
Date: Mon, 7 May 2018 18:38:08 +0100
Subject: Module, Package
In-Reply-To: <7854fb75-4887-49a9-ac17-9d1a2951a801@googlegroups.com>
References: <7854fb75-4887-49a9-ac17-9d1a2951a801@googlegroups.com>
Message-ID: <c353e7d3-669b-ebf3-2cea-386e26a7217a@mrabarnett.plus.com>

On 2018-05-07 17:53, Sharan Basappa wrote:
> I am a bit confused between module and package in Python.
> Does a module contain package or vice versa?
> When we import something in Python, do we import a module or a package?
> 
A module is a file. A package is a collection of one or more modules.


From rosuav at gmail.com  Mon May  7 13:39:25 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 8 May 2018 03:39:25 +1000
Subject: Module, Package
In-Reply-To: <7854fb75-4887-49a9-ac17-9d1a2951a801@googlegroups.com>
References: <7854fb75-4887-49a9-ac17-9d1a2951a801@googlegroups.com>
Message-ID: <CAPTjJmr1oufFevRD6kVKxpY_=t=PVDNf4wRU2qUJ1rVjnKzZhA@mail.gmail.com>

On Tue, May 8, 2018 at 2:53 AM, Sharan Basappa <sharan.basappa at gmail.com> wrote:
> I am a bit confused between module and package in Python.
> Does a module contain package or vice versa?
> When we import something in Python, do we import a module or a package?

You import a module.

A package is one particular form of module, which is built out of
other modules (usually a directory full of .py files). There are a
number of different sorts of modules; regardless, you 'import X' and
get module X.

ChrisA


From rosuav at gmail.com  Mon May  7 15:12:30 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 8 May 2018 05:12:30 +1000
Subject: www.python.org down
In-Reply-To: <XzBHC.153176$sc1.147999@fx09.am4>
References: <CANfN=K_0_GTA4VugYF2psGuosojC=Ds2CrgkzGL2c=_KoipMnA@mail.gmail.com>
 <mailman.9.1525110120.2789.python-list@python.org>
 <XzBHC.153176$sc1.147999@fx09.am4>
Message-ID: <CAPTjJmrXc3y1dbP-=urVk-7SONY3ad=UP7aR_MUULKKbucbnNA@mail.gmail.com>

On Sun, May 6, 2018 at 9:22 PM, Gilmeh Serda
<gilmeh.serdah at nothing.here.invalid> wrote:
> On Mon, 30 Apr 2018 10:38:54 -0700, Jorge Gimeno wrote:
>
>> Not sure who to report to, but the site comes back with a 503. Anyone
>> know where I can direct this to?
>
> Why would you report it? Give it at least a day before you're going
> berserk with "reports"! If there's a serious problem, they will see to it
> that a replacement site is launched that will give info on what happened.
> Sit back and stay calm!
>
> Trust me, there is nothing more annoying than having to wade through a
> crapload of "error reports" early in the morning. And especially from
> those morons who end their reports with "What's wrong?" Gee, are you
> coming over to fix things?
>
> I wish I had a penny for every such "report" we receive to our external
> support box, I'd be rich today.
>

So you'd rather the site just stay down until the right person happens
to notice it?

Nice to know that your attitude towards your web site's users is that
they are "morons", and even more indicative that you consider that
people should let the site be down for a minimum of 86,400 seconds
before it's considered serious enough to actually report.

ChrisA


From skip.montanaro at gmail.com  Mon May  7 15:42:55 2018
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Mon, 07 May 2018 19:42:55 +0000
Subject: Tk covering the entire screen
In-Reply-To: <CANc-5Ux51iRfF7GbvUNA_eY_JietNkHBfoz-A7CuvK73J-2DCQ@mail.gmail.com>
References: <CANc-5UyDNC2P+7ghEAyf7vqiMovUjyxsZi3CUKrpm4x1BWwzSQ@mail.gmail.com>
 <CANc-5Uz6d7-VZLgw+BXJvS3bxRQ-RcwU0fFnu1VYZjdhKh5azA@mail.gmail.com>
 <pcjktl$inj$3@blaine.gmane.org>
 <CANc-5Ux51iRfF7GbvUNA_eY_JietNkHBfoz-A7CuvK73J-2DCQ@mail.gmail.com>
Message-ID: <CANc-5UwW48g8c-drXkNymcxdEbb63OwPiahmpNxHcvsz5BHKaQ@mail.gmail.com>

On Sun, May 6, 2018 at 6:47 PM Skip Montanaro <skip.montanaro at gmail.com>
wrote:

> > Try to upgrade to 2.7.15. It should be shipped with Tk 8.6.
>
> Thanks. I'm using an internal (to work) Anaconda distro at work. Hopefully
> it will update soon.
>

?I got everything up-to-date, but still the cover window only covers two of
my three screens when run on Windows. The only thing I can think of which
might be a problem... When I bring up the Screen Resolution control panel,
my screens are numbered 3, 1, 2 left-to-right. Screens 1 and 2 are covered,
not three. If I change the screen order to 1, 2, 3 in the control panel,
The cover window does cover all three screens, but to move the pointer to
screen one, I have to move off the right of screen 3.

Gotta be a Windows thing. I'll call my help desk.

*sigh* I will never figure out Windows.

Skip


From tjreedy at udel.edu  Mon May  7 15:59:10 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 7 May 2018 15:59:10 -0400
Subject: Tracebacks for exceptions in interactively entered code.
Message-ID: <pcqb2c$7k1$1@blaine.gmane.org>

I intend to improve the IDLE doc section on IDLE-console differences.

The following is from standard interactive mode (PSF CPython 3.7.0a4) on 
Windows (Win 10, Command Prompt)

 >>> def f():
...     return 1/0
...
 >>> f()
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "<stdin>", line 2, in f
ZeroDivisionError: division by zero

Each statement is given the same pseudofile name, "<stdin>", lines are 
numbered within each statement, and the code line is not printed.  As 
far as I remember, this has been the same on Windows since forever, 
though only current versions are relevant to current docs.

Is the above also the same on other systems (linux, Mac)?  I would like 
to know before I say so ;-).

By comparison, IDLE prints

 >>> def f():
	return 1/0

 >>> f()
Traceback (most recent call last):
   File "<pyshell#3>", line 1, in <module>
     f()
   File "<pyshell#2>", line 2, in f
     return 1/0
ZeroDivisionError: division by zero

Each statememt has a different pseudofile name (pyshell is the name 
IDLE's shell module) and the code lines are displayed just as when 
running from a real file.

-- 
Terry Jan Reedy



From all-lists at stefan-klinger.de  Mon May  7 16:27:22 2018
From: all-lists at stefan-klinger.de (all-lists at stefan-klinger.de)
Date: Mon, 7 May 2018 22:27:22 +0200
Subject: seeking deeper (language theory) reason behind Python design choice
Message-ID: <20180507202722.GD7876@tauhou>

Hi,

I was wondering (and have asked on StackOverflow [1] in a more
elaborate way) whether there is a deeper reason to not allow
assignments in lambda expressions.

I'm not criticising, I'm asking in order to know ;-)

The surface-reason is the distinction between assignments and
statements, but why it was designed this way (with respect to lambda,
not in general)?

So far, no satisfying answer has come up, except for maybe to avoid a
programmer accidentally typing `=` instead of `==`, which I find a bit
unsatisfying as the only reason.

There's a bounty on the StackOverflow question.

Thanks for reading!
Stefan

____________________
[1] https://stackoverflow.com/questions/50090868/why-are-assignments-not-allowed-in-pythons-lambda-expressions


--
http://stefan-klinger.de                                      o/X
Send plain text messages only, not exceeding 32kB.            /\/
                                                                \


From python at mrabarnett.plus.com  Mon May  7 16:33:09 2018
From: python at mrabarnett.plus.com (MRAB)
Date: Mon, 7 May 2018 21:33:09 +0100
Subject: use python to log to a remote supercomputer and transfer files
In-Reply-To: <7b33fae7.69ba.1633a93a6ff.Coremail.r-yan14@mails.tsinghua.edu.cn>
References: <7b33fae7.69ba.1633a93a6ff.Coremail.r-yan14@mails.tsinghua.edu.cn>
Message-ID: <82108cf3-0862-d25e-2a8f-48a5ec4646c3@mrabarnett.plus.com>

On 2018-05-07 13:29, ruiyan wrote:
> Hello everyone,
> 
> 
> I need to conduct massive simulation computations using a software called 'lammps' on a remote supercomputer whose operating system is Linux every day. It's extremely annoying to log to the remote supercomputer,  upload files to and download files from the supercomputer using WinSCP and Putty on my windows desktop computer. I want to know whether it is possible to write some scripts and let python do these things for me, i.e., I want to log to the remote supercomputer automatically, upload and download files with a simple hit in python (of course with the files specified). Is this possible? If it is possible, which packages do I need?
> 
> 
> Thanks and best wishes,
> 
There are some examples about scripting in WinSCP here:

https://winscp.net/eng/docs/scripting


From irving.duran at gmail.com  Mon May  7 16:37:37 2018
From: irving.duran at gmail.com (Irving Duran)
Date: Mon, 07 May 2018 20:37:37 +0000
Subject: use python to log to a remote supercomputer and transfer files
In-Reply-To: <82108cf3-0862-d25e-2a8f-48a5ec4646c3@mrabarnett.plus.com>
References: <7b33fae7.69ba.1633a93a6ff.Coremail.r-yan14@mails.tsinghua.edu.cn>
 <82108cf3-0862-d25e-2a8f-48a5ec4646c3@mrabarnett.plus.com>
Message-ID: <CAC9TaS46spDWyxPF8+yUUAWDqT8J-2zYxNUfkKN4pKjJyz+wow@mail.gmail.com>

You can also explore this package -> https://github.com/paramiko/paramiko
in order to be able to download or upload the files.

Thank You,

Irving Duran


On Mon, May 7, 2018 at 3:34 PM MRAB <python at mrabarnett.plus.com> wrote:

> On 2018-05-07 13:29, ruiyan wrote:
> > Hello everyone,
> >
> >
> > I need to conduct massive simulation computations using a software
> called 'lammps' on a remote supercomputer whose operating system is Linux
> every day. It's extremely annoying to log to the remote supercomputer,
> upload files to and download files from the supercomputer using WinSCP and
> Putty on my windows desktop computer. I want to know whether it is possible
> to write some scripts and let python do these things for me, i.e., I want
> to log to the remote supercomputer automatically, upload and download files
> with a simple hit in python (of course with the files specified). Is this
> possible? If it is possible, which packages do I need?
> >
> >
> > Thanks and best wishes,
> >
> There are some examples about scripting in WinSCP here:
>
> https://winscp.net/eng/docs/scripting
> --
> https://mail.python.org/mailman/listinfo/python-list
>


From rosuav at gmail.com  Mon May  7 17:47:24 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 8 May 2018 07:47:24 +1000
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <20180507202722.GD7876@tauhou>
References: <20180507202722.GD7876@tauhou>
Message-ID: <CAPTjJmprLt_4QGJex4o=SO4-cDqJap5uy_P053Mgae1_mFRAcw@mail.gmail.com>

On Tue, May 8, 2018 at 6:27 AM,  <all-lists at stefan-klinger.de> wrote:
> Hi,
>
> I was wondering (and have asked on StackOverflow [1] in a more
> elaborate way) whether there is a deeper reason to not allow
> assignments in lambda expressions.
>
> I'm not criticising, I'm asking in order to know ;-)
>
> The surface-reason is the distinction between assignments and
> statements, but why it was designed this way (with respect to lambda,
> not in general)?
>
> So far, no satisfying answer has come up, except for maybe to avoid a
> programmer accidentally typing `=` instead of `==`, which I find a bit
> unsatisfying as the only reason.

What exactly would be the scope of the assigned name? Let's say we
have a fairly typical use of a lambda function:

items.sort(key=lambda item: item.creation_date)

Now let's change that a bit. How would assignment fit into that?

def sort_func(item):
    date = parse_date(item.creation_date)
    return date.day_of_week, date.year, date.month, date.day
items.sort(key=sort_func)

Makes sense - now we're putting everything made on a Tuesday before
everything made on a Friday (I'm sure that's important to someone,
somewhere). So obviously any assignment should be local to the lambda
function, right?

What about this lambda function?

click_count = 0
b = Button(master, text="Click me", command=lambda: click_count += 1)
b.pack()

Equally obviously, this assignment belongs in the surrounding scope.
It can't be both, though. How should that be resolved?

If you want a way to do assignment as part of an expression, join the
discussions about PEP 572. Have fun; it's probably approaching a
thousand emails so far.

ChrisA


From alexey.muranov at gmail.com  Mon May  7 18:02:34 2018
From: alexey.muranov at gmail.com (Alexey Muranov)
Date: Tue, 08 May 2018 00:02:34 +0200
Subject: Problem/bug with class definition inside function definition
Message-ID: <1525730554.24805.0@smtp.gmail.com>

I have discovered the following bug or problem: it looks like i am 
forced to choose different names for class attributes and function 
arguments, and i see no workaround.  Am i missing some special syntax 
feature ?

Alexey.

---
x = 42

class C1:
    y = x  # Works

class C2:
    x = x  # Works

# ---
def f1(a):
    class D:
        b = a  # Works
    return D

def f2(a):
    class D:
        a = a  # Does not work <<<<<
    return D

def f3(a):
    class D:
        nonlocal a
        a = a  # Does not work either <<<<<
    return D

# ---
def g1(a):
    def h():
        b = a  # Works
        return b
    return h

def g2(a):
    def h():
        a = a  # Does not work (as expected)
        return a
    return h

def g3(a):
    def h():
        nonlocal a
        a = a  # Works
        return a
    return h

# ---
if __name__ == "__main__":
    assert C1.y == 42
    assert C2.x == 42

    assert f1(13).b == 13

    try:
        f2(13)  # NameError
    except NameError:
        pass
    except Exception as e:
        raise Exception( 'Unexpected exception raised: '
                         '{}'.format(type(e).__name__) )
    else:
        raise Exception('No exception')

    try:
        f3(13).a  # AttributeError
    except AttributeError:
        pass
    except Exception as e:
        raise Exception( 'Unexpected exception raised: '
                         '{}'.format(type(e).__name__) )
    else:
        raise Exception('No exception')

    assert g1(13)() == 13

    try:
        g2(13)()  # UnboundLocalError
    except UnboundLocalError:
        pass
    except Exception as e:
        raise Exception( 'Unexpected exception raised: '
                         '{}'.format(type(e).__name__) )
    else:
        raise Exception('No exception')

    assert g3(13)() == 13



From alexey.muranov at gmail.com  Mon May  7 18:21:00 2018
From: alexey.muranov at gmail.com (Alexey Muranov)
Date: Tue, 08 May 2018 00:21:00 +0200
Subject: Problem/bug with class definition inside function definition
In-Reply-To: <1525730554.24805.0@smtp.gmail.com>
References: <1525730554.24805.0@smtp.gmail.com>
Message-ID: <1525731660.30323.0@smtp.gmail.com>

To be more exact, i do see a few workarounds, for example:


    def f4(a):
        b = a
        class D:
            a = b  # Works
        return D

But this is not what i was hoping for.

Alexey.

On Tue, 8 May, 2018 at 12:02 AM, Alexey Muranov 
<alexey.muranov at gmail.com> wrote:
> I have discovered the following bug or problem: it looks like i am 
> forced to choose different names for class attributes and function 
> arguments, and i see no workaround.  Am i missing some special syntax 
> feature ?
> 
> Alexey.
> 
> ---
> x = 42
> 
> class C1:
>    y = x  # Works
> 
> class C2:
>    x = x  # Works
> 
> # ---
> def f1(a):
>    class D:
>        b = a  # Works
>    return D
> 
> def f2(a):
>    class D:
>        a = a  # Does not work <<<<<
>    return D
> 
> def f3(a):
>    class D:
>        nonlocal a
>        a = a  # Does not work either <<<<<
>    return D
> 
> # ---
> def g1(a):
>    def h():
>        b = a  # Works
>        return b
>    return h
> 
> def g2(a):
>    def h():
>        a = a  # Does not work (as expected)
>        return a
>    return h
> 
> def g3(a):
>    def h():
>        nonlocal a
>        a = a  # Works
>        return a
>    return h
> 
> # ---
> if __name__ == "__main__":
>    assert C1.y == 42
>    assert C2.x == 42
> 
>    assert f1(13).b == 13
> 
>    try:
>        f2(13)  # NameError
>    except NameError:
>        pass
>    except Exception as e:
>        raise Exception( 'Unexpected exception raised: '
>                         '{}'.format(type(e).__name__) )
>    else:
>        raise Exception('No exception')
> 
>    try:
>        f3(13).a  # AttributeError
>    except AttributeError:
>        pass
>    except Exception as e:
>        raise Exception( 'Unexpected exception raised: '
>                         '{}'.format(type(e).__name__) )
>    else:
>        raise Exception('No exception')
> 
>    assert g1(13)() == 13
> 
>    try:
>        g2(13)()  # UnboundLocalError
>    except UnboundLocalError:
>        pass
>    except Exception as e:
>        raise Exception( 'Unexpected exception raised: '
>                         '{}'.format(type(e).__name__) )
>    else:
>        raise Exception('No exception')
> 
>    assert g3(13)() == 13
> 



From mail at stefan-klinger.de  Mon May  7 18:52:01 2018
From: mail at stefan-klinger.de (Stefan Klinger)
Date: Tue, 8 May 2018 00:52:01 +0200
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <CAPTjJmprLt_4QGJex4o=SO4-cDqJap5uy_P053Mgae1_mFRAcw@mail.gmail.com>
References: <20180507202722.GD7876@tauhou>
 <CAPTjJmprLt_4QGJex4o=SO4-cDqJap5uy_P053Mgae1_mFRAcw@mail.gmail.com>
Message-ID: <20180507225201.GA14196@tauhou>

Chris Angelico (2018-May-08, excerpt):
> What exactly would be the scope of the assigned name?

Yes, that's more like the kind of answer I was seeking.  But I'm not
entirely satisfied.

> def sort_func(item):
>     date = parse_date(item.creation_date)
>     return date.day_of_week, date.year, date.month, date.day
> items.sort(key=sort_func)

This function contains two statements.  Would be nice to see a
one-statement variant that exposes the same necessity of local
assignment.

I have not thought about local assignment expressions, but they can
already now be done naturally as follows:

    lambda item: (lambda date: date.day_of_week, date.year, date.month, date.day)(parse_date(item.creation_date)

But this is stretching the usefulness of Python's lambda (readability)
quite a bit, I have to admit.

Anyway, I was rather thinking about global assignment.  And there
would even be choice in whether it should be always global, Python has
a rule for that in the following case:

    x = 23

    def foo(y):
        x = 2 * y                       # this is local
        print('x in foo', x)

    print('x before foo', x)
    foo(42)
    print('x after foo', x)


    class z:
        v = 12345

    def bar(y):
        z.v = 2 * y                     # this is global
        print('z.v in bar', z.v)

    print('z.v before bar', z.v)
    bar(0)
    print('z.v after bar', z.v)

Cheers
Stefan


--
http://stefan-klinger.de                                      o/X
Send plain text messages only, not exceeding 32kB.            /\/
                                                                \


From steve+comp.lang.python at pearwood.info  Mon May  7 20:20:52 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Tue, 8 May 2018 00:20:52 +0000 (UTC)
Subject: Tracebacks for exceptions in interactively entered code.
References: <pcqb2c$7k1$1@blaine.gmane.org>
Message-ID: <pcqqh4$16m$11@blaine.gmane.org>

On Mon, 07 May 2018 15:59:10 -0400, Terry Reedy wrote:

> I intend to improve the IDLE doc section on IDLE-console differences.
> 
> The following is from standard interactive mode (PSF CPython 3.7.0a4) on
> Windows (Win 10, Command Prompt)
> 
>  >>> def f():
> ...     return 1/0
> ...
>  >>> f()
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>    File "<stdin>", line 2, in f
> ZeroDivisionError: division by zero
> 
> Each statement is given the same pseudofile name, "<stdin>", lines are
> numbered within each statement, and the code line is not printed.  As
> far as I remember, this has been the same on Windows since forever,
> though only current versions are relevant to current docs.
> 
> Is the above also the same on other systems (linux, Mac)?  I would like
> to know before I say so ;-).

Its the same here:

[steve at ando Python-3.6.4]$ ./python -E
Python 3.6.4 (default, Apr  2 2018, 12:16:49)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-55)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> def f():
...     return 1/x
...
>>> f()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in f
NameError: name 'x' is not defined



-- 
Steve



From steve+comp.lang.python at pearwood.info  Mon May  7 20:45:29 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Tue, 8 May 2018 00:45:29 +0000 (UTC)
Subject: seeking deeper (language theory) reason behind Python design
 choice
References: <20180507202722.GD7876@tauhou>
Message-ID: <pcqrv9$16m$12@blaine.gmane.org>

On Mon, 07 May 2018 22:27:22 +0200, all-lists wrote:

> Hi,
> 
> I was wondering (and have asked on StackOverflow [1] in a more elaborate
> way) whether there is a deeper reason to not allow assignments in lambda
> expressions.

Currently, the real reason is that lambda expressions are limited to a 
single expression as the body of the function, and binding operations in 
Python are statements. It is as simple as that: you can't have

    y = x + 1

inside a lambda for the same reason you can't have

    import spam
    while condition:
        try:
            this()
        except Exception:
            pass

Because lambda takes a single expression.

And the reason for *that* limitation is that after 20+ years of looking, 
nobody has come up with a satisfactory syntax for a multiple statement 
block expression which:

- is not ambiguous

- can be parsed by an LL(1) parser

- and meets Guido's approval.


Nobody has quite ruled out a block expression, in fact it is one of the 
acknowledged useful features which Ruby has that Python doesn't. So its 
not like we don't want it. Its just hard to do without ambiguity or a 
more complex parser.


> 
> I'm not criticising, I'm asking in order to know ;-)
> 
> The surface-reason is the distinction between assignments and
> statements, but why it was designed this way (with respect to lambda,
> not in general)?
> 
> So far, no satisfying answer has come up, except for maybe to avoid a
> programmer accidentally typing `=` instead of `==`, which I find a bit
> unsatisfying as the only reason.

No, that's the reason why = is a statement not an expression. That's not 
why statements aren't allowed in lambdas. If we had blocks, this would be 
perfectly acceptable:

lambda arg: %%%START BLOCK
    spam = arg + 1
    ...
    %%%END BLOCK

since = in a statement on its own is not dangerous. People *almost never* 
intend to write == for the side-effects only:

    # don't care whether they are actually equal or not
    # just want to call the __eq__ method for its side-effects
    spam == arg + 1

Since that never happens in real life, there's no risk of accidentally 
writing "spam = arg + 1" when you wanted "spam == arg + 1".




-- 
Steve



From sharan.basappa at gmail.com  Mon May  7 22:32:36 2018
From: sharan.basappa at gmail.com (Sharan Basappa)
Date: Mon, 7 May 2018 19:32:36 -0700 (PDT)
Subject: Module, Package
In-Reply-To: <mailman.14.1525714768.28519.python-list@python.org>
References: <7854fb75-4887-49a9-ac17-9d1a2951a801@googlegroups.com>
 <CAPTjJmr1oufFevRD6kVKxpY_=t=PVDNf4wRU2qUJ1rVjnKzZhA@mail.gmail.com>
 <mailman.14.1525714768.28519.python-list@python.org>
Message-ID: <735c0bba-c64e-4050-945e-d30a5ed0ff41@googlegroups.com>

On Monday, 7 May 2018 23:09:41 UTC+5:30, Chris Angelico  wrote:
> On Tue, May 8, 2018 at 2:53 AM, Sharan Basappa <sharan.basappa at gmail.com> wrote:
> > I am a bit confused between module and package in Python.
> > Does a module contain package or vice versa?
> > When we import something in Python, do we import a module or a package?
> 
> You import a module.
> 
> A package is one particular form of module, which is built out of
> other modules (usually a directory full of .py files). There are a
> number of different sorts of modules; regardless, you 'import X' and
> get module X.
> 
> ChrisA

Thank you very much. Much appreiated


From sharan.basappa at gmail.com  Mon May  7 22:46:01 2018
From: sharan.basappa at gmail.com (Sharan Basappa)
Date: Mon, 7 May 2018 19:46:01 -0700 (PDT)
Subject: Module, Package
In-Reply-To: <mailman.14.1525714768.28519.python-list@python.org>
References: <7854fb75-4887-49a9-ac17-9d1a2951a801@googlegroups.com>
 <CAPTjJmr1oufFevRD6kVKxpY_=t=PVDNf4wRU2qUJ1rVjnKzZhA@mail.gmail.com>
 <mailman.14.1525714768.28519.python-list@python.org>
Message-ID: <acb5dcdf-3d55-47d1-a1ba-af3951d664a5@googlegroups.com>

MRAB, ChirisA,

One question. So, we can import the entire package or just a module in a given package. Is this correct?

For example,
import nltk
import nltk.stem


From ben+python at benfinney.id.au  Mon May  7 23:00:27 2018
From: ben+python at benfinney.id.au (Ben Finney)
Date: Tue, 08 May 2018 13:00:27 +1000
Subject: Module, Package
References: <7854fb75-4887-49a9-ac17-9d1a2951a801@googlegroups.com>
 <CAPTjJmr1oufFevRD6kVKxpY_=t=PVDNf4wRU2qUJ1rVjnKzZhA@mail.gmail.com>
 <mailman.14.1525714768.28519.python-list@python.org>
 <acb5dcdf-3d55-47d1-a1ba-af3951d664a5@googlegroups.com>
Message-ID: <85y3guonqs.fsf@benfinney.id.au>

Sharan Basappa <sharan.basappa at gmail.com> writes:

> One question. So, we can import the entire package or just a module in
> a given package. Is this correct?

Each time you ?import foo?, you are getting a module.

> For example,
> import nltk

That results in a module object, and you can use the name ?nltk? to
reference that module.

> import nltk.stem

That results in a different module object, and you can use the name
?nltk.stem? (which is the name ?stem? in the namespace ?nltk?) to
reference that module.

See the Python documentation for a good description of the import system
<URL:https://docs.python.org/3/reference/import.html>.

-- 
 \          ?If we could change ourselves, the tendencies in the world |
  `\  would also change.? ?Mohandas K. Gandhi, _Collected Works_, 1913 |
_o__)                                                                  |
Ben Finney



From mikhailwas at gmail.com  Mon May  7 23:45:05 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Tue, 8 May 2018 06:45:05 +0300
Subject: Suggestion for a "data" object syntax
Message-ID: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>

Here is an idea for 'data object' a syntax.
For me it is interesting, how would users find such syntax.
I personally find that this should be attractive from users
perspective.
Main aim is more readable presenting of typical data chunks
and some typical data types (tuples/lists) directly in code.
Further this should significantly simplify typing.

*Example 1. Multi-line strings*

Here is a 3 lines multi-line string, it will be automatically 'dedented'
by the parser by one level of indent:

data === S :
    this is multi-line string
    escape chars: same as in strings (\\, \\n, \\t ...) ,
    but "no need to 'escape' quotes"

(Of course, assuming this feature will be added to the lexers
of your editor, otherwise it may mess up syntax highlighting)

So the proposed statement header is like:

variable === "type" :
    ...

The "===" token and type id's are of course subject to discussion.
"type" is type of data, which tells the parser to
convert data to specific type of Python object.
The above is type "S", a multi-line string.


*Example 2. Tuples*

Tuple is a data block with normal Python elements.

data === T :
    1    2    3    "hello"
    a    b    c + d

Here the separators of elements are : tab character,
new line (and maybe some white-space character like em-space?)
The above construct will be direct synonym for:

data = (1, 2, 3, "hello", a, b, c + d)

Benefits are easy to see: say I want a tuple of strings:

data === T :
    "foo bar"
    "hello world"
    "to be continued..."

VS current:

data = (
    "foo bar" ,
    "hello world" ,
    "to be continued..." ,
    )

Main problem with the latter are commas, it is not easy
to type and, whats more important - hard to notice missing commas.
And brackets of course does not make it nicer either.

The above are typical cases where I see clear win, and
IMO they are quite common constructs.

More complicated examples :


*Example 3. Two-dimensional tuple.*

data === T/T :
    1    2    3    "hello"
    a    b     c + d    e     f

is a synonym for:

data = (
    (1, 2, 3, "hello") ,
    (a, b, c + d, e, f ) )

The rule here is: TAB character is inner elements' separator, and the
new line is outer elements' separator. Line continuation
character is  \  (to help with long lines).

*The benefits is just as in above examples :
readability and 'typeability' boost.*

To present nesting of elements of higher than 2 levels,
normal Python syntax can be used for deeper nesting:

data === T/T :
    1    2    (3    4    5)
    a    b     c

Or maybe even allow commas:
data === T/T :
    1    2    (3, 4, 5)
    a    b     c

VS normal:

data = (
    (1, 2, (3, 4, 5) ) ,
    (a, b, c ) )

So the idea is to cover only first two levels of
nesting of course.

Further, common types may be defined, like e.g. L/L (list of lists)
but I don't want to go far into details and want to stop
on common cases to help evaluate the idea in general.


*Main rules: *
- the definition is allowed  only as a statement (no passing as argument)
- (imo) data starts always as a new line after the header
- implicit string concatenation disallowed


So the question is, how do you like such syntax, and
if so, what common examples can be fit in here.
Any ideas, comments are of course welcome.
Suggest some data and I'll try to express it in this syntax.



M


From storchaka at gmail.com  Tue May  8 01:27:20 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Tue, 8 May 2018 08:27:20 +0300
Subject: Tracebacks for exceptions in interactively entered code.
In-Reply-To: <pcqb2c$7k1$1@blaine.gmane.org>
References: <pcqb2c$7k1$1@blaine.gmane.org>
Message-ID: <pcrcbl$p2g$1@blaine.gmane.org>

07.05.18 22:59, Terry Reedy ????:
> I intend to improve the IDLE doc section on IDLE-console differences.

Don't haste to document it. The behavior of the standard interactive 
mode can be changed in 3.8.



From greg.ewing at canterbury.ac.nz  Tue May  8 02:07:52 2018
From: greg.ewing at canterbury.ac.nz (Gregory Ewing)
Date: Tue, 08 May 2018 18:07:52 +1200
Subject: Problem/bug with class definition inside function definition
In-Reply-To: <classes-20180507232622@ram.dialup.fu-berlin.de>
References: <1525730554.24805.0@smtp.gmail.com>
 <mailman.23.1525730558.28519.python-list@python.org>
 <classes-20180507232622@ram.dialup.fu-berlin.de>
Message-ID: <flct5qF7k8mU1@mid.individual.net>

Python 3.5.1 (default, Jun  1 2016, 13:15:26)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> def f(a):
...  class D:
...   pass
...  D.a = a
...  return D
...
 >>> c = f(42)
 >>> c
<class '__main__.f.<locals>.D'>
 >>> c.a
42

-- 
Greg


From steve+comp.lang.python at pearwood.info  Tue May  8 03:15:22 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Tue, 8 May 2018 07:15:22 +0000 (UTC)
Subject: Suggestion for a "data" object syntax
References: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
Message-ID: <pcriqa$16m$13@blaine.gmane.org>

On Tue, 08 May 2018 06:45:05 +0300, Mikhail V wrote:

> *Example 3. Two-dimensional tuple.*
> 
> data === T/T :
>     1    2    3    "hello"
>     a    b     c + d    e     f
> 
> is a synonym for:
> 
> data = (
>     (1, 2, 3, "hello") ,
>     (a, b, c + d, e, f ) )

Last time you brought up this idea, you were told that it is ambiguous. 
Using whitespace alone, it is impossible to distinguish between

    a + b

and 

    a + b


Can you see the difference? Of course not. That's the whole point. It is 
ambiguous. The first is a single item consisting of a plus b, and the 
second is two items consisting of a, following by unary plus b.

The same applies to unary minus.

That problem *alone* kills this idea.

There's also the problem that your syntax requires the *invisible* 
difference between tabs and spaces to be treated as syntactically 
meaningful.

[...]
> *The benefits is just as in above examples : readability and
> 'typeability' boost.*

But your syntax is not more readable, it is less readable and ambiguous. 
It requires us to care about the difference between two kinds of 
invisible whitespace.


> To present nesting of elements of higher than 2 levels, normal Python
> syntax can be used for deeper nesting:

So not only does idea not give us any new benefit, it cannot even do what 
existing syntax can do. It is inferior to what Python already has, 
ambiguous, and hard to read.

-- 
Steve



From steve+comp.lang.python at pearwood.info  Tue May  8 03:33:21 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Tue, 8 May 2018 07:33:21 +0000 (UTC)
Subject: Module, Package
References: <7854fb75-4887-49a9-ac17-9d1a2951a801@googlegroups.com>
Message-ID: <pcrjs0$16m$14@blaine.gmane.org>

On Mon, 07 May 2018 09:53:45 -0700, Sharan Basappa wrote:

> I am a bit confused between module and package in Python. Does a module
> contain package or vice versa? When we import something in Python, do we
> import a module or a package?

The term "module" in Python has multiple meanings:

- a particular kind of object, types.ModuleType

- a single importable .py, .pyc etc file

A package is a logical collection of importable .py etc files, usually 
collected inside a single directory. When you import a module of a 
package, that gives you a module object.

Normally we would say that packages contain modules. For example, if you 
have this file structure:


library/
+-- __init__.py   # special file which defines a package
+-- widgets.py
+-- stuff/
    +-- __init__.py
    +-- things.py


then we have a package "library", which in turn contains a submodule 
"library.widgets", and a subpackage "library.stuff", which in turn 
contains a submodule "library.stuff.things".

Each of these lines imports a module object:

import library
import library.stuff
import library.stuff.things
import library.widgets

from library import widgets
from library.stuff import things


Effectively, "packages" relates to how you arrange the files on disk; 
"modules" relates to what happens when you import them.


-- 
Steve



From alexey.muranov at gmail.com  Tue May  8 03:55:00 2018
From: alexey.muranov at gmail.com (Alexey Muranov)
Date: Tue, 08 May 2018 09:55:00 +0200
Subject: Problem/bug with class definition inside function definition
In-Reply-To: <1525731660.30323.0@smtp.gmail.com>
References: <1525730554.24805.0@smtp.gmail.com>
 <1525731660.30323.0@smtp.gmail.com>
Message-ID: <1525766100.4532.0@smtp.gmail.com>

Sorry, i was confused.  I would say that this mostly works as expected, 
though the difference between

    x = 42

    class C:
        x = x  # Works

and

    def f2(a):
        class D:
            a = a  # Does not work <<<<<
        return D

is still surprising to me.

Otherwise, probably the solution with

    def f(a):
        _a = a
        class D:
            a = _a
        return D

is good enough, if Python does not allow to refer "simultaneously" to 
variables from different scopes if they have the same name.

Alexey.


On Tue, 8 May, 2018 at 12:21 AM, Alexey Muranov 
<alexey.muranov at gmail.com> wrote:
> To be more exact, i do see a few workarounds, for example:
> 
> 
>    def f4(a):
>        b = a
>        class D:
>            a = b  # Works
>        return D
> 
> But this is not what i was hoping for.
> 
> Alexey.
> 
> On Tue, 8 May, 2018 at 12:02 AM, Alexey Muranov 
> <alexey.muranov at gmail.com> wrote:
>> I have discovered the following bug or problem: it looks like i am 
>> forced to choose different names for class attributes and function 
>> arguments, and i see no workaround.  Am i missing some special 
>> syntax feature ?
>> 
>> Alexey.
>> 
>> ---
>> x = 42
>> 
>> class C1:
>>    y = x  # Works
>> 
>> class C2:
>>    x = x  # Works
>> 
>> # ---
>> def f1(a):
>>    class D:
>>        b = a  # Works
>>    return D
>> 
>> def f2(a):
>>    class D:
>>        a = a  # Does not work <<<<<
>>    return D
>> 
>> def f3(a):
>>    class D:
>>        nonlocal a
>>        a = a  # Does not work either <<<<<
>>    return D
>> 
>> # ---
>> def g1(a):
>>    def h():
>>        b = a  # Works
>>        return b
>>    return h
>> 
>> def g2(a):
>>    def h():
>>        a = a  # Does not work (as expected)
>>        return a
>>    return h
>> 
>> def g3(a):
>>    def h():
>>        nonlocal a
>>        a = a  # Works
>>        return a
>>    return h
>> 
>> # ---
>> if __name__ == "__main__":
>>    assert C1.y == 42
>>    assert C2.x == 42
>> 
>>    assert f1(13).b == 13
>> 
>>    try:
>>        f2(13)  # NameError
>>    except NameError:
>>        pass
>>    except Exception as e:
>>        raise Exception( 'Unexpected exception raised: '
>>                         '{}'.format(type(e).__name__) )
>>    else:
>>        raise Exception('No exception')
>> 
>>    try:
>>        f3(13).a  # AttributeError
>>    except AttributeError:
>>        pass
>>    except Exception as e:
>>        raise Exception( 'Unexpected exception raised: '
>>                         '{}'.format(type(e).__name__) )
>>    else:
>>        raise Exception('No exception')
>> 
>>    assert g1(13)() == 13
>> 
>>    try:
>>        g2(13)()  # UnboundLocalError
>>    except UnboundLocalError:
>>        pass
>>    except Exception as e:
>>        raise Exception( 'Unexpected exception raised: '
>>                         '{}'.format(type(e).__name__) )
>>    else:
>>        raise Exception('No exception')
>> 
>>    assert g3(13)() == 13
>> 
> 



From antoon.pardon at vub.be  Tue May  8 04:29:10 2018
From: antoon.pardon at vub.be (Antoon Pardon)
Date: Tue, 8 May 2018 10:29:10 +0200
Subject: itemgetter with default arguments
In-Reply-To: <pcps6p$jiu$1@blaine.gmane.org>
References: <pchljn$f9u$2@blaine.gmane.org> <pcjmkj$c4g$1@blaine.gmane.org>
 <e2773802-b4af-0518-f307-e88d8916a551@vub.be> <pcps6p$jiu$1@blaine.gmane.org>
Message-ID: <afb8a47f-f957-0d18-519d-7fbb83476f18@vub.be>

On 07-05-18 17:45, Peter Otten wrote:
> Antoon Pardon wrote:
>
>> On 05-05-18 09:33, Peter Otten wrote:
>>> I think you have established that there is no straight-forward way to
>>> write this as a lambda. But is adding a default to itemgetter the right
>>> conclusion?
>>>
>>> If there were an exception-catching decorator you could write
>>>
>>> f = catch(IndexError, "spam")(itemgetter(2))
>> I think your catch function would be a usefull addition, but I don't see
>> it solving this problem once we use itemgetter te get multiple entries.
> Good catch()
>
> ;)
>
> The obvious way, expressing the n-tuple case in terms of the solution for 
> scalars
>
>>>> f = lambda items: tuple(catch(IndexError, "spam")(itemgetter(i))(items) 
> for i in (2, 1, 5))
>>>>>>> f("abc")
> ('c', 'b', 'spam')
>
> is a bit too complex to inline -- and also inefficient. You'd be tempted to 
> factor out the repetetive parts
>
>>>> f = lambda items, gets=[catch(IndexError, "spam")(itemgetter(i)) for i 
> in (2, 1, 5)]: tuple(get(items) for get in gets)
>>>> f("abc")
> ('c', 'b', 'spam')
>
> and thus make it even less readable.
>
> That said -- grepping my code I'm a bit surprised to find only
>
> 17 itemgetter(0)
>  9 itemgetter(1)
>  1 itemgetter(1, 0)
>  1 itemgetter(*indices)
>
> Checking /usr/lib/python3/dist-packages it looks like the situation is 
> similar. I conclude that the most useful addition to the operator module 
> would be
>
> first = itemgetter(0)
> second = itemgetter(1)

The problem with looking for such uses, is that I am working on a lot of
legacy code written in 2.2. It needed few adaptions to still work in 2.7
but I didn't adapt the code to make use of all the new features. But looking
at sort statements, it seems I have (the equivallent of) the following

itemgetter(2)
itemgetter(3)
itemgetter(4)
itemgetter(slice(0,-1))

-- 
Antoon Pardon.



From ned at nedbatchelder.com  Tue May  8 07:04:10 2018
From: ned at nedbatchelder.com (Ned Batchelder)
Date: Tue, 8 May 2018 07:04:10 -0400
Subject: Problem/bug with class definition inside function definition
In-Reply-To: <1525766100.4532.0@smtp.gmail.com>
References: <1525730554.24805.0@smtp.gmail.com>
 <1525731660.30323.0@smtp.gmail.com> <1525766100.4532.0@smtp.gmail.com>
Message-ID: <22708a9c-5bce-9909-abcc-69009d82341c@nedbatchelder.com>

On 5/8/18 3:55 AM, Alexey Muranov wrote:
> Sorry, i was confused.? I would say that this mostly works as 
> expected, though the difference between
>
> ?? x = 42
>
> ?? class C:
> ?????? x = x? # Works
>
> and
>
> ?? def f2(a):
> ?????? class D:
> ?????????? a = a? # Does not work <<<<<
> ?????? return D
>
> is still surprising to me.
>
> Otherwise, probably the solution with
>
> ?? def f(a):
> ?????? _a = a
> ?????? class D:
> ?????????? a = _a
> ?????? return D
>
> is good enough, if Python does not allow to refer "simultaneously" to 
> variables from different scopes if they have the same name.
>
> Alexey.

I'm curious to see the real code you're writing that uses this style of 
class creation.? It feels like there might be an easier way to achieve 
your goal.

--Ned.
>
>
> On Tue, 8 May, 2018 at 12:21 AM, Alexey Muranov 
> <alexey.muranov at gmail.com> wrote:
>> To be more exact, i do see a few workarounds, for example:
>>
>>
>> ?? def f4(a):
>> ?????? b = a
>> ?????? class D:
>> ?????????? a = b? # Works
>> ?????? return D
>>
>> But this is not what i was hoping for.
>>
>> Alexey.
>>
>> On Tue, 8 May, 2018 at 12:02 AM, Alexey Muranov 
>> <alexey.muranov at gmail.com> wrote:
>>> I have discovered the following bug or problem: it looks like i am 
>>> forced to choose different names for class attributes and function 
>>> arguments, and i see no workaround.? Am i missing some special 
>>> syntax feature ?
>>>
>>> Alexey.
>>>
>>> ---
>>> x = 42
>>>
>>> class C1:
>>> ?? y = x? # Works
>>>
>>> class C2:
>>> ?? x = x? # Works
>>>
>>> # ---
>>> def f1(a):
>>> ?? class D:
>>> ?????? b = a? # Works
>>> ?? return D
>>>
>>> def f2(a):
>>> ?? class D:
>>> ?????? a = a? # Does not work <<<<<
>>> ?? return D
>>>
>>> def f3(a):
>>> ?? class D:
>>> ?????? nonlocal a
>>> ?????? a = a? # Does not work either <<<<<
>>> ?? return D
>>>
>>> # ---
>>> def g1(a):
>>> ?? def h():
>>> ?????? b = a? # Works
>>> ?????? return b
>>> ?? return h
>>>
>>> def g2(a):
>>> ?? def h():
>>> ?????? a = a? # Does not work (as expected)
>>> ?????? return a
>>> ?? return h
>>>
>>> def g3(a):
>>> ?? def h():
>>> ?????? nonlocal a
>>> ?????? a = a? # Works
>>> ?????? return a
>>> ?? return h
>>>
>>> # ---
>>> if __name__ == "__main__":
>>> ?? assert C1.y == 42
>>> ?? assert C2.x == 42
>>>
>>> ?? assert f1(13).b == 13
>>>
>>> ?? try:
>>> ?????? f2(13)? # NameError
>>> ?? except NameError:
>>> ?????? pass
>>> ?? except Exception as e:
>>> ?????? raise Exception( 'Unexpected exception raised: '
>>> ??????????????????????? '{}'.format(type(e).__name__) )
>>> ?? else:
>>> ?????? raise Exception('No exception')
>>>
>>> ?? try:
>>> ?????? f3(13).a? # AttributeError
>>> ?? except AttributeError:
>>> ?????? pass
>>> ?? except Exception as e:
>>> ?????? raise Exception( 'Unexpected exception raised: '
>>> ??????????????????????? '{}'.format(type(e).__name__) )
>>> ?? else:
>>> ?????? raise Exception('No exception')
>>>
>>> ?? assert g1(13)() == 13
>>>
>>> ?? try:
>>> ?????? g2(13)()? # UnboundLocalError
>>> ?? except UnboundLocalError:
>>> ?????? pass
>>> ?? except Exception as e:
>>> ?????? raise Exception( 'Unexpected exception raised: '
>>> ??????????????????????? '{}'.format(type(e).__name__) )
>>> ?? else:
>>> ?????? raise Exception('No exception')
>>>
>>> ?? assert g3(13)() == 13
>>>
>>
>



From mikhailwas at gmail.com  Tue May  8 08:52:12 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Tue, 8 May 2018 15:52:12 +0300
Subject: Suggestion for a "data" object syntax
In-Reply-To: <pcriqa$16m$13@blaine.gmane.org>
References: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
 <pcriqa$16m$13@blaine.gmane.org>
Message-ID: <CAE6NSRCo8-dVWSAYuY8MHH6vviy_2Qn_LpGa2kRTN8L2=cceXQ@mail.gmail.com>

On Tue, May 8, 2018 at 10:15 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Tue, 08 May 2018 06:45:05 +0300, Mikhail V wrote:
>
>> *Example 3. Two-dimensional tuple.*
>>
>> data === T/T :
>>     1    2    3    "hello"
>>     a    b     c + d    e     f
>>
>> is a synonym for:
>>
>> data = (
>>     (1, 2, 3, "hello") ,
>>     (a, b, c + d, e, f ) )
>
> Last time you brought up this idea, you were told that it is ambiguous.
> Using whitespace alone, it is impossible to distinguish between
>
>     a + b
>
> and
>
>     a + b
>
>
> Can you see the difference? Of course not. That's the whole point. It is
> ambiguous. The first is a single item consisting of a plus b, and the
> second is two items consisting of a, following by unary plus b.

Can you be more precise what issue are you addressing?
Last time and this time I told it uses TAB character to
separate elements.


> There's also the problem that your syntax requires the *invisible*
> difference between tabs and spaces to be treated as syntactically
> meaningful.

What editor do you use? My editor can toggle tabs highlighting as arrows,
and I suppose almost any editor has good support for highlighting of
characters by search, etc. For NPP there are even plugins like Regex helper.

The only real issue I know that there may be no option to adjust the
minimal size for a tabulation, so it can become too small
in some rare cases, and there is the highlight function for that.

I never had problems with inputing tables - It seems you are having
an issue or may be it's even some personal pet-pieve.

>
> [...]
>> *The benefits is just as in above examples : readability and
>> 'typeability' boost.*
>
> But your syntax is not more readable, it is less readable and ambiguous.
> It requires us to care about the difference between two kinds of
> invisible whitespace.

Yes it requires you to care about tabulation - which many users already do
to improve readability in their code. As well as any software like
Matlab, Excel, etc presents matrices as tables.
So they are all making it "less readable", lol.
Ok Steven, you like the brackets and commas noise, that's
quite funny. Your opinion is heard, but I would be thankful if you'll
speak for yourself,
and not try to enforce your opinion with these "us", "for us".

Also you seem to start with cherry-picking straight away - trying
to find an issue and wind it up with the whole idea, totally ignoring
obvious benefits for most frequent use cases like multiline
strings,1d tuples/lists  and simple tables.
A very common table case is a 2-column table.

So you would prefer this:

L = (
    (a, 1),
    (b, 2),
    (c, 3),
    (foobar, 4))

over this:

L === T/T:
    a    1
    b    2
    c    3
    foobar    4

Right? Your issues with tabs aside, I think it is impossible to ignore the
the readability improvement. Not even speaking of how
many commas and bracket you need to type in the first case.


M


From rosuav at gmail.com  Tue May  8 10:25:34 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 9 May 2018 00:25:34 +1000
Subject: Suggestion for a "data" object syntax
In-Reply-To: <CAE6NSRCo8-dVWSAYuY8MHH6vviy_2Qn_LpGa2kRTN8L2=cceXQ@mail.gmail.com>
References: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
 <pcriqa$16m$13@blaine.gmane.org>
 <CAE6NSRCo8-dVWSAYuY8MHH6vviy_2Qn_LpGa2kRTN8L2=cceXQ@mail.gmail.com>
Message-ID: <CAPTjJmoBeZtx4b1yW_89-T6FPan+t9PvOu+U=Yth3mCwaJNo=A@mail.gmail.com>

On Tue, May 8, 2018 at 10:52 PM, Mikhail V <mikhailwas at gmail.com> wrote:
> Right? Your issues with tabs aside, I think it is impossible to ignore the
> the readability improvement. Not even speaking of how
> many commas and bracket you need to type in the first case.

That's incredibly subjective. Or else straight-up wrong, I'm not sure which.

Why should this be a language feature? Why not just create a data file
and then load it, or use a triple quoted string and write your own
parser? What's the advantage of making this language syntax?

ChrisA


From digitalfantasy.it86559 at digitalfantasy.it  Tue May  8 11:14:16 2018
From: digitalfantasy.it86559 at digitalfantasy.it (Liste guru)
Date: Tue, 8 May 2018 17:14:16 +0200
Subject: Suggestion for a "data" object syntax
In-Reply-To: <CAE6NSRCo8-dVWSAYuY8MHH6vviy_2Qn_LpGa2kRTN8L2=cceXQ@mail.gmail.com>
References: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
 <pcriqa$16m$13@blaine.gmane.org>
 <CAE6NSRCo8-dVWSAYuY8MHH6vviy_2Qn_LpGa2kRTN8L2=cceXQ@mail.gmail.com>
Message-ID: <aa2cc683-a5f0-8ff2-667a-60a342d8b158@digitalfantasy.it>

Il 08/05/2018 14:52, Mikhail V ha scritto:

 ???? ...
> What editor do you use? My editor can toggle tabs highlighting as arrows,
> and I suppose almost any editor has good support for highlighting of
> characters by search, etc. For NPP there are even plugins like Regex helper.

 ??? I like to 'type program.py' and understand what's happening, 
without have to fire up an editor.

 ?? While, in C++, the Microsoft IDE (and some other) mark the class 
members & the parameters so you can easily see what 'counter' is, a lot 
of guide says that you should call it 'm_counter' if it's a member or 
'counter_' if it's a parameter, just in case you don't have your editor 
(or you're colorblind or you don't like to have the parameters printed 
with a light grey ...).


 ?? ...


From steve+comp.lang.python at pearwood.info  Tue May  8 11:20:37 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Tue, 8 May 2018 15:20:37 +0000 (UTC)
Subject: Suggestion for a "data" object syntax
References: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
 <pcriqa$16m$13@blaine.gmane.org>
 <CAE6NSRCo8-dVWSAYuY8MHH6vviy_2Qn_LpGa2kRTN8L2=cceXQ@mail.gmail.com>
Message-ID: <pcsf85$16m$15@blaine.gmane.org>

On Tue, 08 May 2018 15:52:12 +0300, Mikhail V wrote:

>> Last time you brought up this idea, you were told that it is ambiguous.
>> Using whitespace alone, it is impossible to distinguish between
>>
>>     a + b
>>
>> and
>>
>>     a + b
>>
>>
>> Can you see the difference? Of course not. That's the whole point. It
>> is ambiguous. The first is a single item consisting of a plus b, and
>> the second is two items consisting of a, following by unary plus b.
> 
> Can you be more precise what issue are you addressing?

Was I not clear enough the first time?

When you write "a + b" it is impossible for either the human reader or 
the interpreter to tell whether that is meant to be two items separated 
by white space ("a" and "+b") or a single item ("a+b").

The same applies to "a - b".

There is no acceptable work-around or fix for this.

* It is not acceptable to prohibit whitespace between unary operators
  and their operand;

* or to require spaces rather than tabs between binary operators
  and their operands;

* or to make a subtle semantic difference between tabs and spaces
  of this sort.

Unix "make" files require tabs rather than spaces, and it is a constant 
source of bugs and frustration.


> Last time and
> this time I told it uses TAB character to separate elements.

That's not my recollection. As I remember it, it was *your* idea to use 
tab characters, and everyone told you that was not an acceptable work-
around.

Who told you to use tab characters? It would not have been any of the 
core developers. Many of them would rather ban tabs than require them.


>> There's also the problem that your syntax requires the *invisible*
>> difference between tabs and spaces to be treated as syntactically
>> meaningful.
> 
> What editor do you use? My editor can toggle tabs highlighting as
> arrows, and I suppose almost any editor has good support for
> highlighting of characters by search, etc. For NPP there are even
> plugins like Regex helper.

Using a particular editor is not and will not be a mandatory requirement 
for Python.


[...]
> So you would prefer this:
> 
> L = (
>     (a, 1),
>     (b, 2),
>     (c, 3),
>     (foobar, 4))
> 
> over this:
> 
> L === T/T:
>     a    1
>     b    2
>     c    3
>     foobar    4
> 
> Right?

I am amused that you have obviously gone to a lot of trouble to carefully 
line up the columns, and yet they aren't even aligned -- "foobar" extends 
into the second column, pushing the "4" out to the right.

There is no doubt that the first is HUGELY better:

- it uses the standard = assignment operator, not a 
  special "===" operator;

- there's no cryptic and mysterious "T/T" code which looks like
  you are dividing T by T;

- the first one allows you to write it as a single line:

    L = ((a, 1), (b, 2), (c, 3), (foobar, 4))

  instead of wasting vertical space;

- the first one is unambiguous while the second is ambiguous;

- the first one can include nested data structures, while 
  the second cannot.

There is only one advantage to the second format. It gives bad 
programmers a justification to waste time while pretending to be working, 
as they carefully align their columns, then realign them each time the 
data changes.


> Your issues with tabs aside, I think it is impossible to ignore
> the the readability improvement.

An interesting philosophical conundrum... is it possible to ignore 
something which isn't there?

If there is no elephant in the room, and nobody mentions it, are they 
ignoring it?



-- 
Steve



From m.overmeyer at yahoo.ca  Tue May  8 12:25:24 2018
From: m.overmeyer at yahoo.ca (m.overmeyer at yahoo.ca)
Date: Tue, 8 May 2018 09:25:24 -0700 (PDT)
Subject: problem in compiling C API in mingw
In-Reply-To: <mailman.1514.1311724423.1164.python-list@python.org>
References: <mailman.1514.1311724423.1164.python-list@python.org>
Message-ID: <4cb7ae8d-1479-4642-bc3a-8ea6d7aee2a0@googlegroups.com>

On Tuesday, 26 July 2011 23:53:36 UTC, llw... at gmail.com  wrote:
> Hi all again, 
>   I wonder if so far only Python 2.5.x support c extension. I try the
> MSVC 2010 and 2008, also try mingw (gcc 4.x.x) and swig. But even I try
> the simplest example, it said 
> 
> example_wrap.o:example_wrap.c:(.text+0x10ac): undefined reference to `_imp__PyObject_Free'
> example_wrap.o:example_wrap.c:(.text+0x10f5): undefined reference to `_imp__PyCapsule_Import'
> example_wrap.o:example_wrap.c:(.text+0x1100): undefined reference to `_imp__PyErr_Occurred'
> example_wrap.o:example_wrap.c:(.text+0x110e): undefined reference to `_imp__PyErr_Clear'
> example_wrap.o:example_wrap.c:(.text+0x1125): undefined reference to `_imp__PyImport_AddModule'
> example_wrap.o:example_wrap.c:(.text+0x1144): undefined reference to `_imp__PyCapsule_New'
> example_wrap.o:example_wrap.c:(.text+0x1165): undefined reference to `_imp__PyModule_AddObject'
> example_wrap.o:example_wrap.c:(.text+0x1170): undefined reference to `_imp__PyBaseObject_Type'
> example_wrap.o:example_wrap.c:(.text+0x11b2): undefined reference to `_imp__PyObject_SetAttr'
> example_wrap.o:example_wrap.c:(.rdata+0x1e8): undefined reference to `PyObject_GenericGetAttr'
> collect2: ld returned 1 exit status
> 
> and some sort like that.
> 
> So I try to use the compiler itself and get rid of all 3rd part tool,
> here is what I did
> 
> ///////////// source code
> #include "Python.h"
> 
> static  PyObject *
> ex_foo(PyObject *self, PyObject *args)
> {
>     printf("Hello, world n " );
>     Py_INCREF(Py_None);
>     return  Py_None;
> }
> 
> static  PyMethodDef example_methods[] = {
>     {"foo" , ex_foo, METH_VARARGS, "foo() doc string" },
>     {NULL , NULL }
> };
> 
> static  struct  PyModuleDef examplemodule = {
>     PyModuleDef_HEAD_INIT,
>     "example" ,
>     "example module doc string" ,
>     -1 ,
>     example_methods,
>     NULL ,
>     NULL ,
>     NULL ,
>     NULL
> };
> 
> PyMODINIT_FUNC
> PyInit_example(void )
> {
>     return  PyModule_Create(&examplemodule);
> }
> 
> /// my setup.py
> from distutils.core import setup, Extension
> 
> module1 = Extension('example', sources = ['example.c'])
> 
> setup (name = 'example', version = '1.0', description = 'This is a demo package', ext_modules = [module1])
> 
> 
> // running
> python setup.py build --compiler=mingw32
> 
> 
> $ python setup.py build --compiler=mingw32
> running build
> running build_ext
> building 'example' extension
> D:\Programs\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall "-Ic:\Program Files (x8
> 6)\Python\include" "-Ic:\Program Files (x86)\Python\PC" -c example.c -o build\te
> mp.win-amd64-3.1\Release\example.o
> writing build\temp.win-amd64-3.1\Release\example.def
> D:\Programs\MinGW\bin\gcc.exe -mno-cygwin -shared -s build\temp.win-amd64-3.1\Re
> lease\example.o build\temp.win-amd64-3.1\Release\example.def "-Lc:\Program Files
>  (x86)\Python\libs" "-Lc:\Program Files (x86)\Python\PCbuild\amd64" -lpython31 -
> lmsvcr90 -o build\lib.win-amd64-3.1\example.pyd
> build\temp.win-amd64-3.1\Release\example.o:example.c:(.text+0x13): undefined ref
> erence to `_imp___Py_NoneStruct'
> build\temp.win-amd64-3.1\Release\example.o:example.c:(.text+0x32): undefined ref
> erence to `_imp__PyModule_Create2'
> collect2: ld returned 1 exit status
> error: command 'gcc' failed with exit status 1
> --------------------- Original Message Ends --------------------

You are linking against the static version of the Python library. If you link against the DLL version, this problem goes away.

-Lc:\Program Files(x86)\Python\libs" should just be "-Lc:\Program Files(x86)\Python\", assuming that's where the Python DLLs are.

See:
https://stackoverflow.com/questions/5159353/how-can-i-get-rid-of-the-imp-prefix-in-the-linker-in-vc#5159395



From sharan.basappa at gmail.com  Tue May  8 13:37:01 2018
From: sharan.basappa at gmail.com (Sharan Basappa)
Date: Tue, 8 May 2018 10:37:01 -0700 (PDT)
Subject: Module, Package
In-Reply-To: <mailman.32.1525764945.28519.python-list@python.org>
References: <7854fb75-4887-49a9-ac17-9d1a2951a801@googlegroups.com>
 <pcrjs0$16m$14@blaine.gmane.org>
 <mailman.32.1525764945.28519.python-list@python.org>
Message-ID: <cebc9141-cb08-48bf-9062-8377365a92e0@googlegroups.com>

On Tuesday, 8 May 2018 13:05:58 UTC+5:30, Steven D'Aprano  wrote:
> On Mon, 07 May 2018 09:53:45 -0700, Sharan Basappa wrote:
> 
> > I am a bit confused between module and package in Python. Does a module
> > contain package or vice versa? When we import something in Python, do we
> > import a module or a package?
> 
> The term "module" in Python has multiple meanings:
> 
> - a particular kind of object, types.ModuleType
> 
> - a single importable .py, .pyc etc file
> 
> A package is a logical collection of importable .py etc files, usually 
> collected inside a single directory. When you import a module of a 
> package, that gives you a module object.
> 
> Normally we would say that packages contain modules. For example, if you 
> have this file structure:
> 
> 
> library/
> +-- __init__.py   # special file which defines a package
> +-- widgets.py
> +-- stuff/
>     +-- __init__.py
>     +-- things.py
> 
> 
> then we have a package "library", which in turn contains a submodule 
> "library.widgets", and a subpackage "library.stuff", which in turn 
> contains a submodule "library.stuff.things".
> 
> Each of these lines imports a module object:
> 
> import library
> import library.stuff
> import library.stuff.things
> import library.widgets
> 
> from library import widgets
> from library.stuff import things
> 
> 
> Effectively, "packages" relates to how you arrange the files on disk; 
> "modules" relates to what happens when you import them.
> 
> 
> -- 
> Steve

Wow! Thanks a lot.


From mikhailwas at gmail.com  Tue May  8 16:16:23 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Tue, 8 May 2018 23:16:23 +0300
Subject: Suggestion for a "data" object syntax
In-Reply-To: <pcsf85$16m$15@blaine.gmane.org>
References: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
 <pcriqa$16m$13@blaine.gmane.org>
 <CAE6NSRCo8-dVWSAYuY8MHH6vviy_2Qn_LpGa2kRTN8L2=cceXQ@mail.gmail.com>
 <pcsf85$16m$15@blaine.gmane.org>
Message-ID: <CAE6NSRALn2benyf+C87bCKSwRH3gzXcd1WHj_EawR9OngqbcSg@mail.gmail.com>

On Tue, May 8, 2018 at 6:20 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Tue, 08 May 2018 15:52:12 +0300, Mikhail V wrote:
>
>>> Last time you brought up this idea, you were told that it is ambiguous.
>>> Using whitespace alone, it is impossible to distinguish between
>>>
>>>     a + b
>>>
>>> and
>>>
>>>     a + b
>>>
>>>
>>> Can you see the difference? Of course not. That's the whole point. It
>>> is ambiguous. The first is a single item consisting of a plus b, and
>>> the second is two items consisting of a, following by unary plus b.
>>
>> Can you be more precise what issue are you addressing?
>
> Was I not clear enough the first time?
>
> When you write "a + b" it is impossible for either the human reader or
> the interpreter to tell whether that is meant to be two items separated
> by white space ("a" and "+b") or a single item ("a+b").
>
> There is no acceptable work-around or fix for this.
>
> * It is not acceptable to prohibit whitespace between unary operators
>   and their operand;
>
> * or to require spaces rather than tabs between binary operators
>   and their operands;
>

Sorry this all does not seem to even refer to my proposal.

I don't propose to remove spaces, but I propose Tab-separated
elements. If I allow commas as well, this will become not so simple,
probably. Also I don't propose syntax for e-mail code exchange,
but rather syntax for *work* an this can potentially help a lot of people
in everyday work.

Also I don't know what kind of human thinks that this:
 a + b
 is two elements "a" and "+ b"
What is "+ b"? And who writes "- b" with a space in unary minus?
I don't. Nobody does. Is it allowed? yes. no problem.

(It would be great if you group the issues
related to usability separetely from technical problems
with parser. That will help to understand you comments.)


>> Last time and
>> this time I told it uses TAB character to separate elements.
>
> That's not my recollection. As I remember it, it was *your* idea to use
> tab characters, and everyone told you that was not an acceptable work-
> around.

Yes my idea, but not sure what is you concern right now.
IIRC back then, you were the *only one* who commented something about
Tab and parsing, and made some mysterious example with eval("\t") which
I still don't know what it should explain exactly.
You say "everyone?" ... Hmm, now I am starting to suspect - maybe
each your post really represents a result of a quick meeting
regarding each raised proposal?
That would explain the usage of plural "us".

>>> There's also the problem that your syntax requires the *invisible*
>>> difference between tabs and spaces to be treated as syntactically
>>> meaningful.

There is "invisible" difference in indentations tabs vs spaces - so what?
I don't want spaces or tabs visible - there is toggle "show tabs" and "toggle
show space" for that and many more usability features, as I already said.
Look, I work with layouts - there are: Indents, Tabs, spaces, En
space, Em space,
thin space, non-breaking space, "indent to here" control characters.
All those are useful parts of inner syntax - all are "invisible".
What point are you making after all?

Those are basically universal features. And thousands of Python people
already use tabs to align columns so you have to accept it - it is
part of many source code and tabulation formatting is a good and
useful feature, although not all editors cope good with that.


>>
>> What editor do you use? My editor can toggle tabs highlighting as
>> arrows, and I suppose almost any editor has good support for
>> highlighting of characters by search, etc. For NPP there are even
>> plugins like Regex helper.
>
> Using a particular editor is not and will not be a mandatory requirement
> for Python.

Using outdated tools or being PEBCAK are not and will not be justification for
language syntax improvements. Using an editor from 85 - everyone else
should bother?
As said there is already tons of code with which you may be unsatisfied
when you paste it into REPL, but nearly nobody uses REPL for work.

>
> [...]
>> So you would prefer this:
>>
>> L = (
>>     (a, 1),
>>     (b, 2),
>>     (c, 3),
>>     (foobar, 4))
>>
>> over this:
>>
>> L === T/T:
>>     a    1
>>     b    2
>>     c    3
>>     foobar    4
>>
>> Right?
>
> I am amused that you have obviously gone to a lot of trouble to carefully
> line up the columns, and yet they aren't even aligned -- "foobar" extends
> into the second column, pushing the "4" out to the right.

No, i haven't. It takes much less time to type that than bracketed
version. Though I am amused that you've noticed the misaligned
element but can't notice how bad the bracketed version look.
Ok, Steve, as said, I hear you - you like the ugly one, I'll pick the cute
one ;-)


> There is no doubt that the first is HUGELY better:
>
> - it uses the standard = assignment operator, not a
>   special "===" operator;
>
> - there's no cryptic and mysterious "T/T" code which looks like
>   you are dividing T by T;

Your bullet list feels incomplete, can add also:

 - no other languages use such syntax

 - this is not current Python syntax after all. Syntax error, Ta-da!



> - the first one allows you to write it as a single line:
>
>     L = ((a, 1), (b, 2), (c, 3), (foobar, 4))
>
>   instead of wasting vertical space;

Wasting space you say? You economize paper for printing out?
Or do you like command-line editors so much?

>
> - the first one is unambiguous while the second is ambiguous;

I think it's time to reveal what exactly you mean here.
In the above example there is nothing ambigious.
At least not for someone who is Ok with basic editing
skills.


> - the first one can include nested data structures, while
>   the second cannot.

Why it can't? did you read the original e-mail? Also it is not
the primary aim of the suggested syntax, but I work this out too.

Somehow it feels you have collected all posible related and
not directly related concerns together here.


From rosuav at gmail.com  Tue May  8 16:26:39 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 9 May 2018 06:26:39 +1000
Subject: Suggestion for a "data" object syntax
In-Reply-To: <CAE6NSRALn2benyf+C87bCKSwRH3gzXcd1WHj_EawR9OngqbcSg@mail.gmail.com>
References: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
 <pcriqa$16m$13@blaine.gmane.org>
 <CAE6NSRCo8-dVWSAYuY8MHH6vviy_2Qn_LpGa2kRTN8L2=cceXQ@mail.gmail.com>
 <pcsf85$16m$15@blaine.gmane.org>
 <CAE6NSRALn2benyf+C87bCKSwRH3gzXcd1WHj_EawR9OngqbcSg@mail.gmail.com>
Message-ID: <CAPTjJmq_FvJgMhC7rygd_D238f6fXmC5dsee98=vLr4O3RDy8w@mail.gmail.com>

On Wed, May 9, 2018 at 6:16 AM, Mikhail V <mikhailwas at gmail.com> wrote:
> Also I don't know what kind of human thinks that this:
>  a + b
>  is two elements "a" and "+ b"
> What is "+ b"?

Unary plus applied to whatever value 'b' is.

> And who writes "- b" with a space in unary minus?
> I don't. Nobody does. Is it allowed? yes. no problem.

You're making a syntax proposal. That means it has to cope with all
the vagaries of syntax, including things that you think "nobody does".

>> - the first one is unambiguous while the second is ambiguous;
>
> I think it's time to reveal what exactly you mean here.
> In the above example there is nothing ambigious.
> At least not for someone who is Ok with basic editing
> skills.

There are things that are ambiguous to the Python syntax parser.

If you want to create a completely new syntax that happens to
incorporate some Python expressions, that's not a problem. It isn't a
Python syntax enhancement, it is a completely separate file format,
and you can do what you like with that. You can use tabs to separate
tokens, eval() those tokens to figure out the actual value, and then
build the resulting data structure according to your rules. And it's
100% acceptable to demand a stricter form of Python syntax within your
tokens (eg "no tabs allowed"), because it's your own data file.

And, even better: You can write code to parse this, without needing
approval from the core devs. The code you write doesn't have to wait
until Python 3.8 is released (two years from now); it can run on
existing interpreters. All the advantages are on your side.

ChrisA


From mikhailwas at gmail.com  Tue May  8 17:15:50 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Wed, 9 May 2018 00:15:50 +0300
Subject: Suggestion for a "data" object syntax
In-Reply-To: <CAPTjJmoBeZtx4b1yW_89-T6FPan+t9PvOu+U=Yth3mCwaJNo=A@mail.gmail.com>
References: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
 <pcriqa$16m$13@blaine.gmane.org>
 <CAE6NSRCo8-dVWSAYuY8MHH6vviy_2Qn_LpGa2kRTN8L2=cceXQ@mail.gmail.com>
 <CAPTjJmoBeZtx4b1yW_89-T6FPan+t9PvOu+U=Yth3mCwaJNo=A@mail.gmail.com>
Message-ID: <CAE6NSRDN_c1avmS4MtJ7bZ04+hdWtj0yRQx-8fCu4mJWm_ga4Q@mail.gmail.com>

On Tue, May 8, 2018 at 5:25 PM, Chris Angelico <rosuav at gmail.com> wrote:
> On Tue, May 8, 2018 at 10:52 PM, Mikhail V <mikhailwas at gmail.com> wrote:
>> Right? Your issues with tabs aside, I think it is impossible to ignore the
>> the readability improvement. Not even speaking of how
>> many commas and bracket you need to type in the first case.
>
> That's incredibly subjective. Or else straight-up wrong, I'm not sure which.

Just admit it, you try to troll me (or just pretend, I don't know).

Have you ever seen tables with commas left in there?
I've never seen in my whole life. And you should understand why.

Have you ever seen a website with sparse menu items or 'cloud' tags
with commas attached?
Have you ever heard someone claim that writing a 2d matrix down in a
single line is better that present it as a table?

So what you find _incredibly_ subjective here?

I am not telling tabulations work as they should in many code editors, but
there is a lot of work people invest to make better support for them in editors.
Here is another indirect benefit of adding such syntax, as editor developers
will be more motivated to improve the tabulation features.


> Why should this be a language feature? Why not just create a data file
> and then load it, or use a triple quoted string and write your own
> parser? What's the advantage of making this language syntax?

I am not sure what happens if I make another argument -
if it feels so easy for you to deny the obvious improvements (which
also supported by whole worlds' typography experience) then you can
just as easy deny pretty everything. How would we build any conversation
then?




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


From rosuav at gmail.com  Tue May  8 17:33:43 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 9 May 2018 07:33:43 +1000
Subject: Suggestion for a "data" object syntax
In-Reply-To: <CAE6NSRDN_c1avmS4MtJ7bZ04+hdWtj0yRQx-8fCu4mJWm_ga4Q@mail.gmail.com>
References: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
 <pcriqa$16m$13@blaine.gmane.org>
 <CAE6NSRCo8-dVWSAYuY8MHH6vviy_2Qn_LpGa2kRTN8L2=cceXQ@mail.gmail.com>
 <CAPTjJmoBeZtx4b1yW_89-T6FPan+t9PvOu+U=Yth3mCwaJNo=A@mail.gmail.com>
 <CAE6NSRDN_c1avmS4MtJ7bZ04+hdWtj0yRQx-8fCu4mJWm_ga4Q@mail.gmail.com>
Message-ID: <CAPTjJmqkT-ofa3CiN2hX4B9m3pJZJP2AqA-Sh2HXf7q2AMPG4w@mail.gmail.com>

On Wed, May 9, 2018 at 7:15 AM, Mikhail V <mikhailwas at gmail.com> wrote:
> On Tue, May 8, 2018 at 5:25 PM, Chris Angelico <rosuav at gmail.com> wrote:
>> On Tue, May 8, 2018 at 10:52 PM, Mikhail V <mikhailwas at gmail.com> wrote:
>>> Right? Your issues with tabs aside, I think it is impossible to ignore the
>>> the readability improvement. Not even speaking of how
>>> many commas and bracket you need to type in the first case.
>>
>> That's incredibly subjective. Or else straight-up wrong, I'm not sure which.
>
> Just admit it, you try to troll me (or just pretend, I don't know).

No, I am not trolling you.

> Have you ever seen tables with commas left in there?

It's called CSV.

> I've never seen in my whole life. And you should understand why.
>
> Have you ever seen a website with sparse menu items or 'cloud' tags
> with commas attached?
> Have you ever heard someone claim that writing a 2d matrix down in a
> single line is better that present it as a table?
>
> So what you find _incredibly_ subjective here?

Neither of those examples is program code. You are asking for a
syntactic change to a *programming language*. Everything you've said
is fine for a non-code format. Nothing is applicable to a programming
language.

>> Why should this be a language feature? Why not just create a data file
>> and then load it, or use a triple quoted string and write your own
>> parser? What's the advantage of making this language syntax?
>
> I am not sure what happens if I make another argument -
> if it feels so easy for you to deny the obvious improvements (which
> also supported by whole worlds' typography experience) then you can
> just as easy deny pretty everything. How would we build any conversation
> then?

Good question. You're clearly not interested in doing things the
existing (and easy) way, so there's no point debating this.
Fortunately for the rest of us, status quo wins a stalemate.

ChrisA


From breamoreboy at gmail.com  Tue May  8 17:43:01 2018
From: breamoreboy at gmail.com (Mark Lawrence)
Date: Tue, 8 May 2018 22:43:01 +0100
Subject: Suggestion for a "data" object syntax
In-Reply-To: <CAPTjJmqkT-ofa3CiN2hX4B9m3pJZJP2AqA-Sh2HXf7q2AMPG4w@mail.gmail.com>
References: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
 <pcriqa$16m$13@blaine.gmane.org>
 <CAE6NSRCo8-dVWSAYuY8MHH6vviy_2Qn_LpGa2kRTN8L2=cceXQ@mail.gmail.com>
 <CAPTjJmoBeZtx4b1yW_89-T6FPan+t9PvOu+U=Yth3mCwaJNo=A@mail.gmail.com>
 <CAE6NSRDN_c1avmS4MtJ7bZ04+hdWtj0yRQx-8fCu4mJWm_ga4Q@mail.gmail.com>
 <CAPTjJmqkT-ofa3CiN2hX4B9m3pJZJP2AqA-Sh2HXf7q2AMPG4w@mail.gmail.com>
Message-ID: <pct5h2$jmn$1@blaine.gmane.org>

On 08/05/18 22:33, Chris Angelico wrote:
> On Wed, May 9, 2018 at 7:15 AM, Mikhail V <mikhailwas at gmail.com> wrote:
>> On Tue, May 8, 2018 at 5:25 PM, Chris Angelico <rosuav at gmail.com> wrote:
>>> On Tue, May 8, 2018 at 10:52 PM, Mikhail V <mikhailwas at gmail.com> wrote:
>>>> Right? Your issues with tabs aside, I think it is impossible to ignore the
>>>> the readability improvement. Not even speaking of how
>>>> many commas and bracket you need to type in the first case.
>>>
>>> That's incredibly subjective. Or else straight-up wrong, I'm not sure which.
>>
>> Just admit it, you try to troll me (or just pretend, I don't know).
> 
> No, I am not trolling you.
> 
>> Have you ever seen tables with commas left in there?
> 
> It's called CSV.
> 
>> I've never seen in my whole life. And you should understand why.
>>
>> Have you ever seen a website with sparse menu items or 'cloud' tags
>> with commas attached?
>> Have you ever heard someone claim that writing a 2d matrix down in a
>> single line is better that present it as a table?
>>
>> So what you find _incredibly_ subjective here?
> 
> Neither of those examples is program code. You are asking for a
> syntactic change to a *programming language*. Everything you've said
> is fine for a non-code format. Nothing is applicable to a programming
> language.
> 
>>> Why should this be a language feature? Why not just create a data file
>>> and then load it, or use a triple quoted string and write your own
>>> parser? What's the advantage of making this language syntax?
>>
>> I am not sure what happens if I make another argument -
>> if it feels so easy for you to deny the obvious improvements (which
>> also supported by whole worlds' typography experience) then you can
>> just as easy deny pretty everything. How would we build any conversation
>> then?
> 
> Good question. You're clearly not interested in doing things the
> existing (and easy) way, so there's no point debating this.
> Fortunately for the rest of us, status quo wins a stalemate.
> 
> ChrisA
> 

Please stop feeding the OP, to my knowledge he's never once come up with 
any sensible suggestion for Python.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence



From mikhailwas at gmail.com  Tue May  8 19:31:30 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Wed, 9 May 2018 02:31:30 +0300
Subject: Suggestion for a "data" object syntax
In-Reply-To: <CAPTjJmqkT-ofa3CiN2hX4B9m3pJZJP2AqA-Sh2HXf7q2AMPG4w@mail.gmail.com>
References: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
 <pcriqa$16m$13@blaine.gmane.org>
 <CAE6NSRCo8-dVWSAYuY8MHH6vviy_2Qn_LpGa2kRTN8L2=cceXQ@mail.gmail.com>
 <CAPTjJmoBeZtx4b1yW_89-T6FPan+t9PvOu+U=Yth3mCwaJNo=A@mail.gmail.com>
 <CAE6NSRDN_c1avmS4MtJ7bZ04+hdWtj0yRQx-8fCu4mJWm_ga4Q@mail.gmail.com>
 <CAPTjJmqkT-ofa3CiN2hX4B9m3pJZJP2AqA-Sh2HXf7q2AMPG4w@mail.gmail.com>
Message-ID: <CAE6NSRCyAnDVyNS-MFAMpti7m4qMHmLuKmm1Ts_xrO2VmFFDSg@mail.gmail.com>

On Wed, May 9, 2018 at 12:33 AM, Chris Angelico <rosuav at gmail.com> wrote:
> On Wed, May 9, 2018 at 7:15 AM, Mikhail V <mikhailwas at gmail.com> wrote:
>> On Tue, May 8, 2018 at 5:25 PM, Chris Angelico <rosuav at gmail.com> wrote:
>>> On Tue, May 8, 2018 at 10:52 PM, Mikhail V <mikhailwas at gmail.com> wrote:
>>>> Right? Your issues with tabs aside, I think it is impossible to ignore the
>>>> the readability improvement. Not even speaking of how
>>>> many commas and bracket you need to type in the first case.
>>>
>>> That's incredibly subjective. Or else straight-up wrong, I'm not sure which.
>>
>> Just admit it, you try to troll me (or just pretend, I don't know).
>
> No, I am not trolling you.

I don't believe you.


> Neither of those examples is program code. You are asking for a
> syntactic change to a *programming language*. Everything you've said
> is fine for a non-code format. Nothing is applicable to a programming
> language.

Everything I said in previous mail was related to your claim that it's
Ok (or even better?) readable
with brackets and commas in a table than without them.
I was not even starting this terminology course.


From ben+python at benfinney.id.au  Tue May  8 20:14:18 2018
From: ben+python at benfinney.id.au (Ben Finney)
Date: Wed, 09 May 2018 10:14:18 +1000
Subject: Suggestion for a "data" object syntax
References: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
 <pcriqa$16m$13@blaine.gmane.org>
 <CAE6NSRCo8-dVWSAYuY8MHH6vviy_2Qn_LpGa2kRTN8L2=cceXQ@mail.gmail.com>
 <CAPTjJmoBeZtx4b1yW_89-T6FPan+t9PvOu+U=Yth3mCwaJNo=A@mail.gmail.com>
 <CAE6NSRDN_c1avmS4MtJ7bZ04+hdWtj0yRQx-8fCu4mJWm_ga4Q@mail.gmail.com>
 <CAPTjJmqkT-ofa3CiN2hX4B9m3pJZJP2AqA-Sh2HXf7q2AMPG4w@mail.gmail.com>
 <CAE6NSRCyAnDVyNS-MFAMpti7m4qMHmLuKmm1Ts_xrO2VmFFDSg@mail.gmail.com>
Message-ID: <85tvrhofc5.fsf@benfinney.id.au>

Mikhail V <mikhailwas at gmail.com> writes:

> On Wed, May 9, 2018 at 12:33 AM, Chris Angelico <rosuav at gmail.com> wrote:
> > On Wed, May 9, 2018 at 7:15 AM, Mikhail V <mikhailwas at gmail.com> wrote:
> >> Just admit it, you try to troll me (or just pretend, I don't know).
> >
> > No, I am not trolling you.
>
> I don't believe you.

If that's true ? if you believe Chris is trolling you ? then please do
not continue the conversation. Since you have already decided Chris is
trolling you, it follows that you will not respond productively to
anything he says to you. So this thread is already lost.

This forum has no need of another thread attempting to ?win? an argument
that one side believes is dishonest.

-- 
 \       ?The best in us does not require the worst in us: Our love of |
  `\     other human beings does not need to be nurtured by delusion.? |
_o__)                             ?Sam Harris, at _Beyond Belief 2006_ |
Ben Finney



From mikhailwas at gmail.com  Tue May  8 20:57:41 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Wed, 9 May 2018 03:57:41 +0300
Subject: Suggestion for a "data" object syntax
In-Reply-To: <85tvrhofc5.fsf@benfinney.id.au>
References: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
 <pcriqa$16m$13@blaine.gmane.org>
 <CAE6NSRCo8-dVWSAYuY8MHH6vviy_2Qn_LpGa2kRTN8L2=cceXQ@mail.gmail.com>
 <CAPTjJmoBeZtx4b1yW_89-T6FPan+t9PvOu+U=Yth3mCwaJNo=A@mail.gmail.com>
 <CAE6NSRDN_c1avmS4MtJ7bZ04+hdWtj0yRQx-8fCu4mJWm_ga4Q@mail.gmail.com>
 <CAPTjJmqkT-ofa3CiN2hX4B9m3pJZJP2AqA-Sh2HXf7q2AMPG4w@mail.gmail.com>
 <CAE6NSRCyAnDVyNS-MFAMpti7m4qMHmLuKmm1Ts_xrO2VmFFDSg@mail.gmail.com>
 <85tvrhofc5.fsf@benfinney.id.au>
Message-ID: <CAE6NSRDVe7Dz1ZCU=OtPC=uGAQSUp5_hXfQZwB7vCAAt_PitwQ@mail.gmail.com>

On Wed, May 9, 2018 at 3:14 AM, Ben Finney <ben+python at benfinney.id.au> wrote:
> Mikhail V <mikhailwas at gmail.com> writes:
>
>> On Wed, May 9, 2018 at 12:33 AM, Chris Angelico <rosuav at gmail.com> wrote:
>> > On Wed, May 9, 2018 at 7:15 AM, Mikhail V <mikhailwas at gmail.com> wrote:
>> >> Just admit it, you try to troll me (or just pretend, I don't know).
>> >
>> > No, I am not trolling you.
>>
>> I don't believe you.
>
> If that's true ? if you believe Chris is trolling you ? then please do
> not continue the conversation. Since you have already decided Chris is
> trolling you,

Well, the thing is I don't know how exactly the word "trolling" can
be understood by different persons. I use it here in sense of "nitpicking".
Or "fooling around" I don't know actually.
So may be "trolling" has too negative associations to your ears?

As for Chris' attitude in this thread, and my point on this -
well, honestly yes, I believe he uses an opportunity to push
his own game. It has happened before - and now I know already,
so I know that trying to explain and honestly answer his questions ends up
in the same game of Chris - so I suppose he amuses himself
in such a way.
Same scenario happens here - he just completely neglects the whole
proposal straight away with a bold provoking statement.
But then asks "why do you think this a good proposal?"
Which I actually tried to describe in the very proposal.

So honestly I can't understand what game this time he prepared,
and not very much into this kind of things.



>
> This forum has no need of another thread attempting to ?win? an argument
> that one side believes is dishonest.
>
> --
>  \       ?The best in us does not require the worst in us: Our love of |
>   `\     other human beings does not need to be nurtured by delusion.? |
> _o__)                             ?Sam Harris, at _Beyond Belief 2006_ |
> Ben Finney
>
> --
> https://mail.python.org/mailman/listinfo/python-list


From steve+comp.lang.python at pearwood.info  Tue May  8 23:25:53 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Wed, 9 May 2018 03:25:53 +0000 (UTC)
Subject: Suggestion for a "data" object syntax
References: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
 <pcriqa$16m$13@blaine.gmane.org>
 <CAE6NSRCo8-dVWSAYuY8MHH6vviy_2Qn_LpGa2kRTN8L2=cceXQ@mail.gmail.com>
 <pcsf85$16m$15@blaine.gmane.org>
 <CAE6NSRALn2benyf+C87bCKSwRH3gzXcd1WHj_EawR9OngqbcSg@mail.gmail.com>
Message-ID: <pctpo0$qbi$1@blaine.gmane.org>

On Tue, 08 May 2018 23:16:23 +0300, Mikhail V wrote:

> I don't propose to remove spaces, 

And that is why the syntax will be ambiguous. So long as whitespace is 
*allowed* but not *required* around operators, there will be ambiguity 
between a - b and a - b with no way to tell whether they are intended as 
two items or one.


> but I propose Tab-separated elements.

We already have tab-separated elements in Python. It is allowed to use 
tabs between any whitespace separated tokens.

The only restriction is that in Python 3 you must use *consistent* spaces 
or tabs but not a mix of both for indents.


> If I allow commas as well, this will become not so simple, probably.
> Also I don't propose syntax for e-mail code exchange, but rather syntax
> for *work* an this can potentially help a lot of people in everyday
> work.

/head-desk

You: "I have invented amazing new syntax that cannot be exchanged by 
email. Here, let me email some examples to you."

Do you understand that you have already emailed samples of this proposed 
code?


> Also I don't know what kind of human thinks that this:
>  a + b
>  is two elements "a" and "+ b"
> What is "+ b"? 

It is unary plus followed by b.

If you don't know Python's existing syntax, how can you possibly expect 
to invent new syntax?


> And who writes "- b" with a space in unary minus? I don't. Nobody does.

Oh well, if you don't, then clearly nobody in the world, and no code 
generators, could possibly do it. Because Mikhail says so.


> Is it allowed? yes. no problem.

Since it is allowed, it is a HUGE problem for your syntax, since your 
syntax cannot distinguish between the two cases.


[...]
> There is "invisible" difference in indentations tabs vs spaces - so
> what? 

That means that people will look at a piece of code and not know whether 
they are seeing spaces or tabs, since they are both invisible.


> I don't want spaces or tabs visible - there is toggle "show tabs"
> and "toggle show space" for that

/head-desk

You: "This syntax doesn't need tabs and spaces to be visible. Just use 
the Show Tabs and Show Spaces commands on your editor to make them 
visible."


> Those are basically universal features. And thousands of Python people
> already use tabs to align columns so you have to accept it

Current syntax allows people to use tabs to align columns, and it remains 
unambiguous no matter how wacky people align their data, because of the 
commas. Even if they think they are writing Fortran with fixed column 
widths, it is still unambiguous to both the human reader and the parser:

data = [        +       a       ,       -        b      ,
                -       foo     ,       +        bar    ,       ]

even if they separate operators from their operands with tabs. Paste that 
into your Python interpreter, and it has an unambiguous meaning.

The same does not apply to your syntax. Take out the commas, and it is 
impossible to tell what the code means or how many columns it has.


>> Using a particular editor is not and will not be a mandatory
>> requirement for Python.
> 
> Using outdated tools or being PEBCAK are not and will not be
> justification for language syntax improvements.

It is not your choice of what editors people are permitted to use in 
order to read and write Python.


[...]
>> - the first one allows you to write it as a single line:
>>
>>     L = ((a, 1), (b, 2), (c, 3), (foobar, 4))
>>
>>   instead of wasting vertical space;
> 
> Wasting space you say? You economize paper for printing out?

No. I arrange code in the best way I see fit, depending on the code. 
Sometimes that means I put things on a single line, so as to fit more 
lines into a single screen, sometimes it means I spread things out over 
multiple lines in order to get maximum benefit from two dimensional 
layout. It all depends on the code I am writing and I use whatever is 
best for the situation.


>> - the first one is unambiguous while the second is ambiguous;
> 
> I think it's time to reveal what exactly you mean here.

For the fourth time, it means that the current syntax is unambiguous and 
only ever has a single meaning. Your suggestion is ambiguous, it cannot 
be parsed into a single meaning, and you have to guess what the code 
possibly means.

A single expression like either of these:

	a	+	b

	a	+b

under your syntax have TWO legal meanings, and there is no way to tell 
which is required except to guess.

I do not know how to make it more clear.


>> - the first one can include nested data structures, while
>>   the second cannot.
> 
> Why it can't? did you read the original e-mail?

Of course I did. You said:

    "To present nesting of elements of higher than 2 levels, 
    normal Python syntax can be used for deeper nesting"

and 

    "So the idea is to cover only first two levels of 
    nesting of course."

With bracket syntax, I can cover unlimited levels of nesting. Yours 
cannot.




-- 
Steve



From python at bladeshadow.org  Tue May  8 23:48:52 2018
From: python at bladeshadow.org (Python)
Date: Tue, 8 May 2018 22:48:52 -0500
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <pcqrv9$16m$12@blaine.gmane.org>
References: <20180507202722.GD7876@tauhou>
 <pcqrv9$16m$12@blaine.gmane.org>
Message-ID: <20180509034852.GB12850@bladeshadow.org>

On Tue, May 08, 2018 at 12:45:29AM +0000, Steven D'Aprano wrote:
> Currently, the real reason is that lambda expressions are limited to a 
> single expression as the body of the function, and binding operations in 
> Python are statements. 

...which begs the question, why shouldn't assignments be expressions,
as they are in many other languages?  TBH this is one of the few
things about Python that I dislike.

> > So far, no satisfying answer has come up, except for maybe to avoid a
> > programmer accidentally typing `=` instead of `==`, which I find a bit
> > unsatisfying as the only reason.
> 
> No, that's the reason why = is a statement not an expression. That's not 
> why statements aren't allowed in lambdas. If we had blocks, this would be 
> perfectly acceptable:
> 
> lambda arg: %%%START BLOCK
>     spam = arg + 1
>     ...
>     %%%END BLOCK
> 
> since = in a statement on its own is not dangerous. People *almost never* 
> intend to write == for the side-effects only:

Seriously?  I do this--not every day, but more than occasionally, not
just in Python.

    flag = (spam == arg)
vs.
    if spam == arg:
        flag = True
    else:
        flag = False
    if flag:
        do_something()
    else:
        do_something_else()

Obviously this is a simple example which could be rewritten and/or the
comparison copy-pasted; assume a more complex system where you need to
check if the two objects were equal in multiple places, but obtaining
the objects is computationally expensive (say, processing a large file
to obtain a large list of objects), and comparing them is likewise
computationally expensive.

>     # don't care whether they are actually equal or not
>     # just want to call the __eq__ method for its side-effects
>     spam == arg + 1
> 
> Since that never happens in real life, there's no risk of accidentally 
> writing "spam = arg + 1" when you wanted "spam == arg + 1".

I've always felt that this mentality was insulting to the programmer:
"You're too stupid to get this right."  Sure, I've created that bug in
other languages (or rather its inverse) but not since college.  You
make it a few times, you go nuts debugging it, you learn what it is,
you never do it again.

And, this kind of thing is what code reviews are for--Python isn't so
idiot-proof that you can get away without doing them for any
non-trivial code--so (IMO) the language should not prevent you from
doing useful things *simply* because you *might* make a mistake.  I'll
give you an example that is both a case where Python's design choices
make creating a bug easier, AND a case where allowing assignments to
be expressions would save you.

    flag = we_are_done()
    while not flag:
        # do some stuff
        ...
        if error_occured():
            break
        falg = we_are_done()
    notify_user()
   # flag will be checked again later, perhaps for error reporting

Here, a common programming pattern (prime the loop control variable)
gets you in trouble, because the assignment happens in two places, and
you mistyped one of them.  There's no syntax error, but your program
will execute forever, unless you were already done on the first call
to prime the flag, or an error occurs.  This is probably worse than
the = vs. == error, because your brain tends to "autocorrect" certain
kinds of spelling errors, whereas experienced programmers learn to
look for (or avoid entirely) the assignment vs. comparison bug.  The
error here is reasonably easy to spot, given the trivial nature of the
example, but would likely be harder to spot in more complex code with
longer, more meaningful variable names.

This example also is a case FOR allowing assignments to be
expressions.  If Python allowed them, you could rewrite this as:

   while not (flag = we_are_done()):
        ...
        if error_occured():
            break
   notify_user()
   # flag will be checked again later, perhaps for error reporting

This COMPLETELY PREVENTS the spelling bug in the code above, since the
assignment only happens in one place; and as a bonus it's less code.



From rosuav at gmail.com  Wed May  9 01:09:18 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 9 May 2018 15:09:18 +1000
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <20180509034852.GB12850@bladeshadow.org>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
Message-ID: <CAPTjJmqq0B=qyvba8t8cuJGiACNJwfFpmXVkUb_3oMkh0Jg+vg@mail.gmail.com>

On Wed, May 9, 2018 at 1:48 PM, Python <python at bladeshadow.org> wrote:
>> since = in a statement on its own is not dangerous. People *almost never*
>> intend to write == for the side-effects only:
>
> Seriously?  I do this--not every day, but more than occasionally, not
> just in Python.
>
>     flag = (spam == arg)
> vs.
>     if spam == arg:
>         flag = True
>     else:
>         flag = False
>     if flag:
>         do_something()
>     else:
>         do_something_else()

That's not "side effects only". You're evaluating a comparison for its
result - its primary effect. You're assigning the result of the
comparison to something.

Using equality comparisons for side effects would look like this:

spam == arg

No assignment. Just that, as a statement all on its own. It's
perfectly legal, but I doubt you've ever actually done this.

ChrisA


From ian.g.kelly at gmail.com  Wed May  9 01:36:06 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Tue, 8 May 2018 23:36:06 -0600
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <20180509034852.GB12850@bladeshadow.org>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
Message-ID: <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>

On Tue, May 8, 2018 at 9:48 PM, Python <python at bladeshadow.org> wrote:
> On Tue, May 08, 2018 at 12:45:29AM +0000, Steven D'Aprano wrote:
>> since = in a statement on its own is not dangerous. People *almost never*
>> intend to write == for the side-effects only:
>
> Seriously?  I do this--not every day, but more than occasionally, not
> just in Python.
>
>     flag = (spam == arg)
> vs.
>     if spam == arg:
>         flag = True
>     else:
>         flag = False
>     if flag:
>         do_something()
>     else:
>         do_something_else()

As Chris pointed out, this is not an example of using == for side-effects only.

>>     # don't care whether they are actually equal or not
>>     # just want to call the __eq__ method for its side-effects
>>     spam == arg + 1
>>
>> Since that never happens in real life, there's no risk of accidentally
>> writing "spam = arg + 1" when you wanted "spam == arg + 1".
>
> I've always felt that this mentality was insulting to the programmer:
> "You're too stupid to get this right."  Sure, I've created that bug in
> other languages (or rather its inverse) but not since college.  You
> make it a few times, you go nuts debugging it, you learn what it is,
> you never do it again.
>
> And, this kind of thing is what code reviews are for--Python isn't so
> idiot-proof that you can get away without doing them for any
> non-trivial code--so (IMO) the language should not prevent you from
> doing useful things *simply* because you *might* make a mistake.

I do code reviews every day, and I doubt that I would actually notice
if one of them slipped in '=' where '==' was intended. Hopefully it
would be caught by unit testing though.

>  I'll
> give you an example that is both a case where Python's design choices
> make creating a bug easier, AND a case where allowing assignments to
> be expressions would save you.
>
>     flag = we_are_done()
>     while not flag:
>         # do some stuff
>         ...
>         if error_occured():
>             break
>         falg = we_are_done()
>     notify_user()
>    # flag will be checked again later, perhaps for error reporting


while True:
    if we_are_done():
        break
    # do some stuff
    ...
    if error_occurred():
        break
notify_user()


Fixed, using idiomatic Python and without needing to use assignment in
an expression.

> Here, a common programming pattern (prime the loop control variable)
> gets you in trouble, because the assignment happens in two places, and
> you mistyped one of them.  There's no syntax error, but your program
> will execute forever, unless you were already done on the first call
> to prime the flag, or an error occurs.  This is probably worse than
> the = vs. == error, because your brain tends to "autocorrect" certain
> kinds of spelling errors, whereas experienced programmers learn to
> look for (or avoid entirely) the assignment vs. comparison bug.  The
> error here is reasonably easy to spot, given the trivial nature of the
> example, but would likely be harder to spot in more complex code with
> longer, more meaningful variable names.
>
> This example also is a case FOR allowing assignments to be
> expressions.  If Python allowed them, you could rewrite this as:
>
>    while not (flag = we_are_done()):
>         ...
>         if error_occured():
>             break
>    notify_user()
>    # flag will be checked again later, perhaps for error reporting
>
> This COMPLETELY PREVENTS the spelling bug in the code above, since the
> assignment only happens in one place; and as a bonus it's less code.

Or just use an IDE with variable name autocompletion.


From greg.ewing at canterbury.ac.nz  Wed May  9 01:38:35 2018
From: greg.ewing at canterbury.ac.nz (Gregory Ewing)
Date: Wed, 09 May 2018 17:38:35 +1200
Subject: Problem/bug with class definition inside function definition
In-Reply-To: <mailman.33.1525766104.28519.python-list@python.org>
References: <1525730554.24805.0@smtp.gmail.com>
 <1525731660.30323.0@smtp.gmail.com> <1525766100.4532.0@smtp.gmail.com>
 <mailman.33.1525766104.28519.python-list@python.org>
Message-ID: <flffqtFp8mlU1@mid.individual.net>

Alexey Muranov wrote:
>    x = 42
> 
>    class C:
>        x = x  # Works

I'd say it kind of works by accident, and is not really an
intended feature.

> if Python does not allow to refer "simultaneously" to 
> variables from different scopes if they have the same name.

It seems perfectly reasonable to me to have to use different
names to refer to different things in the same context. :-)

-- 
Greg


From steve+comp.lang.python at pearwood.info  Wed May  9 01:44:57 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Wed, 9 May 2018 05:44:57 +0000 (UTC)
Subject: seeking deeper (language theory) reason behind Python design
 choice
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
Message-ID: <pcu1so$qbi$2@blaine.gmane.org>

On Tue, 08 May 2018 22:48:52 -0500, Python wrote:

> On Tue, May 08, 2018 at 12:45:29AM +0000, Steven D'Aprano wrote:
>> Currently, the real reason is that lambda expressions are limited to a
>> single expression as the body of the function, and binding operations
>> in Python are statements.
> 
> ...which begs the question, why shouldn't assignments be expressions, as
> they are in many other languages?  TBH this is one of the few things
> about Python that I dislike.

No, it raises the question :-) Begging the question means to assume the 
answer to the same question you are asking.

As Chris already pointed out, there is a PEP in progress at the moment 
aimed at allowing assignment expressions (PEP 572). It is very 
controversial, but Guido appears to be in favour of it (as I am, although 
not necessarily in its current form). There's about a bazillion emails on 
the Python-Ideas and Python-Dev mailing lists arguing about it.

(Oh, and it goes *all the way back to February*.)

In the very earliest versions of Python, like 0.1, there was only a 
single = operator that was used for both equals and assignment, but that 
was changed by the first official 1.0 release. I don't know if that 
change was driven by personal preference (Guido just liked it better), 
bad experiences with bugs, or what.

But by the time 1.4 came around, Guido had settled on a clean separation 
between statements and expressions as part of Python's design.

That separation has gradually weakened over the years, with the addition 
of the ternary if operator and comprehensions, but it is still an 
important part of Python's design. You might find something on Guido's 
blogs or his various essays:

http://neopythonic.blogspot.com.au/

https://www.artima.com/weblogs/index.jsp?blogger=guido

https://legacy.python.org/doc/essays/


but I don't have time to go trawling the blogs for this.

It might simply be that Guido (like many people) considered assignment to 
fundamentally be an imperative command, not an expression.

Another reason is something Nick Coghlan (re-)discovered during the 
discussions for PEP 572, namely that if you allow the full, unrestricted 
assignment targets as an expression, the code is ambiguous or at least 
hard to understand the intent. That's why PEP 572 has limited assignments 
to just plain names, and not arbitrary assignment targets. Possibly Guido 
recognised this way back in Python 0.x as well.


>> since = in a statement on its own is not dangerous. People *almost
>> never* intend to write == for the side-effects only:
> 
> Seriously?  I do this--not every day, but more than occasionally, not
> just in Python.
> 
>     flag = (spam == arg)

Of course we all do that, but it is nothing like what I said. I even gave 
fully-commented sample code, which you appear to have missed:

    # don't care whether they are actually equal or not
    # just want to call the __eq__ method for its side-effects
    spam == arg + 1

I bet you never, ever, ever call == for the side-effects, throwing away 
the result of the comparison without using it or looking at it in any 
way. In many languages, such a comparison cannot even have side-effects, 
so it would be useless dead code.


>>     # don't care whether they are actually equal or not 
>>     # just want to call the __eq__ method for its side-effects
>>     spam == arg + 1
>> 
>> Since that never happens in real life, there's no risk of accidentally
>> writing "spam = arg + 1" when you wanted "spam == arg + 1".
> 
> I've always felt that this mentality was insulting to the programmer:
> "You're too stupid to get this right."  Sure, I've created that bug in
> other languages (or rather its inverse) but not since college.  You make
> it a few times, you go nuts debugging it, you learn what it is, you
> never do it again.

And fortunately we don't have to deal with a steady stream of new 
programmers learning the language and making newbie errors, right?

If all programmers were as awesome as you and never made typos, the world 
would be a better place. But we know from experience that even 
experienced C programmers can make this mistake by accident.

Or deliberately:

https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-attempt-
of-2003/

or if that URL wraps: https://tinyurl.com/jpvbtua


Of course we all make mistakes, but some features and syntax are bug 
magnets: they *encourage* errors rather than discourage them. Anyone can 
mistype "flga" when they meant "flag", but the use of real words 
discourages that error since the reader can see that "flga" looks weird. 
But == and = are so similar that not only is it an easy typo to make, but 
its a hard typo to spot without a close, careful reading.


-- 
Steve



From rosuav at gmail.com  Wed May  9 01:50:41 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 9 May 2018 15:50:41 +1000
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
Message-ID: <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>

On Wed, May 9, 2018 at 3:36 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
>
> while True:
>     if we_are_done():
>         break
>     # do some stuff
>     ...
>     if error_occurred():
>         break
> notify_user()
>
>
> Fixed, using idiomatic Python and without needing to use assignment in
> an expression.

Why is it that "while True" is idiomatic Python for a non-infinite
loop? Is it merely because Python currently has no other way to spell
certain loops? Surely it would be more idiomatic to encode the loop's
termination condition in the header, if it were possible.

ChrisA


From rosuav at gmail.com  Wed May  9 01:57:35 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 9 May 2018 15:57:35 +1000
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <pcu1so$qbi$2@blaine.gmane.org>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org> <pcu1so$qbi$2@blaine.gmane.org>
Message-ID: <CAPTjJmp5GyJi1BGCkag3GoatOHVH=umd831J3x+iukpK0FcNHA@mail.gmail.com>

On Wed, May 9, 2018 at 3:44 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Tue, 08 May 2018 22:48:52 -0500, Python wrote:
>> I've always felt that this mentality was insulting to the programmer:
>> "You're too stupid to get this right."  Sure, I've created that bug in
>> other languages (or rather its inverse) but not since college.  You make
>> it a few times, you go nuts debugging it, you learn what it is, you
>> never do it again.
>
> And fortunately we don't have to deal with a steady stream of new
> programmers learning the language and making newbie errors, right?
>
> If all programmers were as awesome as you and never made typos, the world
> would be a better place. But we know from experience that even
> experienced C programmers can make this mistake by accident.

Yes, and I'd go further: I *am* too stupid to get this right. That's
why I have an editor that highlights certain words. (My current editor
colours every Python standard library module name, so if I happen to
create a variable called "time", it'll make it really obvious that I
am now shadowing an importable module. Or, as I recently did,
"sched".) That's why Python gives me tracebacks that show me exactly
where I messed up. That's why my code is full of debugging checks,
comments, and other tools to help me track down my mistakes after I
make them.

Because I *will* make mistakes. I will make a LOT of mistakes. And I
am not going to try to pretend that I don't.

ChrisA


From mal at europython.eu  Wed May  9 07:55:21 2018
From: mal at europython.eu (M.-A. Lemburg)
Date: Wed, 9 May 2018 13:55:21 +0200
Subject: EuroPython 2018: Ticket Sales Update
Message-ID: <f6e73885-2e85-c232-366c-47a55ea1762f@europython.eu>

Some community members have been wondering why tickets are not
available yet. We?d like to update you on the current status.

EuroPython is run by the EuroPython Society located in
Sweden. However, the conference being held in the UK, we have to
charge UK VAT for the tickets we sell and submit the collected VAT to
the UK tax authorities. In order to be able to do this, we have
register with the UK tax authorities and this is where we have
experienced unforseen delays.

After several attempts at getting this sorted, our friends at PyCon UK
have helped us find a capable accountant with whom we are currently
implementing the registration. Hopefully, the tax authorities won?t
take too long to issue us a UK VAT ID. As soon as we have it, we will
start ticket sales.

Ticket Prices Available
-----------------------

That said, we do already have some more information for you: we have
decided on the initial ticket prices for EuroPython 2018. In case you
need budget approval from your employer, you may put in your request
now.

Please see our blog post or registration page for full details on the
ticket pricing:

*
https://blog.europython.eu/post/173732504642/europython-2018-ticket-sales-update
* https://ep2018.europython.eu/en/registration/buy-tickets/


Enjoy,
--
EuroPython 2018 Team
https://ep2018.europython.eu/
https://www.europython-society.org/


PS: Please forward or retweet to help us reach all interested parties:
https://twitter.com/europython/status/994182851997421569
Thanks.



From rhodri at kynesim.co.uk  Wed May  9 08:26:42 2018
From: rhodri at kynesim.co.uk (Rhodri James)
Date: Wed, 9 May 2018 13:26:42 +0100
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <CAPTjJmp5GyJi1BGCkag3GoatOHVH=umd831J3x+iukpK0FcNHA@mail.gmail.com>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org> <pcu1so$qbi$2@blaine.gmane.org>
 <CAPTjJmp5GyJi1BGCkag3GoatOHVH=umd831J3x+iukpK0FcNHA@mail.gmail.com>
Message-ID: <0c75d4f7-7f09-d6f4-9113-bf5d529eb864@kynesim.co.uk>

On 09/05/18 06:57, Chris Angelico wrote:
> On Wed, May 9, 2018 at 3:44 PM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> On Tue, 08 May 2018 22:48:52 -0500, Python wrote:
>>> I've always felt that this mentality was insulting to the programmer:
>>> "You're too stupid to get this right."  Sure, I've created that bug in
>>> other languages (or rather its inverse) but not since college.  You make
>>> it a few times, you go nuts debugging it, you learn what it is, you
>>> never do it again.
>>
>> And fortunately we don't have to deal with a steady stream of new
>> programmers learning the language and making newbie errors, right?
>>
>> If all programmers were as awesome as you and never made typos, the world
>> would be a better place. But we know from experience that even
>> experienced C programmers can make this mistake by accident.
> 
> Yes, and I'd go further: I *am* too stupid to get this right.

Thirded.  I am a C and assembler programmer by trade, and I often type 
"=" for "==" when I'm coding quickly, and sometimes even when I'm trying 
to be careful.  I've met a lot of programmers over the years who assert 
that they are experienced enough not to make mistakes like that.  They 
are, without fail, embarrassed when I turn on the compiler warning flags.

-- 
Rhodri James *-* Kynesim Ltd


From jf_byrnes at comcast.net  Wed May  9 14:28:40 2018
From: jf_byrnes at comcast.net (Jim)
Date: Wed, 9 May 2018 13:28:40 -0500
Subject: Problems after upgrading Python 3.6.3 to 3.6.5
Message-ID: <pcvegl$fem$1@blaine.gmane.org>

I am running Linux Mint 18.1 and Python3 version 3.5.2,

Awhile ago I installed Python3.6 from LP-PPA-jonathonf-python-3.6/now.
I did it to run 3.6 in virtual environment. Everything was working until 
I allowed the package manager to upgrade 3.6.3 to 3.6.5. See (1) below.

First problem I had was pip would not run. I solved that problem with 
help from another forum. Then I discovered I could not import tkinter in 
my 3.6 EV. At the end of the error message  (2) it said to install 
python3-tk. After i did so I could import tkinter in 3.6 but not the 
default system python3.5.

At this point I checked the log (1) and saw that python3-tk had been 
removed. Looking at the installed version of python3-tk it now said
3.6.5~16.04.york0.2.

So does the version matter between python3.5 and 3.6 or do I just have 
some kind of path problem. At this point I am somewhat lost as to how to 
get tkinter working again in 3.5.

Regards,  Jim


  (1)
Commit Log for Thu May  3 13:26:38 2018

Removed the following packages:
python3-tk

Upgraded the following packages:
libpython3.6-minimal (3.6.3-1ubuntu1~16.04.york1) to 3.6.5-5~16.04.york0
libpython3.6-stdlib (3.6.3-1ubuntu1~16.04.york1) to 3.6.5-5~16.04.york0
python3.6 (3.6.3-1ubuntu1~16.04.york1) to 3.6.5-5~16.04.york0
python3.6-minimal (3.6.3-1ubuntu1~16.04.york1) to 3.6.5-5~16.04.york0
python3.6-venv (3.6.3-1ubuntu1~16.04.york1) to 3.6.5-5~16.04.york0

Commit Log for Fri May  4 14:32:44 2018

Upgraded the following packages:
python3-gdbm (3.6.3-0ubuntu1~16.04.york0) to 3.6.5-3~16.04.york0.2

Commit Log for Sun May  6 09:28:25 2018

Installed the following packages:
python3-tk (3.6.5-3~16.04.york0.2)

Commit Log for Sun May  6 11:42:31 2018

Installed the following packages:
libexpat1-dev (2.1.0-7ubuntu0.16.04.3)
libpython3-dev (3.5.1-3)
libpython3.5-dev (3.5.2-2ubuntu0~16.04.4)
python3-dev (3.5.1-3)
python3.5-dev (3.5.2-2ubuntu0~16.04.4)

(2)
jfb at jims-mint18 ~ $ python3
Python 3.5.2 (default, Nov 23 2017, 16:37:01)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
 >>> import tkinter
Traceback (most recent call last):
   File "/usr/lib/python3.5/tkinter/__init__.py", line 36, in <module>
     import _tkinter
ImportError: No module named '_tkinter'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "/usr/lib/python3.5/tkinter/__init__.py", line 38, in <module>
     raise ImportError(str(msg) + ', please install the python3-tk package')
ImportError: No module named '_tkinter', please install the python3-tk 
package
 >>>




From bc at freeuk.com  Wed May  9 17:48:42 2018
From: bc at freeuk.com (bartc)
Date: Wed, 9 May 2018 22:48:42 +0100
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <mailman.62.1525844855.28519.python-list@python.org>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org> <pcu1so$qbi$2@blaine.gmane.org>
 <mailman.62.1525844855.28519.python-list@python.org>
Message-ID: <Q0KIC.79619$jb7.24372@fx34.am4>

On 09/05/2018 06:44, Steven D'Aprano wrote:
> On Tue, 08 May 2018 22:48:52 -0500, Python wrote:
> 

> But by the time 1.4 came around, Guido had settled on a clean separation
> between statements and expressions as part of Python's design.
> 
> That separation has gradually weakened over the years,

Presumably it's non-existent now, as it seems you can type any 
expression as a statement in its own right:

   "stmt"
   a + b*c
   p == 0

  with the addition
> of the ternary if operator

If you mean that this is a kind of statement that can be incorporated 
into an expression, then just class it as an operator not a statement. 
(They are different in any case, for example statement-if doesn't return 
a value.)


> and comprehensions,

And that one, although it's a more complex example.

> It might simply be that Guido (like many people) considered assignment to
> fundamentally be an imperative command, not an expression.

You design a language, you get to choose how it works.

(I allow assignments in expressions in my languages, but the two are 
different constructs: statement-assignment returns no value; 
expression-assignment does, although both use ":=" syntax for the 
assignment operator.

That's OK ":=" doesn't really get mixed up with "=" for equality as "=" 
and "==" would do. So one answer would be to use something other than 
"=" for assignments within expressions.

I don't however allow augmented assignments in expressions, as it's not 
that useful, and it would be too much (and I could never get the 
precedences right). But normal assignment is handy.)

-- 
bartc


From steve+comp.lang.python at pearwood.info  Wed May  9 22:08:02 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Thu, 10 May 2018 02:08:02 +0000 (UTC)
Subject: seeking deeper (language theory) reason behind Python design
 choice
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org> <pcu1so$qbi$2@blaine.gmane.org>
 <mailman.62.1525844855.28519.python-list@python.org>
 <Q0KIC.79619$jb7.24372@fx34.am4>
Message-ID: <pd09i2$qbi$3@blaine.gmane.org>

On Wed, 09 May 2018 22:48:42 +0100, bartc wrote:

> On 09/05/2018 06:44, Steven D'Aprano wrote:
>> On Tue, 08 May 2018 22:48:52 -0500, Python wrote:
>> 
>> 
>> But by the time 1.4 came around, Guido had settled on a clean
>> separation between statements and expressions as part of Python's
>> design.
>> 
>> That separation has gradually weakened over the years,
> 
> Presumably it's non-existent now, as it seems you can type any
> expression as a statement in its own right:

That has always been the case. What I mean is that a few of the pure-
statement features have now gained an expression form.


>> with the addition of the ternary if operator
> 
> If you mean that this is a kind of statement that can be incorporated
> into an expression, then just class it as an operator not a statement.

I called it an operator because it is an operator :-)


To hopefully be more clear, any expression can be used as a statement 
(usually pointlessly). But statements (aside from expressions) cannot be 
used as expressions. There are, however, a small number of statements 
which have gained an equivalent expression form.



-- 
Steve



From marko at pacujo.net  Thu May 10 04:09:39 2018
From: marko at pacujo.net (Marko Rauhamaa)
Date: Thu, 10 May 2018 11:09:39 +0300
Subject: seeking deeper (language theory) reason behind Python design
 choice
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <pcu1so$qbi$2@blaine.gmane.org>
 <mailman.62.1525844855.28519.python-list@python.org>
 <Q0KIC.79619$jb7.24372@fx34.am4>
Message-ID: <87fu309bjw.fsf@elektro.pacujo.net>

bartc <bc at freeuk.com>:
> On 09/05/2018 06:44, Steven D'Aprano wrote:
>> But by the time 1.4 came around, Guido had settled on a clean separation
>> between statements and expressions as part of Python's design.
>>
>> That separation has gradually weakened over the years,
>
> Presumably it's non-existent now, as it seems you can type any
> expression as a statement in its own right:
>
>   "stmt"
>   a + b*c
>   p == 0

When typing in code (in various languages), I have a habit of typing
"..." at places that need to be implemented. For example:

    if count:
        ...
    else:
        do_something_smart()
        break

the idea being that "..." will surely trigger a syntax error if I forget
to address it.

I was mildly amused when Python happily executed such code. "..." is a
valid expression and thus, a valid statement.


Marko


From rustompmody at gmail.com  Thu May 10 04:38:51 2018
From: rustompmody at gmail.com (Rustom Mody)
Date: Thu, 10 May 2018 01:38:51 -0700 (PDT)
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <87fu309bjw.fsf@elektro.pacujo.net>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org> <pcu1so$qbi$2@blaine.gmane.org>
 <mailman.62.1525844855.28519.python-list@python.org>
 <Q0KIC.79619$jb7.24372@fx34.am4>
 <87fu309bjw.fsf@elektro.pacujo.net>
Message-ID: <07f64d7d-de4b-4ea9-9a0d-8684b41b2ab8@googlegroups.com>

Marko wrote:
> When typing in code (in various languages), I have a habit of typing 
> "..." at places that need to be implemented

Quite a research area actually
https://wiki.haskell.org/GHC/Typed_holes


From bc at freeuk.com  Thu May 10 06:02:05 2018
From: bc at freeuk.com (bartc)
Date: Thu, 10 May 2018 11:02:05 +0100
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <87fu309bjw.fsf@elektro.pacujo.net>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org> <pcu1so$qbi$2@blaine.gmane.org>
 <mailman.62.1525844855.28519.python-list@python.org>
 <Q0KIC.79619$jb7.24372@fx34.am4> <87fu309bjw.fsf@elektro.pacujo.net>
Message-ID: <kMUIC.171380$Vm6.104840@fx45.am4>

On 10/05/2018 09:09, Marko Rauhamaa wrote:
> bartc <bc at freeuk.com>:
>> On 09/05/2018 06:44, Steven D'Aprano wrote:
>>> But by the time 1.4 came around, Guido had settled on a clean separation
>>> between statements and expressions as part of Python's design.
>>>
>>> That separation has gradually weakened over the years,
>>
>> Presumably it's non-existent now, as it seems you can type any
>> expression as a statement in its own right:
>>
>>    "stmt"
>>    a + b*c
>>    p == 0
> 
> When typing in code (in various languages), I have a habit of typing
> "..." at places that need to be implemented. For example:
> 
>      if count:
>          ...
>      else:
>          do_something_smart()
>          break
> 
> the idea being that "..." will surely trigger a syntax error if I forget
> to address it.
> 
> I was mildly amused when Python happily executed such code. "..." is a
> valid expression and thus, a valid statement.

I wondered what it meant, so I typed in:

    print (...)

and it displayed:

    Ellipsis

which wasn't very enlightening.

-- 
bartc




From marko at pacujo.net  Thu May 10 06:21:26 2018
From: marko at pacujo.net (Marko Rauhamaa)
Date: Thu, 10 May 2018 13:21:26 +0300
Subject: seeking deeper (language theory) reason behind Python design
 choice
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <pcu1so$qbi$2@blaine.gmane.org>
 <mailman.62.1525844855.28519.python-list@python.org>
 <Q0KIC.79619$jb7.24372@fx34.am4> <87fu309bjw.fsf@elektro.pacujo.net>
 <kMUIC.171380$Vm6.104840@fx45.am4>
Message-ID: <87a7t7ak0p.fsf@elektro.pacujo.net>

bartc <bc at freeuk.com>:
> I wondered what it meant, so I typed in:
>
>    print (...)
>
> and it displayed:
>
>    Ellipsis
>
> which wasn't very enlightening.

It doesn't mean anything for Python. It's just a special singleton
sentinel object that is stored in the predefined variable "Ellipsis" and
has a literal "..." in the language.

Apparently, Python provides it as a courtesy to the Numpy module:

   https://docs.scipy.org/doc/numpy-1.13.0/reference/arrays.indexing.html


Marko


From vs at it.uu.se  Thu May 10 06:43:33 2018
From: vs at it.uu.se (Virgil Stokes)
Date: Thu, 10 May 2018 12:43:33 +0200
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
Message-ID: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>

Module info:

Python 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 17:00:18) [MSC v.1900 64 
bit (AMD64)]

C:\Python36>pip show datetime
Name: DateTime
Version: 4.2
Summary: This package provides a DateTime data type, as known from Zope 
2. Unless you need to communicate with Zope 2 APIs, you're probably 
better off using Python's built-in datetime module.
Home-page: http://pypi.python.org/pypi/DateTime
Author: Zope Foundation and Contributors
Author-email: zope-dev at zope.org
License: ZPL 2.1
Location: c:\python36\lib\site-packages
Requires: zope.interface, pytz

I tried first to use Python's built-in datetime module as follows:

from datetime import date, timedelta

 ?d0 = date(2018,02,01)

This gave the following error:

Syntax Error: invalid token: C:\Users\Virgil Stokes\Desktop\Important 
Notes_Files\CheckProcessingDate_02.py, line 7, pos 17
d0 = date(2018,02,01)

Then I used pip to install the datetime module and the same error 
occurred! However, when I removed the leading 0's no syntax error was 
reported and the correct result was returned.

d0 = date(2018,2,1)

Why does the datetime.date? module (both built-in and site-package) not 
accept leading 0's?





From skip.montanaro at gmail.com  Thu May 10 07:28:09 2018
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Thu, 10 May 2018 11:28:09 +0000
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
Message-ID: <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>

>
> This gave the following error:
>
> Syntax Error: invalid token: C:\Users\Virgil Stokes\Desktop\Important
> Notes_Files\CheckProcessingDate_02.py, line 7, pos 17
> d0 = date(2018,02,01)
>

Note that this is a Python syntax error. It actually has nothing to do with
the datetime module. In Python before version 3, leading zeroes were how
you specified octal (base 8) numbers. That changed in Python 3. If you slim
the start of PEP 3127, you'll learn the new notation.

https://www.python.org/dev/peps/pep-3127/

There is a section in that document about removal of the old syntax:

https://www.python.org/dev/peps/pep-3127/#removal-of-old-octal-syntax

Which is what bit you.

Skip


From steve+comp.lang.python at pearwood.info  Thu May 10 07:34:28 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Thu, 10 May 2018 11:34:28 +0000 (UTC)
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
Message-ID: <pd1ao4$qbi$4@blaine.gmane.org>

On Thu, 10 May 2018 12:43:33 +0200, Virgil Stokes wrote:

> Why does the datetime.date? module (both built-in and site-package) not
> accept leading 0's?


This has nothing to do with the datetime module. Syntax Error means it it 
prohibited by the language, not the module.

In Python 2, leading zeroes result in octal (base 8) numbers, which is 
harmless when there is a single digit below 8:

py> 05  # Python 2 octal
5


but mysterious if there is an 8 or 9 digit:

py> 09
  File "<stdin>", line 1
    09
     ^
SyntaxError: invalid token


and a source of errors when there are no 8 or 9 digits:

py> 0123  # pad one hundred twenty-three to four digits
83

So in Python 3, the syntax for octal digits was changed to use a 0o 
prefix, to match the 0x for hexadecimal and 0b for binary, and a bare 
leading 0 made an error.


-- 
Steve



From nobody at nowhere.net  Thu May 10 07:39:27 2018
From: nobody at nowhere.net (AK)
Date: Thu, 10 May 2018 13:39:27 +0200
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <mailman.72.1525949602.28519.python-list@python.org>
Message-ID: <f1ba8c08-39d0-a81d-a8e8-fa12118533e7@nowhere.net>

On 2018-05-10 12:43, Virgil Stokes wrote:
> Module info:
> 
> Python 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 17:00:18) [MSC v.1900 64 
> bit (AMD64)]
[...]
> I tried first to use Python's built-in datetime module as follows:
> 
> from datetime import date, timedelta
> 
>  ?d0 = date(2018,02,01)
> 
> This gave the following error:
> 
> Syntax Error: invalid token: C:\Users\Virgil Stokes\Desktop\Important 
> Notes_Files\CheckProcessingDate_02.py, line 7, pos 17
> d0 = date(2018,02,01)
> 
> Then I used pip to install the datetime module and the same error 
> occurred! However, when I removed the leading 0's no syntax error was 
> reported and the correct result was returned.

It is not a datetime problem. It is PY3 compatibility problem.
Try (should work from both PY2 and PY3):

d0 = date(2018,0o2,0o1)

AK


From akarpierz at gmail.com  Thu May 10 07:39:27 2018
From: akarpierz at gmail.com (AK)
Date: Thu, 10 May 2018 13:39:27 +0200
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <mailman.72.1525949602.28519.python-list@python.org>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <mailman.72.1525949602.28519.python-list@python.org>
Message-ID: <f1ba8c08-39d0-a81d-a8e8-fa12118533e7@nowhere.net>

On 2018-05-10 12:43, Virgil Stokes wrote:
> Module info:
> 
> Python 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 17:00:18) [MSC v.1900 64 
> bit (AMD64)]
[...]
> I tried first to use Python's built-in datetime module as follows:
> 
> from datetime import date, timedelta
> 
>  ?d0 = date(2018,02,01)
> 
> This gave the following error:
> 
> Syntax Error: invalid token: C:\Users\Virgil Stokes\Desktop\Important 
> Notes_Files\CheckProcessingDate_02.py, line 7, pos 17
> d0 = date(2018,02,01)
> 
> Then I used pip to install the datetime module and the same error 
> occurred! However, when I removed the leading 0's no syntax error was 
> reported and the correct result was returned.

It is not a datetime problem. It is PY3 compatibility problem.
Try (should work from both PY2 and PY3):

d0 = date(2018,0o2,0o1)

AK


From darcy at VybeNetworks.com  Thu May 10 07:49:31 2018
From: darcy at VybeNetworks.com (D'Arcy Cain)
Date: Thu, 10 May 2018 07:49:31 -0400
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
Message-ID: <8e30c600-2609-cf03-7965-c4e6877aa4ce@VybeNetworks.com>

On 2018-05-10 07:28 AM, Skip Montanaro wrote:
> https://www.python.org/dev/peps/pep-3127/#removal-of-old-octal-syntax

Funny stuff:

Python could either:

    1. silently do the wrong thing...
    2. immediately disabuse him...
    3. let him continue to think...

Some people passionately believe that (c) is the correct answer

I guess <OL> uses letters in the writer's browser.

-- 
D'Arcy J.M. Cain
Vybe Networks Inc.
http://www.VybeNetworks.com/
IM:darcy at Vex.Net VoIP: sip:darcy at VybeNetworks.com


From darcy at VybeNetworks.com  Thu May 10 07:52:43 2018
From: darcy at VybeNetworks.com (D'Arcy Cain)
Date: Thu, 10 May 2018 07:52:43 -0400
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <f1ba8c08-39d0-a81d-a8e8-fa12118533e7@nowhere.net>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <mailman.72.1525949602.28519.python-list@python.org>
 <f1ba8c08-39d0-a81d-a8e8-fa12118533e7@nowhere.net>
Message-ID: <1009ecf2-fc26-fbfb-c0f7-446e9b204f19@VybeNetworks.com>

On 2018-05-10 07:39 AM, AK wrote:
> Try (should work from both PY2 and PY3):
> 
> d0 = date(2018,0o2,0o1)

Bad advice.  Those numbers are decimal, not octal,  You should use
"date(2018,2,1)" here.  Works in PY2, PY3 and for my birthday, Sept 4.

-- 
D'Arcy J.M. Cain
Vybe Networks Inc.
http://www.VybeNetworks.com/
IM:darcy at Vex.Net VoIP: sip:darcy at VybeNetworks.com


From nobody at nowhere.net  Thu May 10 08:05:44 2018
From: nobody at nowhere.net (AK)
Date: Thu, 10 May 2018 14:05:44 +0200
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <mailman.72.1525949602.28519.python-list@python.org>
 <f1ba8c08-39d0-a81d-a8e8-fa12118533e7@nowhere.net>
 <1009ecf2-fc26-fbfb-c0f7-446e9b204f19@VybeNetworks.com>
 <mailman.75.1525953168.28519.python-list@python.org>
Message-ID: <b028bf9e-5aca-3020-138a-8b2f79ecd5f1@nowhere.net>

On 2018-05-10 13:52, D'Arcy Cain wrote:
> On 2018-05-10 07:39 AM, AK wrote:
>> Try (should work from both PY2 and PY3):
>>
>> d0 = date(2018,0o2,0o1)
> 
> Bad advice.  Those numbers are decimal, not octal,  You should use
> "date(2018,2,1)" here.  Works in PY2, PY3 and for my birthday, Sept 4.

It was only an evidence that it was PY3/PY2 compatibility issue - not a 
solution/correct way.
Of course simple use of decimal constants like date(2018, 2, 1) is most 
correct.

AK


From akarpierz at gmail.com  Thu May 10 08:05:44 2018
From: akarpierz at gmail.com (AK)
Date: Thu, 10 May 2018 14:05:44 +0200
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <mailman.75.1525953168.28519.python-list@python.org>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <mailman.72.1525949602.28519.python-list@python.org>
 <f1ba8c08-39d0-a81d-a8e8-fa12118533e7@nowhere.net>
 <1009ecf2-fc26-fbfb-c0f7-446e9b204f19@VybeNetworks.com>
 <mailman.75.1525953168.28519.python-list@python.org>
Message-ID: <b028bf9e-5aca-3020-138a-8b2f79ecd5f1@nowhere.net>

On 2018-05-10 13:52, D'Arcy Cain wrote:
> On 2018-05-10 07:39 AM, AK wrote:
>> Try (should work from both PY2 and PY3):
>>
>> d0 = date(2018,0o2,0o1)
> 
> Bad advice.  Those numbers are decimal, not octal,  You should use
> "date(2018,2,1)" here.  Works in PY2, PY3 and for my birthday, Sept 4.

It was only an evidence that it was PY3/PY2 compatibility issue - not a 
solution/correct way.
Of course simple use of decimal constants like date(2018, 2, 1) is most 
correct.

AK


From bc at freeuk.com  Thu May 10 12:36:39 2018
From: bc at freeuk.com (bartc)
Date: Thu, 10 May 2018 17:36:39 +0100
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <mailman.73.1525951709.28519.python-list@python.org>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
Message-ID: <dy_IC.301544$gE6.154866@fx06.am4>

On 10/05/2018 12:28, Skip Montanaro wrote:
>>
>> This gave the following error:
>>
>> Syntax Error: invalid token: C:\Users\Virgil Stokes\Desktop\Important
>> Notes_Files\CheckProcessingDate_02.py, line 7, pos 17
>> d0 = date(2018,02,01)
>>
> 
> Note that this is a Python syntax error. It actually has nothing to do with
> the datetime module. In Python before version 3, leading zeroes were how
> you specified octal (base 8) numbers.

I wonder why someone would take a feature generally agreed to be a 
poorly designed feature of C, and incorporate it into a new language.

Especially one with a very different syntax that doesn't need to be 
backwards compatible.

  That changed in Python 3. If you slim
> the start of PEP 3127, you'll learn the new notation.

What, 0O100 instead of 0100? Yeah that's a big improvement...

Fortunately octal doesn't get used much.

-- 
Bartc


From ganesh1pal at gmail.com  Thu May 10 12:48:39 2018
From: ganesh1pal at gmail.com (Ganesh Pal)
Date: Thu, 10 May 2018 22:18:39 +0530
Subject: Print Failure or success based on the value of the standalone tool
Message-ID: <CACT3xuULQFwpitT=WXzxapv=kVnVVOBemHy94QBDTCCH_zSM4w@mail.gmail.com>

I have to test a standalone tool from a python script and I am using
os.system() to run the tool . I need to take decision based on the return
value of the standalone tool .

But since os.system merely throws the output value to STDOUT  & returns the
exit status (0 => no error) of the shell , how can I make this print Fail
or Pass based on the return value of the standalone tool.

In the below example ( return_values() function)



Example:



# cat standalone_tool.py

#!/usr/bin/env python

# script name: standalone_tool.py

import random

def return_values():

    """ My Demo function"""

    # After Execution the actual tools returns True, False, None as return
types

    x = random.choice([True, False, None])

    print x

    return x

return_values()



>>> ret = os.system('python standalone_tool.py')

True

>>> ret

0



 # vi test_standalone_tool.py

#!/usr/bin/env python

import os

# script name: test_standalone_tool.py



for i in range(2):

    retcode = os.system('python standalone_tool.py')

    print retcode

    if retcode:

        print "The standalone tool returned False. Failure"

    else:

        print "The standalone tool returned True. Successful"



1# python test_standalone_tool.py

None

0

The standalone tool returned True. Successful

True

0

The standalone tool returned True. Successful



The above problem is because we are referring to the exit status of the
shell, Is there an easy way to print Failure or success based on the value
returned by python standalone_tool.py .  I am on Linux with Python 2.7 and
sorry for the longish post


Regards,

Ganesh


From rgaddi at highlandtechnology.invalid  Thu May 10 12:50:00 2018
From: rgaddi at highlandtechnology.invalid (Rob Gaddi)
Date: Thu, 10 May 2018 09:50:00 -0700
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <kMUIC.171380$Vm6.104840@fx45.am4>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org> <pcu1so$qbi$2@blaine.gmane.org>
 <mailman.62.1525844855.28519.python-list@python.org>
 <Q0KIC.79619$jb7.24372@fx34.am4> <87fu309bjw.fsf@elektro.pacujo.net>
 <kMUIC.171380$Vm6.104840@fx45.am4>
Message-ID: <pd1t7q$a89$1@dont-email.me>

On 05/10/2018 03:02 AM, bartc wrote:
> On 10/05/2018 09:09, Marko Rauhamaa wrote:
>> bartc <bc at freeuk.com>:
>>
>> When typing in code (in various languages), I have a habit of typing
>> "..." at places that need to be implemented. For example:
>>
>> ???? if count:
>> ???????? ...
>> ???? else:
>> ???????? do_something_smart()
>> ???????? break
>>
>> the idea being that "..." will surely trigger a syntax error if I forget
>> to address it.
>>
>> I was mildly amused when Python happily executed such code. "..." is a
>> valid expression and thus, a valid statement.
> 
> I wondered what it meant, so I typed in:
> 
>  ?? print (...)
> 
> and it displayed:
> 
>  ?? Ellipsis
> 
> which wasn't very enlightening.
> 

No, but if you ever have difficulty remembering how to spell "ellipsis", 
it's good to know Python comes with a built-in reference.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.


From rgaddi at highlandtechnology.invalid  Thu May 10 12:54:33 2018
From: rgaddi at highlandtechnology.invalid (Rob Gaddi)
Date: Thu, 10 May 2018 09:54:33 -0700
Subject: Print Failure or success based on the value of the standalone tool
In-Reply-To: <mailman.79.1525970923.28519.python-list@python.org>
References: <CACT3xuULQFwpitT=WXzxapv=kVnVVOBemHy94QBDTCCH_zSM4w@mail.gmail.com>
 <mailman.79.1525970923.28519.python-list@python.org>
Message-ID: <pd1tga$a89$2@dont-email.me>

On 05/10/2018 09:48 AM, Ganesh Pal wrote:
> I have to test a standalone tool from a python script and I am using
> os.system() to run the tool . I need to take decision based on the return
> value of the standalone tool .
> 
> But since os.system merely throws the output value to STDOUT  & returns the
> exit status (0 => no error) of the shell , how can I make this print Fail
> or Pass based on the return value of the standalone tool.
> 
> In the below example ( return_values() function)
> 

[snip]

By not using os.system, it's been superseded for reasons exactly like 
yours.  https://docs.python.org/3/library/subprocess.html is your friend.


-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.


From ian.g.kelly at gmail.com  Thu May 10 12:59:36 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Thu, 10 May 2018 10:59:36 -0600
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <8e30c600-2609-cf03-7965-c4e6877aa4ce@VybeNetworks.com>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <8e30c600-2609-cf03-7965-c4e6877aa4ce@VybeNetworks.com>
Message-ID: <CALwzidmb_TsLUg60eWq9TbnjKDf4aBsMMRppec11mNsVSYLHYQ@mail.gmail.com>

On Thu, May 10, 2018 at 5:49 AM, D'Arcy Cain <darcy at vybenetworks.com> wrote:
> On 2018-05-10 07:28 AM, Skip Montanaro wrote:
>> https://www.python.org/dev/peps/pep-3127/#removal-of-old-octal-syntax
>
> Funny stuff:
>
> Python could either:
>
>     1. silently do the wrong thing...
>     2. immediately disabuse him...
>     3. let him continue to think...
>
> Some people passionately believe that (c) is the correct answer
>
> I guess <OL> uses letters in the writer's browser.

That's not even the strongest reason for disallowing leading zeroes
rather than silently changing them to decimal. It should be disallowed
simply because the meaning was previously different.

If I have programs that use 0775 expecting it to be equivalent to
0b111111101, and it suddenly changes to 775 when I upgrade to Python
3, that's going to silently introduce weird bugs into my program,
whereas disallowing it means that I immediately get a SyntaxError and
will know to fix it. It's mystifying to me that the PEP doesn't
discuss this transitional issue at all.


From ian.g.kelly at gmail.com  Thu May 10 13:03:54 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Thu, 10 May 2018 11:03:54 -0600
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <dy_IC.301544$gE6.154866@fx06.am4>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
Message-ID: <CALwzidn6qiie4oz3CmysS6D-AtUoF2h215VJODDUL9L89pygNg@mail.gmail.com>

On Thu, May 10, 2018 at 10:36 AM, bartc <bc at freeuk.com> wrote:
> What, 0O100 instead of 0100? Yeah that's a big improvement...
>
> Fortunately octal doesn't get used much.

The PEP discusses this:

"""
Proposed syntaxes included things like arbitrary radix prefixes, such
as 16r100 (256 in hexadecimal), and radix suffixes, similar to the
100h assembler-style suffix. The debate on whether the letter "O"
could be used for octal was intense -- an uppercase "O" looks
suspiciously similar to a zero in some fonts. Suggestions were made to
use a "c" (the second letter of "oCtal"), or even to use a "t" for
"ocTal" and an "n" for "biNary" to go along with the "x" for
"heXadecimal".

For the string % operator, "o" was already being used to denote octal.
Binary formatting is not being added to the % operator because PEP
3101 (Advanced String Formatting) already supports binary, %
formatting will be deprecated in the future.

At the end of the day, since uppercase "O" can look like a zero and
uppercase "B" can look like an 8, it was decided that these prefixes
should be lowercase only, but, like 'r' for raw string, that can be a
preference or style-guide issue.
"""

Personally I would have preferred the "t".


From python at mrabarnett.plus.com  Thu May 10 13:42:24 2018
From: python at mrabarnett.plus.com (MRAB)
Date: Thu, 10 May 2018 18:42:24 +0100
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <CALwzidn6qiie4oz3CmysS6D-AtUoF2h215VJODDUL9L89pygNg@mail.gmail.com>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CALwzidn6qiie4oz3CmysS6D-AtUoF2h215VJODDUL9L89pygNg@mail.gmail.com>
Message-ID: <3eb69457-4921-b9c0-e5e4-9ad1c82d83d6@mrabarnett.plus.com>

On 2018-05-10 18:03, Ian Kelly wrote:
> On Thu, May 10, 2018 at 10:36 AM, bartc <bc at freeuk.com> wrote:
>> What, 0O100 instead of 0100? Yeah that's a big improvement...
>>
>> Fortunately octal doesn't get used much.
> 
> The PEP discusses this:
> 
> """
> Proposed syntaxes included things like arbitrary radix prefixes, such
> as 16r100 (256 in hexadecimal), and radix suffixes, similar to the
> 100h assembler-style suffix. The debate on whether the letter "O"
> could be used for octal was intense -- an uppercase "O" looks
> suspiciously similar to a zero in some fonts. Suggestions were made to
> use a "c" (the second letter of "oCtal"), or even to use a "t" for
> "ocTal" and an "n" for "biNary" to go along with the "x" for
> "heXadecimal".
> 
> For the string % operator, "o" was already being used to denote octal.
> Binary formatting is not being added to the % operator because PEP
> 3101 (Advanced String Formatting) already supports binary, %
> formatting will be deprecated in the future.
> 
> At the end of the day, since uppercase "O" can look like a zero and
> uppercase "B" can look like an 8, it was decided that these prefixes
> should be lowercase only, but, like 'r' for raw string, that can be a
> preference or style-guide issue.
> """
> 
> Personally I would have preferred the "t".
> 
I've seen Q used instead, although that was years ago. (It might've been 
a suffix, I don't remember exactly.)


From richardchausse at gmail.com  Thu May 10 13:49:43 2018
From: richardchausse at gmail.com (richardchausse at gmail.com)
Date: Thu, 10 May 2018 10:49:43 -0700 (PDT)
Subject: How to use an API (xsd format) in Python?
Message-ID: <4a8f521d-e3a6-44bd-81a0-8f47186dfa8d@googlegroups.com>

I need to get some data from CME Group which provides a public API to download (xsd)
What packages should I use in Python to access this data through this API. Thank you. 


From rosuav at gmail.com  Thu May 10 13:53:47 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 11 May 2018 03:53:47 +1000
Subject: How to use an API (xsd format) in Python?
In-Reply-To: <4a8f521d-e3a6-44bd-81a0-8f47186dfa8d@googlegroups.com>
References: <4a8f521d-e3a6-44bd-81a0-8f47186dfa8d@googlegroups.com>
Message-ID: <CAPTjJmroxxMfcTTg31jqJyQVLTi9uDEKEWio7fovd7NR0mcq2g@mail.gmail.com>

On Fri, May 11, 2018 at 3:49 AM,  <richardchausse at gmail.com> wrote:
> I need to get some data from CME Group which provides a public API to download (xsd)
> What packages should I use in Python to access this data through this API. Thank you.

Depends a lot on the API, and I have no idea what CME Group is doing
(or who that even is); but my first thought would be to grab the
'requests' package. If it's any sort of HTTP download, requests is
usually the best way to do it.

ChrisA


From skip.montanaro at gmail.com  Thu May 10 13:58:16 2018
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Thu, 10 May 2018 17:58:16 +0000
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <dy_IC.301544$gE6.154866@fx06.am4>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
Message-ID: <CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>

> I wonder why someone would take a feature generally agreed to be a
> poorly designed feature of C, and incorporate it into a new language.

I think you might be looking at a decision made in the late 1980s through a
pair of glasses made in 2018.

As a C programmer back then I never had a problem with C's octal number
notation. People coming from C, C++ or Java to Python at that time would
certainly have understood that syntax. It's only in the past 15 years or so
that we've seen tons of people coming to Python as a first language for
whom leading zero notation would be unfamiliar.

Skip


From richardchausse at gmail.com  Thu May 10 14:10:56 2018
From: richardchausse at gmail.com (richardchausse at gmail.com)
Date: Thu, 10 May 2018 11:10:56 -0700 (PDT)
Subject: How to use an API (xsd format) in Python?
In-Reply-To: <mailman.83.1525974836.28519.python-list@python.org>
References: <4a8f521d-e3a6-44bd-81a0-8f47186dfa8d@googlegroups.com>
 <CAPTjJmroxxMfcTTg31jqJyQVLTi9uDEKEWio7fovd7NR0mcq2g@mail.gmail.com>
 <mailman.83.1525974836.28519.python-list@python.org>
Message-ID: <95da3d1e-bd19-440b-acf5-c959b070728a@googlegroups.com>

On Thursday, May 10, 2018 at 1:54:11 PM UTC-4, Chris Angelico wrote:

> > I need to get some data from CME Group which provides a public API to download (xsd)
> > What packages should I use in Python to access this data through this API. Thank you.
> 
> Depends a lot on the API, and I have no idea what CME Group is doing
> (or who that even is); but my first thought would be to grab the
> 'requests' package. If it's any sort of HTTP download, requests is
> usually the best way to do it.
> 
> ChrisA

They provide Margin Requirements numbers attached to each future contract. The XSD file provide the XML Schema. I'm not sure what to do with that xsd.

https://www.cmegroup.com/confluence/display/EPICSANDBOX/Margin+Service+API+-+Requests


From charmingoldgit at gmail.com  Thu May 10 14:12:29 2018
From: charmingoldgit at gmail.com (charmingoldgit at gmail.com)
Date: Thu, 10 May 2018 11:12:29 -0700 (PDT)
Subject: Is this a bug or a feature in TkInter?
Message-ID: <c389e020-d33e-4dc5-8a2a-491f3e0955b0@googlegroups.com>

I'm learning to use TkInter in Python and came across this example program from 'Thinking in TkInter' (http://thinkingtkinter.sourceforge.net) - see below.

Two buttons 'button1' and 'button2' are defined. The bug is that event.widget returns '.!frame.!button' from a button1 event. i.e. it somehow drops the '1' from the widget name. Events on button2 are correctly reported.

Is this a bug or a feature?

<code>
from tkinter import *

class MyApp:
	def __init__(self, parent):
		self.myParent = parent   
		self.myContainer1 = Frame(parent)
		self.myContainer1.pack()
		
		button_name = "OK"
		self.button1 = Button(self.myContainer1,
			command=self.buttonHandler(button_name, 1, "Good stuff!"))
			
		# self.button1.bind("<Return>", self.buttonHandler_a(event, button_name, 1, "Good stuff!"))
		self.button1.configure(text=button_name, background="green")  
		self.button1.pack(side=LEFT)
		self.button1.focus_force()  # Put keyboard focus on button1    
		
		button_name = "Cancel"
		self.button2 = Button(self.myContainer1, 
			command=self.buttonHandler(button_name, 2, "Bad  stuff!")) 
			 
		# self.button2.bind("<Return>", self.buttonHandler_a(event, button_name, 2, "Bad  stuff!"))    
		self.button2.configure(text=button_name, background="red")
		self.button2.pack(side=LEFT)   
				
		
	def buttonHandler(self, arg1, arg2, arg3):   
		print("    buttonHandler routine received arguments:", arg1.ljust(8), arg2, arg3)
		
 	def buttonHandler_a(self, event, arg1, arg2, arg3):
		print("buttonHandler_a received event", event)
		self.buttonHandler(arg1, arg2, arg3)
		
print("\n"*100) # clear the screen
print("Starting program tt077.")
root = Tk()
myapp = MyApp(root)
print("Ready to start executing the event loop.")
root.mainloop()
print("Finished       executing the event loop.")
</code>


From breamoreboy at gmail.com  Thu May 10 14:21:21 2018
From: breamoreboy at gmail.com (Mark Lawrence)
Date: Thu, 10 May 2018 19:21:21 +0100
Subject: How to use an API (xsd format) in Python?
In-Reply-To: <95da3d1e-bd19-440b-acf5-c959b070728a@googlegroups.com>
References: <4a8f521d-e3a6-44bd-81a0-8f47186dfa8d@googlegroups.com>
 <CAPTjJmroxxMfcTTg31jqJyQVLTi9uDEKEWio7fovd7NR0mcq2g@mail.gmail.com>
 <mailman.83.1525974836.28519.python-list@python.org>
 <95da3d1e-bd19-440b-acf5-c959b070728a@googlegroups.com>
Message-ID: <pd22et$n84$1@blaine.gmane.org>

On 10/05/18 19:10, richardchausse at gmail.com wrote:
> On Thursday, May 10, 2018 at 1:54:11 PM UTC-4, Chris Angelico wrote:
> 
>>> I need to get some data from CME Group which provides a public API to download (xsd)
>>> What packages should I use in Python to access this data through this API. Thank you.
>>
>> Depends a lot on the API, and I have no idea what CME Group is doing
>> (or who that even is); but my first thought would be to grab the
>> 'requests' package. If it's any sort of HTTP download, requests is
>> usually the best way to do it.
>>
>> ChrisA
> 
> They provide Margin Requirements numbers attached to each future contract. The XSD file provide the XML Schema. I'm not sure what to do with that xsd.
> 
> https://www.cmegroup.com/confluence/display/EPICSANDBOX/Margin+Service+API+-+Requests
> 

Is this http://www.davekuhlman.org/generateDS.html of any use to you?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence



From bc at freeuk.com  Thu May 10 14:31:29 2018
From: bc at freeuk.com (bartc)
Date: Thu, 10 May 2018 19:31:29 +0100
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <mailman.81.1525971876.28519.python-list@python.org>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CALwzidn6qiie4oz3CmysS6D-AtUoF2h215VJODDUL9L89pygNg@mail.gmail.com>
 <mailman.81.1525971876.28519.python-list@python.org>
Message-ID: <Td0JC.111049$Vs7.22268@fx41.am4>

On 10/05/2018 18:03, Ian Kelly wrote:
> On Thu, May 10, 2018 at 10:36 AM, bartc <bc at freeuk.com> wrote:
>> What, 0O100 instead of 0100? Yeah that's a big improvement...
>>
>> Fortunately octal doesn't get used much.
> 
> The PEP discusses this:
> 
> """
> Proposed syntaxes included things like arbitrary radix prefixes, such
> as 16r100 (256 in hexadecimal), and radix suffixes, similar to the
> 100h assembler-style suffix. The debate on whether the letter "O"
> could be used for octal was intense -- an uppercase "O" looks
> suspiciously similar to a zero in some fonts. Suggestions were made to
> use a "c" (the second letter of "oCtal"), or even to use a "t" for
> "ocTal" and an "n" for "biNary" to go along with the "x" for
> "heXadecimal".
> 
> For the string % operator, "o" was already being used to denote octal.
> Binary formatting is not being added to the % operator because PEP
> 3101 (Advanced String Formatting) already supports binary, %
> formatting will be deprecated in the future.
> 
> At the end of the day, since uppercase "O" can look like a zero and
> uppercase "B" can look like an 8, it was decided that these prefixes
> should be lowercase only, but, like 'r' for raw string, that can be a
> preference or style-guide issue.
> """
> 
> Personally I would have preferred the "t".
> 

	
In my own [syntax] designs, for a long time I used:

   100H   (256) Hex
   100B   (4)   Binary

in addition to decimal. Then I when I switched to 0x for hex (so that I 
could write 0xABC instead of needing to write 0ABCH with a leading 
zero), it was easy to extend that scheme:

   2x100  (4)   Binary
   3x100  (9)   Ternary
   4x100  (16)  Quaternary
   5x100  (25)  etc
   6x100  (36)
   7x100  (49)
   8x100  (64)  Octal
   9x100  (81)
   ...           (Not implemented 11x to 15x, nor 10x or 16x)
   0x100  (256) Hex

I think Ada does something similar for example 2#100#.

However I wouldn't be bothered at having to use for example OCT(377), 
HEX(FF), BIN(1111_1111) or even OCTAL(377), although it's a bit clunky. 
At least it will be obvious; more so than 0o100.

-- 
bartc


From mikhailwas at gmail.com  Thu May 10 14:41:23 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Thu, 10 May 2018 21:41:23 +0300
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
Message-ID: <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>

On Wed, May 9, 2018 at 8:50 AM, Chris Angelico <rosuav at gmail.com> wrote:
> On Wed, May 9, 2018 at 3:36 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
>>
>> while True:
>>     if we_are_done():
>>         break
>>     # do some stuff
>>     ...
>>     if error_occurred():
>>         break
>> notify_user()
>>
>>
>> Fixed, using idiomatic Python and without needing to use assignment in
>> an expression.
>
> Why is it that "while True" is idiomatic Python for a non-infinite
> loop? Is it merely because Python currently has no other way to spell
> certain loops? Surely it would be more idiomatic to encode the loop's
> termination condition in the header, if it were possible.

Don't know about 'idiomatic', but the above spelling is exactly what i
tend to use lately for almost all loops. It noticeably reduces cognitive load.
Though lately more often i prefer "while 1:" so it makes
the nodes more lightweight and distinct from the rest lines.
And not even official declaration of "idiomatic" as something else will
make me switch back.


From rosuav at gmail.com  Thu May 10 14:51:34 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 11 May 2018 04:51:34 +1000
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <Td0JC.111049$Vs7.22268@fx41.am4>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CALwzidn6qiie4oz3CmysS6D-AtUoF2h215VJODDUL9L89pygNg@mail.gmail.com>
 <mailman.81.1525971876.28519.python-list@python.org>
 <Td0JC.111049$Vs7.22268@fx41.am4>
Message-ID: <CAPTjJmqwODUPKnHu5k8qwUU6N7R2XR9aAE1m6-D5GCgYZcsNOg@mail.gmail.com>

On Fri, May 11, 2018 at 4:31 AM, bartc <bc at freeuk.com> wrote:
>   2x100  (4)   Binary
>   3x100  (9)   Ternary
>   4x100  (16)  Quaternary
>   5x100  (25)  etc
>   6x100  (36)
>   7x100  (49)
>   8x100  (64)  Octal
>   9x100  (81)
>   ...           (Not implemented 11x to 15x, nor 10x or 16x)
>   0x100  (256) Hex

YAGNI much? How often do you need a base-9 literal in your code??

ChrisA


From jon+usenet at unequivocal.eu  Thu May 10 15:04:58 2018
From: jon+usenet at unequivocal.eu (Jon Ribbens)
Date: Thu, 10 May 2018 19:04:58 -0000 (UTC)
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>
 <mailman.84.1525976408.28519.python-list@python.org>
Message-ID: <slrnpf95uq.258.jon+usenet@sable.unequivocal.eu>

On 2018-05-10, Skip Montanaro <skip.montanaro at gmail.com> wrote:
>> I wonder why someone would take a feature generally agreed to be a
>> poorly designed feature of C, and incorporate it into a new language.
>
> I think you might be looking at a decision made in the late 1980s through a
> pair of glasses made in 2018.
>
> As a C programmer back then I never had a problem with C's octal number
> notation. People coming from C, C++ or Java to Python at that time would
> certainly have understood that syntax. It's only in the past 15 years or so
> that we've seen tons of people coming to Python as a first language for
> whom leading zero notation would be unfamiliar.

This whole thread is reminding me PHP 2, which would magically treat
the second parameter of ChMod() as octal, because clearly if weak
typing is good then *no* typing must be best of all!

  ChMod($filename, 644); // second parameter is actually 420 base 10



From skip.montanaro at gmail.com  Thu May 10 15:11:06 2018
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Thu, 10 May 2018 19:11:06 +0000
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <slrnpf95uq.258.jon+usenet@sable.unequivocal.eu>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>
 <mailman.84.1525976408.28519.python-list@python.org>
 <slrnpf95uq.258.jon+usenet@sable.unequivocal.eu>
Message-ID: <CANc-5Uw3+Vh1Vora15cuW22TtmrWrBF=3Quvzpax5i1464f+1w@mail.gmail.com>

> This whole thread is reminding me PHP 2, which would magically treat
> the second parameter of ChMod() as octal, because clearly if weak
> typing is good then *no* typing must be best of all!

>    ChMod($filename, 644); // second parameter is actually 420 base 10

I knew there was a reason I never used PHP...

Skip


From rosuav at gmail.com  Thu May 10 15:11:44 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 11 May 2018 05:11:44 +1000
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <slrnpf95uq.258.jon+usenet@sable.unequivocal.eu>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>
 <mailman.84.1525976408.28519.python-list@python.org>
 <slrnpf95uq.258.jon+usenet@sable.unequivocal.eu>
Message-ID: <CAPTjJmqcma9bQ9FeXJx+-XJ8e6PtKN69hwte-r0UBydygWPn6g@mail.gmail.com>

On Fri, May 11, 2018 at 5:04 AM, Jon Ribbens <jon+usenet at unequivocal.eu> wrote:
> On 2018-05-10, Skip Montanaro <skip.montanaro at gmail.com> wrote:
>>> I wonder why someone would take a feature generally agreed to be a
>>> poorly designed feature of C, and incorporate it into a new language.
>>
>> I think you might be looking at a decision made in the late 1980s through a
>> pair of glasses made in 2018.
>>
>> As a C programmer back then I never had a problem with C's octal number
>> notation. People coming from C, C++ or Java to Python at that time would
>> certainly have understood that syntax. It's only in the past 15 years or so
>> that we've seen tons of people coming to Python as a first language for
>> whom leading zero notation would be unfamiliar.
>
> This whole thread is reminding me PHP 2, which would magically treat
> the second parameter of ChMod() as octal, because clearly if weak
> typing is good then *no* typing must be best of all!
>
>   ChMod($filename, 644); // second parameter is actually 420 base 10

Bear in mind that Unix file modes are traditionally written in octal,
because they have no meaning as numbers. They're more like
enumerations, or bitfields. The second parameter happens to be equal
to the base 10 number 420, but that's completely useless. A file mode
of 100644 means something; a file mode of 0x81a4 or 33188 decimal
means nothing. PHP went for crazy magic there, but if the API had been
built such that the "644" is passed as a string, it would have been
completely sane and entirely useful.

ChrisA


From tjreedy at udel.edu  Thu May 10 15:23:32 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 10 May 2018 15:23:32 -0400
Subject: Is this a bug or a feature in TkInter?
In-Reply-To: <c389e020-d33e-4dc5-8a2a-491f3e0955b0@googlegroups.com>
References: <c389e020-d33e-4dc5-8a2a-491f3e0955b0@googlegroups.com>
Message-ID: <pd263h$uu0$1@blaine.gmane.org>

On 5/10/2018 2:12 PM, charmingoldgit at gmail.com wrote:
> I'm learning to use TkInter in Python and came across this example program from 'Thinking in TkInter' (http://thinkingtkinter.sourceforge.net) - see below.
> 
> Two buttons 'button1' and 'button2' are defined. The bug is that event.widget returns '.!frame.!button' from a button1 event.

The internal pathname of a widget is generated by tkinter for 
interaction with tk.  '.' is the name given to the root Tk widget. 
Before a couple of years ago, children were given random 8(I 
believe)-digit names.  So you might have seen something like 
.88023535.29038503.  Now, the path component for a widget is '!' + 
widgetName (+ number suffix if needed).  A number suffix is only needed 
to avoid duplication after the first widget of a given class for a 
particular parent.

  i.e. it somehow drops the '1' from the widget name.

There never was a '1' to be dropped.


  Events on button2 are correctly reported.
> 
> Is this a bug or a feature?
> 
> <code>
> from tkinter import *
> 
> class MyApp:
> 	def __init__(self, parent):
> 		self.myParent = parent
> 		self.myContainer1 = Frame(parent)
> 		self.myContainer1.pack()
> 		
> 		button_name = "OK"
> 		self.button1 = Button(self.myContainer1,
> 			command=self.buttonHandler(button_name, 1, "Good stuff!"))

This calls self.buttonHandler and binds the return value, None, to 
command.  Functions bound to 'command' must not require arguments.  Add 
'lambda:' before 'self' and the above will work.  Nothing is printed 
until you click the button and the printing is repeated each time you click.

> 			
> 		# self.button1.bind("<Return>", self.buttonHandler_a(event, button_name, 1, "Good stuff!"))

Functions bound to events must take one argument, the event.  Add 
'lambda event:' before 'self' and the above works when the focus is on 
button1 and you hit return.

Repeat both fixes for button 2.

> 		self.button1.configure(text=button_name, background="green")
> 		self.button1.pack(side=LEFT)
> 		self.button1.focus_force()  # Put keyboard focus on button1
> 		
> 		button_name = "Cancel"
> 		self.button2 = Button(self.myContainer1,
> 			command=self.buttonHandler(button_name, 2, "Bad  stuff!"))
> 			
> 		# self.button2.bind("<Return>", self.buttonHandler_a(event, button_name, 2, "Bad  stuff!"))
> 		self.button2.configure(text=button_name, background="red")
> 		self.button2.pack(side=LEFT)
> 				
> 		
> 	def buttonHandler(self, arg1, arg2, arg3):
> 		print("    buttonHandler routine received arguments:", arg1.ljust(8), arg2, arg3)
> 		
>   	def buttonHandler_a(self, event, arg1, arg2, arg3):
> 		print("buttonHandler_a received event", event)
> 		self.buttonHandler(arg1, arg2, arg3)
> 		
> print("\n"*100) # clear the screen
> print("Starting program tt077.")
> root = Tk()
> myapp = MyApp(root)
> print("Ready to start executing the event loop.")
> root.mainloop()
> print("Finished       executing the event loop.")
> </code>



-- 
Terry Jan Reedy



From grant.b.edwards at gmail.com  Thu May 10 15:32:24 2018
From: grant.b.edwards at gmail.com (Grant Edwards)
Date: Thu, 10 May 2018 19:32:24 +0000 (UTC)
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>
 <mailman.84.1525976408.28519.python-list@python.org>
 <slrnpf95uq.258.jon+usenet@sable.unequivocal.eu>
Message-ID: <pd26o7$d2$1@blaine.gmane.org>

On 2018-05-10, Jon Ribbens <jon+usenet at unequivocal.eu> wrote:

> This whole thread is reminding me PHP 2, which would magically treat
> the second parameter of ChMod() as octal, because clearly if weak
> typing is good then *no* typing must be best of all!
>
>   ChMod($filename, 644); // second parameter is actually 420 base 10

Aaargh.  That's awful.

I didn't think it was possible for my opinion of PHP to get any lower.

I was wrong.

-- 
Grant Edwards               grant.b.edwards        Yow! I wonder if I could
                                  at               ever get started in the
                              gmail.com            credit world?



From marko at pacujo.net  Thu May 10 15:59:03 2018
From: marko at pacujo.net (Marko Rauhamaa)
Date: Thu, 10 May 2018 22:59:03 +0300
Subject: seeking deeper (language theory) reason behind Python design
 choice
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
Message-ID: <871sej9ta0.fsf@elektro.pacujo.net>

Mikhail V <mikhailwas at gmail.com>:

> On Wed, May 9, 2018 at 8:50 AM, Chris Angelico <rosuav at gmail.com> wrote:
>> On Wed, May 9, 2018 at 3:36 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
>>> while True:
>>
>> Why is it that "while True" is idiomatic Python for a non-infinite
>> loop? Is it merely because Python currently has no other way to spell
>> certain loops? Surely it would be more idiomatic to encode the loop's
>> termination condition in the header, if it were possible.
>
> Don't know about 'idiomatic', but the above spelling is exactly what i
> tend to use lately for almost all loops. It noticeably reduces
> cognitive load. Though lately more often i prefer "while 1:" so it
> makes the nodes more lightweight and distinct from the rest lines. And
> not even official declaration of "idiomatic" as something else will
> make me switch back.

How about:

   while ...:
       do_stuff()
       if done:
           break
       do_more_stuff()

where ... is the Ellipsis.

Joking aside, to answer Chris's question, of course you can use a real
condition with "while". However, you shouldn't force it or try to avoid
"while True". It turns out "while True" is the most natural choice in
about half of the while loops.


Marko


From rosuav at gmail.com  Thu May 10 16:07:32 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 11 May 2018 06:07:32 +1000
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <871sej9ta0.fsf@elektro.pacujo.net>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net>
Message-ID: <CAPTjJmqMpUUzKJmomk3Ypms3_k8Cp0eOrDmNEKigQLQfjyzGdQ@mail.gmail.com>

On Fri, May 11, 2018 at 5:59 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
> Mikhail V <mikhailwas at gmail.com>:
>
>> On Wed, May 9, 2018 at 8:50 AM, Chris Angelico <rosuav at gmail.com> wrote:
>>> On Wed, May 9, 2018 at 3:36 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
>>>> while True:
>>>
>>> Why is it that "while True" is idiomatic Python for a non-infinite
>>> loop? Is it merely because Python currently has no other way to spell
>>> certain loops? Surely it would be more idiomatic to encode the loop's
>>> termination condition in the header, if it were possible.
>>
>> Don't know about 'idiomatic', but the above spelling is exactly what i
>> tend to use lately for almost all loops. It noticeably reduces
>> cognitive load. Though lately more often i prefer "while 1:" so it
>> makes the nodes more lightweight and distinct from the rest lines. And
>> not even official declaration of "idiomatic" as something else will
>> make me switch back.
>
> How about:
>
>    while ...:
>        do_stuff()
>        if done:
>            break
>        do_more_stuff()
>
> where ... is the Ellipsis.
>
> Joking aside, to answer Chris's question, of course you can use a real
> condition with "while". However, you shouldn't force it or try to avoid
> "while True". It turns out "while True" is the most natural choice in
> about half of the while loops.

So if I understand you correctly, you're saying that a real condition
is better, but "while True" is the best option half the time. In other
words, "while True" is the ONLY option half the time, since any other
option would be better.

My point is that creating a way to write more conditions as actual
loop headers is an improvement in Pythonicity, not a worsening of it.
It is not fundamentally Pythonic to write a non-infinite loop as
"while True"; that is a limitation caused by the inability to
represent certain conditions in any better way.

It is NOT idiomatic to use "while True" and then write your condition
just inside the loop.

ChrisA


From skip.montanaro at gmail.com  Thu May 10 16:13:24 2018
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Thu, 10 May 2018 20:13:24 +0000
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <CAPTjJmqcma9bQ9FeXJx+-XJ8e6PtKN69hwte-r0UBydygWPn6g@mail.gmail.com>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>
 <mailman.84.1525976408.28519.python-list@python.org>
 <slrnpf95uq.258.jon+usenet@sable.unequivocal.eu>
 <CAPTjJmqcma9bQ9FeXJx+-XJ8e6PtKN69hwte-r0UBydygWPn6g@mail.gmail.com>
Message-ID: <CANc-5UyD=9Kvt55an5yS2OP_4Y03W82B9dNJYqTjfnDQbJhTQw@mail.gmail.com>

> Bear in mind that Unix file modes are traditionally written in octal,
> because they have no meaning as numbers. They're more like
> enumerations, or bitfields.

The current chmod(2) man page says that the type of the second is mode_t,
but back in the early days, it appears it was just declared to be int.
Here's 2.11BSD dated 1986:

https://www.freebsd.org/cgi/man.cgi?query=chmod&sektion=2&apropos=0&manpath=2.11+BSD

By 1991, 4.3BSD declared the second arg to be mode_t:

https://www.freebsd.org/cgi/man.cgi?query=chmod&sektion=2&apropos=0&manpath=4.3BSD+NET%2f2

(I find it odd that the above service doesn't include 4.2BSD man pages, but
I digress.)

Octal notation matched up better with the sizes of the individual groups.
Hex and base 10 are worthless for this, as their boundaries don't line up
with the number of bits used in each group. Binary consumes too much space
and no "chunkiness." Octal was "just right."

Skip


From bc at freeuk.com  Thu May 10 16:18:37 2018
From: bc at freeuk.com (bartc)
Date: Thu, 10 May 2018 21:18:37 +0100
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <mailman.87.1525978297.28519.python-list@python.org>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CALwzidn6qiie4oz3CmysS6D-AtUoF2h215VJODDUL9L89pygNg@mail.gmail.com>
 <mailman.81.1525971876.28519.python-list@python.org>
 <Td0JC.111049$Vs7.22268@fx41.am4>
 <CAPTjJmqwODUPKnHu5k8qwUU6N7R2XR9aAE1m6-D5GCgYZcsNOg@mail.gmail.com>
 <mailman.87.1525978297.28519.python-list@python.org>
Message-ID: <kO1JC.224737$Cd3.58445@fx33.am4>

On 10/05/2018 19:51, Chris Angelico wrote:
> On Fri, May 11, 2018 at 4:31 AM, bartc <bc at freeuk.com> wrote:
>>    2x100  (4)   Binary
>>    3x100  (9)   Ternary
>>    4x100  (16)  Quaternary
>>    5x100  (25)  etc
>>    6x100  (36)
>>    7x100  (49)
>>    8x100  (64)  Octal
>>    9x100  (81)
>>    ...           (Not implemented 11x to 15x, nor 10x or 16x)
>>    0x100  (256) Hex
> 
> YAGNI much? How often do you need a base-9 literal in your code??

I've used base-4 a couple of times, but not base 9 yet, excepting when 
toying with stuff. But you need to be able to print numbers in those 
bases too [not Python, or C]:

     a := 3x2222222222           # base-3
     println a:"x9"              # displays 8888 in base-9

It's interesting to see the patterns that arise when doing arithmetic in 
mixed bases.

Anyway, those extra bases were easier to leave in than to exclude.

-- 
bartc


From pkpearson at nowhere.invalid  Thu May 10 16:56:50 2018
From: pkpearson at nowhere.invalid (Peter Pearson)
Date: 10 May 2018 20:56:50 GMT
Subject: seeking deeper (language theory) reason behind Python design
 choice
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <7s86fd1bncg5hovboehvvqe57budhc2bf8@4ax.com>
 <mailman.69.1525884392.28519.python-list@python.org>
 <87po24zjyk.fsf@nightsong.com>
Message-ID: <fljq0iFoejkU1@mid.individual.net>

On Wed, 09 May 2018 12:51:15 -0700, Paul Rubin wrote:
> Dennis Lee Bieber <wlfraed at ix.netcom.com> writes:
>> 	Yes, code reviews may catch such errors... and later, when the
>> summary of errors is analyzed for suggestions on how to reduce them --
>> the odds are good that "assignment expressions" will be banned in the
>> style documents for that language at the company.
>
> I don't think I've worked on any C programs with that style restriction
> and I can't think of any times when I found that type of bug in deployed
> code.  I've made the error once or twice while coding, but caught it
> right away during inspection or testing.  Banning it seems
> counterproductive.  I could imagine having it flagged by a compiler
> warning that can be locally disabled by a pragma.  

Interestingly, the problem is broader than inadvertently making the
mistake yourself; it includes catching deliberate misdirection by
others.  In the famous "Linux Backdoor Attempt of 2003"
(https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-attempt-of-2003/),
somebody who I think never got caught introduced these lines
into the code for the wait4 function:

    if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
            retval = -EINVAL;

Setting the user ID to zero confers root privileges.

- Peter


From bc at freeuk.com  Thu May 10 18:43:25 2018
From: bc at freeuk.com (bartc)
Date: Thu, 10 May 2018 23:43:25 +0100
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <mailman.84.1525976408.28519.python-list@python.org>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>
 <mailman.84.1525976408.28519.python-list@python.org>
Message-ID: <2W3JC.64439$7b4.11219@fx12.am4>

On 10/05/2018 18:58, Skip Montanaro wrote:
>> I wonder why someone would take a feature generally agreed to be a
>> poorly designed feature of C, and incorporate it into a new language.
> 
> I think you might be looking at a decision made in the late 1980s through a
> pair of glasses made in 2018.
> 
> As a C programmer back then I never had a problem with C's octal number
> notation. People coming from C, C++ or Java to Python at that time would
> certainly have understood that syntax. It's only in the past 15 years or so
> that we've seen tons of people coming to Python as a first language for
> whom leading zero notation would be unfamiliar.

I'm pretty sure I would have had exactly the same opinion in 1989.

Decimal numbers in code should reflect their usage in everyday life as 
much as possible.

And in everyday life, leading zeros do not change the base of a number 
so that it becomes octal. If my car odometer says 075300, it means I've 
done 75,300 miles or km, not 31424:

    mileages = (         # python 2
         215820,
         121090,
         075300,
         005105)

    for m in mileages:
         print m,"miles"

Output:

    215820 miles
    121090 miles
    31424 miles
    2629 miles

This is Wrong, and would have been just as obviously wrong in 1989.

-- 
bartc


From marko at pacujo.net  Thu May 10 18:49:48 2018
From: marko at pacujo.net (Marko Rauhamaa)
Date: Fri, 11 May 2018 01:49:48 +0300
Subject: seeking deeper (language theory) reason behind Python design
 choice
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net>
 <CAPTjJmqMpUUzKJmomk3Ypms3_k8Cp0eOrDmNEKigQLQfjyzGdQ@mail.gmail.com>
 <mailman.92.1525982855.28519.python-list@python.org>
Message-ID: <87wowb86sz.fsf@elektro.pacujo.net>

Chris Angelico <rosuav at gmail.com>:
> On Fri, May 11, 2018 at 5:59 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
>> Joking aside, to answer Chris's question, of course you can use a
>> real condition with "while". However, you shouldn't force it or try
>> to avoid "while True". It turns out "while True" is the most natural
>> choice in about half of the while loops.
>
> So if I understand you correctly, you're saying that a real condition
> is better, but "while True" is the best option half the time. In other
> words, "while True" is the ONLY option half the time, since any other
> option would be better.

A real example:

    def split_cmd(self, cmd):
        args = []
        while True:
            match = self.TERM_PTN.match(cmd)
            if match is None:
                return None, None
            args.append(match.group('term'))
            if not match.group('sep'):
                break
            cmd = cmd[match.end(0):]
        verb = args.pop(0).upper()
        return verb, args

You *could* get rid of True. For example:

    def split_cmd(self, cmd):
        args = []
        match = self.TERM_PTN.match(cmd)
        while match is not None:
            args.append(match.group('term'))
            if not match.group('sep'):
                verb = args.pop(0).upper()
                return verb, args
            cmd = cmd[match.end(0):]
            match = self.TERM_PTN.match(cmd)
        return None, None

However, that would be a slight stylistic degradation because

 1. the redundant matching statement is redundant and

 2. an abnormal return is at the bottom of the function.


Marko


From marko at pacujo.net  Thu May 10 18:51:47 2018
From: marko at pacujo.net (Marko Rauhamaa)
Date: Fri, 11 May 2018 01:51:47 +0300
Subject: seeking deeper (language theory) reason behind Python design
 choice
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net> <87fu2z1dkp.fsf@nightsong.com>
Message-ID: <87sh6z86po.fsf@elektro.pacujo.net>

Paul Rubin <no.email at nospam.invalid>:

> Marko Rauhamaa <marko at pacujo.net> writes:
>> It turns out "while True" is the most natural choice in about half of
>> the while loops.
>
> Maybe the rest would be "repeat until" if Python had that?

No. "Repeat until" is a relatively infrequent need.


Marko


From rosuav at gmail.com  Thu May 10 20:11:33 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 11 May 2018 10:11:33 +1000
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <2W3JC.64439$7b4.11219@fx12.am4>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>
 <mailman.84.1525976408.28519.python-list@python.org>
 <2W3JC.64439$7b4.11219@fx12.am4>
Message-ID: <CAPTjJmr+t3ivSpTqiGmD3DBJo8dba+5sriMffYRsdfVC+yRpSg@mail.gmail.com>

On Fri, May 11, 2018 at 8:43 AM, bartc <bc at freeuk.com> wrote:
> This is Wrong, and would have been just as obviously wrong in 1989.

Having spent many years programming in C and working on Unix, I
strongly disagree. This was *not* obviously wrong. It's easy to say
"but look at the real world"; but in the 80s and 90s, nobody would
have said that it was "obviously wrong" to have the native integer
wrap when it goes past a certain number of bits. And in fact, your
description of the real world makes it equally obvious that numbers
should have a fixed width:

> If my car odometer says 075300, it means I've done 75,300 miles or km, not 31424

You might actually have done 1,075,300 ticks, or 2,075,300, or any
other number that ends with those six digits. That's OBVIOUSLY right,
because you can look at your odometer or a pocket calculator and see
that numbers don't need to have infinite precision.

Octal makes a lot of sense in the right contexts. Allowing octal
literals is a Good Thing. And sticking letters into the middle of a
number doesn't make that much sense, so the leading-zero notation is a
decent choice. It's all very well to argue that it's a suboptimal
choice; but you have to remember that you're arguing that point from
2018, and we have about thirty years of experience using Python. The
choice was most definitely not fundamentally wrong. Ten years ago, the
point was revisited, and a different choice made. That's all.

ChrisA


From rosuav at gmail.com  Thu May 10 20:21:38 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 11 May 2018 10:21:38 +1000
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <87wowb86sz.fsf@elektro.pacujo.net>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net>
 <CAPTjJmqMpUUzKJmomk3Ypms3_k8Cp0eOrDmNEKigQLQfjyzGdQ@mail.gmail.com>
 <mailman.92.1525982855.28519.python-list@python.org>
 <87wowb86sz.fsf@elektro.pacujo.net>
Message-ID: <CAPTjJmpf+HCK-k8St_HK01FYFYac5xUZBB0vq6rLOpJWRrHzHw@mail.gmail.com>

On Fri, May 11, 2018 at 8:49 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
>     def split_cmd(self, cmd):
>         args = []
>         while True:
>             match = self.TERM_PTN.match(cmd)
>             if match is None:
>                 return None, None
>             args.append(match.group('term'))
>             if not match.group('sep'):
>                 break
>             cmd = cmd[match.end(0):]
>         verb = args.pop(0).upper()
>         return verb, args
>
> You *could* get rid of True. For example:

Yes, you could. For a start, you'd want to add a docstring so someone
else can figure out what on earth is going on here. For instance, I
don't understand why, even after iterating several times, a regex
match failure instantly results in you returning (None, None); is that
an error condition? If so, why is it not raising an exception? What
kind of regex is this (at least, it looks like you're doing regex
work), and can you use re.split() instead of all this? Why are you
uppercasing the verb? Why an ALL_CAPS name (usually a constant) being
referenced from an object (self)? So much of this doesn't look even
slightly Pythonic.

But for the loop itself, you absolutely CAN write this more logically.
I'll take your second version as a template:

    def split_cmd(self, cmd):
        args = []
        while (match := self.TERM_PTN.match(cmd)) is not None:
            args.append(match.group('term'))
            if not match.group('sep'):
                verb = args.pop(0).upper()
                return verb, args
            cmd = cmd[match.end(0):]
        return None, None

And, if this is actually a regex, "is not None" is unnecessary:

while match := self.TERM_PTN.match(cmd):

Now do you understand what I mean about putting the condition into the
loop header?

ChrisA


From marko at pacujo.net  Thu May 10 20:25:02 2018
From: marko at pacujo.net (Marko Rauhamaa)
Date: Fri, 11 May 2018 03:25:02 +0300
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>
 <mailman.84.1525976408.28519.python-list@python.org>
 <2W3JC.64439$7b4.11219@fx12.am4>
 <CAPTjJmr+t3ivSpTqiGmD3DBJo8dba+5sriMffYRsdfVC+yRpSg@mail.gmail.com>
 <mailman.94.1525997497.28519.python-list@python.org>
Message-ID: <87o9hn82e9.fsf@elektro.pacujo.net>

Chris Angelico <rosuav at gmail.com>:

> Octal makes a lot of sense in the right contexts.

I think octal is a historical relic from a time when people weren't yet
comfortable with hexadecimal.

> Allowing octal literals is a Good Thing.

I think it's just unavoidable mainly because of os.chmod.


Marko


From marko at pacujo.net  Thu May 10 20:29:57 2018
From: marko at pacujo.net (Marko Rauhamaa)
Date: Fri, 11 May 2018 03:29:57 +0300
Subject: seeking deeper (language theory) reason behind Python design
 choice
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net>
 <CAPTjJmqMpUUzKJmomk3Ypms3_k8Cp0eOrDmNEKigQLQfjyzGdQ@mail.gmail.com>
 <mailman.92.1525982855.28519.python-list@python.org>
 <87wowb86sz.fsf@elektro.pacujo.net>
 <CAPTjJmpf+HCK-k8St_HK01FYFYac5xUZBB0vq6rLOpJWRrHzHw@mail.gmail.com>
 <mailman.95.1525998102.28519.python-list@python.org>
Message-ID: <87k1sb8262.fsf@elektro.pacujo.net>

Chris Angelico <rosuav at gmail.com>:

> But for the loop itself, you absolutely CAN write this more logically.
> I'll take your second version as a template:
>
>     def split_cmd(self, cmd):
>         args = []
>         while (match := self.TERM_PTN.match(cmd)) is not None:
>             args.append(match.group('term'))
>             if not match.group('sep'):
>                 verb = args.pop(0).upper()
>                 return verb, args
>             cmd = cmd[match.end(0):]
>         return None, None
>
> And, if this is actually a regex, "is not None" is unnecessary:
>
> while match := self.TERM_PTN.match(cmd):
>
> Now do you understand what I mean about putting the condition into the
> loop header?

Thanks, but no thanks. The "while True" idiom beats that one hands down.

As for the "is not None" test, I generally want to make it explicit
because

 1. that's what I mean and

 2. there's a chance in some context of confusing None with other falsey
    values.


Marko


From mikhailwas at gmail.com  Thu May 10 20:34:01 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Fri, 11 May 2018 03:34:01 +0300
Subject: Suggestion for a "data" object syntax
In-Reply-To: <pctpo0$qbi$1@blaine.gmane.org>
References: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
 <pcriqa$16m$13@blaine.gmane.org>
 <CAE6NSRCo8-dVWSAYuY8MHH6vviy_2Qn_LpGa2kRTN8L2=cceXQ@mail.gmail.com>
 <pcsf85$16m$15@blaine.gmane.org>
 <CAE6NSRALn2benyf+C87bCKSwRH3gzXcd1WHj_EawR9OngqbcSg@mail.gmail.com>
 <pctpo0$qbi$1@blaine.gmane.org>
Message-ID: <CAE6NSRCBr=EOENJPxaUG4uMyToYg+ZX_KkW0SRaT8feCWzd9Tw@mail.gmail.com>

On Wed, May 9, 2018 at 6:25 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Tue, 08 May 2018 23:16:23 +0300, Mikhail V wrote:
>

>> but I propose Tab-separated elements.
>
> We already have tab-separated elements in Python. It is allowed to use
> tabs between any whitespace separated tokens.

Yes, exactly. So in the proposed syntactic construct, it is *not*
allowed to insert tabs between _any_ tokens.
Namely if you will insert tabs _inside_ equations,
like:
a      + b

Then it will not work (it will parse 2 elements) .

So -  the simple answer, which follows directly from the
proposal: no, you don't insert tabs inside equations in this construct.
In simple words, if you want to do it nevertheless - this proposal is
not for you.

*But I am glad that at least you have managed to formulate your concern
finally,  thanks.*


>> If I allow commas as well, this will become not so simple, probably.
>> Also I don't propose syntax for e-mail code exchange, but rather syntax
>> for *work* an this can potentially help a lot of people in everyday
>> work.
>
> /head-desk
>
> You: "I have invented amazing new syntax that cannot be exchanged by
> email. Here, let me email some examples to you."

"GvR have invented amazing new syntax that cannot be preserved
by sending it by e-mail"!
(not me)

Do you understand that basically any python code sent by e-mail converts tabs to
spaces, thus the only way to receive it - is to send binary file?

Maybe you should've made more influence on that in the past and now we
all would have to use spaces only to format the code.
Also maybe include C-brackets so as not to worry when e-mail clients
add extra spaces in front of lines?


>> Also I don't know what kind of human thinks that this:
>>  a + b
>>  is two elements "a" and "+ b"
>> What is "+ b"?
>
> It is unary plus followed by b.
>
> If you don't know Python's existing syntax, how can you possibly expect
> to invent new syntax?

Wow! Uncle Steven knows Python operators.
My question was: why would you have "+ b" in
the first place in your code? So you treat the worst-case scenario
as a normal case - interesting approach  indeed!

By the way, since you are into unrealistic worst-case scenarios:
Imagine you start with Python learning, how you'd like such constructs:

L = [a     +     b, c, d]
L = [a     +     b, (c, d)]

For a starter, reading this will be quite painful.

Yes, I have told already that there are _some_ cases when
 tabulation formatting can cause visual confusion.
*But why do you blame me*?
It just the issues with editor's incompleteness.
Simple feature like "set the minimal tab size" would have solved
this issue by 100%. Maybe it even exists in some editors,
I would not be surprised at least.

 I hope you are not seriously thinking that there is good syntax
 that gives retro-tools, wacky people, not wacky people,
 pros, etc. same opportunities.

For instance, there is real demand on adding new control characters
to syntax, so as IDE developers can utilize those for making
better user experience. If you apply same one-sided principles here
then you behave good to one group of people, but just ignorant
to other group of people who want better new experience.

Seriously, your sarcasm is pretty one-sided.
You should try to think a bit wider.


>> I don't want spaces or tabs visible - there is toggle "show tabs"
>> and "toggle show space" for that
>
> /head-desk
>
> You: "This syntax doesn't need tabs and spaces to be visible. Just use
> the Show Tabs and Show Spaces commands on your editor to make them
> visible."

Yep!  Just toggle them if you want to find out. That's a good feature!

And you know, **head-desk'ing too often (and without reason) may
be not good to you.**
We need healthy Steven.


>
>>> Using a particular editor is not and will not be a mandatory
>>> requirement for Python.
>>
>> Using outdated tools or being PEBCAK are not and will not be
>> justification for language syntax improvements.
>
> It is not your choice of what editors people are permitted to use in
> order to read and write Python.

Yeah, but most people do not want to sit with technologies from 80's,
especially when many new possibilities are already available.
And that's why the scene of editors is changing so fast,
there is a lot that makes it easier to work.


>>> - the first one can include nested data structures, while
>>>   the second cannot.
>>
>> Why it can't? did you read the original e-mail?
>
> Of course I did. You said:
>
>     "So the idea is to cover only first two levels of
>     nesting of course."
>
> With bracket syntax, I can cover unlimited levels of nesting. Yours
> cannot.

Ok, that was a typo, it must be:

    "So the idea is to _hide brackets for_ first two levels of
    nesting of course."

Thanks for noticing. So it can, but that's not an easy one to
implement.



M


From bc at freeuk.com  Thu May 10 20:55:58 2018
From: bc at freeuk.com (bartc)
Date: Fri, 11 May 2018 01:55:58 +0100
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <87o9hn82e9.fsf@elektro.pacujo.net>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>
 <mailman.84.1525976408.28519.python-list@python.org>
 <2W3JC.64439$7b4.11219@fx12.am4>
 <CAPTjJmr+t3ivSpTqiGmD3DBJo8dba+5sriMffYRsdfVC+yRpSg@mail.gmail.com>
 <mailman.94.1525997497.28519.python-list@python.org>
 <87o9hn82e9.fsf@elektro.pacujo.net>
Message-ID: <kS5JC.258835$sl2.255712@fx46.am4>

On 11/05/2018 01:25, Marko Rauhamaa wrote:
> Chris Angelico <rosuav at gmail.com>:
> 
>> Octal makes a lot of sense in the right contexts.
> 
> I think octal is a historical relic from a time when people weren't yet
> comfortable with hexadecimal.

It's a relic from when machines had word sizes that were multiples of 
three bits, or were divided up on 3-bit boundaries.

-- 
bartc


From rosuav at gmail.com  Thu May 10 21:08:16 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 11 May 2018 11:08:16 +1000
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <87o9hn82e9.fsf@elektro.pacujo.net>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>
 <mailman.84.1525976408.28519.python-list@python.org>
 <2W3JC.64439$7b4.11219@fx12.am4>
 <CAPTjJmr+t3ivSpTqiGmD3DBJo8dba+5sriMffYRsdfVC+yRpSg@mail.gmail.com>
 <mailman.94.1525997497.28519.python-list@python.org>
 <87o9hn82e9.fsf@elektro.pacujo.net>
Message-ID: <CAPTjJmq_ZVBFhYVHbTYwsTRYj+BD-xjTM+KwtyhBL+oF4XqzRg@mail.gmail.com>

On Fri, May 11, 2018 at 10:25 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
> Chris Angelico <rosuav at gmail.com>:
>
>> Octal makes a lot of sense in the right contexts.
>
> I think octal is a historical relic from a time when people weren't yet
> comfortable with hexadecimal.

And any other situation where it makes more sense to group bits into
threes instead of fours. For instance, if you have a six-bit byte,
there's no point using hex. Or if you're working with seven-bit bytes
and use the high bit as a continuation marker.

>> Allowing octal literals is a Good Thing.
>
> I think it's just unavoidable mainly because of os.chmod.

And a variety of other contexts. Yes, chmod is probably the only one
that typical people will come across, but atypical people who read
packet diagrams are just as likely to group bits in other ways than
octets.

If you were to create a new programming language _today_, you MIGHT be
able to get away with not having any form of octal literal (and force
people to use something like int("100644", 8) to define file modes).
Emphasis on might. For any language that's been around for 20+ years,
octal was too important to not retain, and too useful even today to
discard as a mere historical relic.

ChrisA


From rosuav at gmail.com  Thu May 10 21:10:12 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 11 May 2018 11:10:12 +1000
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <87k1sb8262.fsf@elektro.pacujo.net>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net>
 <CAPTjJmqMpUUzKJmomk3Ypms3_k8Cp0eOrDmNEKigQLQfjyzGdQ@mail.gmail.com>
 <mailman.92.1525982855.28519.python-list@python.org>
 <87wowb86sz.fsf@elektro.pacujo.net>
 <CAPTjJmpf+HCK-k8St_HK01FYFYac5xUZBB0vq6rLOpJWRrHzHw@mail.gmail.com>
 <mailman.95.1525998102.28519.python-list@python.org>
 <87k1sb8262.fsf@elektro.pacujo.net>
Message-ID: <CAPTjJmq7pF-qg_t_ioEHX6rDHAn0zF7Pqc43eiDHfQWEsiJwAQ@mail.gmail.com>

On Fri, May 11, 2018 at 10:29 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
> Chris Angelico <rosuav at gmail.com>:
>
>> But for the loop itself, you absolutely CAN write this more logically.
>> I'll take your second version as a template:
>>
>>     def split_cmd(self, cmd):
>>         args = []
>>         while (match := self.TERM_PTN.match(cmd)) is not None:
>>             args.append(match.group('term'))
>>             if not match.group('sep'):
>>                 verb = args.pop(0).upper()
>>                 return verb, args
>>             cmd = cmd[match.end(0):]
>>         return None, None
>>
>> And, if this is actually a regex, "is not None" is unnecessary:
>>
>> while match := self.TERM_PTN.match(cmd):
>>
>> Now do you understand what I mean about putting the condition into the
>> loop header?
>
> Thanks, but no thanks. The "while True" idiom beats that one hands down.

Because you're used to it? Or because it's somehow more logical to
pretend that this is an infinite loop? Explain in more detail.

> As for the "is not None" test, I generally want to make it explicit
> because
>
>  1. that's what I mean and
>
>  2. there's a chance in some context of confusing None with other falsey
>     values.
>

With the standard library re module, there is no such chance. So it's
pointlessly explicit about something that won't ever happen.

ChrisA


From ganesh1pal at gmail.com  Thu May 10 21:23:34 2018
From: ganesh1pal at gmail.com (Ganesh Pal)
Date: Fri, 11 May 2018 06:53:34 +0530
Subject: Print Failure or success based on the value of the standalone tool
In-Reply-To: <pd1tga$a89$2@dont-email.me>
References: <CACT3xuULQFwpitT=WXzxapv=kVnVVOBemHy94QBDTCCH_zSM4w@mail.gmail.com>
 <mailman.79.1525970923.28519.python-list@python.org>
 <pd1tga$a89$2@dont-email.me>
Message-ID: <CACT3xuWzvZgdfDHJ4x6ESx4hSRx4HoHk7QTK9mRiuiz2RDa-bg@mail.gmail.com>

On Thu, May 10, 2018, 22:31 Rob Gaddi

>
>
> By not using os.system, it's been superseded for reasons exactly like
> yours.  https://docs.python.org/3/library/subprocess.html is your friend.
>

Can someone please help me understand this better for me with a program .
Will the  returncode of subprocess still not be  0 or -ve number ?

My requirement is let the  test_standalone_tool.py script which is a
wrapper around standalone_tool.py print pass /fail based on the possible
values I.e True , False and None

I'm not sure weather if I need to i.e replace os.system with subprocess or
make changes in standalone_tool.py to return 0 or -1( use sys.exit())

Regards,
Ganesh


From gheskett at shentel.net  Thu May 10 21:36:26 2018
From: gheskett at shentel.net (Gene Heskett)
Date: Thu, 10 May 2018 21:36:26 -0400
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <kS5JC.258835$sl2.255712@fx46.am4>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <87o9hn82e9.fsf@elektro.pacujo.net> <kS5JC.258835$sl2.255712@fx46.am4>
Message-ID: <201805102136.26478.gheskett@shentel.net>

On Thursday 10 May 2018 20:55:58 bartc wrote:

> On 11/05/2018 01:25, Marko Rauhamaa wrote:
> > Chris Angelico <rosuav at gmail.com>:
> >> Octal makes a lot of sense in the right contexts.
> >
> > I think octal is a historical relic from a time when people weren't
> > yet comfortable with hexadecimal.
>
> It's a relic from when machines had word sizes that were multiples of
> three bits, or were divided up on 3-bit boundaries.
>
> --
> bartc

Maybe so, but isn't it time to fix that?  The first "computer" I ever got 
to take home and learn how it worked, was a Quest Super Elf, had an RCA 
1802 processor on it. This was winter of 77-78, and it had a monitor 
that spoke hexidecimal. I spent that winter exploring it before I set 
out to write the program it would run until June 30th 2008 when we 
switched from Never Twice Same Color to digital.

So other than the *nix chmod, and some similar stuff in 
os9/nitros9/amigados, I have never had to deal with octal. I'm sure the 
security people would be pleased if another bit could be expanded into 
the permissions that chmod controls, so lets deprecate octal and be done 
with it. Computers haven't read a single 8 bit byte in years, some 
reading 128 or 256 bits in a single read cycle today. Bring the language 
into the 21st century.

Its a dirty job, but somebody will have to do it eventually, why not now?

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


From bob at mellowood.ca  Thu May 10 22:04:29 2018
From: bob at mellowood.ca (Bob van der Poel)
Date: Thu, 10 May 2018 19:04:29 -0700
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <201805102136.26478.gheskett@shentel.net>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <87o9hn82e9.fsf@elektro.pacujo.net> <kS5JC.258835$sl2.255712@fx46.am4>
 <201805102136.26478.gheskett@shentel.net>
Message-ID: <CA+HdcZjR=twKaHn-dZ2f2d3bW0H8F4i3D6eN32LnOgfmCtCb-A@mail.gmail.com>

On Thu, May 10, 2018 at 6:36 PM, Gene Heskett <gheskett at shentel.net> wrote:

> On Thursday 10 May 2018 20:55:58 bartc wrote:
>
> > On 11/05/2018 01:25, Marko Rauhamaa wrote:
> > > Chris Angelico <rosuav at gmail.com>:
> > >> Octal makes a lot of sense in the right contexts.
> > >
> > > I think octal is a historical relic from a time when people weren't
> > > yet comfortable with hexadecimal.
> >
> > It's a relic from when machines had word sizes that were multiples of
> > three bits, or were divided up on 3-bit boundaries.
> >
> > --
> > bartc
>
> Maybe so, but isn't it time to fix that?  The first "computer" I ever got
> to take home and learn how it worked, was a Quest Super Elf, had an RCA
> 1802 processor on it. This was winter of 77-78, and it had a monitor
> that spoke hexidecimal. I spent that winter exploring it before I set
> out to write the program it would run until June 30th 2008 when we
> switched from Never Twice Same Color to digital.
>
> So other than the *nix chmod, and some similar stuff in
> os9/nitros9/amigados, I have never had to deal with octal. I'm sure the
> security people would be pleased if another bit could be expanded into
> the permissions that chmod controls, so lets deprecate octal and be done
> with it. Computers haven't read a single 8 bit byte in years, some
> reading 128 or 256 bits in a single read cycle today. Bring the language
> into the 21st century.
>
> Its a dirty job, but somebody will have to do it eventually, why not now?
>

I agree with my freind Gene! And, if it is really necessary to retain
octal, why not preface it with anything BUT a "0". I've been hit by this a
few times in the past. I used lots of hex over the years, but don't recall
ever using octal ... except in frustrating moments when I needed to change
permission bits.

-- 

**** Listen to my FREE CD at http://www.mellowood.ca/music/cedars ****
Bob van der Poel ** Wynndel, British Columbia, CANADA **
EMAIL: bob at mellowood.ca
WWW:   http://www.mellowood.ca


From rosuav at gmail.com  Thu May 10 22:07:24 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 11 May 2018 12:07:24 +1000
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <201805102136.26478.gheskett@shentel.net>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <87o9hn82e9.fsf@elektro.pacujo.net> <kS5JC.258835$sl2.255712@fx46.am4>
 <201805102136.26478.gheskett@shentel.net>
Message-ID: <CAPTjJmoBT+Ra0f5km3U89S0s1FLOS1FBynHnRnigZkKROnTG2A@mail.gmail.com>

On Fri, May 11, 2018 at 11:36 AM, Gene Heskett <gheskett at shentel.net> wrote:
> So other than the *nix chmod, and some similar stuff in
> os9/nitros9/amigados, I have never had to deal with octal. I'm sure the
> security people would be pleased if another bit could be expanded into
> the permissions that chmod controls, so lets deprecate octal and be done
> with it.

What do you mean, "another bit"? Currently, the chmod command on my
system can manage nine primary bits (rwx for each of ugo), plus
setuid, setgid, and sticky. Plus there's a flag for "this is a
symbolic link" and another for "this is a directory", and at least one
or two for devices.

> Computers haven't read a single 8 bit byte in years, some
> reading 128 or 256 bits in a single read cycle today. Bring the language
> into the 21st century.

Remind me how you parse an IP packet (v4 or v6). Do you work with 256
bits at a time?

And if you say "nobody parses network packets in Python", it's a lot
more likely that you'll do network debugging in Python than that
you'll care how exactly your CPU retrieves data from DRAM.

Marking octal literals with "0o" was the right decision. Excising
octal from the language would not be.

ChrisA


From ian.g.kelly at gmail.com  Thu May 10 22:37:36 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Thu, 10 May 2018 20:37:36 -0600
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
Message-ID: <CALwzidmb=sE9Er4UdFuvZGFc6zn+c+NCGEye-DceEGbYFDQ84w@mail.gmail.com>

On Tue, May 8, 2018 at 11:50 PM, Chris Angelico <rosuav at gmail.com> wrote:
> On Wed, May 9, 2018 at 3:36 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
>>
>> while True:
>>     if we_are_done():
>>         break
>>     # do some stuff
>>     ...
>>     if error_occurred():
>>         break
>> notify_user()
>>
>>
>> Fixed, using idiomatic Python and without needing to use assignment in
>> an expression.
>
> Why is it that "while True" is idiomatic Python for a non-infinite
> loop? Is it merely because Python currently has no other way to spell
> certain loops? Surely it would be more idiomatic to encode the loop's
> termination condition in the header, if it were possible.

In the case of the code above you're correct; the condition could be
moved directly into the while. The loop that I adapted first assigned
we_are_done() to flag and then asserted that flag would be checked
again later. I neglected to maintain this part when I rewrote it.


From ian.g.kelly at gmail.com  Thu May 10 22:38:39 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Thu, 10 May 2018 20:38:39 -0600
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <CAPTjJmq7pF-qg_t_ioEHX6rDHAn0zF7Pqc43eiDHfQWEsiJwAQ@mail.gmail.com>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net>
 <CAPTjJmqMpUUzKJmomk3Ypms3_k8Cp0eOrDmNEKigQLQfjyzGdQ@mail.gmail.com>
 <mailman.92.1525982855.28519.python-list@python.org>
 <87wowb86sz.fsf@elektro.pacujo.net>
 <CAPTjJmpf+HCK-k8St_HK01FYFYac5xUZBB0vq6rLOpJWRrHzHw@mail.gmail.com>
 <mailman.95.1525998102.28519.python-list@python.org>
 <87k1sb8262.fsf@elektro.pacujo.net>
 <CAPTjJmq7pF-qg_t_ioEHX6rDHAn0zF7Pqc43eiDHfQWEsiJwAQ@mail.gmail.com>
Message-ID: <CALwzidk424PzRwWoD3qWU=Yo4=pc9pRMv9NRpMZtgrscG0E4Lg@mail.gmail.com>

On Thu, May 10, 2018 at 7:10 PM, Chris Angelico <rosuav at gmail.com> wrote:
> On Fri, May 11, 2018 at 10:29 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
>> Chris Angelico <rosuav at gmail.com>:
>>
>>> But for the loop itself, you absolutely CAN write this more logically.
>>> I'll take your second version as a template:
>>>
>>>     def split_cmd(self, cmd):
>>>         args = []
>>>         while (match := self.TERM_PTN.match(cmd)) is not None:
>>>             args.append(match.group('term'))
>>>             if not match.group('sep'):
>>>                 verb = args.pop(0).upper()
>>>                 return verb, args
>>>             cmd = cmd[match.end(0):]
>>>         return None, None
>>>
>>> And, if this is actually a regex, "is not None" is unnecessary:
>>>
>>> while match := self.TERM_PTN.match(cmd):
>>>
>>> Now do you understand what I mean about putting the condition into the
>>> loop header?
>>
>> Thanks, but no thanks. The "while True" idiom beats that one hands down.
>
> Because you're used to it? Or because it's somehow more logical to
> pretend that this is an infinite loop? Explain in more detail.

In what way does "while True" in the general case pretend to be an
infinite loop? The break / return is right there for anyone to see.

Would you also contend that generator functions are wrong because they
pretend to be normal functions?

def totally_not_a_generator(n):
    while True:
        if n % 2 == 0:
            n //= 2
        else:
            n = n * 3 + 1
        stealthily = n
        yield stealthily
        if n == 1:
            return n

py> print(totally_not_a_generator(42))  # Lies!
<generator object totally_not_a_generator at 0x77fe4d78c0f8>


From steve+comp.lang.python at pearwood.info  Thu May 10 23:16:51 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 11 May 2018 03:16:51 +0000 (UTC)
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
Message-ID: <pd31v3$qbi$5@blaine.gmane.org>

On Thu, 10 May 2018 17:36:39 +0100, bartc wrote:

> I wonder why someone would take a feature generally agreed to be a
> poorly designed feature of C, and incorporate it into a new language.

Because in 1991 or thereabouts, when Guido was designing the language for 
the first time, he thought it was a good idea since Python was intended 
to be a glue language to act as an interface to C libraries, and he 
probably imagined it would mostly be used by people familiar with C.

In hindsight that turned out to be one of the less great ideas, but the 
only people who have no bad ideas are those who have no ideas at all.


>> That changed in Python 3. If you slim
>> the start of PEP 3127, you'll learn the new notation.
> 
> What, 0O100 instead of 0100? Yeah that's a big improvement...

Then write it as 0o100 like sensible people do.


> Fortunately octal doesn't get used much.

Indeed.


-- 
Steve



From steve+comp.lang.python at pearwood.info  Thu May 10 23:21:11 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 11 May 2018 03:21:11 +0000 (UTC)
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CALwzidn6qiie4oz3CmysS6D-AtUoF2h215VJODDUL9L89pygNg@mail.gmail.com>
Message-ID: <pd3276$qbi$6@blaine.gmane.org>

On Thu, 10 May 2018 11:03:54 -0600, Ian Kelly wrote about proposed 
prefixes for octal:

> Personally I would have preferred the "t".

"t" for octal, hey?

That would be annoying if we ever get trinary literals.

n for binary
t for octal
i for trinary
or should that be r for ternary?
o for duodecimal

and of course, x for hexadecimal.

I can just imagine the Stackoverflow posts now...


-- 
Steve



From steve+comp.lang.python at pearwood.info  Thu May 10 23:31:14 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 11 May 2018 03:31:14 +0000 (UTC)
Subject: seeking deeper (language theory) reason behind Python design
 choice
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net>
Message-ID: <pd32q2$qbi$7@blaine.gmane.org>

On Thu, 10 May 2018 22:59:03 +0300, Marko Rauhamaa wrote:

> It turns out "while True" is the most natural choice in
> about half of the while loops.


YMMV.

In my case, it is more like about one in ten.




-- 
Steve



From cs at cskk.id.au  Thu May 10 23:38:36 2018
From: cs at cskk.id.au (Cameron Simpson)
Date: Fri, 11 May 2018 13:38:36 +1000
Subject: Print Failure or success based on the value of the standalone tool
In-Reply-To: <CACT3xuWzvZgdfDHJ4x6ESx4hSRx4HoHk7QTK9mRiuiz2RDa-bg@mail.gmail.com>
References: <CACT3xuWzvZgdfDHJ4x6ESx4hSRx4HoHk7QTK9mRiuiz2RDa-bg@mail.gmail.com>
Message-ID: <20180511033836.GA68526@cskk.homeip.net>

On 11May2018 06:53, Ganesh Pal <ganesh1pal at gmail.com> wrote:
>On Thu, May 10, 2018, 22:31 Rob Gaddi
>> By not using os.system, it's been superseded for reasons exactly like
>> yours.  https://docs.python.org/3/library/subprocess.html is your friend.
>
>Can someone please help me understand this better for me with a program .
>Will the  returncode of subprocess still not be  0 or -ve number ?
>
>My requirement is let the  test_standalone_tool.py script which is a
>wrapper around standalone_tool.py print pass /fail based on the possible
>values I.e True , False and None
>
>I'm not sure weather if I need to i.e replace os.system with subprocess or
>make changes in standalone_tool.py to return 0 or -1( use sys.exit())

Your problem is with standalone_tool.py. os.system() returns the exit status of 
the shell which ran your command, and that is in turn the exit status of the 
last command the shell ran i.e. your command.

Your problem is that standalone_tool.py does not return a relevant exit status.  
As far as Python is concerned your script ran to completion and Python returns 
an exit status of 0 unless you arrange otherwise.

Consider this small script:

  #!/usr/bin/python

  import sys

  def func():
    return 1

  if func() == 1:
    # indicate success as an exit status
    sys.exit(0)
  else:
    # indicate failure as an exit status
    sys.exit(1)

Your script doesn't call sys.exit(), and as such, unless it outright aborts 
(for example, from an exception) Python itself returns a 0 exit status.  
Therefore your standalone_tool.py always has an exit status of 0. Make a 
suitable call to sys.exit() at the end to return a meaningful exit status.

Returning to system() versus the subprocess module, there are other reasons to 
prefer the subprocess module. The biggest is that os.system() runs a shell 
command, a string passed to the programme /bin/sh. As such, that string is 
subject to all manner of syntax - anything the shell can understand.

For example, if you wanted to pass a filename as an argument to your script you 
would need to ensure that nothing in the filename could be misinterpreted as 
punctuation. For example, a filename containing spaces would be handled as 2 
distinct arguments by the shell unless you quote the name.

Using the subprocess module you can pass such items directly to your script 
instead of going _through_ the shell as an intermediate command. Compare:

  import os
  import subprocess

  os.system('standalone_tool.py my-filename-here')
  subprocess.run(['standalone_tool.py', 'my-filename-here'])

The former invokes the shell (/bin/sh) with the string 'standalone_tool.py 
my-filename-here', which the shell interprets. The latter directly runs your 
script.

Cheers,
Cameron Simpson <cs at cskk.id.au>


From brgrt2 at gmail.com  Thu May 10 23:43:09 2018
From: brgrt2 at gmail.com (T Berger)
Date: Thu, 10 May 2018 20:43:09 -0700 (PDT)
Subject: Meaning of abbreviated terms
In-Reply-To: <mailman.3.1525560332.28519.python-list@python.org>
References: <4f2a7e16-1b4d-4852-bc56-2d0b07c72209@googlegroups.com>
 <fe18b054-255e-1fcb-fde7-1d88697711a3@mrabarnett.plus.com>
 <mailman.3.1525560332.28519.python-list@python.org>
Message-ID: <8b5577d8-a5d3-4fd5-8975-9a45e0327162@googlegroups.com>

On Saturday, May 5, 2018 at 6:45:46 PM UTC-4, MRAB wrote:
> On 2018-05-05 17:57, T Berger wrote:
> > What does the "p" in "plist" stand for?
> > Is there a python glossary that spells out the meanings of abbreviated terms?
> > 
> "plist" is "property list". It's listed in the Python documentation.

Thanks for the answer. Missed it till now.


From steve+comp.lang.python at pearwood.info  Fri May 11 01:17:59 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 11 May 2018 05:17:59 +0000 (UTC)
Subject: seeking deeper (language theory) reason behind Python design
 choice
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net>
 <CAPTjJmqMpUUzKJmomk3Ypms3_k8Cp0eOrDmNEKigQLQfjyzGdQ@mail.gmail.com>
 <mailman.92.1525982855.28519.python-list@python.org>
 <87wowb86sz.fsf@elektro.pacujo.net>
 <CAPTjJmpf+HCK-k8St_HK01FYFYac5xUZBB0vq6rLOpJWRrHzHw@mail.gmail.com>
 <mailman.95.1525998102.28519.python-list@python.org>
 <87k1sb8262.fsf@elektro.pacujo.net>
Message-ID: <pd3926$uno$1@blaine.gmane.org>

On Fri, 11 May 2018 03:29:57 +0300, Marko Rauhamaa wrote:

>> Now do you understand what I mean about putting the condition into the
>> loop header?
> 
> Thanks, but no thanks. The "while True" idiom beats that one hands down.

Why do you think it is better to lie to the reader and tell them they are 
entering an infinite loop, only to later on say "Ha ha, fooled you!"?

It doesn't matter whether it is one line later, or sixteen pages later. 
The initial "while True" suggests an infinite loop, because the loop 
condition is *always* True, so the loop never ends.

To answer your question from a later post:

    In what way does "while True" in the general case pretend
    to be an infinite loop?

It doesn't *pretend* to be an infinite loop. It *is* an infinite loop 
which breaks out early.

I realise that all infinite loops end up breaking out early, even if it's 
only when you power-cycle the device. But code ought to match intent, and 
"while condition which can never be false" shouts from the mountain tops 
that it is an infinite loop. The simpler the condition, the more loudly 
it shouts, and you can't get simpler than True.

(The one thing that beats "while True" as an indicator of an infinite 
loop is the old Hypertalk syntax "repeat forever".)

If we want to communicate the intent of our code, the while-condition 
ought to be in the loop header *if possible*. (I appreciate it isn't 
always possible.)

We wouldn't write this:

    # let's pretend we have GOTO
    if True:
        if not condition: GOTO 99
        block
    LABEL 99


and if we came across it in real life, we'd surely question the sanity of 
the developer who wrote it. Why should while loops be any different?

    while True:
        if not condition: break  # equivalent to GOTO 99
        block
    LABEL 99

I understand that *today*, using existing Python syntax, there is 
sometimes no avoiding that (except, possibly, with something worse). I 
get that. But if we had the choice to move the condition into the while 
condition, we ought to take it.


> As for the "is not None" test, I generally want to make it explicit
> because
> 
>  1. that's what I mean and
> 
>  2. there's a chance in some context of confusing None with other falsey
>     values.

Indeed #2 is correct, and of course *in general* we ought to be explicit 
when testing for None. But in the case of regexes, I doubt that testing 
for None is *actually* what you mean. It's merely what you *think* you 
mean *wink*

To be precise, the rule is that re.match() returns a true object (a 
MatchObject) if the search succeeded, and a false object (documented as 
None) if it fails. But we surely don't care that the failure case is 
*specifically* None. It should make no difference at all if re.match() 
returned False instead, or a falsey MatchObject with all fields left 
empty, since we never use it.

So we ought not care that it is specifically None.

Testing for None particularly makes sense if you need a sentinel and:

- you don't distinguish between truthy and falsey values at all;

- or you want to distinguish between truthy values, falsey values,
  and leave None to stand in for things which are neither ("maybe"?).

The re.match case doesn't meet either of those conditions.

Of course, none of this is to say that testing for None is "wrong". 
re.match is documented as returning None, and a backwards-incompatible 
change is exceedingly unlikely. So you're safe there. It's just 
unnecessary.



-- 
Steve



From ian.g.kelly at gmail.com  Fri May 11 01:23:33 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Thu, 10 May 2018 23:23:33 -0600
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <pd3276$qbi$6@blaine.gmane.org>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CALwzidn6qiie4oz3CmysS6D-AtUoF2h215VJODDUL9L89pygNg@mail.gmail.com>
 <pd3276$qbi$6@blaine.gmane.org>
Message-ID: <CALwzidnYcdUr8PFEE4w8fC8S9YsL=sfM-U15Ex10EJQ++gqshg@mail.gmail.com>

On Thu, May 10, 2018 at 9:21 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Thu, 10 May 2018 11:03:54 -0600, Ian Kelly wrote about proposed
> prefixes for octal:
>
>> Personally I would have preferred the "t".
>
> "t" for octal, hey?
>
> That would be annoying if we ever get trinary literals.
>
> n for binary
> t for octal
> i for trinary
> or should that be r for ternary?
> o for duodecimal

I prefer it because it's the first letter of a syllable and it's not
"o", not because it's the third letter of the word. Most of those
suggestions make no sense. Why would we ever want ternary literals
anyway?


From gheskett at shentel.net  Fri May 11 01:41:23 2018
From: gheskett at shentel.net (Gene Heskett)
Date: Fri, 11 May 2018 01:41:23 -0400
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <pd3276$qbi$6@blaine.gmane.org>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CALwzidn6qiie4oz3CmysS6D-AtUoF2h215VJODDUL9L89pygNg@mail.gmail.com>
 <pd3276$qbi$6@blaine.gmane.org>
Message-ID: <201805110141.23374.gheskett@shentel.net>

On Thursday 10 May 2018 23:21:11 Steven D'Aprano wrote:

> On Thu, 10 May 2018 11:03:54 -0600, Ian Kelly wrote about proposed
>
> prefixes for octal:
> > Personally I would have preferred the "t".
>
> "t" for octal, hey?
>
> That would be annoying if we ever get trinary literals.
>
> n for binary
> t for octal
> i for trinary
> or should that be r for ternary?
> o for duodecimal
>
> and of course, x for hexadecimal.
>
> I can just imagine the Stackoverflow posts now...
>
>
> --
> Steve

We'll all be needing nomex underwear I fear.


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


From steve+comp.lang.python at pearwood.info  Fri May 11 01:45:27 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 11 May 2018 05:45:27 +0000 (UTC)
Subject: seeking deeper (language theory) reason behind Python design
 choice
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net> <87fu2z1dkp.fsf@nightsong.com>
 <87sh6z86po.fsf@elektro.pacujo.net>
Message-ID: <pd3alm$uno$2@blaine.gmane.org>

On Fri, 11 May 2018 01:51:47 +0300, Marko Rauhamaa wrote:

> Paul Rubin <no.email at nospam.invalid>:
> 
>> Marko Rauhamaa <marko at pacujo.net> writes:
>>> It turns out "while True" is the most natural choice in about half of
>>> the while loops.
>>
>> Maybe the rest would be "repeat until" if Python had that?
> 
> No. "Repeat until" is a relatively infrequent need.

And again, YMMV. In my experience, most "while True" loops would be 
better off written as a "repeat... until True" loop. But since Python 
doesn't have syntax for such repeat until loops, our work-around is to 
use a while True and break out of it at the end of the loop.

To be honest, I'm having trouble thinking of a good use-case for "while 
True", now that we have infinite iterators. Most cases of

    while True:
        x = get_item()
        if not x: break
        process(x)

are better written as:

    for x in iterator:
        process(x)



-- 
Steve



From steve+comp.lang.python at pearwood.info  Fri May 11 01:49:38 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 11 May 2018 05:49:38 +0000 (UTC)
Subject: seeking deeper (language theory) reason behind Python design
 choice
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net>
 <CAPTjJmqMpUUzKJmomk3Ypms3_k8Cp0eOrDmNEKigQLQfjyzGdQ@mail.gmail.com>
 <mailman.92.1525982855.28519.python-list@python.org>
 <87wowb86sz.fsf@elektro.pacujo.net>
 <CAPTjJmpf+HCK-k8St_HK01FYFYac5xUZBB0vq6rLOpJWRrHzHw@mail.gmail.com>
 <mailman.95.1525998102.28519.python-list@python.org>
 <87k1sb8262.fsf@elektro.pacujo.net> <pd3926$uno$1@blaine.gmane.org>
Message-ID: <pd3ati$uno$3@blaine.gmane.org>

On Fri, 11 May 2018 05:17:59 +0000, Steven D'Aprano wrote:

> On Fri, 11 May 2018 03:29:57 +0300, Marko Rauhamaa wrote:
[...]
> To answer your question from a later post:
> 
>     In what way does "while True" in the general case pretend to be an
>     infinite loop?

Oops, sorry, that was Ian Kelly who asked that, not Marko.



-- 
Steve



From steve+comp.lang.python at pearwood.info  Fri May 11 02:03:19 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 11 May 2018 06:03:19 +0000 (UTC)
Subject: seeking deeper (language theory) reason behind Python design
 choice
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net>
 <CAPTjJmqMpUUzKJmomk3Ypms3_k8Cp0eOrDmNEKigQLQfjyzGdQ@mail.gmail.com>
 <mailman.92.1525982855.28519.python-list@python.org>
 <87wowb86sz.fsf@elektro.pacujo.net>
 <CAPTjJmpf+HCK-k8St_HK01FYFYac5xUZBB0vq6rLOpJWRrHzHw@mail.gmail.com>
 <mailman.95.1525998102.28519.python-list@python.org>
 <87k1sb8262.fsf@elektro.pacujo.net>
 <CAPTjJmq7pF-qg_t_ioEHX6rDHAn0zF7Pqc43eiDHfQWEsiJwAQ@mail.gmail.com>
 <CALwzidk424PzRwWoD3qWU=Yo4=pc9pRMv9NRpMZtgrscG0E4Lg@mail.gmail.com>
Message-ID: <pd3bn6$uno$4@blaine.gmane.org>

On Thu, 10 May 2018 20:38:39 -0600, Ian Kelly wrote:

> Would you also contend that generator functions are wrong because they
> pretend to be normal functions?

You're going to need to be more specific. In what way are they not normal 
functions? You call them like normal functions, providing arguments like 
normal functions, and receiving a result just like normal functions.

If you call a function like iter(), you also get back an iterator, just 
as you do when you call a generator. Is iter() not a normal function?

We also call classes, and callable instances, as if they were normal 
functions. Is that also a problem?

I guess the answer depends on what we mean by "function":

- an instance of FunctionType

- a thing we call to get back a result

or possibly both, as context requires.


> def totally_not_a_generator(n):
>     while True:
>         if n % 2 == 0:
>             n //= 2
>         else:
>             n = n * 3 + 1
>         stealthily = n
>         yield stealthily
>         if n == 1:
>             return n

I must admit, I'm a little perplexed. In what way is this totally not a 
generator? (To be precise, a generator function.) The inspect module 
thinks it is (and so do I): 

py> inspect.isgeneratorfunction(totally_not_a_generator)
True

as well as a function:

py> inspect.isfunction(totally_not_a_generator)
True


It's not a *generator object*, but it returns one:


py> inspect.isgenerator(totally_not_a_generator)
False
py> inspect.isgenerator(totally_not_a_generator(99))
True


-- 
Steve



From ian.g.kelly at gmail.com  Fri May 11 02:12:36 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Fri, 11 May 2018 00:12:36 -0600
Subject: Suggestion for a "data" object syntax
In-Reply-To: <CAE6NSRCBr=EOENJPxaUG4uMyToYg+ZX_KkW0SRaT8feCWzd9Tw@mail.gmail.com>
References: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
 <pcriqa$16m$13@blaine.gmane.org>
 <CAE6NSRCo8-dVWSAYuY8MHH6vviy_2Qn_LpGa2kRTN8L2=cceXQ@mail.gmail.com>
 <pcsf85$16m$15@blaine.gmane.org>
 <CAE6NSRALn2benyf+C87bCKSwRH3gzXcd1WHj_EawR9OngqbcSg@mail.gmail.com>
 <pctpo0$qbi$1@blaine.gmane.org>
 <CAE6NSRCBr=EOENJPxaUG4uMyToYg+ZX_KkW0SRaT8feCWzd9Tw@mail.gmail.com>
Message-ID: <CALwzidksU9-2whNm=fLiM1vNVcCLZFCQd7QdANOVjeaSDdCdXQ@mail.gmail.com>

On Thu, May 10, 2018 at 6:34 PM, Mikhail V <mikhailwas at gmail.com> wrote:
> On Wed, May 9, 2018 at 6:25 AM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> On Tue, 08 May 2018 23:16:23 +0300, Mikhail V wrote:
>>
>
>>> but I propose Tab-separated elements.
>>
>> We already have tab-separated elements in Python. It is allowed to use
>> tabs between any whitespace separated tokens.
>
> Yes, exactly. So in the proposed syntactic construct, it is *not*
> allowed to insert tabs between _any_ tokens.
> Namely if you will insert tabs _inside_ equations,
> like:
> a      + b

Then these are not ordinary expressions, are they? They're a different
type of expression and will require a modified parser. This adds
complexity.

>>> If I allow commas as well, this will become not so simple, probably.
>>> Also I don't propose syntax for e-mail code exchange, but rather syntax
>>> for *work* an this can potentially help a lot of people in everyday
>>> work.
>>
>> /head-desk
>>
>> You: "I have invented amazing new syntax that cannot be exchanged by
>> email. Here, let me email some examples to you."
>
> "GvR have invented amazing new syntax that cannot be preserved
> by sending it by e-mail"!
> (not me)
>
> Do you understand that basically any python code sent by e-mail converts tabs to
> spaces, thus the only way to receive it - is to send binary file?

Um, no, this is false. We send Python code by email all the time.

There are essentially three cases of tabs that can occur in Python:

1) Tabs as indentation: Python permits the use of both tabs and spaces
as indentation, but it requires consistency; if one line is indented
with a tab and three spaces, then the next line in the same block must
also use a tab and three spaces. Therefore, if the tabs are converted
to spaces, they will be converted to the same number of spaces
throughout the block. Indents and dedents remain intact, indentation
is therefore not ruined, and the meaning of the program is not
changed.

2) Tabs as other whitespace: Other tabs in the program, such as in
expressions, don't matter at all. They can safely be replaced with
spaces, and the meaning of the program is not changed.

3) Tabs that appear in strings: This one I'll grant you. A replaced
tab inside a string may alter the meaning of the program. However,
note two things: tabs are rarely used in strings, and when they do
appear it's usual to write them as \t rather than with an actual tab
character.

In any case, the use of tabs is entirely optional. For the most part,
programs can be safely emailed whether they contain tabs or not, the
exception being tabs in strings which are better written as \t. In the
case of your proposed syntax however, the tabs are *required*, and it
is not possible to email a program containing such a construct at all.
Contrary to your assertion, this is *far* different from the status
quo.

>>> Also I don't know what kind of human thinks that this:
>>>  a + b
>>>  is two elements "a" and "+ b"
>>> What is "+ b"?
>>
>> It is unary plus followed by b.
>>
>> If you don't know Python's existing syntax, how can you possibly expect
>> to invent new syntax?
>
> Wow! Uncle Steven knows Python operators.
> My question was: why would you have "+ b" in
> the first place in your code? So you treat the worst-case scenario
> as a normal case - interesting approach  indeed!

When you're designing a language syntax, you need to account for *all*
the cases, not just the ones that you personally would use.

> By the way, since you are into unrealistic worst-case scenarios:
> Imagine you start with Python learning, how you'd like such constructs:
>
> L = [a     +     b, c, d]
> L = [a     +     b, (c, d)]
>
> For a starter, reading this will be quite painful.

I don't know, I find that much less painful than:

L === T:
        a + b   c       d

> Yes, I have told already that there are _some_ cases when
>  tabulation formatting can cause visual confusion.
> *But why do you blame me*?
> It just the issues with editor's incompleteness.
> Simple feature like "set the minimal tab size" would have solved
> this issue by 100%. Maybe it even exists in some editors,
> I would not be surprised at least.

That's great, but if I'm editing a file on an embedded system over a
serial port and the only editor I have available is nano, I should be
able to use it. You can't just assume that everybody has a fully
featured editor (and knows how to use it -- what was that point you
made just above about beginners?)

>  I hope you are not seriously thinking that there is good syntax
>  that gives retro-tools, wacky people, not wacky people,
>  pros, etc. same opportunities.

Why not? The existing Python syntax is fine for this.

> For instance, there is real demand on adding new control characters
> to syntax, so as IDE developers can utilize those for making
> better user experience. If you apply same one-sided principles here
> then you behave good to one group of people, but just ignorant
> to other group of people who want better new experience.

Please link the approved PEP that is going to add syntactically
meaningful control characters.

>>> I don't want spaces or tabs visible - there is toggle "show tabs"
>>> and "toggle show space" for that
>>
>> /head-desk
>>
>> You: "This syntax doesn't need tabs and spaces to be visible. Just use
>> the Show Tabs and Show Spaces commands on your editor to make them
>> visible."
>
> Yep!  Just toggle them if you want to find out. That's a good feature!

Needing to fiddle with editor settings in order to determine how the
code in front of me that somebody else wrote is organized doesn't
sound to me like a good feature. That sounds to me like poor
readability.

>>>> - the first one can include nested data structures, while
>>>>   the second cannot.
>>>
>>> Why it can't? did you read the original e-mail?
>>
>> Of course I did. You said:
>>
>>     "So the idea is to cover only first two levels of
>>     nesting of course."
>>
>> With bracket syntax, I can cover unlimited levels of nesting. Yours
>> cannot.
>
> Ok, that was a typo, it must be:
>
>     "So the idea is to _hide brackets for_ first two levels of
>     nesting of course."

In other words, this syntax is really not appropriate for more than
two levels of nesting due to the mental gymnastics required to keep
track of how the current level of nesting should be expressed.


From steve+comp.lang.python at pearwood.info  Fri May 11 02:19:28 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 11 May 2018 06:19:28 +0000 (UTC)
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CALwzidn6qiie4oz3CmysS6D-AtUoF2h215VJODDUL9L89pygNg@mail.gmail.com>
 <pd3276$qbi$6@blaine.gmane.org>
 <CALwzidnYcdUr8PFEE4w8fC8S9YsL=sfM-U15Ex10EJQ++gqshg@mail.gmail.com>
Message-ID: <pd3clf$uno$5@blaine.gmane.org>

On Thu, 10 May 2018 23:23:33 -0600, Ian Kelly wrote:

> On Thu, May 10, 2018 at 9:21 PM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> On Thu, 10 May 2018 11:03:54 -0600, Ian Kelly wrote about proposed
>> prefixes for octal:
>>
>>> Personally I would have preferred the "t".
>>
>> "t" for octal, hey?
>>
>> That would be annoying if we ever get trinary literals.
>>
>> n for binary
>> t for octal
>> i for trinary
>> or should that be r for ternary?
>> o for duodecimal
> 
> I prefer it because it's the first letter of a syllable and it's not
> "o", not because it's the third letter of the word.

You should have said. Since you quoted the PEP, I inferred you were 
agreeing with the PEP's suggestion:

    even to use a "t" for "ocTal" and an "n" for "biNary" to
    go along with the "x" for "heXadecimal".

Note the "go along with". The X of hexadecimal, and the N of binary, are 
the *last* letter of a syllable, not the first, so I didn't think that 
"first letter of a syllable" was the rule you were applying. If it were, 
you would have picked "C" for oc-tal, not t.

So I guess the rule is:

    "first letter of the word, if the word starts with
    B, or the last letter of the first syllable, if the
    syllable ends with X, or first letter of the second
    syllable if it starts with C, or some random letter
    so long as its not O"

:-)


> Most of those
> suggestions make no sense. Why would we ever want ternary literals
> anyway?

https://en.wikipedia.org/wiki/Ternary_numeral_system#Practical_usage



-- 
Steve



From bob.martin at excite.com  Fri May 11 07:20:36 2018
From: bob.martin at excite.com (Bob Martin)
Date: Fri, 11 May 2018 07:20:36 BST
Subject: Meaning of abbreviated terms
References: <4f2a7e16-1b4d-4852-bc56-2d0b07c72209@googlegroups.com>
 <8b5577d8-a5d3-4fd5-8975-9a45e0327162@googlegroups.com>
Message-ID: <flkr1kF1jgU1@mid.individual.net>

in 793605 20180511 044309 T Berger <brgrt2 at gmail.com> wrote:
>On Saturday, May 5, 2018 at 6:45:46 PM UTC-4, MRAB wrote:
>> On 2018-05-05 17:57, T Berger wrote:
>> > What does the "p" in "plist" stand for?
>> > Is there a python glossary that spells out the meanings of abbreviated terms?
>> >
>> "plist" is "property list". It's listed in the Python documentation.
>
>Thanks for the answer. Missed it till now.

In IBM-speak it was parameter list.


From steve+comp.lang.python at pearwood.info  Fri May 11 02:28:06 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 11 May 2018 06:28:06 +0000 (UTC)
Subject: Meaning of abbreviated terms
References: <4f2a7e16-1b4d-4852-bc56-2d0b07c72209@googlegroups.com>
 <8b5577d8-a5d3-4fd5-8975-9a45e0327162@googlegroups.com>
 <flkr1kF1jgU1@mid.individual.net>
Message-ID: <pd3d5m$uno$6@blaine.gmane.org>

On Fri, 11 May 2018 07:20:36 +0000, Bob Martin wrote:

> in 793605 20180511 044309 T Berger <brgrt2 at gmail.com> wrote:
>>On Saturday, May 5, 2018 at 6:45:46 PM UTC-4, MRAB wrote:
>>> On 2018-05-05 17:57, T Berger wrote:
>>> > What does the "p" in "plist" stand for? Is there a python glossary
>>> > that spells out the meanings of abbreviated terms?
>>> >
>>> "plist" is "property list". It's listed in the Python documentation.
>>
>>Thanks for the answer. Missed it till now.
> 
> In IBM-speak it was parameter list.



But that's not where plists came from, was it? As I understand it, the 
plist data format was invented by Apple, and they called it a property 
list.


-- 
Steve



From ian.g.kelly at gmail.com  Fri May 11 02:39:38 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Fri, 11 May 2018 00:39:38 -0600
Subject: Suggestion for a "data" object syntax
In-Reply-To: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
References: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
Message-ID: <CALwzidnf+djaR+hQsBffM1netC_wmiq_p6rdm05wmM7dbx=KFA@mail.gmail.com>

On Mon, May 7, 2018 at 9:45 PM, Mikhail V <mikhailwas at gmail.com> wrote:
> Here is an idea for 'data object' a syntax.
> For me it is interesting, how would users find such syntax.
> I personally find that this should be attractive from users
> perspective.
> Main aim is more readable presenting of typical data chunks
> and some typical data types (tuples/lists) directly in code.
> Further this should significantly simplify typing.
>
> *Example 1. Multi-line strings*
>
> Here is a 3 lines multi-line string, it will be automatically 'dedented'
> by the parser by one level of indent:
>
> data === S :
>     this is multi-line string
>     escape chars: same as in strings (\\, \\n, \\t ...) ,
>     but "no need to 'escape' quotes"

My reaction #1: why 'S'? Python strings have a name: it's 'str'. They
don't need an additional, even more opaque name on top of that. If I
could go back in time and change the name of the type from 'str' to
'string', I would.

My reaction #2: what's the point of this construct? Python already has
multi-line strings that can be used as expressions, not as statements
only. Why do we need this syntax also? This is also not really
homomorphic with the proposed tuple syntax since that uses
tab-separated fields whereas this is just freeform text.

My reaction #3: Not a fan of adding an '===' operator. We already have
'=' and '=='. Javascript is another language that uses '===' to mean
something completely different from this proposal (it's another
equality operator) and it's a mess there. Come up with something else.

My reaction #4: Come to think of it, in keeping with other assigment
operators like '+=' and '*=' and '//=', if 'a === b' must exist then
it should mean 'a = a == b'. :-)

> *Example 2. Tuples*
>
> Tuple is a data block with normal Python elements.
>
> data === T :
>     1    2    3    "hello"
>     a    b    c + d
>
> Here the separators of elements are : tab character,
> new line (and maybe some white-space character like em-space?)
> The above construct will be direct synonym for:
>
> data = (1, 2, 3, "hello", a, b, c + d)
>
> Benefits are easy to see: say I want a tuple of strings:
>
> data === T :
>     "foo bar"
>     "hello world"
>     "to be continued..."
>
> VS current:
>
> data = (
>     "foo bar" ,
>     "hello world" ,
>     "to be continued..." ,
>     )
>
> Main problem with the latter are commas, it is not easy
> to type

In what bizarro world are commas harder to type than tabs? At least if
I type a comma I know I'll get a comma. If I type a tab then it
depends on my editor settings what I'll actually get.

> and, whats more important - hard to notice missing commas.

But it's totally easy to notice missing tabs, right? Not.

> And brackets of course does not make it nicer either.
>
> The above are typical cases where I see clear win, and
> IMO they are quite common constructs.
>
> More complicated examples :
>
>
> *Example 3. Two-dimensional tuple.*
>
> data === T/T :

What about T/S? S/T? S/S? Are these allowed? How would they work? I
hope you see my point from above about how these syntaxes are not
really homomorphic.

Also, why is there a division operator here?

>     1    2    3    "hello"
>     a    b     c + d    e     f
>
> is a synonym for:
>
> data = (
>     (1, 2, 3, "hello") ,
>     (a, b, c + d, e, f ) )

If this is supposed to be a tabular format then why is the second row
allowed to have a different number of elements than the first row?

What about named fields? Is there a proposal for extending this syntax
to allow construction of dicts or namedtuples?

> The rule here is: TAB character is inner elements' separator, and the
> new line is outer elements' separator. Line continuation
> character is  \  (to help with long lines).

So brackets and commas are too ugly, but line continuation characters
are just fine?

> *The benefits is just as in above examples :
> readability and 'typeability' boost.*

Sorry, I don't see it. For presentation of data this may be fine, but
for code inside a program I'm much more interested in the organization
of the data than the data itself. Commas and brackets make the
organization clear. Tabs obscure it.

> *Main rules: *
> - the definition is allowed  only as a statement (no passing as argument)

Point for the existing syntax, which can be used as an expression.

> - (imo) data starts always as a new line after the header
> - implicit string concatenation disallowed

So this would be a syntax error?

foo === T:
    "one" "two" "three"

That seems reasonable, but what about this?

foo === T/T:
    "this is a very " \
    "long string " \
    "needing to be " \
    "broken up over " \
    "several lines"

> So the question is, how do you like such syntax

I see a lot of disadvantages and not many real advantages.


From rosuav at gmail.com  Fri May 11 02:46:24 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 11 May 2018 16:46:24 +1000
Subject: Print Failure or success based on the value of the standalone tool
In-Reply-To: <20180511033836.GA68526@cskk.homeip.net>
References: <CACT3xuWzvZgdfDHJ4x6ESx4hSRx4HoHk7QTK9mRiuiz2RDa-bg@mail.gmail.com>
 <20180511033836.GA68526@cskk.homeip.net>
Message-ID: <CAPTjJmqZ2dC4816dvuf+zexkTZ_aKNn0EF+4YJM3kuVY+BRndw@mail.gmail.com>

On Fri, May 11, 2018 at 1:38 PM, Cameron Simpson <cs at cskk.id.au> wrote:
> Returning to system() versus the subprocess module, there are other reasons
> to prefer the subprocess module. The biggest is that os.system() runs a
> shell command, a string passed to the programme /bin/sh. As such, that
> string is subject to all manner of syntax - anything the shell can
> understand.

Another good point about subprocess is that you can capture the OUTPUT
of the called command, not just its return value. Hence it is the
easiest and most obvious solution to the OP's problem - that
os.system() leaves the output going to the screen, and thus cannot
succeed or fail based on it.

ChrisA


From ian.g.kelly at gmail.com  Fri May 11 02:53:24 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Fri, 11 May 2018 00:53:24 -0600
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <pd3926$uno$1@blaine.gmane.org>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net>
 <CAPTjJmqMpUUzKJmomk3Ypms3_k8Cp0eOrDmNEKigQLQfjyzGdQ@mail.gmail.com>
 <mailman.92.1525982855.28519.python-list@python.org>
 <87wowb86sz.fsf@elektro.pacujo.net>
 <CAPTjJmpf+HCK-k8St_HK01FYFYac5xUZBB0vq6rLOpJWRrHzHw@mail.gmail.com>
 <mailman.95.1525998102.28519.python-list@python.org>
 <87k1sb8262.fsf@elektro.pacujo.net> <pd3926$uno$1@blaine.gmane.org>
Message-ID: <CALwzidnPQBqPRK69_armEKU4J4U-sSf9dQW432Srzq-CYF3oQw@mail.gmail.com>

On Thu, May 10, 2018 at 11:17 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> To answer your question from a later post:
>
>     In what way does "while True" in the general case pretend
>     to be an infinite loop?
>
> It doesn't *pretend* to be an infinite loop. It *is* an infinite loop
> which breaks out early.
>
> I realise that all infinite loops end up breaking out early, even if it's
> only when you power-cycle the device. But code ought to match intent, and
> "while condition which can never be false" shouts from the mountain tops
> that it is an infinite loop. The simpler the condition, the more loudly
> it shouts, and you can't get simpler than True.
>
> (The one thing that beats "while True" as an indicator of an infinite
> loop is the old Hypertalk syntax "repeat forever".)

How about the asyncio event loop's run_forever and run_until_complete
methods? run_forever also implies an infinite loop, except that you
can stop the event loop at any time. The other choice,
run_until_complete, requires that you already know when you want to
stop when you call it. Another way of looking at it, run_forever is
like a while loop and run_until_complete is like a for loop.

So if you know you want to stop the loop at some point, but you don't
know when, what do you do to express your intent?

> and if we came across it in real life, we'd surely question the sanity of
> the developer who wrote it. Why should while loops be any different?
>
>     while True:
>         if not condition: break  # equivalent to GOTO 99
>         block
>     LABEL 99
>
> I understand that *today*, using existing Python syntax, there is
> sometimes no avoiding that (except, possibly, with something worse). I
> get that. But if we had the choice to move the condition into the while
> condition, we ought to take it.

This is a straw man. As I already replied to Chris, this is not the
type of while True I've been arguing for. Obviously in this case the
condition should be moved into the while statement.


From ian.g.kelly at gmail.com  Fri May 11 02:54:56 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Fri, 11 May 2018 00:54:56 -0600
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <pd3alm$uno$2@blaine.gmane.org>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net>
 <87fu2z1dkp.fsf@nightsong.com> <87sh6z86po.fsf@elektro.pacujo.net>
 <pd3alm$uno$2@blaine.gmane.org>
Message-ID: <CALwzidn5=jiFXT78n3Z0GFroEWUWHrNNeMsVHozXzEsffJ1n7w@mail.gmail.com>

On Thu, May 10, 2018 at 11:45 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> To be honest, I'm having trouble thinking of a good use-case for "while
> True", now that we have infinite iterators. Most cases of
>
>     while True:
>         x = get_item()
>         if not x: break
>         process(x)
>
> are better written as:
>
>     for x in iterator:
>         process(x)

x = get_item()
while True:
    x = process(x)


From charmingoldgit at gmail.com  Fri May 11 02:57:12 2018
From: charmingoldgit at gmail.com (Cuthbert Milligen)
Date: Thu, 10 May 2018 23:57:12 -0700 (PDT)
Subject: Is this a bug or a feature in TkInter?
In-Reply-To: <c389e020-d33e-4dc5-8a2a-491f3e0955b0@googlegroups.com>
References: <c389e020-d33e-4dc5-8a2a-491f3e0955b0@googlegroups.com>
Message-ID: <8d543d15-b289-40b5-a86d-b92cae8d94d4@googlegroups.com>

Hi Terry,

many thanks for your detailed explanation!

(I can't see how to 'reply' under your post...)


From charmingoldgit at gmail.com  Fri May 11 02:58:10 2018
From: charmingoldgit at gmail.com (Cuthbert Milligen)
Date: Thu, 10 May 2018 23:58:10 -0700 (PDT)
Subject: Is this a bug or a feature in TkInter?
In-Reply-To: <mailman.90.1525980221.28519.python-list@python.org>
References: <c389e020-d33e-4dc5-8a2a-491f3e0955b0@googlegroups.com>
 <pd263h$uu0$1@blaine.gmane.org>
 <mailman.90.1525980221.28519.python-list@python.org>
Message-ID: <04e21737-79bc-45a4-98cd-41ded513e5cf@googlegroups.com>

Found it!

Thanks again :-)


From rosuav at gmail.com  Fri May 11 03:01:57 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 11 May 2018 17:01:57 +1000
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <CALwzidk424PzRwWoD3qWU=Yo4=pc9pRMv9NRpMZtgrscG0E4Lg@mail.gmail.com>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net>
 <CAPTjJmqMpUUzKJmomk3Ypms3_k8Cp0eOrDmNEKigQLQfjyzGdQ@mail.gmail.com>
 <mailman.92.1525982855.28519.python-list@python.org>
 <87wowb86sz.fsf@elektro.pacujo.net>
 <CAPTjJmpf+HCK-k8St_HK01FYFYac5xUZBB0vq6rLOpJWRrHzHw@mail.gmail.com>
 <mailman.95.1525998102.28519.python-list@python.org>
 <87k1sb8262.fsf@elektro.pacujo.net>
 <CAPTjJmq7pF-qg_t_ioEHX6rDHAn0zF7Pqc43eiDHfQWEsiJwAQ@mail.gmail.com>
 <CALwzidk424PzRwWoD3qWU=Yo4=pc9pRMv9NRpMZtgrscG0E4Lg@mail.gmail.com>
Message-ID: <CAPTjJmpVWJpQW_N5KZPgpvN=KaOEF1Kk4BHtKt=ht+WVYP4EAA@mail.gmail.com>

On Fri, May 11, 2018 at 12:38 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> Would you also contend that generator functions are wrong because they
> pretend to be normal functions?
>
> def totally_not_a_generator(n):
>     while True:
>         if n % 2 == 0:
>             n //= 2
>         else:
>             n = n * 3 + 1
>         stealthily = n
>         yield stealthily
>         if n == 1:
>             return n
>
> py> print(totally_not_a_generator(42))  # Lies!
> <generator object totally_not_a_generator at 0x77fe4d78c0f8>

Let's see. It's created with 'def'. It can be called by putting
parentheses after its name. Inside the parentheses, you can give it
parameters. When called, it returns a value. Hmm. Sure looks like a
function to me.

Tell me, which of these are functions and which are not?

def tnag5():
    return totally_not_a_generator(5)

def tnag(n):
    return iter(totally_not_a_generator(n))

def ILY():
    return iter([1, 2, 3]) # your heart starts beating

async def what_about_me():
    await spam()
    return 42

def digits_to_number(text):
    return int(text, 10)

class run_command:
    """Compatibility shim for older API"""
    def __init__(self, *args):
        proc = subprocess.run(*args, stdout=subprocess.PIPE)
        self.rc = proc.returncode
        self.output = proc.output

def run_command(*args):
    proc = subprocess.run(*args, stdout=subprocess.PIPE)
    return {"rc": proc.returncode, "output": proc.output}


The only one that inspect.isfunction() returns False for is the class,
and even that is a very function-like class. Every one of these is
callable and will return a useful value. Their headers announce one of
three things:

1) "I am a function" ==> def name(...):
2) "I am a factory for objects of my own type" ==> class name:
3) "I am a coroutine function" ==> async def name(...):

Not one of them is lying. And nor is your totally_not_a_generator. As
Steven said, it's a function, and it returns a value. That's not
materially different from ILY() in my example - it returns something
which you can iterate over.

ChrisA


From ian.g.kelly at gmail.com  Fri May 11 03:02:10 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Fri, 11 May 2018 01:02:10 -0600
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <pd3bn6$uno$4@blaine.gmane.org>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net>
 <CAPTjJmqMpUUzKJmomk3Ypms3_k8Cp0eOrDmNEKigQLQfjyzGdQ@mail.gmail.com>
 <mailman.92.1525982855.28519.python-list@python.org>
 <87wowb86sz.fsf@elektro.pacujo.net>
 <CAPTjJmpf+HCK-k8St_HK01FYFYac5xUZBB0vq6rLOpJWRrHzHw@mail.gmail.com>
 <mailman.95.1525998102.28519.python-list@python.org>
 <87k1sb8262.fsf@elektro.pacujo.net>
 <CAPTjJmq7pF-qg_t_ioEHX6rDHAn0zF7Pqc43eiDHfQWEsiJwAQ@mail.gmail.com>
 <CALwzidk424PzRwWoD3qWU=Yo4=pc9pRMv9NRpMZtgrscG0E4Lg@mail.gmail.com>
 <pd3bn6$uno$4@blaine.gmane.org>
Message-ID: <CALwzidm0DfTdyKy9LjxfT9exV8NY=4aJ173wmq_Lw8qj97mKqw@mail.gmail.com>

On Fri, May 11, 2018 at 12:03 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Thu, 10 May 2018 20:38:39 -0600, Ian Kelly wrote:
>
>> Would you also contend that generator functions are wrong because they
>> pretend to be normal functions?
>
> You're going to need to be more specific. In what way are they not normal
> functions? You call them like normal functions, providing arguments like
> normal functions, and receiving a result just like normal functions.

The way that they execute is not like a normal function. If you call
one, having read the code but having failed to notice the 'yield', you
will be confused by the result.

Likewise, if you run a while True loop (or *any* loop, really), having
read the code but failed to notice the 'break', you will be confused
by the result.

The point being that you cannot necessarily infer what a while loop
will do just by reading the loop condition, any more than you can know
what a function call will return if all you've read are the name and
the signature.

> If you call a function like iter(), you also get back an iterator, just
> as you do when you call a generator. Is iter() not a normal function?

Presumably somebody experienced with Python will already know what
iter does without needing to read the code.

>> def totally_not_a_generator(n):
>>     while True:
>>         if n % 2 == 0:
>>             n //= 2
>>         else:
>>             n = n * 3 + 1
>>         stealthily = n
>>         yield stealthily
>>         if n == 1:
>>             return n
>
> I must admit, I'm a little perplexed. In what way is this totally not a
> generator? (To be precise, a generator function.) The inspect module
> thinks it is (and so do I):

The example was tongue-in-cheek. As suggested by the comment in the
part that you cut out where I called it, the code is lying.


From rosuav at gmail.com  Fri May 11 03:06:42 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 11 May 2018 17:06:42 +1000
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <CALwzidn5=jiFXT78n3Z0GFroEWUWHrNNeMsVHozXzEsffJ1n7w@mail.gmail.com>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net>
 <87fu2z1dkp.fsf@nightsong.com> <87sh6z86po.fsf@elektro.pacujo.net>
 <pd3alm$uno$2@blaine.gmane.org>
 <CALwzidn5=jiFXT78n3Z0GFroEWUWHrNNeMsVHozXzEsffJ1n7w@mail.gmail.com>
Message-ID: <CAPTjJmpd_1JHrGJdGLidcF99b=R7sRn2OrvTzCRdP9wxdtqAtA@mail.gmail.com>

On Fri, May 11, 2018 at 4:54 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Thu, May 10, 2018 at 11:45 PM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> To be honest, I'm having trouble thinking of a good use-case for "while
>> True", now that we have infinite iterators. Most cases of
>>
>>     while True:
>>         x = get_item()
>>         if not x: break
>>         process(x)
>>
>> are better written as:
>>
>>     for x in iterator:
>>         process(x)
>
> x = get_item()
> while True:
>     x = process(x)

More likely:

x = get_item()
while x:
    process(x)
    x = get_item()

which (a) repeats the call to get_item, (b) doesn't support the
'continue' statement, and (c) hides crucial loop iteration information
at the BOTTOM of the loop.

But to make this iterator, you need to separate the while loop's
header from its body. Compare:

while x := get_item():
    process(x)


def get_items():
    while True:
        x = get_item()
        if not x: return
        yield x

for x in get_items():
    process(x)

It hasn't actually gotten rid of the fib of the infinite loop; all
it's done is wrap it up in a function. Yes, that can be of value; but
adding another level of indirection doesn't solve a problem, it just
moves it around.

ChrisA


From rosuav at gmail.com  Fri May 11 03:11:19 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 11 May 2018 17:11:19 +1000
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <CA+HdcZjR=twKaHn-dZ2f2d3bW0H8F4i3D6eN32LnOgfmCtCb-A@mail.gmail.com>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <87o9hn82e9.fsf@elektro.pacujo.net> <kS5JC.258835$sl2.255712@fx46.am4>
 <201805102136.26478.gheskett@shentel.net>
 <CA+HdcZjR=twKaHn-dZ2f2d3bW0H8F4i3D6eN32LnOgfmCtCb-A@mail.gmail.com>
Message-ID: <CAPTjJmqFP4zF-g3op4Z7UdOqyToKdezojYUo--2gTJqtEbhumQ@mail.gmail.com>

On Fri, May 11, 2018 at 12:04 PM, Bob van der Poel <bob at mellowood.ca> wrote:
> I agree with my freind Gene! And, if it is really necessary to retain
> octal, why not preface it with anything BUT a "0". I've been hit by this a
> few times in the past. I used lots of hex over the years, but don't recall
> ever using octal ... except in frustrating moments when I needed to change
> permission bits.

Because if it doesn't start with a 0, it won't look like a number. You
could use &H1A2B for hex (I can't remember what the octal equivalent
was), which consumes the ampersand as a syntactic character; or you
could put a trailing adornment 1A2Bh, which looks like an identifier
if the number starts with a letter. Much cleaner to make the marker
"this is octal" or "this is hex" start with a zero, making it very
clearly a number from the start.

ChrisA


From rosuav at gmail.com  Fri May 11 03:15:26 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 11 May 2018 17:15:26 +1000
Subject: Suggestion for a "data" object syntax
In-Reply-To: <CALwzidnf+djaR+hQsBffM1netC_wmiq_p6rdm05wmM7dbx=KFA@mail.gmail.com>
References: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
 <CALwzidnf+djaR+hQsBffM1netC_wmiq_p6rdm05wmM7dbx=KFA@mail.gmail.com>
Message-ID: <CAPTjJmoTsxqt88GgVZWt3UXpTOvqBOCE2FH1a+-e7L2+izyOwQ@mail.gmail.com>

On Fri, May 11, 2018 at 4:39 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Mon, May 7, 2018 at 9:45 PM, Mikhail V <mikhailwas at gmail.com> wrote:
>> Benefits are easy to see: say I want a tuple of strings:
>>
>> data === T :
>>     "foo bar"
>>     "hello world"
>>     "to be continued..."
>>
>> VS current:
>>
>> data = (
>>     "foo bar" ,
>>     "hello world" ,
>>     "to be continued..." ,
>>     )
>>
>> Main problem with the latter are commas, it is not easy
>> to type
>
> In what bizarro world are commas harder to type than tabs? At least if
> I type a comma I know I'll get a comma. If I type a tab then it
> depends on my editor settings what I'll actually get.

In Mikhail's defense, this is a reasonably elegant solution to the
age-old problem of "I forgot a comma, now two of my entries got joined
implicitly". It automatically makes multiple entries, and if you WANT
joined entries, you would have to request that explicitly with the +
operator or a line continuation backslash. Oh wait, these things
aren't actual expressions, so you probably can't do either of those
things... hmm.

ChrisA


From tjreedy at udel.edu  Fri May 11 04:02:47 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 11 May 2018 04:02:47 -0400
Subject: Is this a bug or a feature in TkInter?
In-Reply-To: <8d543d15-b289-40b5-a86d-b92cae8d94d4@googlegroups.com>
References: <c389e020-d33e-4dc5-8a2a-491f3e0955b0@googlegroups.com>
 <8d543d15-b289-40b5-a86d-b92cae8d94d4@googlegroups.com>
Message-ID: <pd3ij4$sn$1@blaine.gmane.org>

On 5/11/2018 2:57 AM, Cuthbert Milligen wrote:
> Hi Terry,
> 
> many thanks for your detailed explanation!
> 
> (I can't see how to 'reply' under your post...)

Followup to the list rather than reply to me, as you did, is the right 
thing to do.


-- 
Terry Jan Reedy



From greg.ewing at canterbury.ac.nz  Fri May 11 04:28:40 2018
From: greg.ewing at canterbury.ac.nz (Gregory Ewing)
Date: Fri, 11 May 2018 20:28:40 +1200
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <87fu309bjw.fsf@elektro.pacujo.net>
References: <20180507202722.GD7876@tauhou>
 <pcqrv9$16m$12@blaine.gmane.org>	<20180509034852.GB12850@bladeshadow.org>	<pcu1so$qbi$2@blaine.gmane.org>	<mailman.62.1525844855.28519.python-list@python.org>	<Q0KIC.79619$jb7.24372@fx34.am4>
 <87fu309bjw.fsf@elektro.pacujo.net>
Message-ID: <fll2hoF29i9U1@mid.individual.net>

Marko Rauhamaa wrote:
> I was mildly amused when Python happily executed such code. "..." is a
> valid expression and thus, a valid statement.

Fortunately, "?" still works for this!

-- 
Greg


From greg.ewing at canterbury.ac.nz  Fri May 11 05:10:08 2018
From: greg.ewing at canterbury.ac.nz (Gregory Ewing)
Date: Fri, 11 May 2018 21:10:08 +1200
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <mailman.109.1526016021.28519.python-list@python.org>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net>
 <CAPTjJmqMpUUzKJmomk3Ypms3_k8Cp0eOrDmNEKigQLQfjyzGdQ@mail.gmail.com>
 <mailman.92.1525982855.28519.python-list@python.org>
 <87wowb86sz.fsf@elektro.pacujo.net>
 <CAPTjJmpf+HCK-k8St_HK01FYFYac5xUZBB0vq6rLOpJWRrHzHw@mail.gmail.com>
 <mailman.95.1525998102.28519.python-list@python.org>
 <87k1sb8262.fsf@elektro.pacujo.net> <pd3926$uno$1@blaine.gmane.org>
 <mailman.109.1526016021.28519.python-list@python.org>
Message-ID: <fll4vgF2pmtU1@mid.individual.net>

I suggest adding a new builtin constant:

    YouFeelLikeIt = True

Then all pseudo-infinite loops can be written

    while YouFeelLikeIt:
       ...

-- 
Greg


From greg.ewing at canterbury.ac.nz  Fri May 11 05:28:41 2018
From: greg.ewing at canterbury.ac.nz (Gregory Ewing)
Date: Fri, 11 May 2018 21:28:41 +1200
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <kO1JC.224737$Cd3.58445@fx33.am4>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CALwzidn6qiie4oz3CmysS6D-AtUoF2h215VJODDUL9L89pygNg@mail.gmail.com>
 <mailman.81.1525971876.28519.python-list@python.org>
 <Td0JC.111049$Vs7.22268@fx41.am4>
 <CAPTjJmqwODUPKnHu5k8qwUU6N7R2XR9aAE1m6-D5GCgYZcsNOg@mail.gmail.com>
 <mailman.87.1525978297.28519.python-list@python.org>
 <kO1JC.224737$Cd3.58445@fx33.am4>
Message-ID: <fll62bF350sU1@mid.individual.net>

> On 10/05/2018 19:51, Chris Angelico wrote:

>> YAGNI much? How often do you need a base-9 literal in your code??

You've obviously never programmed a Setun ternary computer:

https://en.wikipedia.org/wiki/Setun

-- 
Greg


From greg.ewing at canterbury.ac.nz  Fri May 11 05:40:23 2018
From: greg.ewing at canterbury.ac.nz (Gregory Ewing)
Date: Fri, 11 May 2018 21:40:23 +1200
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <mailman.94.1525997497.28519.python-list@python.org>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>
 <mailman.84.1525976408.28519.python-list@python.org>
 <2W3JC.64439$7b4.11219@fx12.am4>
 <CAPTjJmr+t3ivSpTqiGmD3DBJo8dba+5sriMffYRsdfVC+yRpSg@mail.gmail.com>
 <mailman.94.1525997497.28519.python-list@python.org>
Message-ID: <fll6o9F39u5U1@mid.individual.net>

Chris Angelico wrote:
> Octal makes a lot of sense in the right contexts. Allowing octal
> literals is a Good Thing. And sticking letters into the middle of a
> number doesn't make that much sense, so the leading-zero notation is a
> decent choice.

Also it's easy to forget that octal was a big part of the
PDP-11 culture back then, even though it didn't fit all that
well with a byte-oriented machine, largely due to earlier
PDP models having multiple-of-3 word sizes. Programmers
of that era probably dealt with octal numbers more often
than either hex or decimal.

-- 
Greg


From rosuav at gmail.com  Fri May 11 05:44:08 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 11 May 2018 19:44:08 +1000
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <fll4vgF2pmtU1@mid.individual.net>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net>
 <CAPTjJmqMpUUzKJmomk3Ypms3_k8Cp0eOrDmNEKigQLQfjyzGdQ@mail.gmail.com>
 <mailman.92.1525982855.28519.python-list@python.org>
 <87wowb86sz.fsf@elektro.pacujo.net>
 <CAPTjJmpf+HCK-k8St_HK01FYFYac5xUZBB0vq6rLOpJWRrHzHw@mail.gmail.com>
 <mailman.95.1525998102.28519.python-list@python.org>
 <87k1sb8262.fsf@elektro.pacujo.net> <pd3926$uno$1@blaine.gmane.org>
 <mailman.109.1526016021.28519.python-list@python.org>
 <fll4vgF2pmtU1@mid.individual.net>
Message-ID: <CAPTjJmqjBpJYUvO9tSt4439L+wmDeFfFXpDKUeL887js=o5u3g@mail.gmail.com>

On Fri, May 11, 2018 at 7:10 PM, Gregory Ewing
<greg.ewing at canterbury.ac.nz> wrote:
> I suggest adding a new builtin constant:
>
>    YouFeelLikeIt = True
>
> Then all pseudo-infinite loops can be written
>
>    while YouFeelLikeIt:
>       ...
>

Personally, I prefer to use string literals.

while "you feel like it":
    ...

Which, in a non-joking context, tends to look like this:

while "moar data":
    data = get_data()
    process_data(data)

ChrisA


From greg.ewing at canterbury.ac.nz  Fri May 11 05:55:17 2018
From: greg.ewing at canterbury.ac.nz (Gregory Ewing)
Date: Fri, 11 May 2018 21:55:17 +1200
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <87o9hn82e9.fsf@elektro.pacujo.net>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>	<CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>	<mailman.73.1525951709.28519.python-list@python.org>	<dy_IC.301544$gE6.154866@fx06.am4>	<CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>	<mailman.84.1525976408.28519.python-list@python.org>	<2W3JC.64439$7b4.11219@fx12.am4>	<CAPTjJmr+t3ivSpTqiGmD3DBJo8dba+5sriMffYRsdfVC+yRpSg@mail.gmail.com>	<mailman.94.1525997497.28519.python-list@python.org>
 <87o9hn82e9.fsf@elektro.pacujo.net>
Message-ID: <fll7k7F3fvrU1@mid.individual.net>

Marko Rauhamaa wrote:
> I think octal is a historical relic from a time when people weren't yet
> comfortable with hexadecimal.

Octal made perfect sense for all PDP models up to the
PDP-10, which had word sizes that were a multiple of
3 bits.

It still partly made sense for the PDP-11, because its
instruction encoding fitted well with octal.

Hex came into vogue in the DEC world with the VAX,
which was both byte-addressed and had a hex-oriented
instruction encoding.

-- 
Greg


From greg.ewing at canterbury.ac.nz  Fri May 11 06:08:50 2018
From: greg.ewing at canterbury.ac.nz (Gregory Ewing)
Date: Fri, 11 May 2018 22:08:50 +1200
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <mailman.101.1526004454.28519.python-list@python.org>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <87o9hn82e9.fsf@elektro.pacujo.net> <kS5JC.258835$sl2.255712@fx46.am4>
 <201805102136.26478.gheskett@shentel.net>
 <CAPTjJmoBT+Ra0f5km3U89S0s1FLOS1FBynHnRnigZkKROnTG2A@mail.gmail.com>
 <mailman.101.1526004454.28519.python-list@python.org>
Message-ID: <fll8diF3k4vU1@mid.individual.net>

Chris Angelico wrote:
> What do you mean, "another bit"? Currently, the chmod command on my
> system can manage nine primary bits (rwx for each of ugo), plus
> setuid, setgid, and sticky.

I think the idea is that you could regroup those 4 groups
of 3 into 3 groups of 4, and get a nice mapping to hex.
If hex had been the conventional way of writing binary numbers
back then, Ken and Dennis would probably have done it that
way.

Changing it now would require some fairly intimate surgery
on unix, however, which is somewhat beyond the scope of
what Python can achieve.

-- 
Greg


From greg.ewing at canterbury.ac.nz  Fri May 11 06:12:24 2018
From: greg.ewing at canterbury.ac.nz (Gregory Ewing)
Date: Fri, 11 May 2018 22:12:24 +1200
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <mailman.107.1526009237.28519.python-list@python.org>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CALwzidn6qiie4oz3CmysS6D-AtUoF2h215VJODDUL9L89pygNg@mail.gmail.com>
 <pd3276$qbi$6@blaine.gmane.org>
 <mailman.107.1526009237.28519.python-list@python.org>
Message-ID: <fll8kaF3nd0U1@mid.individual.net>

Steven D'Aprano wrote:
> n for binary
> t for octal
> i for trinary
> o for duodecimal
> 
> and of course, x for hexadecimal.

And in format strings:

   "c" for decimal
   "a" for char
   "r" for string
   "w" for raw string

Looks fine to me. Who wants to write the PEP?

-- 
Greg


From greg.ewing at canterbury.ac.nz  Fri May 11 06:21:48 2018
From: greg.ewing at canterbury.ac.nz (Gregory Ewing)
Date: Fri, 11 May 2018 22:21:48 +1200
Subject: Meaning of abbreviated terms
In-Reply-To: <mailman.118.1526020227.28519.python-list@python.org>
References: <4f2a7e16-1b4d-4852-bc56-2d0b07c72209@googlegroups.com>
 <8b5577d8-a5d3-4fd5-8975-9a45e0327162@googlegroups.com>
 <flkr1kF1jgU1@mid.individual.net> <pd3d5m$uno$6@blaine.gmane.org>
 <mailman.118.1526020227.28519.python-list@python.org>
Message-ID: <fll95uF3rbvU1@mid.individual.net>

Steven D'Aprano wrote:
> But that's not where plists came from, was it? As I understand it, the 
> plist data format was invented by Apple, and they called it a property 
> list.

The term "property list" can also refer to a data structure in Lisp:

https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node108.html

This has very little to do with Apple's use of the term, though.

-- 
Greg


From jon+usenet at unequivocal.eu  Fri May 11 06:36:54 2018
From: jon+usenet at unequivocal.eu (Jon Ribbens)
Date: Fri, 11 May 2018 10:36:54 -0000 (UTC)
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>
 <mailman.84.1525976408.28519.python-list@python.org>
 <slrnpf95uq.258.jon+usenet@sable.unequivocal.eu>
 <CAPTjJmqcma9bQ9FeXJx+-XJ8e6PtKN69hwte-r0UBydygWPn6g@mail.gmail.com>
 <mailman.88.1525979842.28519.python-list@python.org>
Message-ID: <slrnpfasi6.258.jon+usenet@sable.unequivocal.eu>

On 2018-05-10, Chris Angelico <rosuav at gmail.com> wrote:
> On Fri, May 11, 2018 at 5:04 AM, Jon Ribbens <jon+usenet at unequivocal.eu> wrote:
>> This whole thread is reminding me PHP 2, which would magically treat
>> the second parameter of ChMod() as octal, because clearly if weak
>> typing is good then *no* typing must be best of all!
>>
>>   ChMod($filename, 644); // second parameter is actually 420 base 10
>
> Bear in mind that Unix file modes are traditionally written in octal,
> because they have no meaning as numbers. They're more like
> enumerations, or bitfields. The second parameter happens to be equal
> to the base 10 number 420, but that's completely useless. A file mode
> of 100644 means something; a file mode of 0x81a4 or 33188 decimal
> means nothing. PHP went for crazy magic there, but if the API had been
> built such that the "644" is passed as a string, it would have been
> completely sane and entirely useful.

Or indeed if it was passed as 0644 or 0o644 as an octal literal.
The issue is not *why* Rasmus did this - that's obvious - the issue is
that he didn't know why he *shouldn't* make a language where 1234 is a
decimal integer literal except sometimes it isn't. The PHP manual even
recommended that you write the second parameter as 0644 to "remind you"
that it was treated as octal, although the leading 0 made no actual
semantic difference to the way the code was parsed by the language.


From steve+comp.lang.python at pearwood.info  Fri May 11 06:56:40 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 11 May 2018 10:56:40 +0000 (UTC)
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>
 <mailman.84.1525976408.28519.python-list@python.org>
 <2W3JC.64439$7b4.11219@fx12.am4>
 <CAPTjJmr+t3ivSpTqiGmD3DBJo8dba+5sriMffYRsdfVC+yRpSg@mail.gmail.com>
 <mailman.94.1525997497.28519.python-list@python.org>
 <87o9hn82e9.fsf@elektro.pacujo.net> <fll7k7F3fvrU1@mid.individual.net>
Message-ID: <pd3st7$uno$7@blaine.gmane.org>

On Fri, 11 May 2018 21:55:17 +1200, Gregory Ewing wrote:

> Hex came into vogue in the DEC world with the VAX, which was both
> byte-addressed and had a hex-oriented instruction encoding.


Indeed. In 2018 when nearly all computers (aside from some DSPs) have 
standardised on the same number of bits, it is hard to remember that in 
Ancient Days there was damn little standardisation of computers. You had 
computers with 6, 9, or even 60 bits per byte, machines that used BCD in 
preference to binary ints, and even a few Russian-made computers that 
didn't use binary at all, but ternary.

I'm also told that some of those computers didn't run Windows.

*wink*



-- 
Steve



From bc at freeuk.com  Fri May 11 07:09:49 2018
From: bc at freeuk.com (bartc)
Date: Fri, 11 May 2018 12:09:49 +0100
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <mailman.94.1525997497.28519.python-list@python.org>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>
 <mailman.84.1525976408.28519.python-list@python.org>
 <2W3JC.64439$7b4.11219@fx12.am4>
 <CAPTjJmr+t3ivSpTqiGmD3DBJo8dba+5sriMffYRsdfVC+yRpSg@mail.gmail.com>
 <mailman.94.1525997497.28519.python-list@python.org>
Message-ID: <NReJC.131905$I77.15095@fx44.am4>

On 11/05/2018 01:11, Chris Angelico wrote:
> On Fri, May 11, 2018 at 8:43 AM, bartc <bc at freeuk.com> wrote:
>> This is Wrong, and would have been just as obviously wrong in 1989.
> 
> Having spent many years programming in C and working on Unix, I
> strongly disagree.

Using C is apt to give you a rather warped view of things. Such that 
everything in that language is superior to any other way of doing it.

(And actually, because C didn't have binary literals for a long time (I 
think it still doesn't, officially), there has been a lot of discussion 
in comp.lang.c about how they are not really necessary:

: A real programmer can auto-convert from hex
: It's so easy to knock up some macro that will do it
: They have /never/ needed binary in decades of programming

And so on. Meanwhile my own /recent/ code includes lines like this:

     when 2x'101'11010'000 then ... # (x64/x87 disassembler)

although I think I still prefer a trailing B, with separator:

     when 101'11010'000'B then ...

Try /that/ in hex /or/ octal.)

> This was *not* obviously wrong. It's easy to say
> "but look at the real world"; but in the 80s and 90s, nobody would
> have said that it was "obviously wrong" to have the native integer
> wrap when it goes past a certain number of bits. And in fact, your
> description of the real world makes it equally obvious that numbers
> should have a fixed width:

Much of the real world /does/ use fixed widths for numbers, like that 
odometer for a start, or most mechanical or electronic devices that need 
to display numbers. And with many such devices, they wrap as well 
(remember tape counters).

Even my tax return has a limit on how big a sum I can enter in the boxes 
on the paper form.

So the concept of fixed upper width, sometimes modulo numbers isn't 
alien to the general public. But leading zeros that completely change 
the perceived value of a number IS.

> Octal makes a lot of sense in the right contexts. Allowing octal
> literals is a Good Thing. And sticking letters into the middle of a
> number doesn't make that much sense, so the leading-zero notation is a
> decent choice.

No it isn't. You need something that is much more explicit. I know your 
C loyalty is showing here, but just admit it was a terrible choice in 
that language, even in 1972. And just as bad in 1989.

(I've used one language where the default base (radix it called it) was 
octal. But even there, when overriding it, the override mechanism was 
more obvious than the presence of a leading zero.)

  It's all very well to argue that it's a suboptimal
> choice; but you have to remember that you're arguing that point from
> 2018, and we have about thirty years of experience using Python. The
> choice was most definitely not fundamentally wrong. Ten years ago, the
> point was revisited, and a different choice made. That's all.

This gives a few different ways of writing hex and octal:

   https://rosettacode.org/wiki/Literals/Integer

The leading zero method for octal seems to have permeated a few other 
languages. While F#, among others, uses 0o, which in my browser looks 
like Oo12. (If, for some reason, you did want leading zeros, then the 
number would look like OoO12.)

Why do language designers perpetuate bad ideas? The reason for designing 
a new language is just so you can get rid of some of them!

-- 
bartc




From bc at freeuk.com  Fri May 11 07:32:24 2018
From: bc at freeuk.com (bartc)
Date: Fri, 11 May 2018 12:32:24 +0100
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <kO1JC.224737$Cd3.58445@fx33.am4>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CALwzidn6qiie4oz3CmysS6D-AtUoF2h215VJODDUL9L89pygNg@mail.gmail.com>
 <mailman.81.1525971876.28519.python-list@python.org>
 <Td0JC.111049$Vs7.22268@fx41.am4>
 <CAPTjJmqwODUPKnHu5k8qwUU6N7R2XR9aAE1m6-D5GCgYZcsNOg@mail.gmail.com>
 <mailman.87.1525978297.28519.python-list@python.org>
 <kO1JC.224737$Cd3.58445@fx33.am4>
Message-ID: <XafJC.207558$B36.200659@fx22.am4>

On 10/05/2018 21:18, bartc wrote:
> On 10/05/2018 19:51, Chris Angelico wrote:
>> On Fri, May 11, 2018 at 4:31 AM, bartc <bc at freeuk.com> wrote:
>>> ?? 2x100? (4)?? Binary
>>> ?? 3x100? (9)?? Ternary
>>> ?? 4x100? (16)? Quaternary
>>> ?? 5x100? (25)? etc
>>> ?? 6x100? (36)
>>> ?? 7x100? (49)
>>> ?? 8x100? (64)? Octal
>>> ?? 9x100? (81)
>>> ?? ...?????????? (Not implemented 11x to 15x, nor 10x or 16x)
>>> ?? 0x100? (256) Hex
>>
>> YAGNI much? How often do you need a base-9 literal in your code??

I've just found out these also work for floating point. So that:

   a := 8x100.5
   print a

gives 64.625 in decimal (not 64.5 as I expected, because .5 is 5/8 not 
5/10!). Exponent values are octal too, scaling by powers of 8.

I tried it in Python 3 (0o100.5 - I find that prefix fiddly to type 
actually as I have to stop and think), and it seems to be illegal.

Based floating point literals may be unusual, but bear in mind that in 
decimal, some values may not be represented exactly (eg 0.1). I believe 
that in base 2, 4, 8 or 16, any floating point literal can be 
represented exactly, at least up the precision available.


-- 
bartc




From mal at europython.eu  Fri May 11 07:56:30 2018
From: mal at europython.eu (M.-A. Lemburg)
Date: Fri, 11 May 2018 13:56:30 +0200
Subject: EuroPython 2018: Please reset your password
Message-ID: <4dad2f95-a915-c7ae-45e4-8e6ccfbfb157@europython.eu>

Regular password resets are always a good thing to do, but this time
we have a specific reason to ask you to consider taking the extra
time.

In December 2017, our ISP detected port scans originating from our
server and informed us about these. During the analysis, we found that
someone (or better: some script) had found a way to break-in to our
web server running the EuroPython website. We quickly fixed the
situation, reset all authorizations and put measures in place to
strictly limit the number of people having access to the server to a
minimum and better secure the server against future break-in attempts.

The server was only used as SSH port scanning relay and we found no
evidence of loss or leakage of data. We don?t believe that any of your
personal information got into the wrong hands, but even though the
passwords are stored using secure and salted hashes (using PBKDF2), we
still recommend to reset your password to be on the safe side.

We know that this notice is late and we?d like to apologize for the
hassle caused by this.

If you have just created a new account on the
https://ep2018.europython.eu/ website we just launched, no further
action is necessary.

We only recommend the password reset if you have had an account with
us in previous years and this account is active on the new
https://ep2018.europython.eu/ website. Logins on the older versions of
our website are disabled for regular users, so no action is necessary
on these.

Please see our blog post for instructions on how to reset your password:

https://blog.europython.eu/post/173793513217/europython-2018-please-reset-your-password


Enjoy,
--
EuroPython 2018 Team
https://ep2018.europython.eu/
https://www.europython-society.org/


PS: Please forward or retweet to help us reach all interested parties:
https://twitter.com/europython/status/994879080263831552
Thanks.



From ben.usenet at bsb.me.uk  Fri May 11 08:23:21 2018
From: ben.usenet at bsb.me.uk (Ben Bacarisse)
Date: Fri, 11 May 2018 13:23:21 +0100
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>
 <mailman.84.1525976408.28519.python-list@python.org>
 <2W3JC.64439$7b4.11219@fx12.am4>
 <CAPTjJmr+t3ivSpTqiGmD3DBJo8dba+5sriMffYRsdfVC+yRpSg@mail.gmail.com>
 <mailman.94.1525997497.28519.python-list@python.org>
 <87o9hn82e9.fsf@elektro.pacujo.net> <kS5JC.258835$sl2.255712@fx46.am4>
Message-ID: <87vabunzye.fsf@bsb.me.uk>

bartc <bc at freeuk.com> writes:

> On 11/05/2018 01:25, Marko Rauhamaa wrote:
>> Chris Angelico <rosuav at gmail.com>:
>>
>>> Octal makes a lot of sense in the right contexts.
>>
>> I think octal is a historical relic from a time when people weren't yet
>> comfortable with hexadecimal.
>
> It's a relic from when machines had word sizes that were multiples of
> three bits, or were divided up on 3-bit boundaries.

It got into C via B and B was often used on machine with a word size
that was a multiple of three.  But octal was very useful on 16-bit
PDP-11s which is probably why it was kept.  The PDP-11 has 8 registers
and uses 3 bits to specify the addressing mode and many instructions use
the top bit to indicate a variation such as word or byte operation.  The
result is that you'd never choose to use hex to look at PDP-11 code.
That familiarity with octal must have played a bit part in deciding to
include it in C.

-- 
Ben.


From marko at pacujo.net  Fri May 11 08:34:18 2018
From: marko at pacujo.net (Marko Rauhamaa)
Date: Fri, 11 May 2018 15:34:18 +0300
Subject: seeking deeper (language theory) reason behind Python design
 choice
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net>
 <CAPTjJmqMpUUzKJmomk3Ypms3_k8Cp0eOrDmNEKigQLQfjyzGdQ@mail.gmail.com>
 <mailman.92.1525982855.28519.python-list@python.org>
 <87wowb86sz.fsf@elektro.pacujo.net>
 <CAPTjJmpf+HCK-k8St_HK01FYFYac5xUZBB0vq6rLOpJWRrHzHw@mail.gmail.com>
 <mailman.95.1525998102.28519.python-list@python.org>
 <87k1sb8262.fsf@elektro.pacujo.net> <pd3926$uno$1@blaine.gmane.org>
 <mailman.109.1526016021.28519.python-list@python.org>
 <fll4vgF2pmtU1@mid.individual.net>
 <CAPTjJmqjBpJYUvO9tSt4439L+wmDeFfFXpDKUeL887js=o5u3g@mail.gmail.com>
 <mailman.129.1526031851.28519.python-list@python.org>
Message-ID: <87603u8j79.fsf@elektro.pacujo.net>

Chris Angelico <rosuav at gmail.com>:

> On Fri, May 11, 2018 at 7:10 PM, Gregory Ewing
> <greg.ewing at canterbury.ac.nz> wrote:
>> I suggest adding a new builtin constant:
>>
>>    YouFeelLikeIt = True
>>
>> Then all pseudo-infinite loops can be written
>>
>>    while YouFeelLikeIt:
>>       ...
>>
>
> Personally, I prefer to use string literals.
>
> while "you feel like it":
>     ...

I still think my use of the Ellipsis speaks more to the maintainer of
the code:

   while ...:
       pass


Marko


From marko at pacujo.net  Fri May 11 08:39:17 2018
From: marko at pacujo.net (Marko Rauhamaa)
Date: Fri, 11 May 2018 15:39:17 +0300
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>
 <mailman.84.1525976408.28519.python-list@python.org>
 <2W3JC.64439$7b4.11219@fx12.am4>
 <CAPTjJmr+t3ivSpTqiGmD3DBJo8dba+5sriMffYRsdfVC+yRpSg@mail.gmail.com>
 <mailman.94.1525997497.28519.python-list@python.org>
 <87o9hn82e9.fsf@elektro.pacujo.net> <kS5JC.258835$sl2.255712@fx46.am4>
 <87vabunzye.fsf@bsb.me.uk>
Message-ID: <871sei8iyy.fsf@elektro.pacujo.net>

Ben Bacarisse <ben.usenet at bsb.me.uk>:
> bartc <bc at freeuk.com> writes:
>> On 11/05/2018 01:25, Marko Rauhamaa wrote:
>>> I think octal is a historical relic from a time when people weren't
>>> yet comfortable with hexadecimal.
>>
>> It's a relic from when machines had word sizes that were multiples of
>> three bits, or were divided up on 3-bit boundaries.
>
> It got into C via B and B was often used on machine with a word size
> that was a multiple of three. But octal was very useful on 16-bit
> PDP-11s which is probably why it was kept. The PDP-11 has 8 registers
> and uses 3 bits to specify the addressing mode and many instructions
> use the top bit to indicate a variation such as word or byte
> operation. The result is that you'd never choose to use hex to look at
> PDP-11 code. That familiarity with octal must have played a bit part
> in deciding to include it in C.

It may have been the other way round: people were comfortable with
octal, which led to seeing three-bit fields everywhere and even
designing CPUs accordingly. Four-bit fields were used for BCD, but I'm
guessing using letters as digits felt awkward among computer people for
a long time.


Marko


From rosuav at gmail.com  Fri May 11 09:14:37 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 11 May 2018 23:14:37 +1000
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <fll8diF3k4vU1@mid.individual.net>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <87o9hn82e9.fsf@elektro.pacujo.net> <kS5JC.258835$sl2.255712@fx46.am4>
 <201805102136.26478.gheskett@shentel.net>
 <CAPTjJmoBT+Ra0f5km3U89S0s1FLOS1FBynHnRnigZkKROnTG2A@mail.gmail.com>
 <mailman.101.1526004454.28519.python-list@python.org>
 <fll8diF3k4vU1@mid.individual.net>
Message-ID: <CAPTjJmoK-kxhH+pE+fnfXg4PQ=kyaytDdgAa__TiCuL=Td0qXg@mail.gmail.com>

On Fri, May 11, 2018 at 8:08 PM, Gregory Ewing
<greg.ewing at canterbury.ac.nz> wrote:
> Chris Angelico wrote:
>>
>> What do you mean, "another bit"? Currently, the chmod command on my
>> system can manage nine primary bits (rwx for each of ugo), plus
>> setuid, setgid, and sticky.
>
>
> I think the idea is that you could regroup those 4 groups
> of 3 into 3 groups of 4, and get a nice mapping to hex.
> If hex had been the conventional way of writing binary numbers
> back then, Ken and Dennis would probably have done it that
> way.

But they aren't "four groups of three" that could be reorganized.
They're three groups of three, plus three separate bits. Each group of
three is the permissions for one category of user (the owner, anyone
in the owning group, or everyone else). If your permission set is 6,
you may read and write, but not execute. If it's 4, you may only read.
5 lets you read and execute. 0 denies everything. What other bit would
you add? Tack setuid onto "owner", setgid onto "group", and sticky
onto "others"? Pretty arbitrary, and disrupts the fundamental meaning
of each set. (Plus, it still ignores the "is-directory" and "is-link"
bits, etc.)

> Changing it now would require some fairly intimate surgery
> on unix, however, which is somewhat beyond the scope of
> what Python can achieve.
>

Yes, and wouldn't improve either Unix or Python.

ChrisA


From rosuav at gmail.com  Fri May 11 09:24:27 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 11 May 2018 23:24:27 +1000
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <NReJC.131905$I77.15095@fx44.am4>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>
 <mailman.84.1525976408.28519.python-list@python.org>
 <2W3JC.64439$7b4.11219@fx12.am4>
 <CAPTjJmr+t3ivSpTqiGmD3DBJo8dba+5sriMffYRsdfVC+yRpSg@mail.gmail.com>
 <mailman.94.1525997497.28519.python-list@python.org>
 <NReJC.131905$I77.15095@fx44.am4>
Message-ID: <CAPTjJmoSuHpYwwR-xV7RkNSM9a-HqnH-qQy0oZXosiQOvK8pOQ@mail.gmail.com>

On Fri, May 11, 2018 at 9:09 PM, bartc <bc at freeuk.com> wrote:
> On 11/05/2018 01:11, Chris Angelico wrote:
>>
>> On Fri, May 11, 2018 at 8:43 AM, bartc <bc at freeuk.com> wrote:
>>>
>>> This is Wrong, and would have been just as obviously wrong in 1989.
>>
>>
>> Having spent many years programming in C and working on Unix, I
>> strongly disagree.
>
>
> Using C is apt to give you a rather warped view of things. Such that
> everything in that language is superior to any other way of doing it.

Obviously, which is why you hear me vehemently arguing against garbage
collection, since in C you have to explicitly free everything up. And
since I've used C and think that everything it does is the best
possible way to do things, I have strongly debated that we should get
rid of strings as first-class objects and just use buffers of
characters, which are kinda just bytes if you squint at them.

> (And actually, because C didn't have binary literals for a long time (I
> think it still doesn't, officially), there has been a lot of discussion in
> comp.lang.c about how they are not really necessary:
>
> : A real programmer can auto-convert from hex
> : It's so easy to knock up some macro that will do it
> : They have /never/ needed binary in decades of programming
>
> And so on. Meanwhile my own /recent/ code includes lines like this:
>
>     when 2x'101'11010'000 then ... # (x64/x87 disassembler)
>
> although I think I still prefer a trailing B, with separator:
>
>     when 101'11010'000'B then ...
>
> Try /that/ in hex /or/ octal.)

I've no idea what this is supposed to mean, or why you have groups of
three, five, and three. Looks like a possible bug to me. I'm sure it
isn't, of course, since you're one of those perfect programmers who
simply doesn't _make_ errors, but if it were my code, I would be
worried that it isn't correct somewhere.

>> This was *not* obviously wrong. It's easy to say
>> "but look at the real world"; but in the 80s and 90s, nobody would
>> have said that it was "obviously wrong" to have the native integer
>> wrap when it goes past a certain number of bits. And in fact, your
>> description of the real world makes it equally obvious that numbers
>> should have a fixed width:
>
>
> Much of the real world /does/ use fixed widths for numbers, like that
> odometer for a start, or most mechanical or electronic devices that need to
> display numbers. And with many such devices, they wrap as well (remember
> tape counters).
>
> Even my tax return has a limit on how big a sum I can enter in the boxes on
> the paper form.
>
> So the concept of fixed upper width, sometimes modulo numbers isn't alien to
> the general public. But leading zeros that completely change the perceived
> value of a number IS.

Cool. So what's the native integer size for the real world? Use that
as your primary data type.

Oh, can't decide how many digits? That's a pity.

>> Octal makes a lot of sense in the right contexts. Allowing octal
>> literals is a Good Thing. And sticking letters into the middle of a
>> number doesn't make that much sense, so the leading-zero notation is a
>> decent choice.
>
> No it isn't. You need something that is much more explicit. I know your C
> loyalty is showing here, but just admit it was a terrible choice in that
> language, even in 1972. And just as bad in 1989.

Go get a time machine. Spend some time in the 1980s. See what kinds of
programming people were doing. HINT: It wasn't web app development.

> Why do language designers perpetuate bad ideas? The reason for designing a
> new language is just so you can get rid of some of them!

Yeah, which is why your personal pet language has approximately one
user. The more things you change when you create a new language, the
more likely that it'll be utterly useless to anyone but yourself.

Consistency is a lot more important than many people give it credit for.

ChrisA


From ian.g.kelly at gmail.com  Fri May 11 09:28:27 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Fri, 11 May 2018 07:28:27 -0600
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <CAPTjJmpd_1JHrGJdGLidcF99b=R7sRn2OrvTzCRdP9wxdtqAtA@mail.gmail.com>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net>
 <87fu2z1dkp.fsf@nightsong.com> <87sh6z86po.fsf@elektro.pacujo.net>
 <pd3alm$uno$2@blaine.gmane.org>
 <CALwzidn5=jiFXT78n3Z0GFroEWUWHrNNeMsVHozXzEsffJ1n7w@mail.gmail.com>
 <CAPTjJmpd_1JHrGJdGLidcF99b=R7sRn2OrvTzCRdP9wxdtqAtA@mail.gmail.com>
Message-ID: <CALwzidmvkJfTQa5L1Sa61JCpfzLikfJLL2hZdVsAHkH7SaiQuQ@mail.gmail.com>

On Fri, May 11, 2018 at 1:06 AM, Chris Angelico <rosuav at gmail.com> wrote:
> On Fri, May 11, 2018 at 4:54 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
>> On Thu, May 10, 2018 at 11:45 PM, Steven D'Aprano
>> <steve+comp.lang.python at pearwood.info> wrote:
>>> To be honest, I'm having trouble thinking of a good use-case for "while
>>> True", now that we have infinite iterators. Most cases of
>>>
>>>     while True:
>>>         x = get_item()
>>>         if not x: break
>>>         process(x)
>>>
>>> are better written as:
>>>
>>>     for x in iterator:
>>>         process(x)
>>
>> x = get_item()
>> while True:
>>     x = process(x)
>
> More likely:
>
> x = get_item()
> while x:
>     process(x)
>     x = get_item()
>
> which (a) repeats the call to get_item, (b) doesn't support the
> 'continue' statement, and (c) hides crucial loop iteration information
> at the BOTTOM of the loop.
>
> But to make this iterator, you need to separate the while loop's
> header from its body. Compare:
>
> while x := get_item():
>     process(x)
>
>
> def get_items():
>     while True:
>         x = get_item()
>         if not x: return
>         yield x
>
> for x in get_items():
>     process(x)
>
> It hasn't actually gotten rid of the fib of the infinite loop; all
> it's done is wrap it up in a function. Yes, that can be of value; but
> adding another level of indirection doesn't solve a problem, it just
> moves it around.

You can get rid of the while loop:

for x in iter(get_item, None):
    process(x)

The reason I suggested the function I did is because the x in that
case can't reasonably be turned into an iterator because the logic
depends on the loop body. You can't encapsulate the iteration logic
without having side-effects in the iteration or duplicating code.


From ian.g.kelly at gmail.com  Fri May 11 09:31:01 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Fri, 11 May 2018 07:31:01 -0600
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <CAPTjJmpVWJpQW_N5KZPgpvN=KaOEF1Kk4BHtKt=ht+WVYP4EAA@mail.gmail.com>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net>
 <CAPTjJmqMpUUzKJmomk3Ypms3_k8Cp0eOrDmNEKigQLQfjyzGdQ@mail.gmail.com>
 <mailman.92.1525982855.28519.python-list@python.org>
 <87wowb86sz.fsf@elektro.pacujo.net>
 <CAPTjJmpf+HCK-k8St_HK01FYFYac5xUZBB0vq6rLOpJWRrHzHw@mail.gmail.com>
 <mailman.95.1525998102.28519.python-list@python.org>
 <87k1sb8262.fsf@elektro.pacujo.net>
 <CAPTjJmq7pF-qg_t_ioEHX6rDHAn0zF7Pqc43eiDHfQWEsiJwAQ@mail.gmail.com>
 <CALwzidk424PzRwWoD3qWU=Yo4=pc9pRMv9NRpMZtgrscG0E4Lg@mail.gmail.com>
 <CAPTjJmpVWJpQW_N5KZPgpvN=KaOEF1Kk4BHtKt=ht+WVYP4EAA@mail.gmail.com>
Message-ID: <CALwzidk-NgKeO2XBTUs7EvkTFH5t=akP8PQT5CE3oe9CJSkWZw@mail.gmail.com>

On Fri, May 11, 2018 at 1:01 AM, Chris Angelico <rosuav at gmail.com> wrote:
> On Fri, May 11, 2018 at 12:38 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
>> Would you also contend that generator functions are wrong because they
>> pretend to be normal functions?
>>
>> def totally_not_a_generator(n):
>>     while True:
>>         if n % 2 == 0:
>>             n //= 2
>>         else:
>>             n = n * 3 + 1
>>         stealthily = n
>>         yield stealthily
>>         if n == 1:
>>             return n
>>
>> py> print(totally_not_a_generator(42))  # Lies!
>> <generator object totally_not_a_generator at 0x77fe4d78c0f8>
>
> Let's see. It's created with 'def'. It can be called by putting
> parentheses after its name. Inside the parentheses, you can give it
> parameters. When called, it returns a value. Hmm. Sure looks like a
> function to me.
>
> Tell me, which of these are functions and which are not?
>
> def tnag5():
>     return totally_not_a_generator(5)
>
> def tnag(n):
>     return iter(totally_not_a_generator(n))
>
> def ILY():
>     return iter([1, 2, 3]) # your heart starts beating
>
> async def what_about_me():
>     await spam()
>     return 42
>
> def digits_to_number(text):
>     return int(text, 10)
>
> class run_command:
>     """Compatibility shim for older API"""
>     def __init__(self, *args):
>         proc = subprocess.run(*args, stdout=subprocess.PIPE)
>         self.rc = proc.returncode
>         self.output = proc.output
>
> def run_command(*args):
>     proc = subprocess.run(*args, stdout=subprocess.PIPE)
>     return {"rc": proc.returncode, "output": proc.output}
>
>
> The only one that inspect.isfunction() returns False for is the class,
> and even that is a very function-like class. Every one of these is
> callable and will return a useful value. Their headers announce one of
> three things:
>
> 1) "I am a function" ==> def name(...):
> 2) "I am a factory for objects of my own type" ==> class name:
> 3) "I am a coroutine function" ==> async def name(...):
>
> Not one of them is lying. And nor is your totally_not_a_generator. As
> Steven said, it's a function, and it returns a value.

It's a generator that says it's not a generator. How is that not lying?

Anyway, as far as I can see you just repeated the same argument that
Steven wrote. I know all this, of course, and I think you missed the
point. Please read my response to Steven.


From marko at pacujo.net  Fri May 11 09:36:48 2018
From: marko at pacujo.net (Marko Rauhamaa)
Date: Fri, 11 May 2018 16:36:48 +0300
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <87o9hn82e9.fsf@elektro.pacujo.net> <kS5JC.258835$sl2.255712@fx46.am4>
 <201805102136.26478.gheskett@shentel.net>
 <CAPTjJmoBT+Ra0f5km3U89S0s1FLOS1FBynHnRnigZkKROnTG2A@mail.gmail.com>
 <mailman.101.1526004454.28519.python-list@python.org>
 <fll8diF3k4vU1@mid.individual.net>
 <CAPTjJmoK-kxhH+pE+fnfXg4PQ=kyaytDdgAa__TiCuL=Td0qXg@mail.gmail.com>
 <mailman.132.1526044481.28519.python-list@python.org>
Message-ID: <87wowa71qn.fsf@elektro.pacujo.net>

Chris Angelico <rosuav at gmail.com>:

> On Fri, May 11, 2018 at 8:08 PM, Gregory Ewing
> <greg.ewing at canterbury.ac.nz> wrote:
>> I think the idea is that you could regroup those 4 groups of 3 into 3
>> groups of 4, and get a nice mapping to hex. If hex had been the
>> conventional way of writing binary numbers back then, Ken and Dennis
>> would probably have done it that way.
>
> But they aren't "four groups of three" that could be reorganized.
> They're three groups of three, plus three separate bits. Each group of
> three is the permissions for one category of user (the owner, anyone
> in the owning group, or everyone else).

   "And on far-off Earth, Dr. Carlisle Perera had as yet told no one how
   he had wakened from a restless sleep with the message from his
   subconscious still echoing in his brain: The Ramans do everything in
   threes.W

   <URL: https://en.wikipedia.org/wiki/Rendezvous_with_Rama>


Marko


From rosuav at gmail.com  Fri May 11 09:38:56 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 11 May 2018 23:38:56 +1000
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <CALwzidmvkJfTQa5L1Sa61JCpfzLikfJLL2hZdVsAHkH7SaiQuQ@mail.gmail.com>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net>
 <87fu2z1dkp.fsf@nightsong.com> <87sh6z86po.fsf@elektro.pacujo.net>
 <pd3alm$uno$2@blaine.gmane.org>
 <CALwzidn5=jiFXT78n3Z0GFroEWUWHrNNeMsVHozXzEsffJ1n7w@mail.gmail.com>
 <CAPTjJmpd_1JHrGJdGLidcF99b=R7sRn2OrvTzCRdP9wxdtqAtA@mail.gmail.com>
 <CALwzidmvkJfTQa5L1Sa61JCpfzLikfJLL2hZdVsAHkH7SaiQuQ@mail.gmail.com>
Message-ID: <CAPTjJmrRk+HRcNsgqy6ky77TCY5kaj=TKGbxrs7nXMZNijXo2g@mail.gmail.com>

On Fri, May 11, 2018 at 11:28 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> You can get rid of the while loop:
>
> for x in iter(get_item, None):
>     process(x)
>
> The reason I suggested the function I did is because the x in that
> case can't reasonably be turned into an iterator because the logic
> depends on the loop body. You can't encapsulate the iteration logic
> without having side-effects in the iteration or duplicating code.

That's actually equivalent to:

while (x := get_item()) != None:
    process(x)

That's not often going to be what you want. If the function is
guaranteed to return None, you should be using "is not None", and if
it's simply returning something falsey, you should be checking
truthiness. Once again, this is shoe-horning the available mechanics
into tasks that aren't quite what they're designed for; they're "close
enough" for a lot of cases, but not really correct.

ChrisA


From rosuav at gmail.com  Fri May 11 09:40:23 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 11 May 2018 23:40:23 +1000
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <CALwzidk-NgKeO2XBTUs7EvkTFH5t=akP8PQT5CE3oe9CJSkWZw@mail.gmail.com>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net>
 <CAPTjJmqMpUUzKJmomk3Ypms3_k8Cp0eOrDmNEKigQLQfjyzGdQ@mail.gmail.com>
 <mailman.92.1525982855.28519.python-list@python.org>
 <87wowb86sz.fsf@elektro.pacujo.net>
 <CAPTjJmpf+HCK-k8St_HK01FYFYac5xUZBB0vq6rLOpJWRrHzHw@mail.gmail.com>
 <mailman.95.1525998102.28519.python-list@python.org>
 <87k1sb8262.fsf@elektro.pacujo.net>
 <CAPTjJmq7pF-qg_t_ioEHX6rDHAn0zF7Pqc43eiDHfQWEsiJwAQ@mail.gmail.com>
 <CALwzidk424PzRwWoD3qWU=Yo4=pc9pRMv9NRpMZtgrscG0E4Lg@mail.gmail.com>
 <CAPTjJmpVWJpQW_N5KZPgpvN=KaOEF1Kk4BHtKt=ht+WVYP4EAA@mail.gmail.com>
 <CALwzidk-NgKeO2XBTUs7EvkTFH5t=akP8PQT5CE3oe9CJSkWZw@mail.gmail.com>
Message-ID: <CAPTjJmru5H8tHCrgONtw9S64kC0P0dG2aG77Gy1+unYvgkNYUQ@mail.gmail.com>

On Fri, May 11, 2018 at 11:31 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Fri, May 11, 2018 at 1:01 AM, Chris Angelico <rosuav at gmail.com> wrote:
>> On Fri, May 11, 2018 at 12:38 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
>>> Would you also contend that generator functions are wrong because they
>>> pretend to be normal functions?
>>>
>>> def totally_not_a_generator(n):
>>>     while True:
>>>         if n % 2 == 0:
>>>             n //= 2
>>>         else:
>>>             n = n * 3 + 1
>>>         stealthily = n
>>>         yield stealthily
>>>         if n == 1:
>>>             return n
>>>
>>> py> print(totally_not_a_generator(42))  # Lies!
>>> <generator object totally_not_a_generator at 0x77fe4d78c0f8>
>>
>> Let's see. It's created with 'def'. It can be called by putting
>> parentheses after its name. Inside the parentheses, you can give it
>> parameters. When called, it returns a value. Hmm. Sure looks like a
>> function to me.
>>
>> Tell me, which of these are functions and which are not?
>>
>> def tnag5():
>>     return totally_not_a_generator(5)
>>
>> def tnag(n):
>>     return iter(totally_not_a_generator(n))
>>
>> def ILY():
>>     return iter([1, 2, 3]) # your heart starts beating
>>
>> async def what_about_me():
>>     await spam()
>>     return 42
>>
>> def digits_to_number(text):
>>     return int(text, 10)
>>
>> class run_command:
>>     """Compatibility shim for older API"""
>>     def __init__(self, *args):
>>         proc = subprocess.run(*args, stdout=subprocess.PIPE)
>>         self.rc = proc.returncode
>>         self.output = proc.output
>>
>> def run_command(*args):
>>     proc = subprocess.run(*args, stdout=subprocess.PIPE)
>>     return {"rc": proc.returncode, "output": proc.output}
>>
>>
>> The only one that inspect.isfunction() returns False for is the class,
>> and even that is a very function-like class. Every one of these is
>> callable and will return a useful value. Their headers announce one of
>> three things:
>>
>> 1) "I am a function" ==> def name(...):
>> 2) "I am a factory for objects of my own type" ==> class name:
>> 3) "I am a coroutine function" ==> async def name(...):
>>
>> Not one of them is lying. And nor is your totally_not_a_generator. As
>> Steven said, it's a function, and it returns a value.
>
> It's a generator that says it's not a generator. How is that not lying?
>
> Anyway, as far as I can see you just repeated the same argument that
> Steven wrote. I know all this, of course, and I think you missed the
> point. Please read my response to Steven.

You said:

>> Would you also contend that generator functions are wrong because they
>> pretend to be normal functions?

So, yes, your function's name is outright lying. But there's nothing
about it that is *pretending* to be a normal function. It IS a normal
function.

ChrisA


From grant.b.edwards at gmail.com  Fri May 11 10:31:35 2018
From: grant.b.edwards at gmail.com (Grant Edwards)
Date: Fri, 11 May 2018 14:31:35 +0000 (UTC)
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <87o9hn82e9.fsf@elektro.pacujo.net> <kS5JC.258835$sl2.255712@fx46.am4>
 <201805102136.26478.gheskett@shentel.net>
Message-ID: <pd49g7$ad6$1@blaine.gmane.org>

On 2018-05-11, Gene Heskett <gheskett at shentel.net> wrote:

> Computers haven't read a single 8 bit byte in years, some reading
> 128 or 256 bits in a single read cycle today.

Nonsense.  All modern CPUs that I'm aware of still still support
single byte reads, and compilers still use those instructions when the
size of the object being read is 8 bits.

-- 
Grant Edwards               grant.b.edwards        Yow! An INK-LING?  Sure --
                                  at               TAKE one!!  Did you BUY any
                              gmail.com            COMMUNIST UNIFORMS??



From grant.b.edwards at gmail.com  Fri May 11 10:35:27 2018
From: grant.b.edwards at gmail.com (Grant Edwards)
Date: Fri, 11 May 2018 14:35:27 +0000 (UTC)
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
References: <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>
 <mailman.84.1525976408.28519.python-list@python.org>
 <2W3JC.64439$7b4.11219@fx12.am4>
 <CAPTjJmr+t3ivSpTqiGmD3DBJo8dba+5sriMffYRsdfVC+yRpSg@mail.gmail.com>
 <mailman.94.1525997497.28519.python-list@python.org>
 <87o9hn82e9.fsf@elektro.pacujo.net> <kS5JC.258835$sl2.255712@fx46.am4>
 <822afdlt7cmd9po2gin12ced34dg9nua03@4ax.com>
Message-ID: <pd49nf$ad6$2@blaine.gmane.org>

On 2018-05-11, Dennis Lee Bieber <wlfraed at ix.netcom.com> wrote:
> On Fri, 11 May 2018 01:55:58 +0100, bartc <bc at freeuk.com> declaimed the
> following:
>
>>On 11/05/2018 01:25, Marko Rauhamaa wrote:
>>> Chris Angelico <rosuav at gmail.com>:
>>> 
>>>> Octal makes a lot of sense in the right contexts.
>>> 
>>> I think octal is a historical relic from a time when people weren't yet
>>> comfortable with hexadecimal.
>>
>>It's a relic from when machines had word sizes that were multiples of 
>>three bits, or were divided up on 3-bit boundaries.
>
> The Intel 8080a was 8-bit bytes, but octal was actually more usable
> when interpreting op-codes. 3-bits encoded the processor registers
> (including the "M"emory access via HL address). A(7), B(0)-C(1),
> D(2)-E(3), H(4)-L(5), M(6): MOV H,E => 143 octal is easier to decode
> than 63 hex

The first 8080-compatible "computer" I owned was a Heathkit terminal
with an 8085 CPU.  The firmware listings used "split octal":

  0x0000 = 000 000
  0xffff = 377 377

IIRC, PDP-11 assembly listings and machine documentation generally
used octal for the same reason: the 16-bit instruction word was
internally divided into a number of 3-bit fields.

-- 
Grant Edwards               grant.b.edwards        Yow! Now that I have my
                                  at               "APPLE", I comprehend COST
                              gmail.com            ACCOUNTING!!



From grant.b.edwards at gmail.com  Fri May 11 10:40:44 2018
From: grant.b.edwards at gmail.com (Grant Edwards)
Date: Fri, 11 May 2018 14:40:44 +0000 (UTC)
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>
 <mailman.84.1525976408.28519.python-list@python.org>
 <2W3JC.64439$7b4.11219@fx12.am4>
 <CAPTjJmr+t3ivSpTqiGmD3DBJo8dba+5sriMffYRsdfVC+yRpSg@mail.gmail.com>
 <mailman.94.1525997497.28519.python-list@python.org>
 <87o9hn82e9.fsf@elektro.pacujo.net> <fll7k7F3fvrU1@mid.individual.net>
 <pd3st7$uno$7@blaine.gmane.org>
Message-ID: <pd4a1c$ad6$3@blaine.gmane.org>

On 2018-05-11, Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
> On Fri, 11 May 2018 21:55:17 +1200, Gregory Ewing wrote:
>
>> Hex came into vogue in the DEC world with the VAX, which was both
>> byte-addressed and had a hex-oriented instruction encoding.
>
>
> [...] You had computers with 6, 9, or even 60 bits per byte

Ah, the old CDC-6600 had 60-bit words.

IIRC, the Pascal compiler used a 6-bit wide character set, which meant
that you could fit 10 characters in a word, and Pascal identifiers
were limited to 10 characters.

> I'm also told that some of those computers didn't run Windows.

Of course not, everything ran Linux back in the good old days.

-- 
Grant Edwards               grant.b.edwards        Yow! PIZZA!!
                                  at               
                              gmail.com            



From ian.g.kelly at gmail.com  Fri May 11 11:03:11 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Fri, 11 May 2018 09:03:11 -0600
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <CAPTjJmru5H8tHCrgONtw9S64kC0P0dG2aG77Gy1+unYvgkNYUQ@mail.gmail.com>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net>
 <CAPTjJmqMpUUzKJmomk3Ypms3_k8Cp0eOrDmNEKigQLQfjyzGdQ@mail.gmail.com>
 <mailman.92.1525982855.28519.python-list@python.org>
 <87wowb86sz.fsf@elektro.pacujo.net>
 <CAPTjJmpf+HCK-k8St_HK01FYFYac5xUZBB0vq6rLOpJWRrHzHw@mail.gmail.com>
 <mailman.95.1525998102.28519.python-list@python.org>
 <87k1sb8262.fsf@elektro.pacujo.net>
 <CAPTjJmq7pF-qg_t_ioEHX6rDHAn0zF7Pqc43eiDHfQWEsiJwAQ@mail.gmail.com>
 <CALwzidk424PzRwWoD3qWU=Yo4=pc9pRMv9NRpMZtgrscG0E4Lg@mail.gmail.com>
 <CAPTjJmpVWJpQW_N5KZPgpvN=KaOEF1Kk4BHtKt=ht+WVYP4EAA@mail.gmail.com>
 <CALwzidk-NgKeO2XBTUs7EvkTFH5t=akP8PQT5CE3oe9CJSkWZw@mail.gmail.com>
 <CAPTjJmru5H8tHCrgONtw9S64kC0P0dG2aG77Gy1+unYvgkNYUQ@mail.gmail.com>
Message-ID: <CALwzidn1wzxocP+xuoqH__Y_FYyy6A6gKj+hiqOtygyWU_sdzw@mail.gmail.com>

On Fri, May 11, 2018 at 7:40 AM, Chris Angelico <rosuav at gmail.com> wrote:
> So, yes, your function's name is outright lying. But there's nothing
> about it that is *pretending* to be a normal function. It IS a normal
> function.

The detail of whether it's a generator function affects the function's
execution and may be relevant to the caller. Here are two hypothetical
functions. They do some processing with side-effects over a bunch of
items and return the processed items. However, one is a generator
function and the other just returns a list.

def process_items(items):
    ...

def handle_items(items):
    ...

Now, we can agree that these ought to be better documented, but say I
want to call one of these for the side effects and ignore the return
value. Just from reading the first line of the function, do I need to
iterate over the result, or not?

Scenario 2. I have two "while True" loops. One is potentially infinite
and the other is not.

while True:
    ...

while True:
    ...

Obviously, it's important to know whether a loop might be infinite
before I run the code that includes it. Just from reading the first
line of the loop, how do I know? You can argue that they should use
strings instead to describe what they do, which would help, although I
think that's potentially confusing.

I don't see these two situations as being fundamentally different. Do you?


From pevogam at gmail.com  Fri May 11 11:23:36 2018
From: pevogam at gmail.com (pevogam at gmail.com)
Date: Fri, 11 May 2018 08:23:36 -0700 (PDT)
Subject: Passing File Descriptors To Subprocesses
In-Reply-To: <mailman.52.1468724484.2307.python-list@python.org>
References: <f421033d-5fa4-4d02-8c3e-dadc8b778e44@googlegroups.com>
 <CACL+1atgkjXMvy0+45pSXpVf0xxT7=iDpZDAMiHN0tP6XTd5rA@mail.gmail.com>
 <mailman.52.1468724484.2307.python-list@python.org>
Message-ID: <2674dd2c-1a05-4b56-b981-6e7b85cf5cc1@googlegroups.com>

I encountered the same issue with Python 3.4 on CentOS 7 when using only the close_fds argument. Since I am passing a lot of dynamically obtained file descriptors, using the pass_fds argument is impossible for my case. Setting close_fds to False *but* also explicitly making the fds inheritable upon generation solved the issue. I would be really grateful if there was at least a note in the subprocess module explaining that one might need to explicitly make file descriptors inheritable since if it wasn't this post I would have lost even more time than I already did.


From jon+usenet at unequivocal.eu  Fri May 11 11:37:41 2018
From: jon+usenet at unequivocal.eu (Jon Ribbens)
Date: Fri, 11 May 2018 15:37:41 -0000 (UTC)
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <87o9hn82e9.fsf@elektro.pacujo.net> <kS5JC.258835$sl2.255712@fx46.am4>
 <201805102136.26478.gheskett@shentel.net> <pd49g7$ad6$1@blaine.gmane.org>
 <mailman.138.1526049237.28519.python-list@python.org>
Message-ID: <slrnpfbe65.258.jon+usenet@sable.unequivocal.eu>

On 2018-05-11, Grant Edwards <grant.b.edwards at gmail.com> wrote:
> On 2018-05-11, Gene Heskett <gheskett at shentel.net> wrote:
>> Computers haven't read a single 8 bit byte in years, some reading
>> 128 or 256 bits in a single read cycle today.
>
> Nonsense.  All modern CPUs that I'm aware of still still support
> single byte reads, and compilers still use those instructions when the
> size of the object being read is 8 bits.

It's not nonsense. The CPU might have a 'load a byte' instruction but
it will actually read more than a byte and then throw away the extra.


From rosuav at gmail.com  Fri May 11 11:38:37 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 12 May 2018 01:38:37 +1000
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <CALwzidn1wzxocP+xuoqH__Y_FYyy6A6gKj+hiqOtygyWU_sdzw@mail.gmail.com>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
 <CAPTjJmpG-L3Okb0m8pdh6vwDe_yfavog79K6dP56p2yNK1w6AQ@mail.gmail.com>
 <CAE6NSRAPtmZq8PJZ1K-ZV4f_KrN+JzHyE5Dkkpyy7G2Wve05QQ@mail.gmail.com>
 <mailman.86.1525977686.28519.python-list@python.org>
 <871sej9ta0.fsf@elektro.pacujo.net>
 <CAPTjJmqMpUUzKJmomk3Ypms3_k8Cp0eOrDmNEKigQLQfjyzGdQ@mail.gmail.com>
 <mailman.92.1525982855.28519.python-list@python.org>
 <87wowb86sz.fsf@elektro.pacujo.net>
 <CAPTjJmpf+HCK-k8St_HK01FYFYac5xUZBB0vq6rLOpJWRrHzHw@mail.gmail.com>
 <mailman.95.1525998102.28519.python-list@python.org>
 <87k1sb8262.fsf@elektro.pacujo.net>
 <CAPTjJmq7pF-qg_t_ioEHX6rDHAn0zF7Pqc43eiDHfQWEsiJwAQ@mail.gmail.com>
 <CALwzidk424PzRwWoD3qWU=Yo4=pc9pRMv9NRpMZtgrscG0E4Lg@mail.gmail.com>
 <CAPTjJmpVWJpQW_N5KZPgpvN=KaOEF1Kk4BHtKt=ht+WVYP4EAA@mail.gmail.com>
 <CALwzidk-NgKeO2XBTUs7EvkTFH5t=akP8PQT5CE3oe9CJSkWZw@mail.gmail.com>
 <CAPTjJmru5H8tHCrgONtw9S64kC0P0dG2aG77Gy1+unYvgkNYUQ@mail.gmail.com>
 <CALwzidn1wzxocP+xuoqH__Y_FYyy6A6gKj+hiqOtygyWU_sdzw@mail.gmail.com>
Message-ID: <CAPTjJmr1hioruBG5V35uoFAEkekbxxyDqOvUxCwWazYtbKOv2g@mail.gmail.com>

On Sat, May 12, 2018 at 1:03 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Fri, May 11, 2018 at 7:40 AM, Chris Angelico <rosuav at gmail.com> wrote:
>> So, yes, your function's name is outright lying. But there's nothing
>> about it that is *pretending* to be a normal function. It IS a normal
>> function.
>
> The detail of whether it's a generator function affects the function's
> execution and may be relevant to the caller. Here are two hypothetical
> functions. They do some processing with side-effects over a bunch of
> items and return the processed items. However, one is a generator
> function and the other just returns a list.
>
> def process_items(items):
>     ...
>
> def handle_items(items):
>     ...
>
> Now, we can agree that these ought to be better documented, but say I
> want to call one of these for the side effects and ignore the return
> value. Just from reading the first line of the function, do I need to
> iterate over the result, or not?

This is no different from anything else you might need to know about
the functions. It might be essential to know that "handle_items"
actually doesn't return anything at all, and signals success or
failure by what exception it raises. Or that "process_items", due to
internal structure and implementation, absolutely must be called from
the main thread, otherwise you risk OS-level signals corrupting your
data. The solution is simple: read the docstring.

> Scenario 2. I have two "while True" loops. One is potentially infinite
> and the other is not.
>
> while True:
>     ...
>
> while True:
>     ...
>
> Obviously, it's important to know whether a loop might be infinite
> before I run the code that includes it. Just from reading the first
> line of the loop, how do I know? You can argue that they should use
> strings instead to describe what they do, which would help, although I
> think that's potentially confusing.
>
> I don't see these two situations as being fundamentally different. Do you?

Not hugely, no. But it's worth noting that we have the option to
annotate a function's return value. So if you need structured
information about what this function or that function returns, you can
provide that. It's not easy to make program-readable information about
a 'while' loop (since it's not a first-class object), but you can
still have structured information about whether the loop is infinite
or not, by putting it into the loop header.

But I still think you're overblowing the case when you claim that a
generator function isn't a function. That'd be on par with claiming
that a while loop isn't a loop.

ChrisA


From bc at freeuk.com  Fri May 11 11:56:09 2018
From: bc at freeuk.com (bartc)
Date: Fri, 11 May 2018 16:56:09 +0100
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <mailman.133.1526045077.28519.python-list@python.org>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>
 <mailman.84.1525976408.28519.python-list@python.org>
 <2W3JC.64439$7b4.11219@fx12.am4>
 <CAPTjJmr+t3ivSpTqiGmD3DBJo8dba+5sriMffYRsdfVC+yRpSg@mail.gmail.com>
 <mailman.94.1525997497.28519.python-list@python.org>
 <NReJC.131905$I77.15095@fx44.am4>
 <CAPTjJmoSuHpYwwR-xV7RkNSM9a-HqnH-qQy0oZXosiQOvK8pOQ@mail.gmail.com>
 <mailman.133.1526045077.28519.python-list@python.org>
Message-ID: <d2jJC.207297$jZ.48057@fx20.am4>

On 11/05/2018 14:24, Chris Angelico wrote:
> On Fri, May 11, 2018 at 9:09 PM, bartc <bc at freeuk.com> wrote:

>>      when 101'11010'000'B then ...
>>
>> Try /that/ in hex /or/ octal.)
> 
> I've no idea what this is supposed to mean, or why you have groups of
> three, five, and three. Looks like a possible bug to me. I'm sure it
> isn't, of course, since you're one of those perfect programmers who
> simply doesn't _make_ errors, but if it were my code, I would be
> worried that it isn't correct somewhere.

The data-sheet for the 8087 numeric co-processor displays instructions 
of the two-byte opcodes in formats like this (high to low bits):

   [escape 1 0 1] [1 1 0 1 0 ST(i)]

'escape' is the 5-bit sequence 11011. ST(i) is a 3-bit register code. So 
considered as a one 16-bit value, it's divided into groups of 5:3:5:3. 
The escape sequence has already been detected, and the middle two groups 
have been isolated by masking with 111'11111'000B.

So it is checking for combinations of those middle 3:5 groups of bits in 
a way that exactly matches how it's presented in the data sheet. And 
this instruction encoding is still used in current AMD/Intel x64 processors.

The xxxxx-101-11010-xxx pattern corresponds to the FST ST(0) to ST(i) 
instruction:

     when 101'11010'000B then
         genstr("fst ")
         genstr(strfreg(freg))

It's not a bug. Just a good example of the use of binary where hex or 
octal doesn't cut it because the grouping isn't purely in threes or fours.

(I understand that binary literals were added to Python from version 
2.6. The question is why it took so long. They are not a heavyweight 
feature.)

> Cool. So what's the native integer size for the real world? Use that
> as your primary data type.
> 
> Oh, can't decide how many digits? That's a pity.

What's this got to do with octal? Because many languages impose a limit 
on the widths of numeric types, that somehow makes it OK to implement 
octal using leading zeros? Just to catch people out because octal is 
used so rarely.

> Go get a time machine. Spend some time in the 1980s. See what kinds of
> programming people were doing. HINT: It wasn't web app development.

I was doing lots of development in the 1980s. I just didn't use C.

> Yeah, which is why your personal pet language has approximately one
> user. The more things you change when you create a new language, the
> more likely that it'll be utterly useless to anyone but yourself.
> 
> Consistency is a lot more important than many people give it credit for.

That's why 0100 is sixty four in Python 2, and an error in Python 3? 
Instead of being one hundred in both, as common sense would have dictated.

And, for that matter, one hundred in any of my languages, some of which 
did have more than one user.

BTW here is one C-ism that /didn't/ make it into Python 1:

  print (0xE-1)

This prints 13 (0xE is 14, minus 1). But it would be an error in 
conforming C compilers:

    printf("%d", 0xE-1);

"error: invalid suffix "-1" on integer constant"

Perhaps consistency isn't always as important as you say, not for 
something which is crazily stupid.

At least 0xE-1 generates an error (on some compilers; on others, only 
years later when you switch compiler). 0100, if not intended as octal, 
is an undetectable error in C and Python 2.

-- 
bartc


From ian.g.kelly at gmail.com  Fri May 11 12:35:51 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Fri, 11 May 2018 10:35:51 -0600
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <pd3clf$uno$5@blaine.gmane.org>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CALwzidn6qiie4oz3CmysS6D-AtUoF2h215VJODDUL9L89pygNg@mail.gmail.com>
 <pd3276$qbi$6@blaine.gmane.org>
 <CALwzidnYcdUr8PFEE4w8fC8S9YsL=sfM-U15Ex10EJQ++gqshg@mail.gmail.com>
 <pd3clf$uno$5@blaine.gmane.org>
Message-ID: <CALwzidk=8BBiFZNgbvH=GGM89maH6NE+xXyQFYkAZCpn-F2TYA@mail.gmail.com>

On Fri, May 11, 2018 at 12:19 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Thu, 10 May 2018 23:23:33 -0600, Ian Kelly wrote:
>
>> On Thu, May 10, 2018 at 9:21 PM, Steven D'Aprano
>> <steve+comp.lang.python at pearwood.info> wrote:
>>> On Thu, 10 May 2018 11:03:54 -0600, Ian Kelly wrote about proposed
>>> prefixes for octal:
>>>
>>>> Personally I would have preferred the "t".
>>>
>>> "t" for octal, hey?
>>>
>>> That would be annoying if we ever get trinary literals.
>>>
>>> n for binary
>>> t for octal
>>> i for trinary
>>> or should that be r for ternary?
>>> o for duodecimal
>>
>> I prefer it because it's the first letter of a syllable and it's not
>> "o", not because it's the third letter of the word.
>
> You should have said. Since you quoted the PEP, I inferred you were
> agreeing with the PEP's suggestion:
>
>     even to use a "t" for "ocTal" and an "n" for "biNary" to
>     go along with the "x" for "heXadecimal".
>
> Note the "go along with". The X of hexadecimal, and the N of binary, are
> the *last* letter of a syllable, not the first, so I didn't think that
> "first letter of a syllable" was the rule you were applying. If it were,
> you would have picked "C" for oc-tal, not t.

The X of hexadecimal is pronounced as the consonant cluster /ks/. The
k sound ends the first syllable, and the s sound begins the second
syllable. So the X is both, really.

The N of binary is the first letter of the second syllable, unless the
Australian pronunciation is radically different from the American.


From ian.g.kelly at gmail.com  Fri May 11 12:38:19 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Fri, 11 May 2018 10:38:19 -0600
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <CALwzidk=8BBiFZNgbvH=GGM89maH6NE+xXyQFYkAZCpn-F2TYA@mail.gmail.com>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CALwzidn6qiie4oz3CmysS6D-AtUoF2h215VJODDUL9L89pygNg@mail.gmail.com>
 <pd3276$qbi$6@blaine.gmane.org>
 <CALwzidnYcdUr8PFEE4w8fC8S9YsL=sfM-U15Ex10EJQ++gqshg@mail.gmail.com>
 <pd3clf$uno$5@blaine.gmane.org>
 <CALwzidk=8BBiFZNgbvH=GGM89maH6NE+xXyQFYkAZCpn-F2TYA@mail.gmail.com>
Message-ID: <CALwzidmy_QTCt4V+41P4SK87PQQ_NBSH2N8hXOjNtbf+Oj9yNQ@mail.gmail.com>

On Fri, May 11, 2018 at 10:35 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Fri, May 11, 2018 at 12:19 AM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> On Thu, 10 May 2018 23:23:33 -0600, Ian Kelly wrote:
>>
>>> On Thu, May 10, 2018 at 9:21 PM, Steven D'Aprano
>>> <steve+comp.lang.python at pearwood.info> wrote:
>>>> On Thu, 10 May 2018 11:03:54 -0600, Ian Kelly wrote about proposed
>>>> prefixes for octal:
>>>>
>>>>> Personally I would have preferred the "t".
>>>>
>>>> "t" for octal, hey?
>>>>
>>>> That would be annoying if we ever get trinary literals.
>>>>
>>>> n for binary
>>>> t for octal
>>>> i for trinary
>>>> or should that be r for ternary?
>>>> o for duodecimal
>>>
>>> I prefer it because it's the first letter of a syllable and it's not
>>> "o", not because it's the third letter of the word.
>>
>> You should have said. Since you quoted the PEP, I inferred you were
>> agreeing with the PEP's suggestion:
>>
>>     even to use a "t" for "ocTal" and an "n" for "biNary" to
>>     go along with the "x" for "heXadecimal".
>>
>> Note the "go along with". The X of hexadecimal, and the N of binary, are
>> the *last* letter of a syllable, not the first, so I didn't think that
>> "first letter of a syllable" was the rule you were applying. If it were,
>> you would have picked "C" for oc-tal, not t.
>
> The X of hexadecimal is pronounced as the consonant cluster /ks/. The
> k sound ends the first syllable, and the s sound begins the second
> syllable. So the X is both, really.
>
> The N of binary is the first letter of the second syllable, unless the
> Australian pronunciation is radically different from the American.

Also, the C in octal is the last letter of the first syllable. I stand
by my choice.


From skip.montanaro at gmail.com  Fri May 11 16:40:45 2018
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Fri, 11 May 2018 15:40:45 -0500
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <CA+HdcZjR=twKaHn-dZ2f2d3bW0H8F4i3D6eN32LnOgfmCtCb-A@mail.gmail.com>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <87o9hn82e9.fsf@elektro.pacujo.net> <kS5JC.258835$sl2.255712@fx46.am4>
 <201805102136.26478.gheskett@shentel.net>
 <CA+HdcZjR=twKaHn-dZ2f2d3bW0H8F4i3D6eN32LnOgfmCtCb-A@mail.gmail.com>
Message-ID: <CANc-5UwtU_d8hgr2qt5GeLd2q477=66N2uJnaBG2xS30HvH1pA@mail.gmail.com>

>
> And, if it is really necessary to retain
> octal, why not preface it with anything BUT a "0".
>

I believe "0o" offers some symmetry with the "0x" prefix used for hex
literals. (And "0b" for binary.) It's a bit unfortunate that zero and
capital "oh" are visually so similar. Not much to be done about that at
this point. Just avoid upper case for all three prefixes.

Skip


From tjreedy at udel.edu  Fri May 11 17:14:54 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 11 May 2018 17:14:54 -0400
Subject: Passing File Descriptors To Subprocesses
In-Reply-To: <2674dd2c-1a05-4b56-b981-6e7b85cf5cc1@googlegroups.com>
References: <f421033d-5fa4-4d02-8c3e-dadc8b778e44@googlegroups.com>
 <CACL+1atgkjXMvy0+45pSXpVf0xxT7=iDpZDAMiHN0tP6XTd5rA@mail.gmail.com>
 <mailman.52.1468724484.2307.python-list@python.org>
 <2674dd2c-1a05-4b56-b981-6e7b85cf5cc1@googlegroups.com>
Message-ID: <pd510b$6ib$1@blaine.gmane.org>

On 5/11/2018 11:23 AM, pevogam at gmail.com wrote:
> I encountered the same issue with Python 3.4 on CentOS 7 when using only the close_fds argument. Since I am passing a lot of dynamically obtained file descriptors, using the pass_fds argument is impossible for my case. Setting close_fds to False *but* also explicitly making the fds inheritable upon generation solved the issue. I would be really grateful if there was at least a note in the subprocess module explaining that one might need to explicitly make file descriptors inheritable since if it wasn't this post I would have lost even more time than I already did.

Make specific proposal on the tracker bugs.python.org.

-- 
Terry Jan Reedy



From mikhailwas at gmail.com  Fri May 11 19:26:05 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Sat, 12 May 2018 02:26:05 +0300
Subject: Suggestion for a "data" object syntax
In-Reply-To: <CALwzidksU9-2whNm=fLiM1vNVcCLZFCQd7QdANOVjeaSDdCdXQ@mail.gmail.com>
References: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
 <pcriqa$16m$13@blaine.gmane.org>
 <CAE6NSRCo8-dVWSAYuY8MHH6vviy_2Qn_LpGa2kRTN8L2=cceXQ@mail.gmail.com>
 <pcsf85$16m$15@blaine.gmane.org>
 <CAE6NSRALn2benyf+C87bCKSwRH3gzXcd1WHj_EawR9OngqbcSg@mail.gmail.com>
 <pctpo0$qbi$1@blaine.gmane.org>
 <CAE6NSRCBr=EOENJPxaUG4uMyToYg+ZX_KkW0SRaT8feCWzd9Tw@mail.gmail.com>
 <CALwzidksU9-2whNm=fLiM1vNVcCLZFCQd7QdANOVjeaSDdCdXQ@mail.gmail.com>
Message-ID: <CAE6NSRDUjmZHZ7BgvgH_tEc3DC94S+787AtsB4iLn9ipYM+xbA@mail.gmail.com>

On Fri, May 11, 2018 at 9:12 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Thu, May 10, 2018 at 6:34 PM, Mikhail V <mikhailwas at gmail.com> wrote:
>> On Wed, May 9, 2018 at 6:25 AM, Steven D'Aprano
>> <steve+comp.lang.python at pearwood.info> wrote:
>>> On Tue, 08 May 2018 23:16:23 +0300, Mikhail V wrote:
>>>
>>
>>>> but I propose Tab-separated elements.
>
> Then these are not ordinary expressions, are they? They're a different
> type of expression and will require a modified parser. This adds
> complexity.

Definitely such syntax will require modifed parser.


>> "GvR have invented amazing new syntax that cannot be preserved
>> by sending it by e-mail"!
>> (not me)
>>
>> Do you understand that basically any python code sent by e-mail converts tabs to
>> spaces, thus the only way to receive it - is to send binary file?
>
> Um, no, this is false. We send Python code by email all the time.
> 1) Tabs as indentation: Python permits the use of both tabs and spaces

This means if I paste some code _inside_ an existing  block,
I get a Syntax error:
"TabError: inconsistent use of tabs and spaces in indentation"

> 3) Tabs that appear in strings: This one I'll grant you.

This too.

So what is false? Yes with my syntax it will just become
more prone to environments which replace tabs with
spaces. Mostly this happens in e-mails and web forms.
Why they do it I don't have an idea.

Anyway keeping this in mind, I'd prefer not to adapt
the syntax to such things. It would be fair that the software
solutions should address those, as it should not happen.


> In any case, the use of tabs is entirely optional. For the most part,
> programs can be safely emailed whether they contain tabs or not, the

In real situation just send as attachment, with or without such
syntax, it will be
more polite and safe if you wish the person to run the program.
For some talks in email its not *far* worse than now.


>> Yes, I have told already that there are _some_ cases when
>>  tabulation formatting can cause visual confusion.
>> *But why do you blame me*?
>> It just the issues with editor's incompleteness.
>
> That's great, but if I'm editing a file on an embedded system over a
> serial port and the only editor I have available is nano, I should be
> able to use it. You can't just assume that everybody has a fully
> featured editor (and knows how to use it -- what was that point you
> made just above about beginners?)

Wait, wait, wait - we are adult people - what problem causes nano?
I don't have nano so maybe you can tell what happens in nano if you
load for example a text file this:

?a + b ?? a + b ??a + b  ??a + b
?1 ?? 2 ?? 3 ?? 4
?width:??????100% ??!important;

In the above example one arrow ? is one tab char.
What exact problem do you experience?
(note, I don't ask to align the columns, I just ask what
real problems you have with that?)
TBH I cant say for tools other than normal editor.
Just hope it will not become my problem to test
all legacy stuff out there.


>> For instance, there is real demand on adding new control characters
>> to syntax, so as IDE developers can utilize those for making
>> better user experience. If you apply same one-sided principles here
>> then you behave good to one group of people, but just ignorant
>> to other group of people who want better new experience.
>
> Please link the approved PEP that is going to add syntactically
> meaningful control characters.

Sorry, i was writing too fast - not control characters, but characters in
general. That was kind of general parallel to the current situation.
I'll try to ask better: for instance, if propose to use some unicode character
operator - so I can use the editor feature.
In theory - many people may potentially benefit but some people
have issues with it in some software.
And the issues may vary in nature - e.g. Steven can't bind a keyboard
shortcut to type it.
OTOH it may be something really bad - a software failure or general
problem. So the question is what would be more _serious/general_ problem.


>>>> I don't want spaces or tabs visible - there is toggle "show tabs"
>>>> and "toggle show space" for that

> Needing to fiddle with editor settings in order to determine how the
> code in front of me that somebody else wrote is organized doesn't
> sound to me like a good feature. That sounds to me like poor
> readability.
>

Sorry, not sure what you mean. Do you propose _visible_ character
instead of e.g. tab? But then you need to hide it to be able
to read normally.


>>
>>     "So the idea is to _hide brackets for_ first two levels of
>>     nesting of course."
>
> In other words, this syntax is really not appropriate for more than
> two levels of nesting due to the mental gymnastics required to keep
> track of how the current level of nesting should be expressed.

No. How you come up to this conclusion?
it is just  not a trivial task to find an optimal solution to this -
on the one hand it must be feasible to parse, on the other hand
presentable to the reader. Initial  idea is just use current
Python syntax for further nesting:

image === T/T:
    (127,127,127)        (127,127,127)        (127,127,127)
    (127,127,127)        (127,127,127)        (127,127,127)
    (127,127,127)        (127,127,127)        (127,127,127)
    (127,127,127)        (127,127,127)        (127,127,127)

vs:

image = (
    ((127,127,127), (127,127,127), (127,127,127),),
    ((127,127,127), (127,127,127), (127,127,127),),
    ((127,127,127), (127,127,127), (127,127,127),),
    ((127,127,127), (127,127,127), (127,127,127),),
    )


Seriously I find it quite an improvement both for
readability and type-ability.
I see you keep denying it for some unknown reason,
but well, its up to your conscience.


M


From sharan.basappa at gmail.com  Fri May 11 22:47:49 2018
From: sharan.basappa at gmail.com (Sharan Basappa)
Date: Fri, 11 May 2018 19:47:49 -0700 (PDT)
Subject: PIP install
Message-ID: <c635d60f-313d-42e6-ba1b-dfab8b851ed5@googlegroups.com>

I have installed Python recently. Do I need to install PIP separately or this would be part of default installation. When I run pip install <>, windows complains that no such command exists


From mikhailwas at gmail.com  Fri May 11 22:53:20 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Sat, 12 May 2018 05:53:20 +0300
Subject: Suggestion for a "data" object syntax
In-Reply-To: <CALwzidnf+djaR+hQsBffM1netC_wmiq_p6rdm05wmM7dbx=KFA@mail.gmail.com>
References: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
 <CALwzidnf+djaR+hQsBffM1netC_wmiq_p6rdm05wmM7dbx=KFA@mail.gmail.com>
Message-ID: <CAE6NSRB=nsMEO+r9xp=nFw1E0Lta-iBjuNTBRMOU=JC4ZH1MPg@mail.gmail.com>

On Fri, May 11, 2018 at 9:39 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Mon, May 7, 2018 at 9:45 PM, Mikhail V <mikhailwas at gmail.com> wrote:

>> *Example 1. Multi-line strings*
>>
>> data === S :
>>     this is multi-line string
>>     escape chars: same as in strings (\\, \\n, \\t ...) ,
>>     but "no need to 'escape' quotes"
>
> My reaction #1: why 'S'? Python strings have a name: it's 'str'.
> ...
> My reaction #2: what's the point of this construct? Python already has
> multi-line strings that can be used as expressions, not as statements
> only.

#1. I think passing multiline data structures as arguments
is not especially beautiful. Necessary? I don't know.
#2. What is the point? If introduce the new syntax _at all_,
- the cost of adding some additional common types is less -
IOW worth investigating some options?
About string type id - I agree it may be suboptimal with "S", since
it is not like tuples. But well, there must be something.

In this case:

s = """\
multi line string multi multi line string
multi line string multi line string"""

vs:

s === S:
    multi line string multi multi line string
    multi line string multi line string

Nothing revolutional, just a bit cleaner and with
an indent (which is not necesserily always a good thing
but IMO a bit more presentable).
The problem though, this will require editors to
modify their lexers for highlighting - this is a problem :/


> My reaction #3: Not a fan of adding an '===' operator. We already have
> '=' and '=='. Javascript is another language that uses '===' to mean
> something completely different from this proposal (it's another
> equality operator) and it's a mess there. Come up with something else.
>

"===" is just the least disturbing one I've come up with while
experimenting. I thought it should start with "=" at least.
E.g.
data =%  T :
data =\\  T :
(\\  now is syntaxError: unexpected character after line continuation)

I dont know - frankly I think its too early to start the game of
perfect operator choice.


>> Benefits are easy to see: say I want a tuple of strings:
>>
>> data === T :
>>     "foo bar"
>>     "hello world"
>>     "to be continued..."
>>
>> VS current:
>>
>> data = (
>>     "foo bar" ,
>>     "hello world" ,
>>     "to be continued..." ,
>>     )
>>
>> Main problem with the latter are commas, it is not easy
>> to type
>
> In what bizarro world are commas harder to type than tabs? At least if
> I type a comma I know I'll get a comma. If I type a tab then it
> depends on my editor settings what I'll actually get.

Well, in the above case you don't have to type tabs or commas.
As for what character is easier to type : commas or tabs :
I find that Tab key is maybe a bit harder when using together
 with upper number row keys - OTOH when using keypad -
it feels easier. On average I think its comparable.
Also if you type commas, usually you want to type
space after a comma, or  a Tab  ;-)
So Tab maybe will win this race.


>> and, whats more important - hard to notice missing commas.
>
> But it's totally easy to notice missing tabs, right? Not.

**Those are two different things** - commas must be there -
and the issue persists, you want it or not.

I still have feeling that you try to imply that commas have
some role apart from Disambiguation of closely positioned
tokens - that's what they are from reader's POV.
In other words, if inter-token spacing is solid - commas are nothing
but redundant noise.
Do you understand this or not?

Also there was a topic about string lists on 'Ideas' recently -
so thats not only me who notices it.

Issues with input of tabs is more of psychology &
experience I'd say. I haven't problems with that.
Normally I input 2 tabs to make it form a solid whitespace- it
gives me optimal look. And I don't bother too much with
perfect alignment usually.


>> *Example 3. Two-dimensional tuple.*
>>
>> data === T/T :
>
> What about T/S? S/T? S/S? Are these allowed?

Not really. The idea is: to identify common cases
and data structures and try to find an optimal
set of ID's to represent them. But the slash
indicates that it's 2D case - so this one
is sort of explicit sign of higher dimension.

>
> Also, why is there a division operator here?

"slash"


>
>>     1    2    3    "hello"
>>     a    b    c + d    e     f
>>
>> is a synonym for:
>>
>> data = (
>>     (1, 2, 3, "hello") ,
>>     (a, b, c + d, e, f ) )
>
> If this is supposed to be a tabular format then why is the second row
> allowed to have a different number of elements than the first row?

why not ?

>
> What about named fields? Is there a proposal for extending this syntax
> to allow construction of dicts or namedtuples?

Maybe - though there already exist Python built-in methods to convert
e.g. tuples to dicts and lists.


>
>> The rule here is: TAB character is inner elements' separator, and the
>> new line is outer elements' separator. Line continuation
>> character is  \  (to help with long lines).
>
> So brackets and commas are too ugly, but line continuation characters
> are just fine?

Yes.


>> - implicit string concatenation disallowed
>
> So this would be a syntax error?
>
> foo === T:
>     "one" "two" "three"

Yes I think so.


>
> That seems reasonable, but what about this?
>
> foo === T/T:
>     "this is a very " \
>     "long string " \

This one not, I'd say it should give:
foo = (("this is a very ", "long string "))


M


From python at mrabarnett.plus.com  Fri May 11 23:01:43 2018
From: python at mrabarnett.plus.com (MRAB)
Date: Sat, 12 May 2018 04:01:43 +0100
Subject: PIP install
In-Reply-To: <c635d60f-313d-42e6-ba1b-dfab8b851ed5@googlegroups.com>
References: <c635d60f-313d-42e6-ba1b-dfab8b851ed5@googlegroups.com>
Message-ID: <2a2e9959-4659-59f6-4f08-28fa0c4b26e5@mrabarnett.plus.com>

On 2018-05-12 03:47, Sharan Basappa wrote:
> I have installed Python recently. Do I need to install PIP separately or this would be part of default installation. When I run pip install <>, windows complains that no such command exists
> 
That means that pip isn't on the Windows search path.

It might be better to call the pip module via the py launcher:

py -m pip install <>


From sharan.basappa at gmail.com  Fri May 11 23:12:07 2018
From: sharan.basappa at gmail.com (Sharan Basappa)
Date: Fri, 11 May 2018 20:12:07 -0700 (PDT)
Subject: PIP install
In-Reply-To: <mailman.149.1526094111.28519.python-list@python.org>
References: <c635d60f-313d-42e6-ba1b-dfab8b851ed5@googlegroups.com>
 <2a2e9959-4659-59f6-4f08-28fa0c4b26e5@mrabarnett.plus.com>
 <mailman.149.1526094111.28519.python-list@python.org>
Message-ID: <72f37171-dda0-42ad-8537-c55924c3898a@googlegroups.com>

On Saturday, 12 May 2018 08:32:04 UTC+5:30, MRAB  wrote:
> On 2018-05-12 03:47, Sharan Basappa wrote:
> > I have installed Python recently. Do I need to install PIP separately or this would be part of default installation. When I run pip install <>, windows complains that no such command exists
> > 
> That means that pip isn't on the Windows search path.
> 
> It might be better to call the pip module via the py launcher:
> 
> py -m pip install <>

thanks. i uninstalled and re-ininstalled with option to add python to my path. It works now. I could have simply added the python path to env variable but i did not realize the issue then. Thanks a lot


From sharan.basappa at gmail.com  Fri May 11 23:13:08 2018
From: sharan.basappa at gmail.com (Sharan Basappa)
Date: Fri, 11 May 2018 20:13:08 -0700 (PDT)
Subject: issue runing ipython
Message-ID: <0806f2fa-5f4b-4379-a11d-a22535f27d32@googlegroups.com>

I see an issue while running ipython.
Can anyone help please.

D:\Users\sharanb>ipython notebook
[TerminalIPythonApp] WARNING | Subcommand `ipython notebook` is deprecated and will be removed in future versions.
[TerminalIPythonApp] WARNING | You likely want to use `jupyter notebook` in the future
Traceback (most recent call last):
  File "d:\users\sharanb\appdata\local\programs\python\python37-32\lib\runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "d:\users\sharanb\appdata\l


From steve+comp.lang.python at pearwood.info  Sat May 12 00:29:45 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sat, 12 May 2018 04:29:45 +0000 (UTC)
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>
 <mailman.84.1525976408.28519.python-list@python.org>
 <2W3JC.64439$7b4.11219@fx12.am4>
 <CAPTjJmr+t3ivSpTqiGmD3DBJo8dba+5sriMffYRsdfVC+yRpSg@mail.gmail.com>
 <mailman.94.1525997497.28519.python-list@python.org>
 <NReJC.131905$I77.15095@fx44.am4>
 <CAPTjJmoSuHpYwwR-xV7RkNSM9a-HqnH-qQy0oZXosiQOvK8pOQ@mail.gmail.com>
 <mailman.133.1526045077.28519.python-list@python.org>
 <d2jJC.207297$jZ.48057@fx20.am4>
Message-ID: <pd5qjo$unn$1@blaine.gmane.org>

On Fri, 11 May 2018 16:56:09 +0100, bartc wrote:

> 0100, if not intended as octal, is
> an undetectable error in C and Python 2.

How fortunate then that Python 2 is history (soon to be ancient history) 
and people can use Python 3 where that error of judgement has been 
rectified.



-- 
Steve



From steve+comp.lang.python at pearwood.info  Sat May 12 00:50:43 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sat, 12 May 2018 04:50:43 +0000 (UTC)
Subject: issue runing ipython
References: <0806f2fa-5f4b-4379-a11d-a22535f27d32@googlegroups.com>
Message-ID: <pd5rr2$unn$2@blaine.gmane.org>

On Fri, 11 May 2018 20:13:08 -0700, Sharan Basappa wrote:

> I see an issue while running ipython. Can anyone help please.

Is the error message not clear enough? It tells you what the problem is 
("ipython notebook" is deprecated) and tells you how to fix it (use 
"jupyter notebook" instead).


> D:\Users\sharanb>ipython notebook
> [TerminalIPythonApp] WARNING | Subcommand `ipython notebook` is
> deprecated and will be removed in future versions. [TerminalIPythonApp]
> WARNING | You likely want to use `jupyter notebook` in the future
> Traceback (most recent call last):
>   File
>   "d:\users\sharanb\appdata\local\programs\python\python37-32\lib
\runpy.py",
>   line 193, in _run_module_as_main
>     "__main__", mod_spec)
>   File "d:\users\sharanb\appdata\l


I don't know what more there is to say that the error message doesn't 
already say. Have you tried running "jupyter notebook" instead? What 
happens?


-- 
Steve



From steve+comp.lang.python at pearwood.info  Sat May 12 00:54:14 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sat, 12 May 2018 04:54:14 +0000 (UTC)
Subject: Suggestion for a "data" object syntax
References: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
 <pcriqa$16m$13@blaine.gmane.org>
 <CAE6NSRCo8-dVWSAYuY8MHH6vviy_2Qn_LpGa2kRTN8L2=cceXQ@mail.gmail.com>
 <pcsf85$16m$15@blaine.gmane.org>
 <CAE6NSRALn2benyf+C87bCKSwRH3gzXcd1WHj_EawR9OngqbcSg@mail.gmail.com>
 <pctpo0$qbi$1@blaine.gmane.org>
 <CAE6NSRCBr=EOENJPxaUG4uMyToYg+ZX_KkW0SRaT8feCWzd9Tw@mail.gmail.com>
 <CALwzidksU9-2whNm=fLiM1vNVcCLZFCQd7QdANOVjeaSDdCdXQ@mail.gmail.com>
 <CAE6NSRDUjmZHZ7BgvgH_tEc3DC94S+787AtsB4iLn9ipYM+xbA@mail.gmail.com>
Message-ID: <pd5s1l$unn$3@blaine.gmane.org>

On Sat, 12 May 2018 02:26:05 +0300, Mikhail V wrote:

> it is just  not a trivial task to find an optimal solution to this

We already have an optimal solution to this.


* It works with any editor, including simple ones.

* It is safe for transmit over email, or on web forums, 
  so long as you avoid tabs and use spaces.

* It is readable by humans without them needing to distinguish
  between two different kinds of invisible space.

* It can be easily parsed by hand or by machine.

* It works with a multitude of text processing tools whether
  or not they can cope with tabs.

* It is resistant to many sorts of typos.

* It allows great flexibility in the presentation, you aren't
  forced to lay things out in one specific 2D format.

* It uses the same consistent rules for the rest of the language,
  without adding special cases and complexity.

* It is a tried-and-true solution that has been used (with minor
  modifications) for dozens, possibly hundreds, of programming
  languages, natural language lists and data formats.



-- 
Steve



From bob.martin at excite.com  Sat May 12 07:45:42 2018
From: bob.martin at excite.com (Bob Martin)
Date: Sat, 12 May 2018 07:45:42 BST
Subject: Meaning of abbreviated terms
References: <4f2a7e16-1b4d-4852-bc56-2d0b07c72209@googlegroups.com>
 <mailman.118.1526020227.28519.python-list@python.org>
Message-ID: <flngsmFi8t7U1@mid.individual.net>

in 793617 20180511 072806 Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
>On Fri, 11 May 2018 07:20:36 +0000, Bob Martin wrote:
>
>> in 793605 20180511 044309 T Berger <brgrt2 at gmail.com> wrote:
>>>On Saturday, May 5, 2018 at 6:45:46 PM UTC-4, MRAB wrote:
>>>> On 2018-05-05 17:57, T Berger wrote:
>>>> > What does the "p" in "plist" stand for? Is there a python glossary
>>>> > that spells out the meanings of abbreviated terms?
>>>> >
>>>> "plist" is "property list". It's listed in the Python documentation.
>>>
>>>Thanks for the answer. Missed it till now.
>>
>> In IBM-speak it was parameter list.
>
>
>
>But that's not where plists came from, was it? As I understand it, the
>plist data format was invented by Apple, and they called it a property
>list.

How old is Apple?
I was using plist for parameter list in OS/360 in 1965.


From rzzzwilson at gmail.com  Sat May 12 04:12:52 2018
From: rzzzwilson at gmail.com (Ross Wilson)
Date: Sat, 12 May 2018 15:12:52 +0700
Subject: Meaning of abbreviated terms
In-Reply-To: <flngsmFi8t7U1@mid.individual.net>
References: <4f2a7e16-1b4d-4852-bc56-2d0b07c72209@googlegroups.com>
 <mailman.118.1526020227.28519.python-list@python.org>
 <flngsmFi8t7U1@mid.individual.net>
Message-ID: <9b6166c5-b725-335c-19f9-4e8c6181d51b@gmail.com>

The "plist" abbreviation goes back to at least 1958 as it was used in 
the Lisp implementation [0].? And it may even predate Lisp.? I'm very 
sure that what actually went into a plist has often changed over the 
years, but the name persists.

Lisp also used "association lists" [1] which were a key/value data 
structure, usually called an "alist" or "a-list".

Ross

[0] https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node108.html
[1] https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node153.html


On 12/5/2561 BE 13:45, Bob Martin wrote:
> in 793617 20180511 072806 Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
>> On Fri, 11 May 2018 07:20:36 +0000, Bob Martin wrote:
>>
>>> in 793605 20180511 044309 T Berger <brgrt2 at gmail.com> wrote:
>>>> On Saturday, May 5, 2018 at 6:45:46 PM UTC-4, MRAB wrote:
>>>>> On 2018-05-05 17:57, T Berger wrote:
>>>>>> What does the "p" in "plist" stand for? Is there a python glossary
>>>>>> that spells out the meanings of abbreviated terms?
>>>>>>
>>>>> "plist" is "property list". It's listed in the Python documentation.
>>>> Thanks for the answer. Missed it till now.
>>> In IBM-speak it was parameter list.
>>
>>
>> But that's not where plists came from, was it? As I understand it, the
>> plist data format was invented by Apple, and they called it a property
>> list.
> How old is Apple?
> I was using plist for parameter list in OS/360 in 1965.



From greg.ewing at canterbury.ac.nz  Sat May 12 04:35:59 2018
From: greg.ewing at canterbury.ac.nz (Gregory Ewing)
Date: Sat, 12 May 2018 20:35:59 +1200
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <mailman.130.1526036342.28519.python-list@python.org>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>
 <mailman.84.1525976408.28519.python-list@python.org>
 <2W3JC.64439$7b4.11219@fx12.am4>
 <CAPTjJmr+t3ivSpTqiGmD3DBJo8dba+5sriMffYRsdfVC+yRpSg@mail.gmail.com>
 <mailman.94.1525997497.28519.python-list@python.org>
 <87o9hn82e9.fsf@elektro.pacujo.net> <fll7k7F3fvrU1@mid.individual.net>
 <pd3st7$uno$7@blaine.gmane.org>
 <mailman.130.1526036342.28519.python-list@python.org>
Message-ID: <flnnbhFk746U1@mid.individual.net>

Steven D'Aprano wrote:
> You had 
> computers with 6, 9, or even 60 bits per byte,

And some early machines were even weirder, e.g. the EDSAC
with effectively 17-bit words and 35-bit longwords.

-- 
Greg


From greg.ewing at canterbury.ac.nz  Sat May 12 04:44:29 2018
From: greg.ewing at canterbury.ac.nz (Gregory Ewing)
Date: Sat, 12 May 2018 20:44:29 +1200
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <mailman.132.1526044481.28519.python-list@python.org>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <87o9hn82e9.fsf@elektro.pacujo.net> <kS5JC.258835$sl2.255712@fx46.am4>
 <201805102136.26478.gheskett@shentel.net>
 <CAPTjJmoBT+Ra0f5km3U89S0s1FLOS1FBynHnRnigZkKROnTG2A@mail.gmail.com>
 <mailman.101.1526004454.28519.python-list@python.org>
 <fll8diF3k4vU1@mid.individual.net>
 <CAPTjJmoK-kxhH+pE+fnfXg4PQ=kyaytDdgAa__TiCuL=Td0qXg@mail.gmail.com>
 <mailman.132.1526044481.28519.python-list@python.org>
Message-ID: <flnnrdFk9rdU1@mid.individual.net>

Chris Angelico wrote:
> Tack setuid onto "owner", setgid onto "group", and sticky
> onto "others"? Pretty arbitrary, and disrupts the fundamental meaning
> of each set.

Yes, it would be totally silly if e.g. the "ls" command were
to regroup them that way when displaying the permission bits...
oh, wait...

% echo > blarg.txt
% chmod 7777 blarg.txt
% ls -l blarg.txt
-rwsrwsrwt  1 greg  staff  1 12 May 20:40 blarg.txt

-- 
Greg


From greg.ewing at canterbury.ac.nz  Sat May 12 04:58:32 2018
From: greg.ewing at canterbury.ac.nz (Gregory Ewing)
Date: Sat, 12 May 2018 20:58:32 +1200
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <871sei8iyy.fsf@elektro.pacujo.net>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>	<CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>	<mailman.73.1525951709.28519.python-list@python.org>	<dy_IC.301544$gE6.154866@fx06.am4>	<CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>	<mailman.84.1525976408.28519.python-list@python.org>	<2W3JC.64439$7b4.11219@fx12.am4>	<CAPTjJmr+t3ivSpTqiGmD3DBJo8dba+5sriMffYRsdfVC+yRpSg@mail.gmail.com>	<mailman.94.1525997497.28519.python-list@python.org>	<87o9hn82e9.fsf@elektro.pacujo.net>
 <kS5JC.258835$sl2.255712@fx46.am4>	<87vabunzye.fsf@bsb.me.uk>
 <871sei8iyy.fsf@elektro.pacujo.net>
Message-ID: <flnolqFkg7fU1@mid.individual.net>

Marko Rauhamaa wrote:
> I'm
> guessing using letters as digits felt awkward among computer people for
> a long time.

I think you may be underestimating how much weirdness
early computer programmers were willing to accept.
If you think using letters as hex digits is awkward,
you should check out what EDSAC programmers had to
put up with.

-- 
Greg


From rosuav at gmail.com  Sat May 12 05:19:24 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 12 May 2018 19:19:24 +1000
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <flnnrdFk9rdU1@mid.individual.net>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <87o9hn82e9.fsf@elektro.pacujo.net> <kS5JC.258835$sl2.255712@fx46.am4>
 <201805102136.26478.gheskett@shentel.net>
 <CAPTjJmoBT+Ra0f5km3U89S0s1FLOS1FBynHnRnigZkKROnTG2A@mail.gmail.com>
 <mailman.101.1526004454.28519.python-list@python.org>
 <fll8diF3k4vU1@mid.individual.net>
 <CAPTjJmoK-kxhH+pE+fnfXg4PQ=kyaytDdgAa__TiCuL=Td0qXg@mail.gmail.com>
 <mailman.132.1526044481.28519.python-list@python.org>
 <flnnrdFk9rdU1@mid.individual.net>
Message-ID: <CAPTjJmrgWO5mLmAk2qH7O_wk=uj54DcyHdic6cRYXUDVvSuDKg@mail.gmail.com>

On Sat, May 12, 2018 at 6:44 PM, Gregory Ewing
<greg.ewing at canterbury.ac.nz> wrote:
> Chris Angelico wrote:
>>
>> Tack setuid onto "owner", setgid onto "group", and sticky
>> onto "others"? Pretty arbitrary, and disrupts the fundamental meaning
>> of each set.
>
>
> Yes, it would be totally silly if e.g. the "ls" command were
> to regroup them that way when displaying the permission bits...
> oh, wait...
>
> % echo > blarg.txt
> % chmod 7777 blarg.txt
> % ls -l blarg.txt
> -rwsrwsrwt  1 greg  staff  1 12 May 20:40 blarg.txt

That's a hack to fit it into a fixed *display* width. And there are
quite a few weirdnesses to make that work. Not something I would
recommend except when, as here, backward compat is critical.

ChrisA


From bc at freeuk.com  Sat May 12 07:00:59 2018
From: bc at freeuk.com (bartc)
Date: Sat, 12 May 2018 12:00:59 +0100
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <mailman.150.1526099528.28519.python-list@python.org>
References: <356c4123-7519-7ca2-d23d-a870cf038f4e@it.uu.se>
 <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CANc-5UxpgPynkhNC6=pT+j9uKx26U2B_j7bsq2ZAuEs2nWjXHg@mail.gmail.com>
 <mailman.84.1525976408.28519.python-list@python.org>
 <2W3JC.64439$7b4.11219@fx12.am4>
 <CAPTjJmr+t3ivSpTqiGmD3DBJo8dba+5sriMffYRsdfVC+yRpSg@mail.gmail.com>
 <mailman.94.1525997497.28519.python-list@python.org>
 <NReJC.131905$I77.15095@fx44.am4>
 <CAPTjJmoSuHpYwwR-xV7RkNSM9a-HqnH-qQy0oZXosiQOvK8pOQ@mail.gmail.com>
 <mailman.133.1526045077.28519.python-list@python.org>
 <d2jJC.207297$jZ.48057@fx20.am4> <pd5qjo$unn$1@blaine.gmane.org>
 <mailman.150.1526099528.28519.python-list@python.org>
Message-ID: <sPzJC.125816$Vs7.82684@fx41.am4>

On 12/05/2018 05:29, Steven D'Aprano wrote:
> On Fri, 11 May 2018 16:56:09 +0100, bartc wrote:
> 
>> 0100, if not intended as octal, is
>> an undetectable error in C and Python 2.
> 
> How fortunate then that Python 2 is history (soon to be ancient history)
> and people can use Python 3 where that error of judgement has been
> rectified.

At least you're agreeing it was a mistake.

Although it does still mean that Python 3 has this funny quirk:

   a = 00000           # ok
   a = 00123.          # ok
   a = int("00123")    # ok
   a = 00123           # error


-- 
bartc


From mikhailwas at gmail.com  Sat May 12 10:07:17 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Sat, 12 May 2018 17:07:17 +0300
Subject: Suggestion for a "data" object syntax
In-Reply-To: <pd5s1l$unn$3@blaine.gmane.org>
References: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
 <pcriqa$16m$13@blaine.gmane.org>
 <CAE6NSRCo8-dVWSAYuY8MHH6vviy_2Qn_LpGa2kRTN8L2=cceXQ@mail.gmail.com>
 <pcsf85$16m$15@blaine.gmane.org>
 <CAE6NSRALn2benyf+C87bCKSwRH3gzXcd1WHj_EawR9OngqbcSg@mail.gmail.com>
 <pctpo0$qbi$1@blaine.gmane.org>
 <CAE6NSRCBr=EOENJPxaUG4uMyToYg+ZX_KkW0SRaT8feCWzd9Tw@mail.gmail.com>
 <CALwzidksU9-2whNm=fLiM1vNVcCLZFCQd7QdANOVjeaSDdCdXQ@mail.gmail.com>
 <CAE6NSRDUjmZHZ7BgvgH_tEc3DC94S+787AtsB4iLn9ipYM+xbA@mail.gmail.com>
 <pd5s1l$unn$3@blaine.gmane.org>
Message-ID: <CAE6NSRDRqaocKW77_odMxfMx7WKPmH5J-9kxVggo=gx07Bw4ig@mail.gmail.com>

On Sat, May 12, 2018 at 7:54 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Sat, 12 May 2018 02:26:05 +0300, Mikhail V wrote:
>
>> it is just  not a trivial task to find an optimal solution to this
>
> We already have an optimal solution to this.

Yes. current syntax will not go anyway so proposal
addresses cases where it is appropriate and
clearly better.

>
> * It works with any editor, including simple ones.

Ok

> * It is safe for transmit over email, or on web forums,
>   so long as you avoid tabs and use spaces.

I don't use spaces so I'm out of luck already.

> * It is readable by humans without them needing to distinguish
>   between two different kinds of invisible space.

I'm using tabs from childhood and don't find it a problem.

> * It can be easily parsed by hand or by machine.

Parsed by hand?

> * It works with a multitude of text processing tools whether
>   or not they can cope with tabs.

Ok. But this is bullet #1, see above, you repeat it

>
> * It is resistant to many sorts of typos.

Here I think you oversimplify - In fact current syntax
introduces typing problems in many cases:
as a user with very high proficiency in typing and
good sight, I have some trouble inputting nested bracketed
arrays  and spend some time trying to match
corresponding suites. Plus the comma noise here,
so your statement is too one-sided and overestimated.

As said, I remember this and similar issues were raised on 'ideas'
so don't pretend it does not exist.

>
> * It allows great flexibility in the presentation, you aren't
>   forced to lay things out in one specific 2D format.

Only words - but nothing concrete

> * It uses the same consistent rules for the rest of the language,
>   without adding special cases and complexity.

I'll grant you for "special cases", but the rest is quite contradictive.
As said, Python uses indented blocks - not bracketed
blocks as in C.
Python does not make semicolons mandatory.
All this is a great improvement, but it seems you
don't see the parallel here.


> * It is a tried-and-true solution that has been used (with minor
>   modifications) for dozens, possibly hundreds, of programming
>   languages, natural language lists and data formats.

> "natural language lists and data formats"

OTOH all _real_ data list, tables, matrices do not include redundant commas,
unless it is really needed.
Any book, lectures, etc. presents them without commas so its
second nature to any human to see it without commas
and its just better so.



M


From ian.g.kelly at gmail.com  Sat May 12 10:38:35 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Sat, 12 May 2018 08:38:35 -0600
Subject: Suggestion for a "data" object syntax
In-Reply-To: <CAE6NSRDUjmZHZ7BgvgH_tEc3DC94S+787AtsB4iLn9ipYM+xbA@mail.gmail.com>
References: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
 <pcriqa$16m$13@blaine.gmane.org>
 <CAE6NSRCo8-dVWSAYuY8MHH6vviy_2Qn_LpGa2kRTN8L2=cceXQ@mail.gmail.com>
 <pcsf85$16m$15@blaine.gmane.org>
 <CAE6NSRALn2benyf+C87bCKSwRH3gzXcd1WHj_EawR9OngqbcSg@mail.gmail.com>
 <pctpo0$qbi$1@blaine.gmane.org>
 <CAE6NSRCBr=EOENJPxaUG4uMyToYg+ZX_KkW0SRaT8feCWzd9Tw@mail.gmail.com>
 <CALwzidksU9-2whNm=fLiM1vNVcCLZFCQd7QdANOVjeaSDdCdXQ@mail.gmail.com>
 <CAE6NSRDUjmZHZ7BgvgH_tEc3DC94S+787AtsB4iLn9ipYM+xbA@mail.gmail.com>
Message-ID: <CALwzidmY7JNt1FRzCS7g2GbBq68w54F5jpfT5UcXD+J9Wpzgbg@mail.gmail.com>

On Fri, May 11, 2018 at 5:26 PM, Mikhail V <mikhailwas at gmail.com> wrote:
> On Fri, May 11, 2018 at 9:12 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
>> On Thu, May 10, 2018 at 6:34 PM, Mikhail V <mikhailwas at gmail.com> wrote:
>>> Do you understand that basically any python code sent by e-mail converts tabs to
>>> spaces, thus the only way to receive it - is to send binary file?
>>
>> Um, no, this is false. We send Python code by email all the time.
>> 1) Tabs as indentation: Python permits the use of both tabs and spaces
>
> This means if I paste some code _inside_ an existing  block,
> I get a Syntax error:
> "TabError: inconsistent use of tabs and spaces in indentation"

You can't generally paste code into other contexts and expect it to
just work without any editing, for more reasons than the tabs / spaces
issue. This doesn't have to do with emailing code.

>> 3) Tabs that appear in strings: This one I'll grant you.
>
> This too.
>
> So what is false?

Your absurd assertion that the only way to safely email Python code is
as a binary file.

>> In any case, the use of tabs is entirely optional. For the most part,
>> programs can be safely emailed whether they contain tabs or not, the
>
> In real situation just send as attachment, with or without such
> syntax, it will be
> more polite and safe if you wish the person to run the program.
> For some talks in email its not *far* worse than now.

Note that this mailing list does not permit the use of attachments.
Pastebin is fine, but for small snippets it's much simpler just to
include them inline.

>>> Yes, I have told already that there are _some_ cases when
>>>  tabulation formatting can cause visual confusion.
>>> *But why do you blame me*?
>>> It just the issues with editor's incompleteness.
>>
>> That's great, but if I'm editing a file on an embedded system over a
>> serial port and the only editor I have available is nano, I should be
>> able to use it. You can't just assume that everybody has a fully
>> featured editor (and knows how to use it -- what was that point you
>> made just above about beginners?)
>
> Wait, wait, wait - we are adult people - what problem causes nano?
> I don't have nano so maybe you can tell what happens in nano if you
> load for example a text file this:
>
> ?a + b ?? a + b ??a + b  ??a + b
> ?1 ?? 2 ?? 3 ?? 4
> ?width:??????100% ??!important;
>
> In the above example one arrow ? is one tab char.
> What exact problem do you experience?

I have no specific problems. It was just an example of a simple editor
without support for fancy features like viewing tabs and spaces, in an
environment where a more feature-rich editor may not be available.

>>>>> I don't want spaces or tabs visible - there is toggle "show tabs"
>>>>> and "toggle show space" for that
>
>> Needing to fiddle with editor settings in order to determine how the
>> code in front of me that somebody else wrote is organized doesn't
>> sound to me like a good feature. That sounds to me like poor
>> readability.
>>
>
> Sorry, not sure what you mean. Do you propose _visible_ character
> instead of e.g. tab? But then you need to hide it to be able
> to read normally.

Why would I need to hide the separator character in order to be able
to read the data?

>>>     "So the idea is to _hide brackets for_ first two levels of
>>>     nesting of course."
>>
>> In other words, this syntax is really not appropriate for more than
>> two levels of nesting due to the mental gymnastics required to keep
>> track of how the current level of nesting should be expressed.
>
> No. How you come up to this conclusion?
> it is just  not a trivial task to find an optimal solution to this -
> on the one hand it must be feasible to parse, on the other hand
> presentable to the reader. Initial  idea is just use current
> Python syntax for further nesting:
>
> image === T/T:
>     (127,127,127)        (127,127,127)        (127,127,127)
>     (127,127,127)        (127,127,127)        (127,127,127)
>     (127,127,127)        (127,127,127)        (127,127,127)
>     (127,127,127)        (127,127,127)        (127,127,127)
>
> vs:
>
> image = (
>     ((127,127,127), (127,127,127), (127,127,127),),
>     ((127,127,127), (127,127,127), (127,127,127),),
>     ((127,127,127), (127,127,127), (127,127,127),),
>     ((127,127,127), (127,127,127), (127,127,127),),
>     )

And if you have more than three levels of nesting, and you don't
conveniently just have a bunch of 3-tuples that line up perfectly with
one another?

> Seriously I find it quite an improvement both for
> readability and type-ability.
> I see you keep denying it for some unknown reason,
> but well, its up to your conscience.

I'm not sure what my conscience has to do with it.


From mikhailwas at gmail.com  Sat May 12 12:06:44 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Sat, 12 May 2018 19:06:44 +0300
Subject: Suggestion for a "data" object syntax
In-Reply-To: <CALwzidmY7JNt1FRzCS7g2GbBq68w54F5jpfT5UcXD+J9Wpzgbg@mail.gmail.com>
References: <CAE6NSRCjLyxBTD=dMkw0Ky9HfebO_SRkoPzk1LgDtA=noNkezw@mail.gmail.com>
 <pcriqa$16m$13@blaine.gmane.org>
 <CAE6NSRCo8-dVWSAYuY8MHH6vviy_2Qn_LpGa2kRTN8L2=cceXQ@mail.gmail.com>
 <pcsf85$16m$15@blaine.gmane.org>
 <CAE6NSRALn2benyf+C87bCKSwRH3gzXcd1WHj_EawR9OngqbcSg@mail.gmail.com>
 <pctpo0$qbi$1@blaine.gmane.org>
 <CAE6NSRCBr=EOENJPxaUG4uMyToYg+ZX_KkW0SRaT8feCWzd9Tw@mail.gmail.com>
 <CALwzidksU9-2whNm=fLiM1vNVcCLZFCQd7QdANOVjeaSDdCdXQ@mail.gmail.com>
 <CAE6NSRDUjmZHZ7BgvgH_tEc3DC94S+787AtsB4iLn9ipYM+xbA@mail.gmail.com>
 <CALwzidmY7JNt1FRzCS7g2GbBq68w54F5jpfT5UcXD+J9Wpzgbg@mail.gmail.com>
Message-ID: <CAE6NSRD4kL1kKwZ_86+LA39DQ3yf8CQ_ipMEhA=KpHeif7Wa6g@mail.gmail.com>

On Sat, May 12, 2018 at 5:38 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Fri, May 11, 2018 at 5:26 PM, Mikhail V <mikhailwas at gmail.com> wrote:
>> On Fri, May 11, 2018 at 9:12 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
>>> On Thu, May 10, 2018 at 6:34 PM, Mikhail V <mikhailwas at gmail.com> wrote:
>>>> Do you understand that basically any python code sent by e-mail converts tabs to
>>>> spaces, thus the only way to receive it - is to send binary file?

>> So what is false?
>
> Your absurd assertion that the only way to safely email Python code is
> as a binary file.

Why you say so? You have agreed yourself with the assertion.
Also I did not say "safe" but meant that I cannot receive the exact file
in the body of e-mail in case of tabs.


> no support for _fancy features_ like viewing tabs and spaces

:\
is syntax highlighting fancy feature?


>> Sorry, not sure what you mean. Do you propose _visible_ character
>> instead of e.g. tab? But then you need to hide it to be able
>> to read normally.
>
> Why would I need to hide the separator character in order to be able
> to read the data?

So you find e.g. this ok:
?1 ?? 2 ?? 3 ?? 4

>> presentable to the reader. Initial  idea is just use current
>> Python syntax for further nesting:
>>
>> image === T/T:
>>     (127,127,127)        (127,127,127)        (127,127,127)
>>     (127,127,127)        (127,127,127)        (127,127,127)
>>     (127,127,127)        (127,127,127)        (127,127,127)
>>
>> vs:
>> image = (
>>     ((127,127,127), (127,127,127), (127,127,127),),
>>     ((127,127,127), (127,127,127), (127,127,127),),
>>     ((127,127,127), (127,127,127), (127,127,127),),
>>     )
>
> And if you have more than three levels of nesting, and you don't
> conveniently just have a bunch of 3-tuples that line up perfectly with
> one another?

Maybe you can come up with some example in current syntax?
I have browsed some projects with a lot of resource definitions.
sometimes it has 3-4 levels of nesting, and I have hard time
understanding the structure - so maybe it is possible to simplify
those according to this syntax.


From python at bladeshadow.org  Sat May 12 22:42:13 2018
From: python at bladeshadow.org (Python)
Date: Sat, 12 May 2018 21:42:13 -0500
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <7s86fd1bncg5hovboehvvqe57budhc2bf8@4ax.com>
 <CAPTjJmqq0B=qyvba8t8cuJGiACNJwfFpmXVkUb_3oMkh0Jg+vg@mail.gmail.com>
Message-ID: <20180513024213.GG12850@bladeshadow.org>

On Wed, May 09, 2018 at 03:09:18PM +1000, Chris Angelico wrote:
> On Wed, May 9, 2018 at 1:48 PM, Python <python at bladeshadow.org> wrote:
[much snippage...]
> >     flag = (spam == arg)
>
> That's not "side effects only". 

Yeah, I'll chalk that up to posting too late in the evening after
working too long a day...  

On Wed, May 09, 2018 at 12:46:07PM -0400, Dennis Lee Bieber wrote:
> On Tue, 8 May 2018 22:48:52 -0500, Python <python at bladeshadow.org>
> >    if spam == arg:
> 
> 	Mis-typing that as
> 
> 	if spam = arg:
> 
> IS the problem -- you've just changed the value bound to spam, and will
> then branch based upon the new value and not a comparison of values.

Yes, I'm well aware.  While I may have been momentarily confused about
the side effects question, if you read my post I was clearly not
confused about this.  Nor do I think anyone else who pposted in the
thread needed it explained.

Responding to this further would essentially just require me to
reiterate what I already wrote--I won't do that.  I'll simply maintain
that in my rather lenghty experience, this mistake has actually been
rather rare and has to my knowledge *never* caused a support issue
requiring a bug fix to production code in projects I've been
associated with.  It's a useful construction whose detriment has, IMO,
been completely overblown.



From python at bladeshadow.org  Sat May 12 22:52:05 2018
From: python at bladeshadow.org (Python)
Date: Sat, 12 May 2018 21:52:05 -0500
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <CALwzidk424PzRwWoD3qWU=Yo4=pc9pRMv9NRpMZtgrscG0E4Lg@mail.gmail.com>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
Message-ID: <20180513025205.GH12850@bladeshadow.org>

On Tue, May 08, 2018 at 11:36:06PM -0600, Ian Kelly wrote:
> On Tue, May 8, 2018 at 9:48 PM, Python <python at bladeshadow.org> wrote:
> > I'll give you an example that is both a case where Python's design
> > choices make creating a bug easier, AND a case where allowing
> > assignments to be expressions would save you.
> >
> >     flag = we_are_done()
> >     while not flag:
> >         # do some stuff
> >         ...
> >         if error_occured():
> >             break
> >         falg = we_are_done()
> >     notify_user()
> >    # flag will be checked again later, perhaps for error reporting
> 
> while True:
>     if we_are_done():
>         break
>     # do some stuff
>     ...
>     if error_occurred():
>         break
> notify_user()
> 
> Fixed, using idiomatic Python and without needing to use assignment in
> an expression.

Two points:

1. I think the ensuing discussion clearly enough demonstrates that
   this isn't necessarily considered the most idiomatic Python.  I
   would go so far as to say it demonstrates that there's no such
   thing in actuality, in that different "experts" will have different
   opinions about what is or is not Pythonic.

2. Even if there was a definitive standard as to what is or is not
   idiomatic Python, no one is required to write it or care about it,
   and I would estimate that the vast majority of people who write
   Python don't.  People tend to use constructions they're familiar
   with and/or comfortable with, until they discover for themselves a
   reason not to.

On Thu, May 10, 2018 at 08:38:39PM -0600, Ian Kelly wrote:
> In what way does "while True" in the general case pretend to be an
> infinite loop? The break / return is right there for anyone to see.

It doesn't pretend at all, it simply is.  Its loop condition is a
constant which will require the loop to continue indefinitely--in the
general case--without intervention from some other control feature, in
the specific.



From rosuav at gmail.com  Sat May 12 23:01:04 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sun, 13 May 2018 13:01:04 +1000
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <20180513024213.GG12850@bladeshadow.org>
References: <7s86fd1bncg5hovboehvvqe57budhc2bf8@4ax.com>
 <CAPTjJmqq0B=qyvba8t8cuJGiACNJwfFpmXVkUb_3oMkh0Jg+vg@mail.gmail.com>
 <20180513024213.GG12850@bladeshadow.org>
Message-ID: <CAPTjJmoEyQiCh3tx5u-_Q7XvzTENKO1fHSLD-X46rLLXfyk7bA@mail.gmail.com>

On Sun, May 13, 2018 at 12:42 PM, Python <python at bladeshadow.org> wrote:
> On Wed, May 09, 2018 at 12:46:07PM -0400, Dennis Lee Bieber wrote:
>> On Tue, 8 May 2018 22:48:52 -0500, Python <python at bladeshadow.org>
>> >    if spam == arg:
>>
>>       Mis-typing that as
>>
>>       if spam = arg:
>>
>> IS the problem -- you've just changed the value bound to spam, and will
>> then branch based upon the new value and not a comparison of values.
>
> Yes, I'm well aware.  While I may have been momentarily confused about
> the side effects question, if you read my post I was clearly not
> confused about this.  Nor do I think anyone else who pposted in the
> thread needed it explained.
>
> Responding to this further would essentially just require me to
> reiterate what I already wrote--I won't do that.  I'll simply maintain
> that in my rather lenghty experience, this mistake has actually been
> rather rare and has to my knowledge *never* caused a support issue
> requiring a bug fix to production code in projects I've been
> associated with.  It's a useful construction whose detriment has, IMO,
> been completely overblown.
>

That's fine. Your experience has been that it hasn't been a problem;
other people's experience has been the opposite. I have never
personally had to deal with bugs in C code where braces are omitted
and multiple lines indented. Great! But that doesn't mean it's not a
problem, or at least a risk.

Guido has firmly stated that this is not going to happen in Python.
The '=' operator is NOT going to become an expression. You may as well
stop posting about it, because it's not going to change.

ChrisA


From python at bladeshadow.org  Sat May 12 23:08:10 2018
From: python at bladeshadow.org (Python)
Date: Sat, 12 May 2018 22:08:10 -0500
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <CALwzid=Vq19B2Hs5vKbKEhD51o=B4zxkMM8V6pz0R0z-wba8ew@mail.gmail.com>
Message-ID: <20180513030810.GI12850@bladeshadow.org>

Drat, missed the main point I wanted to address in my last post:

On Tue, May 08, 2018 at 11:36:06PM -0600, Ian Kelly wrote:
> > This example also is a case FOR allowing assignments to be
> > expressions.  If Python allowed them, you could rewrite this as:
> >
> >    while not (flag = we_are_done()):
> >         ...
> >         if error_occured():
> >             break
> >    notify_user()
> >    # flag will be checked again later, perhaps for error reporting
> >
> > This COMPLETELY PREVENTS the spelling bug in the code above, since the
> > assignment only happens in one place; and as a bonus it's less code.
> 
> Or just use an IDE with variable name autocompletion.

Every time, without fail?  Probably not going to happen, no matter who
you are.  FWIW I *do* use an editor with autocompletion--I never use
it because in the common case it's faster for me to just type whatever
I'm typing.  But this solution--dictating *how* people work, to
overcome a limitation of the language--is a horrible one.

Besides, your entire response missed the point completely..  All of
the examples you "fixed" were just trivial academic examples designed
to illustrate the problem.  In real code, particularly in a complex
project, the spelling bug is easier to cause and harder to find, and
just rewriting your while loop probably won't do.

My ultimate point was no matter what constructions you allow or don't
allow, coders are human and they're gonna screw it up, and some of
those mistakes will get past all of your well-intentioned bug traps.
Protecting coders from themselves is not a good reason to exclude
useful language constructs.  It's a reason to have good coders, good
process, and good testing.

And if your code reviews won't catch well-known programming pitfalls,
what good are they?



From python at bladeshadow.org  Sat May 12 23:14:50 2018
From: python at bladeshadow.org (Python)
Date: Sat, 12 May 2018 22:14:50 -0500
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <CAPTjJmoEyQiCh3tx5u-_Q7XvzTENKO1fHSLD-X46rLLXfyk7bA@mail.gmail.com>
References: <7s86fd1bncg5hovboehvvqe57budhc2bf8@4ax.com>
 <CAPTjJmqq0B=qyvba8t8cuJGiACNJwfFpmXVkUb_3oMkh0Jg+vg@mail.gmail.com>
 <20180513024213.GG12850@bladeshadow.org>
 <CAPTjJmoEyQiCh3tx5u-_Q7XvzTENKO1fHSLD-X46rLLXfyk7bA@mail.gmail.com>
Message-ID: <20180513031450.GJ12850@bladeshadow.org>

On Sun, May 13, 2018 at 01:01:04PM +1000, Chris Angelico wrote:
> That's fine. Your experience has been that it hasn't been a problem;
> other people's experience has been the opposite. I have never
> personally had to deal with bugs in C code where braces are omitted
> and multiple lines indented. Great! But that doesn't mean it's not a
> problem, or at least a risk.

Every line of code you write is a risk, regardless of whether it's in
a class of some language designer's hated constructs, or not... until
your code is thoroughly tested.  [And even then...]

> Guido has firmly stated that this is not going to happen in Python.
> The '=' operator is NOT going to become an expression. You may as well
> stop posting about it, because it's not going to change.

I'm well aware of this too, but I don't think that precludes reasoned
discussion of whether or not the construct is deserving of its most
hated status.  A large portion of what is discussed in this forum is
philosophical, and entirely unpractical.



From python at bladeshadow.org  Sat May 12 23:49:13 2018
From: python at bladeshadow.org (Python)
Date: Sat, 12 May 2018 22:49:13 -0500
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <pcu1so$qbi$2@blaine.gmane.org>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <pcu1so$qbi$2@blaine.gmane.org>
Message-ID: <20180513034913.GK12850@bladeshadow.org>

On Wed, May 09, 2018 at 05:44:57AM +0000, Steven D'Aprano wrote:
> > On Tue, May 08, 2018 at 12:45:29AM +0000, Steven D'Aprano wrote:
> >> Currently, the real reason is that lambda expressions are limited to a
> >> single expression as the body of the function, and binding operations
> >> in Python are statements.
> > 
> > ...which begs the question, why shouldn't assignments be expressions, as
> > they are in many other languages?  TBH this is one of the few things
> > about Python that I dislike.
> 
> No, it raises the question :-) Begging the question means to assume the 
> answer to the same question you are asking.

In formal logic perhaps, but not in colloquial speech.  Search google
for "beg the question"--what it will give you is exactly how I used
it. [The question is begged for on account of being the obvious
question to ask...]

> As Chris already pointed out, there is a PEP in progress at the moment 
> aimed at allowing assignment expressions (PEP 572). It is very 
> controversial, but Guido appears to be in favour of it (as I am, although 
> not necessarily in its current form). 

Well, obviously I'm a fan of the idea...

> If all programmers were as awesome as you and never made typos, the world 
> would be a better place. 

HA!  I make plenty of mistakes, but I think it's fair to say that when
most reasonably competent programmers have a bit of experience under
their belt, some bug or other has bitten them enough as fledgelings
that they become paranoid about it and just never do it again.  It
does seem that for many of my contemporaries, this is one of those...

When I took C ages ago the text I used had a "pitfalls" section at the
end of every major section, and this was one of the items it
mentioned.  I do think having been exposed to those ideas so early
greatly benefieted me in this regard, and I've found it sorely lacking
in many programming texts I've read in the many years since.  Perhaps
an insufficient focus on programming pitfalls in modern programs is
the reason we're in this mess...



From python at bladeshadow.org  Sun May 13 00:31:20 2018
From: python at bladeshadow.org (Python)
Date: Sat, 12 May 2018 23:31:20 -0500
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <CAPTjJmp5GyJi1BGCkag3GoatOHVH=umd831J3x+iukpK0FcNHA@mail.gmail.com>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <pcu1so$qbi$2@blaine.gmane.org>
 <CAPTjJmp5GyJi1BGCkag3GoatOHVH=umd831J3x+iukpK0FcNHA@mail.gmail.com>
Message-ID: <20180513043120.GL12850@bladeshadow.org>

On Wed, May 09, 2018 at 03:57:35PM +1000, Chris Angelico wrote:
> On Wed, May 9, 2018 at 3:44 PM, Steven D'Aprano
> > If all programmers were as awesome as you and never made typos, the world
> > would be a better place. But we know from experience that even
> > experienced C programmers can make this mistake by accident.
> 
> Yes, and I'd go further: I *am* too stupid to get this right. 

No, you are not.  Do you ever say "dog" when you mean "dot" instead?
Do you ever say "dad" when you mean "mom" instead?  Internalize that
"=" is "equals" (or "assigns" if you prefer) and "==" is "is equal to"
then use those phrases in your head when you're thinking about which
one you need in your code, and I'm pretty sure you'll stop making this
mistake.  It may help that the phrase with twice as many syllables
represents the operator that has twice as many characters.  Eventually
it becomes second nature, like not calling Dad "Mom."




From rosuav at gmail.com  Sun May 13 00:42:48 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sun, 13 May 2018 14:42:48 +1000
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <20180513043120.GL12850@bladeshadow.org>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org> <pcu1so$qbi$2@blaine.gmane.org>
 <CAPTjJmp5GyJi1BGCkag3GoatOHVH=umd831J3x+iukpK0FcNHA@mail.gmail.com>
 <20180513043120.GL12850@bladeshadow.org>
Message-ID: <CAPTjJmopiuzEN8MqtJwGpB8+wK=a-8z2jGRn4W6_scbZU1HLdg@mail.gmail.com>

On Sun, May 13, 2018 at 2:31 PM, Python <python at bladeshadow.org> wrote:
> On Wed, May 09, 2018 at 03:57:35PM +1000, Chris Angelico wrote:
>> On Wed, May 9, 2018 at 3:44 PM, Steven D'Aprano
>> > If all programmers were as awesome as you and never made typos, the world
>> > would be a better place. But we know from experience that even
>> > experienced C programmers can make this mistake by accident.
>>
>> Yes, and I'd go further: I *am* too stupid to get this right.
>
> No, you are not.  Do you ever say "dog" when you mean "dot" instead?
> Do you ever say "dad" when you mean "mom" instead?  Internalize that
> "=" is "equals" (or "assigns" if you prefer) and "==" is "is equal to"
> then use those phrases in your head when you're thinking about which
> one you need in your code, and I'm pretty sure you'll stop making this
> mistake.  It may help that the phrase with twice as many syllables
> represents the operator that has twice as many characters.  Eventually
> it becomes second nature, like not calling Dad "Mom."

Riiiight, of course. Because prevention of bugs is just a matter of
wanting to. You remind me of a previous boss of mine, who didn't
understand why debugging ever had to happen - he thought that if the
programmers he employed would just take a bit more care, they could
write perfect code.

And commits like this never happen:
https://github.com/Rosuav/MustardMine/commit/ca0b1f47b2fe4438caea549410e1f1296798ba56

Let me break it to you gently: you are flat out wrong. Yep, that's as
gentle as I can make it.

ChrisA


From steve+comp.lang.python at pearwood.info  Sun May 13 07:05:48 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sun, 13 May 2018 11:05:48 +0000 (UTC)
Subject: seeking deeper (language theory) reason behind Python design
 choice
References: <7s86fd1bncg5hovboehvvqe57budhc2bf8@4ax.com>
 <20180513024213.GG12850@bladeshadow.org>
Message-ID: <pd966b$unn$4@blaine.gmane.org>

On Sat, 12 May 2018 21:42:13 -0500, Python wrote:

> Responding to this further would essentially just require me to
> reiterate what I already wrote--I won't do that.  I'll simply maintain
> that in my rather lenghty experience, this mistake has actually been
> rather rare and has to my knowledge *never* caused a support issue
> requiring a bug fix to production code in projects I've been associated
> with.  It's a useful construction whose detriment has, IMO, been
> completely overblown.

I already linked to the attempt to install a backdoor in the Linux kernel 
with this, but even for accidental errors, thirty seconds on the CVE 
database finds at least one real-world example:

https://www.cvedetails.com/cve/CVE-2009-4633/


I expect that these days it will be rare, since most C compilers would 
default to warning about it if you run with warnings enabled.


-- 
Steve



From rosuav at gmail.com  Sun May 13 07:46:48 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sun, 13 May 2018 21:46:48 +1000
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <pd966b$unn$4@blaine.gmane.org>
References: <7s86fd1bncg5hovboehvvqe57budhc2bf8@4ax.com>
 <20180513024213.GG12850@bladeshadow.org>
 <pd966b$unn$4@blaine.gmane.org>
Message-ID: <CAPTjJmpp=wqgSQ0sWXsh6jnDDYTHtNkO1Ct1BGQqTe1iD8exqQ@mail.gmail.com>

On Sun, May 13, 2018 at 9:05 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Sat, 12 May 2018 21:42:13 -0500, Python wrote:
>
>> Responding to this further would essentially just require me to
>> reiterate what I already wrote--I won't do that.  I'll simply maintain
>> that in my rather lenghty experience, this mistake has actually been
>> rather rare and has to my knowledge *never* caused a support issue
>> requiring a bug fix to production code in projects I've been associated
>> with.  It's a useful construction whose detriment has, IMO, been
>> completely overblown.
>
> I already linked to the attempt to install a backdoor in the Linux kernel
> with this, but even for accidental errors, thirty seconds on the CVE
> database finds at least one real-world example:
>
> https://www.cvedetails.com/cve/CVE-2009-4633/
>
>
> I expect that these days it will be rare, since most C compilers would
> default to warning about it if you run with warnings enabled.
>

That assumes that you regularly run with warnings enabled. While that
might seem like a no-brainer, unfortunately it isn't. With the number
of C compilers out there, it's hard to make sure your code compiles
cleanly with -Wall on every one of them; and if there's a spew of
warnings, one more isn't going to be noticed. So for a large codebase,
it's entirely possible that it WON'T regularly be compiled with
warnings enabled.

Warnings certainly help, but they're not a complete solution.

ChrisA


From rshepard at appl-ecosys.com  Sun May 13 13:01:10 2018
From: rshepard at appl-ecosys.com (Rich Shepard)
Date: Sun, 13 May 2018 10:01:10 -0700 (PDT)
Subject: pylint/pyreverse with Python3
Message-ID: <alpine.LNX.2.20.1805130958220.6325@salmo.appl-ecosys.com>

   Installed here is pylint-1.7.1 and python-3.6.5. When I try to run
pyreverse (and pylint) on python3 source code it fails because it finds only
the python-2.7 site-package and not the python-3.6 site-package.

   If you have learned how to run pylint/pyreverse on python3 code please
share your knowledge with me.

Rich


From theNurd at nurdletech.com  Sun May 13 15:22:56 2018
From: theNurd at nurdletech.com (Ken Kundert)
Date: Sun, 13 May 2018 12:22:56 -0700
Subject: f-string anomaly
Message-ID: <pda3ae$18kj$1@gioia.aioe.org>

I am seeing an unexpected difference between the behavior of the string
format method and f-strings.

Here is an example:

    import sys, os
    from inform import error, os_error

    class mydict(dict):
        def __format__(self, template):
            print('Template:', template)
            return ', '.join(template.format(v, k=k, v=v) for k, v in
self.items())


    d = mydict(bob='239-8402', ted='371-8567', carol='891-5810',
alice='552-2219')

    print('Using format():')
    print('Email: {0:{{k}}: {{v}}}'.format(d))
    print()
    print('Using f-string:')
    print(f'Email: {d:{{k}} {{v}}}')
    print()
    print('Using f-string:')
    print(f'Email: {d:{{k}} {{v}}}', k=6, v=9)


It generates the following response:

    Using format():
    Template: {k}: {v}
    Email: bob: 239-8402, ted: 371-8567, carol: 891-5810, alice: 552-2219

    Using f-string:
    Traceback (most recent call last):
    File "tryit", line 18, in <module>
        print(f'Email: {d:{{k}} {{v}}}')
    NameError: name 'k' is not defined

Essentially I am using a format string as the template that indicates
how to format each member of a dictionary, {{k}} should interpolate the
key and {{v}} interpolates the value.  This format string is embedded
inside another format string, so the braces are doubled up so that they
will be ignored by the outer format string.

This idea seems to work okay when using the format() method. You can see
I added a print statement inside __format__ that shows that the method
is being called.

However, trying the same idea with f-strings results in a NameError.  It
appears that the escaping does not work when used within the template.
It appears the error occurs before __format__ is called (there is no
output from the print function).

Does anybody know why the format() method would work in this case but
the f-string would not?

Is this a bug in f-strings?

-Ken


From mike.junk.46 at att.net  Sun May 13 16:02:01 2018
From: mike.junk.46 at att.net (Mike McClain)
Date: Sun, 13 May 2018 13:02:01 -0700
Subject: object types, mutable or not?
In-Reply-To: <mailman.27.1526227203.13745.python-list@python.org>
References: <mailman.27.1526227203.13745.python-list@python.org>
Message-ID: <20180513200201.GA26725@playground>

I'm new to Python and OOP.
Python  en 2.7.14 Documentation  The Python Language Reference
3. Data model
3.1. Objects, values and types
An object's type is also unchangeable. [1]
[1]     It is possible in some cases to change an object's type,
    under certain controlled conditions.

It appears to me as if an object's type is totally mutable and
solely dependant on assignment.

>>> obj = 'a1b2'
>>> obj
'a1b2'
>>> type (obj)
<type 'str'>
>>>
>>> obj = list(obj)
>>> obj
['a', '1', 'b', '2']
>>> type (obj)
<type 'list'>
>>>
>>> obj = dict( zip(obj[0::2],obj[1::2]) )
>>> type (obj)
<type 'dict'>
>>> obj
{'a': '1', 'b': '2'}

At what level does my understanding break down?

Thanks,
Mike
--
One reason experience is such a good teacher
    is that she doesn't allow dropouts.


From hjp-python at hjp.at  Sun May 13 17:55:01 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Sun, 13 May 2018 23:55:01 +0200
Subject: Leading 0's syntax error in datetime.date module (Python 3.6)
In-Reply-To: <XafJC.207558$B36.200659@fx22.am4>
References: <CANc-5UwVaNCL2eijeMt5tZ=xpAe2bSM2UU6wjCo22ai-qMBo-g@mail.gmail.com>
 <mailman.73.1525951709.28519.python-list@python.org>
 <dy_IC.301544$gE6.154866@fx06.am4>
 <CALwzidn6qiie4oz3CmysS6D-AtUoF2h215VJODDUL9L89pygNg@mail.gmail.com>
 <mailman.81.1525971876.28519.python-list@python.org>
 <Td0JC.111049$Vs7.22268@fx41.am4>
 <CAPTjJmqwODUPKnHu5k8qwUU6N7R2XR9aAE1m6-D5GCgYZcsNOg@mail.gmail.com>
 <mailman.87.1525978297.28519.python-list@python.org>
 <kO1JC.224737$Cd3.58445@fx33.am4>
 <XafJC.207558$B36.200659@fx22.am4>
Message-ID: <20180513215501.5ggabtijjcl5spap@hjp.at>

On 2018-05-11 12:32:24 +0100, bartc wrote:
> I tried it in Python 3 (0o100.5 - I find that prefix fiddly to type actually
> as I have to stop and think), and it seems to be illegal.

You could also read the docs.


> Based floating point literals may be unusual, but bear in mind that in
> decimal, some values may not be represented exactly (eg 0.1). I believe that
> in base 2, 4, 8 or 16, any floating point literal can be represented
> exactly, at least up the precision available.

Which is why C has hexadecimal floating point literals.

(And of course "any" is only correct if the internal representation is
binary - in general you don't unexpected rounding errors if the base of
the internal representation and the base of the literal match, and you
do get unexpected rounding errors if they don't)

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180513/46f39186/attachment.sig>

From hjp-python at hjp.at  Sun May 13 19:00:25 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Mon, 14 May 2018 01:00:25 +0200
Subject: object types, mutable or not?
In-Reply-To: <20180513200201.GA26725@playground>
References: <mailman.27.1526227203.13745.python-list@python.org>
 <20180513200201.GA26725@playground>
Message-ID: <20180513230025.gdqjmnjbcnb3wlan@hjp.at>

On 2018-05-13 13:02:01 -0700, Mike McClain wrote:
> I'm new to Python and OOP.
> Python  en 2.7.14 Documentation  The Python Language Reference

Python 2 is near end-of-life. If you are new to Python you should use
Python 3 (unless you have to maintain legacy software written in Python
2).

> 3. Data model
> 3.1. Objects, values and types
> An object's type is also unchangeable. [1]
> [1]     It is possible in some cases to change an object's type,
>     under certain controlled conditions.
> 
> It appears to me as if an object's type is totally mutable and
> solely dependant on assignment.
> 
> >>> obj = 'a1b2'
> >>> obj
> 'a1b2'
> >>> type (obj)
> <type 'str'>
> >>>
> >>> obj = list(obj)
> >>> obj
> ['a', '1', 'b', '2']
> >>> type (obj)
> <type 'list'>
> >>>
> >>> obj = dict( zip(obj[0::2],obj[1::2]) )
> >>> type (obj)
> <type 'dict'>
> >>> obj
> {'a': '1', 'b': '2'}
> 
> At what level does my understanding break down?

At the point where you assume that the variable ?obj? always contains
the same objects. This is not the case. In fact, variables in Python
never ?contain? anything, they are only ?bound to? objects (or in other
words, they refer to, or point to objects).


> >>> obj = 'a1b2'

Here an object of type ?str? and value 'a1b2' is created. 
> >>> obj
> 'a1b2'
> >>> type (obj)
> <type 'str'>
> >>>
> >>> obj = list(obj)

Here a new object of type list is created. The variable ?obj? is bound
to this new object. The old str object isn't needed anymore and
destroyed.

> >>> obj
> ['a', '1', 'b', '2']
> >>> type (obj)
> <type 'list'>
> >>>
> >>> obj = dict( zip(obj[0::2],obj[1::2]) )

And here you create another new object (this time a dict) and bind the
variable to this new obj. Again, the old object isn't needed any more
and destroyed.

There is a good talk about this topic by Ned Batchelder on Youtube:
https://www.youtube.com/embed/_AEJHKGk9ns

25 minutes well spent.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180514/0fbaa8ed/attachment.sig>

From Richard at Damon-Family.org  Sun May 13 19:10:11 2018
From: Richard at Damon-Family.org (Richard Damon)
Date: Sun, 13 May 2018 19:10:11 -0400
Subject: object types, mutable or not?
In-Reply-To: <20180513200201.GA26725@playground>
References: <mailman.27.1526227203.13745.python-list@python.org>
 <20180513200201.GA26725@playground>
Message-ID: <53e09f9b-0da4-0ae0-3aff-b23029427474@Damon-Family.org>

On 5/13/18 4:02 PM, Mike McClain wrote:
> I'm new to Python and OOP.
> Python  en 2.7.14 Documentation  The Python Language Reference
> 3. Data model
> 3.1. Objects, values and types
> An object's type is also unchangeable. [1]
> [1]     It is possible in some cases to change an object's type,
>     under certain controlled conditions.
>
> It appears to me as if an object's type is totally mutable and
> solely dependant on assignment.
>
>>>> obj = 'a1b2'
>>>> obj
> 'a1b2'
>>>> type (obj)
> <type 'str'>
>>>> obj = list(obj)
>>>> obj
> ['a', '1', 'b', '2']
>>>> type (obj)
> <type 'list'>
>>>> obj = dict( zip(obj[0::2],obj[1::2]) )
>>>> type (obj)
> <type 'dict'>
>>>> obj
> {'a': '1', 'b': '2'}
>
> At what level does my understanding break down?
>
> Thanks,
> Mike
> --
> One reason experience is such a good teacher
>     is that she doesn't allow dropouts.

The first this is obj is NOT 'the object', but is instead a reference
that 'points' to an object.

When you said

obj = 'a1b2'

a string object with the value a1b2 was created, and obj was pointed to it.

when you then said

obj = list(obj)

then a new object, a list, was created based on the value of the object
that obj was pointing to (the string 'a1b2') and then obj was set to
point to that new object, and the old string object became unreferenced
and will at some point be cleaned up (if between the two assignment you
did a obj2 = obj, then obj2 would continue to point to that original
string object).

Note that this says that after you assigned obj to the dict, if you then
assigned obj2 = obj and then did an operation that changed the value
stored in the dict (like using a mutating member function that adds a
member to the dict), obj2 would see the changes, because they both refer
to the same fundamental object.

-- 
Richard Damon



From python at mrabarnett.plus.com  Sun May 13 19:12:46 2018
From: python at mrabarnett.plus.com (MRAB)
Date: Mon, 14 May 2018 00:12:46 +0100
Subject: object types, mutable or not?
In-Reply-To: <20180513200201.GA26725@playground>
References: <mailman.27.1526227203.13745.python-list@python.org>
 <20180513200201.GA26725@playground>
Message-ID: <373c8d79-0ffd-e8d3-0789-f2d363b4e7e1@mrabarnett.plus.com>

On 2018-05-13 21:02, Mike McClain wrote:
> I'm new to Python and OOP.
> Python  en 2.7.14 Documentation  The Python Language Reference
> 3. Data model
> 3.1. Objects, values and types
> An object's type is also unchangeable. [1]
> [1]     It is possible in some cases to change an object's type,
>      under certain controlled conditions.
> 
> It appears to me as if an object's type is totally mutable and
> solely dependant on assignment.
> 
>>>> obj = 'a1b2'
>>>> obj
> 'a1b2'
>>>> type (obj)
> <type 'str'>
>>>>
>>>> obj = list(obj)
>>>> obj
> ['a', '1', 'b', '2']
>>>> type (obj)
> <type 'list'>
>>>>
>>>> obj = dict( zip(obj[0::2],obj[1::2]) )
>>>> type (obj)
> <type 'dict'>
>>>> obj
> {'a': '1', 'b': '2'}
> 
> At what level does my understanding break down?
> 
You're not mutating an object, you're creating new objects and then 
binding them to the same name.

The name 'obj' refers to a string, then a list, etc.

BTW, you should be using Python 3 unless you really need Python 2. 
Python 2.7 is the last in the Python 2 line, and it'll not longer be 
supported after 2020.


From theNurd at nurdletech.com  Sun May 13 19:25:35 2018
From: theNurd at nurdletech.com (Ken Kundert)
Date: Sun, 13 May 2018 16:25:35 -0700
Subject: f-string anomaly
Message-ID: <pdahhd$1vhr$1@gioia.aioe.org>

I am seeing an unexpected difference between the behavior of the string
format method and f-strings in Python3.6.

Here is an example:

    import sys, os
    from inform import error, os_error

    class mydict(dict):
        def __format__(self, template):
            print('Template:', template)
            return ', '.join(template.format(v, k=k, v=v) for k, v in
self.items())


    d = mydict(bob='239-8402', ted='371-8567', carol='891-5810',
alice='552-2219')

    print('Using format():')
    print('Email: {0:{{k}}: {{v}}}'.format(d))
    print()
    print('Using f-string:')
    print(f'Email: {d:{{k}} {{v}}}')
    print()
    print('Using f-string:')
    print(f'Email: {d:{{k}} {{v}}}', k=6, v=9)


It generates the following response:

    Using format():
    Template: {k}: {v}
    Email: bob: 239-8402, ted: 371-8567, carol: 891-5810, alice: 552-2219

    Using f-string:
    Traceback (most recent call last):
    File "tryit", line 18, in <module>
        print(f'Email: {d:{{k}} {{v}}}')
    NameError: name 'k' is not defined

Essentially I am using a format string as the template that indicates
how to format each member of a dictionary, {{k}} should interpolate the
key and {{v}} interpolates the value.  This format string is embedded
inside another format string, so the braces are doubled up so that they
will be ignored by the outer format string.

This idea seems to work okay when using the format() method. You can see
I added a print statement inside __format__ that shows that the method
is being called.

However, trying the same idea with f-strings results in a NameError.  It
appears that the escaping does not work when used within the template.
It appears the error occurs before __format__ is called (there is no
output from the print function).

Does anybody know why the format() method would work in this case but
the f-string would not?

Is this a but in f-strings?

-Ken


From ben+python at benfinney.id.au  Sun May 13 19:37:22 2018
From: ben+python at benfinney.id.au (Ben Finney)
Date: Mon, 14 May 2018 09:37:22 +1000
Subject: object types, mutable or not?
References: <mailman.27.1526227203.13745.python-list@python.org>
 <20180513200201.GA26725@playground>
Message-ID: <85wow7m8jx.fsf@benfinney.id.au>

Mike McClain <mike.junk.46 at att.net> writes:

> I'm new to Python and OOP.

Welcome! Congratulations on learning Python.

> Python  en 2.7.14 Documentation

I will concur with others in this thread: Learning Python today you
should learn Python 3. Avoid Python 2 for now (you can learn its
obsolete quirks later).

> An object's type is also unchangeable. [1]
> [1]     It is possible in some cases to change an object's type,
>     under certain controlled conditions.

Yes.

> It appears to me as if an object's type is totally mutable and
> solely dependant on assignment.

You are mistaking re-binding of a name, for changing the object. They
are not the same thing.

Let's walk through the meaning of each of the statements in your example:

> >>> obj = 'a1b2'

This creates a new object, the string ?'a1b2'?; then binds the name
?obj? to that object.

> >>> obj
> 'a1b2'

This interrogates what object the name ?obj? currently refers to.

Because this is done in the Python REPL, it also emits a text
representation of that object.

> >>> type (obj)
> <type 'str'>

This interrogates what object the name ?obj? currently refers to, then
asks for the type of that object. For the referenced object, that is the
?str? type.

Because this is done in the Python REPL, it also emits a text
representation of the ?str? type (the type is also an object, of type
?type?).

> >>> obj = list(obj)

This interrogates what object the name ?obj? currently refers to. Then,
it invokes the ?list? type constructor to create a new instance.

Then, the name ?obj? is bound to the new list instance that was created.

> >>> obj
> ['a', '1', 'b', '2']

This interrogates what object the name ?obj? currently refers to.

Because this is done in the Python REPL, it also emits a text
representation of that object.

> >>> type (obj)
> <type 'list'>

This interrogates what object the name ?obj? currently refers to, then
asks for the type of that object. For the referenced object, that is the
?list? type.

Because this is done in the Python REPL, it also emits a text
representation of the ?list? type (the type is also an object, of type
?type?).

> >>> obj = dict( zip(obj[0::2],obj[1::2]) )

This interrogates what object the name ?obj? currently refers to, then
performs a pair of slicing operations on that object; those operations
return new instances each of type ?list?.

Then, the ?zip? function is invoked with those list objects; the return
value is itself a new list.

Then, the ?dict? type constructor is invoked to create a new instance,
based on that list. It returns a new ?dict? instance.

Then, the name ?obj? is bound to that dict instance.

> >>> type (obj)
> <type 'dict'>

This interrogates what object the name ?obj? currently refers to, then
asks for the type of that object. For the referenced object, that is the
?dict? type.

Because this is done in the Python REPL, it also emits a text
representation of the ?dict? type (the type is also an object, of type
?type?).

> >>> obj
> {'a': '1', 'b': '2'}

This interrogates what object the name ?obj? currently refers to.

Because this is done in the Python REPL, it also emits a text
representation of that object.

> At what level does my understanding break down?

Assignment in Python never changes the referenced object. It changes the
*reference*, to refer to some (usually a different) object. The
referenced object is not even invoked, and is certainly not changed, by
the assignment.

Your misunderstanding probably comes from other programming languages,
that have a concept of ?variable? that resenbles a box of a particular
shape, that you put an object into.

Python does not have that concept. Assignment binds a name *to* an
object, like a sticky note or a paper tag. The binding doesn't affect
the object, and can change at some future time to be bound to a
different object without ever affecting the earlier object.

See this excellent talk by Ned Batchelder:

    Ned Batchelder: Facts and myths about Python names and values
    <URL:https://nedbatchelder.com/text/names.html>

-- 
 \          ?In general my children refuse to eat anything that hasn't |
  `\                              danced on television.? ?Erma Bombeck |
_o__)                                                                  |
Ben Finney



From tallpaul at gmail.com  Sun May 13 20:48:47 2018
From: tallpaul at gmail.com (Paul)
Date: Sun, 13 May 2018 17:48:47 -0700
Subject: random.choices() Suggest that the code confirm that cum_weights
 sequence is in ascending order
Message-ID: <CA+og5upAoJX004vm+xZZED13rwtwExoLe3cY+pr_KUEmi7Sxtw@mail.gmail.com>

Hi,
  I just learned how to use random.choices().  I initially misunderstood
the documentation for cum_weights as meaning that a cumulative sequence
would be *constructed from* the sequence which I supplied.  Consequently, I
specified 'cum_weights' with a sequence which wasn't in ascending order.  I
got back k results but I determined that they weren't correct (eg, certain
population values were never returned).

  Since the non-ascending sequence, which I had supplied, could not
possibly be valid input, why isn't this checked (and an error returned)?
 Returning incorrect results (which could be hard to spot as being
incorrect) is much more dangerous.  Also, checking that the list is in
ascending order need only be done once, and seems like it would be
inexpensive.

  Thanks,
  Paul


From tjreedy at udel.edu  Sun May 13 22:08:32 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 13 May 2018 22:08:32 -0400
Subject: f-string anomaly
In-Reply-To: <pda3ae$18kj$1@gioia.aioe.org>
References: <pda3ae$18kj$1@gioia.aioe.org>
Message-ID: <pdaquv$g15$1@blaine.gmane.org>

On 5/13/2018 3:22 PM, Ken Kundert wrote:

Please do not double post.

> I am seeing an unexpected difference between the behavior of the string
> format method and f-strings.

Read 
https://docs.python.org/3/reference/lexical_analysis.html#formatted-string-literals 
carefully.

> Here is an example:
> 
>      import sys, os
>      from inform import error, os_error
> 
>      class mydict(dict):
>          def __format__(self, template):
>              print('Template:', template)
>              return ', '.join(template.format(v, k=k, v=v) for k, v in
> self.items())
> 
> 
>      d = mydict(bob='239-8402', ted='371-8567', carol='891-5810',
> alice='552-2219')
> 
>      print('Using format():')
>      print('Email: {0:{{k}}: {{v}}}'.format(d))
>      print()
>      print('Using f-string:')
>      print(f'Email: {d:{{k}} {{v}}}')
>      print()
>      print('Using f-string:')
>      print(f'Email: {d:{{k}} {{v}}}', k=6, v=9)
> 
> 
> It generates the following response:
> 
>      Using format():
>      Template: {k}: {v}
>      Email: bob: 239-8402, ted: 371-8567, carol: 891-5810, alice: 552-2219
> 
>      Using f-string:
>      Traceback (most recent call last):
>      File "tryit", line 18, in <module>
>          print(f'Email: {d:{{k}} {{v}}}')
>      NameError: name 'k' is not defined

This is what I expected.

> Essentially I am using a format string as the template that indicates
> how to format each member of a dictionary, {{k}} should interpolate the
> key and {{v}} interpolates the value.  This format string is embedded
> inside another format string, so the braces are doubled up so that they
> will be ignored by the outer format string.

"The parts of the string outside curly braces are treated literally, 
except that any doubled curly braces '{{' or '}}' are replaced with the 
corresponding single curly brace. " note 'outside'

> This idea seems to work okay when using the format() method. You can see
> I added a print statement inside __format__ that shows that the method
> is being called.
> 
> However, trying the same idea with f-strings results in a NameError.  It
> appears that the escaping does not work when used within the template.
> It appears the error occurs before __format__ is called (there is no
> output from the print function).
> 
> Does anybody know why the format() method would work in this case but
> the f-string would not?

All names in the expression are resolved in the local namespace of the f 
string.  There are other differences.  Nesting can only be one level deep.

> Is this a bug in f-strings?

Not to me.


-- 
Terry Jan Reedy



From tjreedy at udel.edu  Sun May 13 22:11:34 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 13 May 2018 22:11:34 -0400
Subject: pylint/pyreverse with Python3
In-Reply-To: <alpine.LNX.2.20.1805130958220.6325@salmo.appl-ecosys.com>
References: <alpine.LNX.2.20.1805130958220.6325@salmo.appl-ecosys.com>
Message-ID: <pdar4k$g15$2@blaine.gmane.org>

On 5/13/2018 1:01 PM, Rich Shepard wrote:
>  ? Installed here is pylint-1.7.1 and python-3.6.5. When I try to run
> pyreverse (and pylint) on python3 source code it fails because it finds 
> only
> the python-2.7 site-package and not the python-3.6 site-package.

>  ? If you have learned how to run pylint/pyreverse on python3 code please
> share your knowledge with me.

You have to install a package in /site-packages for each version you 
want to run it with.

Then you have to make sure you run the version you intend to run.


-- 
Terry Jan Reedy




From theNurd at nurdletech.com  Mon May 14 01:08:08 2018
From: theNurd at nurdletech.com (Ken Kundert)
Date: Sun, 13 May 2018 22:08:08 -0700
Subject: f-string anomaly
References: <pda3ae$18kj$1@gioia.aioe.org> <pdaquv$g15$1@blaine.gmane.org>
 <mailman.20.1526263724.2761.python-list@python.org>
Message-ID: <pdb5jp$pg7$1@gioia.aioe.org>

Terry,
    Thanks for your response.

I apologize about the double posting. I am well aware how doing so is
bad form. My double posting was unintentional; it occurred when my news
reader misbehaved.

What I did in my code was to put double braces inside the format_spec,
which the syntax specification in the f-string documentation does not
allow, and so it should be a syntax error. But it does not generate a
syntax error. So the question becomes, how does it interpret {{k}} and
{{v}} in the format spec. I was expecting it to treat the double braces
as escaped braces, and that is what the format method does. And by the
last sentence in the following paragraph, it seems like f-strings should
as well.

    Top-level format specifiers may include nested replacement fields.
    These nested fields may include their own conversion fields and
    format specifiers, but may not include more deeply-nested
    replacement fields. The format specifier mini-language is the same
    as that used by the string .format() method.

> All names in the expression are resolved in the local namespace of the
> f string.  There are other differences.  Nesting can only be one level
> deep.

I tried adding k and v to the local namespace:

    ...
    k = 6
    v = 9
    print(f'Email: {d:{{k}} {{v}}}')

I still got:

    NameError: name 'k' is not defined

I don't know where it is looking for k, but it is not in the local
namespace.

And I don't think the comment on nesting applies. The format string does
not include nested references. Rather "{{k}} {{v}}" is meant to be
treated as a literal string that should de-escaped and passed to the
__format__ method, but no values should be interpolated. What the
__format__ method does with the format spec is not in anyway restricted
by the f string as long as __format__ returns a string.

The comment that the mini-language is the same between the format method
and the f string seems compelling to me. I think this is a bug. I think
the f-string syntax should be updated to explicitly allow escaped braces
in the format_spec, and the implementation of f-strings should be
updated to be consistent with the syntax specification, and with the
format method.

-Ken



On 05/13/2018 07:08 PM, Terry Reedy wrote:
> On 5/13/2018 3:22 PM, Ken Kundert wrote:
> 
> Please do not double post.
> 
>> I am seeing an unexpected difference between the behavior of the string
>> format method and f-strings.
> 
> Read
> https://docs.python.org/3/reference/lexical_analysis.html#formatted-string-literals
> carefully.
> 
>> Here is an example:
>>
>> ???? import sys, os
>> ???? from inform import error, os_error
>>
>> ???? class mydict(dict):
>> ???????? def __format__(self, template):
>> ???????????? print('Template:', template)
>> ???????????? return ', '.join(template.format(v, k=k, v=v) for k, v in
>> self.items())
>>
>>
>> ???? d = mydict(bob='239-8402', ted='371-8567', carol='891-5810',
>> alice='552-2219')
>>
>> ???? print('Using format():')
>> ???? print('Email: {0:{{k}}: {{v}}}'.format(d))
>> ???? print()
>> ???? print('Using f-string:')
>> ???? print(f'Email: {d:{{k}} {{v}}}')
>> ???? print()
>> ???? print('Using f-string:')
>> ???? print(f'Email: {d:{{k}} {{v}}}', k=6, v=9)
>>
>>
>> It generates the following response:
>>
>> ???? Using format():
>> ???? Template: {k}: {v}
>> ???? Email: bob: 239-8402, ted: 371-8567, carol: 891-5810, alice:
>> 552-2219
>>
>> ???? Using f-string:
>> ???? Traceback (most recent call last):
>> ???? File "tryit", line 18, in <module>
>> ???????? print(f'Email: {d:{{k}} {{v}}}')
>> ???? NameError: name 'k' is not defined
> 
> This is what I expected.
> 
>> Essentially I am using a format string as the template that indicates
>> how to format each member of a dictionary, {{k}} should interpolate the
>> key and {{v}} interpolates the value.? This format string is embedded
>> inside another format string, so the braces are doubled up so that they
>> will be ignored by the outer format string.
> 
> "The parts of the string outside curly braces are treated literally,
> except that any doubled curly braces '{{' or '}}' are replaced with the
> corresponding single curly brace. " note 'outside'
> 
>> This idea seems to work okay when using the format() method. You can see
>> I added a print statement inside __format__ that shows that the method
>> is being called.
>>
>> However, trying the same idea with f-strings results in a NameError.? It
>> appears that the escaping does not work when used within the template.
>> It appears the error occurs before __format__ is called (there is no
>> output from the print function).
>>
>> Does anybody know why the format() method would work in this case but
>> the f-string would not?
> 
> All names in the expression are resolved in the local namespace of the f
> string.? There are other differences.? Nesting can only be one level deep.
> 
>> Is this a bug in f-strings?
> 
> Not to me.
> 
> 



From lele at metapensiero.it  Mon May 14 03:30:27 2018
From: lele at metapensiero.it (Lele Gaifax)
Date: Mon, 14 May 2018 09:30:27 +0200
Subject: f-string anomaly
References: <pda3ae$18kj$1@gioia.aioe.org> <pdaquv$g15$1@blaine.gmane.org>
 <mailman.20.1526263724.2761.python-list@python.org>
 <pdb5jp$pg7$1@gioia.aioe.org>
Message-ID: <878t8melt8.fsf@metapensiero.it>

Ken Kundert <theNurd at nurdletech.com> writes:

> I tried adding k and v to the local namespace:
>
>     ...
>     k = 6
>     v = 9
>     print(f'Email: {d:{{k}} {{v}}}')
>
> I still got:
>
>     NameError: name 'k' is not defined

This is not what I get:

    Python 3.6.5 (default, May 11 2018, 13:30:17) 
    [GCC 7.3.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> k=1
    >>> v=2
    >>> print(f'this is {{k}} and {{v}}')
    this is {k} and {v}
    >>> print(f'this is {k} and {v}')
    this is 1 and 2
    >>> print(f'Email: {d:{{k}} {{v}}}')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    NameError: name 'd' is not defined

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivr? di quello che ho pensato ieri
real: Emanuele Gaifas | comincer? ad aver paura di chi mi copia.
lele at metapensiero.it  |                 -- Fortunato Depero, 1929.



From tjol at tjol.eu  Mon May 14 06:15:36 2018
From: tjol at tjol.eu (Thomas Jollans)
Date: Mon, 14 May 2018 12:15:36 +0200
Subject: f-string anomaly
In-Reply-To: <pdaquv$g15$1@blaine.gmane.org>
References: <pda3ae$18kj$1@gioia.aioe.org> <pdaquv$g15$1@blaine.gmane.org>
Message-ID: <1d68e317-e4fb-0779-5850-24d0ff16f24e@tjol.eu>

On 2018-05-14 04:08, Terry Reedy wrote:
> On 5/13/2018 3:22 PM, Ken Kundert wrote:
> 
> Please do not double post.
> 
>> I am seeing an unexpected difference between the behavior of the string
>> format method and f-strings.
> 
> Read
> https://docs.python.org/3/reference/lexical_analysis.html#formatted-string-literals
> carefully.
> 
>> Here is an example:
>>
>> ???? import sys, os
>> ???? from inform import error, os_error
>>
>> ???? class mydict(dict):
>> ???????? def __format__(self, template):
>> ???????????? print('Template:', template)
>> ???????????? return ', '.join(template.format(v, k=k, v=v) for k, v in
>> self.items())
>>
>>
>> ???? d = mydict(bob='239-8402', ted='371-8567', carol='891-5810',
>> alice='552-2219')
>>
>> ???? print('Using format():')
>> ???? print('Email: {0:{{k}}: {{v}}}'.format(d))
>> ???? print()
>> ???? print('Using f-string:')
>> ???? print(f'Email: {d:{{k}} {{v}}}')
>> ???? print()
>> ???? print('Using f-string:')
>> ???? print(f'Email: {d:{{k}} {{v}}}', k=6, v=9)
>>
>>
>> It generates the following response:
>>
>> ???? Using format():
>> ???? Template: {k}: {v}
>> ???? Email: bob: 239-8402, ted: 371-8567, carol: 891-5810, alice:
>> 552-2219
>>
>> ???? Using f-string:
>> ???? Traceback (most recent call last):
>> ???? File "tryit", line 18, in <module>
>> ???????? print(f'Email: {d:{{k}} {{v}}}')
>> ???? NameError: name 'k' is not defined
> 
> This is what I expected.
> 
>> Essentially I am using a format string as the template that indicates
>> how to format each member of a dictionary, {{k}} should interpolate the
>> key and {{v}} interpolates the value.? This format string is embedded
>> inside another format string, so the braces are doubled up so that they
>> will be ignored by the outer format string.
> 
> "The parts of the string outside curly braces are treated literally,
> except that any doubled curly braces '{{' or '}}' are replaced with the
> corresponding single curly brace. " note 'outside'

It only accidentally works with the format method. It, too, does not
support escaped curly brackets in format specifiers, but they'll slip
through IFF all of them are matched:

>>> d = mydict(bob='239-8402', ted='371-8567', carol='891-5810',
... alice='552-2219')
>>> 'Email: {0:{{k}}: {{v}}}'.format(d)
Template: {k}: {v}
'Email: bob: 239-8402, ted: 371-8567, carol: 891-5810, alice: 552-2219'
>>> 'Email: {0:{{k}} {{{{ {{v}}}'.format(d)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: unmatched '{' in format spec
>>> 'Email: {0:{{k}} {{{{}}}} {{v}}}'.format(d)
Template: {k} {{}} {v}
'Email: bob {} 239-8402, ted {} 371-8567, carol {} 891-5810, alice {}
552-2219'
>>>


> 
>> This idea seems to work okay when using the format() method. You can see
>> I added a print statement inside __format__ that shows that the method
>> is being called.
>>
>> However, trying the same idea with f-strings results in a NameError.? It
>> appears that the escaping does not work when used within the template.
>> It appears the error occurs before __format__ is called (there is no
>> output from the print function).
>>
>> Does anybody know why the format() method would work in this case but
>> the f-string would not?
> 
> All names in the expression are resolved in the local namespace of the f
> string.? There are other differences.? Nesting can only be one level deep.
> 
>> Is this a bug in f-strings?
> 
> Not to me.
> 
> 



From zljubisic at gmail.com  Mon May 14 07:05:09 2018
From: zljubisic at gmail.com (zljubisic at gmail.com)
Date: Mon, 14 May 2018 04:05:09 -0700 (PDT)
Subject: Pandas cat.categories.isin list, is this a bug?
Message-ID: <9fb404de-0ff5-4ad5-86fe-16e02ac9a257@googlegroups.com>

Hi,

I have dataframe with CRM_assetID column as category dtype:

df.info()

<class 'pandas.core.frame.DataFrame'>
RangeIndex: 1435952 entries, 0 to 1435951
Data columns (total 75 columns):
startTime                            1435952 non-null object
CRM_assetID                          1435952 non-null category

searching a dataframe for each of three categories:

df[df.CRM_assetID == 'V1254748'].shape
(35, 75)
df[df.CRM_assetID == 'V805722'].shape
(45, 75)
df[df.CRM_assetID == 'V1105400'].shape
(34, 75)


len(df.CRM_assetID.cat.categories.isin(['V1254748', 'V805722', 'V1105400']))

Why this len is not equal to 114 (35 + 45 + 34)?

Regards.


From zljubisic at gmail.com  Mon May 14 07:18:31 2018
From: zljubisic at gmail.com (zljubisic at gmail.com)
Date: Mon, 14 May 2018 04:18:31 -0700 (PDT)
Subject: Pandas cat.categories.isin list, is this a bug?
In-Reply-To: <9fb404de-0ff5-4ad5-86fe-16e02ac9a257@googlegroups.com>
References: <9fb404de-0ff5-4ad5-86fe-16e02ac9a257@googlegroups.com>
Message-ID: <63238c24-fbdb-4c30-a93f-b45208f34cc8@googlegroups.com>

On Monday, 14 May 2018 13:05:24 UTC+2, zlju... at gmail.com  wrote:
> Hi,
> 
> I have dataframe with CRM_assetID column as category dtype:
> 
> df.info()
> 
> <class 'pandas.core.frame.DataFrame'>
> RangeIndex: 1435952 entries, 0 to 1435951
> Data columns (total 75 columns):
> startTime                            1435952 non-null object
> CRM_assetID                          1435952 non-null category
> 
> searching a dataframe for each of three categories:
> 
> df[df.CRM_assetID == 'V1254748'].shape
> (35, 75)
> df[df.CRM_assetID == 'V805722'].shape
> (45, 75)
> df[df.CRM_assetID == 'V1105400'].shape
> (34, 75)
> 
> 
> len(df.CRM_assetID.cat.categories.isin(['V1254748', 'V805722', 'V1105400']))
> 
> Why this len is not equal to 114 (35 + 45 + 34)?
> 
> Regards.

I forgot to copy result of:

len(df.CRM_assetID.cat.categories.isin(['V1254748', 'V805722', 'V1105400'])) 

which is 55418.


From steve+comp.lang.python at pearwood.info  Mon May 14 07:36:04 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Mon, 14 May 2018 11:36:04 +0000 (UTC)
Subject: random.choices() Suggest that the code confirm that cum_weights
 sequence is in ascending order
References: <CA+og5upAoJX004vm+xZZED13rwtwExoLe3cY+pr_KUEmi7Sxtw@mail.gmail.com>
Message-ID: <pdbsb4$unn$5@blaine.gmane.org>

Hi Paul, and welcome!

On Sun, 13 May 2018 17:48:47 -0700, Paul wrote:

> Hi,
>   I just learned how to use random.choices().  
[...]
> Consequently, I specified 'cum_weights' with a sequence which wasn't in
> ascending order.  I got back k results but I determined that they
> weren't correct (eg, certain population values were never returned).
> 
>   Since the non-ascending sequence, which I had supplied, could not
> possibly be valid input, why isn't this checked (and an error returned)?
>  Returning incorrect results (which could be hard to spot as being
> incorrect) is much more dangerous.  Also, checking that the list is in
> ascending order need only be done once, and seems like it would be
> inexpensive.

Sounds like a reasonable feature request to me.


https://bugs.python.org/issue33494



-- 
Steve



From p.f.moore at gmail.com  Mon May 14 07:59:28 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 14 May 2018 12:59:28 +0100
Subject: random.choices() Suggest that the code confirm that cum_weights
 sequence is in ascending order
In-Reply-To: <pdbsb4$unn$5@blaine.gmane.org>
References: <CA+og5upAoJX004vm+xZZED13rwtwExoLe3cY+pr_KUEmi7Sxtw@mail.gmail.com>
 <pdbsb4$unn$5@blaine.gmane.org>
Message-ID: <CACac1F8pqzvMFv20yafmTO8s_R_PmW_wuGpL2SVo7g9bZGvQug@mail.gmail.com>

The problem is that supplying cum_weights allows the code to run in
O(log n) by using bisection. This is significantly faster on large
populations. Adding a test that the cumulative weights are
nondecreasing would add an O(n) step to the code.

So while I understand the OP's problem, I don't think it's soluble
without making the cum_weights argument useless in practice. Better
documentation might be worthwhile (although I don't personally find
the current docs confusing, so suggestions for improvements would be
helpful).

Paul


On 14 May 2018 at 12:36, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> Hi Paul, and welcome!
>
> On Sun, 13 May 2018 17:48:47 -0700, Paul wrote:
>
>> Hi,
>>   I just learned how to use random.choices().
> [...]
>> Consequently, I specified 'cum_weights' with a sequence which wasn't in
>> ascending order.  I got back k results but I determined that they
>> weren't correct (eg, certain population values were never returned).
>>
>>   Since the non-ascending sequence, which I had supplied, could not
>> possibly be valid input, why isn't this checked (and an error returned)?
>>  Returning incorrect results (which could be hard to spot as being
>> incorrect) is much more dangerous.  Also, checking that the list is in
>> ascending order need only be done once, and seems like it would be
>> inexpensive.
>
> Sounds like a reasonable feature request to me.
>
>
> https://bugs.python.org/issue33494
>
>
>
> --
> Steve
>
> --
> https://mail.python.org/mailman/listinfo/python-list


From steve+comp.lang.python at pearwood.info  Mon May 14 08:02:49 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Mon, 14 May 2018 12:02:49 +0000 (UTC)
Subject: object types, mutable or not?
References: <mailman.27.1526227203.13745.python-list@python.org>
 <20180513200201.GA26725@playground>
Message-ID: <pdbtt8$unn$6@blaine.gmane.org>

On Sun, 13 May 2018 13:02:01 -0700, Mike McClain wrote:

[...]
> It appears to me as if an object's type is totally mutable and solely
> dependant on assignment.
> 
>>>> obj = 'a1b2'
>>>> type (obj)
> <type 'str'>
>>>>
>>>> obj = list(obj)
>>>> type (obj)
> <type 'list'>



> At what level does my understanding break down?

Mistaking a name (which refers to an object) for the object itself.

Five years ago, the President Of the United States of America, or POTUS 
for short, referred to Barrack Obama. Today, it refers to Donald Trump. 
This didn't happen by mutating a single person (an object) from a 
youngish black-skinned man to an oldish orange-skinned man. It happened 
by re-assigning the name from Obama to Trump.

Likewise when you re-assign a variable name from one value (an object) to 
another, the original object doesn't change. You just make the name refer 
to a different object, while the first goes on its merry way (probably to 
be collected by the garbage collector and the memory reclaimed).


-- 
Steve



From rosuav at gmail.com  Mon May 14 08:27:24 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Mon, 14 May 2018 22:27:24 +1000
Subject: random.choices() Suggest that the code confirm that cum_weights
 sequence is in ascending order
In-Reply-To: <CACac1F8pqzvMFv20yafmTO8s_R_PmW_wuGpL2SVo7g9bZGvQug@mail.gmail.com>
References: <CA+og5upAoJX004vm+xZZED13rwtwExoLe3cY+pr_KUEmi7Sxtw@mail.gmail.com>
 <pdbsb4$unn$5@blaine.gmane.org>
 <CACac1F8pqzvMFv20yafmTO8s_R_PmW_wuGpL2SVo7g9bZGvQug@mail.gmail.com>
Message-ID: <CAPTjJmoasGyuBj60BROj_YpJw_uU56HN-gOmMCSE-7ombCwcew@mail.gmail.com>

On Mon, May 14, 2018 at 9:59 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> The problem is that supplying cum_weights allows the code to run in
> O(log n) by using bisection. This is significantly faster on large
> populations. Adding a test that the cumulative weights are
> nondecreasing would add an O(n) step to the code.
>

Hang on - are the 'n' and 'log n' there referring to the same n?

ChrisA


From matt.ruffalo at gmail.com  Mon May 14 08:34:51 2018
From: matt.ruffalo at gmail.com (Matt Ruffalo)
Date: Mon, 14 May 2018 08:34:51 -0400
Subject: Pandas cat.categories.isin list, is this a bug?
In-Reply-To: <9fb404de-0ff5-4ad5-86fe-16e02ac9a257@googlegroups.com>
References: <9fb404de-0ff5-4ad5-86fe-16e02ac9a257@googlegroups.com>
Message-ID: <872d0323-13ec-31b9-1dc9-406125c25593@gmail.com>

On 2018-05-14 07:05, zljubisic at gmail.com wrote:
> Hi,
>
> I have dataframe with CRM_assetID column as category dtype:
>
> df.info()
>
> <class 'pandas.core.frame.DataFrame'>
> RangeIndex: 1435952 entries, 0 to 1435951
> Data columns (total 75 columns):
> startTime                            1435952 non-null object
> CRM_assetID                          1435952 non-null category
>
> searching a dataframe for each of three categories:
>
> df[df.CRM_assetID == 'V1254748'].shape
> (35, 75)
> df[df.CRM_assetID == 'V805722'].shape
> (45, 75)
> df[df.CRM_assetID == 'V1105400'].shape
> (34, 75)
>
>
> len(df.CRM_assetID.cat.categories.isin(['V1254748', 'V805722', 'V1105400']))
>
> Why this len is not equal to 114 (35 + 45 + 34)?
>
> Regards.

Hello-

First, this is a general Python group; not everyone here is necessarily
an expert in or user of Pandas. In the future you might have more
success with the pydata mailing list/group.

When you say that `len(df.CRM_assetID.cat.categories.isin(['V1254748',
'V805722', 'V1105400']))` is not equal to 114, it would be helpful to
say what this length actually is.

Your usage of `df.CRM_assetID.cat.categories` refers to the *unique
categories in that column*, not the actual values in that column.
Presumably you have more categories in that column than the three you
are checking with `isin`, since you are checking the length of a boolean
vector that signifies whether each distinct category is in that list.

MMR...


From p.f.moore at gmail.com  Mon May 14 08:49:12 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 14 May 2018 13:49:12 +0100
Subject: random.choices() Suggest that the code confirm that cum_weights
 sequence is in ascending order
In-Reply-To: <CAPTjJmoasGyuBj60BROj_YpJw_uU56HN-gOmMCSE-7ombCwcew@mail.gmail.com>
References: <CA+og5upAoJX004vm+xZZED13rwtwExoLe3cY+pr_KUEmi7Sxtw@mail.gmail.com>
 <pdbsb4$unn$5@blaine.gmane.org>
 <CACac1F8pqzvMFv20yafmTO8s_R_PmW_wuGpL2SVo7g9bZGvQug@mail.gmail.com>
 <CAPTjJmoasGyuBj60BROj_YpJw_uU56HN-gOmMCSE-7ombCwcew@mail.gmail.com>
Message-ID: <CACac1F_ntCCez_QBqiuwK0A7b7cEVwtKY89wsWjL271RgE_gFQ@mail.gmail.com>

On 14 May 2018 at 13:27, Chris Angelico <rosuav at gmail.com> wrote:
> On Mon, May 14, 2018 at 9:59 PM, Paul Moore <p.f.moore at gmail.com> wrote:
>> The problem is that supplying cum_weights allows the code to run in
>> O(log n) by using bisection. This is significantly faster on large
>> populations. Adding a test that the cumulative weights are
>> nondecreasing would add an O(n) step to the code.
>>
>
> Hang on - are the 'n' and 'log n' there referring to the same n?

Yes. The number of elements in the sample population (which is the
same as the number of entries in the weights/cum_weights arrays). See
https://github.com/python/cpython/blob/master/Lib/random.py#L382 for
details, but basically calculating cum_weights from weights costs
O(n), and locating the right index into the population by doing a
bisection search (bisect.bisect) on the cum_weights sequence costs
O(log n). Using the cum_weights argument rather than the weights
argument skips the O(n) step.

If it's possible to check that cum_weights is nondecreasing in O(log
n) time (either directly here, or in bisect.bisect), then the check
wouldn't affect the algorithmic complexity of that case (it would
affect the constants, but I assume we don't care too much about that).
But I don't know of a way of doing that.

Improving the documentation is of course free of runtime cost. And
making it clear that "you should only use cum_weights if you know what
you're doing, and in particular it doesn't cost you O(n) to work them
out" would seem entirely reasonable to me.

Paul


From rhodri at kynesim.co.uk  Mon May 14 08:49:19 2018
From: rhodri at kynesim.co.uk (Rhodri James)
Date: Mon, 14 May 2018 13:49:19 +0100
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <20180513043120.GL12850@bladeshadow.org>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org> <pcu1so$qbi$2@blaine.gmane.org>
 <CAPTjJmp5GyJi1BGCkag3GoatOHVH=umd831J3x+iukpK0FcNHA@mail.gmail.com>
 <20180513043120.GL12850@bladeshadow.org>
Message-ID: <96949666-183e-c6a9-6431-e5eac64325dc@kynesim.co.uk>

On 13/05/18 05:31, Python wrote:
> No, you are not.  Do you ever say "dog" when you mean "dot" instead?
> Do you ever say "dad" when you mean "mom" instead?

One of my aunts used to muddle family names all the time.  She once 
called me by my sister's name; one would have thought the beard was a 
clue to that one.

Similarly  my mother once asked my sister to "Get the thingummy off the 
whatsit."  The alarming thing was that my sister understood this and 
handed her the correct object.

So yes, actually we do make that kind of error all the time.  Moreover, 
it's very hard to notice *in your own code* because you read what you 
meant, not what you wrote.  Ask any author about proof-reading, and 
they'll tell you to get someone else to do it.

-- 
Rhodri James *-* Kynesim Ltd


From rshepard at appl-ecosys.com  Mon May 14 08:49:56 2018
From: rshepard at appl-ecosys.com (Rich Shepard)
Date: Mon, 14 May 2018 05:49:56 -0700 (PDT)
Subject: pylint/pyreverse with Python3 [RESOLVED]
In-Reply-To: <pdar4k$g15$2@blaine.gmane.org>
References: <alpine.LNX.2.20.1805130958220.6325@salmo.appl-ecosys.com>
 <pdar4k$g15$2@blaine.gmane.org>
Message-ID: <alpine.LNX.2.20.1805140546020.25598@salmo.appl-ecosys.com>

On Sun, 13 May 2018, Terry Reedy wrote:

> You have to install a package in /site-packages for each version you want
> to run it with.

Terry,

   It is installed in the site-packages/ directory for both 2.7 and 3.6.

> Then you have to make sure you run the version you intend to run.

   Since both /usr/bin/pylint and /usr/bin/pyreverse are python scripts I can
change the first line to call python3 rather than python. I should have
looked at this before writing.

Thanks,

Rich



From rosuav at gmail.com  Mon May 14 08:53:59 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Mon, 14 May 2018 22:53:59 +1000
Subject: random.choices() Suggest that the code confirm that cum_weights
 sequence is in ascending order
In-Reply-To: <CACac1F_ntCCez_QBqiuwK0A7b7cEVwtKY89wsWjL271RgE_gFQ@mail.gmail.com>
References: <CA+og5upAoJX004vm+xZZED13rwtwExoLe3cY+pr_KUEmi7Sxtw@mail.gmail.com>
 <pdbsb4$unn$5@blaine.gmane.org>
 <CACac1F8pqzvMFv20yafmTO8s_R_PmW_wuGpL2SVo7g9bZGvQug@mail.gmail.com>
 <CAPTjJmoasGyuBj60BROj_YpJw_uU56HN-gOmMCSE-7ombCwcew@mail.gmail.com>
 <CACac1F_ntCCez_QBqiuwK0A7b7cEVwtKY89wsWjL271RgE_gFQ@mail.gmail.com>
Message-ID: <CAPTjJmpHUX0H=sFBP7_f4ab_JPE8fpGu_LLBOCACCnvfSyc-8A@mail.gmail.com>

On Mon, May 14, 2018 at 10:49 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 14 May 2018 at 13:27, Chris Angelico <rosuav at gmail.com> wrote:
>> On Mon, May 14, 2018 at 9:59 PM, Paul Moore <p.f.moore at gmail.com> wrote:
>>> The problem is that supplying cum_weights allows the code to run in
>>> O(log n) by using bisection. This is significantly faster on large
>>> populations. Adding a test that the cumulative weights are
>>> nondecreasing would add an O(n) step to the code.
>>>
>>
>> Hang on - are the 'n' and 'log n' there referring to the same n?
>
> Yes. The number of elements in the sample population (which is the
> same as the number of entries in the weights/cum_weights arrays).

Okay, cool. Thanks. I was a little confused as to whether the weights
were getting grouped up or not. Have seen too many cases where someone
panics about an O(n?) on a tiny n that's unrelated to the important
O(n) on a huge n :)

ChrisA


From rosuav at gmail.com  Mon May 14 08:55:37 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Mon, 14 May 2018 22:55:37 +1000
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <96949666-183e-c6a9-6431-e5eac64325dc@kynesim.co.uk>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org> <pcu1so$qbi$2@blaine.gmane.org>
 <CAPTjJmp5GyJi1BGCkag3GoatOHVH=umd831J3x+iukpK0FcNHA@mail.gmail.com>
 <20180513043120.GL12850@bladeshadow.org>
 <96949666-183e-c6a9-6431-e5eac64325dc@kynesim.co.uk>
Message-ID: <CAPTjJmo34iEWGhSw9M=HmZe0VB39R+in_u_k3=vFFnw9KT7zeQ@mail.gmail.com>

On Mon, May 14, 2018 at 10:49 PM, Rhodri James <rhodri at kynesim.co.uk> wrote:
> On 13/05/18 05:31, Python wrote:
>>
>> No, you are not.  Do you ever say "dog" when you mean "dot" instead?
>> Do you ever say "dad" when you mean "mom" instead?
>
>
> One of my aunts used to muddle family names all the time.  She once called
> me by my sister's name; one would have thought the beard was a clue to that
> one.
>
> Similarly  my mother once asked my sister to "Get the thingummy off the
> whatsit."  The alarming thing was that my sister understood this and handed
> her the correct object.

That's alarming to you? It's pretty normal in my family. I think we
all developed mindreading abilities as young children, or something.

ChrisA


From steve+comp.lang.python at pearwood.info  Mon May 14 08:59:12 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Mon, 14 May 2018 12:59:12 +0000 (UTC)
Subject: random.choices() Suggest that the code confirm that cum_weights
 sequence is in ascending order
References: <CA+og5upAoJX004vm+xZZED13rwtwExoLe3cY+pr_KUEmi7Sxtw@mail.gmail.com>
 <pdbsb4$unn$5@blaine.gmane.org>
 <CACac1F8pqzvMFv20yafmTO8s_R_PmW_wuGpL2SVo7g9bZGvQug@mail.gmail.com>
 <CAPTjJmoasGyuBj60BROj_YpJw_uU56HN-gOmMCSE-7ombCwcew@mail.gmail.com>
Message-ID: <pdc16v$unn$7@blaine.gmane.org>

On Mon, 14 May 2018 22:27:24 +1000, Chris Angelico wrote:

> On Mon, May 14, 2018 at 9:59 PM, Paul Moore <p.f.moore at gmail.com> wrote:
>> The problem is that supplying cum_weights allows the code to run in
>> O(log n) by using bisection. This is significantly faster on large
>> populations. Adding a test that the cumulative weights are
>> nondecreasing would add an O(n) step to the code.
>>
>>
> Hang on - are the 'n' and 'log n' there referring to the same n?

Yes -- the number of values you are choosing from, hence the number of 
weights.

If there are N values (and N weights), an upfront check would need to 
look at all N of them in the worst case that they were already in non-
descending order. (Of course it can bail out early if the check fails.)

Whereas the choice itself can use bisect to do a binary search of the 
values, which on average takes only log N comparisons.


-- 
Steve



From p.f.moore at gmail.com  Mon May 14 09:06:03 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 14 May 2018 14:06:03 +0100
Subject: random.choices() Suggest that the code confirm that cum_weights
 sequence is in ascending order
In-Reply-To: <CAPTjJmpHUX0H=sFBP7_f4ab_JPE8fpGu_LLBOCACCnvfSyc-8A@mail.gmail.com>
References: <CA+og5upAoJX004vm+xZZED13rwtwExoLe3cY+pr_KUEmi7Sxtw@mail.gmail.com>
 <pdbsb4$unn$5@blaine.gmane.org>
 <CACac1F8pqzvMFv20yafmTO8s_R_PmW_wuGpL2SVo7g9bZGvQug@mail.gmail.com>
 <CAPTjJmoasGyuBj60BROj_YpJw_uU56HN-gOmMCSE-7ombCwcew@mail.gmail.com>
 <CACac1F_ntCCez_QBqiuwK0A7b7cEVwtKY89wsWjL271RgE_gFQ@mail.gmail.com>
 <CAPTjJmpHUX0H=sFBP7_f4ab_JPE8fpGu_LLBOCACCnvfSyc-8A@mail.gmail.com>
Message-ID: <CACac1F_qDVK3Er_ZHfxz0Ta+Vt7cqxxQ5Lqd_dBvt=08nzZqoQ@mail.gmail.com>

On 14 May 2018 at 13:53, Chris Angelico <rosuav at gmail.com> wrote:
> On Mon, May 14, 2018 at 10:49 PM, Paul Moore <p.f.moore at gmail.com> wrote:
>> On 14 May 2018 at 13:27, Chris Angelico <rosuav at gmail.com> wrote:
>>> On Mon, May 14, 2018 at 9:59 PM, Paul Moore <p.f.moore at gmail.com> wrote:
>>>> The problem is that supplying cum_weights allows the code to run in
>>>> O(log n) by using bisection. This is significantly faster on large
>>>> populations. Adding a test that the cumulative weights are
>>>> nondecreasing would add an O(n) step to the code.
>>>>
>>>
>>> Hang on - are the 'n' and 'log n' there referring to the same n?
>>
>> Yes. The number of elements in the sample population (which is the
>> same as the number of entries in the weights/cum_weights arrays).
>
> Okay, cool. Thanks. I was a little confused as to whether the weights
> were getting grouped up or not. Have seen too many cases where someone
> panics about an O(n?) on a tiny n that's unrelated to the important
> O(n) on a huge n :)

Yeah, for all of *my* uses of the functions in random, n is so small
as to make all this irrelevant. But when I looked into how cum_weights
worked, I realised it's aimed at people passing significant sized data
sets. An they would probably be hit hard by a change from O(log n) to
O(n).

One thing I always liked about C++ was the way the standard library
documented a lot of the O(n) properties of the operations. It not only
made it easier to know what was costly and what wasn't, it also made
it much clearer what functions were intended for use on large data
sets. I sort of miss that information in Python - not least because
functions like random.choices are often a lot faster than I'd naively
expect.

Paul


From steve+comp.lang.python at pearwood.info  Mon May 14 09:07:30 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Mon, 14 May 2018 13:07:30 +0000 (UTC)
Subject: random.choices() Suggest that the code confirm that cum_weights
 sequence is in ascending order
References: <CA+og5upAoJX004vm+xZZED13rwtwExoLe3cY+pr_KUEmi7Sxtw@mail.gmail.com>
 <pdbsb4$unn$5@blaine.gmane.org>
 <CACac1F8pqzvMFv20yafmTO8s_R_PmW_wuGpL2SVo7g9bZGvQug@mail.gmail.com>
Message-ID: <pdc1mi$unn$8@blaine.gmane.org>

On Mon, 14 May 2018 12:59:28 +0100, Paul Moore wrote:

> The problem is that supplying cum_weights allows the code to run in
> O(log n) by using bisection. This is significantly faster on large
> populations. Adding a test that the cumulative weights are nondecreasing
> would add an O(n) step to the code.
> 
> So while I understand the OP's problem, I don't think it's soluble
> without making the cum_weights argument useless in practice.

How does O(N) make it "useless"? There are lots of O(N) algorithms, even 
O(N**2) and O(2**N) which are nevertheless still useful.

Besides, might this be "premature optimization"? I get it that everyone 
wants their code to be faster rather than unnecessarily slower, but how 
often is random.choices() the bottleneck in your application?



> Better
> documentation might be worthwhile (although I don't personally find the
> current docs confusing, so suggestions for improvements would be
> helpful).

Indeed.

Hopefully the OP is still reading and is willing to sign up on the bug 
tracker.



-- 
Steve



From p.f.moore at gmail.com  Mon May 14 09:35:34 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 14 May 2018 14:35:34 +0100
Subject: random.choices() Suggest that the code confirm that cum_weights
 sequence is in ascending order
In-Reply-To: <pdc1mi$unn$8@blaine.gmane.org>
References: <CA+og5upAoJX004vm+xZZED13rwtwExoLe3cY+pr_KUEmi7Sxtw@mail.gmail.com>
 <pdbsb4$unn$5@blaine.gmane.org>
 <CACac1F8pqzvMFv20yafmTO8s_R_PmW_wuGpL2SVo7g9bZGvQug@mail.gmail.com>
 <pdc1mi$unn$8@blaine.gmane.org>
Message-ID: <CACac1F9th4Vu_eSfbKkPh7Qz89FEdJnM8Y-Y2XLfFtWO-h1_Hw@mail.gmail.com>

On 14 May 2018 at 14:07, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Mon, 14 May 2018 12:59:28 +0100, Paul Moore wrote:
>
>> The problem is that supplying cum_weights allows the code to run in
>> O(log n) by using bisection. This is significantly faster on large
>> populations. Adding a test that the cumulative weights are nondecreasing
>> would add an O(n) step to the code.
>>
>> So while I understand the OP's problem, I don't think it's soluble
>> without making the cum_weights argument useless in practice.
>
> How does O(N) make it "useless"? There are lots of O(N) algorithms, even
> O(N**2) and O(2**N) which are nevertheless still useful.

Well, I've never seen an actual use case for this argument (I can't
think of a case where I'd even have cumulative weights rather than
weights, and obviously calculating the cumulative weights from the
actual weights is what we're trying to avoid). And if you have
cum_weights and O(n) is fine, then calculating weights from
cum_weights is acceptable (although pointless, as it simply duplicates
work). So the people who *really* need cum_weights are those who have
the cumulative weights already, and cannot afford an O(n)
precalculation step.

But yes, clearly in itself an O(n) algorithm isn't useless. And
agreed, in most cases whether random.choices() is O(n) or O(log n) is
irrelevant in practice.

Paul


From python at bladeshadow.org  Mon May 14 11:20:06 2018
From: python at bladeshadow.org (Python)
Date: Mon, 14 May 2018 10:20:06 -0500
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <CAPTjJmopiuzEN8MqtJwGpB8+wK=a-8z2jGRn4W6_scbZU1HLdg@mail.gmail.com>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org>
 <pcu1so$qbi$2@blaine.gmane.org>
 <CAPTjJmp5GyJi1BGCkag3GoatOHVH=umd831J3x+iukpK0FcNHA@mail.gmail.com>
 <20180513043120.GL12850@bladeshadow.org>
 <CAPTjJmopiuzEN8MqtJwGpB8+wK=a-8z2jGRn4W6_scbZU1HLdg@mail.gmail.com>
Message-ID: <20180514152006.GM12850@bladeshadow.org>

On Sun, May 13, 2018 at 02:42:48PM +1000, Chris Angelico wrote:
> On Sun, May 13, 2018 at 2:31 PM, Python <python at bladeshadow.org> wrote:
> >> Yes, and I'd go further: I *am* too stupid to get this right.
> >
> > No, you are not.  Do you ever say "dog" when you mean "dot" instead?
> > Do you ever say "dad" when you mean "mom" instead?  Internalize that
> > "=" is "equals" (or "assigns" if you prefer) and "==" is "is equal to"
> > then use those phrases in your head when you're thinking about which
> > one you need in your code, and I'm pretty sure you'll stop making this
> > mistake.  It may help that the phrase with twice as many syllables
> > represents the operator that has twice as many characters.  Eventually
> > it becomes second nature, like not calling Dad "Mom."
> 
> Riiiight, of course. Because prevention of bugs is just a matter of
> wanting to. 

Preventing *certain classes* of bugs, mainly botching syntax, is mostly
just a matter of wanting to, like a piano virtuoso who can play
complicated pieces night after night flawlessly.  It just takes focus
and practice.  Preventing the = vs. == bug is nowhere near as 
complex or difficut as La Campanella, so you don't even need to be a
virtuoso.  You just have to be mindful and careful.



From python at bladeshadow.org  Mon May 14 11:29:03 2018
From: python at bladeshadow.org (Python)
Date: Mon, 14 May 2018 10:29:03 -0500
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <pd966b$unn$4@blaine.gmane.org>
References: <7s86fd1bncg5hovboehvvqe57budhc2bf8@4ax.com>
 <20180513024213.GG12850@bladeshadow.org>
 <pd966b$unn$4@blaine.gmane.org>
Message-ID: <20180514152903.GN12850@bladeshadow.org>

On Sun, May 13, 2018 at 11:05:48AM +0000, Steven D'Aprano wrote:
> On Sat, 12 May 2018 21:42:13 -0500, Python wrote:
> 
> > Responding to this further would essentially just require me to
> > reiterate what I already wrote--I won't do that.  I'll simply maintain
> > that in my rather lenghty experience, this mistake has actually been
> > rather rare and has to my knowledge *never* caused a support issue
> > requiring a bug fix to production code in projects I've been associated
> > with.  It's a useful construction whose detriment has, IMO, been
> > completely overblown.
> 
> I already linked to the attempt to install a backdoor in the Linux kernel 
> with this, but even for accidental errors, thirty seconds on the CVE 
> database finds at least one real-world example:
> 
> https://www.cvedetails.com/cve/CVE-2009-4633/
> 
> I expect that these days it will be rare, since most C compilers would 
> default to warning about it if you run with warnings enabled.

A couple of anecdotes is a very far way off from making the case.
Either the code was not reviewed or the reviewer was careless.  And
I'm not saying it never happens, I'm saying it's not any worse than
any other possible bug, and far less common in practice than plenty of
other classes of bugs.  I'm also not saying that you couldn't use a
different operator that's less likely to cause confusion.  I *am*
saying this is a useful feature that I find myself wanting very often.
Obviously since there's a PEP about a way to provide exactly this
feature, plenty of people consider it a worthwhile feature to have.

Yes, bugs happen.  Eliminating useful constructs from the language is
not a good way of dealing with that problem.



From python at bladeshadow.org  Mon May 14 11:38:19 2018
From: python at bladeshadow.org (Python)
Date: Mon, 14 May 2018 10:38:19 -0500
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <CAPTjJmpp=wqgSQ0sWXsh6jnDDYTHtNkO1Ct1BGQqTe1iD8exqQ@mail.gmail.com>
References: <7s86fd1bncg5hovboehvvqe57budhc2bf8@4ax.com>
 <20180513024213.GG12850@bladeshadow.org>
 <pd966b$unn$4@blaine.gmane.org>
 <CAPTjJmpp=wqgSQ0sWXsh6jnDDYTHtNkO1Ct1BGQqTe1iD8exqQ@mail.gmail.com>
Message-ID: <20180514153819.GO12850@bladeshadow.org>

On Sun, May 13, 2018 at 09:46:48PM +1000, Chris Angelico wrote:
> > I expect that these days it will be rare, since most C compilers would
> > default to warning about it if you run with warnings enabled.
> 
> That assumes that you regularly run with warnings enabled. While that
> might seem like a no-brainer, unfortunately it isn't. With the number
> of C compilers out there, it's hard to make sure your code compiles
> cleanly with -Wall on every one of them; and if there's a spew of
> warnings, one more isn't going to be noticed. So for a large codebase,
> it's entirely possible that it WON'T regularly be compiled with
> warnings enabled.

As it happens, my team does compile with -Wall -Werror at all times in
every project (though we do rely on some third-party libraries as
dependencies which we can not). But I do agree with your point...

> Warnings certainly help, but they're not a complete solution.

Absolutely correct.  If you're not doing THOROUGH code reviews, and
not thoroughly testing your code, your job is only half done.  You
should be your own first reviewer, and then have a second someone
competent review it after you do.  You should also be your own first
tester, and then have someone competent test it after you.  In both
cases, ideally the "someone competent" would be a team of someones,
though that's not always practical.  But I believe this process is
absolutely essential to producing non-trivial quality software.



From steve+comp.lang.python at pearwood.info  Mon May 14 12:12:55 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Mon, 14 May 2018 16:12:55 +0000 (UTC)
Subject: seeking deeper (language theory) reason behind Python design
 choice
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org> <pcu1so$qbi$2@blaine.gmane.org>
 <CAPTjJmp5GyJi1BGCkag3GoatOHVH=umd831J3x+iukpK0FcNHA@mail.gmail.com>
 <20180513043120.GL12850@bladeshadow.org>
 <CAPTjJmopiuzEN8MqtJwGpB8+wK=a-8z2jGRn4W6_scbZU1HLdg@mail.gmail.com>
 <20180514152006.GM12850@bladeshadow.org>
Message-ID: <pdcci7$unn$9@blaine.gmane.org>

On Mon, 14 May 2018 10:20:06 -0500, Python wrote:

> Preventing *certain classes* of bugs, mainly botching syntax, is mostly
> just a matter of wanting to, 

That comment is very ignorant of the mental processes involved in both 
language processing and typing, two skills used in programming. You can't 
prevent errors merely, or even "mostly", by wanting not to make errors.


> like a piano virtuoso who can play
> complicated pieces night after night flawlessly.

Right up until the moment that they make a mistake, which they do.

Virtuosos suffer from fatigue or injuries, they have slumps, they have 
bad days, they often cannot reproduce the same performance (every 
performance is unique since they are not robots that can repeat every 
minute motion over and over again) and they make mistakes. "Flawlessly" 
does not mean without flaw, it is mere hyperbole.

https://www.telegraph.co.uk/culture/music/
classicalconcertreviews/10878171/Khatia-Buniatishvili-Queen-Elizabeth-
Hall-review-sorely-disappointing.html


> It just takes focus
> and practice.  Preventing the = vs. == bug is nowhere near as complex or
> difficut as La Campanella, so you don't even need to be a virtuoso.  You
> just have to be mindful and careful.

Botched syntax is a form of botched spelling.

https://mail.python.org/pipermail/python-list/2018-May/733040.html

Maybe you just didn't want to spell "pposted" or "lenghty" correctly?


? propos of nothing, I used to know somebody who seriously used to argue 
that his spelling mistakes were deliberate. Not as as a self-deprecating 
joke. He literally tried to convince people that whenever he spelled 
something incorrectly, it was a deliberate choice for "irony" or 
"rhetorical effect" or "my own personal reasons". He fooled nobody.

Very sad, the extents people will go to to fool themselves into believing 
that they have 100% control over each and every one of their actions. 
Just sayin'.



-- 
Steve



From ian.g.kelly at gmail.com  Mon May 14 13:37:18 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Mon, 14 May 2018 11:37:18 -0600
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <20180514152006.GM12850@bladeshadow.org>
References: <20180507202722.GD7876@tauhou> <pcqrv9$16m$12@blaine.gmane.org>
 <20180509034852.GB12850@bladeshadow.org> <pcu1so$qbi$2@blaine.gmane.org>
 <CAPTjJmp5GyJi1BGCkag3GoatOHVH=umd831J3x+iukpK0FcNHA@mail.gmail.com>
 <20180513043120.GL12850@bladeshadow.org>
 <CAPTjJmopiuzEN8MqtJwGpB8+wK=a-8z2jGRn4W6_scbZU1HLdg@mail.gmail.com>
 <20180514152006.GM12850@bladeshadow.org>
Message-ID: <CALwzidm1m1_bjGZe16f7d_NZNhjD2=YNOuSNkesX+moHAj8iwQ@mail.gmail.com>

On Mon, May 14, 2018 at 9:20 AM, Python <python at bladeshadow.org> wrote:
> On Sun, May 13, 2018 at 02:42:48PM +1000, Chris Angelico wrote:
>> On Sun, May 13, 2018 at 2:31 PM, Python <python at bladeshadow.org> wrote:
>> >> Yes, and I'd go further: I *am* too stupid to get this right.
>> >
>> > No, you are not.  Do you ever say "dog" when you mean "dot" instead?
>> > Do you ever say "dad" when you mean "mom" instead?  Internalize that
>> > "=" is "equals" (or "assigns" if you prefer) and "==" is "is equal to"
>> > then use those phrases in your head when you're thinking about which
>> > one you need in your code, and I'm pretty sure you'll stop making this
>> > mistake.  It may help that the phrase with twice as many syllables
>> > represents the operator that has twice as many characters.  Eventually
>> > it becomes second nature, like not calling Dad "Mom."
>>
>> Riiiight, of course. Because prevention of bugs is just a matter of
>> wanting to.
>
> Preventing *certain classes* of bugs, mainly botching syntax, is mostly
> just a matter of wanting to, like a piano virtuoso who can play
> complicated pieces night after night flawlessly.  It just takes focus
> and practice.  Preventing the = vs. == bug is nowhere near as
> complex or difficut as La Campanella, so you don't even need to be a
> virtuoso.  You just have to be mindful and careful.

I'm reminded of the first bullet point of step 6 in this article,
which just crossed my inbox this morning:

https://www.e4developer.com/2018/05/13/how-to-write-horrible-java/


From mkiever at Pirx.sirius.org  Mon May 14 13:46:28 2018
From: mkiever at Pirx.sirius.org (Matthias Kievernagel)
Date: Mon, 14 May 2018 17:46:28 +0000 (UTC)
Subject: spurious BadDrawable error when running test_tk
Message-ID: <pdci1i$1cdv$1@gioia.aioe.org>

Dear list,

I changed some detail in the tkinter library,
so I'm running the tk test like this:

./python -m test -u gui -v test_tk

Approximately every 2 or 3 runs I get a BadDrawable error
from the X server, most of the time at the end after
the last test finished successfully.
As this also happens when I run the test on the unmodified CPython sources
I suspect it is a shortcoming of my non-mainstream setup.
I use ctwm with interactive window placement,
so running the test involves a lot of clicks.
Does anyone know if the errors are to be expected
or should it work nonetheless?
I haven't found anything on b.p.o. about this.

Thanks for any insights,
Matthias Kievernagel




From ian.g.kelly at gmail.com  Mon May 14 14:02:47 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Mon, 14 May 2018 12:02:47 -0600
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <20180514153819.GO12850@bladeshadow.org>
References: <7s86fd1bncg5hovboehvvqe57budhc2bf8@4ax.com>
 <20180513024213.GG12850@bladeshadow.org>
 <pd966b$unn$4@blaine.gmane.org>
 <CAPTjJmpp=wqgSQ0sWXsh6jnDDYTHtNkO1Ct1BGQqTe1iD8exqQ@mail.gmail.com>
 <20180514153819.GO12850@bladeshadow.org>
Message-ID: <CALwzidk=0AMKd81GPrqACp8spoV62ia6b6afR+X16kM-r1zOKA@mail.gmail.com>

On Mon, May 14, 2018 at 9:38 AM, Python <python at bladeshadow.org> wrote:
> Absolutely correct.  If you're not doing THOROUGH code reviews, and
> not thoroughly testing your code, your job is only half done.  You
> should be your own first reviewer, and then have a second someone
> competent review it after you do.

One should never be their own "first reviewer" because it may lead to
the mindset that a "second reviewer" is unnecessary. You're about as
likely to notice the glaring bugs in the code that you just wrote as
you are to notice the missing or misspelled words in the sentence you
just penned. Why? Because you just wrote it, and as a result you
believe that you know what it says, and you'll simply fail to process
the fact that it actually says something different.

That said, when I'm doing a code review, my focus is on all of the
following things:

* Design: does this code make sense for what it's trying to accomplish?
* Functionality: does the code work as intended?
* Readability: can I understand it, and will others understand it later?
* Complexity: could this code be simpler?
* Tests: does the code include good tests?

The existence of subtle bugs are just one of the things that I'm
thinking about, so from my perspective, the more the compiler can help
with this, the better. In C, if I miss a misplaced '=' then the code
will do the wrong thing. In Python, I don't even have to worry about
it, and I like it that way. So when you say that '=' as an expression
should be supported because you think it's useful, and anyway those
sorts of bugs will be caught by code reviews, the way that reads to me
is:

"'=' as an expression should be supported because it's convenient to
me, and I don't believe I write bugs, and if I do it doesn't matter
because my time is important than that of the person who reviews my
code."


From theNurd at nurdletech.com  Mon May 14 14:26:54 2018
From: theNurd at nurdletech.com (Ken Kundert)
Date: Mon, 14 May 2018 11:26:54 -0700
Subject: f-string anomaly
References: <pda3ae$18kj$1@gioia.aioe.org> <pdaquv$g15$1@blaine.gmane.org>
 <mailman.20.1526263724.2761.python-list@python.org>
 <pdb5jp$pg7$1@gioia.aioe.org> <878t8melt8.fsf@metapensiero.it>
 <mailman.23.1526283039.2761.python-list@python.org>
Message-ID: <pdckdc$1gms$1@gioia.aioe.org>

Lele,
    I'm afraid I was unclear. The ... in the code snippet was intended
to imply that these lines were appended to the end of the original code,
where d was defined.

-Ken

On 05/14/2018 12:30 AM, Lele Gaifax wrote:
> Ken Kundert <theNurd at nurdletech.com> writes:
> 
>> I tried adding k and v to the local namespace:
>>
>>     ...
>>     k = 6
>>     v = 9
>>     print(f'Email: {d:{{k}} {{v}}}')
>>
>> I still got:
>>
>>     NameError: name 'k' is not defined
> 
> This is not what I get:
> 
>     Python 3.6.5 (default, May 11 2018, 13:30:17) 
>     [GCC 7.3.0] on linux
>     Type "help", "copyright", "credits" or "license" for more information.
>     >>> k=1
>     >>> v=2
>     >>> print(f'this is {{k}} and {{v}}')
>     this is {k} and {v}
>     >>> print(f'this is {k} and {v}')
>     this is 1 and 2
>     >>> print(f'Email: {d:{{k}} {{v}}}')
>     Traceback (most recent call last):
>       File "<stdin>", line 1, in <module>
>     NameError: name 'd' is not defined
> 
> ciao, lele.
> 



From garyfallidis at gmail.com  Mon May 14 14:32:53 2018
From: garyfallidis at gmail.com (Eleftherios Garyfallidis)
Date: Mon, 14 May 2018 14:32:53 -0400
Subject: ANN: DIPY 0.14.0
In-Reply-To: <CAN6JmWMOfniqEi6D5t=xqbfj6xjwk=0dkKYLpgEgQm9MAxB2gQ@mail.gmail.com>
References: <CAN6JmWMOfniqEi6D5t=xqbfj6xjwk=0dkKYLpgEgQm9MAxB2gQ@mail.gmail.com>
Message-ID: <CAN6JmWPK2ANBTcyG65BaWxZOO3t3rbiCmPhQ=sJcAeNydsZVUw@mail.gmail.com>

Hello all!

We are excited to announce a new *major release* of Diffusion Imaging in
Python (DIPY).

*DIPY 0.14 (Tuesday, 1rst May 2018)*

This release received contributions from *24 developers*. A warm thank you
to each one of you for your contribution.

The complete release notes are available at:
http://nipy.org/dipy/release0.14.html

*Highlights *of this release include:


   - *RecoBundles*: anatomically relevant segmentation of bundles
   - New super fast clustering algorithm: *QuickBundlesX*
   - New tracking algorithm:* Particle Filtering Tracking*.
   - New tracking algorithm: *Probabilistic Residual Bootstrap Tracking*.
   - New API for reading, saving and processing tractograms.
   - Fiber ORientation Estimated using Continuous Axially Symmetric Tensors
   (*FORECAST*).
   - New command line interfaces.
   - Deprecated fvtk (old visualization framework).
   - A range of new visualization improvements.
   - *Large documentation update*.

To upgrade, run the following command in your terminal:

*pip install --upgrade dipy*

or

*conda install -c conda-forge dipy*

This version of DIPY depends on recent versions of nibabel (2.1.0+).

For any questions go to http://dipy.org, or send an e-mail to
neuroimaging at python.org  or ask a question to our interactive chat room
available at https://gitter.im/nipy/dipy

On behalf of the DIPY developers,
Eleftherios Garyfallidis, Ariel Rokem, Serge Koudoro
http://dipy.org/developers.html


From tallpaul at gmail.com  Mon May 14 15:02:33 2018
From: tallpaul at gmail.com (Paul)
Date: Mon, 14 May 2018 12:02:33 -0700
Subject: Python-list Digest, Vol 176, Issue 16
In-Reply-To: <mailman.27.1526313603.24673.python-list@python.org>
References: <mailman.27.1526313603.24673.python-list@python.org>
Message-ID: <CA+og5ur2E8nXwbN+-gWEZP5xoD7-L_cF697nS9xQ4f+=N56eiA@mail.gmail.com>

Hello all,
   Thanks for the thoughtful (and non-snarky) replies.

First, a suggestion for a documentation change:

To this paragraph:

*If neither weights nor cum_weights are specified, selections are made with
equal probability. If a weights sequence is supplied, it must be the same
length as the population sequence. It is a TypeError
<https://docs.python.org/3/library/exceptions.html#TypeError> to specify
both weights and cum_weights.*
Add this sentence:

"A cum_weights sequence, if supplied, must be in strictly-ascending order,
else incorrect results will be (silently) returned."

Secondly, about the cost of verifying the sequence:

1) I understand the added cost of verifying the sequence.  However, this
appears to be a one-time cost.  E.G., if I submit this,

random.choices(lm,cum_weights=[25,26,36,46,136],k=400

then the code will do an O(n log n) operation 400 times.

If verification was added, then the the code would do an O(n log n)
operation 400 times, plus an O(n) operation done *one* time.   So, I'm not
sure that this would be a significant efficiency hit (except in rare cases).

2) Paul Moore wrote:

> So the people who *really* need cum_weights are those

> who have the cumulative weights already, and cannot

> afford an O(n)precalculation step.


I agree that with the "already have the cum_weights" argument.  Based on my
point #1, I'm not convinced about the "can't afford" argument.

3) A minor point.  The documentation also says: "so supplying the
cumulative weights saves work."  However, this is work done (once, as noted
above) by a computer rather than work done (even if aided by a a computer)
by a human, so I'd vote for having the computer do it. :)


To conclude, I would still lean slightly toward having the code enforce the
'strictly-ascending sequence' requirement.  However, given that a)
improving the documentation is much more doable and that, b) in some cases,
the addition of an order O(n) step might be significant, I'd be more than
happy if the documentation could be improved (as suggested).

thanks
  Paul Czyzewki

PS.  I see the issue which steven.daprano opened.  Thanks, Steven.
However, I'm not sure what's appropriate in terms of updating that issue,
or even if I have permission to update it, so I'd appreciate if someone
would add this response to the issue. Thanks.



> From: Paul Moore <p.f.moore at gmail.com>
> To: "Steven D'Aprano" <steve+comp.lang.python at pearwood.info>
> Cc: Python <python-list at python.org>
> Bcc:
> Date: Mon, 14 May 2018 14:35:34 +0100
> Subject: Re: random.choices() Suggest that the code confirm that
> cum_weights sequence is in ascending order
> On 14 May 2018 at 14:07, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
> > On Mon, 14 May 2018 12:59:28 +0100, Paul Moore wrote:
> >
> >> The problem is that supplying cum_weights allows the code to run in
> >> O(log n) by using bisection. This is significantly faster on large
> >> populations. Adding a test that the cumulative weights are nondecreasing
> >> would add an O(n) step to the code.
> >>
> >> So while I understand the OP's problem, I don't think it's soluble
> >> without making the cum_weights argument useless in practice.
> >
> > How does O(N) make it "useless"? There are lots of O(N) algorithms, even
> > O(N**2) and O(2**N) which are nevertheless still useful.
>
> Well, I've never seen an actual use case for this argument (I can't
> think of a case where I'd even have cumulative weights rather than
> weights, and obviously calculating the cumulative weights from the
> actual weights is what we're trying to avoid). And if you have
> cum_weights and O(n) is fine, then calculating weights from
> cum_weights is acceptable (although pointless, as it simply duplicates
> work). So the people who *really* need cum_weights are those who have
> the cumulative weights already, and cannot afford an O(n)
> precalculation step.
>
> But yes, clearly in itself an O(n) algorithm isn't useless. And
> agreed, in most cases whether random.choices() is O(n) or O(log n) is
> irrelevant in practice.
>
> Paul
>


From tallpaul at gmail.com  Mon May 14 15:03:38 2018
From: tallpaul at gmail.com (Paul)
Date: Mon, 14 May 2018 12:03:38 -0700
Subject: random.choices() Suggest that the code confirm that cum_weights
 sequence is in ascending order
Message-ID: <CA+og5upux0S=mhOnEYS5kXXhCbYgLgrZrwHQ+S63uFPpGO7Xiw@mail.gmail.com>

forgot to edit the subject.  Sorry.
  paul c.

On Mon, May 14, 2018 at 12:02 PM, Paul <tallpaul at gmail.com> wrote:

> Hello all,
>    Thanks for the thoughtful (and non-snarky) replies.
>
> First, a suggestion for a documentation change:
>
> To this paragraph:
>
> *If neither weights nor cum_weights are specified, selections are made
> with equal probability. If a weights sequence is supplied, it must be the
> same length as the population sequence. It is a TypeError
> <https://docs.python.org/3/library/exceptions.html#TypeError> to specify
> both weights and cum_weights.*
> Add this sentence:
>
> "A cum_weights sequence, if supplied, must be in strictly-ascending order,
> else incorrect results will be (silently) returned."
>
> Secondly, about the cost of verifying the sequence:
>
> 1) I understand the added cost of verifying the sequence.  However, this
> appears to be a one-time cost.  E.G., if I submit this,
>
> random.choices(lm,cum_weights=[25,26,36,46,136],k=400
>
> then the code will do an O(n log n) operation 400 times.
>
> If verification was added, then the the code would do an O(n log n)
> operation 400 times, plus an O(n) operation done *one* time.   So, I'm not
> sure that this would be a significant efficiency hit (except in rare cases).
>
> 2) Paul Moore wrote:
>
> > So the people who *really* need cum_weights are those
>
> > who have the cumulative weights already, and cannot
>
> > afford an O(n)precalculation step.
>
>
> I agree that with the "already have the cum_weights" argument.  Based on
> my point #1, I'm not convinced about the "can't afford" argument.
>
> 3) A minor point.  The documentation also says: "so supplying the
> cumulative weights saves work."  However, this is work done (once, as noted
> above) by a computer rather than work done (even if aided by a a computer)
> by a human, so I'd vote for having the computer do it. :)
>
>
> To conclude, I would still lean slightly toward having the code enforce
> the 'strictly-ascending sequence' requirement.  However, given that a)
> improving the documentation is much more doable and that, b) in some cases,
> the addition of an order O(n) step might be significant, I'd be more than
> happy if the documentation could be improved (as suggested).
>
> thanks
>   Paul Czyzewki
>
> PS.  I see the issue which steven.daprano opened.  Thanks, Steven.
> However, I'm not sure what's appropriate in terms of updating that issue,
> or even if I have permission to update it, so I'd appreciate if someone
> would add this response to the issue. Thanks.
>
>
>
>> From: Paul Moore <p.f.moore at gmail.com>
>> To: "Steven D'Aprano" <steve+comp.lang.python at pearwood.info>
>> Cc: Python <python-list at python.org>
>> Bcc:
>> Date: Mon, 14 May 2018 14:35:34 +0100
>> Subject: Re: random.choices() Suggest that the code confirm that
>> cum_weights sequence is in ascending order
>> On 14 May 2018 at 14:07, Steven D'Aprano
>> <steve+comp.lang.python at pearwood.info> wrote:
>> > On Mon, 14 May 2018 12:59:28 +0100, Paul Moore wrote:
>> >
>> >> The problem is that supplying cum_weights allows the code to run in
>> >> O(log n) by using bisection. This is significantly faster on large
>> >> populations. Adding a test that the cumulative weights are
>> nondecreasing
>> >> would add an O(n) step to the code.
>> >>
>> >> So while I understand the OP's problem, I don't think it's soluble
>> >> without making the cum_weights argument useless in practice.
>> >
>> > How does O(N) make it "useless"? There are lots of O(N) algorithms, even
>> > O(N**2) and O(2**N) which are nevertheless still useful.
>>
>> Well, I've never seen an actual use case for this argument (I can't
>> think of a case where I'd even have cumulative weights rather than
>> weights, and obviously calculating the cumulative weights from the
>> actual weights is what we're trying to avoid). And if you have
>> cum_weights and O(n) is fine, then calculating weights from
>> cum_weights is acceptable (although pointless, as it simply duplicates
>> work). So the people who *really* need cum_weights are those who have
>> the cumulative weights already, and cannot afford an O(n)
>> precalculation step.
>>
>> But yes, clearly in itself an O(n) algorithm isn't useless. And
>> agreed, in most cases whether random.choices() is O(n) or O(log n) is
>> irrelevant in practice.
>>
>> Paul
>>
>


From lele at metapensiero.it  Mon May 14 15:24:23 2018
From: lele at metapensiero.it (Lele Gaifax)
Date: Mon, 14 May 2018 21:24:23 +0200
Subject: f-string anomaly
References: <pda3ae$18kj$1@gioia.aioe.org> <pdaquv$g15$1@blaine.gmane.org>
 <mailman.20.1526263724.2761.python-list@python.org>
 <pdb5jp$pg7$1@gioia.aioe.org> <878t8melt8.fsf@metapensiero.it>
 <mailman.23.1526283039.2761.python-list@python.org>
 <pdckdc$1gms$1@gioia.aioe.org>
Message-ID: <87zi12ca6w.fsf@metapensiero.it>

Ken Kundert <theNurd at nurdletech.com> writes:

> Lele,
>     I'm afraid I was unclear. The ... in the code snippet was intended
> to imply that these lines were appended to the end of the original code,
> where d was defined.

Ok, but then I get a different behaviour:

    Python 3.6.5 (default, May 11 2018, 13:30:17) 
    [GCC 7.3.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> k=1
    >>> v=2
    >>> d=3
    >>> print(f'Email: {d:{{k}} {{v}}}')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ValueError: Invalid format specifier

Which Python version are you using?

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivr? di quello che ho pensato ieri
real: Emanuele Gaifas | comincer? ad aver paura di chi mi copia.
lele at metapensiero.it  |                 -- Fortunato Depero, 1929.



From python at mrabarnett.plus.com  Mon May 14 15:54:36 2018
From: python at mrabarnett.plus.com (MRAB)
Date: Mon, 14 May 2018 20:54:36 +0100
Subject: f-string anomaly
In-Reply-To: <87zi12ca6w.fsf@metapensiero.it>
References: <pda3ae$18kj$1@gioia.aioe.org> <pdaquv$g15$1@blaine.gmane.org>
 <mailman.20.1526263724.2761.python-list@python.org>
 <pdb5jp$pg7$1@gioia.aioe.org> <878t8melt8.fsf@metapensiero.it>
 <mailman.23.1526283039.2761.python-list@python.org>
 <pdckdc$1gms$1@gioia.aioe.org> <87zi12ca6w.fsf@metapensiero.it>
Message-ID: <d1664f81-b484-322c-2104-d3d19554d1f5@mrabarnett.plus.com>

On 2018-05-14 20:24, Lele Gaifax wrote:
> Ken Kundert <theNurd at nurdletech.com> writes:
> 
>> Lele,
>>     I'm afraid I was unclear. The ... in the code snippet was intended
>> to imply that these lines were appended to the end of the original code,
>> where d was defined.
> 
> Ok, but then I get a different behaviour:
> 
>      Python 3.6.5 (default, May 11 2018, 13:30:17)
>      [GCC 7.3.0] on linux
>      Type "help", "copyright", "credits" or "license" for more information.
>      >>> k=1
>      >>> v=2
>      >>> d=3
>      >>> print(f'Email: {d:{{k}} {{v}}}')
>      Traceback (most recent call last):
>        File "<stdin>", line 1, in <module>
>      ValueError: Invalid format specifier
> 
> Which Python version are you using?
> 
You need to look at the original post for the value of 'd':

class mydict(dict):
     def __format__(self, template):
         print('Template:', template)
         return ', '.join(template.format(v, k=k, v=v) for k, v in 
self.items())

d = mydict(bob='239-8402', ted='371-8567', carol='891-5810',
alice='552-2219')


From theNurd at nurdletech.com  Mon May 14 17:33:23 2018
From: theNurd at nurdletech.com (Ken Kundert)
Date: Mon, 14 May 2018 14:33:23 -0700
Subject: f-string anomaly
References: <pda3ae$18kj$1@gioia.aioe.org> <pdaquv$g15$1@blaine.gmane.org>
 <mailman.20.1526263724.2761.python-list@python.org>
 <pdb5jp$pg7$1@gioia.aioe.org> <878t8melt8.fsf@metapensiero.it>
 <mailman.23.1526283039.2761.python-list@python.org>
 <pdckdc$1gms$1@gioia.aioe.org> <87zi12ca6w.fsf@metapensiero.it>
 <mailman.50.1526325873.2761.python-list@python.org>
Message-ID: <pdcvb2$46u$1@gioia.aioe.org>

Lele,
    I am using Python3.6. d has to be an object of mydict.

Here is the code that exhibits the problem:

     import sys, os
     from inform import error, os_error

     class mydict(dict):
         def __format__(self, template):
             print('Template:', template)
             return ', '.join(template.format(v, k=k, v=v) for k, v in
self.items())


     d = mydict(bob='239-8402', ted='371-8567', carol='891-5810',
alice='552-2219')

     print('Using format():')
     print('Email: {0:{{k}}: {{v}}}'.format(d))
     print()
     print('Using f-string:')
     print(f'Email: {d:{{k}} {{v}}}')
     print()
     print('Using f-string:')
     k=6
     v=9
     print(f'Email: {d:{{k}} {{v}}}')

The result is:

    NameError: name 'k' is not defined

-Ken





On 05/14/2018 12:24 PM, Lele Gaifax wrote:
> Ken Kundert <theNurd at nurdletech.com> writes:
> 
>> Lele,
>>     I'm afraid I was unclear. The ... in the code snippet was intended
>> to imply that these lines were appended to the end of the original code,
>> where d was defined.
> 
> Ok, but then I get a different behaviour:
> 
>     Python 3.6.5 (default, May 11 2018, 13:30:17) 
>     [GCC 7.3.0] on linux
>     Type "help", "copyright", "credits" or "license" for more information.
>     >>> k=1
>     >>> v=2
>     >>> d=3
>     >>> print(f'Email: {d:{{k}} {{v}}}')
>     Traceback (most recent call last):
>       File "<stdin>", line 1, in <module>
>     ValueError: Invalid format specifier
> 
> Which Python version are you using?
> 
> ciao, lele.
> 



From lele at metapensiero.it  Mon May 14 17:55:13 2018
From: lele at metapensiero.it (Lele Gaifax)
Date: Mon, 14 May 2018 23:55:13 +0200
Subject: f-string anomaly
References: <pda3ae$18kj$1@gioia.aioe.org> <pdaquv$g15$1@blaine.gmane.org>
 <mailman.20.1526263724.2761.python-list@python.org>
 <pdb5jp$pg7$1@gioia.aioe.org> <878t8melt8.fsf@metapensiero.it>
 <mailman.23.1526283039.2761.python-list@python.org>
 <pdckdc$1gms$1@gioia.aioe.org> <87zi12ca6w.fsf@metapensiero.it>
 <mailman.50.1526325873.2761.python-list@python.org>
 <pdcvb2$46u$1@gioia.aioe.org>
Message-ID: <87vabpdhry.fsf@metapensiero.it>

Ken Kundert <theNurd at nurdletech.com> writes:

> Lele,
>     I am using Python3.6. d has to be an object of mydict.

My bad, sorry, I completely missed the premise :-|.

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivr? di quello che ho pensato ieri
real: Emanuele Gaifas | comincer? ad aver paura di chi mi copia.
lele at metapensiero.it  |                 -- Fortunato Depero, 1929.



From p.f.moore at gmail.com  Mon May 14 18:43:03 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 14 May 2018 23:43:03 +0100
Subject: Python-list Digest, Vol 176, Issue 16
In-Reply-To: <CA+og5ur2E8nXwbN+-gWEZP5xoD7-L_cF697nS9xQ4f+=N56eiA@mail.gmail.com>
References: <mailman.27.1526313603.24673.python-list@python.org>
 <CA+og5ur2E8nXwbN+-gWEZP5xoD7-L_cF697nS9xQ4f+=N56eiA@mail.gmail.com>
Message-ID: <CACac1F8eQR_LW7P+WfCUFwZoqX_GmVh=nuGebdcaECZMOievog@mail.gmail.com>

On 14 May 2018 at 20:02, Paul <tallpaul at gmail.com> wrote:
> 1) I understand the added cost of verifying the sequence.  However, this
> appears to be a one-time cost.  E.G., if I submit this,
>
> random.choices(lm,cum_weights=[25,26,36,46,136],k=400
>
> then the code will do an O(n log n) operation 400 times.
>
> If verification was added, then the the code would do an O(n log n)
> operation 400 times, plus an O(n) operation done *one* time.   So, I'm not
> sure that this would be a significant efficiency hit (except in rare cases).

That's a good point. But as I don't have any need myself for
random.choices with a significant population size (the only case where
this matters) I'll leave it to those who do use the functionality to
decide on that point.

Regards,
Paul


From summerrae78 at gmail.com  Mon May 14 19:04:21 2018
From: summerrae78 at gmail.com (summerrae78 at gmail.com)
Date: Mon, 14 May 2018 16:04:21 -0700 (PDT)
Subject: pylint/pyreverse with Python3
In-Reply-To: <mailman.21.1526263938.2761.python-list@python.org>
References: <alpine.LNX.2.20.1805130958220.6325@salmo.appl-ecosys.com>
 <pdar4k$g15$2@blaine.gmane.org>
 <mailman.21.1526263938.2761.python-list@python.org>
Message-ID: <79b6703e-571f-4767-b6aa-1fd3cf6dbf2f@googlegroups.com>

I'm having the same issue; can you give an example command line for python2 and python3 specific installation? 

Thanks!

On Sunday, May 13, 2018 at 7:12:29 PM UTC-7, Terry Reedy wrote:
> On 5/13/2018 1:01 PM, Rich Shepard wrote:
> >  ? Installed here is pylint-1.7.1 and python-3.6.5. When I try to run
> > pyreverse (and pylint) on python3 source code it fails because it finds 
> > only
> > the python-2.7 site-package and not the python-3.6 site-package.
> 
> >  ? If you have learned how to run pylint/pyreverse on python3 code please
> > share your knowledge with me.
> 
> You have to install a package in /site-packages for each version you 
> want to run it with.
> 
> Then you have to make sure you run the version you intend to run.
> 
> 
> -- 
> Terry Jan Reedy



From ben+python at benfinney.id.au  Mon May 14 19:19:48 2018
From: ben+python at benfinney.id.au (Ben Finney)
Date: Tue, 15 May 2018 09:19:48 +1000
Subject: object types, mutable or not?
References: <mailman.27.1526227203.13745.python-list@python.org>
 <20180513200201.GA26725@playground> <pdbtt8$unn$6@blaine.gmane.org>
Message-ID: <85r2mdn7u3.fsf@benfinney.id.au>

Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:

> Five years ago, the President Of the United States of America, or POTUS 
> for short, referred to Barrack Obama. Today, it refers to Donald Trump. 
> This didn't happen by mutating a single person (an object) from a 
> youngish black-skinned man to an oldish orange-skinned man. It happened 
> by re-assigning the name from Obama to Trump.

This is a good analogy.

> Likewise when you re-assign a variable name from one value (an object) to 
> another, the original object doesn't change. You just make the name refer 
> to a different object, while the first goes on its merry way (probably to 
> be collected by the garbage collector and the memory reclaimed).

Hopefully I am not the only one who wondered how closely the analogy to
POTUS extends into this description.

-- 
 \      ?I can picture in my mind a world without war, a world without |
  `\   hate. And I can picture us attacking that world, because they'd |
_o__)                                   never expect it.? ?Jack Handey |
Ben Finney



From python at bladeshadow.org  Mon May 14 19:20:13 2018
From: python at bladeshadow.org (Python)
Date: Mon, 14 May 2018 18:20:13 -0500
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <CALwzidk=0AMKd81GPrqACp8spoV62ia6b6afR+X16kM-r1zOKA@mail.gmail.com>
References: <7s86fd1bncg5hovboehvvqe57budhc2bf8@4ax.com>
 <20180513024213.GG12850@bladeshadow.org>
 <pd966b$unn$4@blaine.gmane.org>
 <CAPTjJmpp=wqgSQ0sWXsh6jnDDYTHtNkO1Ct1BGQqTe1iD8exqQ@mail.gmail.com>
 <20180514153819.GO12850@bladeshadow.org>
 <CALwzidk=0AMKd81GPrqACp8spoV62ia6b6afR+X16kM-r1zOKA@mail.gmail.com>
Message-ID: <20180514232013.GP12850@bladeshadow.org>

On Mon, May 14, 2018 at 12:02:47PM -0600, Ian Kelly wrote:
> On Mon, May 14, 2018 at 9:38 AM, Python <python at bladeshadow.org> wrote:
> > Absolutely correct.  If you're not doing THOROUGH code reviews, and
> > not thoroughly testing your code, your job is only half done.  You
> > should be your own first reviewer, and then have a second someone
> > competent review it after you do.
> 
> One should never be their own "first reviewer" because it may lead to
> the mindset that a "second reviewer" is unnecessary.

I went on to say that the second reviewer was required (i.e. this
should be considered a required part of good process).  If you decide
this is your process and it's required then it's required, regardless
of what you personally think.

> You're about as likely to notice the glaring bugs in the code that
> you just wrote as you are to notice the missing or misspelled words
> in the sentence you just penned.

I'm well acquainted with that pheonomenon, though I daresay that if
you proofread your own product you will often find your mistakes.  You
just won't always.  But, I never said review it right after you wrote
it, and in fact I don't do that (well, I do reread it if it seems
something potentially concerning).  Rather I review it when I'm about
to check it in, which for anything non-trivial is generally days
later, after it's been tested (which implies the tests were written).
I find my own bugs very often (but not nearly as often as I'd like).

I am hardly perfect.  What I am is thorough.  I would argue that is
required to write quality software.  If your goal is not to write
quality software, then none of this matters.  And if it is your goal,
you shouldn't need to care about this, because you'll either get it
right through whatever process you have, or you'll avoid it entirely
if you don't think your process is adequate.  Your choice.  Or not, if
the language decides you can't be responsible enough to make that
choice for yourself.

> That said, when I'm doing a code review, my focus is on all of the
> following things:
> 
> * Design: does this code make sense for what it's trying to accomplish?
> * Functionality: does the code work as intended?
> * Readability: can I understand it, and will others understand it later?
> * Complexity: could this code be simpler?
> * Tests: does the code include good tests?

These all seem fine, but if you're missing extremely well-known
pitfalls, then... I'll prefer a different code reviewer. :)  Maybe you
should consider adding that to your list.

> The existence of subtle bugs are just one of the things that I'm
> thinking about, so from my perspective, the more the compiler can help
> with this, the better.

I don't disagree with that, except that I don't consider this a subtle
bug, largely on account of its aforementioned status as well-known
pitfall.  But niether do I consider it damning, obviously.

> In C, if I miss a misplaced '=' then the code will do the wrong
> thing. 

Better yet, the compiler should warn you about it (which I believe it
does).  And you should be compiling with warnings. 

> In Python, I don't even have to worry about it, and I like it that
> way. 

If you're so concerned about making that mistake, YOU CAN CHOOSE TO
NOT USE THAT CONSTRUCT.  It doesn't need to be a decision forced on
you by the compiler.

As we've learned in this thread, there is a PEP for implementing this
feature which Guido apparently approves, so it can't be all that evil
after all, can it?

> So when you say that '=' as an expression should be supported
> because you think it's useful, and anyway those sorts of bugs will
> be caught by code reviews, the way that reads to me is:

Actually if you read all of what I wrote, you'll know that what I said
was assignment as an expression should be allowed, and if there were
to be a different operator to express that to avoid confusion, that
would be just fine with me.  But I don't think that need be a
condition.

> "'=' as an expression should be supported because it's convenient to
> me, and I don't believe I write bugs

Convenience is sort of Python's gig, isn't it?  "Make simple things
easy, make hard things possible."

> and if I do it doesn't matter because my time is important than that
> of the person who reviews my code."

Circumstantially, that may actually be true... or it may not.  Depends
on who you're working with, their roles and seniority, relative skill
and compensation, and probably  other factors.  Most groups have such
a heirarchy, even if it is largely implied rather than stated.
HOWEVER it hardly matters if the construct in question is accepted
practice.



From rosuav at gmail.com  Mon May 14 20:04:49 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 15 May 2018 10:04:49 +1000
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <20180514232013.GP12850@bladeshadow.org>
References: <7s86fd1bncg5hovboehvvqe57budhc2bf8@4ax.com>
 <20180513024213.GG12850@bladeshadow.org>
 <pd966b$unn$4@blaine.gmane.org>
 <CAPTjJmpp=wqgSQ0sWXsh6jnDDYTHtNkO1Ct1BGQqTe1iD8exqQ@mail.gmail.com>
 <20180514153819.GO12850@bladeshadow.org>
 <CALwzidk=0AMKd81GPrqACp8spoV62ia6b6afR+X16kM-r1zOKA@mail.gmail.com>
 <20180514232013.GP12850@bladeshadow.org>
Message-ID: <CAPTjJmrohDu6_Tp_vw_ZbFUvGY=ti1J0HrerpoaVrxubsfUjGQ@mail.gmail.com>

On Tue, May 15, 2018 at 9:20 AM, Python <python at bladeshadow.org> wrote:
> I'm well acquainted with that pheonomenon, though I daresay that if
> you proofread your own product you will often find your mistakes.  You
> just won't always.  But, I never said review it right after you wrote
> it, and in fact I don't do that (well, I do reread it if it seems
> something potentially concerning).  Rather I review it when I'm about
> to check it in, which for anything non-trivial is generally days
> later, after it's been tested (which implies the tests were written).
> I find my own bugs very often (but not nearly as often as I'd like).

Where does your code sit during those days? What happens if multiple
people make changes to the same files in parallel - do you deal with
merge conflicts all the time simply because you don't want to push
code in a timely manner?

ChrisA


From rshepard at appl-ecosys.com  Mon May 14 20:52:36 2018
From: rshepard at appl-ecosys.com (Rich Shepard)
Date: Mon, 14 May 2018 17:52:36 -0700 (PDT)
Subject: pylint/pyreverse with Python3
In-Reply-To: <79b6703e-571f-4767-b6aa-1fd3cf6dbf2f@googlegroups.com>
References: <alpine.LNX.2.20.1805130958220.6325@salmo.appl-ecosys.com>
 <pdar4k$g15$2@blaine.gmane.org>
 <mailman.21.1526263938.2761.python-list@python.org>
 <79b6703e-571f-4767-b6aa-1fd3cf6dbf2f@googlegroups.com>
Message-ID: <alpine.LNX.2.20.1805141747240.25598@salmo.appl-ecosys.com>

On Mon, 14 May 2018, summerrae78 at gmail.com wrote:

> I'm having the same issue; can you give an example command line for
> python2 and python3 specific installation?

Summerrae,

   All my development is now strictly Python3. The installation depends on
your OS and distribution. For a basic installation (ignoring dependendices
which you'll discover when you try to run it), type
 	python setup.py install or
 	python3 setup.py install
from within the directory with the egg, wheel, or source code.

HTH,

Rich


From steve+comp.lang.python at pearwood.info  Mon May 14 20:52:42 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Tue, 15 May 2018 00:52:42 +0000 (UTC)
Subject: seeking deeper (language theory) reason behind Python design
 choice
References: <7s86fd1bncg5hovboehvvqe57budhc2bf8@4ax.com>
 <20180513024213.GG12850@bladeshadow.org> <pd966b$unn$4@blaine.gmane.org>
 <CAPTjJmpp=wqgSQ0sWXsh6jnDDYTHtNkO1Ct1BGQqTe1iD8exqQ@mail.gmail.com>
 <20180514153819.GO12850@bladeshadow.org>
 <CALwzidk=0AMKd81GPrqACp8spoV62ia6b6afR+X16kM-r1zOKA@mail.gmail.com>
 <20180514232013.GP12850@bladeshadow.org>
Message-ID: <pddb0p$unn$10@blaine.gmane.org>

On Mon, 14 May 2018 18:20:13 -0500, Python wrote:

> I am hardly perfect.

Have you tried just wanting to be perfect more?


Look, we get it: it is possible to improve the quality of your code by 
paying attention to what you do, by proof-reading, testing, code reviews, 
warnings, linters, etc. We're not all doomed to be careless coders. I 
agree completely.

Also agree completely that assignment in expressions is sometimes useful.

Also agree that *with care and good management* it is possible to reduce 
the error rate from assignment-expressions to a manageable level -- even 
if assignment is spelled "=". Not to *zero*, but some non-zero manageable 
level.

But you miss the point that even if = versus == errors are picked up by 
code reviews or tests, they are still software bugs. Your *process* 
(testing and reviews) picked up the bug before they went into production, 
but *the bug still was made*.

A mere typo is not a bug if the compiler flags it before the code runs. 
It's just a typo.

So instead of congratulating yourself over how you never make the = 
versus == bug, you ought to be sheepishly realising how often you make 
it, but fortunately you have the processes in place to catch it before it 
reaches production.

Now remember that not every programmer works in large teams with pair 
programming, code reviews, test driven development, automatic buildbots 
to catch errors, etc.

Now remember that in 1991 when Guido made the decision to ban = as an 
expression, those concepts didn't even exist. There were no Python 
linters, and no reason to imagine that there ever would be. Guido didn't 
know that Python would become one of the top 10 most used languages. For 
all he knew, version 1.0 could be the final release.

By 1991 there had already been *decades* of experience with C proving 
that the "=" assignment syntax is dangerously confusable with == and a 
total bug magnet when allowed as expressions as well, so it was perfectly 
reasonable to ban it from the language.

There's nothing you can do with assignment expressions that can't be done 
*almost* as easily with assignment statements. Its often a matter of mere 
personal preference, do I want to write this as a single line or two?

And as the discussions over PEP 572 prove, the choice about allowing 
assignment expressions is *not easy*. Not only is there the matter of 
whether or not to allow it, but what spelling to use, and what scope the 
assignment should operate in.

And if you think that last one is the most trivial, in fact with list 
comprehensions and generator expressions, it will probably end up being 
the most controversial of all the questions.

And the most likely to sink the proposal.



-- 
Steve



From mahesh.tech88 at gmail.com  Mon May 14 21:56:14 2018
From: mahesh.tech88 at gmail.com (mahesh d)
Date: Tue, 15 May 2018 07:26:14 +0530
Subject: Extract
Message-ID: <CADzh5+dVU0Atywv62QcSYzptHJAVJQY+s7WbLW8fpGgiCT9V7A@mail.gmail.com>

Hii
 I have a directory. In that folder .msg files . How can I extract those
files.


Thanks & regards

Mahesh


From cs at cskk.id.au  Tue May 15 01:37:34 2018
From: cs at cskk.id.au (Cameron Simpson)
Date: Tue, 15 May 2018 15:37:34 +1000
Subject: Extract
In-Reply-To: <CADzh5+dVU0Atywv62QcSYzptHJAVJQY+s7WbLW8fpGgiCT9V7A@mail.gmail.com>
References: <CADzh5+dVU0Atywv62QcSYzptHJAVJQY+s7WbLW8fpGgiCT9V7A@mail.gmail.com>
Message-ID: <20180515053734.GA34017@cskk.homeip.net>

On 15May2018 07:26, mahesh d <mahesh.tech88 at gmail.com> wrote:
> I have a directory. In that folder .msg files . How can I extract those
>files.

You can get the filenames from the directory with the os.listdir function or 
with the glob.glob function. If you mean "extract the contents of those files" 
instread of just finding their names, you would need to know about the data 
format within those files, which you have not described.

See the Python docs here:

  https://docs.python.org/3/

and look up the "os" and "glob" modules for the functions mentioned above.

Cheers,
Cameron Simpson <cs at cskk.id.au>


From dieter at handshake.de  Tue May 15 01:39:55 2018
From: dieter at handshake.de (dieter)
Date: Tue, 15 May 2018 07:39:55 +0200
Subject: spurious BadDrawable error when running test_tk
References: <pdci1i$1cdv$1@gioia.aioe.org>
Message-ID: <87d0xx4gus.fsf@handshake.de>

Matthias Kievernagel <mkiever at Pirx.sirius.org> writes:
> I changed some detail in the tkinter library,
> so I'm running the tk test like this:
>
> ./python -m test -u gui -v test_tk
>
> Approximately every 2 or 3 runs I get a BadDrawable error
> from the X server, most of the time at the end after
> the last test finished successfully.
> As this also happens when I run the test on the unmodified CPython sources
> I suspect it is a shortcoming of my non-mainstream setup.
> I use ctwm with interactive window placement,
> so running the test involves a lot of clicks.
> Does anyone know if the errors are to be expected
> or should it work nonetheless?

Your error description suggests a race condition.

Like other (apparently) non deterministic error conditions,
they can be very hard to detect and diagnose. They may occur only
in very rare situations and in special contexts.

My feeling (!) is that "test_tk" has a flaw in the teardown of
the test setup which may in rare cases cause this race condition.
I would not be too worried about this.



From mahesh.tech88 at gmail.com  Tue May 15 02:23:47 2018
From: mahesh.tech88 at gmail.com (mahesh d)
Date: Tue, 15 May 2018 11:53:47 +0530
Subject: Extract data
Message-ID: <CADzh5+fo+54dpu_05kL_Fxb+AfJF9GJCRePaHMq5GnE+njogkg@mail.gmail.com>

Hii.

 I have folder.in that folder some files .txt and some files .msg files. .
My requirement is reading those file contents . Extract data in that files .


From steve+comp.lang.python at pearwood.info  Tue May 15 02:54:22 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Tue, 15 May 2018 06:54:22 +0000 (UTC)
Subject: Extract data
References: <CADzh5+fo+54dpu_05kL_Fxb+AfJF9GJCRePaHMq5GnE+njogkg@mail.gmail.com>
Message-ID: <pde06u$unn$11@blaine.gmane.org>

On Tue, 15 May 2018 11:53:47 +0530, mahesh d wrote:

> Hii.
> 
>  I have folder.in that folder some files .txt and some files .msg files.
>  .
> My requirement is reading those file contents . Extract data in that
> files .

The answer to this question is the same as the answer to your previous 
question "Extract" sent earlier.


Use the glob module, or the os.listdir function, to get a list of files 
matching the extension you want, then read each file.

Do you know how to open and read the contents of a file?

with open("filename.txt", "r"):
    data = f.read()


What you do with the data is then up to you.



-- 
Steve



From steve+comp.lang.python at pearwood.info  Tue May 15 03:02:50 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Tue, 15 May 2018 07:02:50 +0000 (UTC)
Subject: seeking deeper (language theory) reason behind Python design
 choice
References: <7s86fd1bncg5hovboehvvqe57budhc2bf8@4ax.com>
 <20180513024213.GG12850@bladeshadow.org> <pd966b$unn$4@blaine.gmane.org>
 <CAPTjJmpp=wqgSQ0sWXsh6jnDDYTHtNkO1Ct1BGQqTe1iD8exqQ@mail.gmail.com>
 <20180514153819.GO12850@bladeshadow.org>
 <CALwzidk=0AMKd81GPrqACp8spoV62ia6b6afR+X16kM-r1zOKA@mail.gmail.com>
 <20180514232013.GP12850@bladeshadow.org>
 <obdkfd1lko3albvp9j936c3pg9pldftj2d@4ax.com>
Message-ID: <pde0mq$unn$12@blaine.gmane.org>

On Mon, 14 May 2018 21:24:01 -0400, Dennis Lee Bieber wrote:


> 	The problem with adding the feature is that it will start to be
> used by
> newbies who lack the discipline to use it reliably: ensuring that
> comparisons are coded with constants (which for Python really means
> literals) on the left-hand side, so that a type of "=" for "==" will be
> flagged and not transparently pass.


Using = alone is absolutely not on the table.

The current two leading contenders, both controversial, are:

    name := expression

    name given name = expression


The second is being sponsored, backed, supported and subsidised by the 
Department of Repeated Redundancy and Repetitiveness.

(And before you ask, unfortunately "expression as name" has been ruled 
out because it is ambiguous with other uses of "as".


-- 
Steve



From vincent.vande.vyvre at telenet.be  Tue May 15 06:05:11 2018
From: vincent.vande.vyvre at telenet.be (Vincent Vande Vyvre)
Date: Tue, 15 May 2018 12:05:11 +0200
Subject: Uploading on PyPI fail
Message-ID: <b5b7dc6c-23b1-cf48-d26e-feca23714047@telenet.be>

Hi,

Trying to upgrade a package on PyPI, I get this error:

$ python3 setup.py register sdist upload
...
Submitting dist/py3exiv2-0.3.0.tar.gz to https://pypi.python.org/pypi
Upload failed (308): Redirect to Primary Domain
error: Upload failed (308): Redirect to Primary Domain

I know the site has changed but what is changed for me ?

This is the content of my .pypirc:
-----------------------------
[distutils]
index-servers=
 ??? pypi
 ??? pypitest

[pypitest]
repository = https://test.pypi.org/legacy/
username = VinsS
password = *******

[pypi]
repository = https://upload.pypi.org/legacy/
username = VinsS
password = ******
-----------------------------

Note: I've tested on test.pypi.org without problems.

Thanks for all advices,

Vincent

(send at Tue, 15 May 2018 12:04:10 +0200)



From sjeik_appie at hotmail.com  Tue May 15 06:39:57 2018
From: sjeik_appie at hotmail.com (Albert-Jan Roskam)
Date: Tue, 15 May 2018 10:39:57 +0000
Subject: Extract data
In-Reply-To: <pde06u$unn$11@blaine.gmane.org>
Message-ID: <AM0PR10MB1969C913D470D2900DCF0B1983930@AM0PR10MB1969.EURPRD10.PROD.OUTLOOK.COM>



On May 15, 2018 08:54, Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:

On Tue, 15 May 2018 11:53:47 +0530, mahesh d wrote:

> Hii.
>
>  I have folder.in that folder some files .txt and some files .msg files.
>  .
> My requirement is reading those file contents . Extract data in that
> files .

Reading .msg can be done with win32com or https://github.com/mattgwwalker/msg-extractor


From mahesh.tech88 at gmail.com  Tue May 15 08:12:52 2018
From: mahesh.tech88 at gmail.com (mahesh d)
Date: Tue, 15 May 2018 17:42:52 +0530
Subject: Extract data from multiple text files
Message-ID: <CADzh5+c2nt_FBRjEFb2-8rhsGqMyPjPKTt-uQ5-JMgi_Lhy5OA@mail.gmail.com>

import glob,os

import errno

path = 'C:/Users/A-7993\Desktop/task11/sample emails/'

files = glob.glob(path)

'''for name in files:

    print(str(name))

    if name.endswith(".txt"):

           print(name)'''

for file in os.listdir(path):

    print(file)

    if file.endswith(".txt"):

        print(os.path.join(path, file))

        print(file)

        try:

            with open(file) as f:

                msg = f.read()

                print(msg)

        except IOError as exc:

            if exc.errno != errno.EISDIR:

                raise


In the above program . Getting lot of errors . My intention is read the
list of the text files in a folder . Print them


 How can resolve those error


From mahesh.tech88 at gmail.com  Tue May 15 08:18:50 2018
From: mahesh.tech88 at gmail.com (mahesh d)
Date: Tue, 15 May 2018 17:48:50 +0530
Subject: Read data from .msg all files
Message-ID: <CADzh5+eYHnA1AHX0mWCbM66yi+g-K9oiEb_d1MwyUy8Au1ru9Q@mail.gmail.com>

import glob

import win32com.client



files = glob.glob('C:/Users/A-7993/Desktop/task11/sample emails/*.msg')

for file in files:

    print(file)

    with open(file) as f:

        msg=f.read()

        print(msg)

    outlook =
win32com.client.Dispatch("Outlook.Application").GetNamespace("MAPI")

    msg = outlook.OpenSharedItem(file)

    print("FROM:", str(msg.SenderName))

    print(msg.SenderEmailAddress)

    print(msg.SentOn)

    print(msg.To)

    print(msg.CC)

    print(msg.BCC)

    print(msg.Subject)

    print(msg.Body)


How can read all .msg files in a folder. I used outlook.openshared item it
only works one file . How can read the data from .msg files


From rhodri at kynesim.co.uk  Tue May 15 08:23:35 2018
From: rhodri at kynesim.co.uk (Rhodri James)
Date: Tue, 15 May 2018 13:23:35 +0100
Subject: Extract data from multiple text files
In-Reply-To: <CADzh5+c2nt_FBRjEFb2-8rhsGqMyPjPKTt-uQ5-JMgi_Lhy5OA@mail.gmail.com>
References: <CADzh5+c2nt_FBRjEFb2-8rhsGqMyPjPKTt-uQ5-JMgi_Lhy5OA@mail.gmail.com>
Message-ID: <a6811b0f-c3d1-bbad-c5a1-69e27e7fb895@kynesim.co.uk>

On 15/05/18 13:12, mahesh d wrote:
> import glob,os
> import errno
> 
> path = 'C:/Users/A-7993\Desktop/task11/sample emails/'
> files = glob.glob(path)
> 
> for file in os.listdir(path):
>      print(file)
>      if file.endswith(".txt"):
>          print(os.path.join(path, file))
>          print(file)
>          try:
>              with open(file) as f:
>                  msg = f.read()
>                  print(msg)
>          except IOError as exc:
>              if exc.errno != errno.EISDIR:
>                  raise
> 
> 
> In the above program . Getting lot of errors .

What errors?  Please cut and paste the traceback (don't retype it, and 
definitely don't send us screenshots; attachments aren't allowed on the 
mailing list).


-- 
Rhodri James *-* Kynesim Ltd


From vincent.vande.vyvre at telenet.be  Tue May 15 08:35:09 2018
From: vincent.vande.vyvre at telenet.be (Vincent Vande Vyvre)
Date: Tue, 15 May 2018 14:35:09 +0200
Subject: Uploading on PyPI fail (solved)
In-Reply-To: <b5b7dc6c-23b1-cf48-d26e-feca23714047@telenet.be>
References: <b5b7dc6c-23b1-cf48-d26e-feca23714047@telenet.be>
Message-ID: <6d1b595d-7743-ae87-3687-66748606f5f9@telenet.be>

Le 15/05/18 ? 12:05, Vincent Vande Vyvre a ?crit?:
> Hi,
>
> Trying to upgrade a package on PyPI, I get this error:
>
> $ python3 setup.py register sdist upload
> ...
> Submitting dist/py3exiv2-0.3.0.tar.gz to https://pypi.python.org/pypi
> Upload failed (308): Redirect to Primary Domain
> error: Upload failed (308): Redirect to Primary Domain
>
> I know the site has changed but what is changed for me ?
>
> This is the content of my .pypirc:
> -----------------------------
> [distutils]
> index-servers=
> ??? pypi
> ??? pypitest
>
> [pypitest]
> repository = https://test.pypi.org/legacy/
> username = VinsS
> password = *******
>
> [pypi]
> repository = https://upload.pypi.org/legacy/
> username = VinsS
> password = ******
> -----------------------------
>
> Note: I've tested on test.pypi.org without problems.
>
> Thanks for all advices,
>
> Vincent
>
> (send at Tue, 15 May 2018 12:04:10 +0200)
>
Solved with $ twine upload? dist/*


...

Vincent

(send at Tue, 15 May 2018 14:34:10 +0200)




From sjeik_appie at hotmail.com  Tue May 15 08:46:16 2018
From: sjeik_appie at hotmail.com (Albert-Jan Roskam)
Date: Tue, 15 May 2018 12:46:16 +0000
Subject: Extract data from multiple text files
In-Reply-To: <CADzh5+c2nt_FBRjEFb2-8rhsGqMyPjPKTt-uQ5-JMgi_Lhy5OA@mail.gmail.com>
Message-ID: <AM0PR10MB1969CEEA778CC37220BC813383930@AM0PR10MB1969.EURPRD10.PROD.OUTLOOK.COM>



On May 15, 2018 14:12, mahesh d <mahesh.tech88 at gmail.com> wrote:

import glob,os

import errno

path = 'C:/Users/A-7993\Desktop/task11/sample emails/'

files = glob.glob(path)

'''for name in files:

    print(str(name))

    if name.endswith(".txt"):

           print(name)'''

for file in os.listdir(path):

    print(file)

    if file.endswith(".txt"):

        print(os.path.join(path, file))

        print(file)

        try:

            with open(file) as f:

                msg = f.read()

                print(msg)

        except IOError as exc:

            if exc.errno != errno.EISDIR:

                raise


In the above program . Getting lot of errors . My intention is read the
list of the text files in a folder . Print them


How can resolve those error
--
https://mail.python.org/mailman/listinfo/python-list

Try:
path = 'C:/Users/A-7993/Desktop/task11/sample emails/*.msg'
msg_files = glob.glob(path)
print(msg_files)

From matt.ruffalo at gmail.com  Tue May 15 08:53:48 2018
From: matt.ruffalo at gmail.com (Matt Ruffalo)
Date: Tue, 15 May 2018 08:53:48 -0400
Subject: Pandas cat.categories.isin list, is this a bug?
In-Reply-To: <CAF+o+SFLiEmsnG-Q1L5GkV8UWtR6BEG5B+KzpZCky8XubJnEGQ@mail.gmail.com>
References: <9fb404de-0ff5-4ad5-86fe-16e02ac9a257@googlegroups.com>
 <872d0323-13ec-31b9-1dc9-406125c25593@gmail.com>
 <CAF+o+SFLiEmsnG-Q1L5GkV8UWtR6BEG5B+KzpZCky8XubJnEGQ@mail.gmail.com>
Message-ID: <8fe451dc-3475-46e6-beac-d2efff542e79@gmail.com>

On 2018-05-15 06:23, Zoran Ljubi?i? wrote:
> Matt,
>
> thanks for the info about pydata mailing group. I didn't know it exists.
> Because comp.lang.python is not appropriate group for this question, I
> will continue our conversation on gmail.
>
> I have put len(df.CRM_assetID.cat
> <http://df.CRM_assetID.cat>.categories.isin(['V1254748', 'V805722',
> 'V1105400']))? = 55418 in next message, after I noticed that this
> information is missing.
>
> If I want to select all rows that have categories from the list, how
> to do that?
>
> Regards,
>
> Zoran
>

Hi Zoran-

(Including python-list again, for lack of a reason not to. This
conversation is still relevant and appropriate for the general Python
mailing list -- I just meant that the pydata list likely has many more
Pandas users/experts, so you're more likely to get a better answer,
faster, from a more specialized group.)

Selecting all rows that have categories is a bit simpler than what you
are doing -- your issue is that you are working with the *set of
distinct categories*, and not the actual vector of categories
corresponding to your data.

You can select items you're interested in with something like the following:

"""
In [1]: import pandas as pd

In [2]: s = pd.Series(['apple', 'banana', 'apple', 'pear', 'banana',
'cherry', 'pear', 'cherry']).astype('category')

In [3]: s
Out[3]:
0???? apple
1??? banana
2???? apple
3????? pear
4??? banana
5??? cherry
6????? pear
7??? cherry
dtype: category
Categories (4, object): [apple, banana, cherry, pear]

In [4]: s.isin({'apple', 'pear'})
Out[4]:
0???? True
1??? False
2???? True
3???? True
4??? False
5??? False
6???? True
7??? False
dtype: bool

In [5]: s.loc[s.isin({'apple', 'pear'})]
Out[5]:
0??? apple
2??? apple
3???? pear
6???? pear
dtype: category
Categories (4, object): [apple, banana, cherry, pear]
"""

(Note that I'm also passing a set to `isin` instead of a list -- this
doesn't matter when looking for two or three values, but if you're
passing 1000 values to `isin`, or 10_000, or 1_000_000, then linear-time
membership testing can start to become an issue.)

You are accessing the vector of the *unique categories* in that column, like

"""
In [6]: s.cat.categories
Out[6]: Index(['apple', 'banana', 'cherry', 'pear'], dtype='object')

In [7]: s.cat.categories.isin({'apple', 'pear'})
Out[7]: array([ True, False, False,? True])
"""

The vector `s.cat.categories` has one element for each distinct category
in your column, and your column apparently contains 55418 different
categories.

MMR...


From mike.junk.46 at att.net  Tue May 15 10:29:39 2018
From: mike.junk.46 at att.net (Mike McClain)
Date: Tue, 15 May 2018 07:29:39 -0700
Subject: object types, mutable or not?
In-Reply-To: <53e09f9b-0da4-0ae0-3aff-b23029427474@Damon-Family.org>
References: <mailman.27.1526227203.13745.python-list@python.org>
 <20180513200201.GA26725@playground>
 <53e09f9b-0da4-0ae0-3aff-b23029427474@Damon-Family.org>
Message-ID: <20180515142939.GA5181@playground>

On Sun, May 13, 2018 at 07:10:11PM -0400, Richard Damon wrote:
> On 5/13/18 4:02 PM, Mike McClain wrote:
> > I'm new to Python and OOP.
> > Python  en 2.7.14 Documentation  The Python Language Reference
> > 3. Data model
> > 3.1. Objects, values and types
> > An object's type is also unchangeable. [1]
> > [1]     It is possible in some cases to change an object's type,
> >     under certain controlled conditions.
> >
> > It appears to me as if an object's type is totally mutable and
> > solely dependant on assignment.
> >
> >>>> obj = 'a1b2'
> >>>> obj
> > 'a1b2'
<snip>
> > At what level does my understanding break down?
<snip>

> The first this is obj is NOT 'the object', but is instead a reference
> that 'points' to an object.

Many thanks to those teachers who responded.

I think I got it.
The variable is not the object just as the name is not the thing.

I had gotten the impression that everything in OOP is an object but
you're all saying that variables are not objects.

Does a variable have a type?
If so what is the type of a variable and how is that demonstrated
if 'type()' reports what the variable points to?

Thanks,
Mike
--
Men occasionally stumble over the truth, but most of them pick
themselves up and hurry off as if nothing ever happened.
    - Churchill


From grant.b.edwards at gmail.com  Tue May 15 10:45:39 2018
From: grant.b.edwards at gmail.com (Grant Edwards)
Date: Tue, 15 May 2018 14:45:39 +0000 (UTC)
Subject: Read data from .msg all files
References: <CADzh5+eYHnA1AHX0mWCbM66yi+g-K9oiEb_d1MwyUy8Au1ru9Q@mail.gmail.com>
Message-ID: <pderqj$h4v$1@blaine.gmane.org>

On 2018-05-15, mahesh d <mahesh.tech88 at gmail.com> wrote:

> import glob

_Please_ stop creating new threads for this question.  I think this is
the fifth thread you've started for what appears to be a single
question.

-- 
Grant Edwards               grant.b.edwards        Yow! Like I always say
                                  at               -- nothing can beat
                              gmail.com            the BRATWURST here in
                                                   DUSSELDORF!!



From skip.montanaro at gmail.com  Tue May 15 11:14:12 2018
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Tue, 15 May 2018 10:14:12 -0500
Subject: What's the rationale for b"..." in this example?
Message-ID: <CANc-5UzinpCUcEoxd668N9vnD5cqtCtAwTemWGnnuJ7ucD2-PQ@mail.gmail.com>

Consider this:

>>> bytes("abc", encoding="utf-8")
b'abc'

Looks reasonable. Then consider this:

>>> str(bytes("abc", encoding="utf-8"))
"b'abc'"

Why is the b'...' bit still there? I suppose it's because I didn't tell it
explicitly how to decode the bytes object, as when I do, I get the expected
result:

>>> str(bytes("abc", encoding="utf-8"), encoding="utf-8")
'abc'

Coming from a still largely Python 2 perspective, did all attempts to apply
default encodings disappear in Python 3?

Skip


From rhodri at kynesim.co.uk  Tue May 15 12:10:21 2018
From: rhodri at kynesim.co.uk (Rhodri James)
Date: Tue, 15 May 2018 17:10:21 +0100
Subject: object types, mutable or not?
In-Reply-To: <20180515142939.GA5181@playground>
References: <mailman.27.1526227203.13745.python-list@python.org>
 <20180513200201.GA26725@playground>
 <53e09f9b-0da4-0ae0-3aff-b23029427474@Damon-Family.org>
 <20180515142939.GA5181@playground>
Message-ID: <393389a4-66c1-d44b-5b4c-d3621d96c5c3@kynesim.co.uk>

On 15/05/18 15:29, Mike McClain wrote:
> On Sun, May 13, 2018 at 07:10:11PM -0400, Richard Damon wrote:
>> On 5/13/18 4:02 PM, Mike McClain wrote:
>>> I'm new to Python and OOP.
>>> Python  en 2.7.14 Documentation  The Python Language Reference
>>> 3. Data model
>>> 3.1. Objects, values and types
>>> An object's type is also unchangeable. [1]
>>> [1]     It is possible in some cases to change an object's type,
>>>      under certain controlled conditions.
>>>
>>> It appears to me as if an object's type is totally mutable and
>>> solely dependant on assignment.
>>>
>>>>>> obj = 'a1b2'
>>>>>> obj
>>> 'a1b2'
> <snip>
>>> At what level does my understanding break down?
> <snip>
> 
>> The first this is obj is NOT 'the object', but is instead a reference
>> that 'points' to an object.
> 
> Many thanks to those teachers who responded.
> 
> I think I got it.
> The variable is not the object just as the name is not the thing.
> 
> I had gotten the impression that everything in OOP is an object but
> you're all saying that variables are not objects.
> 
> Does a variable have a type?
> If so what is the type of a variable and how is that demonstrated
> if 'type()' reports what the variable points to?

Variables don't have types, or indeed anything much.  They are just 
names, that's all.  Every time you use the name, you get the object the 
name references (or "is bound to" as some people prefer to phrase it).

-- 
Rhodri James *-* Kynesim Ltd


From ethan at stoneleaf.us  Tue May 15 12:27:39 2018
From: ethan at stoneleaf.us (Ethan Furman)
Date: Tue, 15 May 2018 09:27:39 -0700
Subject: What's the rationale for b"..." in this example?
In-Reply-To: <CANc-5UzinpCUcEoxd668N9vnD5cqtCtAwTemWGnnuJ7ucD2-PQ@mail.gmail.com>
References: <CANc-5UzinpCUcEoxd668N9vnD5cqtCtAwTemWGnnuJ7ucD2-PQ@mail.gmail.com>
Message-ID: <5AFB0A7B.6030205@stoneleaf.us>

On 05/15/2018 08:14 AM, Skip Montanaro wrote:
> Consider this:
>
>>>> bytes("abc", encoding="utf-8")
> b'abc'
>
> Looks reasonable. Then consider this:
>
>>>> str(bytes("abc", encoding="utf-8"))
> "b'abc'"
>
> Why is the b'...' bit still there?

Because you are printing a bytes object, not a str.

> I suppose it's because I didn't tell it
> explicitly how to decode the bytes object, as when I do, I get the expected
> result:
>
>>>> str(bytes("abc", encoding="utf-8"), encoding="utf-8")
> 'abc'
>
> Coming from a still largely Python 2 perspective, did all attempts to apply
> default encodings disappear in Python 3?

Pretty much, yup.  There is no more guessing what encoding to use -- either specify it, or be made aware that you 
printed a bytes object.

--
~Ethan~


From travisgriggs at gmail.com  Tue May 15 12:37:30 2018
From: travisgriggs at gmail.com (Travis Griggs)
Date: Tue, 15 May 2018 09:37:30 -0700
Subject: Simplest way to clobber/replace one populated directory with another?
Message-ID: <85ECD342-8D31-4B60-BE06-49AA16278500@gmail.com>

I have a directory structure that might look something like:

    Data
        Current
            A
            B 
            C 
        Previous
            A 
            X

In as simple/quick a step as possible, I want to rename Current as Previous including the contents and wiping out the original such that it is now:

    Data
        Previous
            A
            B
            C

I've tried something like:

    from pathlib import Path
    src = Path('Data/Current?)
    dest = Path('Data/Previous?)
    src.replace(dest)

The docs led me to hope this would work:

    "If target points to an existing file or directory, it will be unconditionally replaced.?

But it *does* appear to be conditional. I get a "Directory not empty" exception. I guess I could recursively delete the ?Previous' directory first. Is that basically the only solution? Or is there a better way to achieve this?

(I prefer `pathlib`, but if `os` or `shutil` is the better hammer here, I'm not opposed to them)

(I am running on Linux)

From python at bladeshadow.org  Tue May 15 12:48:49 2018
From: python at bladeshadow.org (Python)
Date: Tue, 15 May 2018 11:48:49 -0500
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <pddb0p$unn$10@blaine.gmane.org>
References: <7s86fd1bncg5hovboehvvqe57budhc2bf8@4ax.com>
 <20180513024213.GG12850@bladeshadow.org>
 <pd966b$unn$4@blaine.gmane.org>
 <CAPTjJmpp=wqgSQ0sWXsh6jnDDYTHtNkO1Ct1BGQqTe1iD8exqQ@mail.gmail.com>
 <20180514153819.GO12850@bladeshadow.org>
 <CALwzidk=0AMKd81GPrqACp8spoV62ia6b6afR+X16kM-r1zOKA@mail.gmail.com>
 <20180514232013.GP12850@bladeshadow.org>
 <pddb0p$unn$10@blaine.gmane.org>
Message-ID: <20180515164849.GQ12850@bladeshadow.org>

On Tue, May 15, 2018 at 12:52:42AM +0000, Steven D'Aprano wrote:
> But you miss the point that even if = versus == errors are picked up by 
> code reviews or tests, they are still software bugs. Your *process* 
> (testing and reviews) picked up the bug before they went into production, 
> but *the bug still was made*.

I do not miss this point.  My premise from the beginning was that
humans make mistakes, this bug will occur, and most importantly it's
no worse than any other bug.  Wrong code is wrong code.  YOU'RE GOING
TO SCREW UP, and you need *SOMETHING* in place to catch that.  It may
as well also catch this, and it's NOT that hard to do... If you had no
other tools, you could write a regex to scan your code for it and
review the matches.  If you never discovered that this was a
well-known pitfall that's one thing, but I've known about it since
approximately 1986--it's been around a long time as you yourself say,
so there's no excuse for someone now, 30+ years later, not knowing
about it and watching out for it... unless they simply don't care
about writing working code and so put no effort into learning about
such things.

The noob argument only reinforces my point--they're going to screw up
all manner of things, until they learn not to...  The noob argument is
only a worse example of the same reason why we have software
development process (and mentors).  If you're in the unfortunate
position you described, where you don't have peer review, then you
need to employ good proccess EVEN MORE, because you have only yourself
to rely on.  If you don't employ it, it's pretty much a guanrantee
that your software quality will be sub par, unless you are a true
superstar.  [They exist, I've come to know a small handful.
Unfortunately I am not one of them.]

Seperately, I asserted that you can, if you really want to, learn to
not make this mistake, BUT IT'S NOT RELEVANT TO MY POINT.  In life we
learn to stop making all manner of mistakes, and reduce the frequency
of others.  In nearly half a century of life, I've NEVER made the
mistake of putting my hand on a hot stove burner, because I've learned
that it's dangerous, and take extra care around hot stove burners.  To
me this bug is exactly the same.  Likewise I'm POSITIVE there are
types of mistakes that YOU never make, though this bug may not be one
of them.  I'm certain it can be one that you learn to not make, if you
exert the required effort, whatever it may be *for you*.  But I must
admit that neither of us can conclusively prove the other wrong, and
you will likely believe whatever you've convinced yourself of already,
just as I do, and that's fine.  



From python at mrabarnett.plus.com  Tue May 15 13:18:49 2018
From: python at mrabarnett.plus.com (MRAB)
Date: Tue, 15 May 2018 18:18:49 +0100
Subject: Extract data from multiple text files
In-Reply-To: <CADzh5+c2nt_FBRjEFb2-8rhsGqMyPjPKTt-uQ5-JMgi_Lhy5OA@mail.gmail.com>
References: <CADzh5+c2nt_FBRjEFb2-8rhsGqMyPjPKTt-uQ5-JMgi_Lhy5OA@mail.gmail.com>
Message-ID: <8fac4853-1e27-e595-5357-d0ed28ff1a77@mrabarnett.plus.com>

On 2018-05-15 13:12, mahesh d wrote:
> import glob,os
> 
> import errno
> 
> path = 'C:/Users/A-7993\Desktop/task11/sample emails/'
> 
> files = glob.glob(path)
> 
> '''for name in files:
> 
>      print(str(name))
> 
>      if name.endswith(".txt"):
> 
>             print(name)'''
> 
> for file in os.listdir(path):
> 
>      print(file)
> 
>      if file.endswith(".txt"):
> 
>          print(os.path.join(path, file))
> 
>          print(file)
> 
>          try:
> 
>              with open(file) as f:
> 
>                  msg = f.read()
> 
>                  print(msg)
> 
>          except IOError as exc:
> 
>              if exc.errno != errno.EISDIR:
> 
>                  raise
> 
> 
> In the above program . Getting lot of errors . My intention is read the
> list of the text files in a folder . Print them
> 
> 
>   How can resolve those error
> 
You don't say what the errors are, but I'm guessing that it's 
complaining that it can't find the file with trying to open it.

'open' needs the _full path_ to the file, but 'os.listdir' returns only 
the _name_ of the files and directories, not the full path.


From ben+python at benfinney.id.au  Tue May 15 13:22:18 2018
From: ben+python at benfinney.id.au (Ben Finney)
Date: Wed, 16 May 2018 03:22:18 +1000
Subject: object types, mutable or not?
References: <mailman.27.1526227203.13745.python-list@python.org>
 <20180513200201.GA26725@playground>
 <53e09f9b-0da4-0ae0-3aff-b23029427474@Damon-Family.org>
 <20180515142939.GA5181@playground>
Message-ID: <85bmdgn8ad.fsf@benfinney.id.au>

Mike McClain <mike.junk.46 at att.net> writes:

> Many thanks to those teachers who responded.

Thank you for asking the question in a way that allows the discussion
:-)

> I think I got it.
> The variable is not the object just as the name is not the thing.

Yes. The term ?variable? is so overloaded, for people new to Python,
that I prefer to avoid it altogether. I discuss Python's assignment
behaviour in terms of binding and references.

> I had gotten the impression that everything in OOP is an object

That is definitely not true. There are many languages that support OOP
where *not* everything is an object.

See <URL:https://en.wikipedia.org/wiki/Object-oriented_programming#OOP_languages.

> but you're all saying that variables are not objects.

Yes. In the ?everything is an object? adage, it's important to realise
what ontology is being used ? what ?things? exist.

It would be more accurate to say ?every value is an object?, but that
gets into how ?value? has technical meanings and is IMO less helpful
than ?everything is an object?.

A different formulation to make it more accurate would be ?everything
that can be addressed by an expression is an object?. Not as catchy, and
I don't expect to see it used as often :-)

The point being, there are many things *we* can talk about which don't
?exist? as things in the context of that adage. Numbers, file handles,
data structures all are ?things? and therefore are objects in Python.

Variables, sequence indexes, memory locations, names, statements are
concepts with meaning when *talking about* Python, but are not ?things?
that have a value in a Python expression. Because they are not ?things?
in Python, those are not objects in Python.

The adage is intended (IIUC) to contrast with languages other than
Python that *do* support OOP, but where *not* everything is an object.
Examples include Java, PHP, Pascal.

> Does a variable have a type?

No, because in Python, ?variable? refers to the *binding* between a
reference and an object. In that binding, only the object has a type,
and its type is totally unaffected by whatever references are bound to
that object.

> If so what is the type of a variable and how is that demonstrated
> if 'type()' reports what the variable points to?

This is an illustration of why I don't find ?variable? a helpful term
for discussing Python behaviour.

Instead, an expression like ?type(foo)? is better understood as getting
the type of object that the name ?foo? references.

It doesn't make sense to ask ?what is the type of foo? if you're
thinking of ?foo? the name. The type is not a property of the name and
not a property of the name?object binding (the ?variable?). The type is
a property of the object.

-- 
 \         ?It is the fundamental duty of the citizen to resist and to |
  `\          restrain the violence of the state.? ?Noam Chomsky, 1971 |
_o__)                                                                  |
Ben Finney



From ben+python at benfinney.id.au  Tue May 15 13:28:18 2018
From: ben+python at benfinney.id.au (Ben Finney)
Date: Wed, 16 May 2018 03:28:18 +1000
Subject: What's the rationale for b"..." in this example?
References: <CANc-5UzinpCUcEoxd668N9vnD5cqtCtAwTemWGnnuJ7ucD2-PQ@mail.gmail.com>
Message-ID: <857eo4n80d.fsf@benfinney.id.au>

Skip Montanaro <skip.montanaro at gmail.com> writes:

> Consider this:
>
> >>> bytes("abc", encoding="utf-8")
> b'abc'
>
> Looks reasonable. Then consider this:
>
> >>> str(bytes("abc", encoding="utf-8"))
> "b'abc'"
>
> Why is the b'...' bit still there?

Because the bytes object is asked for a text representation of itself,
and the text value ?b'abc'? is what it returned.

> I suppose it's because I didn't tell it explicitly how to decode the
> bytes object, as when I do, I get the expected result:
>
> >>> str(bytes("abc", encoding="utf-8"), encoding="utf-8")
> 'abc'

Yes.

> Coming from a still largely Python 2 perspective, did all attempts to
> apply default encodings disappear in Python 3?

To the extent I understand that question, the answer is no.

Rather, the ?bytes? and ?str? types are now entirely incompatible, and
implicit conversions are never done between them. Any conversions
between them must be explicit.

-- 
 \            ?There are always those who think they know what is your |
  `\          responsibility better than you do.? ?Ralph Waldo Emerson |
_o__)                                                                  |
Ben Finney



From storchaka at gmail.com  Tue May 15 13:38:09 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Tue, 15 May 2018 20:38:09 +0300
Subject: What's the rationale for b"..." in this example?
In-Reply-To: <CANc-5UzinpCUcEoxd668N9vnD5cqtCtAwTemWGnnuJ7ucD2-PQ@mail.gmail.com>
References: <CANc-5UzinpCUcEoxd668N9vnD5cqtCtAwTemWGnnuJ7ucD2-PQ@mail.gmail.com>
Message-ID: <pdf5pt$g3f$1@blaine.gmane.org>

15.05.18 18:14, Skip Montanaro ????:
> Consider this:
> 
>>>> bytes("abc", encoding="utf-8")
> b'abc'
> 
> Looks reasonable. Then consider this:
> 
>>>> str(bytes("abc", encoding="utf-8"))
> "b'abc'"
> 
> Why is the b'...' bit still there? I suppose it's because I didn't tell it
> explicitly how to decode the bytes object, as when I do, I get the expected
> result:
> 
>>>> str(bytes("abc", encoding="utf-8"), encoding="utf-8")
> 'abc'

str() without 'encoding' and 'errors' calls __str__ which falls back to 
__repr__ by default.

bytes.__str__ falls back to bytes.__repr__, this makes errors of mixing 
bytes and strings more obvious. If run Python with the -b option, it 
will emit a BytesWarning first. If run it with -bb, it will become an error.

You can receive many interesting warning when run Python 2 with options 
-b and -3. Getting rid of these warnings will help with porting to 
Python 3 and may fix real bugs.



From rosuav at gmail.com  Tue May 15 13:41:21 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 16 May 2018 03:41:21 +1000
Subject: What's the rationale for b"..." in this example?
In-Reply-To: <CANc-5UzinpCUcEoxd668N9vnD5cqtCtAwTemWGnnuJ7ucD2-PQ@mail.gmail.com>
References: <CANc-5UzinpCUcEoxd668N9vnD5cqtCtAwTemWGnnuJ7ucD2-PQ@mail.gmail.com>
Message-ID: <CAPTjJmqmpOWTxjrLF4GZ2qtyOmZgynavR5R8=puanaVxwzVi=g@mail.gmail.com>

On Wed, May 16, 2018 at 1:14 AM, Skip Montanaro
<skip.montanaro at gmail.com> wrote:
> Consider this:
>
>>>> bytes("abc", encoding="utf-8")
> b'abc'
>
> Looks reasonable. Then consider this:
>
>>>> str(bytes("abc", encoding="utf-8"))
> "b'abc'"
>
> Why is the b'...' bit still there? I suppose it's because I didn't tell it
> explicitly how to decode the bytes object, as when I do, I get the expected
> result:
>
>>>> str(bytes("abc", encoding="utf-8"), encoding="utf-8")
> 'abc'
>
> Coming from a still largely Python 2 perspective, did all attempts to apply
> default encodings disappear in Python 3?

It's there for the same reason as the square brackets here:

>>> str(list('abc'))
"['a', 'b', 'c']"

Calling str() on arbitrary objects returns a printable string; and in
Py3, there's simply nothing special about bytes. Personally, I never
use the str(..., encoding="...") notation; I prefer to use the
.decode() method of the bytes object.

ChrisA


From toby at tobiah.org  Tue May 15 15:10:07 2018
From: toby at tobiah.org (Tobiah)
Date: Tue, 15 May 2018 12:10:07 -0700
Subject: syntax oddities
Message-ID: <pdfbad$5sq$1@gioia.aioe.org>

Why is it len(object) instead of object.len?

Why is it getattr(object, item) rather then object.getattr(item)?

etc...


Thanks


From storchaka at gmail.com  Tue May 15 15:34:09 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Tue, 15 May 2018 22:34:09 +0300
Subject: syntax oddities
In-Reply-To: <pdfbad$5sq$1@gioia.aioe.org>
References: <pdfbad$5sq$1@gioia.aioe.org>
Message-ID: <pdfcjf$8hv$1@blaine.gmane.org>

15.05.18 22:10, Tobiah ????:
> Why is it len(object) instead of object.len?

Because the first form looked better to Guido van Rossum.

> Why is it getattr(object, item) rather then object.getattr(item)?

How do you get the 'getattr' attribute then?



From hjp-python at hjp.at  Tue May 15 16:21:15 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Tue, 15 May 2018 22:21:15 +0200
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <pddb0p$unn$10@blaine.gmane.org>
References: <7s86fd1bncg5hovboehvvqe57budhc2bf8@4ax.com>
 <20180513024213.GG12850@bladeshadow.org>
 <pd966b$unn$4@blaine.gmane.org>
 <CAPTjJmpp=wqgSQ0sWXsh6jnDDYTHtNkO1Ct1BGQqTe1iD8exqQ@mail.gmail.com>
 <20180514153819.GO12850@bladeshadow.org>
 <CALwzidk=0AMKd81GPrqACp8spoV62ia6b6afR+X16kM-r1zOKA@mail.gmail.com>
 <20180514232013.GP12850@bladeshadow.org>
 <pddb0p$unn$10@blaine.gmane.org>
Message-ID: <20180515202115.3pioqxhhdm6xnlr3@hjp.at>

On 2018-05-15 00:52:42 +0000, Steven D'Aprano wrote:
> Now remember that in 1991 when Guido made the decision to ban = as an 
> expression, those concepts didn't even exist. There were no Python 
> linters, and no reason to imagine that there ever would be. Guido didn't 
> know that Python would become one of the top 10 most used languages. For 
> all he knew, version 1.0 could be the final release.
> 
> By 1991 there had already been *decades* of experience with C

About one and a half decades.

> proving that the "=" assignment syntax is dangerously confusable with
> == and a total bug magnet when allowed as expressions as well, so it
> was perfectly reasonable to ban it from the language.

Experience? Yes. Data? I doubt it.

I will readily admit that my knowledge of research into the usability
of programming languages is more than spotty, but I have read a few
papers about the topic over the last decade. I don't recall any which
quantified "bug magnets" under realistic conditions (two hour toy
problems for first-year students don't count). I thought there was one
by Google, but that was about compile-time errors.

Language design ist still mostly an art driven by gut feeling, not
engineering driven by data. I doubt that this was better in 1991.

I have been programming in C since the mid-80's and in Perl since the
mid-90's (both languages allow assignment expressions). I accumulated my
fair share of bugs in that time, but AFAIR I made this particular error
very rarely (I cannot confidently claim that I never made it). Clearly
it is not ?a total bug magnet? in my experience. There are much bigger
problems in C and Perl (and Python, too). But of course my experience is
just that of a single programmer (or a handful if I include people
whose code I've reviewed or debugged) and in any case just anecdotal.
(Could I quantify even my own experience? I guess I could write a script
which searches through all my repositories for changesets where ?=? was
replaced by ?==?. Not sure what that would prove.)

OTOH, despite having used C and Perl long before Python, I don't miss
assignment expressions. Every language has its idioms, and just because
you write stuff like ?if ((fd = open(...)) == -1)? a lot in C doesn't
mean you have to be able to write that in Python.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180515/11b2b73c/attachment.sig>

From ian.g.kelly at gmail.com  Tue May 15 16:27:09 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Tue, 15 May 2018 14:27:09 -0600
Subject: syntax oddities
In-Reply-To: <pdfbad$5sq$1@gioia.aioe.org>
References: <pdfbad$5sq$1@gioia.aioe.org>
Message-ID: <CALwzidmvG4ij=Y1g5QZW8AkUzZmdS4t8zs_6=XP4Vzb3=WunGQ@mail.gmail.com>

On Tue, May 15, 2018 at 1:10 PM, Tobiah <toby at tobiah.org> wrote:
> Why is it len(object) instead of object.len?
>
> Why is it getattr(object, item) rather then object.getattr(item)?

http://effbot.org/pyfaq/why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list.htm


From skip.montanaro at gmail.com  Tue May 15 19:02:10 2018
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Tue, 15 May 2018 18:02:10 -0500
Subject: What's the rationale for b"..." in this example?
In-Reply-To: <CAPTjJmqmpOWTxjrLF4GZ2qtyOmZgynavR5R8=puanaVxwzVi=g@mail.gmail.com>
References: <CANc-5UzinpCUcEoxd668N9vnD5cqtCtAwTemWGnnuJ7ucD2-PQ@mail.gmail.com>
 <CAPTjJmqmpOWTxjrLF4GZ2qtyOmZgynavR5R8=puanaVxwzVi=g@mail.gmail.com>
Message-ID: <CANc-5UyqeGb5RX2QSi=0_Lpmg-PThXQi51aQKHPAMRKXbfREzA@mail.gmail.com>

> Personally, I never use the str(..., encoding="...") notation; I prefer
to use the
> .decode() method of the bytes object.

Thanks. And thanks for the other responses. I obviously didn't have my
thinking cap on this morning. (It was too late in the morning to plead lack
of coffee.)

Skip


From rosuav at gmail.com  Tue May 15 19:34:23 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 16 May 2018 09:34:23 +1000
Subject: What's the rationale for b"..." in this example?
In-Reply-To: <CANc-5UyqeGb5RX2QSi=0_Lpmg-PThXQi51aQKHPAMRKXbfREzA@mail.gmail.com>
References: <CANc-5UzinpCUcEoxd668N9vnD5cqtCtAwTemWGnnuJ7ucD2-PQ@mail.gmail.com>
 <CAPTjJmqmpOWTxjrLF4GZ2qtyOmZgynavR5R8=puanaVxwzVi=g@mail.gmail.com>
 <CANc-5UyqeGb5RX2QSi=0_Lpmg-PThXQi51aQKHPAMRKXbfREzA@mail.gmail.com>
Message-ID: <CAPTjJmr8a5_FeCgGEEQWvWiubA-0Q3cYP1xSQvv-VS1+Uvmcew@mail.gmail.com>

On Wed, May 16, 2018 at 9:02 AM, Skip Montanaro
<skip.montanaro at gmail.com> wrote:
>> Personally, I never use the str(..., encoding="...") notation; I prefer
> to use the
>> .decode() method of the bytes object.
>
> Thanks. And thanks for the other responses. I obviously didn't have my
> thinking cap on this morning. (It was too late in the morning to plead lack
> of coffee.)

You plead lack of coffee until you plead caffeine overdose. That's the
way of things. :)

ChrisA


From steve+comp.lang.python at pearwood.info  Tue May 15 19:48:18 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Tue, 15 May 2018 23:48:18 +0000 (UTC)
Subject: object types, mutable or not?
References: <mailman.27.1526227203.13745.python-list@python.org>
 <20180513200201.GA26725@playground>
 <53e09f9b-0da4-0ae0-3aff-b23029427474@Damon-Family.org>
 <20180515142939.GA5181@playground>
Message-ID: <pdfrk2$unn$13@blaine.gmane.org>

On Tue, 15 May 2018 07:29:39 -0700, Mike McClain wrote:

> I had gotten the impression that everything in OOP is an object but
> you're all saying that variables are not objects.

Perhaps it is better to say every VALUE in Python is an object.

Keywords aren't values. Operators aren't values. Comments aren't values. 
Expressions like "5 + 3*x" themselves aren't values, but they evaluate to 
a value. Neither are variables/names.

Variables *hold* values, or if you prefer, names refer to values. But 
since they aren't themselves values, names/variables aren't objects.

> Does a variable have a type?

In Python, no, variables don't have types. Python uses *dynamic typing* 
which we can simplify a little and describe as:

- variables are just labels that can refer to any value;

- values are typed;

- the interpreter checks that types are compatible at runtime,
  when the code is executed

(e.g. "1 + 2" is permitted, but "1 + []" is not).


The most common alternative is *static typing*, where:

- variables are typed;

- variables are labels that can only refer to a value that matches
  that type;

- the compiler checks that types are compatible at compile-time,
  before the code is executed.



-- 
Steve



From steve+comp.lang.python at pearwood.info  Tue May 15 19:51:42 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Tue, 15 May 2018 23:51:42 +0000 (UTC)
Subject: syntax oddities
References: <pdfbad$5sq$1@gioia.aioe.org>
Message-ID: <pdfrqe$unn$14@blaine.gmane.org>

On Tue, 15 May 2018 12:10:07 -0700, Tobiah wrote:

> Why is it len(object) instead of object.len?

Because we're not serfs in the Kingdom of Nouns:

https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html


-- 
Steve



From steve+comp.lang.python at pearwood.info  Tue May 15 20:04:06 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Wed, 16 May 2018 00:04:06 +0000 (UTC)
Subject: seeking deeper (language theory) reason behind Python design
 choice
References: <7s86fd1bncg5hovboehvvqe57budhc2bf8@4ax.com>
 <20180513024213.GG12850@bladeshadow.org> <pd966b$unn$4@blaine.gmane.org>
 <CAPTjJmpp=wqgSQ0sWXsh6jnDDYTHtNkO1Ct1BGQqTe1iD8exqQ@mail.gmail.com>
 <20180514153819.GO12850@bladeshadow.org>
 <CALwzidk=0AMKd81GPrqACp8spoV62ia6b6afR+X16kM-r1zOKA@mail.gmail.com>
 <20180514232013.GP12850@bladeshadow.org> <pddb0p$unn$10@blaine.gmane.org>
 <20180515202115.3pioqxhhdm6xnlr3@hjp.at>
Message-ID: <pdfshl$unn$15@blaine.gmane.org>

On Tue, 15 May 2018 22:21:15 +0200, Peter J. Holzer wrote:

> On 2018-05-15 00:52:42 +0000, Steven D'Aprano wrote:
[...]
>> By 1991 there had already been *decades* of experience with C
> 
> About one and a half decades.

That would still be plural decades.

C's first release was 1972, so more like 19 years than 15. That's just 
under two decades.


>> proving that the "=" assignment syntax is dangerously confusable with
>> == and a total bug magnet when allowed as expressions as well, so it
>> was perfectly reasonable to ban it from the language.
> 
> Experience? Yes. Data? I doubt it.

I'm using "proving" informally above, not in the sense of actual legal or 
scientific standards of proof.

If you are going to object to that, remember that neither is there 
scientific data proving that assignment as an expression is useful, so we 
can always just reject the construct as "useless until proven otherwise" 
:-)


> I will readily admit that my knowledge of research into the usability of
> programming languages is more than spotty, but I have read a few papers
> about the topic over the last decade. I don't recall any which
> quantified "bug magnets" under realistic conditions (two hour toy
> problems for first-year students don't count). I thought there was one
> by Google, but that was about compile-time errors.
> 
> Language design ist still mostly an art driven by gut feeling, not
> engineering driven by data. I doubt that this was better in 1991.
> 
> I have been programming in C since the mid-80's [...]
> I guess I could write a script which
> searches through all my repositories for changesets where ?=? was
> replaced by ?==?. Not sure what that would prove.)

You were using version control repositories in the 1980s, and still have 
access to them? I'm impressed.


> OTOH, despite having used C and Perl long before Python, I don't miss
> assignment expressions. Every language has its idioms, and just because
> you write stuff like ?if ((fd = open(...)) == -1)? a lot in C doesn't
> mean you have to be able to write that in Python.

I'm not a C coder, but I think that specific example would be immune to 
the bug we are discussing, since (I think) you can't chain assignments in 
C. Am I right?

    fd = open(...)) = -1

would be a syntax error. But:

    fd = -1

would not be.



-- 
Steve



From mike.junk.46 at att.net  Tue May 15 20:23:42 2018
From: mike.junk.46 at att.net (Mike McClain)
Date: Tue, 15 May 2018 17:23:42 -0700
Subject: stock quotes off the web, py style
Message-ID: <20180516002342.GA6956@playground>

    Initially I got my quotes from a broker daily to plug into a
spreadsheet, Then I found Yahoo and wrote a perl script to grab them.
When Yahoo quit supplying quotes I found AlphaVantage.co and rewrote
the perl script.
    AlphaVantage.co has been down since last week and I found
iextrading.com has a freely available interface. Since it needs
a rewrite and I'm trying to get a handle on python this seems
like a good opportunity to explore.
    If someone would please suggest modules to explore. Are there any
upper level modules that would allow me to do something like:

from module import get
def getAquote(symbol):
    url = 'https://api.iextrading.com/1.0/stock/()/quote'.format(symbol)
    reply = module.get(url)
    return my_parse(reply)

Thanks,
Mike
--
Men occasionally stumble over the truth, but most of them pick
themselves up and hurry off as if nothing ever happened.
    - Churchill


From bc at freeuk.com  Tue May 15 20:26:38 2018
From: bc at freeuk.com (bartc)
Date: Wed, 16 May 2018 01:26:38 +0100
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <mailman.88.1526415682.2761.python-list@python.org>
References: <7s86fd1bncg5hovboehvvqe57budhc2bf8@4ax.com>
 <20180513024213.GG12850@bladeshadow.org> <pd966b$unn$4@blaine.gmane.org>
 <CAPTjJmpp=wqgSQ0sWXsh6jnDDYTHtNkO1Ct1BGQqTe1iD8exqQ@mail.gmail.com>
 <20180514153819.GO12850@bladeshadow.org>
 <CALwzidk=0AMKd81GPrqACp8spoV62ia6b6afR+X16kM-r1zOKA@mail.gmail.com>
 <20180514232013.GP12850@bladeshadow.org> <pddb0p$unn$10@blaine.gmane.org>
 <20180515202115.3pioqxhhdm6xnlr3@hjp.at>
 <mailman.88.1526415682.2761.python-list@python.org>
Message-ID: <2VKKC.216808$jZ.124754@fx20.am4>

On 15/05/2018 21:21, Peter J. Holzer wrote:

> I have been programming in C since the mid-80's and in Perl since the
> mid-90's (both languages allow assignment expressions). I accumulated my
> fair share of bugs in that time, but AFAIR I made this particular error
> very rarely (I cannot confidently claim that I never made it). Clearly
> it is not ?a total bug magnet? in my experience. There are much bigger
> problems in C and Perl (and Python, too). But of course my experience is

All those languages use = for assignment and == for equality.

If like me you normally use a language where = means equality (and := is 
used for assignment), then you're going to get it wrong more frequently 
when using C or Python (I don't use Perl).

You might get it wrong anyway because = is used for equality in the real 
world too.

And it's an error that is awkward to detect (in C anyway, as it would be 
an error in Python) because usually both = and == are plausible in an 
expression.

-- 
bartc


From bc at freeuk.com  Tue May 15 20:28:47 2018
From: bc at freeuk.com (bartc)
Date: Wed, 16 May 2018 01:28:47 +0100
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <mailman.95.1526429186.2761.python-list@python.org>
References: <7s86fd1bncg5hovboehvvqe57budhc2bf8@4ax.com>
 <20180513024213.GG12850@bladeshadow.org> <pd966b$unn$4@blaine.gmane.org>
 <CAPTjJmpp=wqgSQ0sWXsh6jnDDYTHtNkO1Ct1BGQqTe1iD8exqQ@mail.gmail.com>
 <20180514153819.GO12850@bladeshadow.org>
 <CALwzidk=0AMKd81GPrqACp8spoV62ia6b6afR+X16kM-r1zOKA@mail.gmail.com>
 <20180514232013.GP12850@bladeshadow.org> <pddb0p$unn$10@blaine.gmane.org>
 <20180515202115.3pioqxhhdm6xnlr3@hjp.at> <pdfshl$unn$15@blaine.gmane.org>
 <mailman.95.1526429186.2761.python-list@python.org>
Message-ID: <3XKKC.216809$jZ.184175@fx20.am4>

On 16/05/2018 01:04, Steven D'Aprano wrote:

> I'm not a C coder, but I think that specific example would be immune to
> the bug we are discussing, since (I think) you can't chain assignments in
> C. Am I right?

Assignments can be chained in C (with right-to-left precedence) as can 
augmented assignments (+= and so on).

-- 
bartc


From ben+python at benfinney.id.au  Tue May 15 21:30:26 2018
From: ben+python at benfinney.id.au (Ben Finney)
Date: Wed, 16 May 2018 11:30:26 +1000
Subject: object types, mutable or not?
References: <mailman.27.1526227203.13745.python-list@python.org>
 <20180513200201.GA26725@playground>
 <53e09f9b-0da4-0ae0-3aff-b23029427474@Damon-Family.org>
 <20180515142939.GA5181@playground> <pdfrk2$unn$13@blaine.gmane.org>
Message-ID: <85y3gkl74d.fsf@benfinney.id.au>

Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:

> On Tue, 15 May 2018 07:29:39 -0700, Mike McClain wrote:
>
> > I had gotten the impression that everything in OOP is an object but
> > you're all saying that variables are not objects.
>
> Perhaps it is better to say every VALUE in Python is an object.

IMO that is better than using the term ?variable?, which carries baggage
from other languages when people try learning Python.

But not good enough. It was you, Steven (I think?) who taught me that
using the term ?value? interchangeably with ?object? is problematic.

That's because, in Python an object can remain the same object, while
its value changes.

    >>> foo = [1, 2, 3]    # A new list now exists.
    >>> foo.append(4)      # It's the same object, but now its value is different.

Therefore, an object is not its value (otherwise, when the value
changes, we necessarily have a different object. That's false, and so
the equivalence is also false.)

An object is not a value; an object *has* a value. The object retains
its identity even when its value changes.

> Variables *hold* values, or if you prefer, names refer to values. But
> since they aren't themselves values, names/variables aren't objects.

I really want that sentence to be useful for this pedagogical purpose.
My earlier message in this thread went to some length to do something
similar.

But because we only invite later confusion when the ?a value is an
object? false equivalence needs un-learning, I can't let it pass.

-- 
 \            ?The idea that He would take his attention away from the |
  `\       universe in order to give me a bicycle with three speeds is |
_o__)  just so unlikely that I can't go along with it.? ?Quentin Crisp |
Ben Finney



From cs at cskk.id.au  Tue May 15 22:47:30 2018
From: cs at cskk.id.au (Cameron Simpson)
Date: Wed, 16 May 2018 12:47:30 +1000
Subject: Extract data from multiple text files
In-Reply-To: <8fac4853-1e27-e595-5357-d0ed28ff1a77@mrabarnett.plus.com>
References: <8fac4853-1e27-e595-5357-d0ed28ff1a77@mrabarnett.plus.com>
Message-ID: <20180516024729.GA54061@cskk.homeip.net>

On 15May2018 18:18, MRAB <python at mrabarnett.plus.com> wrote:
>On 2018-05-15 13:12, mahesh d wrote:
>>import glob,os
[...]
>>files = glob.glob(path)

You've got a list of filenames here - they would work, _if_ you had passed in a 
glob pattern, instead of just the directory path. Try this again, joining 
"*.msg" or "*.txt" to the path.

>>for file in os.listdir(path):

As MRAB has mentioned, this just gets the file basenames. You need to join them 
to the directory path to get the proper pathname.

[...snop...]
>>In the above program . Getting lot of errors . My intention is read the
>>list of the text files in a folder . Print them
>>  How can resolve those error

Please _always_ include a text transcript of the errors, inline in the message 
(not as an attached file).

>You don't say what the errors are, but I'm guessing that it's 
>complaining that it can't find the file with trying to open it.
>
>'open' needs the _full path_ to the file, but 'os.listdir' returns 
>only the _name_ of the files and directories, not the full path.

In particular, since it may not be obvious how to do this correctly:
import the os.path module and look at the os.path.join function.

And finally, _please_ post follow on questions to this list as _replies_ to the 
appropriate list message. By just posting new messages from scratch your new 
message is disconnected from all the earlier ones. Anyone trying to follow your 
discussion will lose all the other context.

Cheers,
Cameron Simpson <cs at cskk.id.au> (formerly cs at zip.com.au)


From steve+comp.lang.python at pearwood.info  Wed May 16 02:39:52 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Wed, 16 May 2018 06:39:52 +0000 (UTC)
Subject: object types, mutable or not?
References: <mailman.27.1526227203.13745.python-list@python.org>
 <20180513200201.GA26725@playground>
 <53e09f9b-0da4-0ae0-3aff-b23029427474@Damon-Family.org>
 <20180515142939.GA5181@playground> <pdfrk2$unn$13@blaine.gmane.org>
 <85y3gkl74d.fsf@benfinney.id.au>
Message-ID: <pdgjnn$fka$1@blaine.gmane.org>

On Wed, 16 May 2018 11:30:26 +1000, Ben Finney wrote:

> Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:
> 
>> On Tue, 15 May 2018 07:29:39 -0700, Mike McClain wrote:
>>
>> > I had gotten the impression that everything in OOP is an object but
>> > you're all saying that variables are not objects.
>>
>> Perhaps it is better to say every VALUE in Python is an object.
> 
> IMO that is better than using the term ?variable?, which carries baggage
> from other languages when people try learning Python.
> 
> But not good enough. It was you, Steven (I think?) who taught me that
> using the term ?value? interchangeably with ?object? is problematic.

Not guilty Yer Honour! It wasn't me!


> That's because, in Python an object can remain the same object, while
> its value changes.

Indeed. But something can BE a value and HAVE a value at the same time, 
just as a class can be both a class and an instance (of the metaclass) at 
the same time.

It is true that if we consider mutable objects like lists, then the 
list's value can change as we move items in and out of the list.

But regardless of the value OF the list, we can still describe the list 
itself AS a value.

English is not optimal for discussing these concepts -- possibly no 
language is, or can be, as the concepts of identity, sameness, value etc 
are fuzzy and nebulous. If I replace the handle of my grandfather's axe, 
and then a year later I replace the head, is it still my grandfather's 
axe?

https://en.wikipedia.org/wiki/Ship_of_Theseus

Interesting if not relevant:

https://www.sciencedirect.com/science/article/pii/S1074552113001154


But I digress... we ought to distinguish between the value of a list, 
which of course may change through the list's lifetime, and the fact that 
no matter what value it has, it is still a value.

I'm not the same person I was 40 years ago, but both then and now I 
remain a person.


[...]
> Therefore, an object is not its value (otherwise, when the value
> changes, we necessarily have a different object. That's false, and so
> the equivalence is also false.)

I think you are begging the question by assuming that a change of value 
implies a new object. That's not how the words are used in standard 
English.

My house can appreciate and depreciate in value, even if I do nothing but 
occasionally remember to take out the trash... but we surely must agree 
that it is the same house, even if I replace the furniture, replace a 
broken window, repaint the living room, replace a broken tap... 


> An object is not a value; an object *has* a value. The object retains
> its identity even when its value changes.

Here you have hit on the crux of the matter. Why cannot both statements 
be true?

Webster's 1913 edition of "value" lists 10 distinct meanings for the 
noun; WordNet gives 6; the Oxford English dictionary on my desk also has 
6, and if I count sub-definitions (1a, 1b, 1c etc) I get fifteen.

Looking at the WordNet definitions, the one I think is nearest to the use 
I am making is something between numbers 1 and 4:

    1: a numerical quantity measured or assigned or computed;

    4: relative darkness or lightness of a color; "I establish the
       colors and principal values by organizing the painting into
       three values--dark, medium...and light"-Joe Hing Lowe

Obviously I'm not talking about the darkness or lightness of a colour 
specifically, but if we can enumerate three values "dark", "light" etc, 
we can surely enumerate a larger number of values including:

    None, True, False, various strings, lists, tuples, etc...

Some of these have numerical values in the sense of 1. above, some have 
textual values, some might be considered enumerations, some are compound 
values containing other values...


>> Variables *hold* values, or if you prefer, names refer to values. But
>> since they aren't themselves values, names/variables aren't objects.
> 
> I really want that sentence to be useful for this pedagogical purpose.
> My earlier message in this thread went to some length to do something
> similar.

The distinction I wanted to make, but forgot to, was that certain things 
are *first-class values* in a language, and others are not.

In Python, all objects are first-class values, and all values are 
objects. That's not the case for all languages, where some values are not 
first-class.

https://en.wikipedia.org/wiki/First-class_citizen

But not all *things* are values at all. For loops, expressions, names, 
try...except clauses etc are "things" but they're not values at all.


> But because we only invite later confusion when the ?a value is an
> object? false equivalence needs un-learning, I can't let it pass.

And I wouldn't expect anything less from you :-)

If we are looking for a single, short, plain English sentence which 
perfectly explains Python's object model using nothing but ordinary words 
whose meaning are self-evidently true and completely unambiguous, I fear 
we are doomed to be disappointed.

But it is fun to keep trying.



-- 
Steve



From rosuav at gmail.com  Wed May 16 02:49:39 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 16 May 2018 16:49:39 +1000
Subject: object types, mutable or not?
In-Reply-To: <pdgjnn$fka$1@blaine.gmane.org>
References: <mailman.27.1526227203.13745.python-list@python.org>
 <20180513200201.GA26725@playground>
 <53e09f9b-0da4-0ae0-3aff-b23029427474@Damon-Family.org>
 <20180515142939.GA5181@playground> <pdfrk2$unn$13@blaine.gmane.org>
 <85y3gkl74d.fsf@benfinney.id.au> <pdgjnn$fka$1@blaine.gmane.org>
Message-ID: <CAPTjJmp7Hdp4txLu7xg2r0263QVYeNRqFmgnpso2aAjM8CbArQ@mail.gmail.com>

On Wed, May 16, 2018 at 4:39 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
>
> But I digress... we ought to distinguish between the value of a list,
> which of course may change through the list's lifetime, and the fact that
> no matter what value it has, it is still a value.
>
> I'm not the same person I was 40 years ago, but both then and now I
> remain a person.

You remain a person, and you still have a value. Hmm. When did this
mailing list turn into a suicide help hotline?

ChrisA


From ben+python at benfinney.id.au  Wed May 16 03:03:22 2018
From: ben+python at benfinney.id.au (Ben Finney)
Date: Wed, 16 May 2018 17:03:22 +1000
Subject: object types, mutable or not?
References: <mailman.27.1526227203.13745.python-list@python.org>
 <20180513200201.GA26725@playground>
 <53e09f9b-0da4-0ae0-3aff-b23029427474@Damon-Family.org>
 <20180515142939.GA5181@playground> <pdfrk2$unn$13@blaine.gmane.org>
 <85y3gkl74d.fsf@benfinney.id.au> <pdgjnn$fka$1@blaine.gmane.org>
Message-ID: <85po1wkrph.fsf@benfinney.id.au>

Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:

> On Wed, 16 May 2018 11:30:26 +1000, Ben Finney wrote:
>
> > An object is not a value; an object *has* a value. The object
> > retains its identity even when its value changes.
>
> Here you have hit on the crux of the matter. Why cannot both
> statements be true?

The above assertion was in the context of saying what is pedagogically
useful.

If we have someone with the patience of a philosophy academic, one can
of course choose to explore the definitions of all terms. Then, by
choosing the definitions appropriately, we can make those statements
both true.

For teaching Python, we should not assume that kind of limitless
patience for ruthlessly abandoning prior meanings of terms before using
them.

For the purpose of teaching Python, I maintain that teaching ?every
value is an object? will lead the learner to infer ?an object is
whatever the value is?. That's a false inference, and we should avoid it
by not stating such an equivalence in the first place.

So, no, I think the more useful ? and less problematic ? framing is that
every object *has* a value, and mutable objects may change to a
different value while remaining the same object.

-- 
 \      ?He who allows oppression, shares the crime.? ?Erasmus Darwin, |
  `\                                     grandfather of Charles Darwin |
_o__)                                                                  |
Ben Finney



From steve+comp.lang.python at pearwood.info  Wed May 16 03:17:46 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Wed, 16 May 2018 07:17:46 +0000 (UTC)
Subject: object types, mutable or not?
References: <mailman.27.1526227203.13745.python-list@python.org>
 <20180513200201.GA26725@playground>
 <53e09f9b-0da4-0ae0-3aff-b23029427474@Damon-Family.org>
 <20180515142939.GA5181@playground> <pdfrk2$unn$13@blaine.gmane.org>
 <85y3gkl74d.fsf@benfinney.id.au> <pdgjnn$fka$1@blaine.gmane.org>
 <85po1wkrph.fsf@benfinney.id.au>
Message-ID: <pdgluq$fka$2@blaine.gmane.org>

On Wed, 16 May 2018 17:03:22 +1000, Ben Finney wrote:

> So, no, I think the more useful ? and less problematic ? framing is that
> every object *has* a value, and mutable objects may change to a
> different value while remaining the same object.

What's an object?

That's not a rhetorical question. When I started learning Python, I had 
*no idea* what "object oriented programming" was, or what classes and 
objects and instances were. I still don't know if there is a precise, 
accurate, unambiguous definition.

If you're going to describe Python in terms of objects for pedagogical 
purposes, you better be prepared to explain in simple, plain English, non-
technical, unambiguous terms what an object is. Without reference to the 
CPython (or any other Python) implementation.

It is true that "value" has a multitude of meanings. But "object" is even 
worse. Not only does it also have a multitude of meanings (Websters lists 
at least 7 for the noun, WordNet gives 5), but it ALSO has a technical 
meaning in computer science, AND a specific meaning in Python as the name 
of the type "object", AND also is used as a synonym for "instance".

I expect that most people understand that the ordinary English word 
"value" has a multitude of meanings, and so will avoid thinking of it as 
a precise technical term. I don't think you can say the same for "object".


-- 
Steve



From anthra.norell at bluewin.ch  Wed May 16 08:33:23 2018
From: anthra.norell at bluewin.ch (Friedrich Rentsch)
Date: Wed, 16 May 2018 14:33:23 +0200
Subject: stock quotes off the web, py style
In-Reply-To: <20180516002342.GA6956@playground>
References: <20180516002342.GA6956@playground>
Message-ID: <11d455e9-aa04-f993-48b0-060425bb7994@bluewin.ch>



On 05/16/2018 02:23 AM, Mike McClain wrote:
>      Initially I got my quotes from a broker daily to plug into a
> spreadsheet, Then I found Yahoo and wrote a perl script to grab them.
> When Yahoo quit supplying quotes I found AlphaVantage.co and rewrote
> the perl script.
>      AlphaVantage.co has been down since last week and I found
> iextrading.com has a freely available interface. Since it needs
> a rewrite and I'm trying to get a handle on python this seems
> like a good opportunity to explore.
>      If someone would please suggest modules to explore. Are there any
> upper level modules that would allow me to do something like:
>
> from module import get
> def getAquote(symbol):
>      url = 'https://api.iextrading.com/1.0/stock/()/quote'.format(symbol)
>      reply = module.get(url)
>      return my_parse(reply)
>
> Thanks,
> Mike
> --
> Men occasionally stumble over the truth, but most of them pick
> themselves up and hurry off as if nothing ever happened.
>      - Churchill

I didn't know the site you mention. I've been getting quotes from Yahoo 
daily. The service they discontinued was for up to 50 symbols per page. 
I now parse a separate page of some 500K of html for each symbol! This 
site is certainly more concise and surely a lot faster. It serves a 
naked set of data, which happens to conform to the python source code 
specification for dictionaries and consequently can be compiled into a 
dictionary with 'eval', like so:

 >>> ibm = urllib2.urlopen 
("https://api.iextrading.com/1.0/stock/IBM/quote").read()
 >>> ibm = eval (ibm)
 >>> for item in sorted (ibm.items()): print '%-24s%s' % item

avgTotalVolume????????? 5331869
calculationPrice??????? close
change????????????????? -0.56
changePercent?????????? -0.00388
close?????????????????? 143.74
closeTime?????????????? 1526414517398
companyName???????????? International Business Machines Corporation
delayedPrice??????????? 143.74
delayedPriceTime??????? 1526414517398
high??????????????????? 143.99
iexAskPrice???????????? 0
iexAskSize????????????? 0
iexBidPrice???????????? 0
iexBidSize????????????? 0
iexLastUpdated????????? 0
iexMarketPercent??????? 0
iexRealtimePrice??????? 0
iexRealtimeSize???????? 0
iexVolume?????????????? 0
latestPrice???????????? 143.74
latestSource??????????? Close
latestTime????????????? May 15, 2018
latestUpdate??????????? 1526414517398
latestVolume??????????? 4085996
low???????????????????? 142.92
marketCap?????????????? 131948764304
open??????????????????? 143.5
openTime??????????????? 1526391000646
peRatio???????????????? 10.34
previousClose?????????? 144.3
primaryExchange???????? New York Stock Exchange
sector????????????????? Technology
symbol????????????????? IBM
week52High????????????? 171.13
week52Low?????????????? 139.13
ytdChange?????????????? -0.0485148849103

You would do multiple symbols in a loop which you enter with an open 
urllib object, rather than opening a new one for each symbol inside the 
loop.

Frederic



From joel.goldstick at gmail.com  Wed May 16 08:56:04 2018
From: joel.goldstick at gmail.com (Joel Goldstick)
Date: Wed, 16 May 2018 08:56:04 -0400
Subject: stock quotes off the web, py style
In-Reply-To: <11d455e9-aa04-f993-48b0-060425bb7994@bluewin.ch>
References: <20180516002342.GA6956@playground>
 <11d455e9-aa04-f993-48b0-060425bb7994@bluewin.ch>
Message-ID: <CAPM-O+zvC7hMXWODAnfkjf+gKNum-+AAAfh7StqXh9U-Zb7YQw@mail.gmail.com>

On Wed, May 16, 2018 at 8:33 AM, Friedrich Rentsch
<anthra.norell at bluewin.ch> wrote:
>
>
> On 05/16/2018 02:23 AM, Mike McClain wrote:
>>
>>      Initially I got my quotes from a broker daily to plug into a
>> spreadsheet, Then I found Yahoo and wrote a perl script to grab them.
>> When Yahoo quit supplying quotes I found AlphaVantage.co and rewrote
>> the perl script.
>>      AlphaVantage.co has been down since last week and I found
>> iextrading.com has a freely available interface. Since it needs
>> a rewrite and I'm trying to get a handle on python this seems
>> like a good opportunity to explore.
>>      If someone would please suggest modules to explore. Are there any
>> upper level modules that would allow me to do something like:
>>
>> from module import get
>> def getAquote(symbol):
>>      url = 'https://api.iextrading.com/1.0/stock/()/quote'.format(symbol)
>>      reply = module.get(url)
>>      return my_parse(reply)
>>
>> Thanks,
>> Mike
>> --
>> Men occasionally stumble over the truth, but most of them pick
>> themselves up and hurry off as if nothing ever happened.
>>      - Churchill
>
>
> I didn't know the site you mention. I've been getting quotes from Yahoo
> daily. The service they discontinued was for up to 50 symbols per page. I
> now parse a separate page of some 500K of html for each symbol! This site is
> certainly more concise and surely a lot faster. It serves a naked set of
> data, which happens to conform to the python source code specification for
> dictionaries and consequently can be compiled into a dictionary with 'eval',
> like so:
>
>>>> ibm = urllib2.urlopen
>>>> ("https://api.iextrading.com/1.0/stock/IBM/quote").read()
>>>> ibm = eval (ibm)
>>>> for item in sorted (ibm.items()): print '%-24s%s' % item
>
> avgTotalVolume          5331869
> calculationPrice        close
> change                  -0.56
> changePercent           -0.00388
> close                   143.74
> closeTime               1526414517398
> companyName             International Business Machines Corporation
> delayedPrice            143.74
> delayedPriceTime        1526414517398
> high                    143.99
> iexAskPrice             0
> iexAskSize              0
> iexBidPrice             0
> iexBidSize              0
> iexLastUpdated          0
> iexMarketPercent        0
> iexRealtimePrice        0
> iexRealtimeSize         0
> iexVolume               0
> latestPrice             143.74
> latestSource            Close
> latestTime              May 15, 2018
> latestUpdate            1526414517398
> latestVolume            4085996
> low                     142.92
> marketCap               131948764304
> open                    143.5
> openTime                1526391000646
> peRatio                 10.34
> previousClose           144.3
> primaryExchange         New York Stock Exchange
> sector                  Technology
> symbol                  IBM
> week52High              171.13
> week52Low               139.13
> ytdChange               -0.0485148849103
>
> You would do multiple symbols in a loop which you enter with an open urllib
> object, rather than opening a new one for each symbol inside the loop.
>
> Frederic
>
> --
> https://mail.python.org/mailman/listinfo/python-list

Many people find the library called Requests a better alternative to
urllib.  It is more intuitive

-- 
Joel Goldstick
http://joelgoldstick.com/blog
http://cc-baseballstats.info/stats/birthdays


From chris at open-cosmos.com  Wed May 16 09:01:06 2018
From: chris at open-cosmos.com (Chris Lindsay)
Date: Wed, 16 May 2018 14:01:06 +0100
Subject: stock quotes off the web, py style
In-Reply-To: <11d455e9-aa04-f993-48b0-060425bb7994@bluewin.ch>
References: <20180516002342.GA6956@playground>
 <11d455e9-aa04-f993-48b0-060425bb7994@bluewin.ch>
Message-ID: <CAHiMU6eaD_w8xfjo=GvbQCEZ+XFgbK+aWcoFRmDYGbaW_0GYLA@mail.gmail.com>

 >It serves a naked set of data, which happens to conform to the python
source code specification for dictionaries and consequently can be compiled
into a dictionary with 'eval', like so:

I would highly discourage any long-term usage (or any usage) of eval() in
this sort of context. If iextrading was compromised, a malicious third
party could simply start serving arbitrary python expressions (instead of
the dictionary-like data currently) and your script would execute it
unquestioningly.

Consider using ast.literal_eval() -
https://docs.python.org/3/library/ast.html#ast.literal_eval  for parsing
string representations of basic python datatypes.

On 16 May 2018 at 13:33, Friedrich Rentsch <anthra.norell at bluewin.ch> wrote:

>
>
> On 05/16/2018 02:23 AM, Mike McClain wrote:
>
>>      Initially I got my quotes from a broker daily to plug into a
>> spreadsheet, Then I found Yahoo and wrote a perl script to grab them.
>> When Yahoo quit supplying quotes I found AlphaVantage.co and rewrote
>> the perl script.
>>      AlphaVantage.co has been down since last week and I found
>> iextrading.com has a freely available interface. Since it needs
>> a rewrite and I'm trying to get a handle on python this seems
>> like a good opportunity to explore.
>>      If someone would please suggest modules to explore. Are there any
>> upper level modules that would allow me to do something like:
>>
>> from module import get
>> def getAquote(symbol):
>>      url = 'https://api.iextrading.com/1.0/stock/()/quote'.format(symbol)
>>      reply = module.get(url)
>>      return my_parse(reply)
>>
>> Thanks,
>> Mike
>> --
>> Men occasionally stumble over the truth, but most of them pick
>> themselves up and hurry off as if nothing ever happened.
>>      - Churchill
>>
>
> I didn't know the site you mention. I've been getting quotes from Yahoo
> daily. The service they discontinued was for up to 50 symbols per page. I
> now parse a separate page of some 500K of html for each symbol! This site
> is certainly more concise and surely a lot faster. It serves a naked set of
> data, which happens to conform to the python source code specification for
> dictionaries and consequently can be compiled into a dictionary with
> 'eval', like so:
>
> >>> ibm = urllib2.urlopen ("https://api.iextrading.com/1.0/stock/IBM/quote
> ").read()
> >>> ibm = eval (ibm)
> >>> for item in sorted (ibm.items()): print '%-24s%s' % item
>
> avgTotalVolume          5331869
> calculationPrice        close
> change                  -0.56
> changePercent           -0.00388
> close                   143.74
> closeTime               1526414517398
> companyName             International Business Machines Corporation
> delayedPrice            143.74
> delayedPriceTime        1526414517398
> high                    143.99
> iexAskPrice             0
> iexAskSize              0
> iexBidPrice             0
> iexBidSize              0
> iexLastUpdated          0
> iexMarketPercent        0
> iexRealtimePrice        0
> iexRealtimeSize         0
> iexVolume               0
> latestPrice             143.74
> latestSource            Close
> latestTime              May 15, 2018
> latestUpdate            1526414517398
> latestVolume            4085996
> low                     142.92
> marketCap               131948764304
> open                    143.5
> openTime                1526391000646
> peRatio                 10.34
> previousClose           144.3
> primaryExchange         New York Stock Exchange
> sector                  Technology
> symbol                  IBM
> week52High              171.13
> week52Low               139.13
> ytdChange               -0.0485148849103
>
> You would do multiple symbols in a loop which you enter with an open
> urllib object, rather than opening a new one for each symbol inside the
> loop.
>
> Frederic
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
Chris
Open Cosmos

Any opinions given above are my own.


From ned at nedbatchelder.com  Wed May 16 09:23:02 2018
From: ned at nedbatchelder.com (Ned Batchelder)
Date: Wed, 16 May 2018 09:23:02 -0400
Subject: object types, mutable or not?
In-Reply-To: <pdgluq$fka$2@blaine.gmane.org>
References: <mailman.27.1526227203.13745.python-list@python.org>
 <20180513200201.GA26725@playground>
 <53e09f9b-0da4-0ae0-3aff-b23029427474@Damon-Family.org>
 <20180515142939.GA5181@playground> <pdfrk2$unn$13@blaine.gmane.org>
 <85y3gkl74d.fsf@benfinney.id.au> <pdgjnn$fka$1@blaine.gmane.org>
 <85po1wkrph.fsf@benfinney.id.au> <pdgluq$fka$2@blaine.gmane.org>
Message-ID: <8b1f93ef-88de-01d1-8f3a-799d88bc81b6@nedbatchelder.com>

On 5/16/18 3:17 AM, Steven D'Aprano wrote:
> On Wed, 16 May 2018 17:03:22 +1000, Ben Finney wrote:
>
>> So, no, I think the more useful ? and less problematic ? framing is that
>> every object *has* a value, and mutable objects may change to a
>> different value while remaining the same object.
> What's an object?
>
> That's not a rhetorical question. When I started learning Python, I had
> *no idea* what "object oriented programming" was, or what classes and
> objects and instances were. I still don't know if there is a precise,
> accurate, unambiguous definition.
>
> If you're going to describe Python in terms of objects for pedagogical
> purposes, you better be prepared to explain in simple, plain English, non-
> technical, unambiguous terms what an object is. Without reference to the
> CPython (or any other Python) implementation.
>
> It is true that "value" has a multitude of meanings. But "object" is even
> worse. Not only does it also have a multitude of meanings (Websters lists
> at least 7 for the noun, WordNet gives 5), but it ALSO has a technical
> meaning in computer science, AND a specific meaning in Python as the name
> of the type "object", AND also is used as a synonym for "instance".
>
> I expect that most people understand that the ordinary English word
> "value" has a multitude of meanings, and so will avoid thinking of it as
> a precise technical term. I don't think you can say the same for "object".
>
>

I've also experimented with different ways to better say "everything is 
an object".? One possibility is, "any right-hand side of an assignment 
is an object," though that is a bit tortured.

Now I'm thinking of trying, "Any piece of data is an object."? I think 
that might work well, with some complications arising when you have to 
explain that functions (and modules and classes and ...) are also a kind 
of data.? At least it will let me use the word "data" so I can pretend 
to be one of the cool kids :)

--Ned.


From p.f.moore at gmail.com  Wed May 16 09:48:27 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 16 May 2018 14:48:27 +0100
Subject: object types, mutable or not?
In-Reply-To: <8b1f93ef-88de-01d1-8f3a-799d88bc81b6@nedbatchelder.com>
References: <mailman.27.1526227203.13745.python-list@python.org>
 <20180513200201.GA26725@playground>
 <53e09f9b-0da4-0ae0-3aff-b23029427474@Damon-Family.org>
 <20180515142939.GA5181@playground> <pdfrk2$unn$13@blaine.gmane.org>
 <85y3gkl74d.fsf@benfinney.id.au> <pdgjnn$fka$1@blaine.gmane.org>
 <85po1wkrph.fsf@benfinney.id.au> <pdgluq$fka$2@blaine.gmane.org>
 <8b1f93ef-88de-01d1-8f3a-799d88bc81b6@nedbatchelder.com>
Message-ID: <CACac1F8OOUCu24Ve8eCbWWGfqbGrMx3F=M_3N8URnYdkaMWUTg@mail.gmail.com>

On 16 May 2018 at 14:23, Ned Batchelder <ned at nedbatchelder.com> wrote:

> I've also experimented with different ways to better say "everything is an
> object".  One possibility is, "any right-hand side of an assignment is an
> object," though that is a bit tortured.

C++ called that an "rvalue". And then went on to define things that
could go on the left hand side of an assignment as "lvalues". And now
we have two confusing concepts to explain - see what happens when you
let a standards committee define your language? :-)

Paul


From steve+comp.lang.python at pearwood.info  Wed May 16 10:06:30 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Wed, 16 May 2018 14:06:30 +0000 (UTC)
Subject: object types, mutable or not?
References: <mailman.27.1526227203.13745.python-list@python.org>
 <20180513200201.GA26725@playground>
 <53e09f9b-0da4-0ae0-3aff-b23029427474@Damon-Family.org>
 <20180515142939.GA5181@playground> <pdfrk2$unn$13@blaine.gmane.org>
 <85y3gkl74d.fsf@benfinney.id.au> <pdgjnn$fka$1@blaine.gmane.org>
 <85po1wkrph.fsf@benfinney.id.au> <pdgluq$fka$2@blaine.gmane.org>
 <8b1f93ef-88de-01d1-8f3a-799d88bc81b6@nedbatchelder.com>
Message-ID: <pdhdt6$fka$3@blaine.gmane.org>

On Wed, 16 May 2018 09:23:02 -0400, Ned Batchelder wrote:

> I've also experimented with different ways to better say "everything is
> an object".? One possibility is, "any right-hand side of an assignment
> is an object," though that is a bit tortured.

What if there's no assignment?

> Now I'm thinking of trying, "Any piece of data is an object."

Is None data? How about True and False?

Surely object() isn't data... and if it is, what about len?

*wink*

-- 
Steve



From grant.b.edwards at gmail.com  Wed May 16 10:25:43 2018
From: grant.b.edwards at gmail.com (Grant Edwards)
Date: Wed, 16 May 2018 14:25:43 +0000 (UTC)
Subject: seeking deeper (language theory) reason behind Python design
 choice
References: <7s86fd1bncg5hovboehvvqe57budhc2bf8@4ax.com>
 <20180513024213.GG12850@bladeshadow.org> <pd966b$unn$4@blaine.gmane.org>
 <CAPTjJmpp=wqgSQ0sWXsh6jnDDYTHtNkO1Ct1BGQqTe1iD8exqQ@mail.gmail.com>
 <20180514153819.GO12850@bladeshadow.org>
 <CALwzidk=0AMKd81GPrqACp8spoV62ia6b6afR+X16kM-r1zOKA@mail.gmail.com>
 <20180514232013.GP12850@bladeshadow.org> <pddb0p$unn$10@blaine.gmane.org>
 <20180515202115.3pioqxhhdm6xnlr3@hjp.at> <pdfshl$unn$15@blaine.gmane.org>
Message-ID: <pdhf17$du1$1@blaine.gmane.org>

On 2018-05-16, Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
> On Tue, 15 May 2018 22:21:15 +0200, Peter J. Holzer wrote:
>
>> On 2018-05-15 00:52:42 +0000, Steven D'Aprano wrote:
> [...]
>>> By 1991 there had already been *decades* of experience with C
>> 
>> About one and a half decades.
>
> That would still be plural decades.

So would zero. ;)

The only plural in English implies is that the quantity is not 1.  It
does _not_ imply the quantity is greater than 1.

-- 
Grant Edwards               grant.b.edwards        Yow! !  Now I understand
                                  at               advanced MICROBIOLOGY and
                              gmail.com            th' new TAX REFORM laws!!



From __peter__ at web.de  Wed May 16 10:31:37 2018
From: __peter__ at web.de (Peter Otten)
Date: Wed, 16 May 2018 16:31:37 +0200
Subject: stock quotes off the web, py style
References: <20180516002342.GA6956@playground>
 <11d455e9-aa04-f993-48b0-060425bb7994@bluewin.ch>
Message-ID: <pdhf88$kdm$1@blaine.gmane.org>

Friedrich Rentsch wrote:

>  >>> ibm = urllib2.urlopen
> ("https://api.iextrading.com/1.0/stock/IBM/quote").read()
>  >>> ibm = eval (ibm)

Dont do this. You are allowing the guys at iextrading.com to execute 
arbitrary code on your machine. Use

    ibm = json.loads(ibm)

instead or 

    import urllib.request, json
    ibm = urllib.request.urlopen(
        "https://api.iextrading.com/1.0/stock/IBM/quote"
    ).read()
    ibm = json.loads(ibm.decode("utf-8"))

if you are using Python 3.




From rosuav at gmail.com  Wed May 16 10:32:59 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Thu, 17 May 2018 00:32:59 +1000
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <pdhf17$du1$1@blaine.gmane.org>
References: <7s86fd1bncg5hovboehvvqe57budhc2bf8@4ax.com>
 <20180513024213.GG12850@bladeshadow.org>
 <pd966b$unn$4@blaine.gmane.org>
 <CAPTjJmpp=wqgSQ0sWXsh6jnDDYTHtNkO1Ct1BGQqTe1iD8exqQ@mail.gmail.com>
 <20180514153819.GO12850@bladeshadow.org>
 <CALwzidk=0AMKd81GPrqACp8spoV62ia6b6afR+X16kM-r1zOKA@mail.gmail.com>
 <20180514232013.GP12850@bladeshadow.org> <pddb0p$unn$10@blaine.gmane.org>
 <20180515202115.3pioqxhhdm6xnlr3@hjp.at> <pdfshl$unn$15@blaine.gmane.org>
 <pdhf17$du1$1@blaine.gmane.org>
Message-ID: <CAPTjJmpp8W-RiUqJZ2DAxgri7E-KYbB=9St1p-DDXW7wVBZz6g@mail.gmail.com>

On Thu, May 17, 2018 at 12:25 AM, Grant Edwards
<grant.b.edwards at gmail.com> wrote:
> On 2018-05-16, Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
>> On Tue, 15 May 2018 22:21:15 +0200, Peter J. Holzer wrote:
>>
>>> On 2018-05-15 00:52:42 +0000, Steven D'Aprano wrote:
>> [...]
>>>> By 1991 there had already been *decades* of experience with C
>>>
>>> About one and a half decades.
>>
>> That would still be plural decades.
>
> So would zero. ;)
>
> The only plural in English implies is that the quantity is not 1.  It
> does _not_ imply the quantity is greater than 1.

By 1991 there had already been AT LEAST negative seven decades of
experience with C. It's mathematically provable! And completely
useless.

ChrisA


From ned at nedbatchelder.com  Wed May 16 11:03:06 2018
From: ned at nedbatchelder.com (Ned Batchelder)
Date: Wed, 16 May 2018 11:03:06 -0400
Subject: object types, mutable or not?
In-Reply-To: <pdhdt6$fka$3@blaine.gmane.org>
References: <mailman.27.1526227203.13745.python-list@python.org>
 <20180513200201.GA26725@playground>
 <53e09f9b-0da4-0ae0-3aff-b23029427474@Damon-Family.org>
 <20180515142939.GA5181@playground> <pdfrk2$unn$13@blaine.gmane.org>
 <85y3gkl74d.fsf@benfinney.id.au> <pdgjnn$fka$1@blaine.gmane.org>
 <85po1wkrph.fsf@benfinney.id.au> <pdgluq$fka$2@blaine.gmane.org>
 <8b1f93ef-88de-01d1-8f3a-799d88bc81b6@nedbatchelder.com>
 <pdhdt6$fka$3@blaine.gmane.org>
Message-ID: <8f005e7b-054e-f9c6-224b-1e883ec4f920@nedbatchelder.com>

On 5/16/18 10:06 AM, Steven D'Aprano wrote:
> On Wed, 16 May 2018 09:23:02 -0400, Ned Batchelder wrote:
>
>> I've also experimented with different ways to better say "everything is
>> an object".? One possibility is, "any right-hand side of an assignment
>> is an object," though that is a bit tortured.
> What if there's no assignment?
>
>> Now I'm thinking of trying, "Any piece of data is an object."
> Is None data? How about True and False?
>
> Surely object() isn't data... and if it is, what about len?
>
This is what I meant by the complication when you get to a deeper 
discussion of all the possible kinds of Python values. I think even 
beginners would consider True and False as data.? The others take more 
explanation.

--Ned.


From ian.g.kelly at gmail.com  Wed May 16 11:09:06 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Wed, 16 May 2018 09:09:06 -0600
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <3XKKC.216809$jZ.184175@fx20.am4>
References: <7s86fd1bncg5hovboehvvqe57budhc2bf8@4ax.com>
 <20180513024213.GG12850@bladeshadow.org>
 <pd966b$unn$4@blaine.gmane.org>
 <CAPTjJmpp=wqgSQ0sWXsh6jnDDYTHtNkO1Ct1BGQqTe1iD8exqQ@mail.gmail.com>
 <20180514153819.GO12850@bladeshadow.org>
 <CALwzidk=0AMKd81GPrqACp8spoV62ia6b6afR+X16kM-r1zOKA@mail.gmail.com>
 <20180514232013.GP12850@bladeshadow.org> <pddb0p$unn$10@blaine.gmane.org>
 <20180515202115.3pioqxhhdm6xnlr3@hjp.at> <pdfshl$unn$15@blaine.gmane.org>
 <mailman.95.1526429186.2761.python-list@python.org>
 <3XKKC.216809$jZ.184175@fx20.am4>
Message-ID: <CALwzidmv8zewrJEL7tQozoPX792cf9MBn0kZBdE-NUuEU-RZFQ@mail.gmail.com>

On Tue, May 15, 2018, 6:36 PM bartc <bc at freeuk.com> wrote:

> On 16/05/2018 01:04, Steven D'Aprano wrote:
>
> > I'm not a C coder, but I think that specific example would be immune to
> > the bug we are discussing, since (I think) you can't chain assignments in
> > C. Am I right?
>
> Assignments can be chained in C (with right-to-left precedence) as can
> augmented assignments (+= and so on).
>

Yes, but not in the particular example that Steven was referring to, which
you elided from your quoting. open(...) is not a valid LHS for assignment.


From bc at freeuk.com  Wed May 16 12:06:26 2018
From: bc at freeuk.com (bartc)
Date: Wed, 16 May 2018 17:06:26 +0100
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <mailman.113.1526483367.2761.python-list@python.org>
References: <7s86fd1bncg5hovboehvvqe57budhc2bf8@4ax.com>
 <20180513024213.GG12850@bladeshadow.org> <pd966b$unn$4@blaine.gmane.org>
 <CAPTjJmpp=wqgSQ0sWXsh6jnDDYTHtNkO1Ct1BGQqTe1iD8exqQ@mail.gmail.com>
 <20180514153819.GO12850@bladeshadow.org>
 <CALwzidk=0AMKd81GPrqACp8spoV62ia6b6afR+X16kM-r1zOKA@mail.gmail.com>
 <20180514232013.GP12850@bladeshadow.org> <pddb0p$unn$10@blaine.gmane.org>
 <20180515202115.3pioqxhhdm6xnlr3@hjp.at> <pdfshl$unn$15@blaine.gmane.org>
 <mailman.95.1526429186.2761.python-list@python.org>
 <3XKKC.216809$jZ.184175@fx20.am4>
 <CALwzidmv8zewrJEL7tQozoPX792cf9MBn0kZBdE-NUuEU-RZFQ@mail.gmail.com>
 <mailman.113.1526483367.2761.python-list@python.org>
Message-ID: <3GYKC.126861$7B3.102722@fx13.am4>

On 16/05/2018 16:09, Ian Kelly wrote:
> On Tue, May 15, 2018, 6:36 PM bartc <bc at freeuk.com> wrote:
> 
>> On 16/05/2018 01:04, Steven D'Aprano wrote:
>>
>>> I'm not a C coder, but I think that specific example would be immune to
>>> the bug we are discussing, since (I think) you can't chain assignments in
>>> C. Am I right?
>>
>> Assignments can be chained in C (with right-to-left precedence) as can
>> augmented assignments (+= and so on).
>>
> 
> Yes, but not in the particular example that Steven was referring to, which
> you elided from your quoting.

I was responding to the chained assignment bit:

  a = b = c = d = x;

is allowed, but (depending on implementation details), the first = might 
be a different kind of assignment from the other three.

> open(...) is not a valid LHS for assignment.

The LHS needs to be an lvalue. A function result by itself won't be. 
open() would need to be a macro that expands to an lvalue, or used like 
this when open() returns a pointer:

    a = *open() = x;

So it only needs an extra * (subject to the correct types of everything 
involved) for both these "=" to be plausible.

-- 
bartc


From brian.j.oney at googlemail.com  Wed May 16 12:07:07 2018
From: brian.j.oney at googlemail.com (Brian Oney)
Date: Wed, 16 May 2018 18:07:07 +0200
Subject: stock quotes off the web, py style
In-Reply-To: <pdhf88$kdm$1@blaine.gmane.org>
References: <20180516002342.GA6956@playground>
 <11d455e9-aa04-f993-48b0-060425bb7994@bluewin.ch>
 <pdhf88$kdm$1@blaine.gmane.org>
Message-ID: <628BEEEC-026F-43BA-853B-136FF91D3984@gmail.com>

thank you for that tip. I missed that somehow...

?? 16 ??? 2018 ?. 16:31:37 GMT+02:00, Peter Otten <__peter__ at web.de> ??????:
>Friedrich Rentsch wrote:
>
>>  >>> ibm = urllib2.urlopen
>> ("https://api.iextrading.com/1.0/stock/IBM/quote").read()
>>  >>> ibm = eval (ibm)
>
>Dont do this. You are allowing the guys at iextrading.com to execute 
>arbitrary code on your machine. Use
>
>    ibm = json.loads(ibm)
>
>instead or 
>
>    import urllib.request, json
>    ibm = urllib.request.urlopen(
>        "https://api.iextrading.com/1.0/stock/IBM/quote"
>    ).read()
>    ibm = json.loads(ibm.decode("utf-8"))
>
>if you are using Python 3.
>
>
>-- 
>https://mail.python.org/mailman/listinfo/python-list


From ian.g.kelly at gmail.com  Wed May 16 12:07:07 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Wed, 16 May 2018 10:07:07 -0600
Subject: syntax oddities
In-Reply-To: <pdfrqe$unn$14@blaine.gmane.org>
References: <pdfbad$5sq$1@gioia.aioe.org> <pdfrqe$unn$14@blaine.gmane.org>
Message-ID: <CALwzid=CikO54Ny-QXM9g1M_mq+BSzsdtF95f0EJcjuRv7e=MA@mail.gmail.com>

On Tue, May 15, 2018, 6:00 PM Steven D'Aprano <
steve+comp.lang.python at pearwood.info> wrote:

> On Tue, 15 May 2018 12:10:07 -0700, Tobiah wrote:
>
> > Why is it len(object) instead of object.len?
>
> Because we're not serfs in the Kingdom of Nouns:
>
> https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html


No, then it would be written LengthGetter(object).getLength()


From mike.junk.46 at att.net  Wed May 16 12:21:53 2018
From: mike.junk.46 at att.net (Mike McClain)
Date: Wed, 16 May 2018 09:21:53 -0700
Subject: stock quotes off the web, py style
In-Reply-To: <11d455e9-aa04-f993-48b0-060425bb7994@bluewin.ch>
References: <20180516002342.GA6956@playground>
 <11d455e9-aa04-f993-48b0-060425bb7994@bluewin.ch>
Message-ID: <20180516162152.GA29802@playground>

On Wed, May 16, 2018 at 02:33:23PM +0200, Friedrich Rentsch wrote:
<snip>
>
> I didn't know the site you mention. I've been getting quotes from
> Yahoo daily. The service they discontinued was for up to 50 symbols
> per page. I now parse a separate page of some 500K of html for each
> symbol! This site is certainly more concise and surely a lot faster.

    Thank you sir for the response and code snippet.
As it turns out iextrading.com doesn't supply data on mutuals which
are the majority of my portfolio so they are not goimng to do me much
good after all.
    If you please, what is the URL of one stock you're getting from
Yahoo that requires parsing 500K of html per symbol? That's better
than not getting the quotes.
    If AlphaVantage ever comes back up, they send 100 days quotes for
each symbol and I only use today's and yesterday's, but it is easy to
parse.

> You would do multiple symbols in a loop which you enter with an open
> urllib object, rather than opening a new one for each symbol inside
> the loop.

    At the moment I can't see how to do that but will figure it out.
Thanks for the pointer.

Mike
--
"There are three kinds of men. The ones who learn by reading. The
few who learn by observation. The rest of them have to pee on the
electric fence for themselves." --- Will Rogers


From mike.junk.46 at att.net  Wed May 16 12:35:01 2018
From: mike.junk.46 at att.net (Mike McClain)
Date: Wed, 16 May 2018 09:35:01 -0700
Subject: stock quotes off the web, py style
In-Reply-To: <pdhf88$kdm$1@blaine.gmane.org>
References: <20180516002342.GA6956@playground>
 <11d455e9-aa04-f993-48b0-060425bb7994@bluewin.ch>
 <pdhf88$kdm$1@blaine.gmane.org>
Message-ID: <20180516163501.GB29802@playground>

For Friedrich's, Peter's and the many other responses, many thanks.
I will get a handle on python eventually and the many teachers on this
list are making that easier.

Mike
--
"There are three kinds of men. The ones who learn by reading. The
few who learn by observation. The rest of them have to pee on the
electric fence for themselves." --- Will Rogers


From ian.g.kelly at gmail.com  Wed May 16 12:47:39 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Wed, 16 May 2018 10:47:39 -0600
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <3GYKC.126861$7B3.102722@fx13.am4>
References: <7s86fd1bncg5hovboehvvqe57budhc2bf8@4ax.com>
 <20180513024213.GG12850@bladeshadow.org>
 <pd966b$unn$4@blaine.gmane.org>
 <CAPTjJmpp=wqgSQ0sWXsh6jnDDYTHtNkO1Ct1BGQqTe1iD8exqQ@mail.gmail.com>
 <20180514153819.GO12850@bladeshadow.org>
 <CALwzidk=0AMKd81GPrqACp8spoV62ia6b6afR+X16kM-r1zOKA@mail.gmail.com>
 <20180514232013.GP12850@bladeshadow.org> <pddb0p$unn$10@blaine.gmane.org>
 <20180515202115.3pioqxhhdm6xnlr3@hjp.at> <pdfshl$unn$15@blaine.gmane.org>
 <mailman.95.1526429186.2761.python-list@python.org>
 <3XKKC.216809$jZ.184175@fx20.am4>
 <CALwzidmv8zewrJEL7tQozoPX792cf9MBn0kZBdE-NUuEU-RZFQ@mail.gmail.com>
 <mailman.113.1526483367.2761.python-list@python.org>
 <3GYKC.126861$7B3.102722@fx13.am4>
Message-ID: <CALwzidnsM3ZCm+jkuxJxniE5z=QZd4evJ8uN0H67qoMtW_Nytg@mail.gmail.com>

On Wed, May 16, 2018 at 10:06 AM, bartc <bc at freeuk.com> wrote:
> On 16/05/2018 16:09, Ian Kelly wrote:
>>
>> On Tue, May 15, 2018, 6:36 PM bartc <bc at freeuk.com> wrote:
>>
>>> On 16/05/2018 01:04, Steven D'Aprano wrote:
>>>
>>>> I'm not a C coder, but I think that specific example would be immune to
>>>> the bug we are discussing, since (I think) you can't chain assignments
>>>> in
>>>> C. Am I right?
>>>
>>>
>>> Assignments can be chained in C (with right-to-left precedence) as can
>>> augmented assignments (+= and so on).
>>>
>>
>> Yes, but not in the particular example that Steven was referring to, which
>> you elided from your quoting.
>
>
> I was responding to the chained assignment bit:
>
>  a = b = c = d = x;
>
> is allowed, but (depending on implementation details), the first = might be
> a different kind of assignment from the other three.
>
>> open(...) is not a valid LHS for assignment.
>
>
> The LHS needs to be an lvalue. A function result by itself won't be. open()
> would need to be a macro that expands to an lvalue, or used like this when
> open() returns a pointer:
>
>    a = *open() = x;
>
> So it only needs an extra * (subject to the correct types of everything
> involved) for both these "=" to be plausible.

Sure, but that wasn't the example. The macro possibility is a good
point, but that's technically the C preprocessor, not the C language
itself.


From rosuav at gmail.com  Wed May 16 13:33:54 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Thu, 17 May 2018 03:33:54 +1000
Subject: object types, mutable or not?
In-Reply-To: <8f005e7b-054e-f9c6-224b-1e883ec4f920@nedbatchelder.com>
References: <mailman.27.1526227203.13745.python-list@python.org>
 <20180513200201.GA26725@playground>
 <53e09f9b-0da4-0ae0-3aff-b23029427474@Damon-Family.org>
 <20180515142939.GA5181@playground> <pdfrk2$unn$13@blaine.gmane.org>
 <85y3gkl74d.fsf@benfinney.id.au> <pdgjnn$fka$1@blaine.gmane.org>
 <85po1wkrph.fsf@benfinney.id.au> <pdgluq$fka$2@blaine.gmane.org>
 <8b1f93ef-88de-01d1-8f3a-799d88bc81b6@nedbatchelder.com>
 <pdhdt6$fka$3@blaine.gmane.org>
 <8f005e7b-054e-f9c6-224b-1e883ec4f920@nedbatchelder.com>
Message-ID: <CAPTjJmrtOSj2A7BAthrWR4FKxD2dsqAEvCNM+-_=z0fAHm7crQ@mail.gmail.com>

On Thu, May 17, 2018 at 1:03 AM, Ned Batchelder <ned at nedbatchelder.com> wrote:
> On 5/16/18 10:06 AM, Steven D'Aprano wrote:
>>
>> On Wed, 16 May 2018 09:23:02 -0400, Ned Batchelder wrote:
>>
>>> I've also experimented with different ways to better say "everything is
>>> an object".  One possibility is, "any right-hand side of an assignment
>>> is an object," though that is a bit tortured.
>>
>> What if there's no assignment?
>>
>>> Now I'm thinking of trying, "Any piece of data is an object."
>>
>> Is None data? How about True and False?
>>
>> Surely object() isn't data... and if it is, what about len?
>>
> This is what I meant by the complication when you get to a deeper discussion
> of all the possible kinds of Python values. I think even beginners would
> consider True and False as data.  The others take more explanation.
>

None takes only a little more explanation. It's data that says you
have no data. It's like asking "is zero a number?" - yes, there's a
mental leap to be made, but since it is so _exactly_ like zero's
status, it's not too hard to explain. (Nothing like as bad as
explaining SQL's NULL, which sometimes is a value, sometimes is a
placeholder meaning "there is no value here", sometimes is a
non-value, and sometimes just defies categorization.) Explaining that
*len* is data requires the concept of "functions are things, too",
which definitely takes some grokking.

ChrisA


From michael.stemper at gmail.com  Wed May 16 17:09:13 2018
From: michael.stemper at gmail.com (Michael F. Stemper)
Date: Wed, 16 May 2018 16:09:13 -0500
Subject: Simplest way to clobber/replace one populated directory with
 another?
In-Reply-To: <mailman.79.1526402261.2761.python-list@python.org>
References: <85ECD342-8D31-4B60-BE06-49AA16278500@gmail.com>
 <mailman.79.1526402261.2761.python-list@python.org>
Message-ID: <pdi6lp$p6o$1@dont-email.me>

On 2018-05-15 11:37, Travis Griggs wrote:
> I have a directory structure that might look something like:
> 
>      Data
>          Current
>              A
>              B
>              C
>          Previous
>              A
>              X
> 
> In as simple/quick a step as possible, I want to rename Current as Previous including the contents and wiping out the original such that it is now:
> 
>      Data
>          Previous
>              A
>              B
>              C

Is this what you need?

username at hostname$ ll */*
-rw-rw-r-- 1 username username  7 May 16 15:54 Current/1
-rw-rw-r-- 1 username username  7 May 16 15:54 Current/2
-rw-rw-r-- 1 username username 11 May 16 15:54 Current/3
-rw-rw-r-- 1 username username 18 May 16 15:55 Previous/1
-rw-rw-r-- 1 username username 18 May 16 15:55 Previous/2
-rw-rw-r-- 1 username username 14 May 16 15:55 Previous/3
username at hostname$ python
Python 2.7.12 (default, Dec  4 2017, 14:50:18)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> import shutil, os
 >>> shutil.rmtree("Previous")
 >>> os.rename("Current","Previous")
 >>>
username at hostname$ ll */*
-rw-rw-r-- 1 username username  7 May 16 15:54 Previous/1
-rw-rw-r-- 1 username username  7 May 16 15:54 Previous/2
-rw-rw-r-- 1 username username 11 May 16 15:54 Previous/3
username at hostname$

> (I am running on Linux)

If you can do this from a bash script rather than a python program, you
could just do:

#!/bin/bash
rm -r Previous
mv Previous Current

-- 
Michael F. Stemper
This email is to be read by its intended recipient only. Any other party
reading is required by the EULA to send me $500.00.


From anthra.norell at bluewin.ch  Wed May 16 18:02:50 2018
From: anthra.norell at bluewin.ch (Friedrich Rentsch)
Date: Thu, 17 May 2018 00:02:50 +0200
Subject: stock quotes off the web, py style
In-Reply-To: <20180516162152.GA29802@playground>
References: <20180516002342.GA6956@playground>
 <11d455e9-aa04-f993-48b0-060425bb7994@bluewin.ch>
 <20180516162152.GA29802@playground>
Message-ID: <47650509-c4a6-6196-2c91-84a4edaf39b6@bluewin.ch>



On 05/16/2018 06:21 PM, Mike McClain wrote:
> On Wed, May 16, 2018 at 02:33:23PM +0200, Friedrich Rentsch wrote:
> <snip>
>> I didn't know the site you mention. I've been getting quotes from
>> Yahoo daily. The service they discontinued was for up to 50 symbols
>> per page. I now parse a separate page of some 500K of html for each
>> symbol! This site is certainly more concise and surely a lot faster.
>      Thank you sir for the response and code snippet.
> As it turns out iextrading.com doesn't supply data on mutuals which
> are the majority of my portfolio so they are not goimng to do me much
> good after all.
>      If you please, what is the URL of one stock you're getting from
> Yahoo that requires parsing 500K of html per symbol? That's better
> than not getting the quotes.
>      If AlphaVantage ever comes back up, they send 100 days quotes for
> each symbol and I only use today's and yesterday's, but it is easy to
> parse.
>
>> You would do multiple symbols in a loop which you enter with an open
>> urllib object, rather than opening a new one for each symbol inside
>> the loop.
>      At the moment I can't see how to do that but will figure it out.
> Thanks for the pointer.
>
> Mike
> --
> "There are three kinds of men. The ones who learn by reading. The
> few who learn by observation. The rest of them have to pee on the
> electric fence for themselves." --- Will Rogers
I meant to check out AlphaVantage myself and registered, since it 
appears to be a kind of interest group. I wasn't aware it is down, 
because I haven't yet tried to log on. But I hope to do so when it comes 
back.

The way I get quotes from Yahoo is a hack: 1. Get a quote on the Yahoo 
web page. 2. Copy the url. 
(https://finance.yahoo.com/quote/IBM?p=IBM&guccounter=1). 3. Compose 
such urls in a loop one symbol at a time and read nearly 600K of html 
text for each of them. 4. Parse the text for the numbers I want to 
extract. Needles in a haystack. Slow for a large set of symbols and 
grossly inefficient in terms of data traffic.

Forget my last suggestion "You would do multiple symbols . . ." that was 
wrong. You have to open a urllib object for every symbol, the same way 
you'd open a file for every file name.

And thanks to the practitioners for the warnings against using 'eval'. I 
have hardly ever used it, never in online communications. So my 
awareness level is low. But I understand the need to be careful.

Frederic




  

You would do multiple symbols

"You would do multiple symbols



From cs at cskk.id.au  Wed May 16 18:54:49 2018
From: cs at cskk.id.au (Cameron Simpson)
Date: Thu, 17 May 2018 08:54:49 +1000
Subject: Simplest way to clobber/replace one populated directory with
 another?
In-Reply-To: <85ECD342-8D31-4B60-BE06-49AA16278500@gmail.com>
References: <85ECD342-8D31-4B60-BE06-49AA16278500@gmail.com>
Message-ID: <20180516225449.GA81392@cskk.homeip.net>

On 15May2018 09:37, Travis Griggs <travisgriggs at gmail.com> wrote:
>I have a directory structure that might look something like:
>
>    Data
>        Current
>            A
>            B
>            C
>        Previous
>            A
>            X
>
>In as simple/quick a step as possible, I want to rename Current as Previous including the contents and wiping out the original such that it is now:
>
>    Data
>        Previous
>            A
>            B
>            C
>
>I've tried something like:
>
>    from pathlib import Path
>    src = Path('Data/Current?)
>    dest = Path('Data/Previous?)
>    src.replace(dest)
>
>The docs led me to hope this would work:
>
>    "If target points to an existing file or directory, it will be unconditionally replaced.?
>
>But it *does* appear to be conditional. I get a "Directory not empty" 
>exception. I guess I could recursively delete the ?Previous' directory first. 
>Is that basically the only solution? Or is there a better way to achieve this?

When I do this and want speed I go:

1) rename Previous to a scratch name (eg .rmtmp-$$-Previous; the mkstemp 
function will help pick a free name for you). Make sure it is in the same 
directory i.e. rename blah/blah/Previous to blah/blah/.rmtmp-$$-Previous) - 
avoids accidentally crossing filesystem boundaries.

2) rename Current to previous

3) remove the old previous (I do this asynchronously in shell scripts)

In fact I do this so often in the shell that I have a trite script called "rmr" 
that does 1+3, and routinely type:

  rmr Previous && mv Current Previous

Prompt back instantly, "rm" of the temp name proceeding siletnly in the 
background.

Cheers,
Cameron Simpson <cs at cskk.id.au>


From arj.python at gmail.com  Wed May 16 21:25:44 2018
From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer)
Date: Thu, 17 May 2018 05:25:44 +0400
Subject: syntax oddities
In-Reply-To: <pdfbad$5sq$1@gioia.aioe.org>
References: <pdfbad$5sq$1@gioia.aioe.org>
Message-ID: <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>

weird, still not much traffic on this thread

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

On Tue, 15 May 2018, 23:15 Tobiah, <toby at tobiah.org> wrote:

> Why is it len(object) instead of object.len?
>
> Why is it getattr(object, item) rather then object.getattr(item)?
>
> etc...
>
>
> Thanks
> --
> https://mail.python.org/mailman/listinfo/python-list
>


From arj.python at gmail.com  Wed May 16 21:33:38 2018
From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer)
Date: Thu, 17 May 2018 05:33:38 +0400
Subject: what does := means simply?
Message-ID: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>

what does := proposes to do?

pep572

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ


From rosuav at gmail.com  Wed May 16 21:44:54 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Thu, 17 May 2018 11:44:54 +1000
Subject: what does := means simply?
In-Reply-To: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
Message-ID: <CAPTjJmo7sryJVHQv2k-PbzdgjCAuSCDP4o=6Zu9qmf3xoRfESg@mail.gmail.com>

On Thu, May 17, 2018 at 11:33 AM, Abdur-Rahmaan Janhangeer
<arj.python at gmail.com> wrote:
> what does := proposes to do?
>
> pep572
>

If you read the PEP, you'll find an answer to your question.

https://www.python.org/dev/peps/pep-0572/

ChrisA


From christysonia at gmail.com  Wed May 16 22:09:51 2018
From: christysonia at gmail.com (christysonia at gmail.com)
Date: Wed, 16 May 2018 19:09:51 -0700 (PDT)
Subject: Edge index problem
Message-ID: <7c7cc154-77af-4c4f-94ed-2b1a91aa8f55@googlegroups.com>

Am trying to get the edge index of selected edges in polygon.. (Maya).. don't how to query and get the values. Pls help me to find out..


From arj.python at gmail.com  Wed May 16 22:39:45 2018
From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer)
Date: Thu, 17 May 2018 06:39:45 +0400
Subject: what does := means simply?
In-Reply-To: <CAPTjJmo7sryJVHQv2k-PbzdgjCAuSCDP4o=6Zu9qmf3xoRfESg@mail.gmail.com>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <CAPTjJmo7sryJVHQv2k-PbzdgjCAuSCDP4o=6Zu9qmf3xoRfESg@mail.gmail.com>
Message-ID: <CADrxXXkHNmocGS=wufpk_x7VpOKOEb0jZ6edW_XNH3Sa76=5KQ@mail.gmail.com>

meaning that's precisely what i'm asking for

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

On Thu, 17 May 2018, 05:45 Chris Angelico, <rosuav at gmail.com> wrote:

> On Thu, May 17, 2018 at 11:33 AM, Abdur-Rahmaan Janhangeer
> <arj.python at gmail.com> wrote:
> > what does := proposes to do?
> >
> > pep572
> >
>
> If you read the PEP, you'll find an answer to your question.
>
> https://www.python.org/dev/peps/pep-0572/
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>


From arj.python at gmail.com  Wed May 16 22:41:31 2018
From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer)
Date: Thu, 17 May 2018 06:41:31 +0400
Subject: why does list's .remove() does not return an object?
Message-ID: <CADrxXXmrvyfCJmFa92O01TKBfh1o1toxFu7jZCyfjAMgpehMVg@mail.gmail.com>

why is x = list.remove(elem) not return the list?

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ


From ned at nedbatchelder.com  Wed May 16 23:01:40 2018
From: ned at nedbatchelder.com (Ned Batchelder)
Date: Wed, 16 May 2018 23:01:40 -0400
Subject: why does list's .remove() does not return an object?
In-Reply-To: <CADrxXXmrvyfCJmFa92O01TKBfh1o1toxFu7jZCyfjAMgpehMVg@mail.gmail.com>
References: <CADrxXXmrvyfCJmFa92O01TKBfh1o1toxFu7jZCyfjAMgpehMVg@mail.gmail.com>
Message-ID: <57b25718-46e0-cca0-aa4d-a1209e9cafee@nedbatchelder.com>

On 5/16/18 10:41 PM, Abdur-Rahmaan Janhangeer wrote:
> why is x = list.remove(elem) not return the list?
>
>
Methods in Python usually do one of two things: 1) mutate the object and 
return None; or 2) leave the object alone and return a new object.? This 
helps make it clear which methods mutate and which don't.? Since .remove 
mutates the list, it returns None.

--Ned.


From jladasky at itu.edu  Wed May 16 23:11:42 2018
From: jladasky at itu.edu (jladasky at itu.edu)
Date: Wed, 16 May 2018 20:11:42 -0700 (PDT)
Subject: why does list's .remove() does not return an object?
In-Reply-To: <mailman.127.1526524911.2761.python-list@python.org>
References: <CADrxXXmrvyfCJmFa92O01TKBfh1o1toxFu7jZCyfjAMgpehMVg@mail.gmail.com>
 <mailman.127.1526524911.2761.python-list@python.org>
Message-ID: <f8ecb7f0-d410-4065-93bd-aad65e7e9fbc@googlegroups.com>

On Wednesday, May 16, 2018 at 7:42:01 PM UTC-7, Abdur-Rahmaan Janhangeer wrote:
> why is x = list.remove(elem) not return the list?
> 
> Abdur-Rahmaan Janhangeer
> https://github.com/Abdur-rahmaanJ

1) If you are naming your list "list," you're asking for trouble.  Shadowing builtin names is risky.  Ten years ago I named a variable "max".  Oops.

2) list.remove() operates in-place.  Would you expect it to return a copy?  Making that copy could potentially use a lot of memory and time.

3) If you do want a copy, construct it from two slices of your original list.  Let's say the element you want to remove is at position 6.  Then:

new_list = old_list[:6] + old_list[7:]


3)


From steve+comp.lang.python at pearwood.info  Wed May 16 23:43:07 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Thu, 17 May 2018 03:43:07 +0000 (UTC)
Subject: syntax oddities
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
Message-ID: <pditoa$fka$4@blaine.gmane.org>

On Thu, 17 May 2018 05:25:44 +0400, Abdur-Rahmaan Janhangeer wrote:

> weird, still not much traffic on this thread

How many ways would you like us to answer the question?

It is a FAQ:

https://docs.python.org/3/faq/design.html

Here's an older version:

http://www.effbot.org/pyfaq/why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list.htm




-- 
Steve



From steve+comp.lang.python at pearwood.info  Wed May 16 23:54:51 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Thu, 17 May 2018 03:54:51 +0000 (UTC)
Subject: what does := means simply?
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
Message-ID: <pdiueb$fka$5@blaine.gmane.org>

On Thu, 17 May 2018 05:33:38 +0400, Abdur-Rahmaan Janhangeer wrote:

> what does := proposes to do?

Simply, it proposes to add a new operator := for assignment (or binding) 
as an expression, as an addition to the = assignment operator which 
operates only as a statement. The syntax is:

    name := expression

and the meaning is:

1. evaluate <expression>

2. assign that value to <name>

3. return that same value as the result


A simple example (not necessarily a GOOD example, but a SIMPLE one):

print(x := 100, x+1, x*2, x**3)

will print:

100 101 200 1000000

Today, we would write that as:

x = 100
print(x, x+1, x*2, x**3)


A better example might be:


if mo := re.search(pattern1, text):
    print(mo.group(0))
elif mo := re.match(pattern2, text):
    print(mo.group(3))
elif mo := re.search(pattern3, text):
    print(mo.group(2))



which today would need to be written as:


mo = re.search(pattern, text)
if mo:
    print(mo.group(0))
else:
    mo = re.match(pattern2, text)
    if mo:
        print(mo.group(3))
    else:
        mo := re.search(pattern3, text)
        if mo:
            print(mo.group(2))



-- 
Steve



From kret.ca at gmail.com  Thu May 17 00:10:52 2018
From: kret.ca at gmail.com (kret.ca at gmail.com)
Date: Wed, 16 May 2018 21:10:52 -0700 (PDT)
Subject: Python - requests - forms - web scraping - how to deal with multi
 stage forms
Message-ID: <8edbf5f6-ffc9-4c59-ac10-51324310583c@googlegroups.com>

https://stackoverflow.com/questions/50383210/python-requests-how-to-post-few-stages-forms


From zljubisic at gmail.com  Thu May 17 03:49:17 2018
From: zljubisic at gmail.com (zljubisic at gmail.com)
Date: Thu, 17 May 2018 00:49:17 -0700 (PDT)
Subject: Pandas cat.categories.isin list, is this a bug?
In-Reply-To: <mailman.73.1526388833.2761.python-list@python.org>
References: <9fb404de-0ff5-4ad5-86fe-16e02ac9a257@googlegroups.com>
 <872d0323-13ec-31b9-1dc9-406125c25593@gmail.com>
 <CAF+o+SFLiEmsnG-Q1L5GkV8UWtR6BEG5B+KzpZCky8XubJnEGQ@mail.gmail.com>
 <8fe451dc-3475-46e6-beac-d2efff542e79@gmail.com>
 <mailman.73.1526388833.2761.python-list@python.org>
Message-ID: <2d577759-9f4a-4b39-8612-1f781a3a70a0@googlegroups.com>

Hi Matt,

> (Including python-list again, for lack of a reason not to. This
> conversation is still relevant and appropriate for the general Python
> mailing list -- I just meant that the pydata list likely has many more
> Pandas users/experts, so you're more likely to get a better answer,
> faster, from a more specialized group.)

OK, for now we will stay here, but in the future I will use pydata as you have suggested.

> Selecting all rows that have categories is a bit simpler than what you
> are doing -- your issue is that you are working with the *set of
> distinct categories*, and not the actual vector of categories
> corresponding to your data.

Yes, now I got it thanks to your explanation. 
df.CRM_assetID.cat.categories means unique categories of the CRM_assetID field.
Now I am using df_cat[df_cat.CRM_assetID.isin({'V1254748', 'V805722', 'V1105400'})].shape to select all rows that have relevant categories.
Thanks for the set instead of list as well. Very good tip.
Everything works as it should now. 

Matt, you were more than helpful.
Thank you very very much.

Best regards.


From greg.ewing at canterbury.ac.nz  Thu May 17 04:13:25 2018
From: greg.ewing at canterbury.ac.nz (Gregory Ewing)
Date: Thu, 17 May 2018 20:13:25 +1200
Subject: object types, mutable or not?
In-Reply-To: <mailman.112.1526482996.2761.python-list@python.org>
References: <mailman.27.1526227203.13745.python-list@python.org>
 <20180513200201.GA26725@playground>
 <53e09f9b-0da4-0ae0-3aff-b23029427474@Damon-Family.org>
 <20180515142939.GA5181@playground> <pdfrk2$unn$13@blaine.gmane.org>
 <85y3gkl74d.fsf@benfinney.id.au> <pdgjnn$fka$1@blaine.gmane.org>
 <85po1wkrph.fsf@benfinney.id.au> <pdgluq$fka$2@blaine.gmane.org>
 <8b1f93ef-88de-01d1-8f3a-799d88bc81b6@nedbatchelder.com>
 <pdhdt6$fka$3@blaine.gmane.org>
 <8f005e7b-054e-f9c6-224b-1e883ec4f920@nedbatchelder.com>
 <mailman.112.1526482996.2761.python-list@python.org>
Message-ID: <fm4rt7FhigdU1@mid.individual.net>

I don't think it's very helpful to anyone to say that "everything
is an object", because "everything" is far too vague a term.
(It's not even close to being true -- there are plenty of concepts
in Python that are not objects.)

I think I would say something like "All data that a Python program
can manipulate comes in the form of things we call objects."
Then go on to give some examples of different kinds of objects --
integer objects, string objects, list objects, etc. And that
variables in Python don't contain objects, they just refer to
objects. Draw some diagrams with boxes and arrows.

-- 
Greg


From arj.python at gmail.com  Thu May 17 04:18:28 2018
From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer)
Date: Thu, 17 May 2018 12:18:28 +0400
Subject: what does := means simply?
In-Reply-To: <pdiueb$fka$5@blaine.gmane.org>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
Message-ID: <CADrxXXnkzGGnkdEFUYBepO2Ym3kh4CU7s6MydVtjOU+xLk+erg@mail.gmail.com>

thank you very much @steve

i guess it will make py fly more than ever !

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

On Thu, 17 May 2018, 07:57 Steven D'Aprano, <
steve+comp.lang.python at pearwood.info> wrote:

> On Thu, 17 May 2018 05:33:38 +0400, Abdur-Rahmaan Janhangeer wrote:
>
> > what does := proposes to do?
>
> Simply, it proposes to add a new operator := for assignment (or binding)
> as an expression, as an addition to the = assignment operator which
> operates only as a statement. The syntax is:
>
>     name := expression
>
> and the meaning is:
>
> 1. evaluate <expression>
>
> 2. assign that value to <name>
>
> 3. return that same value as the result
>
>
> A simple example (not necessarily a GOOD example, but a SIMPLE one):
>
> print(x := 100, x+1, x*2, x**3)
>
> will print:
>
> 100 101 200 1000000
>
> Today, we would write that as:
>
> x = 100
> print(x, x+1, x*2, x**3)
>
>
> A better example might be:
>
>
> if mo := re.search(pattern1, text):
>     print(mo.group(0))
> elif mo := re.match(pattern2, text):
>     print(mo.group(3))
> elif mo := re.search(pattern3, text):
>     print(mo.group(2))
>
>
>
> which today would need to be written as:
>
>
> mo = re.search(pattern, text)
> if mo:
>     print(mo.group(0))
> else:
>     mo = re.match(pattern2, text)
>     if mo:
>         print(mo.group(3))
>     else:
>         mo := re.search(pattern3, text)
>         if mo:
>             print(mo.group(2))
>
>
>
> --
> Steve
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>


From arj.python at gmail.com  Thu May 17 04:23:17 2018
From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer)
Date: Thu, 17 May 2018 12:23:17 +0400
Subject: why does list's .remove() does not return an object?
In-Reply-To: <57b25718-46e0-cca0-aa4d-a1209e9cafee@nedbatchelder.com>
References: <CADrxXXmrvyfCJmFa92O01TKBfh1o1toxFu7jZCyfjAMgpehMVg@mail.gmail.com>
 <57b25718-46e0-cca0-aa4d-a1209e9cafee@nedbatchelder.com>
Message-ID: <CADrxXXn_DQatgBYW+DS5oz9EXYO_fn0ByQRQSFhJ_UpEdQ3y9g@mail.gmail.com>

if then a more convenient way might be found to naturally remove and return
the list

maybe it was not included as one might want to remove the list only

x = [1]
x.remove(1)

as opposed to

x = [1]
x.remove(1)
new_list = x

i was looking for like

x = [1]
x.remove(1).return()

ps. list is was demo illustrative var

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

On Thu, 17 May 2018, 07:01 Ned Batchelder, <ned at nedbatchelder.com> wrote:

> On 5/16/18 10:41 PM, Abdur-Rahmaan Janhangeer wrote:
> > why is x = list.remove(elem) not return the list?
> >
> >
> Methods in Python usually do one of two things: 1) mutate the object and
> return None; or 2) leave the object alone and return a new object.  This
> helps make it clear which methods mutate and which don't.  Since .remove
> mutates the list, it returns None.
>
> --Ned.
> --
> https://mail.python.org/mailman/listinfo/python-list
>


From arj.python at gmail.com  Thu May 17 04:24:42 2018
From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer)
Date: Thu, 17 May 2018 12:24:42 +0400
Subject: syntax oddities
In-Reply-To: <pditoa$fka$4@blaine.gmane.org>
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
Message-ID: <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>

just a remark that people help and discuss on more issues unrelated to
python

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

On Thu, 17 May 2018, 07:45 Steven D'Aprano, <
steve+comp.lang.python at pearwood.info> wrote:

> On Thu, 17 May 2018 05:25:44 +0400, Abdur-Rahmaan Janhangeer wrote:
>
> > weird, still not much traffic on this thread
>
> How many ways would you like us to answer the question?
>
> It is a FAQ:
>
> https://docs.python.org/3/faq/design.html
>
> Here's an older version:
>
>
> http://www.effbot.org/pyfaq/why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list.htm
>
>
>
>
> --
> Steve
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>


From anubhav.yadav at gmx.com  Thu May 17 04:29:59 2018
From: anubhav.yadav at gmx.com (GMX)
Date: Thu, 17 May 2018 13:59:59 +0530
Subject: Python - requests - forms - web scraping - how to deal with
 multi stage forms
In-Reply-To: <8edbf5f6-ffc9-4c59-ac10-51324310583c@googlegroups.com>
References: <8edbf5f6-ffc9-4c59-ac10-51324310583c@googlegroups.com>
Message-ID: <etPan.5afd3d87.72de2e15.1ec3@gmx.com>


https://stackoverflow.com/questions/50383210/python-requests-how-to-post-few-stages-forms?
--?
https://mail.python.org/mailman/listinfo/python-list?


Hi,?

Your post will get more traction on the email list if you try to post the actual question on the list against posting a url to an external website for your question.?

Coming back to the question. I think what you want to do is implement some client side processing using Javascript or one of it?s frameworks and implement the parts. Once everything is done you can submit it to the python server.?

Hope that helps.?



Anubhav.

From greg.ewing at canterbury.ac.nz  Thu May 17 04:48:01 2018
From: greg.ewing at canterbury.ac.nz (Gregory Ewing)
Date: Thu, 17 May 2018 20:48:01 +1200
Subject: syntax oddities
In-Reply-To: <mailman.123.1526520359.2761.python-list@python.org>
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <mailman.123.1526520359.2761.python-list@python.org>
Message-ID: <fm4tu4Fi0tfU1@mid.individual.net>

> On Tue, 15 May 2018, 23:15 Tobiah, <toby at tobiah.org> wrote:
> 
>>Why is it getattr(object, item) rather then object.getattr(item)?

It's part of the design philosophy of Python that the
namespace of a new user-defined class should as far as
possible start off as a "blank slate", not cluttered
up with a bunch of predefined names. So, very general
things like getattr() that apply to any object are
implemented as functions that operate on an object,
rather than methods.

-- 
Greg


From jfong at ms4.hinet.net  Thu May 17 05:12:01 2018
From: jfong at ms4.hinet.net (Jach Fong)
Date: Thu, 17 May 2018 17:12:01 +0800
Subject: why does list's .remove() does not return an object?
In-Reply-To: <CADrxXXn_DQatgBYW+DS5oz9EXYO_fn0ByQRQSFhJ_UpEdQ3y9g@mail.gmail.com>
References: <CADrxXXmrvyfCJmFa92O01TKBfh1o1toxFu7jZCyfjAMgpehMVg@mail.gmail.com>
 <57b25718-46e0-cca0-aa4d-a1209e9cafee@nedbatchelder.com>
 <CADrxXXn_DQatgBYW+DS5oz9EXYO_fn0ByQRQSFhJ_UpEdQ3y9g@mail.gmail.com>
Message-ID: <ca0bf687-4d5f-f87c-3165-7f9abdc8854d@ms4.hinet.net>

Abdur-Rahmaan Janhangeer at 2018/5/17 PM 04:23 wrote:
> if then a more convenient way might be found to naturally remove and return
> the list
> 
> maybe it was not included as one might want to remove the list only
> 
> x = [1]
> x.remove(1)
> 
> as opposed to
> 
> x = [1]
> x.remove(1)
> new_list = x

IMO, this way is more flexible on its usage and avoid
a redundant copy.

--Jach

> 
> i was looking for like
> 
> x = [1]
> x.remove(1).return()
> 
> ps. list is was demo illustrative var
> 
> Abdur-Rahmaan Janhangeer
> https://github.com/Abdur-rahmaanJ
> 
> On Thu, 17 May 2018, 07:01 Ned Batchelder, <ned at nedbatchelder.com> wrote:
> 
>> On 5/16/18 10:41 PM, Abdur-Rahmaan Janhangeer wrote:
>>> why is x = list.remove(elem) not return the list?
>>>
>>>
>> Methods in Python usually do one of two things: 1) mutate the object and
>> return None; or 2) leave the object alone and return a new object.  This
>> helps make it clear which methods mutate and which don't.  Since .remove
>> mutates the list, it returns None.
>>
>> --Ned.
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



From wegge at wegge.dk  Thu May 17 05:16:32 2018
From: wegge at wegge.dk (Anders Wegge Keller)
Date: Thu, 17 May 2018 11:16:32 +0200
Subject: object types, mutable or not?
In-Reply-To: <CACac1F8OOUCu24Ve8eCbWWGfqbGrMx3F=M_3N8URnYdkaMWUTg@mail.gmail.com>
References: <mailman.27.1526227203.13745.python-list@python.org>
 <20180513200201.GA26725@playground>
 <53e09f9b-0da4-0ae0-3aff-b23029427474@Damon-Family.org>
 <20180515142939.GA5181@playground> <pdfrk2$unn$13@blaine.gmane.org>
 <85y3gkl74d.fsf@benfinney.id.au> <pdgjnn$fka$1@blaine.gmane.org>
 <85po1wkrph.fsf@benfinney.id.au> <pdgluq$fka$2@blaine.gmane.org>
 <8b1f93ef-88de-01d1-8f3a-799d88bc81b6@nedbatchelder.com>
 <CACac1F8OOUCu24Ve8eCbWWGfqbGrMx3F=M_3N8URnYdkaMWUTg@mail.gmail.com>
Message-ID: <20180517111632.33904cdf@wegge.dk>

P? Wed, 16 May 2018 14:48:27 +0100
Paul Moore <p.f.moore at gmail.com> skrev:

> C++ called that an "rvalue". And then went on to define things that
> could go on the left hand side of an assignment as "lvalues". And now
> we have two confusing concepts to explain - see what happens when you
> let a standards committee define your language? :-)

 I'm not sure the C++ committee has to bear the responsibility for those
terms. They are pretty well defined in the C world, so I think you need to
point the finger of accusation at either Brian or Dennis. 

-- 
//Wegge


From rosuav at gmail.com  Thu May 17 05:28:44 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Thu, 17 May 2018 19:28:44 +1000
Subject: object types, mutable or not?
In-Reply-To: <20180517111632.33904cdf@wegge.dk>
References: <mailman.27.1526227203.13745.python-list@python.org>
 <20180513200201.GA26725@playground>
 <53e09f9b-0da4-0ae0-3aff-b23029427474@Damon-Family.org>
 <20180515142939.GA5181@playground> <pdfrk2$unn$13@blaine.gmane.org>
 <85y3gkl74d.fsf@benfinney.id.au> <pdgjnn$fka$1@blaine.gmane.org>
 <85po1wkrph.fsf@benfinney.id.au> <pdgluq$fka$2@blaine.gmane.org>
 <8b1f93ef-88de-01d1-8f3a-799d88bc81b6@nedbatchelder.com>
 <CACac1F8OOUCu24Ve8eCbWWGfqbGrMx3F=M_3N8URnYdkaMWUTg@mail.gmail.com>
 <20180517111632.33904cdf@wegge.dk>
Message-ID: <CAPTjJmqGWhZZ-tS1-xLBf=EyRN92prPmOx3T3dqSf9J2c_2G3Q@mail.gmail.com>

On Thu, May 17, 2018 at 7:16 PM, Anders Wegge Keller <wegge at wegge.dk> wrote:
> P? Wed, 16 May 2018 14:48:27 +0100
> Paul Moore <p.f.moore at gmail.com> skrev:
>
>> C++ called that an "rvalue". And then went on to define things that
>> could go on the left hand side of an assignment as "lvalues". And now
>> we have two confusing concepts to explain - see what happens when you
>> let a standards committee define your language? :-)
>
>  I'm not sure the C++ committee has to bear the responsibility for those
> terms. They are pretty well defined in the C world, so I think you need to
> point the finger of accusation at either Brian or Dennis.
>

Let's be fair and blame one of them for each.

ChrisA


From jpn.jha1 at gmail.com  Thu May 17 07:42:03 2018
From: jpn.jha1 at gmail.com (Jpn Jha)
Date: Thu, 17 May 2018 17:12:03 +0530
Subject: About: from sklearn import linear_model ModuleNotFoundError: No
 module named sklearn
Message-ID: <CACt-=weCYHcMykSfjULCtdc645xAU6ZVeLBAvy2OeoN6QnR4Aw@mail.gmail.com>

Dear Team
Please attached  Python_PyCharm  Interpreter doc and zoom it .

The screen shots are explanatory.

Could you please  guide me step  wise  to resolve the Issue.
I am  completely new to Python.

Thanks
Regards

Jai Prakash
7975839735


From bc at freeuk.com  Thu May 17 07:58:43 2018
From: bc at freeuk.com (bartc)
Date: Thu, 17 May 2018 12:58:43 +0100
Subject: what does := means simply?
In-Reply-To: <mailman.130.1526529433.2761.python-list@python.org>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
Message-ID: <O7eLC.226881$Pv4.24578@fx23.am4>

On 17/05/2018 04:54, Steven D'Aprano wrote:
> On Thu, 17 May 2018 05:33:38 +0400, Abdur-Rahmaan Janhangeer wrote:
> 
>> what does := proposes to do?

> A simple example (not necessarily a GOOD example, but a SIMPLE one):
> 
> print(x := 100, x+1, x*2, x**3)

It's also not a good example because it assumes left-to-right evaluation 
order of the arguments. Even if Python guarantees that, it might be a 
problem if the code is ever ported anywhere else.

-- 
bartc


From p.f.moore at gmail.com  Thu May 17 08:07:12 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 17 May 2018 13:07:12 +0100
Subject: what does := means simply?
In-Reply-To: <O7eLC.226881$Pv4.24578@fx23.am4>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
Message-ID: <CACac1F9cugt73nRc5BSDJSRovuLkjR0bck_KdbJo4UvqnfRBzw@mail.gmail.com>

On 17 May 2018 at 12:58, bartc <bc at freeuk.com> wrote:
> On 17/05/2018 04:54, Steven D'Aprano wrote:
>>
>> On Thu, 17 May 2018 05:33:38 +0400, Abdur-Rahmaan Janhangeer wrote:
>>
>>> what does := proposes to do?
>
>> A simple example (not necessarily a GOOD example, but a SIMPLE one):
>>
>> print(x := 100, x+1, x*2, x**3)
>
>
> It's also not a good example because it assumes left-to-right evaluation
> order of the arguments. Even if Python guarantees that, it might be a
> problem if the code is ever ported anywhere else.

It's a good example, because it makes it clear that the benefits of :=
are at least in some cases, somewhat dependent on the fact that Python
evaluates arguments left to right :-)

Paul


From storchaka at gmail.com  Thu May 17 08:54:27 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Thu, 17 May 2018 15:54:27 +0300
Subject: what does := means simply?
In-Reply-To: <CACac1F9cugt73nRc5BSDJSRovuLkjR0bck_KdbJo4UvqnfRBzw@mail.gmail.com>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CACac1F9cugt73nRc5BSDJSRovuLkjR0bck_KdbJo4UvqnfRBzw@mail.gmail.com>
Message-ID: <pdjttv$je9$1@blaine.gmane.org>

17.05.18 15:07, Paul Moore ????:
> It's a good example, because it makes it clear that the benefits of :=
> are at least in some cases, somewhat dependent on the fact that Python
> evaluates arguments left to right :-)

Unless it evaluates them in other order.



From antoon.pardon at vub.be  Thu May 17 08:56:32 2018
From: antoon.pardon at vub.be (Antoon Pardon)
Date: Thu, 17 May 2018 14:56:32 +0200
Subject: what does := means simply?
In-Reply-To: <CAPTjJmo7sryJVHQv2k-PbzdgjCAuSCDP4o=6Zu9qmf3xoRfESg@mail.gmail.com>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <CAPTjJmo7sryJVHQv2k-PbzdgjCAuSCDP4o=6Zu9qmf3xoRfESg@mail.gmail.com>
Message-ID: <d46f5aa9-2b04-3014-2dbd-ab68ab94d152@vub.be>

On 17-05-18 03:44, Chris Angelico wrote:
> On Thu, May 17, 2018 at 11:33 AM, Abdur-Rahmaan Janhangeer
> <arj.python at gmail.com> wrote:
>> what does := proposes to do?
>>
>> pep572
>>
> If you read the PEP, you'll find an answer to your question.
>
> https://www.python.org/dev/peps/pep-0572/
>
> ChrisA

Just wondering, but in discussing this PEP has one considered
making the ';' into an expression too, with the value being
the value of the last expression?

I just ask because sometimes I have a loop that now often is written
as follows:

    while True:
        a = prepare_a()
        b = prepare_b()
        if not condition(a, b):
            break
        Do other stuff

Now with the := assignment it seems I will be able to write it like this:

    while [a := prepare_a(), b := prepare_b(), condition(a, b)][-1]:
        Do other stuff.


But IMO it would be nicer if it could be written as:

    while a := prepare_a(); b := prepare_b(); condition(a, b):
        Do other stuff

-- 
Antoon Pardon



From grant.b.edwards at gmail.com  Thu May 17 09:29:59 2018
From: grant.b.edwards at gmail.com (Grant Edwards)
Date: Thu, 17 May 2018 13:29:59 +0000 (UTC)
Subject: syntax oddities
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
Message-ID: <pdk04n$r9v$1@blaine.gmane.org>

On 2018-05-17, Abdur-Rahmaan Janhangeer <arj.python at gmail.com> wrote:

> just a remark that people help and discuss on more issues unrelated to
> python
[...]
> On Thu, 17 May 2018, 07:45 Steven D'Aprano, <
> steve+comp.lang.python at pearwood.info> wrote:
>> On Thu, 17 May 2018 05:25:44 +0400, Abdur-Rahmaan Janhangeer wrote:
>>

And one such popular issue is how top-posting is evil.

-- 
Grant Edwards               grant.b.edwards        Yow! Catsup and Mustard all
                                  at               over the place!  It's the
                              gmail.com            Human Hamburger!



From grant.b.edwards at gmail.com  Thu May 17 09:30:58 2018
From: grant.b.edwards at gmail.com (Grant Edwards)
Date: Thu, 17 May 2018 13:30:58 +0000 (UTC)
Subject: Python - requests - forms - web scraping - how to deal with
 multi stage forms
References: <8edbf5f6-ffc9-4c59-ac10-51324310583c@googlegroups.com>
Message-ID: <pdk06i$r9v$2@blaine.gmane.org>

On 2018-05-17, kret.ca at gmail.com <kret.ca at gmail.com> wrote:

> https://stackoverflow.com/questions/50383210/python-requests-how-to-post-few-stages-forms

Your point?

-- 
Grant Edwards               grant.b.edwards        Yow! I had pancake makeup
                                  at               for brunch!
                              gmail.com            



From steve+comp.lang.python at pearwood.info  Thu May 17 09:32:11 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Thu, 17 May 2018 13:32:11 +0000 (UTC)
Subject: what does := means simply?
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
Message-ID: <pdk08q$fka$6@blaine.gmane.org>

On Thu, 17 May 2018 12:58:43 +0100, bartc wrote:

> On 17/05/2018 04:54, Steven D'Aprano wrote:
>> On Thu, 17 May 2018 05:33:38 +0400, Abdur-Rahmaan Janhangeer wrote:
>> 
>>> what does := proposes to do?
> 
>> A simple example (not necessarily a GOOD example, but a SIMPLE one):
>> 
>> print(x := 100, x+1, x*2, x**3)
> 
> It's also not a good example because it assumes left-to-right evaluation
> order of the arguments. Even if Python guarantees that, it might be a
> problem if the code is ever ported anywhere else.

Seriously? You think we have a responsibility to write examples which 
will work with arbitrary languages with arbitrarily different evaluation 
order?

Okay, let's be clear:

- if the language has different evaluation order, it might not work;

- if the language has different syntax, it might not work;

- if the language has not variables or names, it might not work;

- if the language uses something other than decimal for numeric
  literals, it might not work;

- if the language doesn't use + * and ** for addition, multiplication
  and exponentiation, it might not work;

- if the language has no print, it might not work;

- if the language doesn't use ( ) for function calls, it might
  not work;

- or if the print function does something else, say, erases your 
  hard disk, you probably don't want to run that example;

- or if the language has no I/O, or no functions, it might not 
  do what you expect either;

- and if the language doesn't actually have a working interpreter
  or compiler for any existing computer, you may have trouble
  getting the code to run.


Did I miss any other problems?


-- 
Steve



From steve+comp.lang.python at pearwood.info  Thu May 17 09:34:28 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Thu, 17 May 2018 13:34:28 +0000 (UTC)
Subject: what does := means simply?
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <CAPTjJmo7sryJVHQv2k-PbzdgjCAuSCDP4o=6Zu9qmf3xoRfESg@mail.gmail.com>
 <d46f5aa9-2b04-3014-2dbd-ab68ab94d152@vub.be>
Message-ID: <pdk0d3$fka$7@blaine.gmane.org>

On Thu, 17 May 2018 14:56:32 +0200, Antoon Pardon wrote:

> On 17-05-18 03:44, Chris Angelico wrote:

>> https://www.python.org/dev/peps/pep-0572/

> Just wondering, but in discussing this PEP has one considered making the
> ';' into an expression too, with the value being the value of the last
> expression?

I'm not going to answer for Chris, the PEP author, but if I were the PEP 
author I'd say "No, but you can write your own competing PEP".



-- 
Steve



From steve+comp.lang.python at pearwood.info  Thu May 17 09:36:01 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Thu, 17 May 2018 13:36:01 +0000 (UTC)
Subject: what does := means simply?
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CACac1F9cugt73nRc5BSDJSRovuLkjR0bck_KdbJo4UvqnfRBzw@mail.gmail.com>
 <pdjttv$je9$1@blaine.gmane.org>
Message-ID: <pdk0g1$fka$8@blaine.gmane.org>

On Thu, 17 May 2018 15:54:27 +0300, Serhiy Storchaka wrote:

> 17.05.18 15:07, Paul Moore ????:
>> It's a good example, because it makes it clear that the benefits of :=
>> are at least in some cases, somewhat dependent on the fact that Python
>> evaluates arguments left to right :-)
> 
> Unless it evaluates them in other order.

I don't think it does though, does it?

I know there are a few expressions that evaluate out of left-to-right 
order. But I think positional arguments are always evaluated left-to-
right.


-- 
Steve



From marko at pacujo.net  Thu May 17 09:39:46 2018
From: marko at pacujo.net (Marko Rauhamaa)
Date: Thu, 17 May 2018 16:39:46 +0300
Subject: what does := means simply?
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <CAPTjJmo7sryJVHQv2k-PbzdgjCAuSCDP4o=6Zu9qmf3xoRfESg@mail.gmail.com>
 <d46f5aa9-2b04-3014-2dbd-ab68ab94d152@vub.be>
 <mailman.143.1526561864.2761.python-list@python.org>
Message-ID: <87lgcijt99.fsf@elektro.pacujo.net>

Antoon Pardon <antoon.pardon at vub.be>:

> On 17-05-18 03:44, Chris Angelico wrote:
> I just ask because sometimes I have a loop that now often is written
> as follows:
>
>     while True:
>         a = prepare_a()
>         b = prepare_b()
>         if not condition(a, b):
>             break
>         Do other stuff
>
> Now with the := assignment it seems I will be able to write it like this:
>
>     while [a := prepare_a(), b := prepare_b(), condition(a, b)][-1]:
>         Do other stuff.
>
>
> But IMO it would be nicer if it could be written as:
>
>     while a := prepare_a(); b := prepare_b(); condition(a, b):
>         Do other stuff

I know you must be joking but...

   while condition(a := prepare_a(), b := prepare_b()):
       Do other stuff.


Marko


From rosuav at gmail.com  Thu May 17 10:03:17 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 18 May 2018 00:03:17 +1000
Subject: what does := means simply?
In-Reply-To: <pdk0d3$fka$7@blaine.gmane.org>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <CAPTjJmo7sryJVHQv2k-PbzdgjCAuSCDP4o=6Zu9qmf3xoRfESg@mail.gmail.com>
 <d46f5aa9-2b04-3014-2dbd-ab68ab94d152@vub.be> <pdk0d3$fka$7@blaine.gmane.org>
Message-ID: <CAPTjJmrF36T6Ti=T1yV1ZSba_=XBwOMu5fRhwWZNbo68jzTetQ@mail.gmail.com>

On Thu, May 17, 2018 at 11:34 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Thu, 17 May 2018 14:56:32 +0200, Antoon Pardon wrote:
>
>> On 17-05-18 03:44, Chris Angelico wrote:
>
>>> https://www.python.org/dev/peps/pep-0572/
>
>> Just wondering, but in discussing this PEP has one considered making the
>> ';' into an expression too, with the value being the value of the last
>> expression?
>
> I'm not going to answer for Chris, the PEP author, but if I were the PEP
> author I'd say "No, but you can write your own competing PEP".
>

Yep. Or just "you're welcome to propose an unrelated feature".

ChrisA


From rosuav at gmail.com  Thu May 17 10:03:51 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 18 May 2018 00:03:51 +1000
Subject: what does := means simply?
In-Reply-To: <O7eLC.226881$Pv4.24578@fx23.am4>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
Message-ID: <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>

On Thu, May 17, 2018 at 9:58 PM, bartc <bc at freeuk.com> wrote:
> On 17/05/2018 04:54, Steven D'Aprano wrote:
>>
>> On Thu, 17 May 2018 05:33:38 +0400, Abdur-Rahmaan Janhangeer wrote:
>>
>>> what does := proposes to do?
>
>
>> A simple example (not necessarily a GOOD example, but a SIMPLE one):
>>
>> print(x := 100, x+1, x*2, x**3)
>
>
> It's also not a good example because it assumes left-to-right evaluation
> order of the arguments. Even if Python guarantees that, it might be a
> problem if the code is ever ported anywhere else.
>

Python DOES guarantee it, and nobody cares about your personal toy
language other than you. :)

ChrisA


From steve+comp.lang.python at pearwood.info  Thu May 17 10:13:06 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Thu, 17 May 2018 14:13:06 +0000 (UTC)
Subject: Request for comments: use-cases for delayed evaluation
Message-ID: <pdk2lh$fka$9@blaine.gmane.org>

Suppose Python had a mechanism to delay the evaluation of expressions 
until needed. What would you use it for?

Python already does this on an ad hoc basis. For example, the "and" and 
"or" operators are special:

    <left expression> and <right expression>

If the expression on the left is falsey, the expression on the right is 
ignored and not evaluated. Similarly for "or":

    <left expression> or <right expression>

only evaluates the expression on the right if the one on the left is 
falsey.

Similarly for ternary if.

But apart from these few ad hoc examples of short-circuiting behaviour, 
we don't really have an convenient way to do the same in our code. But 
what if we did? I can think of four places where I would like to delay 
the evaluation of expressions:

1. Late binding of function parameter defaults.

Given a function with defaults:

    def function(arg=DEFAULT)

Python's standard behaviour is to evaluate DEFAULT *once*, then always 
return the same value. Sometimes we want the default to be re-evaluated 
each time the function is called without an argument.


2. Printing of individual expressions, not just their value, within a 
line of code.

Sometimes I have a line of code where I'm not sure if a particular sub-
expression is correct. Of course I can refactor the code, but a 
lightweight solution would be to just insert a print:

    result = spam + eggs + print(EXPRESSION) +  cheese

Alas, this doesn't work: print doesn't return anything useful (it returns 
None), and the expression is evaluated before print can see it. But a 
simple helper function could solve this problem:

    # pseudo-code
    def debugprint(EXPRESSION):
        value = (evaluate EXPRESSION)
        print(EXPRESSION AS A STRING, value)
        return value



3. Assertions, similar to the "assert" statement, which don't evaluate 
the (potentially expensive) expression unless a flag is switched on:

    # pseudo-code
    def myassert(EXPRESSION, flag=None):
        if flag is None:
            flag = DEBUGGING
        if flag and not (evaluate EXPRESSION):
            s = EXPRESSION as a string
            raise AssertionError('assertion "%s" failed' % s)



4. Similarly, delaying the evaluation of expressions for logging:

    log.debug(str(sum(primes_below(10**10)))

has to calculate a huge number of prime numbers, and sum them, even if 
the log level is above DEBUG and the result won't be logged.


Of course I realise that every one of these have work-arounds or 
alternate solutions, some of which work quite well, some of which not so 
well. That's not my question.

My question is, if we had a way to delay the evaluation of expressions, 
what if anything would you use it for?

Use-cases beyond the four above are especially welcome.



-- 
Steve



From toby at tobiah.org  Thu May 17 10:18:32 2018
From: toby at tobiah.org (Tobiah)
Date: Thu, 17 May 2018 07:18:32 -0700
Subject: syntax oddities
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
Message-ID: <pdk2vn$1ukl$1@gioia.aioe.org>

Top posting is awesome for the reader plowing through
a thread in order.  In that case the cruft at the bottom
is only for occasional reference.

Ok, I yield!  I know the bottom-posting party has congress
right now.

On 05/17/2018 06:29 AM, Grant Edwards wrote:
> On 2018-05-17, Abdur-Rahmaan Janhangeer <arj.python at gmail.com> wrote:
> 
>> just a remark that people help and discuss on more issues unrelated to
>> python
> [...]
>> On Thu, 17 May 2018, 07:45 Steven D'Aprano, <
>> steve+comp.lang.python at pearwood.info> wrote:
>>> On Thu, 17 May 2018 05:25:44 +0400, Abdur-Rahmaan Janhangeer wrote:
>>>
> 
> And one such popular issue is how top-posting is evil.
> 



From toby at tobiah.org  Thu May 17 10:20:57 2018
From: toby at tobiah.org (Tobiah)
Date: Thu, 17 May 2018 07:20:57 -0700
Subject: what does := means simply?
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
Message-ID: <pdk348$1ukl$2@gioia.aioe.org>

On 05/16/2018 08:54 PM, Steven D'Aprano wrote:
> On Thu, 17 May 2018 05:33:38 +0400, Abdur-Rahmaan Janhangeer wrote:
> 
>> what does := proposes to do?
> 
> Simply, it proposes to add a new operator := for assignment (or binding)
> as an expression, as an addition to the = assignment operator which
> operates only as a statement. The syntax is:
> 
>      name := expression
> 
> and the meaning is:
> 
> 1. evaluate <expression>
> 
> 2. assign that value to <name>
> 
> 3. return that same value as the result

Well, that would be a welcome addition!




From bc at freeuk.com  Thu May 17 10:30:29 2018
From: bc at freeuk.com (bartc)
Date: Thu, 17 May 2018 15:30:29 +0100
Subject: what does := means simply?
In-Reply-To: <mailman.145.1526564077.2761.python-list@python.org>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4> <pdk08q$fka$6@blaine.gmane.org>
 <mailman.145.1526564077.2761.python-list@python.org>
Message-ID: <4mgLC.227580$pC1.1911@fx07.am4>

On 17/05/2018 14:32, Steven D'Aprano wrote:
> On Thu, 17 May 2018 12:58:43 +0100, bartc wrote:
> 
>> On 17/05/2018 04:54, Steven D'Aprano wrote:
>>> On Thu, 17 May 2018 05:33:38 +0400, Abdur-Rahmaan Janhangeer wrote:
>>>
>>>> what does := proposes to do?
>>
>>> A simple example (not necessarily a GOOD example, but a SIMPLE one):
>>>
>>> print(x := 100, x+1, x*2, x**3)
>>
>> It's also not a good example because it assumes left-to-right evaluation
>> order of the arguments. Even if Python guarantees that, it might be a
>> problem if the code is ever ported anywhere else.
> 
> Seriously? You think we have a responsibility to write examples which
> will work with arbitrary languages with arbitrarily different evaluation
> order?
> 
> Okay, let's be clear:
> 
> - if the language has different evaluation order, it might not work;

That's right. The rest of your list either doesn't matter so much or is 
only remotely likely.

Doing a certain amount of restructuring of an algorithm expressed in one 
language in order to port it to another is expected. But relying on 
evaluation order is bad form. Suppose this bit of code was imported from 
elsewhere where evaluation was right to left?

Anyway, try this:

     def showarg(x): print(x)

     def dummy(*args,**kwargs): pass

     dummy(a=showarg(1),*[showarg(2),showarg(3)])

This displays 2,3,1 showing that evaluation is not left to right.


-- 
bartc


From tallpaul at gmail.com  Thu May 17 10:31:27 2018
From: tallpaul at gmail.com (Paul)
Date: Thu, 17 May 2018 07:31:27 -0700
Subject: syntax oddities
In-Reply-To: <pdk2vn$1ukl$1@gioia.aioe.org>
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org>
Message-ID: <CA+og5uqt+R0w5=2jfw7H-9kHA=vGS15rUNXcwGkr_jSj1aMcUg@mail.gmail.com>

Top posting saves a huge amount of useless scrolling time.  Is it frowned
upon on this list?

On Thu, May 17, 2018, 7:26 AM Tobiah <toby at tobiah.org> wrote:

> Top posting is awesome for the reader plowing through
> a thread in order.  In that case the cruft at the bottom
> is only for occasional reference.
>
> Ok, I yield!  I know the bottom-posting party has congress
> right now.
>
> On 05/17/2018 06:29 AM, Grant Edwards wrote:
> > On 2018-05-17, Abdur-Rahmaan Janhangeer <arj.python at gmail.com> wrote:
> >
> >> just a remark that people help and discuss on more issues unrelated to
> >> python
> > [...]
> >> On Thu, 17 May 2018, 07:45 Steven D'Aprano, <
> >> steve+comp.lang.python at pearwood.info> wrote:
> >>> On Thu, 17 May 2018 05:25:44 +0400, Abdur-Rahmaan Janhangeer wrote:
> >>>
> >
> > And one such popular issue is how top-posting is evil.
> >
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>


From rosuav at gmail.com  Thu May 17 10:35:59 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 18 May 2018 00:35:59 +1000
Subject: syntax oddities
In-Reply-To: <CA+og5uqt+R0w5=2jfw7H-9kHA=vGS15rUNXcwGkr_jSj1aMcUg@mail.gmail.com>
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org>
 <CA+og5uqt+R0w5=2jfw7H-9kHA=vGS15rUNXcwGkr_jSj1aMcUg@mail.gmail.com>
Message-ID: <CAPTjJmq3CNLOL2WisScptnFyPbgoYW4RLhLDx5MryQ3kGHXYow@mail.gmail.com>

On Fri, May 18, 2018 at 12:31 AM, Paul <tallpaul at gmail.com> wrote:
> Top posting saves a huge amount of useless scrolling time.  Is it frowned
> upon on this list?

Trimming your replies saves even more. Yes, it is.

ChrisA


From tallpaul at gmail.com  Thu May 17 10:48:17 2018
From: tallpaul at gmail.com (Paul)
Date: Thu, 17 May 2018 07:48:17 -0700
Subject: syntax oddities
In-Reply-To: <CAPTjJmq3CNLOL2WisScptnFyPbgoYW4RLhLDx5MryQ3kGHXYow@mail.gmail.com>
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org>
 <CA+og5uqt+R0w5=2jfw7H-9kHA=vGS15rUNXcwGkr_jSj1aMcUg@mail.gmail.com>
 <CAPTjJmq3CNLOL2WisScptnFyPbgoYW4RLhLDx5MryQ3kGHXYow@mail.gmail.com>
Message-ID: <CA+og5uqO==SqWXyEP301fY1W2zhKcf=7zqDxfjKQ0rcb-8Oqvw@mail.gmail.com>

<tallpaul at gmail.com> wrote:

> > Is it frowned
> > upon on this list?
>
> Trimming your replies saves even more. Yes, it is.
>
> ChrisA
> -
>

kk.
Thanks
 Paul

>
>


From bc at freeuk.com  Thu May 17 10:50:17 2018
From: bc at freeuk.com (bartc)
Date: Thu, 17 May 2018 15:50:17 +0100
Subject: what does := means simply?
In-Reply-To: <mailman.150.1526565834.2761.python-list@python.org>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
Message-ID: <EEgLC.382764$gE6.296392@fx06.am4>

On 17/05/2018 15:03, Chris Angelico wrote:
> On Thu, May 17, 2018 at 9:58 PM, bartc <bc at freeuk.com> wrote:
>> On 17/05/2018 04:54, Steven D'Aprano wrote:
>>>
>>> On Thu, 17 May 2018 05:33:38 +0400, Abdur-Rahmaan Janhangeer wrote:
>>>
>>>> what does := proposes to do?
>>
>>
>>> A simple example (not necessarily a GOOD example, but a SIMPLE one):
>>>
>>> print(x := 100, x+1, x*2, x**3)
>>
>>
>> It's also not a good example because it assumes left-to-right evaluation
>> order of the arguments. Even if Python guarantees that, it might be a
>> problem if the code is ever ported anywhere else.
>>
> 
> Python DOES guarantee it, and nobody cares about your personal toy
> language other than you. :)

As I said, it's poor form.

Of course, full-on Python code is pretty much impossible to port 
anywhere else anyway.

-- 
bartc


From marko at pacujo.net  Thu May 17 10:50:22 2018
From: marko at pacujo.net (Marko Rauhamaa)
Date: Thu, 17 May 2018 17:50:22 +0300
Subject: what does := means simply?
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4> <pdk08q$fka$6@blaine.gmane.org>
 <mailman.145.1526564077.2761.python-list@python.org>
 <4mgLC.227580$pC1.1911@fx07.am4>
Message-ID: <87efiajpzl.fsf@elektro.pacujo.net>

bartc <bc at freeuk.com>:
> Anyway, try this:
>
>     def showarg(x): print(x)
>
>     def dummy(*args,**kwargs): pass
>
>     dummy(a=showarg(1),*[showarg(2),showarg(3)])
>
> This displays 2,3,1 showing that evaluation is not left to right.

Nice one!


Marko


From ned at nedbatchelder.com  Thu May 17 10:55:29 2018
From: ned at nedbatchelder.com (Ned Batchelder)
Date: Thu, 17 May 2018 10:55:29 -0400
Subject: why does list's .remove() does not return an object?
In-Reply-To: <CADrxXXn_DQatgBYW+DS5oz9EXYO_fn0ByQRQSFhJ_UpEdQ3y9g@mail.gmail.com>
References: <CADrxXXmrvyfCJmFa92O01TKBfh1o1toxFu7jZCyfjAMgpehMVg@mail.gmail.com>
 <57b25718-46e0-cca0-aa4d-a1209e9cafee@nedbatchelder.com>
 <CADrxXXn_DQatgBYW+DS5oz9EXYO_fn0ByQRQSFhJ_UpEdQ3y9g@mail.gmail.com>
Message-ID: <2c6e4639-ce25-026b-5963-90c8e2888747@nedbatchelder.com>

On 5/17/18 4:23 AM, Abdur-Rahmaan Janhangeer wrote:
> if then a more convenient way might be found to naturally remove and 
> return the list
>
> maybe it was not included as one might want to remove the list only
>
> x = [1]
> x.remove(1)
>
> as opposed to
>
> x = [1]
> x.remove(1)
> new_list = x
>
> i was looking for like
>
> x = [1]
> x.remove(1).return()

I don't understand what this would return? x? You already have x. Is it 
meant to make a copy? x has been mutated, so I don't understand the 
benefit of making a copy of the 1-less x.? Can you elaborate on the 
problem you are trying to solve?

--Ned.

(PS: bottom-posting (adding your response below the text you are 
responding to) will make the conversation easier to follow...)

>
> ps. list is was demo illustrative var
>
> Abdur-Rahmaan Janhangeer
> https://github.com/Abdur-rahmaanJ
>
> On Thu, 17 May 2018, 07:01 Ned Batchelder, <ned at nedbatchelder.com 
> <mailto:ned at nedbatchelder.com>> wrote:
>
>     On 5/16/18 10:41 PM, Abdur-Rahmaan Janhangeer wrote:
>     > why is x = list.remove(elem) not return the list?
>     >
>     >
>     Methods in Python usually do one of two things: 1) mutate the
>     object and
>     return None; or 2) leave the object alone and return a new
>     object.? This
>     helps make it clear which methods mutate and which don't. Since
>     .remove
>     mutates the list, it returns None.
>
>     --Ned.
>     -- 
>     https://mail.python.org/mailman/listinfo/python-list
>



From rshepard at appl-ecosys.com  Thu May 17 10:56:41 2018
From: rshepard at appl-ecosys.com (Rich Shepard)
Date: Thu, 17 May 2018 07:56:41 -0700 (PDT)
Subject: syntax oddities
In-Reply-To: <CAPTjJmq3CNLOL2WisScptnFyPbgoYW4RLhLDx5MryQ3kGHXYow@mail.gmail.com>
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org>
 <CA+og5uqt+R0w5=2jfw7H-9kHA=vGS15rUNXcwGkr_jSj1aMcUg@mail.gmail.com>
 <CAPTjJmq3CNLOL2WisScptnFyPbgoYW4RLhLDx5MryQ3kGHXYow@mail.gmail.com>
Message-ID: <alpine.LNX.2.20.1805170751540.11458@salmo.appl-ecosys.com>

On Fri, 18 May 2018, Chris Angelico wrote:

>> Top posting saves a huge amount of useless scrolling time.  Is it frowned
>> upon on this list?
>
> Trimming your replies saves even more. Yes, it is.

   Allow me to add an additional reason for trimming and responding beneath
each quoted section: it puts the response in the proper context.

   People who top-post require the reader to scroll up and down to fit the
response to the original message. Might as well just send a response without
the original message and elimiate all scrolling ... as well as the context
of the thread.

   When we respond to a received message (mail list or direct) we want the
reader to understand what we write. Trimming away all but the pieces to
which we respond makes communication more clear and, we hope, more
effective.

Regards,

Rich


From rosuav at gmail.com  Thu May 17 11:06:55 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 18 May 2018 01:06:55 +1000
Subject: what does := means simply?
In-Reply-To: <4mgLC.227580$pC1.1911@fx07.am4>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4> <pdk08q$fka$6@blaine.gmane.org>
 <mailman.145.1526564077.2761.python-list@python.org>
 <4mgLC.227580$pC1.1911@fx07.am4>
Message-ID: <CAPTjJmowMq7qdvxj0Gt2OtwEq5QJ4Kr1-TYvi2GuktTjFqn4Lg@mail.gmail.com>

On Fri, May 18, 2018 at 12:30 AM, bartc <bc at freeuk.com> wrote:
> Anyway, try this:
>
>     def showarg(x): print(x)
>
>     def dummy(*args,**kwargs): pass
>
>     dummy(a=showarg(1),*[showarg(2),showarg(3)])
>
> This displays 2,3,1 showing that evaluation is not left to right.
>

Keyword args are evaluated after positional args. It's a bad idea to
put positional after keyword; you risk mis-identifying your args:

>>> def dummy(a, b, c): pass
...
>>> dummy(a=showarg(1),*[showarg(2),showarg(3)])
2
3
1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: dummy() got multiple values for argument 'a'

Evaluation is not always left to right, but it is always well-defined.

ChrisA


From arj.python at gmail.com  Thu May 17 11:26:28 2018
From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer)
Date: Thu, 17 May 2018 19:26:28 +0400
Subject: why does list's .remove() does not return an object?
In-Reply-To: <2c6e4639-ce25-026b-5963-90c8e2888747@nedbatchelder.com>
References: <CADrxXXmrvyfCJmFa92O01TKBfh1o1toxFu7jZCyfjAMgpehMVg@mail.gmail.com>
 <57b25718-46e0-cca0-aa4d-a1209e9cafee@nedbatchelder.com>
 <CADrxXXn_DQatgBYW+DS5oz9EXYO_fn0ByQRQSFhJ_UpEdQ3y9g@mail.gmail.com>
 <2c6e4639-ce25-026b-5963-90c8e2888747@nedbatchelder.com>
Message-ID: <CADrxXX==e330Fav84eCFwU2EUE6gUyaGKOaguCVs-1W7+uyq=w@mail.gmail.com>

On Thu, 17 May 2018, 18:55 Ned Batchelder, <ned at nedbatchelder.com> wrote:

> On 5/17/18 4:23 AM, Abdur-Rahmaan Janhangeer wrote:
>
> if then a more convenient way might be found to naturally remove and
> return the list
>
> maybe it was not included as one might want to remove the list only
>
> x = [1]
> x.remove(1)
>
> as opposed to
>
> x = [1]
> x.remove(1)
> new_list = x
>
> i was looking for like
>
> x = [1]
> x.remove(1).return()
>
>
> I don't understand what this would return? x? You already have x.  Is it
> meant to make a copy? x has been mutated, so I don't understand the benefit
> of making a copy of the 1-less x.  Can you elaborate on the problem you are
> trying to solve?
>
> --Ned.
>
>
assignment to another var

>
>


From ian.g.kelly at gmail.com  Thu May 17 11:27:46 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Thu, 17 May 2018 09:27:46 -0600
Subject: what does := means simply?
In-Reply-To: <CAPTjJmowMq7qdvxj0Gt2OtwEq5QJ4Kr1-TYvi2GuktTjFqn4Lg@mail.gmail.com>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4> <pdk08q$fka$6@blaine.gmane.org>
 <mailman.145.1526564077.2761.python-list@python.org>
 <4mgLC.227580$pC1.1911@fx07.am4>
 <CAPTjJmowMq7qdvxj0Gt2OtwEq5QJ4Kr1-TYvi2GuktTjFqn4Lg@mail.gmail.com>
Message-ID: <CALwzidmKbpmUuqp=93_+bNhKB3Zdhky6Z9ukqQOWOMs4O9PtsA@mail.gmail.com>

On Thu, May 17, 2018 at 9:06 AM, Chris Angelico <rosuav at gmail.com> wrote:
> On Fri, May 18, 2018 at 12:30 AM, bartc <bc at freeuk.com> wrote:
>> Anyway, try this:
>>
>>     def showarg(x): print(x)
>>
>>     def dummy(*args,**kwargs): pass
>>
>>     dummy(a=showarg(1),*[showarg(2),showarg(3)])
>>
>> This displays 2,3,1 showing that evaluation is not left to right.
>>
>
> Keyword args are evaluated after positional args. It's a bad idea to
> put positional after keyword; you risk mis-identifying your args:
>
>>>> def dummy(a, b, c): pass
> ...
>>>> dummy(a=showarg(1),*[showarg(2),showarg(3)])
> 2
> 3
> 1
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: dummy() got multiple values for argument 'a'
>
> Evaluation is not always left to right, but it is always well-defined.

I wasn't actually aware it was allowed to place keyword args before
positional args; this must be relatively new in Python 3.

This raises a new issue for me w.r.t. PEP 572. The spelling of :=
makes it unlikely to accidentally use in place of ==, but what about
:= and = confusion? For example, say I mean to write this:

    foo(a := 42, b, c)

but accidentally write this instead:

    foo(a = 42, b, c)

Hopefully for many functions this would just be a TypeError
("unexpected keyword argument"). At the same time, it's a fairly
common practice to pass a variable to a function that happens to have
the same name as the argument being passed. Has there been any
discussion of whether this is likely to be a source of confusion?


From rosuav at gmail.com  Thu May 17 11:37:48 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 18 May 2018 01:37:48 +1000
Subject: what does := means simply?
In-Reply-To: <CALwzidmKbpmUuqp=93_+bNhKB3Zdhky6Z9ukqQOWOMs4O9PtsA@mail.gmail.com>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4> <pdk08q$fka$6@blaine.gmane.org>
 <mailman.145.1526564077.2761.python-list@python.org>
 <4mgLC.227580$pC1.1911@fx07.am4>
 <CAPTjJmowMq7qdvxj0Gt2OtwEq5QJ4Kr1-TYvi2GuktTjFqn4Lg@mail.gmail.com>
 <CALwzidmKbpmUuqp=93_+bNhKB3Zdhky6Z9ukqQOWOMs4O9PtsA@mail.gmail.com>
Message-ID: <CAPTjJmp3Su_AsyZQdNL1e_TaxqrQsSrpJN8H_j8Gt9XNE5BM5g@mail.gmail.com>

On Fri, May 18, 2018 at 1:27 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> This raises a new issue for me w.r.t. PEP 572. The spelling of :=
> makes it unlikely to accidentally use in place of ==, but what about
> := and = confusion? For example, say I mean to write this:
>
>     foo(a := 42, b, c)
>
> but accidentally write this instead:
>
>     foo(a = 42, b, c)
>
> Hopefully for many functions this would just be a TypeError
> ("unexpected keyword argument"). At the same time, it's a fairly
> common practice to pass a variable to a function that happens to have
> the same name as the argument being passed. Has there been any
> discussion of whether this is likely to be a source of confusion?

There has been. The value of it is too great to disallow it, and most
style guides would recommend writing the keyword argument with no
spaces around the equals sign, so there's a bit of a chance to catch
the bug that way. But you're right that it is a potential bug.

ChrisA


From abrault at mapgears.com  Thu May 17 11:48:22 2018
From: abrault at mapgears.com (Alexandre Brault)
Date: Thu, 17 May 2018 11:48:22 -0400
Subject: why does list's .remove() does not return an object?
In-Reply-To: <CADrxXX==e330Fav84eCFwU2EUE6gUyaGKOaguCVs-1W7+uyq=w@mail.gmail.com>
References: <CADrxXXmrvyfCJmFa92O01TKBfh1o1toxFu7jZCyfjAMgpehMVg@mail.gmail.com>
 <57b25718-46e0-cca0-aa4d-a1209e9cafee@nedbatchelder.com>
 <CADrxXXn_DQatgBYW+DS5oz9EXYO_fn0ByQRQSFhJ_UpEdQ3y9g@mail.gmail.com>
 <2c6e4639-ce25-026b-5963-90c8e2888747@nedbatchelder.com>
 <CADrxXX==e330Fav84eCFwU2EUE6gUyaGKOaguCVs-1W7+uyq=w@mail.gmail.com>
Message-ID: <9f86d58c-f95f-31c0-3b79-dba75e3b49dc@mapgears.com>


On 2018-05-17 11:26 AM, Abdur-Rahmaan Janhangeer wrote:
> I don't understand what this would return? x? You already have x.  Is it
> meant to make a copy? x has been mutated, so I don't understand the benefit
> of making a copy of the 1-less x.  Can you elaborate on the problem you are
> trying to solve?
>
> --Ned.
>
>
> assignment to another var
>
You already have access to the list before removal, the list after
removal and the element to be removed.

Do need a copy of the list before removing x?
>>> old_list = list[:]
>>> list.remove(x)

Do you need the list after removing x?
>>> list.remove(x)? # list is the modified list

Do you need x?
>>> list.remove(x)? # x is x

What else would need to be assigned to another var?


From arj.python at gmail.com  Thu May 17 11:57:31 2018
From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer)
Date: Thu, 17 May 2018 19:57:31 +0400
Subject: why does list's .remove() does not return an object?
In-Reply-To: <9f86d58c-f95f-31c0-3b79-dba75e3b49dc@mapgears.com>
References: <CADrxXXmrvyfCJmFa92O01TKBfh1o1toxFu7jZCyfjAMgpehMVg@mail.gmail.com>
 <57b25718-46e0-cca0-aa4d-a1209e9cafee@nedbatchelder.com>
 <CADrxXXn_DQatgBYW+DS5oz9EXYO_fn0ByQRQSFhJ_UpEdQ3y9g@mail.gmail.com>
 <2c6e4639-ce25-026b-5963-90c8e2888747@nedbatchelder.com>
 <CADrxXX==e330Fav84eCFwU2EUE6gUyaGKOaguCVs-1W7+uyq=w@mail.gmail.com>
 <9f86d58c-f95f-31c0-3b79-dba75e3b49dc@mapgears.com>
Message-ID: <CADrxXXnaWr1JHZpoayeqKB5qsvx_fp0uwF6H1FsM8Yn88HO5hw@mail.gmail.com>

x = [0,1]
x.remove(0)
new_list = x

instead i want in one go

x = [0,1]
new_list = x.remove(0) # here a way for it to return the modified list by
adding a .return() maybe ?

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

On Thu, 17 May 2018, 19:54 Alexandre Brault, <abrault at mapgears.com> wrote:

>
> On 2018-05-17 11:26 AM, Abdur-Rahmaan Janhangeer wrote:
> > I don't understand what this would return? x? You already have x.  Is it
> > meant to make a copy? x has been mutated, so I don't understand the
> benefit
> > of making a copy of the 1-less x.  Can you elaborate on the problem you
> are
> > trying to solve?
> >
> > --Ned.
> >
> >
> > assignment to another var
> >
> You already have access to the list before removal, the list after
> removal and the element to be removed.
>
> Do need a copy of the list before removing x?
> >>> old_list = list[:]
> >>> list.remove(x)
>
> Do you need the list after removing x?
> >>> list.remove(x)  # list is the modified list
>
> Do you need x?
> >>> list.remove(x)  # x is x
>
> What else would need to be assigned to another var?
> --
> https://mail.python.org/mailman/listinfo/python-list
>


From D.Strohl at F5.com  Thu May 17 12:14:13 2018
From: D.Strohl at F5.com (Dan Strohl)
Date: Thu, 17 May 2018 16:14:13 +0000
Subject: Request for comments: use-cases for delayed evaluation
In-Reply-To: <pdk2lh$fka$9@blaine.gmane.org>
References: <pdk2lh$fka$9@blaine.gmane.org>
Message-ID: <b484c47921ab4624961196df8c9376a7@F5.com>



I could easily see using all of the examples;  I run into this pretty regularly.

What about something like the following (which, honestly is really a combination of other examples).

If I have a function that has multiple parameters, each of which might be expensive, but it might break out earlier depending on how each one is evaluated... for example:

(pretending that "$" is a flag that says "evaluate later", and $(arg) is how you say "evaluate now")

def combine_unless_none(*$args, sep=', '):
    """ if any arg evaluates to None, return '', otherwise join"""
    for arg in args:
        tmp_arg = $(arg)
        If tmp_arg is None:
            return "
    return sep.join(args)



From ned at nedbatchelder.com  Thu May 17 12:25:41 2018
From: ned at nedbatchelder.com (Ned Batchelder)
Date: Thu, 17 May 2018 12:25:41 -0400
Subject: why does list's .remove() does not return an object?
In-Reply-To: <CADrxXXnaWr1JHZpoayeqKB5qsvx_fp0uwF6H1FsM8Yn88HO5hw@mail.gmail.com>
References: <CADrxXXmrvyfCJmFa92O01TKBfh1o1toxFu7jZCyfjAMgpehMVg@mail.gmail.com>
 <57b25718-46e0-cca0-aa4d-a1209e9cafee@nedbatchelder.com>
 <CADrxXXn_DQatgBYW+DS5oz9EXYO_fn0ByQRQSFhJ_UpEdQ3y9g@mail.gmail.com>
 <2c6e4639-ce25-026b-5963-90c8e2888747@nedbatchelder.com>
 <CADrxXX==e330Fav84eCFwU2EUE6gUyaGKOaguCVs-1W7+uyq=w@mail.gmail.com>
 <9f86d58c-f95f-31c0-3b79-dba75e3b49dc@mapgears.com>
 <CADrxXXnaWr1JHZpoayeqKB5qsvx_fp0uwF6H1FsM8Yn88HO5hw@mail.gmail.com>
Message-ID: <dcc03962-1c1b-66f4-2736-25099d24b61c@nedbatchelder.com>

On 5/17/18 11:57 AM, Abdur-Rahmaan Janhangeer wrote:
> x = [0,1]
> x.remove(0)
> new_list = x
>
> instead i want in one go
>
> x = [0,1]
> new_list = x.remove(0) # here a way for it to return the modified list by
> adding a .return() maybe ?

There isn't a way to do that in one line.? I often find myself splitting 
long statements into more, shorter, statements to express myself more 
clearly.

I don't know if you have a real piece of code in mind, so I don't know 
if you can tell us:? why is it useful to have another variable referring 
to the same list?

--Ned.
>
> Abdur-Rahmaan Janhangeer
> https://github.com/Abdur-rahmaanJ
>
> On Thu, 17 May 2018, 19:54 Alexandre Brault, <abrault at mapgears.com> wrote:
>
>> On 2018-05-17 11:26 AM, Abdur-Rahmaan Janhangeer wrote:
>>> I don't understand what this would return? x? You already have x.  Is it
>>> meant to make a copy? x has been mutated, so I don't understand the
>> benefit
>>> of making a copy of the 1-less x.  Can you elaborate on the problem you
>> are
>>> trying to solve?
>>>
>>> --Ned.
>>>
>>>
>>> assignment to another var
>>>
>> You already have access to the list before removal, the list after
>> removal and the element to be removed.
>>
>> Do need a copy of the list before removing x?
>>>>> old_list = list[:]
>>>>> list.remove(x)
>> Do you need the list after removing x?
>>>>> list.remove(x)  # list is the modified list
>> Do you need x?
>>>>> list.remove(x)  # x is x
>> What else would need to be assigned to another var?
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>



From D.Strohl at F5.com  Thu May 17 12:28:05 2018
From: D.Strohl at F5.com (Dan Strohl)
Date: Thu, 17 May 2018 16:28:05 +0000
Subject: why does list's .remove() does not return an object?
In-Reply-To: <9f86d58c-f95f-31c0-3b79-dba75e3b49dc@mapgears.com>
References: <CADrxXXmrvyfCJmFa92O01TKBfh1o1toxFu7jZCyfjAMgpehMVg@mail.gmail.com>
 <57b25718-46e0-cca0-aa4d-a1209e9cafee@nedbatchelder.com>
 <CADrxXXn_DQatgBYW+DS5oz9EXYO_fn0ByQRQSFhJ_UpEdQ3y9g@mail.gmail.com>
 <2c6e4639-ce25-026b-5963-90c8e2888747@nedbatchelder.com>
 <CADrxXX==e330Fav84eCFwU2EUE6gUyaGKOaguCVs-1W7+uyq=w@mail.gmail.com>
 <9f86d58c-f95f-31c0-3b79-dba75e3b49dc@mapgears.com>
Message-ID: <df0d57b9632d46aa8f33d9d1c7f7bd94@F5.com>

On 2018-05-17 11:26 AM, Abdur-Rahmaan Janhangeer wrote:
> I don't understand what this would return? x? You already have x.  Is 
> it meant to make a copy? x has been mutated, so I don't understand the 
> benefit of making a copy of the 1-less x.  Can you elaborate on the 
> problem you are trying to solve?
>
> --Ned.
>
>
> assignment to another var
>

Though I don?t know what the OP was specifically looking for I could see a benefit to returning the item deleted.

So, lets take as an example I have an object like:

class ListItem(object):
    def __init__(self, key, data):
        self.key = key
        self.data = data
    def __eq__(other):
        return other == self.key

and I do something like:

i1 = ListItem('hello', 'foobar')
l2 = ListItem('goodby', 'snafu')

l = [i1, i2]

So, lets say I have a need where I want to do something like a remove, but I also want to be able to get the .data variable from the object I am removing, it would be nice to be able to simply do

x = l.remove('hello')
print(x.data)

Yes, I could do a index/pop to get this, or I could keep a separate dict of the objects as well for lookups, or a number of other techniques, but it would be easier to simply get it back during the remove().

Dan Strohl


From ned at nedbatchelder.com  Thu May 17 12:37:25 2018
From: ned at nedbatchelder.com (Ned Batchelder)
Date: Thu, 17 May 2018 12:37:25 -0400
Subject: why does list's .remove() does not return an object?
In-Reply-To: <df0d57b9632d46aa8f33d9d1c7f7bd94@F5.com>
References: <CADrxXXmrvyfCJmFa92O01TKBfh1o1toxFu7jZCyfjAMgpehMVg@mail.gmail.com>
 <57b25718-46e0-cca0-aa4d-a1209e9cafee@nedbatchelder.com>
 <CADrxXXn_DQatgBYW+DS5oz9EXYO_fn0ByQRQSFhJ_UpEdQ3y9g@mail.gmail.com>
 <2c6e4639-ce25-026b-5963-90c8e2888747@nedbatchelder.com>
 <CADrxXX==e330Fav84eCFwU2EUE6gUyaGKOaguCVs-1W7+uyq=w@mail.gmail.com>
 <9f86d58c-f95f-31c0-3b79-dba75e3b49dc@mapgears.com>
 <df0d57b9632d46aa8f33d9d1c7f7bd94@F5.com>
Message-ID: <55670513-08f5-79b2-566b-51e1654c4623@nedbatchelder.com>

On 5/17/18 12:28 PM, Dan Strohl via Python-list wrote:
> On 2018-05-17 11:26 AM, Abdur-Rahmaan Janhangeer wrote:
>> I don't understand what this would return? x? You already have x.  Is
>> it meant to make a copy? x has been mutated, so I don't understand the
>> benefit of making a copy of the 1-less x.  Can you elaborate on the
>> problem you are trying to solve?
>>
>> --Ned.
>>
>>
>> assignment to another var
>>
> Though I don?t know what the OP was specifically looking for I could see a benefit to returning the item deleted.

Notice that this is not the thing the OP wanted returned.? I believe 
they are looking to return the list, not the item.

--Ned.


From steve+comp.lang.python at pearwood.info  Thu May 17 13:19:40 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Thu, 17 May 2018 17:19:40 +0000 (UTC)
Subject: what does := means simply?
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4>
Message-ID: <pdkdjc$fka$10@blaine.gmane.org>

On Thu, 17 May 2018 15:50:17 +0100, bartc wrote:

> On 17/05/2018 15:03, Chris Angelico wrote:
>> On Thu, May 17, 2018 at 9:58 PM, bartc <bc at freeuk.com> wrote:
>>> On 17/05/2018 04:54, Steven D'Aprano wrote:
>>>>
>>>> On Thu, 17 May 2018 05:33:38 +0400, Abdur-Rahmaan Janhangeer wrote:
>>>>
>>>>> what does := proposes to do?
>>>
>>>
>>>> A simple example (not necessarily a GOOD example, but a SIMPLE one):
>>>>
>>>> print(x := 100, x+1, x*2, x**3)
>>>
>>>
>>> It's also not a good example because it assumes left-to-right
>>> evaluation order of the arguments. Even if Python guarantees that, it
>>> might be a problem if the code is ever ported anywhere else.
>>>
>>>
>> Python DOES guarantee it, and nobody cares about your personal toy
>> language other than you. :)
> 
> As I said, it's poor form.

"... to rely on a language's guaranteed features, because, well, for no 
reason really."


> Of course, full-on Python code is pretty much impossible to port
> anywhere else anyway.

*rolls eyes*

You know what "Turing Complete" means, don't you? Either:

- Python is the only Turing Complete programming language in the universe;

- Python is the only programming language in the universe which is
  strictly more powerful than a Turing Machine; or

- you're talking nonsense on stilts.


I know where I'd put my money.


Of course it may sometimes be tricky to mechanically port certain Python 
programs to languages which are less powerful (in the Blub sense). But 
this is nothing new: mechanically porting from one language to another is 
always fraught with problems, unless the languages are designed for that 
(e.g. Coffeescript and Javascript).

Any pair of languages will have code that is hard to port from one to the 
other without jumping through hoops. Try porting C code with lots of 
dynamic memory allocations and pointer accesses to COBOL, or Scheme code 
using continuations to Python, or Hyperscript text chunking code to 
Fortran.

But hard does not mean "pretty much impossible".




-- 
Steve



From steve+comp.lang.python at pearwood.info  Thu May 17 13:29:56 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Thu, 17 May 2018 17:29:56 +0000 (UTC)
Subject: what does := means simply?
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4> <pdk08q$fka$6@blaine.gmane.org>
 <mailman.145.1526564077.2761.python-list@python.org>
 <4mgLC.227580$pC1.1911@fx07.am4> <87efiajpzl.fsf@elektro.pacujo.net>
Message-ID: <pdke6k$fka$11@blaine.gmane.org>

On Thu, 17 May 2018 17:50:22 +0300, Marko Rauhamaa wrote:

> bartc <bc at freeuk.com>:
>> Anyway, try this:
>>
>>     def showarg(x): print(x)
>>
>>     def dummy(*args,**kwargs): pass
>>
>>     dummy(a=showarg(1),*[showarg(2),showarg(3)])
>>
>> This displays 2,3,1 showing that evaluation is not left to right.
> 
> Nice one!

I'm fairly sure that both you and Bart know full well I was talking about 
positional arguments. My example used only positional arguments, and my 
reply to Serhiy explicitly referenced positional arguments.

But don't bother responding to what I *actually* said, it's much more fun 
to attack a strawman, right?

And besides, Bart's "showarg" function is a waste of space: it could be 
simply replaced by print.

py> dummy(a=print(1), *[print(2), print(3)])
2
3
1

You want some more examples of non-left to right evaluation order?

Comprehensions.

Ternary if.

Are there any others? Could be. So what? The existence of odd corner 
cases in the language doesn't invalidate my example that doesn't go 
anywhere near those odd corners.


-- 
Steve



From steve+comp.lang.python at pearwood.info  Thu May 17 13:34:29 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Thu, 17 May 2018 17:34:29 +0000 (UTC)
Subject: what does := means simply?
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4>
Message-ID: <pdkef5$fka$12@blaine.gmane.org>

On Thu, 17 May 2018 15:50:17 +0100, bartc wrote:

> Of course, full-on Python code is pretty much impossible to port
> anywhere else anyway.

Oh, I forgot to mention... given that Python is frequently used to 
prototype applications before the production-ready application is written 
in C, C++ or Java, the idea that Python code (whether "full on" or 
otherwise) cannot be ported is especially silly.


-- 
Steve



From ben.usenet at bsb.me.uk  Thu May 17 13:39:36 2018
From: ben.usenet at bsb.me.uk (Ben Bacarisse)
Date: Thu, 17 May 2018 18:39:36 +0100
Subject: object types, mutable or not?
References: <mailman.27.1526227203.13745.python-list@python.org>
 <20180513200201.GA26725@playground>
 <53e09f9b-0da4-0ae0-3aff-b23029427474@Damon-Family.org>
 <20180515142939.GA5181@playground> <pdfrk2$unn$13@blaine.gmane.org>
 <85y3gkl74d.fsf@benfinney.id.au> <pdgjnn$fka$1@blaine.gmane.org>
 <85po1wkrph.fsf@benfinney.id.au> <pdgluq$fka$2@blaine.gmane.org>
 <8b1f93ef-88de-01d1-8f3a-799d88bc81b6@nedbatchelder.com>
 <CACac1F8OOUCu24Ve8eCbWWGfqbGrMx3F=M_3N8URnYdkaMWUTg@mail.gmail.com>
 <20180517111632.33904cdf@wegge.dk>
 <mailman.136.1526549116.2761.python-list@python.org>
Message-ID: <87muwygp0n.fsf@bsb.me.uk>

Anders Wegge Keller <wegge at wegge.dk> writes:

> P? Wed, 16 May 2018 14:48:27 +0100
> Paul Moore <p.f.moore at gmail.com> skrev:
>
>> C++ called that an "rvalue". And then went on to define things that
>> could go on the left hand side of an assignment as "lvalues". And now
>> we have two confusing concepts to explain - see what happens when you
>> let a standards committee define your language? :-)
>
>  I'm not sure the C++ committee has to bear the responsibility for those
> terms. They are pretty well defined in the C world, so I think you need to
> point the finger of accusation at either Brian or Dennis.

The terms are much older than that.  The first BCPL (1967) reference
manual uses the terms, and I don't think Martin Richards invented them.

(And C++ has added glvalue and prvalue to lvalue and rvalue.)

-- 
Ben.


From menyland at gmail.com  Thu May 17 13:40:14 2018
From: menyland at gmail.com (Chris Nyland)
Date: Thu, 17 May 2018 13:40:14 -0400
Subject: Package DLL or SO in wheel
Message-ID: <CALGOvYa3TO1ErtvFtqsEHCFJFSmP9Dm=XkwPThpMxffS35cNZA@mail.gmail.com>

Hello,

We have several internal modules we have developed that are used mostly to
read different types of data files. Most of the time the different data
file formats come with some sort of DLL or SO files that gives a standard
interface to read the files. Our design pattern is to create a python
library that uses ctypes to interface with the shared library.

To be clear we are not building the shared libraries these are usually
provided by another group or distributed by a  third party.

So the issue is I want to bundle these share libraries with the module into
a wheel or sdist package to server off our local PyPiServer. I have combed
though the documentation on the setup.py and setuptools and I cannot figure
out a simple way to do this. Currently we are just adding them as datafiles
but this means that the wheels are not named with a particular platform and
thus we need to bundle all the different possible shared libraries with it.

Additionally using the data files method always puts the share library in
the same directory as the Python source while this works I wasn't certain
if there is a more appropriate place for the libraries in the Python
installation.

So in summary:
1. How do I create a setup.py to bundle the appropriate share library into
a wheel for a given platform and name the wheel properly.
2. Where is the most appropriate spot to stick these shared libraries?

Most of our work is done in Windows but we have some modules that we use on
Linux as well. We have both 32 and 64 bit environments. We are currently
using Python 3.6.

Thanks

Chris


From rosuav at gmail.com  Thu May 17 13:44:25 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 18 May 2018 03:44:25 +1000
Subject: what does := means simply?
In-Reply-To: <pdkef5$fka$12@blaine.gmane.org>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkef5$fka$12@blaine.gmane.org>
Message-ID: <CAPTjJmr+_PYaM4YeUO+XyTM8MWACvLOipyfBAggDNiAwp5MV7g@mail.gmail.com>

On Fri, May 18, 2018 at 3:34 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Thu, 17 May 2018 15:50:17 +0100, bartc wrote:
>
>> Of course, full-on Python code is pretty much impossible to port
>> anywhere else anyway.
>
> Oh, I forgot to mention... given that Python is frequently used to
> prototype applications before the production-ready application is written
> in C, C++ or Java, the idea that Python code (whether "full on" or
> otherwise) cannot be ported is especially silly.
>

I'm morbidly curious as to what "half-on Python code" would look like.

ChrisA


From steve+comp.lang.python at pearwood.info  Thu May 17 13:48:38 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Thu, 17 May 2018 17:48:38 +0000 (UTC)
Subject: what does := means simply?
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkef5$fka$12@blaine.gmane.org>
 <CAPTjJmr+_PYaM4YeUO+XyTM8MWACvLOipyfBAggDNiAwp5MV7g@mail.gmail.com>
Message-ID: <pdkf9m$fka$13@blaine.gmane.org>

On Fri, 18 May 2018 03:44:25 +1000, Chris Angelico wrote:

> I'm morbidly curious as to what "half-on Python code" would look like.

Writing Java in Python. Or C in Python. Or Lisp in Python. Or ...


-- 
Steve



From rosuav at gmail.com  Thu May 17 13:55:23 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 18 May 2018 03:55:23 +1000
Subject: what does := means simply?
In-Reply-To: <pdkf9m$fka$13@blaine.gmane.org>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkef5$fka$12@blaine.gmane.org>
 <CAPTjJmr+_PYaM4YeUO+XyTM8MWACvLOipyfBAggDNiAwp5MV7g@mail.gmail.com>
 <pdkf9m$fka$13@blaine.gmane.org>
Message-ID: <CAPTjJmouHOuCDQKLQ2mYqXAx+Kgwe4EfrZ2SA6yKcEjseZJSuA@mail.gmail.com>

On Fri, May 18, 2018 at 3:48 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Fri, 18 May 2018 03:44:25 +1000, Chris Angelico wrote:
>
>> I'm morbidly curious as to what "half-on Python code" would look like.
>
> Writing Java in Python. Or C in Python. Or Lisp in Python. Or ...
>

Ah. I was wondering if this was more like "Python code written when
the programmer's brain was half-on" (which, for many, is any time
prior to the third cup of coffee).

Actually, probably not all that different, come to think of it.

ChrisA


From dstanek at dstanek.com  Thu May 17 15:29:56 2018
From: dstanek at dstanek.com (David Stanek)
Date: Thu, 17 May 2018 15:29:56 -0400
Subject: why does list's .remove() does not return an object?
In-Reply-To: <55670513-08f5-79b2-566b-51e1654c4623@nedbatchelder.com>
References: <CADrxXXmrvyfCJmFa92O01TKBfh1o1toxFu7jZCyfjAMgpehMVg@mail.gmail.com>
 <57b25718-46e0-cca0-aa4d-a1209e9cafee@nedbatchelder.com>
 <CADrxXXn_DQatgBYW+DS5oz9EXYO_fn0ByQRQSFhJ_UpEdQ3y9g@mail.gmail.com>
 <2c6e4639-ce25-026b-5963-90c8e2888747@nedbatchelder.com>
 <CADrxXX==e330Fav84eCFwU2EUE6gUyaGKOaguCVs-1W7+uyq=w@mail.gmail.com>
 <9f86d58c-f95f-31c0-3b79-dba75e3b49dc@mapgears.com>
 <df0d57b9632d46aa8f33d9d1c7f7bd94@F5.com>
 <55670513-08f5-79b2-566b-51e1654c4623@nedbatchelder.com>
Message-ID: <CAO69Nd=yG1tZ+PepALLBOS8Fv3ajfbGyStB6DGbNyjY9gx6MmQ@mail.gmail.com>

On 17-May-2018 12:37, Ned Batchelder wrote:
> On 5/17/18 12:28 PM, Dan Strohl via Python-list wrote:
> > On 2018-05-17 11:26 AM, Abdur-Rahmaan Janhangeer wrote:
> > > I don't understand what this would return? x? You already have x.  Is
> > > it meant to make a copy? x has been mutated, so I don't understand the
> > > benefit of making a copy of the 1-less x.  Can you elaborate on the
> > > problem you are trying to solve?
> > >
> > > --Ned.
> > >
> > >
> > > assignment to another var
> > >
> > Though I don?t know what the OP was specifically looking for I could see a benefit to returning the item deleted.
>
> Notice that this is not the thing the OP wanted returned.  I believe they
> are looking to return the list, not the item.
>

I'm guessing that they want to be able to do some sort of method
chaining like:

  the_list.remove(x).remove(y)

Although the clarifying example was contrived and confusing. A more
concrete example would be greatly appreciated.

-- 
david stanek
web: https://dstanek.com
twitter: https://twitter.com/dstanek


From toby at tobiah.org  Thu May 17 15:34:03 2018
From: toby at tobiah.org (Tobiah)
Date: Thu, 17 May 2018 12:34:03 -0700
Subject: why does list's .remove() does not return an object?
References: <CADrxXXmrvyfCJmFa92O01TKBfh1o1toxFu7jZCyfjAMgpehMVg@mail.gmail.com>
 <57b25718-46e0-cca0-aa4d-a1209e9cafee@nedbatchelder.com>
 <CADrxXXn_DQatgBYW+DS5oz9EXYO_fn0ByQRQSFhJ_UpEdQ3y9g@mail.gmail.com>
 <2c6e4639-ce25-026b-5963-90c8e2888747@nedbatchelder.com>
 <CADrxXX==e330Fav84eCFwU2EUE6gUyaGKOaguCVs-1W7+uyq=w@mail.gmail.com>
 <9f86d58c-f95f-31c0-3b79-dba75e3b49dc@mapgears.com>
 <CADrxXXnaWr1JHZpoayeqKB5qsvx_fp0uwF6H1FsM8Yn88HO5hw@mail.gmail.com>
 <dcc03962-1c1b-66f4-2736-25099d24b61c@nedbatchelder.com>
 <mailman.164.1526574347.2761.python-list@python.org>
Message-ID: <pdklfa$vqf$1@gioia.aioe.org>

On 05/17/2018 09:25 AM, Ned Batchelder wrote:
> On 5/17/18 11:57 AM, Abdur-Rahmaan Janhangeer wrote:
>> x = [0,1]
>> x.remove(0)
>> new_list = x

Just call the original list 'new_list' to begin with.

   new_list = [0, 1]
   new_list.remove(0)


There you are!


From info at wingware.com  Thu May 17 15:54:41 2018
From: info at wingware.com (Wingware)
Date: Thu, 17 May 2018 15:54:41 -0400
Subject: ANN: Wing Python IDE 6.0.12 released
Message-ID: <5AFDDE01.4090508@wingware.com>

Hi,

We've just released Wing 6.0.12 <http://wingware.com/news/2018-05-15>, 
which adds wxPython 4 as a supported matplotlib backend, fixes remote 
development with Python 3.7, improves PEP287 docstring formatting 
errors, correctly updates the Source Assistant for remote files, fixes 
display glitches in the Remote Hosts dialog, adds minor updates of the 
French localization, and makes about 20 other improvements.  For 
details, see https://wingware.com/pub/wingide/6.0.12/CHANGELOG.txt

Download Now <https://wingware.com/downloads>

About Wing

Wing is a family of cross-platform 
<http://wingware.com/doc/install/supported-platforms> Python IDEs with 
powerful integrated editing, debugging, unit testing, and project 
management features. Wing runs on Windows, Linux, and OS X, and can be 
used to develop any kind of Python code for web, desktop, embedded 
scripting, and other applications.

Wing 101 <https://wingware.com/downloads/wing-101> and Wing Personal 
<https://wingware.com/downloads/wing-personal> omit some features and 
are free to download and use without a license. Wing Pro 
<https://wingware.com/downloads/wing-pro> requires purchasing 
<https://wingware.com/store/purchase> or upgrading 
<https://wingware.com/store/upgrade> a license, or obtaining a 30-day 
trial at startup.

Version 6 introduces many new features, including improved 
multi-selection, much easier remote development 
<https://wingware.com/doc/proj/remote-hosts>, debugging from the Python 
Shell, recursive debugging, PEP 484 and 526 type hinting, support for 
Python 3.6 and 3.7, Vagrant <https://wingware.com/doc/howtos/vagrant>, 
Jupyter <https://wingware.com/doc/howtos/jupyter>, and Django 
<https://wingware.com/doc/howtos/django> 1.10+, easier Raspberry Pi 
<https://wingware.com/doc/howtos/raspberry> development, optimized 
debugger, OS X full screen mode, One Dark color palette, Russian 
localization (thanks to Alexandr Dragukin), expanded free product line, 
and much more. For details, see What's New in Wing Version 6 
<https://wingware.com/wingide/whatsnew>.

Wing 6 works with Python versions 2.5 through 2.7 and 3.2 through 3.7, 
including also Anaconda, ActivePython, EPD, Stackless, and others 
derived from the CPython implementation.

For more product information, please visit wingware.com 
<https://wingware.com/>

Upgrading

You can try Wing 6 without removing older versions. Wing 6 will read and 
convert your old preferences, settings, and projects. Projects should be 
saved to a new name since previous versions of Wing cannot read Wing 6 
projects.

See also Migrating from Older Versions 
<https://wingware.com/doc/install/migrating> and Upgrading 
<https://wingware.com/doc/install/upgrading>.

Links

Release notice: https://wingware.com/news/2018-05-15
Downloads and Free Trial: https://wingware.com/downloads
Buy: https://wingware.com/store/purchase
Upgrade: https://wingware.com/store/upgrade

Questions?  Don't hesitate to email us at support at wingware.com.

Thanks,

-- 

Stephan Deibel
Wingware | Python IDE

The Intelligent Development Environment for Python Programmers

wingware.com



From skip.montanaro at gmail.com  Thu May 17 15:55:12 2018
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Thu, 17 May 2018 14:55:12 -0500
Subject: logging date format with milliseconds and timezone
Message-ID: <CANc-5Uw7uHmJBOnkQCoKiokZX1YW=QobnecsxJ+n5eNENyNrog@mail.gmail.com>

It seems that the logging.Formatter class uses two formats by default to
format a time, default_time_format (%Y-%m-%d %H:%M:%S) and
default_msec_format (%s,%03d). The former is a format string for
time.strftime (and thus can't represent fractions of a second). The latter
accomplishes that, but expanding %s with the output of (I believe)
time.strftime and %03d with the milliseconds in the current time. Users can
pass a datefmt arg to logging.basicConfig, or override the aforementioned
default_*_format attributes. Is there some way to format the timestamp with
both fractions of a second and timezone in a way similar to
datetime.strftime? In particular, I'd be happy with this format:
%Y-%m-%dT%H:%M:%S.%f%z. Maybe there is some magic flag to tell the system
I'm want to use datetime.strftime instead of time.strftime?

Thx,

Skip


From Karsten.Hilbert at gmx.net  Thu May 17 17:27:44 2018
From: Karsten.Hilbert at gmx.net (Karsten Hilbert)
Date: Thu, 17 May 2018 23:27:44 +0200
Subject: Aw: Re: why does list's .remove() does not return an object?
In-Reply-To: <dcc03962-1c1b-66f4-2736-25099d24b61c@nedbatchelder.com>
References: <CADrxXXmrvyfCJmFa92O01TKBfh1o1toxFu7jZCyfjAMgpehMVg@mail.gmail.com>
 <57b25718-46e0-cca0-aa4d-a1209e9cafee@nedbatchelder.com>
 <CADrxXXn_DQatgBYW+DS5oz9EXYO_fn0ByQRQSFhJ_UpEdQ3y9g@mail.gmail.com>
 <2c6e4639-ce25-026b-5963-90c8e2888747@nedbatchelder.com>
 <CADrxXX==e330Fav84eCFwU2EUE6gUyaGKOaguCVs-1W7+uyq=w@mail.gmail.com>
 <9f86d58c-f95f-31c0-3b79-dba75e3b49dc@mapgears.com>
 <CADrxXXnaWr1JHZpoayeqKB5qsvx_fp0uwF6H1FsM8Yn88HO5hw@mail.gmail.com>
 <dcc03962-1c1b-66f4-2736-25099d24b61c@nedbatchelder.com>
Message-ID: <trinity-3530bb42-ef5a-46f5-b76c-c9c0f355a233-1526592464584@3c-app-gmx-bs16>

> On 5/17/18 11:57 AM, Abdur-Rahmaan Janhangeer wrote:
> > x = [0,1]
> > x.remove(0)
> > new_list = x
> >
> > instead i want in one go
> >
> > x = [0,1]
> > new_list = x.remove(0) # here a way for it to return the modified list by
> > adding a .return() maybe ?
> 
> There isn't a way to do that in one line.

   new_list = list(x.remove(0))
   new_list = x.remove(0)[:]

?

No one said x can't be modified, only that new_list is
to contain the modified list after one line of code :)

kh


From Karsten.Hilbert at gmx.net  Thu May 17 17:31:23 2018
From: Karsten.Hilbert at gmx.net (Karsten Hilbert)
Date: Thu, 17 May 2018 23:31:23 +0200
Subject: Aw: Re: why does list's .remove() does not return an object?
In-Reply-To: <trinity-3530bb42-ef5a-46f5-b76c-c9c0f355a233-1526592464584@3c-app-gmx-bs16>
References: <CADrxXXmrvyfCJmFa92O01TKBfh1o1toxFu7jZCyfjAMgpehMVg@mail.gmail.com>
 <57b25718-46e0-cca0-aa4d-a1209e9cafee@nedbatchelder.com>
 <CADrxXXn_DQatgBYW+DS5oz9EXYO_fn0ByQRQSFhJ_UpEdQ3y9g@mail.gmail.com>
 <2c6e4639-ce25-026b-5963-90c8e2888747@nedbatchelder.com>
 <CADrxXX==e330Fav84eCFwU2EUE6gUyaGKOaguCVs-1W7+uyq=w@mail.gmail.com>
 <9f86d58c-f95f-31c0-3b79-dba75e3b49dc@mapgears.com>
 <CADrxXXnaWr1JHZpoayeqKB5qsvx_fp0uwF6H1FsM8Yn88HO5hw@mail.gmail.com>
 <dcc03962-1c1b-66f4-2736-25099d24b61c@nedbatchelder.com>
 <trinity-3530bb42-ef5a-46f5-b76c-c9c0f355a233-1526592464584@3c-app-gmx-bs16>
Message-ID: <trinity-287a3096-e276-4f49-a079-41e2f411c3b3-1526592683246@3c-app-gmx-bs16>

>    new_list = list(x.remove(0))
>    new_list = x.remove(0)[:]

Please disregard :)

kh


From ian.g.kelly at gmail.com  Thu May 17 17:34:06 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Thu, 17 May 2018 15:34:06 -0600
Subject: why does list's .remove() does not return an object?
In-Reply-To: <trinity-3530bb42-ef5a-46f5-b76c-c9c0f355a233-1526592464584@3c-app-gmx-bs16>
References: <CADrxXXmrvyfCJmFa92O01TKBfh1o1toxFu7jZCyfjAMgpehMVg@mail.gmail.com>
 <57b25718-46e0-cca0-aa4d-a1209e9cafee@nedbatchelder.com>
 <CADrxXXn_DQatgBYW+DS5oz9EXYO_fn0ByQRQSFhJ_UpEdQ3y9g@mail.gmail.com>
 <2c6e4639-ce25-026b-5963-90c8e2888747@nedbatchelder.com>
 <CADrxXX==e330Fav84eCFwU2EUE6gUyaGKOaguCVs-1W7+uyq=w@mail.gmail.com>
 <9f86d58c-f95f-31c0-3b79-dba75e3b49dc@mapgears.com>
 <CADrxXXnaWr1JHZpoayeqKB5qsvx_fp0uwF6H1FsM8Yn88HO5hw@mail.gmail.com>
 <dcc03962-1c1b-66f4-2736-25099d24b61c@nedbatchelder.com>
 <trinity-3530bb42-ef5a-46f5-b76c-c9c0f355a233-1526592464584@3c-app-gmx-bs16>
Message-ID: <CALwzid=rtk2G0pXO1d3P2a2CgMwL-ggFoW1Un6zzza9QKoWzXA@mail.gmail.com>

On Thu, May 17, 2018 at 3:27 PM, Karsten Hilbert
<Karsten.Hilbert at gmx.net> wrote:
>> On 5/17/18 11:57 AM, Abdur-Rahmaan Janhangeer wrote:
>> > x = [0,1]
>> > x.remove(0)
>> > new_list = x
>> >
>> > instead i want in one go
>> >
>> > x = [0,1]
>> > new_list = x.remove(0) # here a way for it to return the modified list by
>> > adding a .return() maybe ?
>>
>> There isn't a way to do that in one line.
>
>    new_list = list(x.remove(0))
>    new_list = x.remove(0)[:]
>
> ?
>
> No one said x can't be modified, only that new_list is
> to contain the modified list after one line of code :)

Did you actually run either of those?


From saxri89 at gmail.com  Thu May 17 17:40:11 2018
From: saxri89 at gmail.com (Xristos Xristoou)
Date: Thu, 17 May 2018 14:40:11 -0700 (PDT)
Subject: file download using django and javascript
Message-ID: <12cc200e-a5f1-403d-9c32-89040c6a84ef@googlegroups.com>



i have create a django app with REST JSON API and i fill html table in web page from my JSON.

here some examples

javascript snippets :

var field22=document.getElementById('f22');
field22.innerHTML=e.target.feature.properties.id;

var field23=document.getElementById('f23');
field23.innerHTML=e.target.feature.properties.file_1;

html :

    </tbody></table><br> <br>
    <table style="width:95%">
      <tbody><tr>
      <th align="left">id :</th>
      <td id="f22"></td>
      </tr> <tr>
       <th align="left">file :</th>
      <td id="f23"></td>
      </tr> <tr>

i have parse my JSON in table with success but in the file field now i have a simple text from image path.

Now i want in this path to have some hyperlink(or button) for download this file.

any idea how to do this because i stack ?i dont know how to connection javasscript with my download or how to download this file using javascript

django app code

models.py:

class MyModel(models.Model):
    file_1 = models.FileField(upload_to='documents/',blank=True, null=True)

simple test django donwload :

def download(request, id):
    product_file=MyModel.objects.get(pk=id)
    f = StringIO()
    zip = zipfile.ZipFile(f, 'w')
    product_file_url = product_file.file_1.url
    file_url = settings.MEDIA_ROOT + product_file_url[6:]
    filename = product_file_url[6:].split('/')[-1]
    zip.write(file_url,filename)
    zip.close()
    response = HttpResponse(f.getvalue(), content_type="application/zip")
    response['Content-Disposition'] = 'attachment; filename=file-download.zip'
    return response



From rosuav at gmail.com  Thu May 17 18:38:31 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 18 May 2018 08:38:31 +1000
Subject: syntax oddities
In-Reply-To: <2d0sfdh2h3ki49koh2s667os2ug9tvp6e4@4ax.com>
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org> <2d0sfdh2h3ki49koh2s667os2ug9tvp6e4@4ax.com>
Message-ID: <CAPTjJmoY7V7d1-iKa8yxWb4W=u1iJU-ZKXS9c554LhQ-YBfe0w@mail.gmail.com>

On Fri, May 18, 2018 at 8:31 AM, Dennis Lee Bieber
<wlfraed at ix.netcom.com> wrote:
> On Thu, 17 May 2018 07:18:32 -0700, Tobiah <toby at tobiah.org> declaimed the
> following:
>
>>Top posting is awesome for the reader plowing through
>>a thread in order.  In that case the cruft at the bottom
>>is only for occasional reference.
>>
>
>         That concept is meaningful only email between two parties, where the
> quoted material is a "courtesy copy" for content the other party likely
> provided a week earlier (snail mail).

And I'm not sure it's of value there either. If I emailed someone a
week ago and s/he responds today, proper quote trimming is of great
value, just as it is with newsgroups/mailing lists. The only time it
wouldn't much matter is if we're going back and forth with extreme
rapidity, and then you may as well bottom-post because it makes little
difference.

ChrisA


From tallpaul at gmail.com  Thu May 17 18:44:45 2018
From: tallpaul at gmail.com (Paul)
Date: Thu, 17 May 2018 18:44:45 -0400
Subject: syntax oddities
In-Reply-To: <2d0sfdh2h3ki49koh2s667os2ug9tvp6e4@4ax.com>
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org> <2d0sfdh2h3ki49koh2s667os2ug9tvp6e4@4ax.com>
Message-ID: <CA+og5uq9_HBHPyacq5EHtM4qvrBWMKRrWOSq8cXt+jsLz4xATw@mail.gmail.com>

>
>
>         That concept is meaningful only email between two parties, where
> the
> quoted material is a "courtesy copy" for content the other party likely
> provided a week earlier (snail mail).
>
>         But mailing lists/newsgroups are the equivalent of a bulletin board
> open to anyone walking past. Bottom posting (or better, trim and
> intersperse) allows someone who has no prior knowledge of the message chain
> to read it from top-down, picking up the relevant points as they go...
> Rather than having to flip through a stack of pages looking for information
> being referenced by the top-most sheet of paper.
>
>
> --
>         Wulfraed                 Dennis Lee Bieber


I've been using email for thirty years, including thousands of group emails
at many tech companies, and no one has ever suggested, let alone insisted
on, bottom posting.  If someone's late to a thread they can read from it
the bottom up. But, for everyone who has been  keeping up, not having to
scroll is a big advantage.
   I'm not suggesting that the convention on this list be changed, but it's
by no means the only option which makes sense.
  Paul C.

>
>


From rosuav at gmail.com  Thu May 17 18:49:31 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 18 May 2018 08:49:31 +1000
Subject: syntax oddities
In-Reply-To: <CA+og5uq9_HBHPyacq5EHtM4qvrBWMKRrWOSq8cXt+jsLz4xATw@mail.gmail.com>
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org> <2d0sfdh2h3ki49koh2s667os2ug9tvp6e4@4ax.com>
 <CA+og5uq9_HBHPyacq5EHtM4qvrBWMKRrWOSq8cXt+jsLz4xATw@mail.gmail.com>
Message-ID: <CAPTjJmr_4YGjovAMYOEXwTT7ADQk8Ywo+ntjWrB-zt433Aph8g@mail.gmail.com>

On Fri, May 18, 2018 at 8:44 AM, Paul <tallpaul at gmail.com> wrote:
>>
>>
>>         That concept is meaningful only email between two parties, where
>> the
>> quoted material is a "courtesy copy" for content the other party likely
>> provided a week earlier (snail mail).
>>
>>         But mailing lists/newsgroups are the equivalent of a bulletin board
>> open to anyone walking past. Bottom posting (or better, trim and
>> intersperse) allows someone who has no prior knowledge of the message chain
>> to read it from top-down, picking up the relevant points as they go...
>> Rather than having to flip through a stack of pages looking for information
>> being referenced by the top-most sheet of paper.
>>
>>
>> --
>>         Wulfraed                 Dennis Lee Bieber
>
>
> I've been using email for thirty years, including thousands of group emails
> at many tech companies, and no one has ever suggested, let alone insisted
> on, bottom posting.  If someone's late to a thread they can read from it
> the bottom up.

Remind me which direction text is usually written in English?

ChrisA


From mike.junk.46 at att.net  Thu May 17 19:29:00 2018
From: mike.junk.46 at att.net (Mike McClain)
Date: Thu, 17 May 2018 16:29:00 -0700
Subject: object types, mutable or not?
In-Reply-To: <CAPTjJmqGWhZZ-tS1-xLBf=EyRN92prPmOx3T3dqSf9J2c_2G3Q@mail.gmail.com>
References: <20180515142939.GA5181@playground> <pdfrk2$unn$13@blaine.gmane.org>
 <85y3gkl74d.fsf@benfinney.id.au> <pdgjnn$fka$1@blaine.gmane.org>
 <85po1wkrph.fsf@benfinney.id.au> <pdgluq$fka$2@blaine.gmane.org>
 <8b1f93ef-88de-01d1-8f3a-799d88bc81b6@nedbatchelder.com>
 <CACac1F8OOUCu24Ve8eCbWWGfqbGrMx3F=M_3N8URnYdkaMWUTg@mail.gmail.com>
 <20180517111632.33904cdf@wegge.dk>
 <CAPTjJmqGWhZZ-tS1-xLBf=EyRN92prPmOx3T3dqSf9J2c_2G3Q@mail.gmail.com>
Message-ID: <20180517232900.GA24006@playground>

On Thu, May 17, 2018 at 07:28:44PM +1000, Chris Angelico wrote:
> On Thu, May 17, 2018 at 7:16 PM, Anders Wegge Keller <wegge at wegge.dk> wrote:
> > P?? Wed, 16 May 2018 14:48:27 +0100
> > Paul Moore <p.f.moore at gmail.com> skrev:
> >
> >> C++ called that an "rvalue". And then went on to define things that
> >> could go on the left hand side of an assignment as "lvalues". And now
> >> we have two confusing concepts to explain - see what happens when you
> >> let a standards committee define your language? :-)
> >
> >  I'm not sure the C++ committee has to bear the responsibility for those
> > terms. They are pretty well defined in the C world, so I think you need to
> > point the finger of accusation at either Brian or Dennis.
> >
>
> Let's be fair and blame one of them for each.
>

Let's be fair and make that accolades.
We stand on their shoulders.

I like telling a computer what to do.
Don't you?

Enjoy,
Mike
--
Once you can accept the universe as matter expanding into nothing
that is something, wearing stripes with plaid comes easy.
    - Albert Einstein


From steve+comp.lang.python at pearwood.info  Thu May 17 20:39:29 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 18 May 2018 00:39:29 +0000 (UTC)
Subject: syntax oddities
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org> <2d0sfdh2h3ki49koh2s667os2ug9tvp6e4@4ax.com>
 <CAPTjJmoY7V7d1-iKa8yxWb4W=u1iJU-ZKXS9c554LhQ-YBfe0w@mail.gmail.com>
Message-ID: <pdl7c0$3fh$1@blaine.gmane.org>

On Fri, 18 May 2018 08:38:31 +1000, Chris Angelico wrote:

> On Fri, May 18, 2018 at 8:31 AM, Dennis Lee Bieber
> <wlfraed at ix.netcom.com> wrote:
>> On Thu, 17 May 2018 07:18:32 -0700, Tobiah <toby at tobiah.org> declaimed
>> the following:
>>
>>>Top posting is awesome for the reader plowing through a thread in
>>>order.  In that case the cruft at the bottom is only for occasional
>>>reference.
>>>
>>>
>>         That concept is meaningful only email between two parties,
>>         where the
>> quoted material is a "courtesy copy" for content the other party likely
>> provided a week earlier (snail mail).
> 
> And I'm not sure it's of value there either. If I emailed someone a week
> ago and s/he responds today, proper quote trimming is of great value,
> just as it is with newsgroups/mailing lists. The only time it wouldn't
> much matter is if we're going back and forth with extreme rapidity, and
> then you may as well bottom-post because it makes little difference.

Bottom-posting is infinitely more evil than top-posting.

The next time I have to scroll past fifteen pages of quoted text twelve 
layers deep, only to read "Me too!!!1!" or "LOL!!!" as the sole addition 
to the conversation, I'm going to go all Jack Nicholson in The Shining.

What we want is *inline* posting, which follows the *trimmed* posting. If 
there happens to be only a single quoted section left untrimmed (as in 
this email) it may superficially look like bottom-posting, but it isn't.

Top-posting is good for real-time rapid-fire conversations between two 
parties where the context is self-evident and you will never, ever need 
to look through the archives again.

But bottom-posting without trimming combines the worst of both strategies.


-- 
Steve



From bc at freeuk.com  Thu May 17 21:17:39 2018
From: bc at freeuk.com (bartc)
Date: Fri, 18 May 2018 02:17:39 +0100
Subject: what does := means simply?
In-Reply-To: <mailman.167.1526577723.2761.python-list@python.org>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkdjc$fka$10@blaine.gmane.org>
 <mailman.167.1526577723.2761.python-list@python.org>
Message-ID: <NQpLC.180984$oo.95504@fx35.am4>

On 17/05/2018 18:19, Steven D'Aprano wrote:
> On Thu, 17 May 2018 15:50:17 +0100, bartc wrote:

>> Of course, full-on Python code is pretty much impossible to port
>> anywhere else anyway.
> 
> *rolls eyes*

> Any pair of languages will have code that is hard to port from one to the
> other without jumping through hoops. Try porting C code with lots of
> dynamic memory allocations and pointer accesses to COBOL, or Scheme code
> using continuations to Python, or Hyperscript text chunking code to
> Fortran.
> 
> But hard does not mean "pretty much impossible".


Normally you'd use the source code as a start point. In the case of 
Python, that means Python source code. But you will quickly run into 
problems because you will often see 'import lib' and be unable to find 
lib.py anywhere.

That's one problem. Others might involve how to deal with something like 
__globals__ which doesn't have an equivalent in the target language. And 
we haven't started on features that are specific to Python.

But most non-esoteric languages will have functions, variables, 
assignments, expressions, loops and so on. The basics. Algorithms 
expressed using those will be simplest to port.

When I was looking at benchmarks involving multiple languages and wanted 
to port one to a new language, I usually ended up working from Pascal or 
Lua because they tended not to use advanced features that made the job 
harder.

-- 
bartc


From steve+comp.lang.python at pearwood.info  Thu May 17 21:45:26 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 18 May 2018 01:45:26 +0000 (UTC)
Subject: what does := means simply?
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkdjc$fka$10@blaine.gmane.org>
 <mailman.167.1526577723.2761.python-list@python.org>
 <NQpLC.180984$oo.95504@fx35.am4>
Message-ID: <pdlb7l$3fh$2@blaine.gmane.org>

On Fri, 18 May 2018 02:17:39 +0100, bartc wrote:

> Normally you'd use the source code as a start point. In the case of
> Python, that means Python source code. But you will quickly run into
> problems because you will often see 'import lib' and be unable to find
> lib.py anywhere.

Seriously? There's a finite number of file extensions to look for:

.py .pyc .pyo .pyw .dll .so

pretty much is the lot, except on some obscure platforms which few people 
use.

To successful port anything but the most trivial code, you actually have 
to understand *both* languages -- including the syntax, semantics, built-
in language features, AND libraries.


> That's one problem. Others might involve how to deal with something like
> __globals__ which doesn't have an equivalent in the target language. And
> we haven't started on features that are specific to Python.

How about features which are specific to C, or Scheme, or Forth, or APL, 
or bash, or Fortran, or Intercal, or Java, or Javascript, or Ruby, or 
Smalltalk, or Rust, or Go, or any of hundreds of other languages?

Since every language has features that some other languages don't have, 
is it your position that it is impossible to port code from any language 
to any other?

If you want to *really* see code that is hard to port, you should try 
porting an Inform 7 program to another language. Any other language.



-- 
Steve



From arj.python at gmail.com  Thu May 17 22:07:15 2018
From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer)
Date: Fri, 18 May 2018 06:07:15 +0400
Subject: why does list's .remove() does not return an object?
In-Reply-To: <pdklfa$vqf$1@gioia.aioe.org>
References: <CADrxXXmrvyfCJmFa92O01TKBfh1o1toxFu7jZCyfjAMgpehMVg@mail.gmail.com>
 <57b25718-46e0-cca0-aa4d-a1209e9cafee@nedbatchelder.com>
 <CADrxXXn_DQatgBYW+DS5oz9EXYO_fn0ByQRQSFhJ_UpEdQ3y9g@mail.gmail.com>
 <2c6e4639-ce25-026b-5963-90c8e2888747@nedbatchelder.com>
 <CADrxXX==e330Fav84eCFwU2EUE6gUyaGKOaguCVs-1W7+uyq=w@mail.gmail.com>
 <9f86d58c-f95f-31c0-3b79-dba75e3b49dc@mapgears.com>
 <CADrxXXnaWr1JHZpoayeqKB5qsvx_fp0uwF6H1FsM8Yn88HO5hw@mail.gmail.com>
 <dcc03962-1c1b-66f4-2736-25099d24b61c@nedbatchelder.com>
 <mailman.164.1526574347.2761.python-list@python.org>
 <pdklfa$vqf$1@gioia.aioe.org>
Message-ID: <CADrxXXke5dmuNqKaT1ZnaK+dmYGWO4Gdy5jsPOcS7J-uEUvkUQ@mail.gmail.com>

ah there's no return question then

that precisely returned the discussion to the first answer

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

On Thu, 17 May 2018, 23:35 Tobiah, <toby at tobiah.org> wrote:

> On 05/17/2018 09:25 AM, Ned Batchelder wrote:
> > On 5/17/18 11:57 AM, Abdur-Rahmaan Janhangeer wrote:
> >> x = [0,1]
> >> x.remove(0)
> >> new_list = x
>
> Just call the original list 'new_list' to begin with.
>
>    new_list = [0, 1]
>    new_list.remove(0)
>
>
> There you are!
> --
> https://mail.python.org/mailman/listinfo/python-list
>


From ian.g.kelly at gmail.com  Thu May 17 22:33:14 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Thu, 17 May 2018 20:33:14 -0600
Subject: what does := means simply?
In-Reply-To: <pdlb7l$3fh$2@blaine.gmane.org>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkdjc$fka$10@blaine.gmane.org>
 <mailman.167.1526577723.2761.python-list@python.org>
 <NQpLC.180984$oo.95504@fx35.am4> <pdlb7l$3fh$2@blaine.gmane.org>
Message-ID: <CALwzidmgF1vFB0J254JMZkjvQte3hDDbZmX1DL8DKf3WGEt6ug@mail.gmail.com>

On Thu, May 17, 2018, 7:50 PM Steven D'Aprano <
steve+comp.lang.python at pearwood.info> wrote:

>
> If you want to *really* see code that is hard to port, you should try
> porting an Inform 7 program to another language. Any other language.
>

How about Z-code?

*ducks*

>


From ben+python at benfinney.id.au  Thu May 17 23:45:43 2018
From: ben+python at benfinney.id.au (Ben Finney)
Date: Fri, 18 May 2018 13:45:43 +1000
Subject: what does := means simply?
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkdjc$fka$10@blaine.gmane.org>
 <mailman.167.1526577723.2761.python-list@python.org>
 <NQpLC.180984$oo.95504@fx35.am4> <pdlb7l$3fh$2@blaine.gmane.org>
Message-ID: <85h8n5lj88.fsf@benfinney.id.au>

Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:

> If you want to *really* see code that is hard to port, you should try
> porting an Inform 7 program to another language. Any other language.

Does porting Inform 7 code to Inform 6 count? They are very different
languages :-)

-- 
 \      ?Puritanism: The haunting fear that someone, somewhere, may be |
  `\                                         happy.? ?Henry L. Mencken |
_o__)                                                                  |
Ben Finney



From bob at mellowood.ca  Fri May 18 02:02:45 2018
From: bob at mellowood.ca (Bob van der Poel)
Date: Thu, 17 May 2018 23:02:45 -0700
Subject: what does := means simply?
In-Reply-To: <85h8n5lj88.fsf@benfinney.id.au>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkdjc$fka$10@blaine.gmane.org>
 <mailman.167.1526577723.2761.python-list@python.org>
 <NQpLC.180984$oo.95504@fx35.am4> <pdlb7l$3fh$2@blaine.gmane.org>
 <85h8n5lj88.fsf@benfinney.id.au>
Message-ID: <CA+HdcZh8Vej0no=aSVdyV1jpE0hO_u4MBjK+Msw9e-77x9eybg@mail.gmail.com>

On Thu, May 17, 2018, 8:45 PM Ben Finney, <ben+python at benfinney.id.au>
wrote:

> Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:
>
> > If you want to *really* see code that is hard to port, you should try
> > porting an Inform 7 program to another language. Any other language.
>
> Does porting Inform 7 code to Inform 6 count? They are very different
> languages :-)
>
>
My least favorite remains APL.


From dieter at handshake.de  Fri May 18 02:12:50 2018
From: dieter at handshake.de (dieter)
Date: Fri, 18 May 2018 08:12:50 +0200
Subject: Request for comments: use-cases for delayed evaluation
References: <pdk2lh$fka$9@blaine.gmane.org>
Message-ID: <871se9pk4d.fsf@handshake.de>

Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:

> Suppose Python had a mechanism to delay the evaluation of expressions 
> until needed. What would you use it for?

Delayed evaluation is some form of "lazy evaluation": evaluate an
expression (only) at the time, it is needed (maybe for the first time).

The avocates of "lazy evaluation" bring forward that it gives you
a convenient new modularization facility: you can separate the description
for the construction of (potentially huge or even infinite) data structures
from the algorithms operating on those structures. The "lazy evaluation"
ensures that the structure is "unfolded" only so far as a concrete
algorithm requires it.

An example could be a game. Lazy evaluation would allow to describe
once and for all how to compute the tree of game states reachable from
a given game state (usually a huge, maybe even an infinite tree).
Various algorithms for the selection of the next game move could
all work on tree (and would be some form of tree search).

With lazy evaluation, Python might become more attractive in
areas where conceptually huge data structures can be involved: games,
articial intelligence, proving systems, ...



From dieter at handshake.de  Fri May 18 02:36:13 2018
From: dieter at handshake.de (dieter)
Date: Fri, 18 May 2018 08:36:13 +0200
Subject: Package DLL or SO in wheel
References: <CALGOvYa3TO1ErtvFtqsEHCFJFSmP9Dm=XkwPThpMxffS35cNZA@mail.gmail.com>
Message-ID: <87wow1o4gy.fsf@handshake.de>

Chris Nyland <menyland at gmail.com> writes:
> We have several internal modules we have developed that are used mostly to
> read different types of data files. Most of the time the different data
> file formats come with some sort of DLL or SO files that gives a standard
> interface to read the files. Our design pattern is to create a python
> library that uses ctypes to interface with the shared library.
>
> To be clear we are not building the shared libraries these are usually
> provided by another group or distributed by a  third party.
>
> So the issue is I want to bundle these share libraries with the module into
> a wheel or sdist package to server off our local PyPiServer.

I am not yet familiar with the newer "wheel" concept but
with "older" technology you could approach it as follows.

I am using "setuptools", thus I use this for the presentation below.
But "setuptools" is based on the standard "distutils" package
and this has the same facilities.

With "setuptools", you describe how to handle (especially install)
a distribution by providing describing arguments to a "setup"
function. The "ext_modules" parameter is responsible to
describe extensions, i.e. things corresponding to shared objects/DLLs.
The value of "ext_modules" is a sequence of "setuptools.Extension"
instances.

The standard "setuptools.Extension" class can handle C/C++
compilation (and various other generation types). It
supports standard parameters decribing sources, macros, includes,
libraries -- things typically involved in C/C++ compilation).
For your case, you would need your own "Extension" class: as
source it would use the precreated shared object[s]; as additional
parameter, it would have the target platform supported by those
shared object[s]. On installation, it would check for platform compatibility
and then put the shared object[s] at the correct place.

If I would need to implement such an "Extension" class, I would
look at the implementation of "setuptools.Extension" (likely,
I would also have to look at its base "distutils.Extension")
and derive my "Extention" by simplification (the shared object[s]
are already build and available; they need just get installed).




From lele at metapensiero.it  Fri May 18 02:53:15 2018
From: lele at metapensiero.it (Lele Gaifax)
Date: Fri, 18 May 2018 08:53:15 +0200
Subject: syntax oddities
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org>
 <2d0sfdh2h3ki49koh2s667os2ug9tvp6e4@4ax.com>
 <CA+og5uq9_HBHPyacq5EHtM4qvrBWMKRrWOSq8cXt+jsLz4xATw@mail.gmail.com>
 <CAPTjJmr_4YGjovAMYOEXwTT7ADQk8Ywo+ntjWrB-zt433Aph8g@mail.gmail.com>
Message-ID: <87lgchlajo.fsf@metapensiero.it>

Chris Angelico <rosuav at gmail.com> writes:

> Remind me which direction text is usually written in English?

This applies to italian as well, accordingly to one my signatures, that
roughly corresponds to the following:

  Because it is contrary to the normal sense of reading
  > What's wrong with top-posting?
  >> The answers that precede the questions
  >>> What's the most boring thing in e-mails?

:-)

ciao, lele.
-- 
nickname: Lele Gaifax | Perch? ? contrario al normale senso di lettura
real: Emanuele Gaifas | > Cosa c'? di male nel rispondere in cima?
lele at metapensiero.it  | >> Le risposte che precedono le domande
                      | >>> Qual'? la cosa pi? noiosa nelle e-mail?



From rhodri at kynesim.co.uk  Fri May 18 07:04:54 2018
From: rhodri at kynesim.co.uk (Rhodri James)
Date: Fri, 18 May 2018 12:04:54 +0100
Subject: what does := means simply?
In-Reply-To: <pdlb7l$3fh$2@blaine.gmane.org>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkdjc$fka$10@blaine.gmane.org>
 <mailman.167.1526577723.2761.python-list@python.org>
 <NQpLC.180984$oo.95504@fx35.am4> <pdlb7l$3fh$2@blaine.gmane.org>
Message-ID: <573f37f6-1cfd-e87e-64e4-8db60df3d337@kynesim.co.uk>

On 18/05/18 02:45, Steven D'Aprano wrote:
> To successful port anything but the most trivial code, you actually have
> to understand *both* languages -- including the syntax, semantics, built-
> in language features, AND libraries.

A point that was once made to me about translating human languages is 
that to do it well, you need to understand both languages *and both 
cultures.*  The same principle probably applies to computer languages as 
well; how often have we collectively complained about people trying to 
write (say) FORTRAN in Python?

-- 
Rhodri James *-* Kynesim Ltd


From rhodri at kynesim.co.uk  Fri May 18 07:08:39 2018
From: rhodri at kynesim.co.uk (Rhodri James)
Date: Fri, 18 May 2018 12:08:39 +0100
Subject: syntax oddities
In-Reply-To: <CA+og5uq9_HBHPyacq5EHtM4qvrBWMKRrWOSq8cXt+jsLz4xATw@mail.gmail.com>
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org> <2d0sfdh2h3ki49koh2s667os2ug9tvp6e4@4ax.com>
 <CA+og5uq9_HBHPyacq5EHtM4qvrBWMKRrWOSq8cXt+jsLz4xATw@mail.gmail.com>
Message-ID: <be6291dd-968c-fe23-d8ff-d73f57d16513@kynesim.co.uk>

On 17/05/18 23:44, Paul wrote:
> I've been using email for thirty years, including thousands of group emails
> at many tech companies, and no one has ever suggested, let alone insisted
> on, bottom posting.

I've been using email for thirty years, etc, etc, and I've always 
insisted on proper quoting, trimming and interspersed posting.  Clearly 
you've never worked in the right companies ;-)

-- 
Rhodri James *-* Kynesim Ltd


From bc at freeuk.com  Fri May 18 07:09:02 2018
From: bc at freeuk.com (bartc)
Date: Fri, 18 May 2018 12:09:02 +0100
Subject: what does := means simply?
In-Reply-To: <mailman.186.1526608074.2761.python-list@python.org>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkdjc$fka$10@blaine.gmane.org>
 <mailman.167.1526577723.2761.python-list@python.org>
 <NQpLC.180984$oo.95504@fx35.am4> <pdlb7l$3fh$2@blaine.gmane.org>
 <mailman.186.1526608074.2761.python-list@python.org>
Message-ID: <avyLC.201959$Z64.75842@fx36.am4>

On 18/05/2018 02:45, Steven D'Aprano wrote:
> On Fri, 18 May 2018 02:17:39 +0100, bartc wrote:
> 
>> Normally you'd use the source code as a start point. In the case of
>> Python, that means Python source code. But you will quickly run into
>> problems because you will often see 'import lib' and be unable to find
>> lib.py anywhere.
> 
> Seriously? There's a finite number of file extensions to look for:
> 
> .py .pyc .pyo .pyw .dll .so
> 
> pretty much is the lot, except on some obscure platforms which few people
> use.

Which one corresponds to 'import sys'?

If the source to such libraries is not available then it is necessary to 
emulate that functionality. You are writing from scratch, not porting, 
according to specifications. And those specifications may be 
inexplicably tied to the inner workings of the language.

That is a little bit harder, yes? Especially as Python is a scripting 
language and might rely more than most on this quite extensive built-in 
functionality, even on fairly short programs.

(When I once thought about implementing an interpreter for Python 
byte-code, I found all this out very quickly. Such an interpreter could 
work perfectly but it would not get past 'import sys'.)

> To successful port anything but the most trivial code, you actually have
> to understand *both* languages -- including the syntax, semantics, built-
> in language features, AND libraries.

Don't forget configuration and build systems. The code you want to port 
may not even exist, but is synthesised as part of the build process, and 
be specific to a particular build.

I'm talking about the seemingly rare case these days where you DO have 
the source code!

>> That's one problem. Others might involve how to deal with something like
>> __globals__ which doesn't have an equivalent in the target language. And
>> we haven't started on features that are specific to Python.
> 
> How about features which are specific to C

I'm quite familiar with C which has its own set of problems. But taking 
one aspect, if a C program relies on its standard library, then it is 
very often possible to directly call that standard library from another 
language, so you don't need to reimplement it, nor port it.

> Since every language has features that some other languages don't have,
> is it your position that it is impossible to port code from any language
> to any other?

I'm saying some languages make it more difficult, and Python is one of 
them, especially written 'Pythonically', which seems to be code for 
'this only makes sense in Python', so that you can't understand it even 
if you have no intention of  porting it.


> If you want to *really* see code that is hard to port, you should try
> porting an Inform 7 program to another language. Any other language.

You seem to be saying that because it is rarely completely impossible to 
port software, that we disregard any difficulties and consider all such 
porting as equally trivial.

I'm just saying that in my experience, given the choice of porting the 
same program from other Python or, say, Lua, I would choose Lua.

Same with choosing between 'full-on' C++ and, say, Pascal.

Both C++ and Python can be used to write software in a simple style (as 
I would use); typically they are not used that way. Given the rich set 
of esoteric features of both, programmers do like to pull out all the stops.

-- 
bartc


From bc at freeuk.com  Fri May 18 07:29:15 2018
From: bc at freeuk.com (bartc)
Date: Fri, 18 May 2018 12:29:15 +0100
Subject: syntax oddities
In-Reply-To: <mailman.183.1526597380.2761.python-list@python.org>
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org> <2d0sfdh2h3ki49koh2s667os2ug9tvp6e4@4ax.com>
 <CA+og5uq9_HBHPyacq5EHtM4qvrBWMKRrWOSq8cXt+jsLz4xATw@mail.gmail.com>
 <CAPTjJmr_4YGjovAMYOEXwTT7ADQk8Ywo+ntjWrB-zt433Aph8g@mail.gmail.com>
 <mailman.183.1526597380.2761.python-list@python.org>
Message-ID: <7OyLC.150095$ny5.70995@fx17.am4>

On 17/05/2018 23:49, Chris Angelico wrote:
> On Fri, May 18, 2018 at 8:44 AM, Paul <tallpaul at gmail.com> wrote:

>> I've been using email for thirty years, including thousands of group emails
>> at many tech companies, and no one has ever suggested, let alone insisted
>> on, bottom posting.  If someone's late to a thread they can read from it
>> the bottom up.
> 
> Remind me which direction text is usually written in English?

Is this a trick question? It's usually written left to right.


From rosuav at gmail.com  Fri May 18 07:38:39 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 18 May 2018 21:38:39 +1000
Subject: syntax oddities
In-Reply-To: <7OyLC.150095$ny5.70995@fx17.am4>
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org> <2d0sfdh2h3ki49koh2s667os2ug9tvp6e4@4ax.com>
 <CA+og5uq9_HBHPyacq5EHtM4qvrBWMKRrWOSq8cXt+jsLz4xATw@mail.gmail.com>
 <CAPTjJmr_4YGjovAMYOEXwTT7ADQk8Ywo+ntjWrB-zt433Aph8g@mail.gmail.com>
 <mailman.183.1526597380.2761.python-list@python.org>
 <7OyLC.150095$ny5.70995@fx17.am4>
Message-ID: <CAPTjJmoXEiL3U23E7_70ii7zmg19r=ZwrfxsXNjcf9f9TAOc7w@mail.gmail.com>

On Fri, May 18, 2018 at 9:29 PM, bartc <bc at freeuk.com> wrote:
> On 17/05/2018 23:49, Chris Angelico wrote:
>>
>> On Fri, May 18, 2018 at 8:44 AM, Paul <tallpaul at gmail.com> wrote:
>
>
>>> I've been using email for thirty years, including thousands of group
>>> emails
>>> at many tech companies, and no one has ever suggested, let alone insisted
>>> on, bottom posting.  If someone's late to a thread they can read from it
>>> the bottom up.
>>
>>
>> Remind me which direction text is usually written in English?
>
>
> Is this a trick question? It's usually written left to right.

And the lines are written top to bottom. Not bottom to top. Why should
people have to read sections from the bottom up, but text within the
section from the top down?

ChrisA


From simonandrew132 at gmail.com  Fri May 18 07:40:59 2018
From: simonandrew132 at gmail.com (Alferdize)
Date: Fri, 18 May 2018 17:10:59 +0530
Subject: Fwd: sys module does not contain ps1
In-Reply-To: <CA+EVXgvexHBEmwN19n+ustzDNqefAjAfPrUO08qWK=QwGAf2qQ@mail.gmail.com>
References: <CA+EVXgvexHBEmwN19n+ustzDNqefAjAfPrUO08qWK=QwGAf2qQ@mail.gmail.com>
Message-ID: <CA+EVXgs8EzzB74pnuCCfQ2ZA7c6jmGQE8-Gx=VXvP+-vspHFbg@mail.gmail.com>

---------- Forwarded message ----------
From: Alferdize <simonandrew132 at gmail.com>
Date: Thu, May 17, 2018 at 10:13 PM
Subject: sys module does not contain ps1
To: python-list at python.org


It is giving error like I have given below
>>> import sys
>>> sys.ps1
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    sys.ps1
AttributeError: module 'sys' has no attribute 'ps1'
-------------- next part --------------
Python 3.7.0b3 (v3.7.0b3:4e7efa9c6f, Mar 29 2018, 18:42:04) [MSC v.1913 64 bit (AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> import sys
>>> sys.ps1
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    sys.ps1
AttributeError: module 'sys' has no attribute 'ps1'
>>> dir(sys)
['__breakpointhook__', '__displayhook__', '__doc__', '__excepthook__', '__interactivehook__', '__loader__', '__name__', '__package__', '__spec__', '__stderr__', '__stdin__', '__stdout__', '_clear_type_cache', '_current_frames', '_debugmallocstats', '_enablelegacywindowsfsencoding', '_framework', '_getframe', '_git', '_home', '_xoptions', 'api_version', 'argv', 'base_exec_prefix', 'base_prefix', 'breakpointhook', 'builtin_module_names', 'byteorder', 'call_tracing', 'callstats', 'copyright', 'displayhook', 'dllhandle', 'dont_write_bytecode', 'exc_info', 'excepthook', 'exec_prefix', 'executable', 'exit', 'flags', 'float_info', 'float_repr_style', 'get_asyncgen_hooks', 'get_coroutine_origin_tracking_depth', 'get_coroutine_wrapper', 'getallocatedblocks', 'getcheckinterval', 'getdefaultencoding', 'getfilesystemencodeerrors', 'getfilesystemencoding', 'getprofile', 'getrecursionlimit', 'getrefcount', 'getsizeof', 'getswitchinterval', 'gettrace', 'getwindowsversion', 'hash_info', 'hexversion', 'implementation', 'int_info', 'intern', 'is_finalizing', 'last_traceback', 'last_type', 'last_value', 'maxsize', 'maxunicode', 'meta_path', 'modules', 'path', 'path_hooks', 'path_importer_cache', 'platform', 'prefix', 'set_asyncgen_hooks', 'set_coroutine_origin_tracking_depth', 'set_coroutine_wrapper', 'setcheckinterval', 'setprofile', 'setrecursionlimit', 'setswitchinterval', 'settrace', 'stderr', 'stdin', 'stdout', 'thread_info', 'version', 'version_info', 'warnoptions', 'winver']
>>> 

From ned at nedbatchelder.com  Fri May 18 07:45:38 2018
From: ned at nedbatchelder.com (Ned Batchelder)
Date: Fri, 18 May 2018 07:45:38 -0400
Subject: what does := means simply?
In-Reply-To: <avyLC.201959$Z64.75842@fx36.am4>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkdjc$fka$10@blaine.gmane.org>
 <mailman.167.1526577723.2761.python-list@python.org>
 <NQpLC.180984$oo.95504@fx35.am4> <pdlb7l$3fh$2@blaine.gmane.org>
 <mailman.186.1526608074.2761.python-list@python.org>
 <avyLC.201959$Z64.75842@fx36.am4>
Message-ID: <5a3ee283-d114-af92-3fb8-52b6743117c4@nedbatchelder.com>

On 5/18/18 7:09 AM, bartc wrote:
> On 18/05/2018 02:45, Steven D'Aprano wrote:
>> On Fri, 18 May 2018 02:17:39 +0100, bartc wrote:
>>
>>> Normally you'd use the source code as a start point. In the case of
>>> Python, that means Python source code. But you will quickly run into
>>> problems because you will often see 'import lib' and be unable to find
>>> lib.py anywhere.
>>
>> Seriously? There's a finite number of file extensions to look for:
>>
>> .py .pyc .pyo .pyw .dll .so
>>
>> pretty much is the lot, except on some obscure platforms which few 
>> people
>> use.
>
> Which one corresponds to 'import sys'?
>
> If the source to such libraries is not available then it is necessary 
> to emulate that functionality. You are writing from scratch, not 
> porting, according to specifications. And those specifications may be 
> inexplicably tied to the inner workings of the language.
>
> That is a little bit harder, yes? Especially as Python is a scripting 
> language and might rely more than most on this quite extensive 
> built-in functionality, even on fairly short programs.
>
> (When I once thought about implementing an interpreter for Python 
> byte-code, I found all this out very quickly. Such an interpreter 
> could work perfectly but it would not get past 'import sys'.)
>
>> To successful port anything but the most trivial code, you actually have
>> to understand *both* languages -- including the syntax, semantics, 
>> built-
>> in language features, AND libraries.
>
> Don't forget configuration and build systems. The code you want to 
> port may not even exist, but is synthesised as part of the build 
> process, and be specific to a particular build.
>
> I'm talking about the seemingly rare case these days where you DO have 
> the source code!
>
>>> That's one problem. Others might involve how to deal with something 
>>> like
>>> __globals__ which doesn't have an equivalent in the target language. 
>>> And
>>> we haven't started on features that are specific to Python.
>>
>> How about features which are specific to C
>
> I'm quite familiar with C which has its own set of problems. But 
> taking one aspect, if a C program relies on its standard library, then 
> it is very often possible to directly call that standard library from 
> another language, so you don't need to reimplement it, nor port it.
>
>> Since every language has features that some other languages don't have,
>> is it your position that it is impossible to port code from any language
>> to any other?
>
> I'm saying some languages make it more difficult, and Python is one of 
> them, especially written 'Pythonically', which seems to be code for 
> 'this only makes sense in Python', so that you can't understand it 
> even if you have no intention of? porting it.
>
>
>> If you want to *really* see code that is hard to port, you should try
>> porting an Inform 7 program to another language. Any other language.
>
> You seem to be saying that because it is rarely completely impossible 
> to port software, that we disregard any difficulties and consider all 
> such porting as equally trivial.
>
> I'm just saying that in my experience, given the choice of porting the 
> same program from other Python or, say, Lua, I would choose Lua.
>
> Same with choosing between 'full-on' C++ and, say, Pascal.
>
> Both C++ and Python can be used to write software in a simple style 
> (as I would use); typically they are not used that way. Given the rich 
> set of esoteric features of both, programmers do like to pull out all 
> the stops.
>

Your logic here seems to be to use the least-common denominator among 
some guessed-at set of languages, so that if you ever have to 
re-implement a program, you can transliterate it into another language.? 
I would much rather choose a tool and use it well (that is, to its 
fullest power) than to hobble myself on the off-chance I have to switch 
languages in the future.

I guess I don't understand the type of work you've been doing: I have 
only very very rarely had to reimplement the same program in another 
language.? I can't imagine choosing tooling or style based on that concern.

We have had this discussion at work: do we use Python in a "simple" way 
so that new developers coming from Java (or C, etc) can understand it? 
Or do we assume that people working in a large Python codebase 
understand Python?? I choose the latter.

--Ned.


From ben.usenet at bsb.me.uk  Fri May 18 08:20:27 2018
From: ben.usenet at bsb.me.uk (Ben Bacarisse)
Date: Fri, 18 May 2018 13:20:27 +0100
Subject: syntax oddities
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org>
 <2d0sfdh2h3ki49koh2s667os2ug9tvp6e4@4ax.com>
 <CA+og5uq9_HBHPyacq5EHtM4qvrBWMKRrWOSq8cXt+jsLz4xATw@mail.gmail.com>
 <CAPTjJmr_4YGjovAMYOEXwTT7ADQk8Ywo+ntjWrB-zt433Aph8g@mail.gmail.com>
 <mailman.183.1526597380.2761.python-list@python.org>
 <7OyLC.150095$ny5.70995@fx17.am4>
Message-ID: <87lgchf94k.fsf@bsb.me.uk>

bartc <bc at freeuk.com> writes:

> On 17/05/2018 23:49, Chris Angelico wrote:
>> On Fri, May 18, 2018 at 8:44 AM, Paul <tallpaul at gmail.com> wrote:
>
>>> I've been using email for thirty years, including thousands of group emails
>>> at many tech companies, and no one has ever suggested, let alone insisted
>>> on, bottom posting.  If someone's late to a thread they can read from it
>>> the bottom up.
>>
>> Remind me which direction text is usually written in English?
>
> Is this a trick question? It's usually written left to right.

in a rather biased way "front to back" -- turning pages to the left.
an English book is read left to right, top to bottom and what we call
two" because in printed text, pages also ordered need to be order.  Thus
we read English text left to right and top to bottom.  I say "at least
bottom.  The slightly sarcastic question was supposed remind people that
lines left to right, lines are stacked, almost always from top to
There are at least two directions for most text.  After constructing

-- 
Ben.


From p.f.moore at gmail.com  Fri May 18 08:25:52 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Fri, 18 May 2018 13:25:52 +0100
Subject: syntax oddities
In-Reply-To: <be6291dd-968c-fe23-d8ff-d73f57d16513@kynesim.co.uk>
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org> <2d0sfdh2h3ki49koh2s667os2ug9tvp6e4@4ax.com>
 <CA+og5uq9_HBHPyacq5EHtM4qvrBWMKRrWOSq8cXt+jsLz4xATw@mail.gmail.com>
 <be6291dd-968c-fe23-d8ff-d73f57d16513@kynesim.co.uk>
Message-ID: <CACac1F-vHtFt_rzELBpxffJrSmZiFv47ftJEz2fVf0nWufo18g@mail.gmail.com>

On 18 May 2018 at 12:08, Rhodri James <rhodri at kynesim.co.uk> wrote:
> On 17/05/18 23:44, Paul wrote:
>>
>> I've been using email for thirty years, including thousands of group
>> emails
>> at many tech companies, and no one has ever suggested, let alone insisted
>> on, bottom posting.
>
> I've been using email for thirty years, etc, etc, and I've always insisted
> on proper quoting, trimming and interspersed posting.  Clearly you've never
> worked in the right companies ;-)

There are two completely independent cultures here. In "Corporate"
cultures like where I work (where IT and business functions interact a
lot, and business users typically use tools like Outlook) top-posting
is common, conventional, and frankly, effective. Conversely, in purely
technical communities like open source, where conventions originated
in low-bandwidth channels like early networks, interspersed posting,
heavy trimming and careful quoting are the norm. I've participated in
both communities for 30 years or more, and you deal with people in the
way that they find most comfortable.

It's polite to follow the conventions of the community that you're
interacting with - so on this mailing list, for example, quoting and
posting inline is the norm and top-posting is considered impolite.
Arguing about how the community's conventions are wrong is also
impolite :-) I'm reminded of the old stereotypes of Brits speaking
English NICE AND LOUDLY to foreigners to help them understand what
we're saying... (Disclaimer: I'm a Brit, so I'm poking fun at myself
here :-))

Paul


From steve+comp.lang.python at pearwood.info  Fri May 18 08:29:38 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 18 May 2018 12:29:38 +0000 (UTC)
Subject: what does := means simply?
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkdjc$fka$10@blaine.gmane.org>
 <mailman.167.1526577723.2761.python-list@python.org>
 <NQpLC.180984$oo.95504@fx35.am4> <pdlb7l$3fh$2@blaine.gmane.org>
 <mailman.186.1526608074.2761.python-list@python.org>
 <avyLC.201959$Z64.75842@fx36.am4>
Message-ID: <pdmgvh$3fh$3@blaine.gmane.org>

On Fri, 18 May 2018 12:09:02 +0100, bartc wrote:

> On 18/05/2018 02:45, Steven D'Aprano wrote:
>> On Fri, 18 May 2018 02:17:39 +0100, bartc wrote:
>> 
>>> Normally you'd use the source code as a start point. In the case of
>>> Python, that means Python source code. But you will quickly run into
>>> problems because you will often see 'import lib' and be unable to find
>>> lib.py anywhere.
>> 
>> Seriously? There's a finite number of file extensions to look for:
>> 
>> .py .pyc .pyo .pyw .dll .so
>> 
>> pretty much is the lot, except on some obscure platforms which few
>> people use.
> 
> Which one corresponds to 'import sys'?

The functions in sys are built-in to the CPython interpreter. For other 
interpreters, they could correspond to some file, or not, as the 
implementer desires.

So just like built-in functions, your first stop when porting is to READ 
THE DOCUMENTATION and learn what the semantics of the functions you care 
about, not the source code.

But you know that.

If I see:

    result = math.sin(x)

and I want to port it, what should I do?

1. Dive into the source code of math.so or math.dll, and from there dig 
deeper into the platform maths libraries and the intricacies of the sin 
function;

2. Read the docs, discover that math.sin returns the trigonometric sine 
function, and use my target languages own sine implementation? (If and 
only if there is a difference in behaviour between sine implementations 
should I *consider* diving into the platform sine.)


I don't believe you actually choose 1 when you are porting.

So why should sys.version be treated differently from math.sin(), for 
example? What matters is the *interface*, not the implementation, and we 
best get the interface from the docs, not from diving into the source.

Diving into the source is the last resort.


> If the source to such libraries is not available then it is necessary to
> emulate that functionality. You are writing from scratch, not porting,
> according to specifications.

I disagree.

Come on Bart, be serious here. You surely don't mean to say that porting 
the Python script

    print("Hello World!")

to Ruby:

    print "Hello world!"


is "writing from scratch, not porting" unless the Ruby print uses 
precisely the same implementation as the Python print. All that matters 
is that for *this* specific use, the two print commands behave the same.


>> Since every language has features that some other languages don't have,
>> is it your position that it is impossible to port code from any
>> language to any other?
> 
> I'm saying some languages make it more difficult, and Python is one of
> them

Only if you are trying to port *down* the Blub hierarchy, to a less 
powerful language.

But that's always the case.


[...]
>> If you want to *really* see code that is hard to port, you should try
>> porting an Inform 7 program to another language. Any other language.
> 
> You seem to be saying that because it is rarely completely impossible to
> port software, that we disregard any difficulties and consider all such
> porting as equally trivial.

No.


> I'm just saying that in my experience, given the choice of porting the
> same program from other Python or, say, Lua, I would choose Lua.

If they are *the same program* then surely they will be identical (modulo 
syntax and naming of builtins) and there should be no difference in 
difficulty in porting.

If they are *semantically the same* (they do the same thing) but have 
different implementations, then you've just blown a hole in your own 
argument.

If a Python program does a task T using some implementation P which Lua 
cannot easily use, and a Lua program does exactly the same task T but 
using a different implementation L, then the way to port the Python 
program to Lua is to adapt the algorithm so that it uses L.

Any successful port is going to require changes to the implementation, 
because the two languages are going to have differences in semantics. The 
Ruby print is not absolutely identical to the Python print, so there may 
be times you need to work around those differences. Lua's tables are not 
identical to either Python lists or dicts (but a little like both).

And port is going to require you to adapt the code. Sometimes a little, 
sometimes a lot.

But you know that.



-- 
Steve



From rhodri at kynesim.co.uk  Fri May 18 09:00:08 2018
From: rhodri at kynesim.co.uk (Rhodri James)
Date: Fri, 18 May 2018 14:00:08 +0100
Subject: syntax oddities
In-Reply-To: <CACac1F-vHtFt_rzELBpxffJrSmZiFv47ftJEz2fVf0nWufo18g@mail.gmail.com>
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org> <2d0sfdh2h3ki49koh2s667os2ug9tvp6e4@4ax.com>
 <CA+og5uq9_HBHPyacq5EHtM4qvrBWMKRrWOSq8cXt+jsLz4xATw@mail.gmail.com>
 <be6291dd-968c-fe23-d8ff-d73f57d16513@kynesim.co.uk>
 <CACac1F-vHtFt_rzELBpxffJrSmZiFv47ftJEz2fVf0nWufo18g@mail.gmail.com>
Message-ID: <10b589de-2ba6-b52f-e0a9-0267e5676ef3@kynesim.co.uk>

On 18/05/18 13:25, Paul Moore wrote:
> Arguing about how the community's conventions are wrong is also
> impolite:-)

It's not an argument, it's a contradiction :-)

> I'm reminded of the old stereotypes of Brits speaking
> English NICE AND LOUDLY to foreigners to help them understand what
> we're saying... (Disclaimer: I'm a Brit, so I'm poking fun at myself
> here :-))

It's not actually the worst thing you could do.  People speaking NICE 
AND LOUDLY also tend to speak more slowly and with better diction, both 
of which make life simpler for your poor old foreigner.

-- 
Rhodri James *-* Kynesim Ltd


From steve+comp.lang.python at pearwood.info  Fri May 18 09:24:58 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 18 May 2018 13:24:58 +0000 (UTC)
Subject: syntax oddities
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org> <2d0sfdh2h3ki49koh2s667os2ug9tvp6e4@4ax.com>
 <CA+og5uq9_HBHPyacq5EHtM4qvrBWMKRrWOSq8cXt+jsLz4xATw@mail.gmail.com>
 <be6291dd-968c-fe23-d8ff-d73f57d16513@kynesim.co.uk>
 <CACac1F-vHtFt_rzELBpxffJrSmZiFv47ftJEz2fVf0nWufo18g@mail.gmail.com>
Message-ID: <pdmk7a$3fh$4@blaine.gmane.org>

On Fri, 18 May 2018 13:25:52 +0100, Paul Moore wrote:

> In "Corporate"
> cultures like where I work (where IT and business functions interact a
> lot, and business users typically use tools like Outlook) top-posting is
> common, conventional, and frankly, effective.

I don't believe that email is effective in corporate culture *at all*, 
regardless of posting convention. Email is for sending, not reading or 
responding to. When people do respond to it, they invariably send some 
stream of consciousness nonsense that doesn't answer the questions you 
asked or give you enough instructions to actually get the job done that 
they want you to do.

Email in corporate culture is good for only one thing: after the 
seventeen pages of quoted text, and before the two page disclaimer 
telling you that legally you are in violation of a hundred and seventeen 
laws by merely walking past the building where the email was sent, the 
sender usually has their phone number so you can call them and ask them 
what they actually want done.

*Usually*.




-- 
Steve



From Richard at Damon-Family.org  Fri May 18 10:30:02 2018
From: Richard at Damon-Family.org (Richard Damon)
Date: Fri, 18 May 2018 10:30:02 -0400
Subject: syntax oddities
In-Reply-To: <CACac1F-vHtFt_rzELBpxffJrSmZiFv47ftJEz2fVf0nWufo18g@mail.gmail.com>
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org> <2d0sfdh2h3ki49koh2s667os2ug9tvp6e4@4ax.com>
 <CA+og5uq9_HBHPyacq5EHtM4qvrBWMKRrWOSq8cXt+jsLz4xATw@mail.gmail.com>
 <be6291dd-968c-fe23-d8ff-d73f57d16513@kynesim.co.uk>
 <CACac1F-vHtFt_rzELBpxffJrSmZiFv47ftJEz2fVf0nWufo18g@mail.gmail.com>
Message-ID: <aa33df90-0e40-4aab-ce2a-3e18099eb4d4@Damon-Family.org>

On 5/18/18 8:25 AM, Paul Moore wrote:
> On 18 May 2018 at 12:08, Rhodri James <rhodri at kynesim.co.uk> wrote:
> There are two completely independent cultures here. In "Corporate"
> cultures like where I work (where IT and business functions interact a
> lot, and business users typically use tools like Outlook) top-posting
> is common, conventional, and frankly, effective. Conversely, in purely
> technical communities like open source, where conventions originated
> in low-bandwidth channels like early networks, interspersed posting,
> heavy trimming and careful quoting are the norm. I've participated in
> both communities for 30 years or more, and you deal with people in the
> way that they find most comfortable.
>
> It's polite to follow the conventions of the community that you're
> interacting with - so on this mailing list, for example, quoting and
> posting inline is the norm and top-posting is considered impolite.
> Arguing about how the community's conventions are wrong is also
> impolite :-) I'm reminded of the old stereotypes of Brits speaking
> English NICE AND LOUDLY to foreigners to help them understand what
> we're saying... (Disclaimer: I'm a Brit, so I'm poking fun at myself
> here :-))
>
> Paul

I would divide the two communities/cultures differently. Top Posting is
reasonable, effective and common in an environment where the primary
recipients of the message can be assumed to have read, and likely
remembered, the previous messages, and they are included mostly as a
quick memory aid to remember WHICH conversation this message pertains
with, or to a lessor extent, to help bring someone new to the
conversation up to speed or if the message is pulled up out of an
archive. Here the real focus is on the new content and the past record
is mostly a 'foot note' (which is expected to be at the end). Since
people tend to ignore the quoted material, if often ends up unedited and
gets long (this actual is useful when someone new gets added to the
email chain)

The second community has a wide audience, and it is expected that many
people may come in at 'the middle' of a discussion, and thus the message
with the history is likely to be read as a whole. It also can generally
be assume that prior messages are available, thus less context is
'needed'. Here Interspersed/Bottom posting works better (Interspersed if
responding point by point, Bottom if single point or responding to the
message en-total.)

Mailing list, Usenet, Forums and the like all tend to fall into the
second category, but people more used to the more private type of
conversations may have bad habits and not think about how it should
transition to the different environment.

-- 
Richard Damon



From bc at freeuk.com  Fri May 18 10:37:41 2018
From: bc at freeuk.com (bartc)
Date: Fri, 18 May 2018 15:37:41 +0100
Subject: what does := means simply?
In-Reply-To: <mailman.199.1526646718.2761.python-list@python.org>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkdjc$fka$10@blaine.gmane.org>
 <mailman.167.1526577723.2761.python-list@python.org>
 <NQpLC.180984$oo.95504@fx35.am4> <pdlb7l$3fh$2@blaine.gmane.org>
 <mailman.186.1526608074.2761.python-list@python.org>
 <avyLC.201959$Z64.75842@fx36.am4> <pdmgvh$3fh$3@blaine.gmane.org>
 <mailman.199.1526646718.2761.python-list@python.org>
Message-ID: <NyBLC.259028$Xa4.208590@fx29.am4>

On 18/05/2018 13:29, Steven D'Aprano wrote:
> On Fri, 18 May 2018 12:09:02 +0100, bartc wrote:
> 
>> On 18/05/2018 02:45, Steven D'Aprano wrote:
>>> On Fri, 18 May 2018 02:17:39 +0100, bartc wrote:
>>>
>>>> Normally you'd use the source code as a start point. In the case of
>>>> Python, that means Python source code. But you will quickly run into
>>>> problems because you will often see 'import lib' and be unable to find
>>>> lib.py anywhere.
>>>
>>> Seriously? There's a finite number of file extensions to look for:
>>>
>>> .py .pyc .pyo .pyw .dll .so
>>>
>>> pretty much is the lot, except on some obscure platforms which few
>>> people use.
>>
>> Which one corresponds to 'import sys'?
> 
> The functions in sys are built-in to the CPython interpreter. For other
> interpreters, they could correspond to some file, or not, as the
> implementer desires.
> 
> So just like built-in functions, your first stop when porting is to READ
> THE DOCUMENTATION and learn what the semantics of the functions you care
> about, not the source code.

But there is a huge amount of such functionality.

There are other ways of doing it which can make more use of the actual 
language (ie. Python) and make use of generally available libraries (eg. 
msvcrt.dll/libc.so.6), with fewer mysterious goings-on in the middle.

> If I see:
> 
>      result = math.sin(x)
> 
> and I want to port it, what should I do?

>      print("Hello World!")
> 
> is "writing from scratch, not porting" unless the Ruby print uses
> precisely the same implementation as the Python print. All that matters
> is that for *this* specific use, the two print commands behave the same.

And you've chosen two of the most common language features for your 
examples, which would probably be available on a 1970s BASIC (I know SQR 
was, can't remember about SIN).

Those are not the kinds of problem I mean.

> 
>>> Since every language has features that some other languages don't have,
>>> is it your position that it is impossible to port code from any
>>> language to any other?
>>
>> I'm saying some languages make it more difficult, and Python is one of
>> them
> 
> Only if you are trying to port *down* the Blub hierarchy, to a less
> powerful language.

You might be trying to go from one level of Blub to the same level of 
Blub, but the two Blubs are completely incompatible.

>> I'm just saying that in my experience, given the choice of porting the
>> same program from other Python or, say, Lua, I would choose Lua.
> 
> If they are *the same program* then surely they will be identical (modulo
> syntax and naming of builtins) and there should be no difference in
> difficulty in porting.
> 
> If they are *semantically the same* (they do the same thing) but have
> different implementations, then you've just blown a hole in your own
> argument.

Have a look at some of the implementations here (to test some Mandelbrot 
benchmark):

https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html

The three Python examples all use 'import sys' and 'import 
multiprocessing', none of which I can find any trace of as any sort of 
files let alone .py. One of them also uses 'import array', which I can't 
find either.

Now look at the Lua and Lua#2 examples. They don't appear to use 
anything that hairy, and could be good candidates for porting. As would 
be Free Pascal #3 (the other Pascals use threads).

(Although when I tried to port the Lua just now, I ran into trouble 
because I didn't know Lua well enough (it's also poorly written IMO, and 
I ran out of time). That's fair enough; you need to be familiar with the 
language you're porting from.

But I could be very familiar with Python and still wouldn't be able to 
directly translate code which depended heavily on library functions. 
Knowing the specification of those is not going to help if I don't 
already have something that does exactly the same job.)

Looking also at the amount of code, the Pythons don't appear to be that 
much shorter or simpler than many of the others.

-- 
bartc


From rosuav at gmail.com  Fri May 18 10:38:01 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 19 May 2018 00:38:01 +1000
Subject: syntax oddities
In-Reply-To: <aa33df90-0e40-4aab-ce2a-3e18099eb4d4@Damon-Family.org>
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org> <2d0sfdh2h3ki49koh2s667os2ug9tvp6e4@4ax.com>
 <CA+og5uq9_HBHPyacq5EHtM4qvrBWMKRrWOSq8cXt+jsLz4xATw@mail.gmail.com>
 <be6291dd-968c-fe23-d8ff-d73f57d16513@kynesim.co.uk>
 <CACac1F-vHtFt_rzELBpxffJrSmZiFv47ftJEz2fVf0nWufo18g@mail.gmail.com>
 <aa33df90-0e40-4aab-ce2a-3e18099eb4d4@Damon-Family.org>
Message-ID: <CAPTjJmpOvCDf=bY4cKTQkmBUAKRzxbWpOQgTPK=p6kKO8X0xyw@mail.gmail.com>

On Sat, May 19, 2018 at 12:30 AM, Richard Damon
<Richard at damon-family.org> wrote:
> I would divide the two communities/cultures differently. Top Posting is
> reasonable, effective and common in an environment where the primary
> recipients of the message can be assumed to have read, and likely
> remembered, the previous messages, and they are included mostly as a
> quick memory aid to remember WHICH conversation this message pertains
> with, or to a lessor extent, to help bring someone new to the
> conversation up to speed or if the message is pulled up out of an
> archive. Here the real focus is on the new content and the past record
> is mostly a 'foot note' (which is expected to be at the end). Since
> people tend to ignore the quoted material, if often ends up unedited and
> gets long (this actual is useful when someone new gets added to the
> email chain)

If people are generally going to ignore the quoted content, why have
it at all? Why not just post context-free messages that have a
reference to the rest of the conversation?

The ONLY way that the unedited quoted material is useful to someone
joining the email chain is if EVERY message is a response to the
single most recent message, and thus carries the entire conversation.
Otherwise, your email thread will branch and fork, and someone cc'd in
on a message will see only part of the thread, making it worse than
useless. The way you describe things, email is the wrong tool for the
job, and you should be using a message board of some sort.

So, no, top posting still isn't "reasonable, effective, and common" in
any environment. It might be common, but that's all.

ChrisA


From rosuav at gmail.com  Fri May 18 10:47:28 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 19 May 2018 00:47:28 +1000
Subject: what does := means simply?
In-Reply-To: <NyBLC.259028$Xa4.208590@fx29.am4>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkdjc$fka$10@blaine.gmane.org>
 <mailman.167.1526577723.2761.python-list@python.org>
 <NQpLC.180984$oo.95504@fx35.am4> <pdlb7l$3fh$2@blaine.gmane.org>
 <mailman.186.1526608074.2761.python-list@python.org>
 <avyLC.201959$Z64.75842@fx36.am4> <pdmgvh$3fh$3@blaine.gmane.org>
 <mailman.199.1526646718.2761.python-list@python.org>
 <NyBLC.259028$Xa4.208590@fx29.am4>
Message-ID: <CAPTjJmoU9EUcOXT4ZcfrXep0UWN1U5fpngzj_oO6qEezc3eG2A@mail.gmail.com>

On Sat, May 19, 2018 at 12:37 AM, bartc <bc at freeuk.com> wrote:
> Have a look at some of the implementations here (to test some Mandelbrot
> benchmark):
>
> https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html
>
> The three Python examples all use 'import sys' and 'import multiprocessing',
> none of which I can find any trace of as any sort of files let alone .py.
> One of them also uses 'import array', which I can't find either.

I guess you didn't look very hard.

>>> import multiprocessing
>>> multiprocessing.__file__
'/usr/local/lib/python3.8/multiprocessing/__init__.py'
>>> import array
>>> array.__file__
'/usr/local/lib/python3.8/lib-dynload/array.cpython-38m-x86_64-linux-gnu.so'

Hey look, files!

But that still isn't the point. Porting does NOT mean emulating. Read
the documentation, not the implementation.

ChrisA


From grant.b.edwards at gmail.com  Fri May 18 10:55:52 2018
From: grant.b.edwards at gmail.com (Grant Edwards)
Date: Fri, 18 May 2018 14:55:52 +0000 (UTC)
Subject: syntax oddities
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org> <2d0sfdh2h3ki49koh2s667os2ug9tvp6e4@4ax.com>
 <CA+og5uq9_HBHPyacq5EHtM4qvrBWMKRrWOSq8cXt+jsLz4xATw@mail.gmail.com>
 <be6291dd-968c-fe23-d8ff-d73f57d16513@kynesim.co.uk>
 <CACac1F-vHtFt_rzELBpxffJrSmZiFv47ftJEz2fVf0nWufo18g@mail.gmail.com>
 <pdmk7a$3fh$4@blaine.gmane.org>
Message-ID: <pdmpho$1at$1@blaine.gmane.org>

On 2018-05-18, Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
> On Fri, 18 May 2018 13:25:52 +0100, Paul Moore wrote:
>
>> In "Corporate" cultures like where I work (where IT and business
>> functions interact a lot, and business users typically use tools
>> like Outlook) top-posting is common, conventional, and frankly,
>> effective.

You work someplace pretty unique.  Everyplace I've worked has done the
whole top-posting and include the whole damn thread in reverse order
thing.  It just doesn't work.  The attached reverse-chronological
history doesn't seem to do _any_ good at all.  AFAICT, nobody ever
reads it.  Occasionally somebody will refer opaquely to something with
the phrase "see below" -- but there's never any indication to _what_
among the fifteen messages and thirty attachements they are referring.

> I don't believe that email is effective in corporate culture *at all*, 
> regardless of posting convention. Email is for sending, not reading or 
> responding to. When people do respond to it, they invariably send some 
> stream of consciousness nonsense that doesn't answer the questions you 
> asked or give you enough instructions to actually get the job done that 
> they want you to do.

And most people seem to believe that if they read more that the first
two sentences of any e-mail it might trigger the apocolypse or give
their cat scabies or something else dreadful.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm EMOTIONAL
                                  at               now because I have
                              gmail.com            MERCHANDISING CLOUT!!



From Richard at Damon-Family.org  Fri May 18 11:09:47 2018
From: Richard at Damon-Family.org (Richard Damon)
Date: Fri, 18 May 2018 11:09:47 -0400
Subject: syntax oddities
In-Reply-To: <CAPTjJmpOvCDf=bY4cKTQkmBUAKRzxbWpOQgTPK=p6kKO8X0xyw@mail.gmail.com>
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org> <2d0sfdh2h3ki49koh2s667os2ug9tvp6e4@4ax.com>
 <CA+og5uq9_HBHPyacq5EHtM4qvrBWMKRrWOSq8cXt+jsLz4xATw@mail.gmail.com>
 <be6291dd-968c-fe23-d8ff-d73f57d16513@kynesim.co.uk>
 <CACac1F-vHtFt_rzELBpxffJrSmZiFv47ftJEz2fVf0nWufo18g@mail.gmail.com>
 <aa33df90-0e40-4aab-ce2a-3e18099eb4d4@Damon-Family.org>
 <CAPTjJmpOvCDf=bY4cKTQkmBUAKRzxbWpOQgTPK=p6kKO8X0xyw@mail.gmail.com>
Message-ID: <852c1a53-0f0d-dccc-8596-521d2d3124c4@Damon-Family.org>

On 5/18/18 10:38 AM, Chris Angelico wrote:
> On Sat, May 19, 2018 at 12:30 AM, Richard Damon
> <Richard at damon-family.org> wrote:
>> I would divide the two communities/cultures differently. Top Posting is
>> reasonable, effective and common in an environment where the primary
>> recipients of the message can be assumed to have read, and likely
>> remembered, the previous messages, and they are included mostly as a
>> quick memory aid to remember WHICH conversation this message pertains
>> with, or to a lessor extent, to help bring someone new to the
>> conversation up to speed or if the message is pulled up out of an
>> archive. Here the real focus is on the new content and the past record
>> is mostly a 'foot note' (which is expected to be at the end). Since
>> people tend to ignore the quoted material, if often ends up unedited and
>> gets long (this actual is useful when someone new gets added to the
>> email chain)
> If people are generally going to ignore the quoted content, why have
> it at all? Why not just post context-free messages that have a
> reference to the rest of the conversation?
Because, as I said, there are occational and lesser usages for the
quoted material, it just isn't primary. It is a 'foot note'
>
> The ONLY way that the unedited quoted material is useful to someone
> joining the email chain is if EVERY message is a response to the
> single most recent message, and thus carries the entire conversation.
> Otherwise, your email thread will branch and fork, and someone cc'd in
> on a message will see only part of the thread, making it worse than
> useless. The way you describe things, email is the wrong tool for the
> job, and you should be using a message board of some sort.
>
> So, no, top posting still isn't "reasonable, effective, and common" in
> any environment. It might be common, but that's all.
>
> ChrisA

If the thread forks, and someone is brought into one of the forks to
help with an issue brought up in THAT fork, then the context will
generally be sufficient for that.

Normally people WILL reply to the latest message in the chain (and in
fact Outlook will warn you if you are not doing that). The main reason
people don't reply to the most recent message is that several people
replied nearly simultaneously, and yes the? other comments not in the
message people carry forward will get lost from the history. But for
that to happen you need multiple active participants in the conversation
which starts to strays away from the model.

-- 
Richard Damon



From rosuav at gmail.com  Fri May 18 11:36:24 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 19 May 2018 01:36:24 +1000
Subject: syntax oddities
In-Reply-To: <852c1a53-0f0d-dccc-8596-521d2d3124c4@Damon-Family.org>
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org> <2d0sfdh2h3ki49koh2s667os2ug9tvp6e4@4ax.com>
 <CA+og5uq9_HBHPyacq5EHtM4qvrBWMKRrWOSq8cXt+jsLz4xATw@mail.gmail.com>
 <be6291dd-968c-fe23-d8ff-d73f57d16513@kynesim.co.uk>
 <CACac1F-vHtFt_rzELBpxffJrSmZiFv47ftJEz2fVf0nWufo18g@mail.gmail.com>
 <aa33df90-0e40-4aab-ce2a-3e18099eb4d4@Damon-Family.org>
 <CAPTjJmpOvCDf=bY4cKTQkmBUAKRzxbWpOQgTPK=p6kKO8X0xyw@mail.gmail.com>
 <852c1a53-0f0d-dccc-8596-521d2d3124c4@Damon-Family.org>
Message-ID: <CAPTjJmq7UuwdE9bpeUYgxWJ74ny_25D4YAWkYaYKxycAK8oAqA@mail.gmail.com>

On Sat, May 19, 2018 at 1:09 AM, Richard Damon <Richard at damon-family.org> wrote:
> If the thread forks, and someone is brought into one of the forks to
> help with an issue brought up in THAT fork, then the context will
> generally be sufficient for that.

That assumes that they don't need any information that was posted in
reply to something else.

> Normally people WILL reply to the latest message in the chain (and in
> fact Outlook will warn you if you are not doing that). The main reason
> people don't reply to the most recent message is that several people
> replied nearly simultaneously, and yes the  other comments not in the
> message people carry forward will get lost from the history. But for
> that to happen you need multiple active participants in the conversation
> which starts to strays away from the model.

Considering that I've had situations with 3-4 active participants and
replies-to-non-last-emails on our family mailing list - a list whose
membership is literally just my parents and siblings (including one
sister-in-law) - I would be astonished if it's a rare occurrence in
corporate environments. Unless, of course, the norm is to snap off an
email instantly, without bothering to actually put any thought into
what's being said. Oh wait, it probably is...

ChrisA


From marko at pacujo.net  Fri May 18 11:54:28 2018
From: marko at pacujo.net (Marko Rauhamaa)
Date: Fri, 18 May 2018 18:54:28 +0300
Subject: syntax oddities
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org>
 <2d0sfdh2h3ki49koh2s667os2ug9tvp6e4@4ax.com>
 <CA+og5uq9_HBHPyacq5EHtM4qvrBWMKRrWOSq8cXt+jsLz4xATw@mail.gmail.com>
 <be6291dd-968c-fe23-d8ff-d73f57d16513@kynesim.co.uk>
 <CACac1F-vHtFt_rzELBpxffJrSmZiFv47ftJEz2fVf0nWufo18g@mail.gmail.com>
 <pdmk7a$3fh$4@blaine.gmane.org> <pdmpho$1at$1@blaine.gmane.org>
 <mailman.206.1526655500.2761.python-list@python.org>
Message-ID: <87d0xtarij.fsf@elektro.pacujo.net>

Grant Edwards <grant.b.edwards at gmail.com>:
> And most people seem to believe that if they read more that the first
> two sentences of any e-mail it might trigger the apocolypse or give
> their cat scabies or something else dreadful.

I quickly glance at the hundred or so subject lines every morning and
open the one or two that happen to catch my attention.


Marko


From python at mrabarnett.plus.com  Fri May 18 12:51:59 2018
From: python at mrabarnett.plus.com (MRAB)
Date: Fri, 18 May 2018 17:51:59 +0100
Subject: Fwd: sys module does not contain ps1
In-Reply-To: <CA+EVXgs8EzzB74pnuCCfQ2ZA7c6jmGQE8-Gx=VXvP+-vspHFbg@mail.gmail.com>
References: <CA+EVXgvexHBEmwN19n+ustzDNqefAjAfPrUO08qWK=QwGAf2qQ@mail.gmail.com>
 <CA+EVXgs8EzzB74pnuCCfQ2ZA7c6jmGQE8-Gx=VXvP+-vspHFbg@mail.gmail.com>
Message-ID: <80c48706-8a9b-24ae-b7dc-acdda3d11e73@mrabarnett.plus.com>

On 2018-05-18 12:40, Alferdize wrote:
> ---------- Forwarded message ----------
> From: Alferdize <simonandrew132 at gmail.com>
> Date: Thu, May 17, 2018 at 10:13 PM
> Subject: sys module does not contain ps1
> To: python-list at python.org
> 
> 
> It is giving error like I have given below
>>>> import sys
>>>> sys.ps1
> Traceback (most recent call last):
>    File "<pyshell#1>", line 1, in <module>
>      sys.ps1
> AttributeError: module 'sys' has no attribute 'ps1'
> 
[snip]

I have the same version (Python 3.7.0b3). Here, sys has 'ps1' and 'ps2', 
but not 'last_traceback', 'last_type' or 'last_value'.


From arj.python at gmail.com  Fri May 18 13:14:11 2018
From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer)
Date: Fri, 18 May 2018 21:14:11 +0400
Subject: css script project refractor code
Message-ID: <CADrxXXkhvBrs2qn8F_m=ijmFg_qp-MB2P=tR1UTe7+1ExVF9Yw@mail.gmail.com>

i have a project at :

README :
https://github.com/Abdur-rahmaanJ/css-script/blob/master/README.md

SITE :
https://abdur-rahmaanj.github.io/css-script/

and i want to refractor the main file :

https://github.com/Abdur-rahmaanJ/css-script/blob/master/css_script/main.py

if this was an old project of yours, what advices do you give for
improvements?

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ


From rosuav at gmail.com  Fri May 18 13:20:35 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 19 May 2018 03:20:35 +1000
Subject: Fwd: sys module does not contain ps1
In-Reply-To: <80c48706-8a9b-24ae-b7dc-acdda3d11e73@mrabarnett.plus.com>
References: <CA+EVXgvexHBEmwN19n+ustzDNqefAjAfPrUO08qWK=QwGAf2qQ@mail.gmail.com>
 <CA+EVXgs8EzzB74pnuCCfQ2ZA7c6jmGQE8-Gx=VXvP+-vspHFbg@mail.gmail.com>
 <80c48706-8a9b-24ae-b7dc-acdda3d11e73@mrabarnett.plus.com>
Message-ID: <CAPTjJmon+R_Ss0Ret=AjdSEr=JwiSUccK0iF+iMo8uWu_Ex88Q@mail.gmail.com>

On Sat, May 19, 2018 at 2:51 AM, MRAB <python at mrabarnett.plus.com> wrote:
> I have the same version (Python 3.7.0b3). Here, sys has 'ps1' and 'ps2', but
> not 'last_traceback', 'last_type' or 'last_value'.

They aren't there till they're needed:

$ python3
Python 3.8.0a0 (heads/literal_eval-exception:ddcb2eb331, Feb 21 2018, 04:32:23)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.last_type
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'sys' has no attribute 'last_type'
>>> sys.last_type
<class 'AttributeError'>

ChrisA


From bc at freeuk.com  Fri May 18 13:27:40 2018
From: bc at freeuk.com (bartc)
Date: Fri, 18 May 2018 18:27:40 +0100
Subject: what does := means simply?
In-Reply-To: <mailman.205.1526654858.2761.python-list@python.org>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkdjc$fka$10@blaine.gmane.org>
 <mailman.167.1526577723.2761.python-list@python.org>
 <NQpLC.180984$oo.95504@fx35.am4> <pdlb7l$3fh$2@blaine.gmane.org>
 <mailman.186.1526608074.2761.python-list@python.org>
 <avyLC.201959$Z64.75842@fx36.am4> <pdmgvh$3fh$3@blaine.gmane.org>
 <mailman.199.1526646718.2761.python-list@python.org>
 <NyBLC.259028$Xa4.208590@fx29.am4>
 <CAPTjJmoU9EUcOXT4ZcfrXep0UWN1U5fpngzj_oO6qEezc3eG2A@mail.gmail.com>
 <mailman.205.1526654858.2761.python-list@python.org>
Message-ID: <72ELC.189741$eg.62291@fx43.am4>

On 18/05/2018 15:47, Chris Angelico wrote:
> On Sat, May 19, 2018 at 12:37 AM, bartc <bc at freeuk.com> wrote:
>> Have a look at some of the implementations here (to test some Mandelbrot
>> benchmark):
>>
>> https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html
>>
>> The three Python examples all use 'import sys' and 'import multiprocessing',
>> none of which I can find any trace of as any sort of files let alone .py.
>> One of them also uses 'import array', which I can't find either.
> 
> I guess you didn't look very hard.
> 
>>>> import multiprocessing
>>>> multiprocessing.__file__
> '/usr/local/lib/python3.8/multiprocessing/__init__.py'

But you have to load it first to find out. (And if you follow nested 
imports, you will eventually get to those that don't have a .py file.)

>>>> import array
>>>> array.__file__
> '/usr/local/lib/python3.8/lib-dynload/array.cpython-38m-x86_64-linux-gnu.so'

I get "module 'array' has no attribute '__file__'".

However, if I load sys, multiprocessing and array, then print 
sys.modules, I get a very long list of modules, at which point anyone 
thinking of emulating the behaviour of those modules would promptly give up.

------------------------

(BTW here's a port of that benchmark based on the Lua code:

   https://pastebin.com/raw/ivDaKudX

The actual language is not relevant, as this is clear enough that it 
could probably be re-implemented on anything. The 'files' module is only 
needed for openfile, closefile, and 'outbyte', which should be standard 
in any language. ('writebytes' might not be, so that was changed to a loop.)

The point of all this: writing clean simple code has a big advantage, 
and I think my version is one of the cleanest (even though it writes to 
a file, not the console).

Although it should be pointed out that these programs are pulling out 
all the stops in order to get the best performance; clarity wasn't a 
priority. But they should all use the same algorithm (to be within the 
rules), and it is that we're trying to extract.)

-- 
bartc


From rosuav at gmail.com  Fri May 18 14:36:21 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 19 May 2018 04:36:21 +1000
Subject: what does := means simply?
In-Reply-To: <72ELC.189741$eg.62291@fx43.am4>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkdjc$fka$10@blaine.gmane.org>
 <mailman.167.1526577723.2761.python-list@python.org>
 <NQpLC.180984$oo.95504@fx35.am4> <pdlb7l$3fh$2@blaine.gmane.org>
 <mailman.186.1526608074.2761.python-list@python.org>
 <avyLC.201959$Z64.75842@fx36.am4> <pdmgvh$3fh$3@blaine.gmane.org>
 <mailman.199.1526646718.2761.python-list@python.org>
 <NyBLC.259028$Xa4.208590@fx29.am4>
 <CAPTjJmoU9EUcOXT4ZcfrXep0UWN1U5fpngzj_oO6qEezc3eG2A@mail.gmail.com>
 <mailman.205.1526654858.2761.python-list@python.org>
 <72ELC.189741$eg.62291@fx43.am4>
Message-ID: <CAPTjJmr=vpEWbv8Y_9adexPZ91r46=84WS+R20tz_SF3xFG2Rg@mail.gmail.com>

On Sat, May 19, 2018 at 3:27 AM, bartc <bc at freeuk.com> wrote:
> On 18/05/2018 15:47, Chris Angelico wrote:
>>
>> On Sat, May 19, 2018 at 12:37 AM, bartc <bc at freeuk.com> wrote:
>>>
>>> Have a look at some of the implementations here (to test some Mandelbrot
>>> benchmark):
>>>
>>>
>>> https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html
>>>
>>> The three Python examples all use 'import sys' and 'import
>>> multiprocessing',
>>> none of which I can find any trace of as any sort of files let alone .py.
>>> One of them also uses 'import array', which I can't find either.
>>
>>
>> I guess you didn't look very hard.
>>
>>>>> import multiprocessing
>>>>> multiprocessing.__file__
>>
>> '/usr/local/lib/python3.8/multiprocessing/__init__.py'
>
>
> But you have to load it first to find out. (And if you follow nested
> imports, you will eventually get to those that don't have a .py file.)

... so?

> However, if I load sys, multiprocessing and array, then print sys.modules, I
> get a very long list of modules, at which point anyone thinking of emulating
> the behaviour of those modules would promptly give up.

Once again, you're confusing *porting* with *emulating*. If you don't
understand the difference between those two concepts, I recommend
spending some time with Wikipedia.

ChrisA


From tjreedy at udel.edu  Fri May 18 14:40:22 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 18 May 2018 14:40:22 -0400
Subject: Fwd: sys module does not contain ps1
In-Reply-To: <CA+EVXgs8EzzB74pnuCCfQ2ZA7c6jmGQE8-Gx=VXvP+-vspHFbg@mail.gmail.com>
References: <CA+EVXgvexHBEmwN19n+ustzDNqefAjAfPrUO08qWK=QwGAf2qQ@mail.gmail.com>
 <CA+EVXgs8EzzB74pnuCCfQ2ZA7c6jmGQE8-Gx=VXvP+-vspHFbg@mail.gmail.com>
Message-ID: <pdn6il$4l7$1@blaine.gmane.org>

On 5/18/2018 7:40 AM, Alferdize wrote:
> ---------- Forwarded message ----------
> From: Alferdize <simonandrew132 at gmail.com>
> Date: Thu, May 17, 2018 at 10:13 PM
> Subject: sys module does not contain ps1
> To: python-list at python.org
> 
> 
> It is giving error like I have given below
>>>> import sys
>>>> sys.ps1
> Traceback (most recent call last):
>    File "<pyshell#1>", line 1, in <module>
>      sys.ps1
> AttributeError: module 'sys' has no attribute 'ps1'

The docs say
"""
sys.ps1
sys.ps2

     Strings specifying the primary and secondary prompt of the 
interpreter. These are only defined if the interpreter is in interactive 
mode.
"""
You must be running your code in a program, perhaps IDLE, that simulates 
the interpreter's interactive mode, but which actually runs your code in 
a Python interpreter running in non-interactive mode.

-- 
Terry Jan Reedy



From bc at freeuk.com  Fri May 18 14:48:23 2018
From: bc at freeuk.com (bartc)
Date: Fri, 18 May 2018 19:48:23 +0100
Subject: what does := means simply?
In-Reply-To: <72ELC.189741$eg.62291@fx43.am4>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkdjc$fka$10@blaine.gmane.org>
 <mailman.167.1526577723.2761.python-list@python.org>
 <NQpLC.180984$oo.95504@fx35.am4> <pdlb7l$3fh$2@blaine.gmane.org>
 <mailman.186.1526608074.2761.python-list@python.org>
 <avyLC.201959$Z64.75842@fx36.am4> <pdmgvh$3fh$3@blaine.gmane.org>
 <mailman.199.1526646718.2761.python-list@python.org>
 <NyBLC.259028$Xa4.208590@fx29.am4>
 <CAPTjJmoU9EUcOXT4ZcfrXep0UWN1U5fpngzj_oO6qEezc3eG2A@mail.gmail.com>
 <mailman.205.1526654858.2761.python-list@python.org>
 <72ELC.189741$eg.62291@fx43.am4>
Message-ID: <PdFLC.294114$6D.258692@fx19.am4>

On 18/05/2018 18:27, bartc wrote:

> (BTW here's a port of that benchmark based on the Lua code:
> 
>  ? https://pastebin.com/raw/ivDaKudX

And here's the payoff: I was able to use this version to port it to 
Python. One which works better the the originals, as they wrote output 
to the screen (/binary/ output) which I found difficult to capture into 
an actual ppm file in order to test it worked.

The translation was straightforward, EXCEPT that I wasted an hour trying 
to figure out to write /a single byte/ to a file. The following 
eventually worked, using a binary file as a text one had Unicode 
problems, but it's still hacky.

Note this version doesn't use any imports at all.

----------------------------------------------------------------

# For Python 3 (it'll work on Python 2 but give the wrong results)

n = 200                # adjust this for output size: n * n pixels
outfile = "test.ppm"   # adjust for output file name
end = 0       	       # lines containing 'end' can be removed

def start():
     m = 2/n
     ba = 1<<(n%8+1)
     bb = 1<<(8-n%8)

     f = open(outfile,"wb")

     f.write(b"P4\n")
     f.write((str(n)+" "+str(n)+"\n").encode())

     for y in range(n):
         ci = y*m-1
         b = 1

         for x in range(n):
             cr = x*m-1.5
             zr = cr
             zi = ci
             zrq = cr*cr
             ziq = ci*ci
             b <<= 1
             for i in range(1,50):
                 zi = zr*zi*2+ci
                 zr = zrq-ziq+cr
                 ziq = zi*zi
                 zrq = zr*zr
                 if zrq+ziq>4:
                     b +=1
                     break
                 end
             end
             if b>=256:
                 f.write(bytes([511-b]))
                 b = 1
             end
         end
         if b != 1:
             f.write(bytes([(ba-b)*bb]))
         end
     end
     f.close()
end

start()



From bc at freeuk.com  Fri May 18 14:53:59 2018
From: bc at freeuk.com (bartc)
Date: Fri, 18 May 2018 19:53:59 +0100
Subject: what does := means simply?
In-Reply-To: <mailman.214.1526668590.2761.python-list@python.org>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkdjc$fka$10@blaine.gmane.org>
 <mailman.167.1526577723.2761.python-list@python.org>
 <NQpLC.180984$oo.95504@fx35.am4> <pdlb7l$3fh$2@blaine.gmane.org>
 <mailman.186.1526608074.2761.python-list@python.org>
 <avyLC.201959$Z64.75842@fx36.am4> <pdmgvh$3fh$3@blaine.gmane.org>
 <mailman.199.1526646718.2761.python-list@python.org>
 <NyBLC.259028$Xa4.208590@fx29.am4>
 <CAPTjJmoU9EUcOXT4ZcfrXep0UWN1U5fpngzj_oO6qEezc3eG2A@mail.gmail.com>
 <mailman.205.1526654858.2761.python-list@python.org>
 <72ELC.189741$eg.62291@fx43.am4>
 <CAPTjJmr=vpEWbv8Y_9adexPZ91r46=84WS+R20tz_SF3xFG2Rg@mail.gmail.com>
 <mailman.214.1526668590.2761.python-list@python.org>
Message-ID: <3jFLC.204944$Z64.107877@fx36.am4>

On 18/05/2018 19:36, Chris Angelico wrote:
> On Sat, May 19, 2018 at 3:27 AM, bartc <bc at freeuk.com> wrote:

> Once again, you're confusing *porting* with *emulating*.

This is the point. Those libraries are specific to Python and cannot be 
ported.

And very often they don't just provide general support that can be 
found, in different forms, in any target language, but is also specific.

Then if you are still porting your application, rather than rewriting or 
heavily adapting, you will need to emulate what they do.

> If you don't
> understand the difference between those two concepts, I recommend
> spending some time with Wikipedia.

And I recommend you doing some actual porting from Python or any other 
big language.

-- 
bartc


From rosuav at gmail.com  Fri May 18 14:57:41 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 19 May 2018 04:57:41 +1000
Subject: what does := means simply?
In-Reply-To: <PdFLC.294114$6D.258692@fx19.am4>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkdjc$fka$10@blaine.gmane.org>
 <mailman.167.1526577723.2761.python-list@python.org>
 <NQpLC.180984$oo.95504@fx35.am4> <pdlb7l$3fh$2@blaine.gmane.org>
 <mailman.186.1526608074.2761.python-list@python.org>
 <avyLC.201959$Z64.75842@fx36.am4> <pdmgvh$3fh$3@blaine.gmane.org>
 <mailman.199.1526646718.2761.python-list@python.org>
 <NyBLC.259028$Xa4.208590@fx29.am4>
 <CAPTjJmoU9EUcOXT4ZcfrXep0UWN1U5fpngzj_oO6qEezc3eG2A@mail.gmail.com>
 <mailman.205.1526654858.2761.python-list@python.org>
 <72ELC.189741$eg.62291@fx43.am4> <PdFLC.294114$6D.258692@fx19.am4>
Message-ID: <CAPTjJmqBFB4rhu5Xsieotb=jgii1mxB8Hph7=OvsSNh70aajLA@mail.gmail.com>

On Sat, May 19, 2018 at 4:48 AM, bartc <bc at freeuk.com> wrote:
> The translation was straightforward, EXCEPT that I wasted an hour trying to
> figure out to write /a single byte/ to a file. The following eventually
> worked, using a binary file as a text one had Unicode problems, but it's
> still hacky.

You can't write a single byte to a text file, because text files don't
store bytes. I'm not sure which part of this took you an hour to
figure out.

> # For Python 3 (it'll work on Python 2 but give the wrong results)

What does "work" mean? If it gives the wrong results, how is it working?

> end = 0                # lines containing 'end' can be removed

You're not writing Python code here.

ChrisA


From rosuav at gmail.com  Fri May 18 15:00:50 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 19 May 2018 05:00:50 +1000
Subject: what does := means simply?
In-Reply-To: <3jFLC.204944$Z64.107877@fx36.am4>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkdjc$fka$10@blaine.gmane.org>
 <mailman.167.1526577723.2761.python-list@python.org>
 <NQpLC.180984$oo.95504@fx35.am4> <pdlb7l$3fh$2@blaine.gmane.org>
 <mailman.186.1526608074.2761.python-list@python.org>
 <avyLC.201959$Z64.75842@fx36.am4> <pdmgvh$3fh$3@blaine.gmane.org>
 <mailman.199.1526646718.2761.python-list@python.org>
 <NyBLC.259028$Xa4.208590@fx29.am4>
 <CAPTjJmoU9EUcOXT4ZcfrXep0UWN1U5fpngzj_oO6qEezc3eG2A@mail.gmail.com>
 <mailman.205.1526654858.2761.python-list@python.org>
 <72ELC.189741$eg.62291@fx43.am4>
 <CAPTjJmr=vpEWbv8Y_9adexPZ91r46=84WS+R20tz_SF3xFG2Rg@mail.gmail.com>
 <mailman.214.1526668590.2761.python-list@python.org>
 <3jFLC.204944$Z64.107877@fx36.am4>
Message-ID: <CAPTjJmp1mskroB9b2Z7Pvtkb4quLQnepMocus_u1h70hKbrVEA@mail.gmail.com>

On Sat, May 19, 2018 at 4:53 AM, bartc <bc at freeuk.com> wrote:
> On 18/05/2018 19:36, Chris Angelico wrote:
>>
>> On Sat, May 19, 2018 at 3:27 AM, bartc <bc at freeuk.com> wrote:
>
>
>> Once again, you're confusing *porting* with *emulating*.
>
>
> This is the point. Those libraries are specific to Python and cannot be
> ported.
>
> And very often they don't just provide general support that can be found, in
> different forms, in any target language, but is also specific.
>
> Then if you are still porting your application, rather than rewriting or
> heavily adapting, you will need to emulate what they do.
>
>> If you don't
>> understand the difference between those two concepts, I recommend
>> spending some time with Wikipedia.
>
>
> And I recommend you doing some actual porting from Python or any other big
> language.
>

I've ported code from 8086 assembly code to C++, from C to Pike, from
DeScribe Macro Language to REXX, and many other pairings, some obscure
and some not. Each time, the goal has been to port the PROGRAM, not
the underlying libraries. The goal is to reimplement the algorithm in
a new language, not to blithely rewrite one line of code at a time
using the new language's syntax.

I have a quarter century of experience with a quarter million
languages. (Okay, that's a bit of a Threepio exaggeration, but a lot
of languages.) Porting code from one language to another is not new to
me.

ChrisA


From abrault at mapgears.com  Fri May 18 15:15:58 2018
From: abrault at mapgears.com (Alexandre Brault)
Date: Fri, 18 May 2018 15:15:58 -0400
Subject: what does := means simply?
In-Reply-To: <PdFLC.294114$6D.258692@fx19.am4>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <pdiueb$fka$5@blaine.gmane.org>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkdjc$fka$10@blaine.gmane.org>
 <mailman.167.1526577723.2761.python-list@python.org>
 <NQpLC.180984$oo.95504@fx35.am4> <pdlb7l$3fh$2@blaine.gmane.org>
 <mailman.186.1526608074.2761.python-list@python.org>
 <avyLC.201959$Z64.75842@fx36.am4> <pdmgvh$3fh$3@blaine.gmane.org>
 <mailman.199.1526646718.2761.python-list@python.org>
 <NyBLC.259028$Xa4.208590@fx29.am4>
 <CAPTjJmoU9EUcOXT4ZcfrXep0UWN1U5fpngzj_oO6qEezc3eG2A@mail.gmail.com>
 <mailman.205.1526654858.2761.python-list@python.org>
 <72ELC.189741$eg.62291@fx43.am4> <PdFLC.294114$6D.258692@fx19.am4>
Message-ID: <a4c8ca45-3d8d-ec90-9faf-61caee727363@mapgears.com>

On 2018-05-18 02:48 PM, bartc wrote:
> On 18/05/2018 18:27, bartc wrote:
>
>> (BTW here's a port of that benchmark based on the Lua code:
>>
>> ?? https://pastebin.com/raw/ivDaKudX
>
> And here's the payoff: I was able to use this version to port it to
> Python. One which works better the the originals, as they wrote output
> to the screen (/binary/ output) which I found difficult to capture
> into an actual ppm file in order to test it worked.
>
> The translation was straightforward, EXCEPT that I wasted an hour
> trying to figure out to write /a single byte/ to a file. The following
> eventually worked, using a binary file as a text one had Unicode
> problems, but it's still hacky.
>
> Note this version doesn't use any imports at all.
Except your version doesn't read its parameter from the command line
args and doesn't output to standard output, which all of the others do.
That's why the other Python versions of that code imported sys: Because
that's how you read from commandline args and write bytes to standard
output in Python. You don't need to know *exactly* how sys works to have
an idea of what sys.argv and sys.stdout do


From jladasky at itu.edu  Fri May 18 16:53:45 2018
From: jladasky at itu.edu (jladasky at itu.edu)
Date: Fri, 18 May 2018 13:53:45 -0700 (PDT)
Subject: About: from sklearn import linear_model ModuleNotFoundError: No
 module named sklearn
In-Reply-To: <mailman.140.1526558039.2761.python-list@python.org>
References: <CACt-=weCYHcMykSfjULCtdc645xAU6ZVeLBAvy2OeoN6QnR4Aw@mail.gmail.com>
 <mailman.140.1526558039.2761.python-list@python.org>
Message-ID: <7b08dff8-8422-49b8-9c91-eb83a7159973@googlegroups.com>

On Thursday, May 17, 2018 at 4:54:11 AM UTC-7, Jpn Jha wrote:
> Dear Team
> Please attached  Python_PyCharm  Interpreter doc and zoom it .
> 
> The screen shots are explanatory.

The Python mailing list is text-only.  Your screen shots were removed.

In general, please don't use screenshots when asking for programming assistance on the Internet.  Aside from the extra bandwidth that screen shots consume, it is also impossible for people who are trying to help you to cut and paste code from a screen shot.  Use text.


From bc at freeuk.com  Fri May 18 17:12:47 2018
From: bc at freeuk.com (bartc)
Date: Fri, 18 May 2018 22:12:47 +0100
Subject: what does := means simply?
In-Reply-To: <mailman.218.1526671307.2761.python-list@python.org>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkdjc$fka$10@blaine.gmane.org>
 <mailman.167.1526577723.2761.python-list@python.org>
 <NQpLC.180984$oo.95504@fx35.am4> <pdlb7l$3fh$2@blaine.gmane.org>
 <mailman.186.1526608074.2761.python-list@python.org>
 <avyLC.201959$Z64.75842@fx36.am4> <pdmgvh$3fh$3@blaine.gmane.org>
 <mailman.199.1526646718.2761.python-list@python.org>
 <NyBLC.259028$Xa4.208590@fx29.am4>
 <CAPTjJmoU9EUcOXT4ZcfrXep0UWN1U5fpngzj_oO6qEezc3eG2A@mail.gmail.com>
 <mailman.205.1526654858.2761.python-list@python.org>
 <72ELC.189741$eg.62291@fx43.am4> <PdFLC.294114$6D.258692@fx19.am4>
 <a4c8ca45-3d8d-ec90-9faf-61caee727363@mapgears.com>
 <mailman.218.1526671307.2761.python-list@python.org>
Message-ID: <alHLC.125421$7b4.13323@fx12.am4>

On 18/05/2018 20:15, Alexandre Brault wrote:
> On 2018-05-18 02:48 PM, bartc wrote:

>> Note this version doesn't use any imports at all.
> Except your version doesn't read its parameter from the command line
> args and doesn't output to standard output, which all of the others do.
> That's why the other Python versions of that code imported sys: Because
> that's how you read from commandline args and write bytes to standard
> output in Python. You don't need to know *exactly* how sys works to have
> an idea of what sys.argv and sys.stdout do

My version wasn't an entry in the Shoot-out game.

The command line input was left out as, if someone wants to port the 
algorithm to their language, they will know how it's done. (And each one 
will do that messy bit of input a little differently.)

Capturing the output as I said was problematic, and I needed that in 
order to display the .ppm output so that I could see it. Maybe in a 
Linux environment it can be piped into a program to do that. But that's 
not what I used; I needed an actual .ppm file.

(Something went wrong with the header when trying to direct it to a 
file. But directing binary data to a text display, with arbitrary byte 
sequences might be some escape code that does undesirable things, is a 
no-no for me.)

-- 
bart


From bc at freeuk.com  Fri May 18 17:53:06 2018
From: bc at freeuk.com (bartc)
Date: Fri, 18 May 2018 22:53:06 +0100
Subject: what does := means simply?
In-Reply-To: <mailman.216.1526669865.2761.python-list@python.org>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkdjc$fka$10@blaine.gmane.org>
 <mailman.167.1526577723.2761.python-list@python.org>
 <NQpLC.180984$oo.95504@fx35.am4> <pdlb7l$3fh$2@blaine.gmane.org>
 <mailman.186.1526608074.2761.python-list@python.org>
 <avyLC.201959$Z64.75842@fx36.am4> <pdmgvh$3fh$3@blaine.gmane.org>
 <mailman.199.1526646718.2761.python-list@python.org>
 <NyBLC.259028$Xa4.208590@fx29.am4>
 <CAPTjJmoU9EUcOXT4ZcfrXep0UWN1U5fpngzj_oO6qEezc3eG2A@mail.gmail.com>
 <mailman.205.1526654858.2761.python-list@python.org>
 <72ELC.189741$eg.62291@fx43.am4> <PdFLC.294114$6D.258692@fx19.am4>
 <CAPTjJmqBFB4rhu5Xsieotb=jgii1mxB8Hph7=OvsSNh70aajLA@mail.gmail.com>
 <mailman.216.1526669865.2761.python-list@python.org>
Message-ID: <ZWHLC.190031$eg.73535@fx43.am4>

On 18/05/2018 19:57, Chris Angelico wrote:
> On Sat, May 19, 2018 at 4:48 AM, bartc <bc at freeuk.com> wrote:
>> The translation was straightforward, EXCEPT that I wasted an hour trying to
>> figure out to write /a single byte/ to a file. The following eventually
>> worked, using a binary file as a text one had Unicode problems, but it's
>> still hacky.
> 
> You can't write a single byte to a text file, because text files don't
> store bytes. I'm not sure which part of this took you an hour to
> figure out.

I've worked with text files for 40 years. Now Python is telling me I've 
been doing it wrong all that time!

Look at the original code I posted from which this Python was based. 
That creates a file - just a file - without worrying about whether it's 
text or binary. Files are just collections of bytes, as far as the OS is 
concerned.

So what could be more natural than writing a byte to the end of a file?

(Note that this particular file format is a hybrid; it has a text header 
followed by binary data. This is not unusual; probably every binary 
format will contain text too.

A programming language - and one that's supposed to be easy - should 
take that in its stride.)

>> # For Python 3 (it'll work on Python 2 but give the wrong results)
> 
> What does "work" mean? If it gives the wrong results, how is it working?

It works in that Python 2 is not complaining about anything, and it 
finishes (very quickly too). But the output file is 3 times the size it 
should be, and contains the wrong data.

>> end = 0                # lines containing 'end' can be removed
> 
> You're not writing Python code here.

Sorry but I'm lost without the block terminators. I needed them to match 
the logic to the original. After I used them, I decided it looked better.

-- 
bartc


From chema at rinzewind.org  Fri May 18 18:24:55 2018
From: chema at rinzewind.org (=?iso-8859-1?Q?Jos=E9_Mar=EDa?= Mateos)
Date: Fri, 18 May 2018 18:24:55 -0400
Subject: syntax oddities
In-Reply-To: <alpine.LNX.2.20.1805170751540.11458@salmo.appl-ecosys.com>
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org>
 <CA+og5uqt+R0w5=2jfw7H-9kHA=vGS15rUNXcwGkr_jSj1aMcUg@mail.gmail.com>
 <CAPTjJmq3CNLOL2WisScptnFyPbgoYW4RLhLDx5MryQ3kGHXYow@mail.gmail.com>
 <alpine.LNX.2.20.1805170751540.11458@salmo.appl-ecosys.com>
Message-ID: <20180518222455.GA5306@miniequipaje>

On Thu, May 17, 2018 at 07:56:41AM -0700, Rich Shepard wrote:
> Allow me to add an additional reason for trimming and responding 
> beneath each quoted section: it puts the response in the proper 
> context.

And another one I learned recently on a similar conversation on another 
mailing list (that of the e-mail client I'm using right now): it is very 
useful for searches. Every e-mail contains just the right amount of text 
necessary to be properly read, as opposed to a more or less complete 
copy of the current thread.

Cheers,

-- 
Jos? Mar?a Mateos
https://rinzewind.org/blog-es || https://rinzewind.org/blog-en


From chema at rinzewind.org  Fri May 18 18:34:05 2018
From: chema at rinzewind.org (=?iso-8859-1?Q?Jos=E9_Mar=EDa?= Mateos)
Date: Fri, 18 May 2018 18:34:05 -0400
Subject: syntax oddities
In-Reply-To: <pdmpho$1at$1@blaine.gmane.org>
References: <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org>
 <2d0sfdh2h3ki49koh2s667os2ug9tvp6e4@4ax.com>
 <CA+og5uq9_HBHPyacq5EHtM4qvrBWMKRrWOSq8cXt+jsLz4xATw@mail.gmail.com>
 <be6291dd-968c-fe23-d8ff-d73f57d16513@kynesim.co.uk>
 <CACac1F-vHtFt_rzELBpxffJrSmZiFv47ftJEz2fVf0nWufo18g@mail.gmail.com>
 <pdmk7a$3fh$4@blaine.gmane.org> <pdmpho$1at$1@blaine.gmane.org>
Message-ID: <20180518223405.GC5306@miniequipaje>

On Fri, May 18, 2018 at 02:55:52PM +0000, Grant Edwards wrote:
> You work someplace pretty unique.  Everyplace I've worked has done the
> whole top-posting and include the whole damn thread in reverse order
> thing.  It just doesn't work.  The attached reverse-chronological
> history doesn't seem to do _any_ good at all.  AFAICT, nobody ever
> reads it.  Occasionally somebody will refer opaquely to something with
> the phrase "see below" -- but there's never any indication to _what_
> among the fifteen messages and thirty attachements they are referring.

In my experience, this "e-mail-that-contains-the-entire-conversation" is 
useful if and only if you happen to receive a forwarded copy so you know 
something you were not previously aware of. Otherwise, replies just 
accumulate past conversations because people are too lazy to bother.

I wouldn't dare inline-replying in my current Outlook corporate 
environment. I just top-post, don't trim, go with the flow.

Cheers,

-- 
Jos? Mar?a Mateos
https://rinzewind.org/blog-es || https://rinzewind.org/blog-en


From darcy at VybeNetworks.com  Fri May 18 19:12:40 2018
From: darcy at VybeNetworks.com (D'Arcy Cain)
Date: Fri, 18 May 2018 19:12:40 -0400
Subject: Proper email etiquette
In-Reply-To: <20180518222455.GA5306@miniequipaje>
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org>
 <CA+og5uqt+R0w5=2jfw7H-9kHA=vGS15rUNXcwGkr_jSj1aMcUg@mail.gmail.com>
 <CAPTjJmq3CNLOL2WisScptnFyPbgoYW4RLhLDx5MryQ3kGHXYow@mail.gmail.com>
 <alpine.LNX.2.20.1805170751540.11458@salmo.appl-ecosys.com>
 <20180518222455.GA5306@miniequipaje>
Message-ID: <fecd092f-5092-5c68-f955-39d90d002939@VybeNetworks.com>

On 2018-05-18 06:24 PM, Jos? Mar?a Mateos wrote:
> And another one I learned recently on a similar conversation on another 
> mailing list (that of the e-mail client I'm using right now): it is very 
> useful for searches. Every e-mail contains just the right amount of text 
> necessary to be properly read, as opposed to a more or less complete 
> copy of the current thread.
Another good idea is to change the subject when the topic changes.

-- 
D'Arcy J.M. Cain
Vybe Networks Inc.
http://www.VybeNetworks.com/
IM:darcy at Vex.Net VoIP: sip:darcy at VybeNetworks.com


From rosuav at gmail.com  Fri May 18 20:00:33 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 19 May 2018 10:00:33 +1000
Subject: what does := means simply?
In-Reply-To: <ZWHLC.190031$eg.73535@fx43.am4>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <mailman.130.1526529433.2761.python-list@python.org>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkdjc$fka$10@blaine.gmane.org>
 <mailman.167.1526577723.2761.python-list@python.org>
 <NQpLC.180984$oo.95504@fx35.am4> <pdlb7l$3fh$2@blaine.gmane.org>
 <mailman.186.1526608074.2761.python-list@python.org>
 <avyLC.201959$Z64.75842@fx36.am4> <pdmgvh$3fh$3@blaine.gmane.org>
 <mailman.199.1526646718.2761.python-list@python.org>
 <NyBLC.259028$Xa4.208590@fx29.am4>
 <CAPTjJmoU9EUcOXT4ZcfrXep0UWN1U5fpngzj_oO6qEezc3eG2A@mail.gmail.com>
 <mailman.205.1526654858.2761.python-list@python.org>
 <72ELC.189741$eg.62291@fx43.am4> <PdFLC.294114$6D.258692@fx19.am4>
 <CAPTjJmqBFB4rhu5Xsieotb=jgii1mxB8Hph7=OvsSNh70aajLA@mail.gmail.com>
 <mailman.216.1526669865.2761.python-list@python.org>
 <ZWHLC.190031$eg.73535@fx43.am4>
Message-ID: <CAPTjJmrWxXvmGaFdqFvekUrL1SFpwwfHhvNcPkJtAOHa8e+7Mw@mail.gmail.com>

On Sat, May 19, 2018 at 7:53 AM, bartc <bc at freeuk.com> wrote:
> I've worked with text files for 40 years. Now Python is telling me I've been
> doing it wrong all that time!
>
> Look at the original code I posted from which this Python was based. That
> creates a file - just a file - without worrying about whether it's text or
> binary. Files are just collections of bytes, as far as the OS is concerned.
>
> So what could be more natural than writing a byte to the end of a file?

So, you create a file without worrying about whether it's text or
binary, and you add a byte to the end of the file. That means you're
treating it as a binary file, not as a text file. Do you understand
that?

ChrisA


From steve+comp.lang.python at pearwood.info  Fri May 18 20:03:29 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sat, 19 May 2018 00:03:29 +0000 (UTC)
Subject: what does := means simply?
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <O7eLC.226881$Pv4.24578@fx23.am4>
 <CAPTjJmqLQPfw1wPDHRBS5oxUyHpMypCqSO6wgk561E3Cc2bcTg@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkdjc$fka$10@blaine.gmane.org>
 <mailman.167.1526577723.2761.python-list@python.org>
 <NQpLC.180984$oo.95504@fx35.am4> <pdlb7l$3fh$2@blaine.gmane.org>
 <mailman.186.1526608074.2761.python-list@python.org>
 <avyLC.201959$Z64.75842@fx36.am4> <pdmgvh$3fh$3@blaine.gmane.org>
 <mailman.199.1526646718.2761.python-list@python.org>
 <NyBLC.259028$Xa4.208590@fx29.am4>
 <CAPTjJmoU9EUcOXT4ZcfrXep0UWN1U5fpngzj_oO6qEezc3eG2A@mail.gmail.com>
 <mailman.205.1526654858.2761.python-list@python.org>
 <72ELC.189741$eg.62291@fx43.am4> <PdFLC.294114$6D.258692@fx19.am4>
 <CAPTjJmqBFB4rhu5Xsieotb=jgii1mxB8Hph7=OvsSNh70aajLA@mail.gmail.com>
 <mailman.216.1526669865.2761.python-list@python.org>
 <ZWHLC.190031$eg.73535@fx43.am4>
Message-ID: <pdnpkh$3fh$5@blaine.gmane.org>

On Fri, 18 May 2018 22:53:06 +0100, bartc wrote:

> I've worked with text files for 40 years. Now Python is telling me I've
> been doing it wrong all that time!

Welcome to the 20th Century! We interchange text and data with
people from all over the world now, and one or two of them use
characters that aren't ASCII!

Start here:

https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/

or https://tinyurl.com/h8yg9d7


Then follow up with:

https://nedbatchelder.com/text/unipain.html



-- 
Steve



From bc at freeuk.com  Fri May 18 20:55:39 2018
From: bc at freeuk.com (bartc)
Date: Sat, 19 May 2018 01:55:39 +0100
Subject: what does := means simply?
In-Reply-To: <mailman.221.1526688036.2761.python-list@python.org>
References: <CADrxXX=5Pg1MSA437UXXJar0CUuKXV8Z6xac2A=jvcLABTy8Nw@mail.gmail.com>
 <mailman.150.1526565834.2761.python-list@python.org>
 <EEgLC.382764$gE6.296392@fx06.am4> <pdkdjc$fka$10@blaine.gmane.org>
 <mailman.167.1526577723.2761.python-list@python.org>
 <NQpLC.180984$oo.95504@fx35.am4> <pdlb7l$3fh$2@blaine.gmane.org>
 <mailman.186.1526608074.2761.python-list@python.org>
 <avyLC.201959$Z64.75842@fx36.am4> <pdmgvh$3fh$3@blaine.gmane.org>
 <mailman.199.1526646718.2761.python-list@python.org>
 <NyBLC.259028$Xa4.208590@fx29.am4>
 <CAPTjJmoU9EUcOXT4ZcfrXep0UWN1U5fpngzj_oO6qEezc3eG2A@mail.gmail.com>
 <mailman.205.1526654858.2761.python-list@python.org>
 <72ELC.189741$eg.62291@fx43.am4> <PdFLC.294114$6D.258692@fx19.am4>
 <CAPTjJmqBFB4rhu5Xsieotb=jgii1mxB8Hph7=OvsSNh70aajLA@mail.gmail.com>
 <mailman.216.1526669865.2761.python-list@python.org>
 <ZWHLC.190031$eg.73535@fx43.am4>
 <CAPTjJmrWxXvmGaFdqFvekUrL1SFpwwfHhvNcPkJtAOHa8e+7Mw@mail.gmail.com>
 <mailman.221.1526688036.2761.python-list@python.org>
Message-ID: <gCKLC.200167$Qg7.22084@fx08.am4>

On 19/05/2018 01:00, Chris Angelico wrote:
> On Sat, May 19, 2018 at 7:53 AM, bartc <bc at freeuk.com> wrote:
>> I've worked with text files for 40 years. Now Python is telling me I've been
>> doing it wrong all that time!
>>
>> Look at the original code I posted from which this Python was based. That
>> creates a file - just a file - without worrying about whether it's text or
>> binary. Files are just collections of bytes, as far as the OS is concerned.
>>
>> So what could be more natural than writing a byte to the end of a file?
> 
> So, you create a file without worrying about whether it's text or
> binary, and you add a byte to the end of the file. That means you're
> treating it as a binary file, not as a text file. Do you understand
> that?

Well I /don't/ worry about, but the reason is that long ago I switched 
to using binary mode for all files. (My 'createfile' function shown 
after my sig shows how it works. It's a thin wrapper around C's fopen, 
and it's C that has this thing about text and binary files.)

But in Python, even as a binary file I had some trouble writing to it, 
as it's fussy when dealing with strings and bytearrays and bytes and 
array.arrays all with their own rules.

-- 
bartc

global function createfile(name, options="wb") =
     if not name.isstring or name="" then
         return nil
     fi

     return fopen(name,options)
end





From steve+comp.lang.python at pearwood.info  Fri May 18 21:00:03 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sat, 19 May 2018 01:00:03 +0000 (UTC)
Subject: what does := means simply?
References: <pdmgvh$3fh$3@blaine.gmane.org>
 <mailman.199.1526646718.2761.python-list@python.org>
 <NyBLC.259028$Xa4.208590@fx29.am4>
 <CAPTjJmoU9EUcOXT4ZcfrXep0UWN1U5fpngzj_oO6qEezc3eG2A@mail.gmail.com>
 <mailman.205.1526654858.2761.python-list@python.org>
 <72ELC.189741$eg.62291@fx43.am4> <PdFLC.294114$6D.258692@fx19.am4>
 <CAPTjJmqBFB4rhu5Xsieotb=jgii1mxB8Hph7=OvsSNh70aajLA@mail.gmail.com>
 <mailman.216.1526669865.2761.python-list@python.org>
 <ZWHLC.190031$eg.73535@fx43.am4>
 <dlrufd9sm0v230qses3mlitcf324cu12v6@4ax.com>
Message-ID: <pdnsuj$3fh$6@blaine.gmane.org>

On Fri, 18 May 2018 20:42:05 -0400, Dennis Lee Bieber wrote:

> 	Unfortunately -- in the current era, "text" means "a defined 
encoding",

Text has ALWAYS meant "a defined encoding". It is just that for a long 
time, people could get away with assuming that the encoding they used was 
the *only* possible encoding, and using it implicitly without even 
thinking about it.

That One True Encoding is, of course, EBCDIC.

No, I kid, of course it is Mac-Roman.

Ha ha, no, just pulling your leg... of course it's ISO 8859-1 (not to be 
confused with ISO-8859-1, yes the hyphen is significant). Except for web 
browsers, which are required to interpret declarations of ISO 8859-1 as 
CP-1252 instead.

Actually, I'm still kidding around. Everyone knows the One True Encoding 
is ISCII. (That's not a typo.)



-- 
Steve



From bc at freeuk.com  Fri May 18 21:02:07 2018
From: bc at freeuk.com (bartc)
Date: Sat, 19 May 2018 02:02:07 +0100
Subject: what does := means simply?
In-Reply-To: <mailman.223.1526690534.2761.python-list@python.org>
References: <pdmgvh$3fh$3@blaine.gmane.org>
 <mailman.199.1526646718.2761.python-list@python.org>
 <NyBLC.259028$Xa4.208590@fx29.am4>
 <CAPTjJmoU9EUcOXT4ZcfrXep0UWN1U5fpngzj_oO6qEezc3eG2A@mail.gmail.com>
 <mailman.205.1526654858.2761.python-list@python.org>
 <72ELC.189741$eg.62291@fx43.am4> <PdFLC.294114$6D.258692@fx19.am4>
 <CAPTjJmqBFB4rhu5Xsieotb=jgii1mxB8Hph7=OvsSNh70aajLA@mail.gmail.com>
 <mailman.216.1526669865.2761.python-list@python.org>
 <ZWHLC.190031$eg.73535@fx43.am4> <dlrufd9sm0v230qses3mlitcf324cu12v6@4ax.com>
 <mailman.223.1526690534.2761.python-list@python.org>
Message-ID: <kIKLC.164193$ta2.7961@fx03.am4>

On 19/05/2018 01:42, Dennis Lee Bieber wrote:
> On Fri, 18 May 2018 22:53:06 +0100, bartc <bc at freeuk.com> declaimed the
> following:
> 
> 
>> I've worked with text files for 40 years. Now Python is telling me I've
>> been doing it wrong all that time!
>>
>> Look at the original code I posted from which this Python was based.
>> That creates a file - just a file - without worrying about whether it's
>> text or binary. Files are just collections of bytes, as far as the OS is
>> concerned.
> 
> 	And on Windows, there is a difference.
> 
> 	On Windows, sending a <lf> byte to a TEXT file will result in writing
> <cr><lf>. On Windows a new-line is indicated by that combination: <cr><lf>.

Are you sure that's Windows itself, and not just the C library? (Which 
was presumably trying to be helpful by making programs work on Unix and 
Windows without changes, but is actually a nuisance.)

Some Windows programs may need cr,lf, but I doubt they well convert 
between lf and cr,lf unless they use C file functions.

-- 
bartc


From bc at freeuk.com  Fri May 18 21:10:35 2018
From: bc at freeuk.com (bartc)
Date: Sat, 19 May 2018 02:10:35 +0100
Subject: what does := means simply?
In-Reply-To: <mailman.224.1526691745.2761.python-list@python.org>
References: <pdmgvh$3fh$3@blaine.gmane.org>
 <mailman.199.1526646718.2761.python-list@python.org>
 <NyBLC.259028$Xa4.208590@fx29.am4>
 <CAPTjJmoU9EUcOXT4ZcfrXep0UWN1U5fpngzj_oO6qEezc3eG2A@mail.gmail.com>
 <mailman.205.1526654858.2761.python-list@python.org>
 <72ELC.189741$eg.62291@fx43.am4> <PdFLC.294114$6D.258692@fx19.am4>
 <CAPTjJmqBFB4rhu5Xsieotb=jgii1mxB8Hph7=OvsSNh70aajLA@mail.gmail.com>
 <mailman.216.1526669865.2761.python-list@python.org>
 <ZWHLC.190031$eg.73535@fx43.am4> <dlrufd9sm0v230qses3mlitcf324cu12v6@4ax.com>
 <pdnsuj$3fh$6@blaine.gmane.org>
 <mailman.224.1526691745.2761.python-list@python.org>
Message-ID: <fQKLC.163818$ny5.147948@fx17.am4>

On 19/05/2018 02:00, Steven D'Aprano wrote:
> On Fri, 18 May 2018 20:42:05 -0400, Dennis Lee Bieber wrote:
> 
>> 	Unfortunately -- in the current era, "text" means "a defined
> encoding",
> 
> Text has ALWAYS meant "a defined encoding". It is just that for a long
> time, people could get away with assuming that the encoding they used was
> the *only* possible encoding, and using it implicitly without even
> thinking about it.
> 
> That One True Encoding is, of course, EBCDIC.
> 
> No, I kid, of course it is Mac-Roman.
> 
> Ha ha, no, just pulling your leg... of course it's ISO 8859-1 (not to be
> confused with ISO-8859-1, yes the hyphen is significant). Except for web
> browsers, which are required to interpret declarations of ISO 8859-1 as
> CP-1252 instead.
> 
> Actually, I'm still kidding around. Everyone knows the One True Encoding
> is ISCII. (That's not a typo.)

The .ppm (really .pbm) file which was the subject of this sub-thread has 
its header defined using ASCII. I don't think an EBCDIC 'P4' etc will work.

-- 
bartc


From rosuav at gmail.com  Fri May 18 21:26:31 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 19 May 2018 11:26:31 +1000
Subject: what does := means simply?
In-Reply-To: <fQKLC.163818$ny5.147948@fx17.am4>
References: <pdmgvh$3fh$3@blaine.gmane.org>
 <mailman.199.1526646718.2761.python-list@python.org>
 <NyBLC.259028$Xa4.208590@fx29.am4>
 <CAPTjJmoU9EUcOXT4ZcfrXep0UWN1U5fpngzj_oO6qEezc3eG2A@mail.gmail.com>
 <mailman.205.1526654858.2761.python-list@python.org>
 <72ELC.189741$eg.62291@fx43.am4> <PdFLC.294114$6D.258692@fx19.am4>
 <CAPTjJmqBFB4rhu5Xsieotb=jgii1mxB8Hph7=OvsSNh70aajLA@mail.gmail.com>
 <mailman.216.1526669865.2761.python-list@python.org>
 <ZWHLC.190031$eg.73535@fx43.am4>
 <dlrufd9sm0v230qses3mlitcf324cu12v6@4ax.com> <pdnsuj$3fh$6@blaine.gmane.org>
 <mailman.224.1526691745.2761.python-list@python.org>
 <fQKLC.163818$ny5.147948@fx17.am4>
Message-ID: <CAPTjJmq=5tt-BXXAYq7jbqCv4nAMpfP+wf-0QxMkkNk5802g5A@mail.gmail.com>

On Sat, May 19, 2018 at 11:10 AM, bartc <bc at freeuk.com> wrote:
> On 19/05/2018 02:00, Steven D'Aprano wrote:
>>
>> On Fri, 18 May 2018 20:42:05 -0400, Dennis Lee Bieber wrote:
>>
>>>         Unfortunately -- in the current era, "text" means "a defined
>>
>> encoding",
>>
>> Text has ALWAYS meant "a defined encoding". It is just that for a long
>> time, people could get away with assuming that the encoding they used was
>> the *only* possible encoding, and using it implicitly without even
>> thinking about it.
>>
>> That One True Encoding is, of course, EBCDIC.
>>
>> No, I kid, of course it is Mac-Roman.
>>
>> Ha ha, no, just pulling your leg... of course it's ISO 8859-1 (not to be
>> confused with ISO-8859-1, yes the hyphen is significant). Except for web
>> browsers, which are required to interpret declarations of ISO 8859-1 as
>> CP-1252 instead.
>>
>> Actually, I'm still kidding around. Everyone knows the One True Encoding
>> is ISCII. (That's not a typo.)
>
>
> The .ppm (really .pbm) file which was the subject of this sub-thread has its
> header defined using ASCII. I don't think an EBCDIC 'P4' etc will work.
>

"Defined using ASCII" is a tricky concept. There are a number of file
formats that have certain parts defined because of ASCII mnemonics,
but are actually defined numerically. The PNG format begins with the
four bytes 89 50 4E 47, chosen because three of those bytes represent
the letters "PNG" in ASCII. But it's defined as those byte values. The
first three represent "i&+" in EBCDIC, and that would be just as
valid, because you get the correct bytes.

Your file contains bytes. Not text.

ChrisA


From mike.junk.46 at att.net  Fri May 18 21:31:16 2018
From: mike.junk.46 at att.net (Mike McClain)
Date: Fri, 18 May 2018 18:31:16 -0700
Subject: decorat{or,ion}
In-Reply-To: <mailman.30.1526659203.31214.python-list@python.org>
References: <mailman.30.1526659203.31214.python-list@python.org>
Message-ID: <20180519013116.GA16615@playground>

    Let's say I want something that does most or all of foo's
functionality plus a little more and maybe tweek some of foo's
output, so I write a wrapper around foo and call it bar.
If inside bar are the call to foo, as well as methods baz(),
buz() and bug() that make their magic and bar ends up performing
as I want.

    If I understood correctly baz(), buz() and bug() plus the glue
that is bar are decorations around foo or bar is a decorator of foo.

    Apologies, I don't yet know how to show that foo and bar are
meant to be objects. I wrote my first fortran program in the 1960's
but this is my first attempt to delve into the world of OOP. At the
moment this world view feels like I imagine a grasshopper sees the
world through a miriad of lenses.

    For that matter, are baz(), buz() and bug() methods if they only
help bar get the job done but don't have a place in bar's interface?

Thanks again,
Mike
--
"Keep active but don't be afraid to occasionally indulge."
    - Jeralean Talley, America's oldest living woman


From sharan.basappa at gmail.com  Sat May 19 00:50:12 2018
From: sharan.basappa at gmail.com (Sharan Basappa)
Date: Fri, 18 May 2018 21:50:12 -0700 (PDT)
Subject: Numpy array
Message-ID: <4f03b757-ff98-4386-bd73-9acd85b0eb66@googlegroups.com>

This is regarding numpy array. I am a bit confused how parts of the array are being accessed in the example below.

1 import scipy as sp
2 data = sp.genfromtxt("web_traffic.tsv", delimiter="\t")
3 print(data[:10])
4 x = data[:,0]
5 y = data[:,1]

Apparently, line 3 prints the first 10 entries in the array
line 4 & 5 is to extract all rows but only 1st and second columns alone for x and y respectively.

I am confused as to how data[:10] gives the first 10 rows while data[:,0] gives all rows



From dieter at handshake.de  Sat May 19 02:22:59 2018
From: dieter at handshake.de (dieter)
Date: Sat, 19 May 2018 08:22:59 +0200
Subject: decorat{or,ion}
References: <mailman.30.1526659203.31214.python-list@python.org>
 <20180519013116.GA16615@playground>
Message-ID: <87in7kmaf0.fsf@handshake.de>

Mike McClain <mike.junk.46 at att.net> writes:
>     Let's say I want something that does most or all of foo's
> functionality plus a little more and maybe tweek some of foo's
> output, so I write a wrapper around foo and call it bar.
> If inside bar are the call to foo, as well as methods baz(),
> buz() and bug() that make their magic and bar ends up performing
> as I want.
>
>     If I understood correctly baz(), buz() and bug() plus the glue
> that is bar are decorations around foo or bar is a decorator of foo.

Maybe. I have never had need to speak of a "decoration".
My feeling tends more to use this term for the syntactic
construct ("@<decorator>[(args)]<function>") then the implementation
details of the decorator ("bar" in your example).

>     Apologies, I don't yet know how to show that foo and bar are
> meant to be objects.

No need to force yourself to view them as "object"s.

An "object", in general, is something that can have attributes
(holding the object state) and methods (defining often operations on
the object state but in some cases also general operations (not
related to the object state).
In this sense, almost everything you handle in a Python script
can be view as an object (an exception are the variables;
they, themselves, are not objects but their values are objects).

In your example, "foo" and "bar" are functions.
As such, they are also objects - but the feature (attributes,
methods) is rarely used explicitely (you can use
"dir(<your function>)" to learn what attributes and methods
your function has). You use functions in Python typically as
you are used to use them in another programming language.


> ...
>     For that matter, are baz(), buz() and bug() methods if they only
> help bar get the job done but don't have a place in bar's interface?

Your functions are methods, if they are defined inside a class.

Typically (there are exceptions), this means that their definition
occurs at the top level of a "class" statement:

       class CLS...:
         ...
         def method(self, ...):
           ...

       In this case, "method" is a method of class "CLS"
       and its instances (called "CLS" objects).

When you access a method of an object, then
the function representing the method is wrapped;
the wrapper remembers the object and the function and
ensures that the object is automatically passed as
the first parameter of the function ("self" in the example above)
in method calls.
Thus, the distinction between a method and a "normal" function
is that for a method, the first parameter is passed automatically
while in a "normal" function, the call must pass all arguments explicitly.



From steve+comp.lang.python at pearwood.info  Sat May 19 03:22:28 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sat, 19 May 2018 07:22:28 +0000 (UTC)
Subject: decorat{or,ion}
References: <mailman.30.1526659203.31214.python-list@python.org>
 <20180519013116.GA16615@playground>
Message-ID: <pdojbj$3fh$7@blaine.gmane.org>

On Fri, 18 May 2018 18:31:16 -0700, Mike McClain wrote:

> Let's say I want something that does most or all of foo's functionality
> plus a little more and maybe tweek some of foo's output, so I write a
> wrapper around foo and call it bar. If inside bar are the call to foo,
> as well as methods baz(), buz() and bug() that make their magic and bar
> ends up performing as I want.

I *think* you are describing something like this:

def foo(x):
    return x + 1

def bar(arg):
    a = baz(arg)  # do some magic
    result = bar(a)  # call the important function
    return buz(result)  # and a bit more magic


No methods are required! We can simply talk about ordinary functions.

(Methods are, in a sense, just like normal functions except they carry 
around some extra state, namely the object that owns them.)

Is that what you mean?


>     If I understood correctly baz(), buz() and bug() plus the glue
> that is bar are decorations around foo or bar is a decorator of foo.

Typically, we wouldn't use the term "decorator" or "decoration" to 
describe a hand-written function like bar(), even if it calls foo(). 
Normally the "decorator" terminology is reserved for one of two things:

(1) The software design pattern of using a factory function to "wrap" one 
function inside an automatically generated wrapper function that provides 
the extra additional functionality:


def factory(func):
    # Wrap func() to force it to return zero instead of negative
    def wrapped(arg):
        result = func(arg)
        if result < 0:
            result = 0
        return result
    # return the wrapped function
    return wrapped


(2) the syntax for applying such a factory function:

@factory
def myfunction(x):
    return 5 - x


Does this help?

I know these concepts are sometimes tricky. Concrete examples often make 
them easier to understand. Feel free to ask more questions as needed.


-- 
Steve



From hjp-python at hjp.at  Sat May 19 04:00:03 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Sat, 19 May 2018 10:00:03 +0200
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <pdfshl$unn$15@blaine.gmane.org>
References: <7s86fd1bncg5hovboehvvqe57budhc2bf8@4ax.com>
 <20180513024213.GG12850@bladeshadow.org>
 <pd966b$unn$4@blaine.gmane.org>
 <CAPTjJmpp=wqgSQ0sWXsh6jnDDYTHtNkO1Ct1BGQqTe1iD8exqQ@mail.gmail.com>
 <20180514153819.GO12850@bladeshadow.org>
 <CALwzidk=0AMKd81GPrqACp8spoV62ia6b6afR+X16kM-r1zOKA@mail.gmail.com>
 <20180514232013.GP12850@bladeshadow.org>
 <pddb0p$unn$10@blaine.gmane.org>
 <20180515202115.3pioqxhhdm6xnlr3@hjp.at>
 <pdfshl$unn$15@blaine.gmane.org>
Message-ID: <20180519080003.r4qkg3aa4ecznlgh@hjp.at>

On 2018-05-16 00:04:06 +0000, Steven D'Aprano wrote:
> On Tue, 15 May 2018 22:21:15 +0200, Peter J. Holzer wrote:
> > On 2018-05-15 00:52:42 +0000, Steven D'Aprano wrote:
> [...]
> >> By 1991 there had already been *decades* of experience with C
> > 
> > About one and a half decades.
> 
> That would still be plural decades.
> 
> C's first release was 1972, so more like 19 years than 15.

I thought it was 1974, but Ritchie writes "By early 1973, the essentials
of modern C were complete." So you are closer than me. But we don't
know whether those early users of C tended to confuse ?=? and ?==?
(Ritchie did change the compound assignments from ?=+?, ?=-? etc. so
?+=?, ?-=?, etc., so at the early stages he did change syntax if it
proved to be error-prone. He didn't change the precedence of ?&? and ?|?
after introducing ?&&? and ?||?, though.). C spread beyond the Unix team
in the mid to late 70s.

> >> proving that the "=" assignment syntax is dangerously confusable with
> >> == and a total bug magnet when allowed as expressions as well, so it
> >> was perfectly reasonable to ban it from the language.
> > 
> > Experience? Yes. Data? I doubt it.
> 
> I'm using "proving" informally above, not in the sense of actual legal or 
> scientific standards of proof.

?Proof by assertion?? I am not a native English speaker, but I don't
think just claiming that something is the case constitutes a ?proof?
even in the most informal use of the language.

Humans are notoriously bad at estimating risk. We often talk a lot about
and take rather extreme measures to avoid relatively small risks (e.g.
being killed in a terrorist attack) while mostly ignoring much larger
risks (e.g. being killed in a car accident). Yes, bugs of this class
were found in the wild. Yes, compiler writers added warnings about
suspicious use of assignments in a boolean context. Yes, Guido avoided
assignment expressions because he thought they were too dangerous. But
does any of this prove that assignment expressions are ?a total bug
magnet?? I don't think so.


> If you are going to object to that, remember that neither is there 
> scientific data proving that assignment as an expression is useful, so we 
> can always just reject the construct as "useless until proven otherwise" 
> :-)

It is used, therefore it is useful ;-).

I think it is very useful in C which reports exceptional conditions
(errors, end of file, ...) by returning reserved values. So you often
want to combine an assignment and a test. The vast majority of
assignment sub-expressions you'll see in a C program are of this type.

I think it would be much less useful in Python, because Python has
exceptions and generators (and these are used by both the standard
library and idiomatic Python code). So most situations where you would
use an assignment sub-expression in C simply don't arise. As I said, I
don't miss the feature in Python.


> > I have been programming in C since the mid-80's [...]
> > I guess I could write a script which
> > searches through all my repositories for changesets where ?=? was
> > replaced by ?==?. Not sure what that would prove.)
> 
> You were using version control repositories in the 1980s, and still have 
> access to them? I'm impressed.

I started using Unix in early 1987 and SCCS shortly afterwards. So this
year may mark my 30th anniversary as a version control system user. But
I don't know if I still have any of my SCCS repos, and if I have, the
disks and tapes probably aren't readable any more.

But I wasn't actually thinking of going that far back. I am not much
interested whether I made that kind of error as a C newbie in 1987. I am
interested whether I made it as an experienced C and Perl programmer.
So I was thinking of analyzing repos which are moderately current. If I
could find cases where I wrote ?=? instead of ?==?, I'd have to admit
that a) I do make that error at least occationally and b) I don't always
find it before committing. But that still wouldn't prove anything: I
would have to compare it to other bug classes, and most importantly,
whether a single programmer (me) tends make (or not make) a specific
error doesn't say anything about the entirety of programmers. And it's
the latter that counts.


> > OTOH, despite having used C and Perl long before Python, I don't miss
> > assignment expressions. Every language has its idioms, and just because
> > you write stuff like ?if ((fd = open(...)) == -1)? a lot in C doesn't
> > mean you have to be able to write that in Python.
> 
> I'm not a C coder, but I think that specific example would be immune to 
> the bug we are discussing, since (I think) you can't chain assignments in 
> C. Am I right?
> 
>     fd = open(...)) = -1
> 
> would be a syntax error.

Yes, because you omitted a parenthesis ;-), But yes, that would be error
(although not a syntax error - the syntax is fine), because the result
of an assignment isn't an l-value in standard C and cannot be assigned
to. Some compilers (among them GCC) offer that as an extension, though.

I used this example because it is very idiomatic C. Every C programmer
writes that dozens of times a day. But I don't feel the need to write
that in Python because Python has other (arguably more elegant)
mechanisms.

> But:
> 
>     fd = -1
> 
> would not be.

Yes. A C programmer might write ?if (fd = -1)? instead of ?if (fd == -1)?.
But I don't think that it happens all that frequently.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180519/015c6cfe/attachment.sig>

From hjp-python at hjp.at  Sat May 19 04:18:30 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Sat, 19 May 2018 10:18:30 +0200
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <2VKKC.216808$jZ.124754@fx20.am4>
References: <20180513024213.GG12850@bladeshadow.org>
 <pd966b$unn$4@blaine.gmane.org>
 <CAPTjJmpp=wqgSQ0sWXsh6jnDDYTHtNkO1Ct1BGQqTe1iD8exqQ@mail.gmail.com>
 <20180514153819.GO12850@bladeshadow.org>
 <CALwzidk=0AMKd81GPrqACp8spoV62ia6b6afR+X16kM-r1zOKA@mail.gmail.com>
 <20180514232013.GP12850@bladeshadow.org>
 <pddb0p$unn$10@blaine.gmane.org>
 <20180515202115.3pioqxhhdm6xnlr3@hjp.at>
 <mailman.88.1526415682.2761.python-list@python.org>
 <2VKKC.216808$jZ.124754@fx20.am4>
Message-ID: <20180519081830.auofsxk2ibujbzge@hjp.at>

On 2018-05-16 01:26:38 +0100, bartc wrote:
> On 15/05/2018 21:21, Peter J. Holzer wrote:
> > I have been programming in C since the mid-80's and in Perl since the
> > mid-90's (both languages allow assignment expressions). I accumulated my
> > fair share of bugs in that time, but AFAIR I made this particular error
> > very rarely (I cannot confidently claim that I never made it). Clearly
> > it is not ?a total bug magnet? in my experience. There are much bigger
> > problems in C and Perl (and Python, too). But of course my experience is
> 
> All those languages use = for assignment and == for equality.
> 
> If like me you normally use a language where = means equality (and := is
> used for assignment), then you're going to get it wrong more frequently when
> using C or Python (I don't use Perl).

Absolutely. These days I program mostly in Python and Perl and find that
I often omit semicolons in Perl. If I was programming in Pascal and C I
probably would mix up ?:=?, ?=? and ?==?. But I don't. All the programming
languages I have used regularly (C, Perl, Java, JavaScript, Python) use
the same operators for assignment and comparison. So my fingers know what
to type.

(I wonder whether the notion that ?=? and ?==? are easy to mix up stems
from the early days of C when C was an outlier (most other languages at
the time used ?=? for equality). Now C is mainstream and it's those other
languages that seem odd.)

> You might get it wrong anyway because = is used for equality in the real
> world too.

Not after a few years of programming. Probably not even after a few
weeks of programming. You develop muscle memory quite quickly. 

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180519/a8d5acc4/attachment.sig>

From marko at pacujo.net  Sat May 19 04:38:09 2018
From: marko at pacujo.net (Marko Rauhamaa)
Date: Sat, 19 May 2018 11:38:09 +0300
Subject: seeking deeper (language theory) reason behind Python design
 choice
References: <20180513024213.GG12850@bladeshadow.org>
 <pd966b$unn$4@blaine.gmane.org>
 <CAPTjJmpp=wqgSQ0sWXsh6jnDDYTHtNkO1Ct1BGQqTe1iD8exqQ@mail.gmail.com>
 <20180514153819.GO12850@bladeshadow.org>
 <CALwzidk=0AMKd81GPrqACp8spoV62ia6b6afR+X16kM-r1zOKA@mail.gmail.com>
 <20180514232013.GP12850@bladeshadow.org>
 <pddb0p$unn$10@blaine.gmane.org>
 <20180515202115.3pioqxhhdm6xnlr3@hjp.at>
 <mailman.88.1526415682.2761.python-list@python.org>
 <2VKKC.216808$jZ.124754@fx20.am4>
 <20180519081830.auofsxk2ibujbzge@hjp.at>
 <mailman.230.1526717913.2761.python-list@python.org>
Message-ID: <87r2m89h1q.fsf@elektro.pacujo.net>

"Peter J. Holzer" <hjp-python at hjp.at>:
> (I wonder whether the notion that ?=? and ?==? are easy to mix up
> stems from the early days of C when C was an outlier (most other
> languages at the time used ?=? for equality). Now C is mainstream and
> it's those other languages that seem odd.)

I occasionally mix them up one way or another, whether by typing them
wrong accidentally or through some copy-and-paste mishap. Typos of all
kind happen all the time, but the "="/"==" mixup isn't easy for the eye
to spot and it doesn't create a syntax error.

A famous example:

   +       if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
   +                       retval = -EINVAL;

   <URL: https://lwn.net/Articles/57135/>


Marko


From bc at freeuk.com  Sat May 19 06:33:26 2018
From: bc at freeuk.com (bartc)
Date: Sat, 19 May 2018 11:33:26 +0100
Subject: what does := means simply?
In-Reply-To: <mailman.225.1526693200.2761.python-list@python.org>
References: <pdmgvh$3fh$3@blaine.gmane.org>
 <mailman.199.1526646718.2761.python-list@python.org>
 <NyBLC.259028$Xa4.208590@fx29.am4>
 <CAPTjJmoU9EUcOXT4ZcfrXep0UWN1U5fpngzj_oO6qEezc3eG2A@mail.gmail.com>
 <mailman.205.1526654858.2761.python-list@python.org>
 <72ELC.189741$eg.62291@fx43.am4> <PdFLC.294114$6D.258692@fx19.am4>
 <CAPTjJmqBFB4rhu5Xsieotb=jgii1mxB8Hph7=OvsSNh70aajLA@mail.gmail.com>
 <mailman.216.1526669865.2761.python-list@python.org>
 <ZWHLC.190031$eg.73535@fx43.am4> <dlrufd9sm0v230qses3mlitcf324cu12v6@4ax.com>
 <pdnsuj$3fh$6@blaine.gmane.org>
 <mailman.224.1526691745.2761.python-list@python.org>
 <fQKLC.163818$ny5.147948@fx17.am4>
 <CAPTjJmq=5tt-BXXAYq7jbqCv4nAMpfP+wf-0QxMkkNk5802g5A@mail.gmail.com>
 <mailman.225.1526693200.2761.python-list@python.org>
Message-ID: <V3TLC.289245$CH6.116439@fx01.am4>

On 19/05/2018 02:26, Chris Angelico wrote:
> On Sat, May 19, 2018 at 11:10 AM, bartc <bc at freeuk.com> wrote:

>> The .ppm (really .pbm) file which was the subject of this sub-thread has its
>> header defined using ASCII. I don't think an EBCDIC 'P4' etc will work.
>>
> 
> "Defined using ASCII" is a tricky concept. There are a number of file
> formats that have certain parts defined because of ASCII mnemonics,
> but are actually defined numerically. The PNG format begins with the
> four bytes 89 50 4E 47, chosen because three of those bytes represent
> the letters "PNG" in ASCII. But it's defined as those byte values. The
> first three represent "i&+" in EBCDIC, and that would be just as
> valid, because you get the correct bytes.
> 
> Your file contains bytes. Not text.

Not you understand why some of us don't bother with 'text mode' files.

However if you have an actual EBCDIC system and would to read .ppm 
files, then you will have trouble reading the numeric parameters as they 
are expressed using sequences of ASCII digits.

The simplest way would be to pass each byte through an ASCII to EBCDIC 
lookup table (so that code 0x37 for ASCII '7', which is EOT in EBCDIC, 
is turned into 0xF8 which is EBCDIC '7').

But then you are acknowledging the file is, in fact, ASCII.

-- 
bartc


From hjp-python at hjp.at  Sat May 19 07:17:04 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Sat, 19 May 2018 13:17:04 +0200
Subject: seeking deeper (language theory) reason behind Python design
 choice
In-Reply-To: <87r2m89h1q.fsf@elektro.pacujo.net>
References: <20180514153819.GO12850@bladeshadow.org>
 <CALwzidk=0AMKd81GPrqACp8spoV62ia6b6afR+X16kM-r1zOKA@mail.gmail.com>
 <20180514232013.GP12850@bladeshadow.org>
 <pddb0p$unn$10@blaine.gmane.org>
 <20180515202115.3pioqxhhdm6xnlr3@hjp.at>
 <mailman.88.1526415682.2761.python-list@python.org>
 <2VKKC.216808$jZ.124754@fx20.am4>
 <20180519081830.auofsxk2ibujbzge@hjp.at>
 <mailman.230.1526717913.2761.python-list@python.org>
 <87r2m89h1q.fsf@elektro.pacujo.net>
Message-ID: <20180519111704.qlaik3yqll7qrrml@hjp.at>

On 2018-05-19 11:38:09 +0300, Marko Rauhamaa wrote:
> "Peter J. Holzer" <hjp-python at hjp.at>:
> > (I wonder whether the notion that ?=? and ?==? are easy to mix up
> > stems from the early days of C when C was an outlier (most other
> > languages at the time used ?=? for equality). Now C is mainstream and
> > it's those other languages that seem odd.)
> 
> I occasionally mix them up one way or another, whether by typing them
> wrong accidentally or through some copy-and-paste mishap. Typos of all
> kind happen all the time, but the "="/"==" mixup isn't easy for the eye
> to spot and it doesn't create a syntax error.
> 
> A famous example:
> 
>    +       if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
>    +                       retval = -EINVAL;

It's famous, but it is also a bad example:

1) It wasn't an accident, it was deliberate.
2) It was spotted.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180519/dfd951fb/attachment.sig>

From hjp-python at hjp.at  Sat May 19 07:33:17 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Sat, 19 May 2018 13:33:17 +0200
Subject: what does := means simply?
In-Reply-To: <V3TLC.289245$CH6.116439@fx01.am4>
References: <CAPTjJmqBFB4rhu5Xsieotb=jgii1mxB8Hph7=OvsSNh70aajLA@mail.gmail.com>
 <mailman.216.1526669865.2761.python-list@python.org>
 <ZWHLC.190031$eg.73535@fx43.am4>
 <dlrufd9sm0v230qses3mlitcf324cu12v6@4ax.com>
 <pdnsuj$3fh$6@blaine.gmane.org>
 <mailman.224.1526691745.2761.python-list@python.org>
 <fQKLC.163818$ny5.147948@fx17.am4>
 <CAPTjJmq=5tt-BXXAYq7jbqCv4nAMpfP+wf-0QxMkkNk5802g5A@mail.gmail.com>
 <mailman.225.1526693200.2761.python-list@python.org>
 <V3TLC.289245$CH6.116439@fx01.am4>
Message-ID: <20180519113317.w7ijjsyaallwp2ud@hjp.at>

On 2018-05-19 11:33:26 +0100, bartc wrote:
> On 19/05/2018 02:26, Chris Angelico wrote:
> > On Sat, May 19, 2018 at 11:10 AM, bartc <bc at freeuk.com> wrote:
> > > The .ppm (really .pbm) file which was the subject of this sub-thread has its
> > > header defined using ASCII. I don't think an EBCDIC 'P4' etc will work.
> > 
> > "Defined using ASCII" is a tricky concept. There are a number of file
> > formats that have certain parts defined because of ASCII mnemonics,
> > but are actually defined numerically. The PNG format begins with the
> > four bytes 89 50 4E 47, chosen because three of those bytes represent
> > the letters "PNG" in ASCII. But it's defined as those byte values. The
> > first three represent "i&+" in EBCDIC, and that would be just as
> > valid, because you get the correct bytes.
> > 
> > Your file contains bytes. Not text.
> 
> Not you understand why some of us don't bother with 'text mode' files.

"Not" or "Now"?

Yesterday you claimed that you worked with them for 40 years.

> However if you have an actual EBCDIC system and would to read .ppm files,
> then you will have trouble reading the numeric parameters as they are
> expressed using sequences of ASCII digits.
> 
> The simplest way would be to pass each byte through an ASCII to EBCDIC
> lookup table (so that code 0x37 for ASCII '7', which is EOT in EBCDIC, is
> turned into 0xF8 which is EBCDIC '7').

(EBCDIC '7' is actually 0xF7)

I think the simplest way would be perform the calculation by hand
(new_value = old_value * 10 + next_byte - 0x30). At least in a language
which lets me process individual bytes easily. That would even work on
both ASCII and EBCDIC based systems (and on every other platform, too).


> But then you are acknowledging the file is, in fact, ASCII.

No need to acknowledge anything. Yes. the inventor of the format was
obviously thinking in ASCII, but to implement it you don't have to do
that. Just read bytes and extract information from them.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180519/1fb83023/attachment.sig>

From rosuav at gmail.com  Sat May 19 07:38:59 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 19 May 2018 21:38:59 +1000
Subject: what does := means simply?
In-Reply-To: <V3TLC.289245$CH6.116439@fx01.am4>
References: <pdmgvh$3fh$3@blaine.gmane.org>
 <mailman.199.1526646718.2761.python-list@python.org>
 <NyBLC.259028$Xa4.208590@fx29.am4>
 <CAPTjJmoU9EUcOXT4ZcfrXep0UWN1U5fpngzj_oO6qEezc3eG2A@mail.gmail.com>
 <mailman.205.1526654858.2761.python-list@python.org>
 <72ELC.189741$eg.62291@fx43.am4> <PdFLC.294114$6D.258692@fx19.am4>
 <CAPTjJmqBFB4rhu5Xsieotb=jgii1mxB8Hph7=OvsSNh70aajLA@mail.gmail.com>
 <mailman.216.1526669865.2761.python-list@python.org>
 <ZWHLC.190031$eg.73535@fx43.am4>
 <dlrufd9sm0v230qses3mlitcf324cu12v6@4ax.com> <pdnsuj$3fh$6@blaine.gmane.org>
 <mailman.224.1526691745.2761.python-list@python.org>
 <fQKLC.163818$ny5.147948@fx17.am4>
 <CAPTjJmq=5tt-BXXAYq7jbqCv4nAMpfP+wf-0QxMkkNk5802g5A@mail.gmail.com>
 <mailman.225.1526693200.2761.python-list@python.org>
 <V3TLC.289245$CH6.116439@fx01.am4>
Message-ID: <CAPTjJmqPxG_annQKUzv6XZ79JV-tjzpS_LjZcxVnp_zs2HS37A@mail.gmail.com>

On Sat, May 19, 2018 at 8:33 PM, bartc <bc at freeuk.com> wrote:
> On 19/05/2018 02:26, Chris Angelico wrote:
>>
>> On Sat, May 19, 2018 at 11:10 AM, bartc <bc at freeuk.com> wrote:
>
>
>>> The .ppm (really .pbm) file which was the subject of this sub-thread has
>>> its
>>> header defined using ASCII. I don't think an EBCDIC 'P4' etc will work.
>>>
>>
>> "Defined using ASCII" is a tricky concept. There are a number of file
>> formats that have certain parts defined because of ASCII mnemonics,
>> but are actually defined numerically. The PNG format begins with the
>> four bytes 89 50 4E 47, chosen because three of those bytes represent
>> the letters "PNG" in ASCII. But it's defined as those byte values. The
>> first three represent "i&+" in EBCDIC, and that would be just as
>> valid, because you get the correct bytes.
>>
>> Your file contains bytes. Not text.
>
>
> Not you understand why some of us don't bother with 'text mode' files.
>
> However if you have an actual EBCDIC system and would to read .ppm files,
> then you will have trouble reading the numeric parameters as they are
> expressed using sequences of ASCII digits.
>
> The simplest way would be to pass each byte through an ASCII to EBCDIC
> lookup table (so that code 0x37 for ASCII '7', which is EOT in EBCDIC, is
> turned into 0xF8 which is EBCDIC '7').
>
> But then you are acknowledging the file is, in fact, ASCII.

Cool! So what happens if you acknowledge that a file is ASCII, and
then it starts with a byte value of E3 ?

ChrisA


From bc at freeuk.com  Sat May 19 08:28:41 2018
From: bc at freeuk.com (bartc)
Date: Sat, 19 May 2018 13:28:41 +0100
Subject: what does := means simply?
In-Reply-To: <mailman.233.1526729942.2761.python-list@python.org>
References: <pdmgvh$3fh$3@blaine.gmane.org>
 <mailman.199.1526646718.2761.python-list@python.org>
 <NyBLC.259028$Xa4.208590@fx29.am4>
 <CAPTjJmoU9EUcOXT4ZcfrXep0UWN1U5fpngzj_oO6qEezc3eG2A@mail.gmail.com>
 <mailman.205.1526654858.2761.python-list@python.org>
 <72ELC.189741$eg.62291@fx43.am4> <PdFLC.294114$6D.258692@fx19.am4>
 <CAPTjJmqBFB4rhu5Xsieotb=jgii1mxB8Hph7=OvsSNh70aajLA@mail.gmail.com>
 <mailman.216.1526669865.2761.python-list@python.org>
 <ZWHLC.190031$eg.73535@fx43.am4> <dlrufd9sm0v230qses3mlitcf324cu12v6@4ax.com>
 <pdnsuj$3fh$6@blaine.gmane.org>
 <mailman.224.1526691745.2761.python-list@python.org>
 <fQKLC.163818$ny5.147948@fx17.am4>
 <CAPTjJmq=5tt-BXXAYq7jbqCv4nAMpfP+wf-0QxMkkNk5802g5A@mail.gmail.com>
 <mailman.225.1526693200.2761.python-list@python.org>
 <V3TLC.289245$CH6.116439@fx01.am4>
 <CAPTjJmqPxG_annQKUzv6XZ79JV-tjzpS_LjZcxVnp_zs2HS37A@mail.gmail.com>
 <mailman.233.1526729942.2761.python-list@python.org>
Message-ID: <YLULC.220696$Vm6.152613@fx45.am4>

On 19/05/2018 12:38, Chris Angelico wrote:
> On Sat, May 19, 2018 at 8:33 PM, bartc <bc at freeuk.com> wrote:

>> But then you are acknowledging the file is, in fact, ASCII.
> 
> Cool! So what happens if you acknowledge that a file is ASCII, and
> then it starts with a byte value of E3 ?

It depends.

If this is a .ppm file I'm trying to read, and it starts with anything 
other than 'P' followed by one of '1','2','3','4','5','6' (by which I 
mean the ASCII codes for those), then it's a bad ppm file.

What are you really trying to say here?

Out of interest, how would Python handle the headers for binary file 
formats P4, P5, P6? I'd have a go but I don't want to waste half the day 
trying to get past the language.

It is quite possible to deal with files, including files which are 
completely or partially text, a byte at a time, without having silly 
restrictions put on them by the language.

Here's the palaver I had to go through last time I wrote such a file 
using Python, and this is just for the header:

     s="P6\n%d %d\n255\n" % (hdr.width, hdr.height)
     sbytes=array.array('B',list(map(ord,s)))
     f.write(sbytes)

Was there a simple way to write way to do this? Most likely, but you 
have to find it first! Here's how I write it elsewhere:

   println @f, "P6"
   println @f, width,height
   println @f, 255

It's simpler because it doesn't get tied up in knots in trying to make 
text different from bytes, bytearrays or array.arrays.

-- 
bartc


From bc at freeuk.com  Sat May 19 08:43:14 2018
From: bc at freeuk.com (bartc)
Date: Sat, 19 May 2018 13:43:14 +0100
Subject: what does := means simply?
In-Reply-To: <mailman.232.1526729599.2761.python-list@python.org>
References: <CAPTjJmqBFB4rhu5Xsieotb=jgii1mxB8Hph7=OvsSNh70aajLA@mail.gmail.com>
 <mailman.216.1526669865.2761.python-list@python.org>
 <ZWHLC.190031$eg.73535@fx43.am4> <dlrufd9sm0v230qses3mlitcf324cu12v6@4ax.com>
 <pdnsuj$3fh$6@blaine.gmane.org>
 <mailman.224.1526691745.2761.python-list@python.org>
 <fQKLC.163818$ny5.147948@fx17.am4>
 <CAPTjJmq=5tt-BXXAYq7jbqCv4nAMpfP+wf-0QxMkkNk5802g5A@mail.gmail.com>
 <mailman.225.1526693200.2761.python-list@python.org>
 <V3TLC.289245$CH6.116439@fx01.am4> <20180519113317.w7ijjsyaallwp2ud@hjp.at>
 <mailman.232.1526729599.2761.python-list@python.org>
Message-ID: <BZULC.164040$ny5.143736@fx17.am4>

On 19/05/2018 12:33, Peter J. Holzer wrote:
> On 2018-05-19 11:33:26 +0100, bartc wrote:

>> Not you understand why some of us don't bother with 'text mode' files.
> 
> "Not" or "Now"?

Now.

> Yesterday you claimed that you worked with them for 40 years.

Text files, yes. Not 'text mode' which is something inflicted on us by 
the C library.

(All my current programs can deal with lf or cr/lf line endings. I 
dropped cr-only line endings as I hadn't seen such a file since the 90's.)

>> However if you have an actual EBCDIC system and would to read .ppm files,
>> then you will have trouble reading the numeric parameters as they are
>> expressed using sequences of ASCII digits.

> I think the simplest way would be perform the calculation by hand
> (new_value = old_value * 10 + next_byte - 0x30). At least in a language
> which lets me process individual bytes easily. That would even work on
> both ASCII and EBCDIC based systems (and on every other platform, too).

/The/ simplest? Don't forget the numbers can be several digits each. 
Here's how I read them (NOT Python):

     readln @f, width, height

Would it work in an EBCDIC based system? Probably not. But, who cares? 
(I can't say I've never used such a system, but that was some ancient 
mainframe from the 70s. But I'm pretty certain I won't ever again.)

(Perhaps someone who has access to an EBCDIC system can try a .PPM 
reader to see what happens. I suspect that won't work either.)

-- 
bartc


From mal at europython.eu  Sat May 19 10:18:03 2018
From: mal at europython.eu (M.-A. Lemburg)
Date: Sat, 19 May 2018 16:18:03 +0200
Subject: EuroPython 2018: Call for Proposals closes on Sunday
Message-ID: <bcb26bdb-a41e-bd36-43f8-cd1e23a2b613@europython.eu>

We would like to remind you that our two week call for proposals (CFP)
closes on Sunday, May 20.

If you?d like to submit a talk, please see our CFP announcement for
details:

https://blog.europython.eu/post/173666124852/europython-2018-call-for-proposals-cfp-is-open

Submissions are possibe via the CFP page on the EuroPython 2018
website:

https://ep2018.europython.eu/en/call-for-proposals/

We?d like to invite everyone to submit proposals for talks, trainings,
panels, etc. Looking at the submission counts, we are especially
looking for more trainings submissions (note that you get a free
conference ticket and training pass as trainer of a selected
training).

Submissions will then go into a talk voting phase where EuroPython
attendees of previous years can vote on the submissions. The program
work group will then use these votes as basis for the final talk
selection and scheduling.

We expect to have the schedule available by end of May.

Please help us spread this reminder by sharing it on your social
networks as widely as possible. Thank you !

Link to the blog post:

https://blog.europython.eu/post/174049845802/europython-2018-call-for-proposals-closes-on

Tweet:

https://twitter.com/europython/status/997842991036424198

Enjoy,
--
EuroPython 2018 Team
https://ep2018.europython.eu/
https://www.europython-society.org/



From steve+comp.lang.python at pearwood.info  Sat May 19 10:38:22 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sat, 19 May 2018 14:38:22 +0000 (UTC)
Subject: (Not actually off-topic) Anyone here used Rebol or Red?
Message-ID: <pdpcsu$tc5$1@blaine.gmane.org>

I'm looking for anyone with experience using either Rebol or its more 
modern fork, Red.

And yes, it is relevant to Python.


-- 
Steve



From subhabangalore at gmail.com  Sat May 19 12:19:08 2018
From: subhabangalore at gmail.com (subhabangalore at gmail.com)
Date: Sat, 19 May 2018 09:19:08 -0700 (PDT)
Subject: TypeError: expected string or Unicode object, NoneType found
Message-ID: <938e588e-45c4-4415-869d-9cdf0bbeb7f4@googlegroups.com>

I wrote a small piece of following code 

import nltk
from nltk.corpus.reader import TaggedCorpusReader
from nltk.tag import CRFTagger
def NE_TAGGER():
    reader = TaggedCorpusReader('/python27/', r'.*\.pos')
    f1=reader.fileids()
    print "The Files of Corpus are:",f1
    sents=reader.tagged_sents()
    ls=len(sents)
    print "Length of Corpus Is:",ls
    train_data=sents[:300]
    test_data=sents[301:350]
    ct = CRFTagger()
    crf_tagger=ct.train(train_data,'model.crf.tagger')

This code is working fine. 
Now if I change the data size to say 500 or 3000 in  train_data by giving  train_data=sents[:500] or
 train_data=sents[:3000] it is giving me the following error.

Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    NE_TAGGER()
  File "C:\Python27\HindiCRFNERTagger1.py", line 20, in NE_TAGGER
    crf_tagger=ct.train(train_data,'model.crf.tagger')
  File "C:\Python27\lib\site-packages\nltk\tag\crf.py", line 185, in train
    trainer.append(features,labels)
  File "pycrfsuite\_pycrfsuite.pyx", line 312, in pycrfsuite._pycrfsuite.BaseTrainer.append (pycrfsuite/_pycrfsuite.cpp:3800)
  File "stringsource", line 53, in vector.from_py.__pyx_convert_vector_from_py_std_3a__3a_string (pycrfsuite/_pycrfsuite.cpp:10738)
  File "stringsource", line 15, in string.from_py.__pyx_convert_string_from_py_std__in_string (pycrfsuite/_pycrfsuite.cpp:10633)
TypeError: expected string or Unicode object, NoneType found
>>> 

I have searched for solutions in web found the following links as,
https://stackoverflow.com/questions/14219038/python-multiprocessing-typeerror-expected-string-or-unicode-object-nonetype-f
or
https://github.com/kamakazikamikaze/easysnmp/issues/50

reloaded Python but did not find much help. 

I am using Python 2.7.15 (v2.7.15:ca079a3ea3, Apr 30 2018, 16:22:17) [MSC v.1500 32 bit (Intel)] on win32

My O/S is, MS-Windows 7.

If any body may kindly suggest a resolution. 


From __peter__ at web.de  Sat May 19 12:47:34 2018
From: __peter__ at web.de (Peter Otten)
Date: Sat, 19 May 2018 18:47:34 +0200
Subject: TypeError: expected string or Unicode object, NoneType found
References: <938e588e-45c4-4415-869d-9cdf0bbeb7f4@googlegroups.com>
Message-ID: <pdpkb5$bnf$1@blaine.gmane.org>

subhabangalore at gmail.com wrote:

> I wrote a small piece of following code
> 
> import nltk
> from nltk.corpus.reader import TaggedCorpusReader
> from nltk.tag import CRFTagger
> def NE_TAGGER():
>     reader = TaggedCorpusReader('/python27/', r'.*\.pos')
>     f1=reader.fileids()
>     print "The Files of Corpus are:",f1
>     sents=reader.tagged_sents()
>     ls=len(sents)
>     print "Length of Corpus Is:",ls
>     train_data=sents[:300]
>     test_data=sents[301:350]

Offtopic: not that sents[300] is neither in the training nor in the test 
data; Python uses half-open intervals.

>     ct = CRFTagger()
>     crf_tagger=ct.train(train_data,'model.crf.tagger')
> 
> This code is working fine.
> Now if I change the data size to say 500 or 3000 in  train_data by giving 
> train_data=sents[:500] or
>  train_data=sents[:3000] it is giving me the following error.

What about sents[:499], sents[:498], ...? 

I'm not an nltk user, but to debug the problem I suggest that you identify 
the exact index that triggers the exception, and then print it

print sents[minimal_index_that_causes_typeerror]

Perhaps you can spot a problem with the input data.
 
(In the spirit of the "offtopic" remark: if sents[:333] triggers the failure 
you have to print sents[332])


> Traceback (most recent call last):
>   File "<pyshell#2>", line 1, in <module>
>     NE_TAGGER()
>   File "C:\Python27\HindiCRFNERTagger1.py", line 20, in NE_TAGGER
>     crf_tagger=ct.train(train_data,'model.crf.tagger')
>   File "C:\Python27\lib\site-packages\nltk\tag\crf.py", line 185, in train
>     trainer.append(features,labels)
>   File "pycrfsuite\_pycrfsuite.pyx", line 312, in
>   pycrfsuite._pycrfsuite.BaseTrainer.append
>   (pycrfsuite/_pycrfsuite.cpp:3800) File "stringsource", line 53, in
>   vector.from_py.__pyx_convert_vector_from_py_std_3a__3a_string
>   (pycrfsuite/_pycrfsuite.cpp:10738) File "stringsource", line 15, in
>   string.from_py.__pyx_convert_string_from_py_std__in_string
>   (pycrfsuite/_pycrfsuite.cpp:10633)
> TypeError: expected string or Unicode object, NoneType found
>>>> 
> 
> I have searched for solutions in web found the following links as,
> https://stackoverflow.com/questions/14219038/python-multiprocessing-typeerror-expected-string-or-unicode-object-nonetype-f
> or
> https://github.com/kamakazikamikaze/easysnmp/issues/50
> 
> reloaded Python but did not find much help.
> 
> I am using Python 2.7.15 (v2.7.15:ca079a3ea3, Apr 30 2018, 16:22:17) [MSC
> v.1500 32 bit (Intel)] on win32
> 
> My O/S is, MS-Windows 7.
> 
> If any body may kindly suggest a resolution.




From gherron at digipen.edu  Sat May 19 13:08:59 2018
From: gherron at digipen.edu (Gary Herron)
Date: Sat, 19 May 2018 10:08:59 -0700
Subject: Numpy array
In-Reply-To: <4f03b757-ff98-4386-bd73-9acd85b0eb66@googlegroups.com>
References: <4f03b757-ff98-4386-bd73-9acd85b0eb66@googlegroups.com>
Message-ID: <a5325692-b177-8593-292f-d3f06680a1f9@digipen.edu>

The "indexing" page of the documentation might help you with this:

https://docs.scipy.org/doc/numpy-1.14.0/reference/arrays.indexing.html


On 05/18/2018 09:50 PM, sharan.basappa at gmail.com wrote:
> This is regarding numpy array. I am a bit confused how parts of the array are being accessed in the example below.
>
> 1 import scipy as sp
> 2 data = sp.genfromtxt("web_traffic.tsv", delimiter="\t")
> 3 print(data[:10])
> 4 x = data[:,0]
> 5 y = data[:,1]
>
> Apparently, line 3 prints the first 10 entries in the array
> line 4 & 5 is to extract all rows but only 1st and second columns alone for x and y respectively.
>
> I am confused as to how data[:10] gives the first 10 rows while data[:,0] gives all rows
>

-- 
Dr. Gary Herron
Professor of Computer Science
DigiPen Institute of Technology
(425) 895-4418



From tjreedy at udel.edu  Sat May 19 13:47:26 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 19 May 2018 13:47:26 -0400
Subject: TypeError: expected string or Unicode object, NoneType found
In-Reply-To: <pdpkb5$bnf$1@blaine.gmane.org>
References: <938e588e-45c4-4415-869d-9cdf0bbeb7f4@googlegroups.com>
 <pdpkb5$bnf$1@blaine.gmane.org>
Message-ID: <pdpnrd$78d$1@blaine.gmane.org>

On 5/19/2018 12:47 PM, Peter Otten wrote:
> subhabangalore at gmail.com wrote:
> 
>> I wrote a small piece of following code
>>
>> import nltk
>> from nltk.corpus.reader import TaggedCorpusReader
>> from nltk.tag import CRFTagger

To implement Peter's suggestion:

>> def NE_TAGGER():

def tagger(stop):

>>      reader = TaggedCorpusReader('/python27/', r'.*\.pos')
>>      f1=reader.fileids()
>>      print "The Files of Corpus are:",f1
>>      sents=reader.tagged_sents()
>>      ls=len(sents)
>>      print "Length of Corpus Is:",ls
>>      train_data=sents[:300]
>>      test_data=sents[301:350]
> 
> Offtopic: not that sents[300] is neither in the training nor in the test
> data; Python uses half-open intervals.

       train_data=sents[:stop]
       test_data=sents[stop:max+50]

>>      ct = CRFTagger()
>>      crf_tagger=ct.train(train_data,'model.crf.tagger')
>>
>> This code is working fine.
>> Now if I change the data size to say 500 or 3000 in  train_data by giving
>> train_data=sents[:500] or
>>   train_data=sents[:3000] it is giving me the following error.
> 
> What about sents[:499], sents[:498], ...?

Do a rough binary search for the first stop value that raises.

tagger(400)
tagger(350 or 450, depending)
...

You could automate with bisect module, but bisection by eye should be 
faster.

> I'm not an nltk user, but to debug the problem I suggest that you identify
> the exact index that triggers the exception, and then print it
> 
> print sents[minimal_index_that_causes_typeerror]
> 
> Perhaps you can spot a problem with the input data.
>   
> (In the spirit of the "offtopic" remark: if sents[:333] triggers the failure
> you have to print sents[332])

Or mentally subtract 1 from minimal failing stop value.

> 
>> Traceback (most recent call last):
>>    File "<pyshell#2>", line 1, in <module>
>>      NE_TAGGER()
>>    File "C:\Python27\HindiCRFNERTagger1.py", line 20, in NE_TAGGER
>>      crf_tagger=ct.train(train_data,'model.crf.tagger')
>>    File "C:\Python27\lib\site-packages\nltk\tag\crf.py", line 185, in train
>>      trainer.append(features,labels)
>>    File "pycrfsuite\_pycrfsuite.pyx", line 312, in
>>    pycrfsuite._pycrfsuite.BaseTrainer.append
>>    (pycrfsuite/_pycrfsuite.cpp:3800) File "stringsource", line 53, in
>>    vector.from_py.__pyx_convert_vector_from_py_std_3a__3a_string
>>    (pycrfsuite/_pycrfsuite.cpp:10738) File "stringsource", line 15, in
>>    string.from_py.__pyx_convert_string_from_py_std__in_string
>>    (pycrfsuite/_pycrfsuite.cpp:10633)
>> TypeError: expected string or Unicode object, NoneType found
>>>>>
>>
>> I have searched for solutions in web found the following links as,
>> https://stackoverflow.com/questions/14219038/python-multiprocessing-typeerror-expected-string-or-unicode-object-nonetype-f
>> or
>> https://github.com/kamakazikamikaze/easysnmp/issues/50
>>
>> reloaded Python but did not find much help.
>>
>> I am using Python 2.7.15 (v2.7.15:ca079a3ea3, Apr 30 2018, 16:22:17) [MSC
>> v.1500 32 bit (Intel)] on win32
>>
>> My O/S is, MS-Windows 7.
>>
>> If any body may kindly suggest a resolution.
> 
> 


-- 
Terry Jan Reedy



From python at mrabarnett.plus.com  Sat May 19 15:07:53 2018
From: python at mrabarnett.plus.com (MRAB)
Date: Sat, 19 May 2018 20:07:53 +0100
Subject: what does := means simply?
In-Reply-To: <YLULC.220696$Vm6.152613@fx45.am4>
References: <pdmgvh$3fh$3@blaine.gmane.org>
 <mailman.199.1526646718.2761.python-list@python.org>
 <NyBLC.259028$Xa4.208590@fx29.am4>
 <CAPTjJmoU9EUcOXT4ZcfrXep0UWN1U5fpngzj_oO6qEezc3eG2A@mail.gmail.com>
 <mailman.205.1526654858.2761.python-list@python.org>
 <72ELC.189741$eg.62291@fx43.am4> <PdFLC.294114$6D.258692@fx19.am4>
 <CAPTjJmqBFB4rhu5Xsieotb=jgii1mxB8Hph7=OvsSNh70aajLA@mail.gmail.com>
 <mailman.216.1526669865.2761.python-list@python.org>
 <ZWHLC.190031$eg.73535@fx43.am4> <dlrufd9sm0v230qses3mlitcf324cu12v6@4ax.com>
 <pdnsuj$3fh$6@blaine.gmane.org>
 <mailman.224.1526691745.2761.python-list@python.org>
 <fQKLC.163818$ny5.147948@fx17.am4>
 <CAPTjJmq=5tt-BXXAYq7jbqCv4nAMpfP+wf-0QxMkkNk5802g5A@mail.gmail.com>
 <mailman.225.1526693200.2761.python-list@python.org>
 <V3TLC.289245$CH6.116439@fx01.am4>
 <CAPTjJmqPxG_annQKUzv6XZ79JV-tjzpS_LjZcxVnp_zs2HS37A@mail.gmail.com>
 <mailman.233.1526729942.2761.python-list@python.org>
 <YLULC.220696$Vm6.152613@fx45.am4>
Message-ID: <7f16f7e2-5fd8-4f9d-dc43-3b6416522151@mrabarnett.plus.com>

On 2018-05-19 13:28, bartc wrote:
> On 19/05/2018 12:38, Chris Angelico wrote:
>> On Sat, May 19, 2018 at 8:33 PM, bartc <bc at freeuk.com> wrote:
> 
>>> But then you are acknowledging the file is, in fact, ASCII.
>> 
>> Cool! So what happens if you acknowledge that a file is ASCII, and
>> then it starts with a byte value of E3 ?
> 
> It depends.
> 
> If this is a .ppm file I'm trying to read, and it starts with anything
> other than 'P' followed by one of '1','2','3','4','5','6' (by which I
> mean the ASCII codes for those), then it's a bad ppm file.
> 
> What are you really trying to say here?
> 
> Out of interest, how would Python handle the headers for binary file
> formats P4, P5, P6? I'd have a go but I don't want to waste half the day
> trying to get past the language.
> 
> It is quite possible to deal with files, including files which are
> completely or partially text, a byte at a time, without having silly
> restrictions put on them by the language.
> 
> Here's the palaver I had to go through last time I wrote such a file
> using Python, and this is just for the header:
> 
>       s="P6\n%d %d\n255\n" % (hdr.width, hdr.height)
>       sbytes=array.array('B',list(map(ord,s)))
>       f.write(sbytes)
> 
> Was there a simple way to write way to do this? Most likely, but you
> have to find it first! Here's how I write it elsewhere:
> 
>     println @f, "P6"
>     println @f, width,height
>     println @f, 255
> 
> It's simpler because it doesn't get tied up in knots in trying to make
> text different from bytes, bytearrays or array.arrays.
> 
It's very simple:

     s = b"P6\n%d %d\n255\n" % (hdr.width, hdr.height)
     f.write(s)


From bc at freeuk.com  Sat May 19 18:14:08 2018
From: bc at freeuk.com (bartc)
Date: Sat, 19 May 2018 23:14:08 +0100
Subject: what does := means simply?
In-Reply-To: <mailman.240.1526759265.2761.python-list@python.org>
References: <dlrufd9sm0v230qses3mlitcf324cu12v6@4ax.com>
 <pdnsuj$3fh$6@blaine.gmane.org>
 <mailman.224.1526691745.2761.python-list@python.org>
 <fQKLC.163818$ny5.147948@fx17.am4>
 <CAPTjJmq=5tt-BXXAYq7jbqCv4nAMpfP+wf-0QxMkkNk5802g5A@mail.gmail.com>
 <mailman.225.1526693200.2761.python-list@python.org>
 <V3TLC.289245$CH6.116439@fx01.am4>
 <CAPTjJmqPxG_annQKUzv6XZ79JV-tjzpS_LjZcxVnp_zs2HS37A@mail.gmail.com>
 <mailman.233.1526729942.2761.python-list@python.org>
 <YLULC.220696$Vm6.152613@fx45.am4>
 <m4p0gdtrtrs43lbfjpcsoe5f60cs37jhsp@4ax.com>
 <mailman.240.1526759265.2761.python-list@python.org>
Message-ID: <Ok1MC.165333$ny5.163789@fx17.am4>

On 19/05/2018 20:47, Dennis Lee Bieber wrote:
> On Sat, 19 May 2018 13:28:41 +0100, bartc <bc at freeuk.com> declaimed the
> following:
> 
> 
>> Out of interest, how would Python handle the headers for binary file
>> formats P4, P5, P6? I'd have a go but I don't want to waste half the day
>> trying to get past the language.
>>
> 	Based upon http://netpbm.sourceforge.net/doc/ppm.html
> 
> P6	1024	768		255
> 
> and
> 
> P6
> # random comment
> 1024
> 768
> # another random comment
> 255
> 
> are both valid headers.

The comments and examples here: 
https://en.wikipedia.org/wiki/Netpbm_format, and all actual ppm files 
I've come across, suggest the 3 parts of the header (2 parts for P1/P4) 
are on separate lines. That is, separated by newlines. The comments are 
a small detail that is not hard to deal with.

I think if ppm readers expect the 2-3 line format then generators will 
be less tempted to either stick everything on one line or stretch it 
across half a dozen. The point of ppm is simplicity after all.

And actually, a ppm reader I've just downloaded, an image viewer that 
deals with dozens of formats, had problems when I tried to put 
everything on one line. (I think it needs the signature on its own line.)

> Reading an arbitrary PPM thereby is going to be tedious.

PPM was intended to be simple to read and to write (try TIFF, or JPEG, 
for something that is going to be a lot more work).

>>>> ppmfil = open("junk.ppm", "wb")

(ppmfil? We don't have have 6-character limits any more.)

>>>> header = struct.pack("3s27s",
> ... 			b"P6 ",
> ... 			bytes("%8s %8s %8s\n" %
> ... 				(width, height, maxval),
> ... 				"ASCII"))
>>>>
>>>> header
> b'P6     1024      768      255\n'

Hmm, I'd write this elsewhere, if it's going to be one line, as just:

   println @f,"P6",width,height,"255"

I'm sure Python must be able to do something along these lines, even if 
it's:

   f.write("P6 "+str(width)+" "+str(height)+" 255\n")

with whatever is needed to make that string compatible with a binary 
file. I don't know what the struct.pack stuff is for; the header can 
clearly be free-format text.

> 	And how would that language handle Unicode text?

That's not relevant here. (Where it might be relevant, then Unicode must 
be encoded as UTF8 within an 8-bit string.)

-- 
bartc


From bellcanadardp at gmail.com  Sat May 19 18:58:54 2018
From: bellcanadardp at gmail.com (bellcanadardp at gmail.com)
Date: Sat, 19 May 2018 15:58:54 -0700 (PDT)
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <mailman.8292.1233248983.3487.python-list@python.org>
References: <1a7951080901290824p424caee3jb74b1343ce884916@mail.gmail.com>
 <ec96e1390901290849g507dcb17tf2372e573f4a5bb5@mail.gmail.com>
 <mailman.8292.1233248983.3487.python-list@python.org>
Message-ID: <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>

On Thursday, 29 January 2009 12:09:29 UTC-5, Anjanesh Lekshminarayanan  wrote:
> > It does auto-detect it as cp1252- look at the files in the traceback and
> > you'll see lib\encodings\cp1252.py. Since cp1252 seems to be the wrong
> > encoding, try opening it as utf-8 or latin1 and see if that fixes it.
> 
> Thanks a lot ! utf-8 and latin1 were accepted !

hello i am having same issue..i believe the code is written in python 2 and i am running python 3.6..i tried at the interpreter..f =
open(filename, encoding="utf-8" and also latin-1..but then when i run my file i still get the error...also my line is at 7414..how do you find this line??...is it better to try to run the file .py in python 2??..thnxz


From rosuav at gmail.com  Sat May 19 19:02:52 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sun, 20 May 2018 09:02:52 +1000
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>
References: <1a7951080901290824p424caee3jb74b1343ce884916@mail.gmail.com>
 <ec96e1390901290849g507dcb17tf2372e573f4a5bb5@mail.gmail.com>
 <mailman.8292.1233248983.3487.python-list@python.org>
 <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>
Message-ID: <CAPTjJmrPQ6APAhwXOn5_3ayyPEpj_zk98dbEOK0t6AQ9Wa2PEQ@mail.gmail.com>

On Sun, May 20, 2018 at 8:58 AM,  <bellcanadardp at gmail.com> wrote:
> On Thursday, 29 January 2009 12:09:29 UTC-5, Anjanesh Lekshminarayanan  wrote:
>> > It does auto-detect it as cp1252- look at the files in the traceback and
>> > you'll see lib\encodings\cp1252.py. Since cp1252 seems to be the wrong
>> > encoding, try opening it as utf-8 or latin1 and see if that fixes it.
>>
>> Thanks a lot ! utf-8 and latin1 were accepted !
>
> hello i am having same issue..i believe the code is written in python 2 and i am running python 3.6..i tried at the interpreter..f =
> open(filename, encoding="utf-8" and also latin-1..but then when i run my file i still get the error...also my line is at 7414..how do you find this line??...is it better to try to run the file .py in python 2??..thnxz

You're responding to something from 2009.

Your file is apparently not encoded the way you think it is. You'll
have to figure out what it ACTUALLY is.

ChrisA


From skip.montanaro at gmail.com  Sat May 19 19:47:46 2018
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Sat, 19 May 2018 18:47:46 -0500
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>
References: <1a7951080901290824p424caee3jb74b1343ce884916@mail.gmail.com>
 <ec96e1390901290849g507dcb17tf2372e573f4a5bb5@mail.gmail.com>
 <mailman.8292.1233248983.3487.python-list@python.org>
 <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>
Message-ID: <CANc-5Uxy8T+LKC=vw6ujxnY4K+yPpA1U7-boLXSYSeDbx8DgeQ@mail.gmail.com>

As Chris indicated, you'll have to figure out the correct encoding. You
might want to check out the chardet module (available on PyPI, I believe)
and see if it can come up with a better guess. I imagine there are other
encoding guessers out there. That's just one I'm familiar with.

Skip


From mike.junk.46 at att.net  Sat May 19 21:07:46 2018
From: mike.junk.46 at att.net (Mike McClain)
Date: Sat, 19 May 2018 18:07:46 -0700
Subject: decorat{or,ion}
In-Reply-To: <87in7kmaf0.fsf@handshake.de>
References: <mailman.30.1526659203.31214.python-list@python.org>
 <20180519013116.GA16615@playground> <87in7kmaf0.fsf@handshake.de>
Message-ID: <20180520010746.GA6699@playground>

On Sat, May 19, 2018 at 08:22:59AM +0200, dieter wrote:
> Mike McClain <mike.junk.46 at att.net> writes:
<snip>
>
> An "object", in general, is something that can have attributes
> (holding the object state) and methods (defining often operations on
> the object state but in some cases also general operations (not
> related to the object state).
> In this sense, almost everything you handle in a Python script
> can be view as an object (an exception are the variables;
> they, themselves, are not objects but their values are objects).
>
> In your example, "foo" and "bar" are functions.
> As such, they are also objects - but the feature (attributes,
> methods) is rarely used explicitely (you can use
> "dir(<your function>)" to learn what attributes and methods
> your function has). You use functions in Python typically as
> you are used to use them in another programming language.
>
>
> > ...
> >     For that matter, are baz(), buz() and bug() methods if they only
> > help bar get the job done but don't have a place in bar's interface?
>
> Your functions are methods, if they are defined inside a class.
>
> Typically (there are exceptions), this means that their definition
> occurs at the top level of a "class" statement:
>
>        class CLS...:
>          ...
>          def method(self, ...):
>            ...
>
>        In this case, "method" is a method of class "CLS"
>        and its instances (called "CLS" objects).
>
> When you access a method of an object, then
> the function representing the method is wrapped;
> the wrapper remembers the object and the function and
> ensures that the object is automatically passed as
> the first parameter of the function ("self" in the example above)
> in method calls.
> Thus, the distinction between a method and a "normal" function
> is that for a method, the first parameter is passed automatically
> while in a "normal" function, the call must pass all arguments explicitly.
>
>
    Hi dieter,
        Thanks for the response, this is still a foreign language to me and I need all
    the help I can get. I'm reading the docs, doing the tutorial again but still have
    more questions than answers.
        If I understand what you said, 'taint necessarily so, I'll restate it in psuedo
    code since I've little feel for python syntax yet.

    Let's forget buz().

    def bar(*args):
        (a,b,rest) = parseArgs(args)
        def baz(x):
            ...
        def bug(k,l,m):
            ...
        bug(foo(a), baz(b), rest)

    In 'def bar()', baz & bug are simply functions.
    Are they accessable outside bar?


    class bar(*args):
        (a,b,rest) = parseArgs(args)
        def baz(x):
            ...
        ...

    In 'class bar()' I understand baz and bug should be named _baz_ , _bug_,
    if they're not expected to be called from outside bar but there's nothing
    to prevent one from doing so except manners. Also they're now methods while
    still being functions and had to be declared 'def baz(self,x):'.

    Feel free to laugh if what I'm saying is nonsense in python.

        If I execute 'bar.baz(mu)', assuming mu is enough like b above for
    baz not to throw an exception, can I expect the action of baz to change in a
    manner similar to the change in parameters? Or does something in self prevent that?

    How badly did I miss understand?

    Thanks,
    Mike
--
    I am going to go stand outside so if anyone asks about me,
        tell them I'M OUTSTANDING!


From bc at freeuk.com  Sat May 19 21:13:01 2018
From: bc at freeuk.com (bartc)
Date: Sun, 20 May 2018 02:13:01 +0100
Subject: what does := means simply?
In-Reply-To: <mailman.244.1526776756.2761.python-list@python.org>
References: <CAPTjJmq=5tt-BXXAYq7jbqCv4nAMpfP+wf-0QxMkkNk5802g5A@mail.gmail.com>
 <mailman.225.1526693200.2761.python-list@python.org>
 <V3TLC.289245$CH6.116439@fx01.am4>
 <CAPTjJmqPxG_annQKUzv6XZ79JV-tjzpS_LjZcxVnp_zs2HS37A@mail.gmail.com>
 <mailman.233.1526729942.2761.python-list@python.org>
 <YLULC.220696$Vm6.152613@fx45.am4>
 <m4p0gdtrtrs43lbfjpcsoe5f60cs37jhsp@4ax.com>
 <mailman.240.1526759265.2761.python-list@python.org>
 <Ok1MC.165333$ny5.163789@fx17.am4>
 <2bg1gd55l010vujodr58g9uil0uvrogf5d@4ax.com>
 <mailman.244.1526776756.2761.python-list@python.org>
Message-ID: <xY3MC.167349$7B3.74141@fx13.am4>

On 20/05/2018 01:39, Dennis Lee Bieber wrote:
> On Sat, 19 May 2018 23:14:08 +0100, bartc <bc at freeuk.com> declaimed the
> following:
> 
> 
>> The comments and examples here:
>> https://en.wikipedia.org/wiki/Netpbm_format, and all actual ppm files
>> I've come across, suggest the 3 parts of the header (2 parts for P1/P4)
>> are on separate lines. That is, separated by newlines. The comments are
>> a small detail that is not hard to deal with.
>>
> 
> 	Wikipedia is not a definitive document...
> 
> http://netpbm.sourceforge.net/doc/ppm.html has
> """
> Each PPM image consists of the following:
> 
>      A "magic number" for identifying the file type. A ppm image's magic
> number is the two characters "P6".
>      Whitespace (blanks, TABs, CRs, LFs).
>      A width, formatted as ASCII characters in decimal.
>      Whitespace.
>      A height, again in ASCII decimal.
>      Whitespace.
>      The maximum color value (Maxval), again in ASCII decimal. Must be less
> than 65536 and more than zero.
>      A single whitespace character (usually a newline).
> """

I think if you are going to be generating ppm, then the best choice of 
format, for the widest acceptance, is to separate the header groups with 
a newline. (As I mentioned my downloaded viewer needs a new line after 
the first group. My own viewer, which I only threw together the other 
day to test that benchmark, also expects the newlines. Otherwise I might 
need to do 5 minutes' coding to fix it.)

(Regarding those benchmarks 
(https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html), 
as far as I can tell every language generates the ppm file inline (no 
special ppm library), and they all generate the P4 signature on one line 
and width/height on the next line.

(Click on any source file and look for "P4". Most do it with less fuss 
than Python too.))

> 	That all the ones you've seen have a certain layout may only mean that
> the generating software used a common library implementation:
> http://netpbm.sourceforge.net/doc/libnetpbm.html

Blimey, it makes a meal of it. I got the impression this was supposed to 
be a simple image format, and with the line-oriented all-text formats it 
was.

But it could be worse: they might have used XML.

-- 
bartc


From mike.junk.46 at att.net  Sat May 19 21:36:20 2018
From: mike.junk.46 at att.net (Mike McClain)
Date: Sat, 19 May 2018 18:36:20 -0700
Subject: decorat{or,ion}
In-Reply-To: <pdojbj$3fh$7@blaine.gmane.org>
References: <mailman.30.1526659203.31214.python-list@python.org>
 <20180519013116.GA16615@playground> <pdojbj$3fh$7@blaine.gmane.org>
Message-ID: <20180520013620.GB6699@playground>

On Sat, May 19, 2018 at 07:22:28AM +0000, Steven D'Aprano wrote:
> On Fri, 18 May 2018 18:31:16 -0700, Mike McClain wrote:
>
<snip>
> I *think* you are describing something like this:
Real close!
> def foo(x):
>     return x + 1
>
> def bar(arg):
>     a = baz(arg)  # do some magic
>     result = bar(a)  # call the important function
      result = foo(a)  #                    small change
>     return buz(result)  # and a bit more magic

<snip>

> Typically, we wouldn't use the term "decorator" or "decoration" to
> describe a hand-written function like bar(), even if it calls foo().
> Normally the "decorator" terminology is reserved for one of two things:
>
> (1) The software design pattern of using a factory function to "wrap" one
> function inside an automatically generated wrapper function that provides
> the extra additional functionality:
>
>
> def factory(func):
>     # Wrap func() to force it to return zero instead of negative
>     def wrapped(arg):
>         result = func(arg)
>         if result < 0:
>             result = 0
>         return result
>     # return the wrapped function
>     return wrapped
>
>
> (2) the syntax for applying such a factory function:
>
> @factory
> def myfunction(x):
>     return 5 - x

Too early to tell. Your definition of factory returns a function ref
so needs assignment unless used (execd) immediately. Yes, no?

def factory(func):
    # Wrap func() to a different kind of magic
    def bar(arg):
        a = baz(arg)  # do some magic
        result = func(a)  #                    small change
        return buz(result)  # and a bit more magic
    return bar

@factory
def foo(x):
    return something_outrageous

At this point it looks to me that I've created a nameless function
that can't be used. How does the assignment take place?

> Does this help?

If I've understood you correctly it helps one Heck of a lot.
If I haven't, no doubt the fault is mine.
I've used several procedural languages but you OOP folk think in
strange paths. So far it is a fun trip.

> I know these concepts are sometimes tricky. Concrete examples often make
> them easier to understand. Feel free to ask more questions as needed.
> --
> Steve

Walk with Light,
Mike
--
    I am going to go stand outside so if anyone asks about me,
        tell them I'M OUTSTANDING!


From mikhailwas at gmail.com  Sat May 19 22:58:27 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Sun, 20 May 2018 05:58:27 +0300
Subject: "Data blocks" syntax specification draft
Message-ID: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>

I have made up a printable PDF with the current version
of the syntax suggestion.

https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf

After some of your comments I've made some further
re-considerations, e.g. element separation should
be now much simpler.
A lot of examples with comparison included.


Comments, suggestions are welcome.


M


From rosuav at gmail.com  Sat May 19 23:05:47 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sun, 20 May 2018 13:05:47 +1000
Subject: "Data blocks" syntax specification draft
In-Reply-To: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
Message-ID: <CAPTjJmrBO5i1S+15wK9nybdHN1BNQ=1TmLAAQb_ou9GGMGfzuQ@mail.gmail.com>

On Sun, May 20, 2018 at 12:58 PM, Mikhail V <mikhailwas at gmail.com> wrote:
> I have made up a printable PDF with the current version
> of the syntax suggestion.
>
> https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf
>
> After some of your comments I've made some further
> re-considerations, e.g. element separation should
> be now much simpler.
> A lot of examples with comparison included.
>
>
> Comments, suggestions are welcome.
>

One comment.

I'm not interested in downloading a PDF. Can you rework your document
to be in a more textual format like Markdown or reStructuredText?
Since you're hosting on GitHub anyway, the rendering can be done
automatically.

ChrisA


From steve+comp.lang.python at pearwood.info  Sun May 20 01:29:49 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sun, 20 May 2018 05:29:49 +0000 (UTC)
Subject: (Not actually off-topic) Anyone here used Rebol or Red?
References: <pdpcsu$tc5$1@blaine.gmane.org>
Message-ID: <pdr14c$tc5$2@blaine.gmane.org>

On Sat, 19 May 2018 14:38:22 +0000, Steven D'Aprano wrote:

> I'm looking for anyone with experience using either Rebol or its more
> modern fork, Red.
> 
> And yes, it is relevant to Python.

Never mind, the Timbot has answered my question on the Python-Ideas list, 
so we're all good.



-- 
Steve



From __peter__ at web.de  Sun May 20 03:55:11 2018
From: __peter__ at web.de (Peter Otten)
Date: Sun, 20 May 2018 09:55:11 +0200
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
References: <1a7951080901290824p424caee3jb74b1343ce884916@mail.gmail.com>
 <ec96e1390901290849g507dcb17tf2372e573f4a5bb5@mail.gmail.com>
 <mailman.8292.1233248983.3487.python-list@python.org>
 <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>
Message-ID: <pdr9h3$qbq$1@blaine.gmane.org>

bellcanadardp at gmail.com wrote:

> On Thursday, 29 January 2009 12:09:29 UTC-5, Anjanesh Lekshminarayanan 
> wrote:
>> > It does auto-detect it as cp1252- look at the files in the traceback
>> > and you'll see lib\encodings\cp1252.py. Since cp1252 seems to be the
>> > wrong encoding, try opening it as utf-8 or latin1 and see if that fixes
>> > it.
>> 
>> Thanks a lot ! utf-8 and latin1 were accepted !
> 
> hello i am having same issue..i believe the code is written in python 2
> and i am running python 3.6..i tried at the interpreter..f =
> open(filename, encoding="utf-8" and also latin-1..but then when i run my
> file i still get the error...also my line is at 7414..how do you find this
> line??...is it better to try to run the file .py in python 2??..thnxz

open(filename, encoding="latin-1") will succeed with *every* file -- the 
characters may be nonsensical, but you will *not* get a UnicodeDecodeError.

> ...is it better to try to run the file .py in python 2?

Not "better", but perhaps easier. If the code works with Python 2 then I 
recommend that you use that.

If you want help to debug it you need to provide some of the relevant source 
code and -- first and foremost -- the traceback.

> my line is at 7414..how do you find this line?

Read the traceback carefully. It should contain both filename and line.



From hjp-python at hjp.at  Sun May 20 05:19:42 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Sun, 20 May 2018 11:19:42 +0200
Subject: what does := means simply?
In-Reply-To: <BZULC.164040$ny5.143736@fx17.am4>
References: <dlrufd9sm0v230qses3mlitcf324cu12v6@4ax.com>
 <pdnsuj$3fh$6@blaine.gmane.org>
 <mailman.224.1526691745.2761.python-list@python.org>
 <fQKLC.163818$ny5.147948@fx17.am4>
 <CAPTjJmq=5tt-BXXAYq7jbqCv4nAMpfP+wf-0QxMkkNk5802g5A@mail.gmail.com>
 <mailman.225.1526693200.2761.python-list@python.org>
 <V3TLC.289245$CH6.116439@fx01.am4>
 <20180519113317.w7ijjsyaallwp2ud@hjp.at>
 <mailman.232.1526729599.2761.python-list@python.org>
 <BZULC.164040$ny5.143736@fx17.am4>
Message-ID: <20180520091942.lr4ivj43hdnr3pb5@hjp.at>

On 2018-05-19 13:43:14 +0100, bartc wrote:
> On 19/05/2018 12:33, Peter J. Holzer wrote:
> > On 2018-05-19 11:33:26 +0100, bartc wrote:
> 
> > > Not you understand why some of us don't bother with 'text mode' files.
> > 
> > "Not" or "Now"?
> 
> Now.
> 
> > Yesterday you claimed that you worked with them for 40 years.
> 
> Text files, yes. Not 'text mode' which is something inflicted on us by the C
> library.

I very much enjoy the fact that the programming languages I've used to
process text files in the last 15 years (i.e. Perl and Python) can
convert just about any character encoding and any newline convention to
a canonical representation with a single parameter to open.

When the "textmode" in the C library was invented (it wasn't just C,
though: Wirth's Modula-2 book describes a remarkably similar mechanism)
the situation was a lot more complicated: Many operating systems didn't
have a newline character (or character sequence). They had fixed length
records or a length indicator at the start of each line or even more
complicated schemes. The textmode removes these differences - you always
get lines terminated by \n. Without a textmode, you would have to deal
with all those different file formats if you wanted to write a portable
version of even a simple program like cat. The world has become simpler
in this regard.


> > > However if you have an actual EBCDIC system and would to read .ppm files,
> > > then you will have trouble reading the numeric parameters as they are
> > > expressed using sequences of ASCII digits.
> 
> > I think the simplest way would be perform the calculation by hand
> > (new_value = old_value * 10 + next_byte - 0x30). At least in a language
> > which lets me process individual bytes easily. That would even work on
> > both ASCII and EBCDIC based systems (and on every other platform, too).
> 
> /The/ simplest? Don't forget the numbers can be several digits each. Here's
> how I read them (NOT Python):
> 
>     readln @f, width, height
> 
> Would it work in an EBCDIC based system? Probably not. But, who cares?

The premise in your previous message was that you are on an EBCDIC based
system (and a quite limited at that which doesn't even have a character
set conversion library, so you would have to program the character set
conversion yourself). So you can't cop out with "I don't care about
EBCDIC based systems".

(Your single readln wouldn't work reliably on ASCII systems either,
since - as others have already pointed out - the header format of a PPM
file isn't quite as simple as you imagine).

> (Perhaps someone who has access to an EBCDIC system can try a .PPM reader to
> see what happens. I suspect that won't work either.)

A PPM reader for an EBCDIC system will certainly be able to read PPM
files on an EBCDIC system. Why would anybody write and release software
which doesn't work on the intended target system?

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180520/dd1fb609/attachment.sig>

From bc at freeuk.com  Sun May 20 07:11:34 2018
From: bc at freeuk.com (bartc)
Date: Sun, 20 May 2018 12:11:34 +0100
Subject: what does := means simply?
In-Reply-To: <mailman.247.1526781497.2761.python-list@python.org>
References: <V3TLC.289245$CH6.116439@fx01.am4>
 <CAPTjJmqPxG_annQKUzv6XZ79JV-tjzpS_LjZcxVnp_zs2HS37A@mail.gmail.com>
 <mailman.233.1526729942.2761.python-list@python.org>
 <YLULC.220696$Vm6.152613@fx45.am4>
 <m4p0gdtrtrs43lbfjpcsoe5f60cs37jhsp@4ax.com>
 <mailman.240.1526759265.2761.python-list@python.org>
 <Ok1MC.165333$ny5.163789@fx17.am4>
 <2bg1gd55l010vujodr58g9uil0uvrogf5d@4ax.com>
 <mailman.244.1526776756.2761.python-list@python.org>
 <xY3MC.167349$7B3.74141@fx13.am4>
 <ktj1gdt31c2e6r427uhtnre4ohusm9v15d@4ax.com>
 <mailman.247.1526781497.2761.python-list@python.org>
Message-ID: <FJcMC.34772$463.31746@fx21.am4>

On 20/05/2018 02:58, Dennis Lee Bieber wrote:
> On Sun, 20 May 2018 02:13:01 +0100, bartc <bc at freeuk.com> declaimed the
> following:
> 
>> I think if you are going to be generating ppm, then the best choice of
>> format, for the widest acceptance, is to separate the header groups with
>> a newline. (As I mentioned my downloaded viewer needs a new line after
>> the first group. My own viewer, which I only threw together the other
>> day to test that benchmark, also expects the newlines. Otherwise I might
>> need to do 5 minutes' coding to fix it.)
>>
> 	IrfanView had no problem opening my file, where the only <lf> was the
> one after the maxval field. Between that as an example, and the
> documentation of the format, one could decree that any reader that
> /requires/ <lf>s at various points is erroneous or incomplete.

I think that's the wrong approach. You need to work to the lowest common 
denominator, not the highest. (Within reason anyway.)

If you tested half a dozen viewers, and two of them don't need any 
newlines between groups, and the rest need at least one, or between all 
groups, what does this tell you about how you should be generating your 
file?

You may not know what viewer or reader is to be used.

I have a suspicion (although I will have to test more) that newlines 
between groups is more universally accepted.

(I tried to get irfanview but it tells me I need Windows 10, which is an 
odd requirement for an image viewer. So I'll have to try it later.)

-- 
bartc


From bc at freeuk.com  Sun May 20 07:38:59 2018
From: bc at freeuk.com (bartc)
Date: Sun, 20 May 2018 12:38:59 +0100
Subject: what does := means simply?
In-Reply-To: <mailman.252.1526807990.2761.python-list@python.org>
References: <dlrufd9sm0v230qses3mlitcf324cu12v6@4ax.com>
 <pdnsuj$3fh$6@blaine.gmane.org>
 <mailman.224.1526691745.2761.python-list@python.org>
 <fQKLC.163818$ny5.147948@fx17.am4>
 <CAPTjJmq=5tt-BXXAYq7jbqCv4nAMpfP+wf-0QxMkkNk5802g5A@mail.gmail.com>
 <mailman.225.1526693200.2761.python-list@python.org>
 <V3TLC.289245$CH6.116439@fx01.am4> <20180519113317.w7ijjsyaallwp2ud@hjp.at>
 <mailman.232.1526729599.2761.python-list@python.org>
 <BZULC.164040$ny5.143736@fx17.am4> <20180520091942.lr4ivj43hdnr3pb5@hjp.at>
 <mailman.252.1526807990.2761.python-list@python.org>
Message-ID: <m7dMC.329719$nr7.291374@fx31.am4>

On 20/05/2018 10:19, Peter J. Holzer wrote:
> On 2018-05-19 13:43:14 +0100, bartc wrote:

>> Text files, yes. Not 'text mode' which is something inflicted on us by the C
>> library.
> 
> I very much enjoy the fact that the programming languages I've used to
> process text files in the last 15 years (i.e. Perl and Python) can
> convert just about any character encoding and any newline convention to
> a canonical representation with a single parameter to open.

And I quite like the fact that I have complete control over what is 
being read or written. And if there is some obscure bug, that the actual 
contents of a file aren't hidden behind some protocols in library.

> When the "textmode" in the C library was invented (it wasn't just C,
> though: Wirth's Modula-2 book describes a remarkably similar mechanism)

I also like the way that the single '\n' character in a source file 
conveniently matches the single '\n' character used by Unix. So no 
translation of any kind is needed, and you can assume that if you write 
1000 empty lines the output file will be 1000 bytes long.

The complications are in all the other operating systems. And the bugs 
when someone assumes that one '\n' in a program equals one 10 byte in a 
file, will only occur on those other systems.

> The premise in your previous message was that you are on an EBCDIC based
> system (and a quite limited at that which doesn't even have a character
> set conversion library, so you would have to program the character set
> conversion yourself). So you can't cop out with "I don't care about
> EBCDIC based systems".

I think it was Steven D'Aprano who brought up EBCDIC. And not seriously.

> (Your single readln wouldn't work reliably on ASCII systems either,
> since - as others have already pointed out - the header format of a PPM
> file isn't quite as simple as you imagine).

The line-reading has to be in a loop in order to skip comments, which I 
didn't show because the bigger obstacle in Python appeared to be reading 
the numbers (and is not needed for those specific Mandelbrot images). 
It's something like this: repeat ... until width.isint

> A PPM reader for an EBCDIC system will certainly be able to read PPM
> files on an EBCDIC system. Why would anybody write and release software
> which doesn't work on the intended target system?

Then the /same software/ probably wouldn't work anywhere else. I mean 
taking source which doesn't know or care about what system its on, and 
that operates on a ppm file downloaded from the internet.

-- 
bartc


From bellcanadardp at gmail.com  Sun May 20 07:59:12 2018
From: bellcanadardp at gmail.com (bellcanadardp at gmail.com)
Date: Sun, 20 May 2018 04:59:12 -0700 (PDT)
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <mailman.243.1526773687.2761.python-list@python.org>
References: <1a7951080901290824p424caee3jb74b1343ce884916@mail.gmail.com>
 <ec96e1390901290849g507dcb17tf2372e573f4a5bb5@mail.gmail.com>
 <mailman.8292.1233248983.3487.python-list@python.org>
 <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>
 <CANc-5Uxy8T+LKC=vw6ujxnY4K+yPpA1U7-boLXSYSeDbx8DgeQ@mail.gmail.com>
 <mailman.243.1526773687.2761.python-list@python.org>
Message-ID: <27ef2bfb-e3ed-495c-bb98-f71e502d412a@googlegroups.com>

On Saturday, 19 May 2018 19:48:20 UTC-4, Skip Montanaro  wrote:
> As Chris indicated, you'll have to figure out the correct encoding. You
> might want to check out the chardet module (available on PyPI, I believe)
> and see if it can come up with a better guess. I imagine there are other
> encoding guessers out there. That's just one I'm familiar with.
> 
> Skip

hello Skip
thank you for the reply, but how exactly am i supposed to find oout what is the correct encodeing??

tommy


From bellcanadardp at gmail.com  Sun May 20 07:59:42 2018
From: bellcanadardp at gmail.com (bellcanadardp at gmail.com)
Date: Sun, 20 May 2018 04:59:42 -0700 (PDT)
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <mailman.242.1526770975.2761.python-list@python.org>
References: <1a7951080901290824p424caee3jb74b1343ce884916@mail.gmail.com>
 <ec96e1390901290849g507dcb17tf2372e573f4a5bb5@mail.gmail.com>
 <mailman.8292.1233248983.3487.python-list@python.org>
 <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>
 <CAPTjJmrPQ6APAhwXOn5_3ayyPEpj_zk98dbEOK0t6AQ9Wa2PEQ@mail.gmail.com>
 <mailman.242.1526770975.2761.python-list@python.org>
Message-ID: <3b7ef81a-a830-482e-9a00-d2246735d126@googlegroups.com>

On Saturday, 19 May 2018 19:03:09 UTC-4, Chris Angelico  wrote:
> On Sun, May 20, 2018 at 8:58 AM,  <bellcanadardp at gmail.com> wrote:
> > On Thursday, 29 January 2009 12:09:29 UTC-5, Anjanesh Lekshminarayanan  wrote:
> >> > It does auto-detect it as cp1252- look at the files in the traceback and
> >> > you'll see lib\encodings\cp1252.py. Since cp1252 seems to be the wrong
> >> > encoding, try opening it as utf-8 or latin1 and see if that fixes it.
> >>
> >> Thanks a lot ! utf-8 and latin1 were accepted !
> >
> > hello i am having same issue..i believe the code is written in python 2 and i am running python 3.6..i tried at the interpreter..f =
> > open(filename, encoding="utf-8" and also latin-1..but then when i run my file i still get the error...also my line is at 7414..how do you find this line??...is it better to try to run the file .py in python 2??..thnxz
> 
> You're responding to something from 2009.
> 
> Your file is apparently not encoded the way you think it is. You'll
> have to figure out what it ACTUALLY is.
> 
> ChrisA


hello Chris
thank you for the reply, but how exactly am i supposed to find oout what is the correct encodeing??


From Richard at Damon-Family.org  Sun May 20 08:58:09 2018
From: Richard at Damon-Family.org (Richard Damon)
Date: Sun, 20 May 2018 08:58:09 -0400
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <3b7ef81a-a830-482e-9a00-d2246735d126@googlegroups.com>
References: <1a7951080901290824p424caee3jb74b1343ce884916@mail.gmail.com>
 <ec96e1390901290849g507dcb17tf2372e573f4a5bb5@mail.gmail.com>
 <mailman.8292.1233248983.3487.python-list@python.org>
 <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>
 <CAPTjJmrPQ6APAhwXOn5_3ayyPEpj_zk98dbEOK0t6AQ9Wa2PEQ@mail.gmail.com>
 <mailman.242.1526770975.2761.python-list@python.org>
 <3b7ef81a-a830-482e-9a00-d2246735d126@googlegroups.com>
Message-ID: <9fed7701-3d00-9207-ed84-4367474fc898@Damon-Family.org>

On 5/20/18 7:59 AM, bellcanadardp at gmail.com wrote:
> On Saturday, 19 May 2018 19:03:09 UTC-4, Chris Angelico  wrote:
>> On Sun, May 20, 2018 at 8:58 AM,  <bellcanadardp at gmail.com> wrote:
>>> On Thursday, 29 January 2009 12:09:29 UTC-5, Anjanesh Lekshminarayanan  wrote:
>>>>> It does auto-detect it as cp1252- look at the files in the traceback and
>>>>> you'll see lib\encodings\cp1252.py. Since cp1252 seems to be the wrong
>>>>> encoding, try opening it as utf-8 or latin1 and see if that fixes it.
>>>> Thanks a lot ! utf-8 and latin1 were accepted !
>>> hello i am having same issue..i believe the code is written in python 2 and i am running python 3.6..i tried at the interpreter..f =
>>> open(filename, encoding="utf-8" and also latin-1..but then when i run my file i still get the error...also my line is at 7414..how do you find this line??...is it better to try to run the file .py in python 2??..thnxz
>> You're responding to something from 2009.
>>
>> Your file is apparently not encoded the way you think it is. You'll
>> have to figure out what it ACTUALLY is.
>>
>> ChrisA
>
> hello Chris
> thank you for the reply, but how exactly am i supposed to find oout what is the correct encodeing??

Basically, you need to know it from some other source to be totally
certain. This is part of the 'disaster' of 8 bit code pages.

There are a few guesses that can be done that often get you close.
utf-8, IF it validates is almost always what the file is (unless it is
just ASCII, where you generally never even notice the issue).

There are programs that will look at some heuristics in the file and try
to guess. Another option is to open the file in a text editor which will
be more forgiving and show the bad character as an error symbol, and see
if? you can recognize what 'language' (human) the user seems to have
been using, and guess the character encoding from that (or just remove
the bad characters if they are just in comments/unimportant strings.)

-- 
Richard Damon



From skip.montanaro at gmail.com  Sun May 20 09:07:47 2018
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Sun, 20 May 2018 08:07:47 -0500
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <27ef2bfb-e3ed-495c-bb98-f71e502d412a@googlegroups.com>
References: <1a7951080901290824p424caee3jb74b1343ce884916@mail.gmail.com>
 <ec96e1390901290849g507dcb17tf2372e573f4a5bb5@mail.gmail.com>
 <mailman.8292.1233248983.3487.python-list@python.org>
 <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>
 <CANc-5Uxy8T+LKC=vw6ujxnY4K+yPpA1U7-boLXSYSeDbx8DgeQ@mail.gmail.com>
 <mailman.243.1526773687.2761.python-list@python.org>
 <27ef2bfb-e3ed-495c-bb98-f71e502d412a@googlegroups.com>
Message-ID: <CANc-5UxFU+TQMqaEXHziQwF3M_Q4cJFh0k3KA3FVxEKyVs=3mg@mail.gmail.com>

> how exactly am i supposed to find oout what is the correct encodeing?

It seems you are a Python beginner. Rather than just tell you how to use
this one module, I'll point you at some of the ways to get help through
Python.

* On pypi.org, search for "chardet" and see if the author provided online
documentation links.

* At the shell prompt, you might well have a "pydoc" command. Try "pydoc
chardet" after installing it.

* At the Python ">>> " prompt, import the chardet module, then use the
help() function to get some basic help gleaned from the module itself.
(This is basically what the pydoc command does.)

>>> import chardet
>>> help(chardet)
...

* Even more abbreviated than the help() function, the dir() function will
just tell you what attributes an object (not just a module) has.

* Go to docs.python.org and do some tutorial/beginner reading.

* Finally, try searching for "how to get help in python" in your favorite
search engine. There are plenty of useful websites/blogs/articles devoted
to this topic.

Skip


From Karsten.Hilbert at gmx.net  Sun May 20 09:43:54 2018
From: Karsten.Hilbert at gmx.net (Karsten Hilbert)
Date: Sun, 20 May 2018 15:43:54 +0200
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <27ef2bfb-e3ed-495c-bb98-f71e502d412a@googlegroups.com>
References: <1a7951080901290824p424caee3jb74b1343ce884916@mail.gmail.com>
 <ec96e1390901290849g507dcb17tf2372e573f4a5bb5@mail.gmail.com>
 <mailman.8292.1233248983.3487.python-list@python.org>
 <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>
 <CANc-5Uxy8T+LKC=vw6ujxnY4K+yPpA1U7-boLXSYSeDbx8DgeQ@mail.gmail.com>
 <mailman.243.1526773687.2761.python-list@python.org>
 <27ef2bfb-e3ed-495c-bb98-f71e502d412a@googlegroups.com>
Message-ID: <20180520134354.GB2192@hermes.hilbert.loc>

On Sun, May 20, 2018 at 04:59:12AM -0700, bellcanadardp at gmail.com wrote:

> On Saturday, 19 May 2018 19:48:20 UTC-4, Skip Montanaro  wrote:
> > As Chris indicated, you'll have to figure out the correct encoding. You
> > might want to check out the chardet module (available on PyPI, I believe)
> > and see if it can come up with a better guess. I imagine there are other
> > encoding guessers out there. That's just one I'm familiar with.
> 
> thank you for the reply, but how exactly am i supposed to find oout what is the correct encodeing??

One CAN NOT.

The best you can do is to go ask the canonical source of the
file what encoding the file is _supposed_ to be in.

Then go from there and allow for errors.

Karsten
-- 


From bellcanadardp at gmail.com  Sun May 20 10:30:18 2018
From: bellcanadardp at gmail.com (bellcanadardp at gmail.com)
Date: Sun, 20 May 2018 07:30:18 -0700 (PDT)
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <mailman.253.1526821099.2761.python-list@python.org>
References: <1a7951080901290824p424caee3jb74b1343ce884916@mail.gmail.com>
 <ec96e1390901290849g507dcb17tf2372e573f4a5bb5@mail.gmail.com>
 <mailman.8292.1233248983.3487.python-list@python.org>
 <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>
 <CAPTjJmrPQ6APAhwXOn5_3ayyPEpj_zk98dbEOK0t6AQ9Wa2PEQ@mail.gmail.com>
 <mailman.242.1526770975.2761.python-list@python.org>
 <3b7ef81a-a830-482e-9a00-d2246735d126@googlegroups.com>
 <9fed7701-3d00-9207-ed84-4367474fc898@Damon-Family.org>
 <mailman.253.1526821099.2761.python-list@python.org>
Message-ID: <73951445-7124-4ded-a8f5-dfff0246ac82@googlegroups.com>

On Sunday, 20 May 2018 08:58:32 UTC-4, Richard Damon  wrote:
> On 5/20/18 7:59 AM, bellcanadardp at gmail.com wrote:
> > On Saturday, 19 May 2018 19:03:09 UTC-4, Chris Angelico  wrote:
> >> On Sun, May 20, 2018 at 8:58 AM,  <bellcanadardp at gmail.com> wrote:
> >>> On Thursday, 29 January 2009 12:09:29 UTC-5, Anjanesh Lekshminarayanan  wrote:
> >>>>> It does auto-detect it as cp1252- look at the files in the traceback and
> >>>>> you'll see lib\encodings\cp1252.py. Since cp1252 seems to be the wrong
> >>>>> encoding, try opening it as utf-8 or latin1 and see if that fixes it.
> >>>> Thanks a lot ! utf-8 and latin1 were accepted !
> >>> hello i am having same issue..i believe the code is written in python 2 and i am running python 3.6..i tried at the interpreter..f =
> >>> open(filename, encoding="utf-8" and also latin-1..but then when i run my file i still get the error...also my line is at 7414..how do you find this line??...is it better to try to run the file .py in python 2??..thnxz
> >> You're responding to something from 2009.
> >>
> >> Your file is apparently not encoded the way you think it is. You'll
> >> have to figure out what it ACTUALLY is.
> >>
> >> ChrisA
> >
> > hello Chris
> > thank you for the reply, but how exactly am i supposed to find oout what is the correct encodeing??
> 
> Basically, you need to know it from some other source to be totally
> certain. This is part of the 'disaster' of 8 bit code pages.
> 
> There are a few guesses that can be done that often get you close.
> utf-8, IF it validates is almost always what the file is (unless it is
> just ASCII, where you generally never even notice the issue).
> 
> There are programs that will look at some heuristics in the file and try
> to guess. Another option is to open the file in a text editor which will
> be more forgiving and show the bad character as an error symbol, and see
> if? you can recognize what 'language' (human) the user seems to have
> been using, and guess the character encoding from that (or just remove
> the bad characters if they are just in comments/unimportant strings.)
> 
> -- 
> Richard Damon

thank you for the email reply Richard Damon
i will study all your great  guidelines

i actually got my script to function by running it in python 2.7
thanx for your kind suggestions very much

tommy


From bc at freeuk.com  Sun May 20 14:29:08 2018
From: bc at freeuk.com (bartc)
Date: Sun, 20 May 2018 19:29:08 +0100
Subject: what does := means simply?
In-Reply-To: <mailman.258.1526830645.2761.python-list@python.org>
References: <fQKLC.163818$ny5.147948@fx17.am4>
 <CAPTjJmq=5tt-BXXAYq7jbqCv4nAMpfP+wf-0QxMkkNk5802g5A@mail.gmail.com>
 <mailman.225.1526693200.2761.python-list@python.org>
 <V3TLC.289245$CH6.116439@fx01.am4> <20180519113317.w7ijjsyaallwp2ud@hjp.at>
 <mailman.232.1526729599.2761.python-list@python.org>
 <BZULC.164040$ny5.143736@fx17.am4> <20180520091942.lr4ivj43hdnr3pb5@hjp.at>
 <mailman.252.1526807990.2761.python-list@python.org>
 <m7dMC.329719$nr7.291374@fx31.am4>
 <sr23gdhmq107n2fro4gcgj4pfjo4ii6j9d@4ax.com>
 <mailman.258.1526830645.2761.python-list@python.org>
Message-ID: <T7jMC.211177$RH3.127045@fx27.am4>

On 20/05/2018 16:37, Dennis Lee Bieber wrote:
> On Sun, 20 May 2018 12:38:59 +0100, bartc <bc at freeuk.com> declaimed the

> 	Just for giggles, I decided to write the start of a PPM reader (it only
> handles P6 binary, doesn't have the code for the other styles, and doesn't
> incorporate PPM writer functions but...)
> 
> 	It successfully processed the PPM file my prior writing code
> generated...
> 
> -=-=-=-=-=-
> import struct
> 
> class PPM(object):
...

> -=-=-=-=-=-
> Type: b'P6'	Width: 3	Height: 3	MaxVal: 255
> [(0, 255, 0), (128, 128, 128), (255, 0, 0), (128, 128, 128), (255, 255,
> 255), (128, 128, 128), (0, 0, 255), (128, 128, 128), (0, 0, 0)]

Yes, that appears to work. (But I think it has a bug when there are two 
successive #-comment lines.)

Meanwhile I've given up my campaign to have only line-oriented headers, 
and spent the five minutes needed to allow for free-format headers, and 
actually it's now simpler:

   readln @f,sig
   width  := readnextint(f)  # a 6-line function returning 0 on error
   height := readnextint(f)
   maxval := readnextint(f)  # (for some file types)

However I don't think this works properly when a comment follows (on the 
same line) the last format item, as a well-formed header will have an 
extra white-space character to be skipped. I believe your program might 
have the same problem; it will read the header OK, but not start reading 
the data at the right place.

(A rather poor specification I think which could have been tightened up.)

-- 
bartc



From jf_byrnes at comcast.net  Sun May 20 15:03:44 2018
From: jf_byrnes at comcast.net (Jim)
Date: Sun, 20 May 2018 14:03:44 -0500
Subject: Python 3.6 causes error, python 3.5 does not.
Message-ID: <pdsgmd$vfo$1@blaine.gmane.org>

Mint 18
Libreoffice 5.1.6.2
Python 3.6.5 in one virtual environment
Python 3.5.2 in another

I am writing a script that uses pyautogui to get some data and paste it 
into a Libreoffice calc file, there by bypassing the complexity of uno.

The problem is it runs fine if I use python 3.5. If I use python 3.6 it 
opens the calc file then pops up a dialog saying "std::bad_alloc". There 
are no relevant errors in the terminal. At this point I must reload the 
file and let calc recover it. I googled "std::bad_alloc" but didn'

This is the portion of the code that causes the error:

import pyautogui
import subprocess
import threading
import time

LONG_ENOUGH = 5

class LO():
     '''Manipulate libreoffice not using UNO'''
     def __init__(self):
         self.filename = 
'/home/jfb/Documents/Financial/Investing/Stocks.ods'
         opener = threading.Thread(target=self.open_it, 
args=(self.filename,))
         opener.start()
         time.sleep(5) #LONG_ENOUGH)
         #self.manipulate_LO()

     #Open and work with libreoffice
     def open_it(self, filename):
         #subprocess.call(["libreoffice", filename])
         subprocess.run(["libreoffice", filename])

lo = LO()

To complicate matters not all .ods files show this problem. I ran some 
tests. Two of my .ods files are effected but a couple of others are not. 
A new test file I created is not effected.

I don't know if I have a Libreoffice problem, file corruption or a 
Python problem. The fact that 3.6 gives an error but 3.5 does not is the 
reason I decided to ask here first.

Regards,  Jim



From bruceg113355 at gmail.com  Sun May 20 15:54:01 2018
From: bruceg113355 at gmail.com (bruceg113355 at gmail.com)
Date: Sun, 20 May 2018 12:54:01 -0700 (PDT)
Subject: best way to remove leading zeros from a tuple like string
Message-ID: <189bca64-1c7e-459f-a8a2-59db0e1752f8@googlegroups.com>

Lets say I have the following tuple like string.
  (128, 020, 008, 255)

What is the best way to to remove leading zeroes and end up with the following.
  (128, 20, 8, 255)        -- I do not care about spaces

This is the solution I came up with
    s = "(128, 020, 008, 255)"
    v = s.replace ("(", "")
    v = v.replace (")", "")
    vv = ",".join([str(int(i)) for i in v.split(",")])
    final = "(" + vv + ")"


Thanks,
Bruce


From Richard at Damon-Family.org  Sun May 20 16:36:12 2018
From: Richard at Damon-Family.org (Richard Damon)
Date: Sun, 20 May 2018 16:36:12 -0400
Subject: what does := means simply?
In-Reply-To: <kn53gd5rnbqgmjdc6243p3jooia0hpsno7@4ax.com>
References: <YLULC.220696$Vm6.152613@fx45.am4>
 <m4p0gdtrtrs43lbfjpcsoe5f60cs37jhsp@4ax.com>
 <mailman.240.1526759265.2761.python-list@python.org>
 <Ok1MC.165333$ny5.163789@fx17.am4>
 <2bg1gd55l010vujodr58g9uil0uvrogf5d@4ax.com>
 <mailman.244.1526776756.2761.python-list@python.org>
 <xY3MC.167349$7B3.74141@fx13.am4>
 <ktj1gdt31c2e6r427uhtnre4ohusm9v15d@4ax.com>
 <mailman.247.1526781497.2761.python-list@python.org>
 <FJcMC.34772$463.31746@fx21.am4> <kn53gd5rnbqgmjdc6243p3jooia0hpsno7@4ax.com>
Message-ID: <9c4a111d-2eac-078f-38e9-0db1e177555a@Damon-Family.org>

On 5/20/18 11:52 AM, Dennis Lee Bieber wrote:
> On Sun, 20 May 2018 12:11:34 +0100, bartc <bc at freeuk.com> declaimed the
> following:
>
>> I think that's the wrong approach. You need to work to the lowest common 
>> denominator, not the highest. (Within reason anyway.)
>>
> 	If a reader can not handle permitted variations documented in a
> specification, then that reader is erroneous, and bug report should be
> filed for it.
>
>> If you tested half a dozen viewers, and two of them don't need any 
>> newlines between groups, and the rest need at least one, or between all 
>> groups, what does this tell you about how you should be generating your 
>> file?
>>
> 	Nothing about how /I/ should generate the file -- it tells me those
> readers are non-conformant with the specification.
>
> 	The specification document drives the requirements for reading and
> writing, the requirements drive the implementation. If a program does not
> implement the requirements derived from the specification, that program is
> incomplete and/or in error.
>
> 	That most implementations are using a <newline> convention when
> /writing/ a PPM file does not negate the fact that the specification
> permits for no <newlines> at all (barring the need for one at the end of a
> comment), and a conformant /reader/ program shall accept those variations.
>
>
There are 3 basic ways to write something to a spec like this.

1) Write exactly to the specification, choosing options for generation
based on what is the easiest for you, and if other tools can't read
this, insist on writing bug reports.

2) Try to maximize portability by not only looking at the specs, but
also common implementations, and choosing the options that maximize the
acceptability of your output to tools that don't fully meet the specs.
Also, if a common implementation generates something not quite to the
standard, try to make it so you can accept that output too.

3) Decide to be a perverse implementation and choose strange ((or
random) combinations for generation choices to come up with files to
stress test other implementations, and be totally picky about the input
format, reporting the slightest deviation from the spec.


The second option is the best to choose if you really want to make your
application as useful as possible (except as a stress test).

-- 
Richard Damon



From michael.stemper at gmail.com  Sun May 20 17:00:45 2018
From: michael.stemper at gmail.com (Michael F. Stemper)
Date: Sun, 20 May 2018 16:00:45 -0500
Subject: best way to remove leading zeros from a tuple like string
In-Reply-To: <189bca64-1c7e-459f-a8a2-59db0e1752f8@googlegroups.com>
References: <189bca64-1c7e-459f-a8a2-59db0e1752f8@googlegroups.com>
Message-ID: <pdsnm8$8vd$1@dont-email.me>

On 2018-05-20 14:54, bruceg113355 at gmail.com wrote:
> Lets say I have the following tuple like string.
>    (128, 020, 008, 255)
> 
> What is the best way to to remove leading zeroes and end up with the following.
>    (128, 20, 8, 255)        -- I do not care about spaces


I'd use a few regular expressions:

 >>> from re import sub
 >>> tuple = '(0128, 020, 008,012, 255)'
 >>> sub( " 0*", " ", tuple ) # leading zeroes following space(s)
'(0128, 20, 8,012, 255)'
 >>> sub( ",0*", ",", tuple ) # leading zeroes following comma
'(0128, 020, 008,12, 255)'
 >>> sub( "\(0*", "(", tuple ) # leading zeroes after opening parend
'(128, 020, 008,012, 255)'

Each step could be written as "tuple = sub( ..."

 >>> tuple = sub( " 0*", " ", tuple ) # following space(s)
 >>> tuple = sub( ",0*", ",", tuple ) # following comma
 >>> tuple = sub( "\(0*", "(", tuple ) # after opening parend
 >>> tuple
'(128, 20, 8,12, 255)'
 >>>


Or, if you like to make your code hard to read and maintain, you could
combine them all into a single expression:

 >>> sub( " 0*", " ", sub( ",0*", ",", sub( "\(0*", "(", tuple ) ) )
'(128, 20, 8,12, 255)'
 >>>

-- 
Michael F. Stemper
What happens if you play John Cage's "4'33" at a slower tempo?


From ben.usenet at bsb.me.uk  Sun May 20 17:19:10 2018
From: ben.usenet at bsb.me.uk (Ben Bacarisse)
Date: Sun, 20 May 2018 22:19:10 +0100
Subject: best way to remove leading zeros from a tuple like string
References: <189bca64-1c7e-459f-a8a2-59db0e1752f8@googlegroups.com>
Message-ID: <87d0xqkott.fsf@bsb.me.uk>

bruceg113355 at gmail.com writes:

> Lets say I have the following tuple like string.
>   (128, 020, 008, 255)
>
> What is the best way to to remove leading zeroes and end up with the following.
>   (128, 20, 8, 255)        -- I do not care about spaces

You could use a regexp:

  import re
  ...
  re.sub(r"(?<![0-9])0+(?=[0-9])", "", "(128, 020, 008, 255)")

I post this because I think it works (interesting corner cases are 10005
and 000), but I don't think, having done it, that it's the right way to
go.  It's a little too mysterious and fragile.

This may be better:

  re.sub(r"[0-9]+", lambda m: str(int(m.group(0))), "(128, 020, 008, 255)")

Obviously, name the function if you prefer (or if you use this in
several places) and compile the pattern if you do a lot of these matches.

-- 
Ben.


From bruceg113355 at gmail.com  Sun May 20 17:19:28 2018
From: bruceg113355 at gmail.com (bruceg113355 at gmail.com)
Date: Sun, 20 May 2018 14:19:28 -0700 (PDT)
Subject: best way to remove leading zeros from a tuple like string
In-Reply-To: <pdsnm8$8vd$1@dont-email.me>
References: <189bca64-1c7e-459f-a8a2-59db0e1752f8@googlegroups.com>
 <pdsnm8$8vd$1@dont-email.me>
Message-ID: <360b3420-92fa-4fb6-8d30-399f0cb26f3e@googlegroups.com>

On Sunday, May 20, 2018 at 5:01:08 PM UTC-4, Michael F. Stemper wrote:
> On 2018-05-20 14:54, bruceg113355 at gmail.com wrote:
> > Lets say I have the following tuple like string.
> >    (128, 020, 008, 255)
> > 
> > What is the best way to to remove leading zeroes and end up with the following.
> >    (128, 20, 8, 255)        -- I do not care about spaces
> 
> 
> I'd use a few regular expressions:
> 
>  >>> from re import sub
>  >>> tuple = '(0128, 020, 008,012, 255)'
>  >>> sub( " 0*", " ", tuple ) # leading zeroes following space(s)
> '(0128, 20, 8,012, 255)'
>  >>> sub( ",0*", ",", tuple ) # leading zeroes following comma
> '(0128, 020, 008,12, 255)'
>  >>> sub( "\(0*", "(", tuple ) # leading zeroes after opening parend
> '(128, 020, 008,012, 255)'
> 
> Each step could be written as "tuple = sub( ..."
> 
>  >>> tuple = sub( " 0*", " ", tuple ) # following space(s)
>  >>> tuple = sub( ",0*", ",", tuple ) # following comma
>  >>> tuple = sub( "\(0*", "(", tuple ) # after opening parend
>  >>> tuple
> '(128, 20, 8,12, 255)'
>  >>>
> 
> 
> Or, if you like to make your code hard to read and maintain, you could
> combine them all into a single expression:
> 
>  >>> sub( " 0*", " ", sub( ",0*", ",", sub( "\(0*", "(", tuple ) ) )
> '(128, 20, 8,12, 255)'
>  >>>
> 
> -- 
> Michael F. Stemper
> What happens if you play John Cage's "4'33" at a slower tempo?



I did not think about using regular expressions.
After your response, I looked into regular expressions and also found  Regex.Replace
After thinking about my question, I said why not use a replace statement.
This works for me: mytuplestring.replace("0","")

Thanks for a good starting point:)
Bruce


From tallpaul at gmail.com  Sun May 20 17:32:06 2018
From: tallpaul at gmail.com (Paul)
Date: Sun, 20 May 2018 17:32:06 -0400
Subject: best way to remove leading zeros from a tuple like string
In-Reply-To: <360b3420-92fa-4fb6-8d30-399f0cb26f3e@googlegroups.com>
References: <189bca64-1c7e-459f-a8a2-59db0e1752f8@googlegroups.com>
 <pdsnm8$8vd$1@dont-email.me>
 <360b3420-92fa-4fb6-8d30-399f0cb26f3e@googlegroups.com>
Message-ID: <CA+og5uoy08VUSEj6aM-BVmDx2MzO5_6oQ-fW0A6uQhvXy9UXPw@mail.gmail.com>

>
>
> This works for me: mytuplestring.replace("0","")
>
> Your regex will also eliminate  non-leading zeros.


From tallpaul at gmail.com  Sun May 20 17:54:21 2018
From: tallpaul at gmail.com (Paul)
Date: Sun, 20 May 2018 17:54:21 -0400
Subject: best way to remove leading zeros from a tuple like string
In-Reply-To: <CA+og5uodUMytqKp+T+JcL_NHZLPoPnzO8TS4ik8XgZNQe3jtYg@mail.gmail.com>
References: <189bca64-1c7e-459f-a8a2-59db0e1752f8@googlegroups.com>
 <pdsnm8$8vd$1@dont-email.me>
 <360b3420-92fa-4fb6-8d30-399f0cb26f3e@googlegroups.com>
 <CA+og5uoy08VUSEj6aM-BVmDx2MzO5_6oQ-fW0A6uQhvXy9UXPw@mail.gmail.com>
 <CA+og5uodUMytqKp+T+JcL_NHZLPoPnzO8TS4ik8XgZNQe3jtYg@mail.gmail.com>
Message-ID: <CA+og5uqymZ23w0GVE-ZuQL9Ha8nmcxEm++WnmU2tOpwc5pazqg@mail.gmail.com>

On Sun, May 20, 2018, 5:53 PM Paul <tallpaul at gmail.com> wrote:

> This works for me: mytuplestring.replace("0","")
>
>>
>>> Your regex will also eliminate  non-leading zeros.
>>
>>
> If you Google
>
> regex tester
>
> you will find several useful sites where you can test regexes.  Regex
> errors are very common, even after you have experience with them.
>


From bruceg113355 at gmail.com  Sun May 20 18:10:42 2018
From: bruceg113355 at gmail.com (bruceg113355 at gmail.com)
Date: Sun, 20 May 2018 15:10:42 -0700 (PDT)
Subject: best way to remove leading zeros from a tuple like string
In-Reply-To: <mailman.263.1526851940.2761.python-list@python.org>
References: <189bca64-1c7e-459f-a8a2-59db0e1752f8@googlegroups.com>
 <pdsnm8$8vd$1@dont-email.me>
 <360b3420-92fa-4fb6-8d30-399f0cb26f3e@googlegroups.com>
 <CA+og5uoy08VUSEj6aM-BVmDx2MzO5_6oQ-fW0A6uQhvXy9UXPw@mail.gmail.com>
 <mailman.263.1526851940.2761.python-list@python.org>
Message-ID: <9b95ff46-75ef-4b2d-8b43-f9e7c3e89427@googlegroups.com>

On Sunday, May 20, 2018 at 5:32:32 PM UTC-4, Paul wrote:
> >
> >
> > This works for me: mytuplestring.replace("0","")
> >
> > Your regex will also eliminate  non-leading zeros.


Your right, what was I thinking?


From mikhailwas at gmail.com  Sun May 20 18:28:51 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Mon, 21 May 2018 01:28:51 +0300
Subject: "Data blocks" syntax specification draft
Message-ID: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>

> >
> > Comments, suggestions are welcome.
> >
>
> One comment.
>
> I'm not interested in downloading a PDF. Can you rework your document
> to be in a more textual format like Markdown or reStructuredText?
> Since you're hosting on GitHub anyway, the rendering can be done
> automatically.
>
> ChrisA


What against PDF?
Anyway, I have reloaded files with most recent corrections in various formats:

PDF
https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf

TXT
https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.txt

HTML(direct preview link)
http://htmlpreview.github.io/?https://raw.githubusercontent.com/Mikhail22/Documents/master/data-blocks-v01.html


"Markdown" is too vague - there dozens of markdown styles and
also they include subsets of HTML. It is just plain text with tags -
it cannot represent syntax in civilized form (unless I embed images
for every source example - but then it is too inconvenient for editing).
Source examples on Github will force a crappy font and replace tabs.

I suggest you just view HTML or PDF - it looks better and if you need
source - just download TXT - it has tabs preserved at least.


From __peter__ at web.de  Sun May 20 18:39:29 2018
From: __peter__ at web.de (Peter Otten)
Date: Mon, 21 May 2018 00:39:29 +0200
Subject: best way to remove leading zeros from a tuple like string
References: <189bca64-1c7e-459f-a8a2-59db0e1752f8@googlegroups.com>
Message-ID: <pdstau$i4u$1@blaine.gmane.org>

bruceg113355 at gmail.com wrote:

> Lets say I have the following tuple like string.
>   (128, 020, 008, 255)
> 
> What is the best way to to remove leading zeroes and end up with the
> following.
>   (128, 20, 8, 255)        -- I do not care about spaces
> 
> This is the solution I came up with
>     s = "(128, 020, 008, 255)"
>     v = s.replace ("(", "")
>     v = v.replace (")", "")
>     vv = ",".join([str(int(i)) for i in v.split(",")])
>     final = "(" + vv + ")"

Two more:

>>> s = "(0000128, 020, 008, 255, -1203,01,-000, -0123)"

>>> str(tuple(map(int, s[1:-1].split(","))))
'(128, 20, 8, 255, -1203, 1, 0, -123)'

>>> re.sub(r"\b0+\B", "", s)
'(128, 20, 8, 255, -1203,1,-0, -123)'




From michael.stemper at gmail.com  Sun May 20 18:45:44 2018
From: michael.stemper at gmail.com (Michael F. Stemper)
Date: Sun, 20 May 2018 17:45:44 -0500
Subject: best way to remove leading zeros from a tuple like string
In-Reply-To: <87d0xqkott.fsf@bsb.me.uk>
References: <189bca64-1c7e-459f-a8a2-59db0e1752f8@googlegroups.com>
 <87d0xqkott.fsf@bsb.me.uk>
Message-ID: <pdstr1$f2r$1@dont-email.me>

On 2018-05-20 16:19, Ben Bacarisse wrote:
> bruceg113355 at gmail.com writes:
> 
>> Lets say I have the following tuple like string.
>>    (128, 020, 008, 255)
>>
>> What is the best way to to remove leading zeroes and end up with the following.
>>    (128, 20, 8, 255)        -- I do not care about spaces
> 
> You could use a regexp:
> 
>    import re
>    ...
>    re.sub(r"(?<![0-9])0+(?=[0-9])", "", "(128, 020, 008, 255)")
> 
> I post this because I think it works (interesting corner cases are 10005
> and 000), 

Seeing this makes me realize that mine will eliminate any numbers that
are all leading zero, including '0'. Also, forms like '-0042' will be
left unchanged.

Maybe splitting it into integer forms and sending each through
str( int( ) ) would be the safest. This partly does the trick, but
packing the results back into a string that resembles a tuple has
been left as a short exercise for the student:

 >>> tuple = '(0128, 020, 000, 008, -0042,255)'
 >>> fields = tuple[1:len(tuple)-1].split(",")
 >>> for field in fields:
...   print( str(int(field)) )
...
128
20
0
8
-42
255
 >>>


-- 
Michael F. Stemper
Why doesn't anybody care about apathy?


From ben.usenet at bsb.me.uk  Sun May 20 18:55:53 2018
From: ben.usenet at bsb.me.uk (Ben Bacarisse)
Date: Sun, 20 May 2018 23:55:53 +0100
Subject: best way to remove leading zeros from a tuple like string
References: <189bca64-1c7e-459f-a8a2-59db0e1752f8@googlegroups.com>
 <87d0xqkott.fsf@bsb.me.uk> <pdstr1$f2r$1@dont-email.me>
Message-ID: <877enykkcm.fsf@bsb.me.uk>

"Michael F. Stemper" <michael.stemper at gmail.com> writes:

> On 2018-05-20 16:19, Ben Bacarisse wrote:
>> bruceg113355 at gmail.com writes:
>>
>>> Lets say I have the following tuple like string.
>>>    (128, 020, 008, 255)
>>>
>>> What is the best way to to remove leading zeroes and end up with the following.
>>>    (128, 20, 8, 255)        -- I do not care about spaces
>>
>> You could use a regexp:
>>
>>    import re
>>    ...
>>    re.sub(r"(?<![0-9])0+(?=[0-9])", "", "(128, 020, 008, 255)")
>>
>> I post this because I think it works (interesting corner cases are 10005
>> and 000), 
>
> Seeing this makes me realize that mine will eliminate any numbers that
> are all leading zero, including '0'. Also, forms like '-0042' will be
> left unchanged.

I realised after posting the negatives won't work.  Not, I suspect, an
issue for the OP but -0042 can certainly be said to have "leading
zeros".

> Maybe splitting it into integer forms and sending each through
> str( int( ) ) would be the safest.

Yup.  I gave a version of that method too which handles negative numbers
by accident (by leaving the - in place!).  A better version would be

  re.sub(r"-?[0-9]+", lambda m: str(int(m.group(0))), s)

<snip>
-- 
Ben.


From bruceg113355 at gmail.com  Sun May 20 19:16:48 2018
From: bruceg113355 at gmail.com (bruceg113355 at gmail.com)
Date: Sun, 20 May 2018 16:16:48 -0700 (PDT)
Subject: best way to remove leading zeros from a tuple like string
In-Reply-To: <877enykkcm.fsf@bsb.me.uk>
References: <189bca64-1c7e-459f-a8a2-59db0e1752f8@googlegroups.com>
 <87d0xqkott.fsf@bsb.me.uk> <pdstr1$f2r$1@dont-email.me>
 <877enykkcm.fsf@bsb.me.uk>
Message-ID: <8b551692-c4e5-4577-9786-650fc5f520fd@googlegroups.com>

On Sunday, May 20, 2018 at 6:56:05 PM UTC-4, Ben Bacarisse wrote:
> "Michael F. Stemper" <michael.stemper at gmail.com> writes:
> 
> > On 2018-05-20 16:19, Ben Bacarisse wrote:
> >> bruceg113355 at gmail.com writes:
> >>
> >>> Lets say I have the following tuple like string.
> >>>    (128, 020, 008, 255)
> >>>
> >>> What is the best way to to remove leading zeroes and end up with the following.
> >>>    (128, 20, 8, 255)        -- I do not care about spaces
> >>
> >> You could use a regexp:
> >>
> >>    import re
> >>    ...
> >>    re.sub(r"(?<![0-9])0+(?=[0-9])", "", "(128, 020, 008, 255)")
> >>
> >> I post this because I think it works (interesting corner cases are 10005
> >> and 000), 
> >
> > Seeing this makes me realize that mine will eliminate any numbers that
> > are all leading zero, including '0'. Also, forms like '-0042' will be
> > left unchanged.
> 
> I realised after posting the negatives won't work.  Not, I suspect, an
> issue for the OP but -0042 can certainly be said to have "leading
> zeros".
> 
> > Maybe splitting it into integer forms and sending each through
> > str( int( ) ) would be the safest.
> 
> Yup.  I gave a version of that method too which handles negative numbers
> by accident (by leaving the - in place!).  A better version would be
> 
>   re.sub(r"-?[0-9]+", lambda m: str(int(m.group(0))), s)
> 
> <snip>
> -- 
> Ben.



Looking over the responses, I modified my original code as follows:

>>> s = "(0000128, 020, 008, 255, -1203,01,-000, -0123)" 
>>> ",".join([str(int(i)) for i in s[1:-1].split(",")])
'128,20,8,255,-1203,1,0,-123'


If I decide I need the parentheses, this works.

>>> "(" + ",".join([str(int(i)) for i in s[1:-1].split(",")]) + ")"
'(128,20,8,255,-1203,1,0,-123)'

Thanks,
Bruce



From ian.g.kelly at gmail.com  Sun May 20 20:02:21 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Sun, 20 May 2018 18:02:21 -0600
Subject: "Data blocks" syntax specification draft
In-Reply-To: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
Message-ID: <CALwzid=oQoLHqBDVyqwys1CpmAPdkPaTPuy1dy=zSc_HyRYrEQ@mail.gmail.com>

On Sun, May 20, 2018 at 4:28 PM, Mikhail V <mikhailwas at gmail.com> wrote:
> "Markdown" is too vague - there dozens of markdown styles and
> also they include subsets of HTML. It is just plain text with tags

The whole point of Markdown is that it's readable as plain text
precisely because it *doesn't* use obvious tags like HTML.

> it cannot represent syntax in civilized form (unless I embed images
> for every source example - but then it is too inconvenient for editing).

Why would you need images to represent syntax? What's wrong with code blocks?

> Source examples on Github will force a crappy font and replace tabs.

Has it occurred to you that this will also be a problem for anybody
else trying to create examples using this syntax on Github?

> I suggest you just view HTML or PDF - it looks better and if you need
> source - just download TXT - it has tabs preserved at least.

You know, if you're serious about this proposal, then eventually you
will have to write a PEP for it. And that PEP has a required style and
format. And that format is reStructuredText.


From wolfram.hinderer at googlemail.com  Sun May 20 20:09:26 2018
From: wolfram.hinderer at googlemail.com (Wolfram Hinderer)
Date: Mon, 21 May 2018 02:09:26 +0200
Subject: best way to remove leading zeros from a tuple like string
In-Reply-To: <8b551692-c4e5-4577-9786-650fc5f520fd@googlegroups.com>
References: <189bca64-1c7e-459f-a8a2-59db0e1752f8@googlegroups.com>
 <87d0xqkott.fsf@bsb.me.uk> <pdstr1$f2r$1@dont-email.me>
 <877enykkcm.fsf@bsb.me.uk>
 <8b551692-c4e5-4577-9786-650fc5f520fd@googlegroups.com>
Message-ID: <bef26331-f31c-f041-2759-10e636c4551b@googlemail.com>

Am 21.05.2018 um 01:16 schrieb bruceg113355 at gmail.com:
> If I decide I need the parentheses, this works.
>
>>>> "(" + ",".join([str(int(i)) for i in s[1:-1].split(",")]) + ")"
> '(128,20,8,255,-1203,1,0,-123)'
>
> Thanks,
> Bruce

Creating the tuple seems to be even simpler.

 >>> str(tuple(map(int, s[1:-1].split(","))))
'(128, 20, 8, 255, -1203, 1, 0, -123)'

Wolfram


From rosuav at gmail.com  Sun May 20 22:20:51 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Mon, 21 May 2018 12:20:51 +1000
Subject: "Data blocks" syntax specification draft
In-Reply-To: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
Message-ID: <CAPTjJmoOQV_pz+SAJjXk53qYTfDMoC7EO-VoyE_EaihGPHz_oA@mail.gmail.com>

On Mon, May 21, 2018 at 8:28 AM, Mikhail V <mikhailwas at gmail.com> wrote:
>> >
>> > Comments, suggestions are welcome.
>> >
>>
>> One comment.
>>
>> I'm not interested in downloading a PDF. Can you rework your document
>> to be in a more textual format like Markdown or reStructuredText?
>> Since you're hosting on GitHub anyway, the rendering can be done
>> automatically.
>>
>> ChrisA
>
>
> What against PDF?
> Anyway, I have reloaded files with most recent corrections in various formats:

The very best way to put your proposal is right here in the body of
the email, as plain Unicode (and primarily ASCII) text, no images, no
external links, no side dependencies.

The second best way is to have a simple link that anyone can click on
to read your proposal. It's an external dependency, but you're
depending on a web browser and a basic internet connection, and
nothing more.

Forcing us to download a PDF and then read it? Well, it's your
decision. My decision is that I cannot be bothered going to THAT much
effort to figure out what you're saying. The PDF link you give is not
viewable on the web, and the text file looks like source code for your
PDF, but isn't very readable either.

As Ian says, reStructuredText is the only supported format [1] for
PEPs, so you may as well just start using it straight away. GitHub
automatically renders it if you use a ".rst" extension on your file,
so the rendered form would be visible on the web. Consider:

https://github.com/python/peps/blob/master/pep-0562.rst

I'm not going to read your proposal if you force me to go to heaps of
effort for it. The onus is on YOU to gather support, not on everyone
else to refute it, so it's up to you to publish it accessibly.

ChrisA

[1] Technically plain text is also supported, but not for new PEPs.


From sujith.sjk at gmail.com  Sun May 20 22:29:34 2018
From: sujith.sjk at gmail.com (sujith.j Sjk)
Date: Mon, 21 May 2018 07:59:34 +0530
Subject: Issue
In-Reply-To: <CAOpC7vMGsexgb3Qk5GWyUnP9MTKkKJBtx+ADLJ7U-WW_jkn_-w@mail.gmail.com>
References: <CAOpC7vMGsexgb3Qk5GWyUnP9MTKkKJBtx+ADLJ7U-WW_jkn_-w@mail.gmail.com>
Message-ID: <CAOpC7vPdz7J5tywt9oHWVgNTnmJi=hnSL716LVfSsSoG2JiFKg@mail.gmail.com>

> Hi,
>
> Am facing the below issue when starting pyton.
>
>
>


From torriem at gmail.com  Sun May 20 22:39:44 2018
From: torriem at gmail.com (Michael Torrie)
Date: Sun, 20 May 2018 20:39:44 -0600
Subject: Poor corporate communication culture - was Re: syntax oddities
In-Reply-To: <CACac1F-vHtFt_rzELBpxffJrSmZiFv47ftJEz2fVf0nWufo18g@mail.gmail.com>
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org> <2d0sfdh2h3ki49koh2s667os2ug9tvp6e4@4ax.com>
 <CA+og5uq9_HBHPyacq5EHtM4qvrBWMKRrWOSq8cXt+jsLz4xATw@mail.gmail.com>
 <be6291dd-968c-fe23-d8ff-d73f57d16513@kynesim.co.uk>
 <CACac1F-vHtFt_rzELBpxffJrSmZiFv47ftJEz2fVf0nWufo18g@mail.gmail.com>
Message-ID: <5a753de7-0d41-f1d2-f9b7-4f53afac56a2@gmail.com>

On 05/18/2018 06:25 AM, Paul Moore wrote:
> There are two completely independent cultures here. In "Corporate"
> cultures like where I work (where IT and business functions interact a
> lot, and business users typically use tools like Outlook) top-posting
> is common, conventional, and frankly, effective. 

I beg to differ with you.  I find communication in corporate culture to
be horrible and generally ineffective.  Many times I've written an email
and got a terse, top-posted reply that didn't address my question or
point at all, requiring several emails to finally get the point across.
If the other person had simply trimmed my post to quote my question, and
then replied below it, he'd have got it right the first time, as he'd
have to actually read what I wrote while doing this.  I know I
comprehend much better when I selectively quote.

Nine times out of ten, a top posted reply from a manager is a sure sign
he hasn't bothered to read anything of what I actually wrote. Instead he
just answers the question he thought I asked.

You must work for corporations that are pretty amazing compared to the
average American one.


From mikhailwas at gmail.com  Sun May 20 23:32:55 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Mon, 21 May 2018 06:32:55 +0300
Subject: "Data blocks" syntax specification draft
In-Reply-To: <CALwzid=oQoLHqBDVyqwys1CpmAPdkPaTPuy1dy=zSc_HyRYrEQ@mail.gmail.com>
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
 <CALwzid=oQoLHqBDVyqwys1CpmAPdkPaTPuy1dy=zSc_HyRYrEQ@mail.gmail.com>
Message-ID: <CAE6NSRDNvRpnZ+trS3rpHPYREeK51x8DnR9JoiqtL9Zc2xJLnA@mail.gmail.com>

On Mon, May 21, 2018 at 3:02 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Sun, May 20, 2018 at 4:28 PM, Mikhail V <mikhailwas at gmail.com> wrote:
>> "Markdown" is too vague - there dozens of markdown styles and
>> also they include subsets of HTML. It is just plain text with tags
>
> The whole point of Markdown is that it's readable as plain text
> precisely because it *doesn't* use obvious tags like HTML.
>
>> it cannot represent syntax in civilized form (unless I embed images
>> for every source example - but then it is too inconvenient for editing).
>
> Why would you need images to represent syntax? What's wrong with code blocks?

Code blocks where? In what software/webkit it is supposed to be
rendered?
How do you imagine a serious proposal with such syntax comparisons
without ability to make more or less precise presentation in various
fonts?
To speak about significant syntax change seriously you need many samples
in at least 2-3 modern quality fonts. Modulo a pair of reasonable color schemes.
Modern editors (and users) are far beyond type-writer fonts.

>> I suggest you just view HTML or PDF - it looks better and if you need
>> source - just download TXT - it has tabs preserved at least.
>
> You know, if you're serious about this proposal, then eventually you
> will have to write a PEP for it. And that PEP has a required style and
> format. And that format is reStructuredText.

Making reStructuredText is not a problem, but as said - it is not
serious to speak of syntax without good samples. IOW besides a
Markdown PEP such proposal requires a lot of supplementary material.
The best method is to create images of code snippets in addition to
text. Main advantage of images that it will be independent of browser/OS
but it requires some extra job.


From mikhailwas at gmail.com  Mon May 21 00:00:05 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Mon, 21 May 2018 07:00:05 +0300
Subject: "Data blocks" syntax specification draft
In-Reply-To: <CAPTjJmoOQV_pz+SAJjXk53qYTfDMoC7EO-VoyE_EaihGPHz_oA@mail.gmail.com>
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
 <CAPTjJmoOQV_pz+SAJjXk53qYTfDMoC7EO-VoyE_EaihGPHz_oA@mail.gmail.com>
Message-ID: <CAE6NSRCwdJy_7tMn=OnSDqwqkCDZSMKRnnP6TC6TSou0sEf5ug@mail.gmail.com>

On Mon, May 21, 2018 at 5:20 AM, Chris Angelico <rosuav at gmail.com> wrote:
> On Mon, May 21, 2018 at 8:28 AM, Mikhail V <mikhailwas at gmail.com> wrote:
>>> >
>>> > Comments, suggestions are welcome.
>>> >
>>>
>>> One comment.
>>>
>>> I'm not interested in downloading a PDF. Can you rework your document
>>> to be in a more textual format like Markdown or reStructuredText?
>>> Since you're hosting on GitHub anyway, the rendering can be done
>>> automatically.
>>>
>>> ChrisA
>>
>>
>> What against PDF?
>> Anyway, I have reloaded files with most recent corrections in various formats:
>
> The very best way to put your proposal is right here in the body of
> the email, as plain Unicode (and primarily ASCII) text, no images, no
> external links, no side dependencies.

Well that's the easiest way for me, but - if the document changes constantly
then it is more convenient to have a web link for a document.

> The second best way is to have a simple link that anyone can click on
> to read your proposal. It's an external dependency, but you're
> depending on a web browser and a basic internet connection, and
> nothing more.
>
> Forcing us to download a PDF and then read it? Well, it's your
> decision. My decision is that I cannot be bothered going to THAT much
> effort to figure out what you're saying.

THAT much effort to click two times instead of one - and get a
formatted document instead of plain bw text. o-kaay..

> The PDF link you give is not viewable on the web

Dunno, works for me - I click it and see immediately my PDF in
the browser. But I (and many people) prefer to download anyway.
Also I provided a link to HTML - also works per click and looks even
better than PDF.

> As Ian says, reStructuredText is the only supported format [1] for
> PEPs, so you may as well just start using it straight away. GitHub
> automatically renders it if you use a ".rst" extension on your file,
> so the rendered form would be visible on the web.

Ok. How is about images? this proposal will require a lot of images
- otherwise people who read it are forced to copy-paste snippets
into their code editors to understand how it may look in reality.

> I'm not going to read your proposal if you force me to go to heaps of
> effort for it.

heaps! oh come on, youre making up again.


From rosuav at gmail.com  Mon May 21 00:05:41 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Mon, 21 May 2018 14:05:41 +1000
Subject: "Data blocks" syntax specification draft
In-Reply-To: <CAE6NSRCwdJy_7tMn=OnSDqwqkCDZSMKRnnP6TC6TSou0sEf5ug@mail.gmail.com>
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
 <CAPTjJmoOQV_pz+SAJjXk53qYTfDMoC7EO-VoyE_EaihGPHz_oA@mail.gmail.com>
 <CAE6NSRCwdJy_7tMn=OnSDqwqkCDZSMKRnnP6TC6TSou0sEf5ug@mail.gmail.com>
Message-ID: <CAPTjJmr2BPY2MRD=Vy+xiMj2-dbZZyiWfj_=ete7NcLVGMhzKg@mail.gmail.com>

On Mon, May 21, 2018 at 2:00 PM, Mikhail V <mikhailwas at gmail.com> wrote:
>> The second best way is to have a simple link that anyone can click on
>> to read your proposal. It's an external dependency, but you're
>> depending on a web browser and a basic internet connection, and
>> nothing more.
>>
>> Forcing us to download a PDF and then read it? Well, it's your
>> decision. My decision is that I cannot be bothered going to THAT much
>> effort to figure out what you're saying.
>
> THAT much effort to click two times instead of one - and get a
> formatted document instead of plain bw text. o-kaay..

Two clicks? No, that isn't how it happened for me. I clicked on it and
then I couldn't see the content. What second click am I supposed to do
that shows me the page?

>> As Ian says, reStructuredText is the only supported format [1] for
>> PEPs, so you may as well just start using it straight away. GitHub
>> automatically renders it if you use a ".rst" extension on your file,
>> so the rendered form would be visible on the web.
>
> Ok. How is about images? this proposal will require a lot of images
> - otherwise people who read it are forced to copy-paste snippets
> into their code editors to understand how it may look in reality.

If you're proposing syntax for Python, it's ultimately going to have
to be text. You cannot say "and every text editor has to render it
like this". If you can't demonstrate it using plain text, you have a
major problem on your hands.

>> I'm not going to read your proposal if you force me to go to heaps of
>> effort for it.
>
> heaps! oh come on, youre making up again.

No, I'm not making it up. Just because the PDF works perfectly for
you, you assume that it'll work perfectly for everyone. That is not
the case, and that isn't my problem - it's your problem.

Suppose someone posted a Microsoft Word document, claiming that
Internet Explorer will display it perfectly. Would you accept that,
and say that we should all switch to IE? Would you moan that it's so
easy, and we're just complainers for not wanting to play your games?
Or would we just drop the thread and ignore you thereafter?

I'm not going to debate this with you. If you want people to read your
content, you need to make it accessible; it's much easier for me to
just assume that a proposal that requires a PDF and a bunch of images
simply isn't worth reading.

ChrisA


From dieter at handshake.de  Mon May 21 03:11:02 2018
From: dieter at handshake.de (dieter)
Date: Mon, 21 May 2018 09:11:02 +0200
Subject: decorat{or,ion}
References: <mailman.30.1526659203.31214.python-list@python.org>
 <20180519013116.GA16615@playground> <87in7kmaf0.fsf@handshake.de>
 <20180520010746.GA6699@playground>
Message-ID: <87in7hscu1.fsf@handshake.de>

Mike McClain <mike.junk.46 at att.net> writes:
> ...
>         Thanks for the response, this is still a foreign language to me and I need all
>     the help I can get. I'm reading the docs, doing the tutorial again but still have
>     more questions than answers.
>         If I understand what you said, 'taint necessarily so, I'll restate it in psuedo
>     code since I've little feel for python syntax yet.
>
>     Let's forget buz().
>
>     def bar(*args):
>         (a,b,rest) = parseArgs(args)
>         def baz(x):
>             ...
>         def bug(k,l,m):
>             ...
>         bug(foo(a), baz(b), rest)
>
>     In 'def bar()', baz & bug are simply functions.

Indeed.

>     Are they accessable outside bar?

No, unless they are explicitly passed out by "bar" (usually either as
function result or part thereof; but there are other ways as well).


>     class bar(*args):
>         (a,b,rest) = parseArgs(args)

I do not think that this would work.

While the "class" statement (defining a class)
has some similarity with the "def" statement (defining a function),
there are also differences.

In particular, the arguments in "class C(<arguments>)"
correspond to arguments passed to a function call, not the arguments
of a function definition. As one consequence, they are not made
visible in the class' namespace: your "parseArgs(args)" above
will not work (likely, you will already get an error before that point.

As a side note:
Associated with a class definition is a so called "metaclass"
(the association is usually implicit, but can be made explicit).
The arguments in "class C(<arguments>)" are passed as
one of the parameters in a metaclass call (other parameters are
the class name and the class dict). Thus, the "class" statement
effectively leads to a (function/method) call with the somewhat
prepared content of the class statement as parameters.

>         def baz(x):
>             ...
>         ...
>
>     In 'class bar()' I understand baz and bug should be named _baz_ , _bug_,
>     if they're not expected to be called from outside bar but there's nothing
>     to prevent one from doing so except manners.

It is a tacit convention that names starting with a "_" are in
various ways special:

        __...__: are usually used for Python internal purposes and
          often treated very differently from other attributes.

          Usually, you should avoid to define such attributes
          yourself, unless you want to customize the
          associated Python behaviour.
          Otherwise, future Python versions might give a special
          meaning to your attribute and it may then no longer
          work as in previous Python versions.

        __...: those attributes are mangled inside a class statement:
          the mangling consists of prepending "_<class name>".

          The purpose of this feature is to avoid name clashes
          in class inheritance. "__..." attribute are in some
          way "private" to the class (as far as the mangling
          ensures this), not (easily) seen be deriving classes.

       _...: provides a hint that this attribute/name is ment more for
          "local" rather then "public" use.

          There is nothing in Python that enforces this.


>     Also they're now methods while
>     still being functions and had to be declared 'def baz(self,x):'.

The precise details are as follows:

  The "def" always defines a function (whether or not it appears
  inside or outside of a "class" statement).

  If used inside a "class" statement, the function is put into
  the dictionary associated with the constructed class.

  If an attribute of a class or class instance is looked up
  in the "normal" way" (i.e. "<obj>.<attr>") and
  the result happens to be a function, then the function
  is not returned directly but wrapped into a method wrapper
  (containing both "<obj>" and the function).
  This means that the function is turned into a method
  during its access (not during its definition).

Usually, you access the functions in a "class" definition in the "normal
way" - and the result will behave as a method. Thus, you
can view (for simplicity) the corresponding definitions as method definitions
-- even though the transformation into a method only happens
on access to (and not on definition of) the function.


>     Feel free to laugh if what I'm saying is nonsense in python.

Do not be worried.

>         If I execute 'bar.baz(mu)',

As mentioned above, your example will not work. Let's modify
a bit:

  class C:
    def baz(self, b):
      ...

  c = C()

If you use "C.baz", the result is in Python 2
a so called "unbound method":
it contains the class "C" and the function "baz".
If you want to call an "unbound method", you must
pass in all function arguments, including the first one. The call
will raise a "TypeError", when the first argument is not an instance
of the associated class.
In Python 3, "C.baz" returns the function "baz".

If you use "c.baz", the result is a so called "bound method":
it contains the object "c" and the function "baz".
If you call a "bound method", the associated object
is passed autemoatically as first parameter to the function; you
specify only the remaining arguments in the call.

>     assuming mu is enough like b above for
>     baz not to throw an exception, can I expect the action of baz to change in a
>     manner similar to the change in parameters? Or does something in self prevent that?

I do not understand your question and expectations.

Hopefully, my explanation above will already clarify
Python's treatment of functions versus methods sufficiently,
that you can understand what is happening or at least that
you can reformulate your question.


As a side note: you can fairly safely play with Python
in an interactive way - and thus learn much about Python internals.

Below is a transcript for the exploration of the function/method
handling discussed in the message:

lsdm: python3
Python 3.5.2 (default, Nov 23 2017, 16:37:01) 
[GCC 5.4.0 20160609] on linux
>>> class C:
...   def baz(self, b): print(b)
... 
>>> c = C()
>>> C.baz
<function C.baz at 0xb712c7c4>
>>> C.baz(1,2)
2
>>> c.baz
<bound method C.baz of <__main__.C object at 0xb70311ac>>
>>> c.baz(2)
2
# provide information about the method's attributes
>>> dir(c.baz)
['__call__', '__class__', '__delattr__', '__dir__', '__doc__', '__eq__', '__format__', '__func__', '__ge__', '__get__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__self__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__']
# "<method>.__self__" contains the associated object
>>> c.baz.__self__ is c
True
# "<method>.__func__" contains the associated function
>>> c.baz.__func__ is C.baz
True



From dieter at handshake.de  Mon May 21 03:21:29 2018
From: dieter at handshake.de (dieter)
Date: Mon, 21 May 2018 09:21:29 +0200
Subject: Python 3.6 causes error, python 3.5 does not.
References: <pdsgmd$vfo$1@blaine.gmane.org>
Message-ID: <87efi5sccm.fsf@handshake.de>

Jim <jf_byrnes at comcast.net> writes:
> ...
> The problem is it runs fine if I use python 3.5. If I use python 3.6
> it opens the calc file then pops up a dialog saying
> "std::bad_alloc".

This looks like a C++ error message -- maybe from "calc".

It also looks quite severe (some memory allocation problem).
Therefore, it does not look likely that we can help you via this list.
I would use a C/C++ level debugger, to find out whether the message
come from the Python side (quite unlikely in my opinion) or from
"libreoffice".



From __peter__ at web.de  Mon May 21 03:26:51 2018
From: __peter__ at web.de (Peter Otten)
Date: Mon, 21 May 2018 09:26:51 +0200
Subject: best way to remove leading zeros from a tuple like string
References: <189bca64-1c7e-459f-a8a2-59db0e1752f8@googlegroups.com>
 <87d0xqkott.fsf@bsb.me.uk> <pdstr1$f2r$1@dont-email.me>
 <877enykkcm.fsf@bsb.me.uk>
 <8b551692-c4e5-4577-9786-650fc5f520fd@googlegroups.com>
Message-ID: <pdts8s$854$1@blaine.gmane.org>

bruceg113355 at gmail.com wrote:

> Looking over the responses, I modified my original code as follows:
> 
>>>> s = "(0000128, 020, 008, 255, -1203,01,-000, -0123)"
>>>> ",".join([str(int(i)) for i in s[1:-1].split(",")])
> '128,20,8,255,-1203,1,0,-123'

I think this looks better with a generator instead of the listcomp:

>>> ",".join(str(int(i)) for i in s[1:-1].split(","))
'128,20,8,255,-1203,1,0,-123'




From mvoicem at gmail.com  Mon May 21 04:00:41 2018
From: mvoicem at gmail.com (m)
Date: Mon, 21 May 2018 10:00:41 +0200
Subject: Spam levels.
In-Reply-To: <4sd3le-ct4.ln1@tanner.seckford.org>
References: <4sd3le-ct4.ln1@tanner.seckford.org>
Message-ID: <5b027ca9$0$619$65785112@news.neostrada.pl>

W dniu 10.02.2018 o?15:57, C W Rose pisze:
> No other groups (in the limited set which I read) have the problem,
> and I don't understand why the spammers neither spam a range of
> groups, nor change their adddresses more frequently.  It may be
> that destroying comp.lang.python is their actual objective.
> 
> Either way, a depressing state of affairs.

The sad thing is, that your post is unseen, because of spam :S

I also almost stopped reading c.l.python, because of enormous spam
levels. Do I have any option to read it without spam, other than launch
my own filtering NNTP server and do whack the mole game for myself?

Maybe join forces and establish such server for public use?

p. m.


From mvoicem at gmail.com  Mon May 21 04:21:09 2018
From: mvoicem at gmail.com (m)
Date: Mon, 21 May 2018 10:21:09 +0200
Subject: "Data blocks" syntax specification draft
In-Reply-To: <mailman.273.1526875659.2761.python-list@python.org>
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
 <CAPTjJmoOQV_pz+SAJjXk53qYTfDMoC7EO-VoyE_EaihGPHz_oA@mail.gmail.com>
 <CAE6NSRCwdJy_7tMn=OnSDqwqkCDZSMKRnnP6TC6TSou0sEf5ug@mail.gmail.com>
 <mailman.273.1526875659.2761.python-list@python.org>
Message-ID: <5b028176$0$674$65785112@news.neostrada.pl>

W dniu 21.05.2018 o?06:00, Mikhail V pisze:
>> As Ian says, reStructuredText is the only supported format [1] for
>> PEPs, so you may as well just start using it straight away. GitHub
>> automatically renders it if you use a ".rst" extension on your file,
>> so the rendered form would be visible on the web.
> Ok. How is about images? this proposal will require a lot of images
> - otherwise people who read it are forced to copy-paste snippets
> into their code editors to understand how it may look in reality.
> 

I would say, that if proposition of your syntax requires images, then
it's bad syntax.

And re PDF - i opened that pdf with one click - hopefully I have
configured my thunderbird to that. And what do I see? Completely
unreadable code, because you used bizzare, non monospaced,  font to code
examples.

p. m.


From steve+comp.lang.python at pearwood.info  Mon May 21 05:21:09 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Mon, 21 May 2018 09:21:09 +0000 (UTC)
Subject: "Data blocks" syntax specification draft
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
Message-ID: <pdu324$l8j$1@blaine.gmane.org>

On Mon, 21 May 2018 01:28:51 +0300, Mikhail V wrote:

> Source examples on
> Github will force a crappy font and replace tabs.


Is that supposed to convince us that using mandatory TABs is a good idea?


-- 
Steve



From steve+comp.lang.python at pearwood.info  Mon May 21 05:22:33 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Mon, 21 May 2018 09:22:33 +0000 (UTC)
Subject: Poor corporate communication culture - was Re: syntax oddities
References: <pdfbad$5sq$1@gioia.aioe.org>
 <CADrxXXnZK-uW9Cciv87R+nFXR80ixV7CB=oF_QPycnW-hjFG5g@mail.gmail.com>
 <pditoa$fka$4@blaine.gmane.org>
 <CADrxXXmHRgDwU4OxF6cuh5=ooabfSnTj-Hay6LYVxedF8=cGRw@mail.gmail.com>
 <pdk04n$r9v$1@blaine.gmane.org>
 <mailman.144.1526563942.2761.python-list@python.org>
 <pdk2vn$1ukl$1@gioia.aioe.org> <2d0sfdh2h3ki49koh2s667os2ug9tvp6e4@4ax.com>
 <CA+og5uq9_HBHPyacq5EHtM4qvrBWMKRrWOSq8cXt+jsLz4xATw@mail.gmail.com>
 <be6291dd-968c-fe23-d8ff-d73f57d16513@kynesim.co.uk>
 <CACac1F-vHtFt_rzELBpxffJrSmZiFv47ftJEz2fVf0nWufo18g@mail.gmail.com>
 <5a753de7-0d41-f1d2-f9b7-4f53afac56a2@gmail.com>
Message-ID: <pdu34p$l8j$2@blaine.gmane.org>

On Sun, 20 May 2018 20:39:44 -0600, Michael Torrie wrote:

> Nine times out of ten, a top posted reply from a manager is a sure sign
> he hasn't bothered to read anything of what I actually wrote. Instead he
> just answers the question he thought I asked.

And the other one time out of ten, he's only read the first sentence.

Only half kidding.




-- 
Steve



From chris at open-cosmos.com  Mon May 21 06:41:23 2018
From: chris at open-cosmos.com (Chris Lindsay)
Date: Mon, 21 May 2018 11:41:23 +0100
Subject: "Data blocks" syntax specification draft
In-Reply-To: <pdu324$l8j$1@blaine.gmane.org>
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
 <pdu324$l8j$1@blaine.gmane.org>
Message-ID: <CAHiMU6cGz=X4LMcYac=_Us0+9ATPTrJPLZaeXmK07KbnNFSP2A@mail.gmail.com>

So this is a syntax for defining large blocks of static data in-line with
code.

If a block of static data is large enough to start to be ugly, a common
approach is to load the data from some other file, in a language which is
designed around structured data. YAML comes to mind - it has minimal
punctuation, and whitespace as syntax, with little in the way of syntax
ambiguity since it isn't already a scripting language.

What use-case do you foresee for your proposed new format, that isn't
already (better) accomplished by using a separate structured
data/serialisation language?

On 21 May 2018 at 10:21, Steven D'Aprano <
steve+comp.lang.python at pearwood.info> wrote:

> On Mon, 21 May 2018 01:28:51 +0300, Mikhail V wrote:
>
> > Source examples on
> > Github will force a crappy font and replace tabs.
>
>
> Is that supposed to convince us that using mandatory TABs is a good idea?
>
>
> --
> Steve
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
Chris
Open Cosmos

Any opinions given above are my own.


From ned at nedbatchelder.com  Mon May 21 07:14:52 2018
From: ned at nedbatchelder.com (Ned Batchelder)
Date: Mon, 21 May 2018 07:14:52 -0400
Subject: "Data blocks" syntax specification draft
In-Reply-To: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
Message-ID: <e2764d57-1534-8819-84c6-658ddc05b38a@nedbatchelder.com>

On 5/19/18 10:58 PM, Mikhail V wrote:
> I have made up a printable PDF with the current version
> of the syntax suggestion.
>
> https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf
>
> After some of your comments I've made some further
> re-considerations, e.g. element separation should
> be now much simpler.
> A lot of examples with comparison included.
>
>
> Comments, suggestions are welcome.
>

Mikhail, you have a completely different esthetic for syntax than the 
rest of the Python world.? Your proposal seems to have almost nothing in 
common with existing Python syntax.? Your approach to whitespace is 
different. You've ignored existing words (tuple, str) in favor of new 
shorthands (t, s).? You use semicolon and asterisk for something new.? 
Parentheses enclosing strings!?

This is never going to be adopted as Python syntax. It's too different.

That's fine: make a new file format.? Write a library that can read and 
write this format.? Propose it to people, and get them using it.? We 
have xml, ini, json, yaml, and toml.? Now we can also have data blocks.

--Ned.


From bc at freeuk.com  Mon May 21 08:33:22 2018
From: bc at freeuk.com (bartc)
Date: Mon, 21 May 2018 13:33:22 +0100
Subject: "Data blocks" syntax specification draft
In-Reply-To: <mailman.272.1526875544.2761.python-list@python.org>
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
 <CAPTjJmoOQV_pz+SAJjXk53qYTfDMoC7EO-VoyE_EaihGPHz_oA@mail.gmail.com>
 <CAE6NSRCwdJy_7tMn=OnSDqwqkCDZSMKRnnP6TC6TSou0sEf5ug@mail.gmail.com>
 <CAPTjJmr2BPY2MRD=Vy+xiMj2-dbZZyiWfj_=ete7NcLVGMhzKg@mail.gmail.com>
 <mailman.272.1526875544.2761.python-list@python.org>
Message-ID: <n0zMC.215290$r6.98242@fx10.am4>

On 21/05/2018 05:05, Chris Angelico wrote:
> On Mon, May 21, 2018 at 2:00 PM, Mikhail V <mikhailwas at gmail.com> wrote:

>> heaps! oh come on, youre making up again.
> 
> No, I'm not making it up. Just because the PDF works perfectly for
> you, you assume that it'll work perfectly for everyone. That is not
> the case, and that isn't my problem - it's your problem.

Perhaps the problem could well be at your end.

I don't remember having much trouble viewing PDFs, it's just a bit of a 
pain to do so (and I prefer to read them properly downloaded via the 
Adobe reader so that I can scroll in page mode, some extra steps).

I've just viewed a PDF on an old, low-spec Linux machine and it seemed 
fine, so it's not a Windows thing. (Can't access the OP's link for 
reasons unconnected with PDF.)

PDF seems to be universally used for all sorts of things (I used to have 
to print boarding passes via PDF; I doubt airlines wanted to alienate 
Linux users).

-- 
bartc


From bc at freeuk.com  Mon May 21 08:48:43 2018
From: bc at freeuk.com (bartc)
Date: Mon, 21 May 2018 13:48:43 +0100
Subject: "Data blocks" syntax specification draft
In-Reply-To: <mailman.248.1526785116.2761.python-list@python.org>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
Message-ID: <MezMC.257592$6D.186888@fx05.am4>

On 20/05/2018 03:58, Mikhail V wrote:
> I have made up a printable PDF with the current version
> of the syntax suggestion.
> 
> https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf
> 
> After some of your comments I've made some further
> re-considerations, e.g. element separation should
> be now much simpler.
> A lot of examples with comparison included.
> 
> 
> Comments, suggestions are welcome.

This is intended to be used inside actual Python programs?

In that case code is normally displayed in fixed pitch, as it would 
normally be viewed in a code editor, even if part of a document.

But I have to say it looks pretty terrible, and I can't see that it buys 
much over normal syntax.

The use of the funny /// symbol, and reserving identifiers t, L and d 
when following ///, is also a little naff.

(Note that lines starting // are interpreted as comment lines in C and 
C++ languages, and may be used by others too. Those used to see those as 
comments may get confused.)

It's not clear what ///. is for, or why it's necessary (presumably you 
have to use ///. /// instead of /// ///).

The ///d dictionary example is ambiguous: can you have more than one 
key:value per line or not? If so, it would look like this:

   ///d "a "b "c" "d" "e" "f"

so that the pairing is not clear.

You also seem to have more need of the "\" line continuation character 
in your syntax, because Python can do this:

    data = {

but you need:

    date = \
    ///

Or do you also allow: date = ///  with data following on the next line?


-- 
bartc


From chema at rinzewind.org  Mon May 21 10:48:01 2018
From: chema at rinzewind.org (=?iso-8859-1?Q?Jos=E9_Mar=EDa?= Mateos)
Date: Mon, 21 May 2018 10:48:01 -0400
Subject: Spam levels.
In-Reply-To: <5b027ca9$0$619$65785112@news.neostrada.pl>
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <5b027ca9$0$619$65785112@news.neostrada.pl>
Message-ID: <20180521144801.GB7508@equipaje>

On Mon, May 21, 2018 at 10:00:41AM +0200, m wrote:
> I also almost stopped reading c.l.python, because of enormous spam
> levels. Do I have any option to read it without spam, other than launch
> my own filtering NNTP server and do whack the mole game for myself?
> 
> Maybe join forces and establish such server for public use?

If you're willing to let NNTP access go, the mailing list works 
perfectly fine and is virtually spam-free.

Cheers,

-- 
Jos? Mar?a (Chema) Mateos
https://rinzewind.org/blog-es || https://rinzewind.org/blog-en


From grant.b.edwards at gmail.com  Mon May 21 11:42:28 2018
From: grant.b.edwards at gmail.com (Grant Edwards)
Date: Mon, 21 May 2018 15:42:28 +0000 (UTC)
Subject: Spam levels.
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <5b027ca9$0$619$65785112@news.neostrada.pl>
 <20180521144801.GB7508@equipaje>
Message-ID: <pdupd4$6ra$1@blaine.gmane.org>

On 2018-05-21, Jos? Mar?a Mateos <chema at rinzewind.org> wrote:
> On Mon, May 21, 2018 at 10:00:41AM +0200, m wrote:
>> I also almost stopped reading c.l.python, because of enormous spam
>> levels. Do I have any option to read it without spam, other than launch
>> my own filtering NNTP server and do whack the mole game for myself?
>> 
>> Maybe join forces and establish such server for public use?
>
> If you're willing to let NNTP access go, the mailing list works 
> perfectly fine and is virtually spam-free.

You can have both.  Point your NNTP client at news.gmane.org and
subscribe to gmane.comp.python.general.

That said, I never noticed any more spam on c.l.p than on the mailing
list.  I assume that's because my Usenet provider (Panix.com) filtered
it out.  I switched from Usenet to Gmane mainly because references
headers are bit more consistent on Gmane, so threading works somewhat
better.

[Regardless of whether I'm using Usenet or Gmane, I have slrn
configured to plonk all posts made from google.groups.]

-- 
Grant Edwards               grant.b.edwards        Yow! My nose feels like a
                                  at               bad Ronald Reagan movie ...
                              gmail.com            



From rbistolfi at gmail.com  Mon May 21 13:05:33 2018
From: rbistolfi at gmail.com (Rodrigo Bistolfi)
Date: Mon, 21 May 2018 14:05:33 -0300
Subject: best way to remove leading zeros from a tuple like string
In-Reply-To: <pdts8s$854$1@blaine.gmane.org>
References: <189bca64-1c7e-459f-a8a2-59db0e1752f8@googlegroups.com>
 <87d0xqkott.fsf@bsb.me.uk> <pdstr1$f2r$1@dont-email.me>
 <877enykkcm.fsf@bsb.me.uk>
 <8b551692-c4e5-4577-9786-650fc5f520fd@googlegroups.com>
 <pdts8s$854$1@blaine.gmane.org>
Message-ID: <CAMQZ-Rcms7YXhGiefjNRiz2Nne+19+LCKAQtH+WqT3UbW0HhRw@mail.gmail.com>

>>> repr(tuple(int(i) for i in s[1:-1].split(',')))
'(128, 20, 8, 255, -1203, 1, 0, -123)'

2018-05-21 4:26 GMT-03:00 Peter Otten <__peter__ at web.de>:

> bruceg113355 at gmail.com wrote:
>
> > Looking over the responses, I modified my original code as follows:
> >
> >>>> s = "(0000128, 020, 008, 255, -1203,01,-000, -0123)"
> >>>> ",".join([str(int(i)) for i in s[1:-1].split(",")])
> > '128,20,8,255,-1203,1,0,-123'
>
> I think this looks better with a generator instead of the listcomp:
>
> >>> ",".join(str(int(i)) for i in s[1:-1].split(","))
> '128,20,8,255,-1203,1,0,-123'
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>


From rgaddi at highlandtechnology.invalid  Mon May 21 13:13:36 2018
From: rgaddi at highlandtechnology.invalid (Rob Gaddi)
Date: Mon, 21 May 2018 10:13:36 -0700
Subject: Numpy array
In-Reply-To: <4f03b757-ff98-4386-bd73-9acd85b0eb66@googlegroups.com>
References: <4f03b757-ff98-4386-bd73-9acd85b0eb66@googlegroups.com>
Message-ID: <pduuo2$oo$1@dont-email.me>

On 05/18/2018 09:50 PM, Sharan Basappa wrote:
> This is regarding numpy array. I am a bit confused how parts of the array are being accessed in the example below.
> 
> 1 import scipy as sp
> 2 data = sp.genfromtxt("web_traffic.tsv", delimiter="\t")
> 3 print(data[:10])
> 4 x = data[:,0]
> 5 y = data[:,1]
> 
> Apparently, line 3 prints the first 10 entries in the array
> line 4 & 5 is to extract all rows but only 1st and second columns alone for x and y respectively.
> 
> I am confused as to how data[:10] gives the first 10 rows while data[:,0] gives all rows
> 

Numpy ordering is [rows,columns,...].  Things you don't provide an 
explicit answer for are assumed to be "all", which in Python syntax is 
":".  The reason for THAT goes into how slices are constructed.

So your example 3 could also be written print(data[0:10,:]), which sets 
rows to the range starting with 0 and ending before 10, and columns to 
everything.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.


From mikhailwas at gmail.com  Mon May 21 14:08:13 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Mon, 21 May 2018 21:08:13 +0300
Subject: "Data blocks" syntax specification draft
In-Reply-To: <CAPTjJmr2BPY2MRD=Vy+xiMj2-dbZZyiWfj_=ete7NcLVGMhzKg@mail.gmail.com>
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
 <CAPTjJmoOQV_pz+SAJjXk53qYTfDMoC7EO-VoyE_EaihGPHz_oA@mail.gmail.com>
 <CAE6NSRCwdJy_7tMn=OnSDqwqkCDZSMKRnnP6TC6TSou0sEf5ug@mail.gmail.com>
 <CAPTjJmr2BPY2MRD=Vy+xiMj2-dbZZyiWfj_=ete7NcLVGMhzKg@mail.gmail.com>
Message-ID: <CAE6NSRCMtJVuHTLq+emkzGBdiH7-cT3A90cNi2ALbhmw=rpZFw@mail.gmail.com>

On Mon, May 21, 2018 at 7:05 AM, Chris Angelico <rosuav at gmail.com> wrote:
>>> Forcing us to download a PDF and then read it? Well, it's your
>>> decision. My decision is that I cannot be bothered going to THAT much
>>> effort to figure out what you're saying.
>>
>> THAT much effort to click two times instead of one - and get a
>> formatted document instead of plain bw text. o-kaay..
>
> Two clicks? No, that isn't how it happened for me. I clicked on it and
> then I couldn't see the content.

Sorry I don't know - seems that everyone can see it.

> What second click am I supposed to do
> that shows me the page?

No, no second click is needed. But if you want to download a file -
there is a button "download file". So in a pair of clicks you get
a file on your PC and you can use your favorite viewer to view
PDF, which is IMO more convenient than in a browser.

>> Ok. How is about images? this proposal will require a lot of images
>> - otherwise people who read it are forced to copy-paste snippets
>> into their code editors to understand how it may look in reality.
>
> If you're proposing syntax for Python, it's ultimately going to have
> to be text.

All of files that I provided are TEXT. Well maybe PDF is a bit "less text
than TXT" but still its just text pieces.

> You cannot say "and every text editor has to render it
> like this". If you can't demonstrate it using plain text, you have a
> major problem on your hands.

How do you do that?!  You're truly unsurpassed master of polemics.
How you turn everything upside down so easily? - that is _me_ who tells
to make _various_ samples so as to be able to see difference by
various fonts. And it is _you_ who say "everybody look at black and
white sample with a font out of 80' ".
WTF means "If you can't demonstrate it using plain text"?
There is nothing more simple than demonstrate it in plain text.
But it is not enough to judge the syntax since there is
_huge_ difference of fonts, and presence of highlighting makes huge
difference especially for expressions with keywords.

>>> I'm not going to read your proposal if you force me to go to heaps of
>>> effort for it.
>>
>> heaps! oh come on, youre making up again.
>
> No, I'm not making it up. Just because the PDF works perfectly for
> you, you assume that it'll work perfectly for everyone.

Look, PDF is one of the most widely used document exchange formats.
And you know it. I personally  don't need the PDF either - creating it
just adds me
work. And I am not debating anything about it, just made it for convenience
since someone maybe prefer it.


From rosuav at gmail.com  Mon May 21 15:17:50 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 22 May 2018 05:17:50 +1000
Subject: "Data blocks" syntax specification draft
In-Reply-To: <CAE6NSRCMtJVuHTLq+emkzGBdiH7-cT3A90cNi2ALbhmw=rpZFw@mail.gmail.com>
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
 <CAPTjJmoOQV_pz+SAJjXk53qYTfDMoC7EO-VoyE_EaihGPHz_oA@mail.gmail.com>
 <CAE6NSRCwdJy_7tMn=OnSDqwqkCDZSMKRnnP6TC6TSou0sEf5ug@mail.gmail.com>
 <CAPTjJmr2BPY2MRD=Vy+xiMj2-dbZZyiWfj_=ete7NcLVGMhzKg@mail.gmail.com>
 <CAE6NSRCMtJVuHTLq+emkzGBdiH7-cT3A90cNi2ALbhmw=rpZFw@mail.gmail.com>
Message-ID: <CAPTjJmrMsd7+Y9Jrcvd_=VtCrfhPsjv2S2qpY71fMbftkiNsVQ@mail.gmail.com>

On Tue, May 22, 2018 at 4:08 AM, Mikhail V <mikhailwas at gmail.com> wrote:
>>> Ok. How is about images? this proposal will require a lot of images
>>> - otherwise people who read it are forced to copy-paste snippets
>>> into their code editors to understand how it may look in reality.
>>
>> If you're proposing syntax for Python, it's ultimately going to have
>> to be text.
>
> All of files that I provided are TEXT. Well maybe PDF is a bit "less text
> than TXT" but still its just text pieces.

Funny, I'm pretty sure I heard you say that your proposal would
require a lot of images. Or are images somehow just a bit less text
than text too?

I'm not interested in a proposal that is hard to read, for a syntax
that is utterly unpythonic, to achieve something that is better done
with a data file format. Bye!

ChrisA


From marko at pacujo.net  Mon May 21 15:49:02 2018
From: marko at pacujo.net (Marko Rauhamaa)
Date: Mon, 21 May 2018 22:49:02 +0300
Subject: "Data blocks" syntax specification draft
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
 <CAPTjJmoOQV_pz+SAJjXk53qYTfDMoC7EO-VoyE_EaihGPHz_oA@mail.gmail.com>
 <CAE6NSRCwdJy_7tMn=OnSDqwqkCDZSMKRnnP6TC6TSou0sEf5ug@mail.gmail.com>
 <CAPTjJmr2BPY2MRD=Vy+xiMj2-dbZZyiWfj_=ete7NcLVGMhzKg@mail.gmail.com>
 <CAE6NSRCMtJVuHTLq+emkzGBdiH7-cT3A90cNi2ALbhmw=rpZFw@mail.gmail.com>
 <mailman.285.1526926096.2761.python-list@python.org>
Message-ID: <87sh6k94cx.fsf@elektro.pacujo.net>

Mikhail V <mikhailwas at gmail.com>:
> How do you do that?! You're truly unsurpassed master of polemics. How
> you turn everything upside down so easily?

If someone's behavior annoys you too much, just put them in your kill
file.

(And no, you don't have to declare it publically.)


Marko


From cwr at seckford.org  Mon May 21 16:11:18 2018
From: cwr at seckford.org (C W Rose)
Date: Mon, 21 May 2018 21:11:18 +0100
Subject: Spam levels.
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <5b027ca9$0$619$65785112@news.neostrada.pl>
Message-ID: <6olbte-7i3.ln1@tanner.seckford.org>

m <mvoicem at gmail.com> wrote:
> W dniu 10.02.2018 o?15:57, C W Rose pisze:
>> No other groups (in the limited set which I read) have the problem,
>> and I don't understand why the spammers neither spam a range of
>> groups, nor change their adddresses more frequently.  It may be
>> that destroying comp.lang.python is their actual objective.
>> 
>> Either way, a depressing state of affairs.
> 
> The sad thing is, that your post is unseen, because of spam :S
> 
> I also almost stopped reading c.l.python, because of enormous spam
> levels. Do I have any option to read it without spam, other than launch
> my own filtering NNTP server and do whack the mole game for myself?
> 
> Maybe join forces and establish such server for public use?
> 

The situation is getting worse:

    comp.lang.python messages 29 Jan - 14 May 2018
    Fetched: 3081
    Killed: 6616
    Valid: 31.77 %

Almost all of the garbage is coming from the "Case Solutions" poster,
with a hotmail address.  He's said himself that he doesn't read the
group, and there's really no point to endless reposting in a newsgroup
with no relevance to the posts, so it's just mindless vandalism.
He doesn't change addresses or headers much, so the filter seldom needs
updating; however, I think comp.lang.python is reaching the end of the line.

comp.lang.c has less overwhelming problems, due to a single obsessive:
    comp.lang.c messages 29 Jan - 14 May 2018
    Fetched: 3969
    Killed: 618
    Valid: 86.52 %

If you are using Linux, leafnode is easy to set up, and has enough filtering
to keep comp.lang.python readable.  I pull from news.eternal-september.org
and news.gmane.org (though I don't know how much longer gmane will last).
Both are free.

Will

-- 
"It is very disappointing that mindless individuals are vandalising
 the Larkin toads in Hull."
    A police spokesman



From brucegoodstein at gmail.com  Mon May 21 16:16:22 2018
From: brucegoodstein at gmail.com (brucegoodstein at gmail.com)
Date: Mon, 21 May 2018 13:16:22 -0700 (PDT)
Subject: best way to remove leading zeros from a tuple like string
In-Reply-To: <mailman.284.1526922336.2761.python-list@python.org>
References: <189bca64-1c7e-459f-a8a2-59db0e1752f8@googlegroups.com>
 <87d0xqkott.fsf@bsb.me.uk> <pdstr1$f2r$1@dont-email.me>
 <877enykkcm.fsf@bsb.me.uk>
 <8b551692-c4e5-4577-9786-650fc5f520fd@googlegroups.com>
 <pdts8s$854$1@blaine.gmane.org>
 <CAMQZ-Rcms7YXhGiefjNRiz2Nne+19+LCKAQtH+WqT3UbW0HhRw@mail.gmail.com>
 <mailman.284.1526922336.2761.python-list@python.org>
Message-ID: <8c95ec11-cd81-4ea9-a054-e7b63a587646@googlegroups.com>

On Monday, May 21, 2018 at 1:05:52 PM UTC-4, Rodrigo Bistolfi wrote:
> >>> repr(tuple(int(i) for i in s[1:-1].split(',')))
> '(128, 20, 8, 255, -1203, 1, 0, -123)'
> 
> 2018-05-21 4:26 GMT-03:00 Peter Otten <__peter__ at web.de>:
> 
> > bruceg113355 at gmail.com wrote:
> >
> > > Looking over the responses, I modified my original code as follows:
> > >
> > >>>> s = "(0000128, 020, 008, 255, -1203,01,-000, -0123)"
> > >>>> ",".join([str(int(i)) for i in s[1:-1].split(",")])
> > > '128,20,8,255,-1203,1,0,-123'
> >
> > I think this looks better with a generator instead of the listcomp:
> >
> > >>> ",".join(str(int(i)) for i in s[1:-1].split(","))
> > '128,20,8,255,-1203,1,0,-123'
> >
> >
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> >


I am not familiar with the repr statement.
Looking into your response, I like it.
There is no need to add-in the parentheses.

With the repr statment:
>>> bb = repr (tuple (int (i) for i in s [1: -1] .split (',')))
>>> bb
'(128, 20, 8, 255, -1203, 1, 0, -123)'
>>> type(bb)
<class 'str'>
>>>

Without the repr statement:
>>> aa = (tuple (int (i) for i in s [1: -1] .split (',')))
>>> aa
(128, 20, 8, 255, -1203, 1, 0, -123)
>>> type(aa)
<class 'tuple'>
>>>

Thanks,
Bruce





From D.Strohl at F5.com  Mon May 21 16:34:33 2018
From: D.Strohl at F5.com (Dan Strohl)
Date: Mon, 21 May 2018 20:34:33 +0000
Subject: "Data blocks" syntax specification draft
In-Reply-To: <e2764d57-1534-8819-84c6-658ddc05b38a@nedbatchelder.com>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <e2764d57-1534-8819-84c6-658ddc05b38a@nedbatchelder.com>
Message-ID: <e4ef68c3b397469c9117f9767320767c@F5.com>

On 5/19/18 10:58 PM, Mikhail V wrote:
>> I have made up a printable PDF with the current version of the syntax 
>> suggestion.
>>
>> https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf
>>
>> After some of your comments I've made some further re-considerations, 
>> e.g. element separation should be now much simpler.
>> A lot of examples with comparison included.
>>
>>
>> Comments, suggestions are welcome.
>>
>
>Mikhail, you have a completely different esthetic for syntax than the rest of the Python world.? Your proposal seems to have almost nothing in common with existing Python syntax.? Your approach to >whitespace is different. You've ignored existing words (tuple, str) in favor of new shorthands (t, s).? You use semicolon and asterisk for something new. Parentheses enclosing strings!?
>
>This is never going to be adopted as Python syntax. It's too different.
>
>That's fine: make a new file format.? Write a library that can read and write this format.? Propose it to people, and get them using it.? We have xml, ini, json, yaml, and toml.? Now we can also have data >blocks.

Mikhail,

I'm afraid I would have to agree with Ned,   in looking at it, this did not seem to be any less complex than existing python structures, nor was it significantly less typing (in many cases) after you put the /// in there.

Also there were several places where it's not deterministic enough around data types... how would it handle a tuple like:

test=(0x991, 0x01, 'Hello', 123e334562.9, 1, '1', "This is a single string (including this)",  custom_object)

I get the idea of trying to remove some of those extra punctuation marks, but they exist for a reason, and removing them just leads to a more complex world of "sometimes you use them and sometimes you don?t".

For the dictionary type, with odd elements being keys and even being values, that can get really hard to visually parse if you have a long block in a row... for example:

///d abc def ghi jkl mno pqr stu vwx yz1 ab2 cd4

Would break, but... where?  Which parts are supposed to be keys v. values?

You mentioned ease of import of data in your summary, I haven't seen any data files that use a format like this, so I don?t offhand see that value, but if it is, as Ned mentioned, then doing a translator object for it makes sense.  Approach this like a new data format (like XML, JSON, etc) Then also, if it ends up taking off, you are better placed to come back and say "see, everyone's using this format, Python should handle it by default".

Finally, you mentioned several "main problems".  Those I totally agree with, but I don?t think you realize how complex they are.  The parser would have nightmares trying to parse some of these structures into tokens without having a totally different parser engine just for that, and there are lots of corner cases that would break this approach and would need a different approach, requiring a long list of caveats, and at least personally, I just don't see the value there.  The few places where it seems like it would be a benefit are pretty small, and the places where it makes things more complex seem common.

Dan Strohl



From jf_byrnes at comcast.net  Mon May 21 17:06:00 2018
From: jf_byrnes at comcast.net (Jim)
Date: Mon, 21 May 2018 16:06:00 -0500
Subject: Python 3.6 causes error, python 3.5 does not.
In-Reply-To: <pdsgmd$vfo$1@blaine.gmane.org>
References: <pdsgmd$vfo$1@blaine.gmane.org>
Message-ID: <pdvc7l$gmc$1@blaine.gmane.org>

On 05/20/2018 02:03 PM, Jim wrote:
> Mint 18
> Libreoffice 5.1.6.2
> Python 3.6.5 in one virtual environment
> Python 3.5.2 in another
> 
> I am writing a script that uses pyautogui to get some data and paste it 
> into a Libreoffice calc file, there by bypassing the complexity of uno.
> 
> The problem is it runs fine if I use python 3.5. If I use python 3.6 it 
> opens the calc file then pops up a dialog saying "std::bad_alloc". There 
> are no relevant errors in the terminal. At this point I must reload the 
> file and let calc recover it. I googled "std::bad_alloc" but didn'
> 
> This is the portion of the code that causes the error:
> 
> import pyautogui
> import subprocess
> import threading
> import time
> 
> LONG_ENOUGH = 5
> 
> class LO():
>  ??? '''Manipulate libreoffice not using UNO'''
>  ??? def __init__(self):
>  ??????? self.filename = 
> '/home/jfb/Documents/Financial/Investing/Stocks.ods'
>  ??????? opener = threading.Thread(target=self.open_it, 
> args=(self.filename,))
>  ??????? opener.start()
>  ??????? time.sleep(5) #LONG_ENOUGH)
>  ??????? #self.manipulate_LO()
> 
>  ??? #Open and work with libreoffice
>  ??? def open_it(self, filename):
>  ??????? #subprocess.call(["libreoffice", filename])
>  ??????? subprocess.run(["libreoffice", filename])
> 
> lo = LO()
> 
> To complicate matters not all .ods files show this problem. I ran some 
> tests. Two of my .ods files are effected but a couple of others are not. 
> A new test file I created is not effected.
> 
> I don't know if I have a Libreoffice problem, file corruption or a 
> Python problem. The fact that 3.6 gives an error but 3.5 does not is the 
> reason I decided to ask here first.
> 
> Regards,? Jim
> 

To follow up. I just discovered the error only happens if I start the 
script from inside the 3.6 virtual environment. If I start it from 
another terminal with the full path to the 3.6 VE and the script it runs 
without error.

Regards,  Jim



From mikhailwas at gmail.com  Mon May 21 21:42:43 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Tue, 22 May 2018 04:42:43 +0300
Subject: "Data blocks" syntax specification draft
In-Reply-To: <e2764d57-1534-8819-84c6-658ddc05b38a@nedbatchelder.com>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <e2764d57-1534-8819-84c6-658ddc05b38a@nedbatchelder.com>
Message-ID: <CAE6NSRCoE7TGHhp7v+Kq4Abu-5VXKUxiizurwUpi9qSVVKGj=g@mail.gmail.com>

On Mon, May 21, 2018 at 2:14 PM, Ned Batchelder <ned at nedbatchelder.com> wrote:
> On 5/19/18 10:58 PM, Mikhail V wrote:
>>
>> I have made up a printable PDF with the current version
>> of the syntax suggestion.
>>
>> https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf
>>
>> After some of your comments I've made some further
>> re-considerations, e.g. element separation should
>> be now much simpler.
>> A lot of examples with comparison included.
>>
>>
>> Comments, suggestions are welcome.
>>
>
> Mikhail, you have a completely different esthetic for syntax than the rest
> of the Python world.

In what sense? I don't propose to add braces to Python or anything like that.

> Your proposal seems to have almost nothing in common
> with existing Python syntax.

Well, if  speak of adding any embedded data syntax at all - how do you think:
should the embedded syntax copy everything? Even if it will look worse
in the end?
Frankly, I don't think so.
If you ask me:  may it be totally different syntax than Python?
I'd say - no, but it should be something compromising.

What other criteria is there?
Main benefits i see in Python syntax: indentation-based,
no termination tokens, new-line statement separation. Overall tendency
to prioritize readability
(e.g. over parse-ability). All these points i try to oblige.
Actually if think deeper of it - these points are not even something "Pythonic"
but merely just common sense and some basic readability principles.

> Your approach to whitespace is different.
> You've ignored existing words (tuple, str) in favor of new shorthands (t,s).

Yes. Turns out these two things should work better for presentation,
so nothing much unexpectable and nothing personal against existing words ;-).
Type abbreviations deserve more explanation in the doc though.
Simply put - if I write whole words - then type names _will dominate over data_.
E.g.:

/// tuple
   /// tuple
      foo  bar

and even so:

tuple:
   tuple:
      foo  bar

Might it be that the latter is more 'Pythonic'? Maybe yes. But how it
will look on average structure - should be compared.
Again: with proper highlighting this _might_ be an option, but without
highlighting -
sorry, would be just too hard to eyeball the nodes.

Regarding further smaller details - semicolons, asterisks - those are
subject for
further observations and may change.


> Parentheses enclosing strings!?

:-) Ok, here I agree -   the whole 'string type' part - that would be
just too much to
slip through. This would cause inconsistence and add confusion when
placed together with
normal token presentation structs. Although e.g. in a separate file
with a string-only data
it could make the difference.


From mikhailwas at gmail.com  Mon May 21 22:17:53 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Tue, 22 May 2018 05:17:53 +0300
Subject: "Data blocks" syntax specification draft
In-Reply-To: <CAHiMU6cGz=X4LMcYac=_Us0+9ATPTrJPLZaeXmK07KbnNFSP2A@mail.gmail.com>
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
 <pdu324$l8j$1@blaine.gmane.org>
 <CAHiMU6cGz=X4LMcYac=_Us0+9ATPTrJPLZaeXmK07KbnNFSP2A@mail.gmail.com>
Message-ID: <CAE6NSRA9sNDkL2RgpaUnziRv5ka2j_L4y1rScKoLJSnR+KCXpg@mail.gmail.com>

On Mon, May 21, 2018 at 1:41 PM, Chris Lindsay via Python-list
<python-list at python.org> wrote:

> If a block of static data is large enough to start to be ugly, a common
> approach is to load the data from some other file, in a language which is
> designed around structured data.


Maybe it is common in industrial applications but not in smaller production,
and according to my observation not common at all in all occasional scripts.

>YAML comes to mind

Actually plugging a data syntax in existing language is not a new idea.
Though I don't know real success stories.

> What use-case do you foresee for your proposed new format, that isn't
> already (better) accomplished by using a separate structured
> data/serialisation language?

Well everything described in the doc is quite common. So simply put,
for all data beyond trivial inline [1,2,3].

If your idea is to use external data for all scenarios - then there are
many questions - which toolchains, file organisation, distribution etc.
One common approach is an TSV/ CSV editor plus a quick dirty
self-defined parser.
One criteria for a syntax - how simple to edit it in normal text editor
and how other existing data editors can do it.


From ned at nedbatchelder.com  Mon May 21 22:21:52 2018
From: ned at nedbatchelder.com (Ned Batchelder)
Date: Mon, 21 May 2018 22:21:52 -0400
Subject: "Data blocks" syntax specification draft
In-Reply-To: <CAE6NSRCoE7TGHhp7v+Kq4Abu-5VXKUxiizurwUpi9qSVVKGj=g@mail.gmail.com>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <e2764d57-1534-8819-84c6-658ddc05b38a@nedbatchelder.com>
 <CAE6NSRCoE7TGHhp7v+Kq4Abu-5VXKUxiizurwUpi9qSVVKGj=g@mail.gmail.com>
Message-ID: <51bd84e9-3c7a-811e-2ec3-01610432492a@nedbatchelder.com>

On 5/21/18 9:42 PM, Mikhail V wrote:
> On Mon, May 21, 2018 at 2:14 PM, Ned Batchelder<ned at nedbatchelder.com>  wrote:
>> On 5/19/18 10:58 PM, Mikhail V wrote:
>>> I have made up a printable PDF with the current version
>>> of the syntax suggestion.
>>>
>>> https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf
>>>
>>> After some of your comments I've made some further
>>> re-considerations, e.g. element separation should
>>> be now much simpler.
>>> A lot of examples with comparison included.
>>>
>>>
>>> Comments, suggestions are welcome.
>>>
>> Mikhail, you have a completely different esthetic for syntax than the rest
>> of the Python world.
> In what sense? I don't propose to add braces to Python or anything like that.
>

In the sense that no one likes it.? I don't mean to be blunt, but it 
doesn't look or act like Python, and it replaces existing structures 
with things that are completely different.

You've proposed it and asked for feedback, but you seem to be completely 
ignoring the feedback people are giving you.

It's not going to be added to Python. Write it as a third-party library.

--Ned.


From ben+python at benfinney.id.au  Mon May 21 22:41:01 2018
From: ben+python at benfinney.id.au (Ben Finney)
Date: Tue, 22 May 2018 12:41:01 +1000
Subject: "Data blocks" syntax specification draft
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <e2764d57-1534-8819-84c6-658ddc05b38a@nedbatchelder.com>
 <CAE6NSRCoE7TGHhp7v+Kq4Abu-5VXKUxiizurwUpi9qSVVKGj=g@mail.gmail.com>
 <51bd84e9-3c7a-811e-2ec3-01610432492a@nedbatchelder.com>
Message-ID: <85zi0sjttu.fsf@benfinney.id.au>

Ned Batchelder <ned at nedbatchelder.com> writes:

> You've proposed it and asked for feedback, but you seem to be
> completely ignoring the feedback people are giving you.

Another problem with the proposal: The motivation to introduce such a
large change is not compelling. What is the problem this proposal aims
to solve? Why solve it with such a large amount of fundamental change,
when (as discussed in this thread) there are apparently many existing
solutions that work well?

If there's a problem that existing solutions are not addressing well,
the proposal needs to do the work of explicitly stating the problem and
its constraints, demonstrating an understanding of those existing
solutions and how they are inadequate to the explicitly described
problem.

-- 
 \         ?If you can do no good, at least do no harm.? ?_Slapstick_, |
  `\                                                     Kurt Vonnegut |
_o__)                                                                  |
Ben Finney



From mikhailwas at gmail.com  Mon May 21 22:49:34 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Tue, 22 May 2018 05:49:34 +0300
Subject: "Data blocks" syntax specification draft
In-Reply-To: <MezMC.257592$6D.186888@fx05.am4>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
Message-ID: <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>

On Mon, May 21, 2018 at 3:48 PM, bartc <bc at freeuk.com> wrote:

>
> This is intended to be used inside actual Python programs?
>
> In that case code is normally displayed in fixed pitch, as it would normally
> be viewed in a code editor, even if part of a document.
>
> But I have to say it looks pretty terrible, and I can't see that it buys
> much over normal syntax.

Ha, here we go. Last time I have used fixed pitch font for work -
maybe 4 years ago.
(and IMO fixed pitch font plus specifically Python - I find quite a blasphemy)

So, you re right, of course in one sense: "///" looks terrible with
a fixed pitch font! That's so true, but also it is true that this ///
I well maybe change for something less font-sensitive.
And in all fonts other than fixed pitch it looks cute enough.

Simply speaking, if it was not for Python, I might propose something
like:

# t
   # t
      11  22  33

You get the point?
So basically all nice chars are already occupied.
Proposing Unicode symbols -- that will probably will be
dead on arrival (just remembering some of such past proposals).
Leaving out symbols could be an option as well.
Still the structure needs a syntactical entry point.
E.g.

data = ///
t
   t
      11  22  33

Hmm. not bad. But I must think about parsing as well.


> It's not clear what ///. is for, or why it's necessary (presumably you have
> to use ///. /// instead of /// ///).

"///."  is meant to inherit the previous (parent) type:

/// t
   /// .
      /// .

is same as

/// t
   /// t
      /// t

So I can change types of all child nodes with one keystroke.


>
> The ///d dictionary example is ambiguous: can you have more than one
> key:value per line or not? If so, it would look like this:
>
>   ///d "a" "b" "c" "d" "e" "f"

///d   "a" "b"    "c" "d"    "e" "f"

Now better? :-)

Or compare these two:

{"a": "b", "c": "d", "e": "f"}

///d   "a" "b"    "c" "d"    "e" "f"

I'd say, the second one is much better.


> Or do you also allow: date = ///  with data following on the next line?

Yes, all this should be legal:

data = /// t
   11 22 33

data =\
/// t
   11 22 33

data = /// t  11 22 33


But this probly not good:

data = /// t  11 22 33  /// t  44  55

Because it will not be clear for the reader how further suite termination
happens.


From pfeiffer at cs.nmsu.edu  Mon May 21 23:39:16 2018
From: pfeiffer at cs.nmsu.edu (Joe Pfeiffer)
Date: Mon, 21 May 2018 21:39:16 -0600
Subject: "Data blocks" syntax specification draft
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
 <pdu324$l8j$1@blaine.gmane.org>
 <CAHiMU6cGz=X4LMcYac=_Us0+9ATPTrJPLZaeXmK07KbnNFSP2A@mail.gmail.com>
 <CAE6NSRA9sNDkL2RgpaUnziRv5ka2j_L4y1rScKoLJSnR+KCXpg@mail.gmail.com>
 <mailman.4.1526955481.18022.python-list@python.org>
Message-ID: <1bd0xo4avv.fsf@pfeifferfamily.net>

Mikhail V <mikhailwas at gmail.com> writes:

> On Mon, May 21, 2018 at 1:41 PM, Chris Lindsay via Python-list
> <python-list at python.org> wrote:
>
>> If a block of static data is large enough to start to be ugly, a common
>> approach is to load the data from some other file, in a language which is
>> designed around structured data.
>
>
> Maybe it is common in industrial applications but not in smaller production,
> and according to my observation not common at all in all occasional scripts.

It is absolutely standard in all applications that have a configuration
file.


From auriocus at gmx.de  Tue May 22 02:01:05 2018
From: auriocus at gmx.de (Christian Gollwitzer)
Date: Tue, 22 May 2018 08:01:05 +0200
Subject: "Data blocks" syntax specification draft
In-Reply-To: <mailman.4.1526955481.18022.python-list@python.org>
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
 <pdu324$l8j$1@blaine.gmane.org>
 <CAHiMU6cGz=X4LMcYac=_Us0+9ATPTrJPLZaeXmK07KbnNFSP2A@mail.gmail.com>
 <CAE6NSRA9sNDkL2RgpaUnziRv5ka2j_L4y1rScKoLJSnR+KCXpg@mail.gmail.com>
 <mailman.4.1526955481.18022.python-list@python.org>
Message-ID: <pe0bn1$8ns$1@dont-email.me>

Am 22.05.18 um 04:17 schrieb Mikhail V:
> On Mon, May 21, 2018 at 1:41 PM, Chris Lindsay via Python-list
> <python-list at python.org> wrote:
> 
>> If a block of static data is large enough to start to be ugly, a common
>> approach is to load the data from some other file, in a language which is
>> designed around structured data.
> 
> 
> Maybe it is common in industrial applications but not in smaller production,
> and according to my observation not common at all in all occasional scripts.
> 
>> YAML comes to mind
> 
> Actually plugging a data syntax in existing language is not a new idea.
> Though I don't know real success stories.
> 

Thing is, you can do it already now in the script, without modifying the 
Python interpreter, by parsing a triple-quoted string. See the examples 
right here: http://pyyaml.org/wiki/PyYAMLDocumentation

	Christian


From tjol at tjol.eu  Tue May 22 04:33:20 2018
From: tjol at tjol.eu (Thomas Jollans)
Date: Tue, 22 May 2018 10:33:20 +0200
Subject: best way to remove leading zeros from a tuple like string
In-Reply-To: <CA+og5uqymZ23w0GVE-ZuQL9Ha8nmcxEm++WnmU2tOpwc5pazqg@mail.gmail.com>
References: <189bca64-1c7e-459f-a8a2-59db0e1752f8@googlegroups.com>
 <pdsnm8$8vd$1@dont-email.me>
 <360b3420-92fa-4fb6-8d30-399f0cb26f3e@googlegroups.com>
 <CA+og5uoy08VUSEj6aM-BVmDx2MzO5_6oQ-fW0A6uQhvXy9UXPw@mail.gmail.com>
 <CA+og5uodUMytqKp+T+JcL_NHZLPoPnzO8TS4ik8XgZNQe3jtYg@mail.gmail.com>
 <CA+og5uqymZ23w0GVE-ZuQL9Ha8nmcxEm++WnmU2tOpwc5pazqg@mail.gmail.com>
Message-ID: <2c2b7af6-8813-48ee-a135-8a4466458082@tjol.eu>

On 2018-05-20 23:54, Paul wrote:
> you will find several useful sites where you can test regexes.  Regex
> errors are very common, even after you have experience with them.

What's the benefit of those compared to simply trying out the regex in a
Python console?


From arj.python at gmail.com  Tue May 22 05:34:16 2018
From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer)
Date: Tue, 22 May 2018 13:34:16 +0400
Subject: Issue
In-Reply-To: <CAOpC7vPdz7J5tywt9oHWVgNTnmJi=hnSL716LVfSsSoG2JiFKg@mail.gmail.com>
References: <CAOpC7vMGsexgb3Qk5GWyUnP9MTKkKJBtx+ADLJ7U-WW_jkn_-w@mail.gmail.com>
 <CAOpC7vPdz7J5tywt9oHWVgNTnmJi=hnSL716LVfSsSoG2JiFKg@mail.gmail.com>
Message-ID: <CADrxXXnAT8M=UViVh8KOdDYrH9gJ9NWNxkTnRs1c4eXf99eS2g@mail.gmail.com>

greetings,

did you send a log file attached?

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

On Tue, 22 May 2018, 10:28 sujith.j Sjk, <sujith.sjk at gmail.com> wrote:

> > Hi,
> >
> > Am facing the below issue when starting pyton.
> >
> >
> >
> --
> https://mail.python.org/mailman/listinfo/python-list
>


From tallpaul at gmail.com  Tue May 22 05:38:14 2018
From: tallpaul at gmail.com (Paul)
Date: Tue, 22 May 2018 02:38:14 -0700
Subject: best way to remove leading zeros from a tuple like string
In-Reply-To: <2c2b7af6-8813-48ee-a135-8a4466458082@tjol.eu>
References: <189bca64-1c7e-459f-a8a2-59db0e1752f8@googlegroups.com>
 <pdsnm8$8vd$1@dont-email.me>
 <360b3420-92fa-4fb6-8d30-399f0cb26f3e@googlegroups.com>
 <CA+og5uoy08VUSEj6aM-BVmDx2MzO5_6oQ-fW0A6uQhvXy9UXPw@mail.gmail.com>
 <CA+og5uodUMytqKp+T+JcL_NHZLPoPnzO8TS4ik8XgZNQe3jtYg@mail.gmail.com>
 <CA+og5uqymZ23w0GVE-ZuQL9Ha8nmcxEm++WnmU2tOpwc5pazqg@mail.gmail.com>
 <2c2b7af6-8813-48ee-a135-8a4466458082@tjol.eu>
Message-ID: <CA+og5uodjk3tbM=iZQ40R3voCrNgxcVGmQui-v+wr3aW0NhnsQ@mail.gmail.com>

Thomas Jollans wrote:

> On 2018-05-20 23:54, Paul wrote:
> > you will find several useful sites where you can test regexes.
>
> What's the benefit of those compared to simply trying out the regex in a
> Python console?
>

Possibly nothing.  But there are obvious benefits compared to trying to
write and test such an expression in one's head, which was the situation
which led me to suggest it.  :)

>


From sujith.sjk at gmail.com  Tue May 22 06:08:13 2018
From: sujith.sjk at gmail.com (sujith.j Sjk)
Date: Tue, 22 May 2018 15:38:13 +0530
Subject: Issue
In-Reply-To: <CADrxXXnAT8M=UViVh8KOdDYrH9gJ9NWNxkTnRs1c4eXf99eS2g@mail.gmail.com>
References: <CAOpC7vMGsexgb3Qk5GWyUnP9MTKkKJBtx+ADLJ7U-WW_jkn_-w@mail.gmail.com>
 <CAOpC7vPdz7J5tywt9oHWVgNTnmJi=hnSL716LVfSsSoG2JiFKg@mail.gmail.com>
 <CADrxXXnAT8M=UViVh8KOdDYrH9gJ9NWNxkTnRs1c4eXf99eS2g@mail.gmail.com>
Message-ID: <CAOpC7vPTonwPws_AAk8_GohQYL-eRLNOLrSZcECausBg5wxpAg@mail.gmail.com>

yes

On Tue, May 22, 2018 at 3:04 PM, Abdur-Rahmaan Janhangeer <
arj.python at gmail.com> wrote:

> greetings,
>
> did you send a log file attached?
>
> Abdur-Rahmaan Janhangeer
> https://github.com/Abdur-rahmaanJ
>
> On Tue, 22 May 2018, 10:28 sujith.j Sjk, <sujith.sjk at gmail.com> wrote:
>
>> > Hi,
>> >
>> > Am facing the below issue when starting pyton.
>> >
>> >
>> >
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>


From subhabangalore at gmail.com  Tue May 22 06:11:38 2018
From: subhabangalore at gmail.com (subhabangalore at gmail.com)
Date: Tue, 22 May 2018 03:11:38 -0700 (PDT)
Subject: Problem of writing long list of lists file to csv
Message-ID: <ffcd7a19-6d07-42a3-86f8-9cc25a383081@googlegroups.com>

I have a list of lists (177 lists). 

I am trying to write them as file.

I used the following code to write it in a .csv file.

import  csv
def word2vec_preprocessing():
    a1=open("/python27/EngText1.txt","r")
    list1=[]
    for line in a1:
        line1=line.lower().replace(".","").split()
        #print line1
        list1.append(line1)
    lst1=list1
    lst2=lst1[:4]
    with open("my_csv.csv","wb") as f:
        writer = csv.writer(f)
        writer.writerows(lst2)

Here it is writing only the first four lists. 

I have searched for help and it seems it is an issue and 
without much of fix. 
Please see the following link. 
https://stackoverflow.com/questions/30711899/python-how-to-write-list-of-lists-to-file

I have now tried pandas and json as follows, but same result. 
my_df = pd.DataFrame(lst2)
    my_df.to_csv('sbb_csv.csv', index=False, header=False)

with open('sbb1.json', 'w') as F:
        # Use the json dumps method to write the list to disk  
        F.write(json.dumps(lst2))
    with open('sbb1.json', 'r') as F:
        B = json.loads(F.read())

    print B


I am using Python 2.7.15 (v2.7.15:ca079a3ea3, Apr 30 2018, 16:22:17) [MSC v.1500 32 bit (Intel)] on win32
in MS-Windows.

Please suggest what  error I may be doing? 

Thanking in advance.



    


From __peter__ at web.de  Tue May 22 06:25:28 2018
From: __peter__ at web.de (Peter Otten)
Date: Tue, 22 May 2018 12:25:28 +0200
Subject: Problem of writing long list of lists file to csv
References: <ffcd7a19-6d07-42a3-86f8-9cc25a383081@googlegroups.com>
Message-ID: <pe0r2k$nnq$1@blaine.gmane.org>

subhabangalore at gmail.com wrote:

>     lst2=lst1[:4]
>     with open("my_csv.csv","wb") as f:
>         writer = csv.writer(f)
>         writer.writerows(lst2)
> 
> Here it is writing only the first four lists. 

Hint: look at the first line in the quotation above. 




From bc at freeuk.com  Tue May 22 06:25:59 2018
From: bc at freeuk.com (bartc)
Date: Tue, 22 May 2018 11:25:59 +0100
Subject: "Data blocks" syntax specification draft
In-Reply-To: <mailman.7.1526957382.18022.python-list@python.org>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
Message-ID: <VeSMC.135109$ga6.33227@fx24.am4>

On 22/05/2018 03:49, Mikhail V wrote:
> On Mon, May 21, 2018 at 3:48 PM, bartc <bc at freeuk.com> wrote:

>> But I have to say it looks pretty terrible, and I can't see that it buys
>> much over normal syntax.

> 
> # t
>     # t
>        11  22  33
> 

Is this example complete? Presumably it means ((11,22,33),).

> You get the point?
> So basically all nice chars are already occupied.

You mean for introducing tuple, list and dict literals? Python already 
uses (, [ and { for those, with the advantage of having a closing ), ] 
and } to make it easier to see where each ends.

The only advantage of your proposal is that it resembles Python block 
syntax a little more, but I don't know if it follows the same rules of 
indentation and for inlining content.

> Proposing Unicode symbols -- that will probably will be
> dead on arrival (just remembering some of such past proposals).
> Leaving out symbols could be an option as well.
> Still the structure needs a syntactical entry point.

Note that Python tuples don't always need a start symbol:

    a = 10,20,30

assigns a tuple to a.

> E.g.
> 
> data = ///
> t
>     t
>        11  22  33
> 
> Hmm. not bad. But I must think about parsing as well.

Have you tried writing a parser for this? It can be stand-alone, not a 
full parser for Python code. That could help reveal any problems.

But think about when t could be the name of a variable, and you want to 
construct the tuple (t,t,t):

  ///t t t t

That already looks a little odd. And when the /// is omitted:

  t t t t

Is that one tuple of (t,t,t), or a tuple of (t,(t))?


Also, is ///t ///t ///t a b c allowed, or does it have to be split 
across lines? If it is allowed, then it's not clear to which tuple b and 
c belong to, or even a, if an empty tuple is allowed.

I think this syntax is ambiguous; you need a more rigorous 
specification. (How will it parse ///.3 4 5 for example?)

> So I can change types of all child nodes with one keystroke.

Suppose you only wanted to change the top one?

> 
>>
>> The ///d dictionary example is ambiguous: can you have more than one
>> key:value per line or not? If so, it would look like this:
>>
>>    ///d "a" "b" "c" "d" "e" "f"
> 
> ///d   "a" "b"    "c" "d"    "e" "f"
> 
> Now better? :-)

Not really. Suppose one got accidentally missed out, and there was some 
spurious name at the end, so that you had this (dispensing with quotes, 
these are variables):

    ///d a b c e f x

The pairing is a:b, c:e, f:x rather the a:b, c:d, e:f that was intended 
with the x being an error. Use of : and , add useful redundancy. It's 
not clear whether:

   ///d a b
     c e
     f x

is allowed (I don't know what the terminating conditions are), but in a 
very long dict literal, it's easy to get confused.


I think this is an interesting first draft of an idea, but it doesn't 
seem rigorous. And people don't like that triple stroke prefix, or those 
single letter codes (why not just use 'tuple', 'list', 'dict')?

For example, here is a proposal I've just made up for a similar idea, 
but to make such constructors obey similar rules to Python blocks:

  tuple:
      10
      20
      30

  list:
      list:
          10
          tuple: 5,6,7
          30
      "forty"
      "fifty"

So, the keyword prefixes are followed by ":"; entities can follow on the 
same line, but using "," rather than ";", and the end of a sequence is 
just like the end of a 'suite'.

But even here there is ambiguity: the '5,6,7' forms a tuple of its own 
in normal syntax, so these could be a tuple of one tuple of 3, rather 
than a tuple of 3. (I may need ";" here rather than ,")

-- 
bartc



From rhodri at kynesim.co.uk  Tue May 22 06:39:11 2018
From: rhodri at kynesim.co.uk (Rhodri James)
Date: Tue, 22 May 2018 11:39:11 +0100
Subject: Issue
In-Reply-To: <CAOpC7vPTonwPws_AAk8_GohQYL-eRLNOLrSZcECausBg5wxpAg@mail.gmail.com>
References: <CAOpC7vMGsexgb3Qk5GWyUnP9MTKkKJBtx+ADLJ7U-WW_jkn_-w@mail.gmail.com>
 <CAOpC7vPdz7J5tywt9oHWVgNTnmJi=hnSL716LVfSsSoG2JiFKg@mail.gmail.com>
 <CADrxXXnAT8M=UViVh8KOdDYrH9gJ9NWNxkTnRs1c4eXf99eS2g@mail.gmail.com>
 <CAOpC7vPTonwPws_AAk8_GohQYL-eRLNOLrSZcECausBg5wxpAg@mail.gmail.com>
Message-ID: <0033f013-9fdc-8c3e-d209-26048016b687@kynesim.co.uk>

[Re-ordered for comprehensibility.]

On 22/05/18 11:08, sujith.j Sjk wrote:
> On Tue, May 22, 2018 at 3:04 PM, Abdur-Rahmaan Janhangeer <
> arj.python at gmail.com> wrote:
>> On Tue, 22 May 2018, 10:28 sujith.j Sjk, <sujith.sjk at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> Am facing the below issue when starting pyton.
>>
 >> greetings,
 >>
 >> did you send a log file attached?
 >
 > yes

I'm afraid it didn't make it to us.  The mailing list strips off 
attachments.  Please copy and paste the error into your message, and 
we'll do our best to decode it for you.

-- 
Rhodri James *-* Kynesim Ltd


From subhabangalore at gmail.com  Tue May 22 09:51:55 2018
From: subhabangalore at gmail.com (subhabangalore at gmail.com)
Date: Tue, 22 May 2018 06:51:55 -0700 (PDT)
Subject: Problem of writing long list of lists file to csv
In-Reply-To: <mailman.14.1526984744.18022.python-list@python.org>
References: <ffcd7a19-6d07-42a3-86f8-9cc25a383081@googlegroups.com>
 <pe0r2k$nnq$1@blaine.gmane.org>
 <mailman.14.1526984744.18022.python-list@python.org>
Message-ID: <40d56f69-2a34-402e-83d9-70cc5ee6a0ae@googlegroups.com>

On Tuesday, May 22, 2018 at 3:55:58 PM UTC+5:30, Peter Otten wrote:
> 
> 
> >     lst2=lst1[:4]
> >     with open("my_csv.csv","wb") as f:
> >         writer = csv.writer(f)
> >         writer.writerows(lst2)
> > 
> > Here it is writing only the first four lists. 
> 
> Hint: look at the first line in the quotation above.

Thank you Sir. Sorry to disturb you. 


From rosuav at gmail.com  Tue May 22 10:25:59 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 23 May 2018 00:25:59 +1000
Subject: "Data blocks" syntax specification draft
In-Reply-To: <VeSMC.135109$ga6.33227@fx24.am4>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
Message-ID: <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>

On Tue, May 22, 2018 at 8:25 PM, bartc <bc at freeuk.com> wrote:
> Note that Python tuples don't always need a start symbol:
>
>    a = 10,20,30
>
> assigns a tuple to a.

The tuple has nothing to do with the parentheses, except for the
special case of the empty tuple. It's the comma.

ChrisA


From grant.b.edwards at gmail.com  Tue May 22 10:50:00 2018
From: grant.b.edwards at gmail.com (Grant Edwards)
Date: Tue, 22 May 2018 14:50:00 +0000 (UTC)
Subject: best way to remove leading zeros from a tuple like string
References: <189bca64-1c7e-459f-a8a2-59db0e1752f8@googlegroups.com>
 <pdsnm8$8vd$1@dont-email.me>
 <360b3420-92fa-4fb6-8d30-399f0cb26f3e@googlegroups.com>
 <CA+og5uoy08VUSEj6aM-BVmDx2MzO5_6oQ-fW0A6uQhvXy9UXPw@mail.gmail.com>
 <CA+og5uodUMytqKp+T+JcL_NHZLPoPnzO8TS4ik8XgZNQe3jtYg@mail.gmail.com>
 <CA+og5uqymZ23w0GVE-ZuQL9Ha8nmcxEm++WnmU2tOpwc5pazqg@mail.gmail.com>
 <2c2b7af6-8813-48ee-a135-8a4466458082@tjol.eu>
Message-ID: <pe1amo$16d$1@blaine.gmane.org>

On 2018-05-22, Thomas Jollans <tjol at tjol.eu> wrote:
> On 2018-05-20 23:54, Paul wrote:
>> you will find several useful sites where you can test regexes.  Regex
>> errors are very common, even after you have experience with them.
>
> What's the benefit of those compared to simply trying out the regex in a
> Python console?

Doesn't everybody have an executable file in their home directory
named "testit.py" which is continually morphed to test different
Python features?

-- 
Grant Edwards               grant.b.edwards        Yow! What's the MATTER
                                  at               Sid? ... Is your BEVERAGE
                              gmail.com            unsatisfactory?



From rosuav at gmail.com  Tue May 22 11:12:04 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 23 May 2018 01:12:04 +1000
Subject: best way to remove leading zeros from a tuple like string
In-Reply-To: <pe1amo$16d$1@blaine.gmane.org>
References: <189bca64-1c7e-459f-a8a2-59db0e1752f8@googlegroups.com>
 <pdsnm8$8vd$1@dont-email.me>
 <360b3420-92fa-4fb6-8d30-399f0cb26f3e@googlegroups.com>
 <CA+og5uoy08VUSEj6aM-BVmDx2MzO5_6oQ-fW0A6uQhvXy9UXPw@mail.gmail.com>
 <CA+og5uodUMytqKp+T+JcL_NHZLPoPnzO8TS4ik8XgZNQe3jtYg@mail.gmail.com>
 <CA+og5uqymZ23w0GVE-ZuQL9Ha8nmcxEm++WnmU2tOpwc5pazqg@mail.gmail.com>
 <2c2b7af6-8813-48ee-a135-8a4466458082@tjol.eu> <pe1amo$16d$1@blaine.gmane.org>
Message-ID: <CAPTjJmqAwziMyY-3aSH3XxmJ5nuQNXRSmxmLLkvnW7kdfEkLUw@mail.gmail.com>

On Wed, May 23, 2018 at 12:50 AM, Grant Edwards
<grant.b.edwards at gmail.com> wrote:
> On 2018-05-22, Thomas Jollans <tjol at tjol.eu> wrote:
>> On 2018-05-20 23:54, Paul wrote:
>>> you will find several useful sites where you can test regexes.  Regex
>>> errors are very common, even after you have experience with them.
>>
>> What's the benefit of those compared to simply trying out the regex in a
>> Python console?
>
> Doesn't everybody have an executable file in their home directory
> named "testit.py" which is continually morphed to test different
> Python features?
>

Certainly not! Mine is ~/tmp/runme.py in case I need other files with it.

:)

ChrisA


From ian.g.kelly at gmail.com  Tue May 22 11:22:16 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Tue, 22 May 2018 09:22:16 -0600
Subject: "Data blocks" syntax specification draft
In-Reply-To: <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
Message-ID: <CALwzid=z409FFgG-cBq=VO5u0sHC8J3hutwzn15vT_+fx0zv5A@mail.gmail.com>

On Tue, May 22, 2018 at 8:25 AM, Chris Angelico <rosuav at gmail.com> wrote:
> On Tue, May 22, 2018 at 8:25 PM, bartc <bc at freeuk.com> wrote:
>> Note that Python tuples don't always need a start symbol:
>>
>>    a = 10,20,30
>>
>> assigns a tuple to a.
>
> The tuple has nothing to do with the parentheses, except for the
> special case of the empty tuple. It's the comma.

Although, if the rule were really as simple as "commas make tuples",
then this would be a list containing a tuple: [1, 2, 3].

Curiously, parentheses are also sometimes required for iterable
unpacking. For example:

py> 1, 2, *range(3,5)
(1, 2, 3, 4)
py> d = {}
py> d[1, 2] = 42
py> d[1, 2, *range(3,5)] = 43
  File "<stdin>", line 1
    d[1, 2, *range(3,5)] = 43
            ^
SyntaxError: invalid syntax

py> def foo():
...   return 1, 2
...
py> foo()
(1, 2)

py> def foo():
...   return 1, 2, *range(3, 5)
  File "<stdin>", line 2
    return 1, 2, *range(3, 5)
                 ^
SyntaxError: invalid syntax

py> def foo():
...   yield 1, 2
...
py> list(foo())
[(1, 2)]
py> def foo():
...   yield 1, 2, *range(3, 5)
  File "<stdin>", line 2
    yield 1, 2, *range(3, 5)
                ^
SyntaxError: invalid syntax

py> for x in 1, 2: print(x)
...
1
2
py> for x in 1, 2, *range(3, 5): print(x)
  File "<stdin>", line 1
    for x in 1, 2, *range(3, 5): print(x)
                   ^
SyntaxError: invalid syntax


From ian.g.kelly at gmail.com  Tue May 22 11:27:38 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Tue, 22 May 2018 09:27:38 -0600
Subject: "Data blocks" syntax specification draft
In-Reply-To: <CALwzid=z409FFgG-cBq=VO5u0sHC8J3hutwzn15vT_+fx0zv5A@mail.gmail.com>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
 <CALwzid=z409FFgG-cBq=VO5u0sHC8J3hutwzn15vT_+fx0zv5A@mail.gmail.com>
Message-ID: <CALwzid=33LJGjw-YRgvAMABs9Dn9KwHUiaiOL0a_sZBdJaXg1w@mail.gmail.com>

On Tue, May 22, 2018 at 9:22 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Tue, May 22, 2018 at 8:25 AM, Chris Angelico <rosuav at gmail.com> wrote:
>> On Tue, May 22, 2018 at 8:25 PM, bartc <bc at freeuk.com> wrote:
>>> Note that Python tuples don't always need a start symbol:
>>>
>>>    a = 10,20,30
>>>
>>> assigns a tuple to a.
>>
>> The tuple has nothing to do with the parentheses, except for the
>> special case of the empty tuple. It's the comma.
>
> Although, if the rule were really as simple as "commas make tuples",
> then this would be a list containing a tuple: [1, 2, 3].
>
> Curiously, parentheses are also sometimes required for iterable
> unpacking. For example:

[SNIP]

> py> def foo():
> ...   yield 1, 2
> ...
> py> list(foo())
> [(1, 2)]
> py> def foo():
> ...   yield 1, 2, *range(3, 5)
>   File "<stdin>", line 2
>     yield 1, 2, *range(3, 5)
>                 ^
> SyntaxError: invalid syntax

Here's another case where parentheses are always required:

py> def foo():
...   yield from 1, 2
  File "<stdin>", line 2
    yield from 1, 2
                ^
SyntaxError: invalid syntax

This one might be explained by noting that "yield from" is actually an
expression and so it could be confusing as to whether this should be
equivalent to "yield from (1, 2)" or "(yield from 1), 2". But "yield"
has the same issue and does allow an unparenthesized tuple.


From rosuav at gmail.com  Tue May 22 11:34:58 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 23 May 2018 01:34:58 +1000
Subject: "Data blocks" syntax specification draft
In-Reply-To: <CALwzid=z409FFgG-cBq=VO5u0sHC8J3hutwzn15vT_+fx0zv5A@mail.gmail.com>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
 <CALwzid=z409FFgG-cBq=VO5u0sHC8J3hutwzn15vT_+fx0zv5A@mail.gmail.com>
Message-ID: <CAPTjJmpS=9Nxr2aRDPbUfF05C9zOsDCsDnBJC_7=8+dwXB42ww@mail.gmail.com>

On Wed, May 23, 2018 at 1:22 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Tue, May 22, 2018 at 8:25 AM, Chris Angelico <rosuav at gmail.com> wrote:
>> On Tue, May 22, 2018 at 8:25 PM, bartc <bc at freeuk.com> wrote:
>>> Note that Python tuples don't always need a start symbol:
>>>
>>>    a = 10,20,30
>>>
>>> assigns a tuple to a.
>>
>> The tuple has nothing to do with the parentheses, except for the
>> special case of the empty tuple. It's the comma.
>
> Although, if the rule were really as simple as "commas make tuples",
> then this would be a list containing a tuple: [1, 2, 3].

In an arbitrary expression, a comma between two expressions creates a
tuple. In other contexts, the comma has other meanings, which take
precedence:

* Separating a function's arguments (both at definition and call)
* Enumerating import targets and global/nonlocal names
* Separating an assertion from its message
* Listing multiple context managers
* And probably some that I've forgotten.

In those contexts, you can override the normal interpretation and
force the tuple by using parentheses, preventing it from being parsed
as something else, and making it instead a single expression:

print((1, 2)) # prints a tuple
print(1, 2) # prints two items

The comma is what makes the tuple, though, not the parentheses. The
parentheses merely prevent this from being something else.

> Curiously, parentheses are also sometimes required for iterable
> unpacking. For example:
>
> py> 1, 2, *range(3,5)
> (1, 2, 3, 4)
> py> d = {}
> py> d[1, 2] = 42
> py> d[1, 2, *range(3,5)] = 43
>   File "<stdin>", line 1
>     d[1, 2, *range(3,5)] = 43
>             ^
> SyntaxError: invalid syntax

I'm not sure what you mean about the parentheses here. AIUI iterable
unpacking simply isn't supported inside subscripting. If that's an
actual problem anywhere, I'm sure it could be added :)

> py> def foo():
> ...   return 1, 2
> ...
> py> foo()
> (1, 2)
>
> py> def foo():
> ...   return 1, 2, *range(3, 5)
>   File "<stdin>", line 2
>     return 1, 2, *range(3, 5)
>                  ^
> SyntaxError: invalid syntax

That's a slightly curious case, since it's definitely being parsed the
same way. PEP 448 gives precedence for adding this sort of thing, if
anyone feels like digging into it. You may find that there's some
ambiguity somewhere in the unparenthesized version.

> py> def foo():
> ...   yield 1, 2
> ...
> py> list(foo())
> [(1, 2)]
> py> def foo():
> ...   yield 1, 2, *range(3, 5)
>   File "<stdin>", line 2
>     yield 1, 2, *range(3, 5)
>                 ^
> SyntaxError: invalid syntax

That's the exact same thing as the 'return' example, so it'll behave
the same way.

> py> for x in 1, 2: print(x)
> ...
> 1
> 2
> py> for x in 1, 2, *range(3, 5): print(x)
>   File "<stdin>", line 1
>     for x in 1, 2, *range(3, 5): print(x)
>                    ^
> SyntaxError: invalid syntax

In fact, I think probably all four of your examples would behave the
same way. So if you want to push for the change, go for it :)

ChrisA


From ian.g.kelly at gmail.com  Tue May 22 11:43:55 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Tue, 22 May 2018 09:43:55 -0600
Subject: "Data blocks" syntax specification draft
In-Reply-To: <CAPTjJmpS=9Nxr2aRDPbUfF05C9zOsDCsDnBJC_7=8+dwXB42ww@mail.gmail.com>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
 <CALwzid=z409FFgG-cBq=VO5u0sHC8J3hutwzn15vT_+fx0zv5A@mail.gmail.com>
 <CAPTjJmpS=9Nxr2aRDPbUfF05C9zOsDCsDnBJC_7=8+dwXB42ww@mail.gmail.com>
Message-ID: <CALwzidnW5=rpSkDWduHnnjE4FY69VR5gR6Gq48tQQRE49GcHkA@mail.gmail.com>

On Tue, May 22, 2018 at 9:34 AM, Chris Angelico <rosuav at gmail.com> wrote:
> On Wed, May 23, 2018 at 1:22 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
>> On Tue, May 22, 2018 at 8:25 AM, Chris Angelico <rosuav at gmail.com> wrote:
>>> On Tue, May 22, 2018 at 8:25 PM, bartc <bc at freeuk.com> wrote:
>>>> Note that Python tuples don't always need a start symbol:
>>>>
>>>>    a = 10,20,30
>>>>
>>>> assigns a tuple to a.
>>>
>>> The tuple has nothing to do with the parentheses, except for the
>>> special case of the empty tuple. It's the comma.
>>
>> Although, if the rule were really as simple as "commas make tuples",
>> then this would be a list containing a tuple: [1, 2, 3].
>
> In an arbitrary expression, a comma between two expressions creates a
> tuple. In other contexts, the comma has other meanings, which take
> precedence:
>
> * Separating a function's arguments (both at definition and call)
> * Enumerating import targets and global/nonlocal names
> * Separating an assertion from its message
> * Listing multiple context managers
> * And probably some that I've forgotten.
>
> In those contexts, you can override the normal interpretation and
> force the tuple by using parentheses, preventing it from being parsed
> as something else, and making it instead a single expression:
>
> print((1, 2)) # prints a tuple
> print(1, 2) # prints two items
>
> The comma is what makes the tuple, though, not the parentheses. The
> parentheses merely prevent this from being something else.

In other words, the rule is not really as simple as "commas make
tuples". I stand by what I wrote.

>> Curiously, parentheses are also sometimes required for iterable
>> unpacking. For example:
>>
>> py> 1, 2, *range(3,5)
>> (1, 2, 3, 4)
>> py> d = {}
>> py> d[1, 2] = 42
>> py> d[1, 2, *range(3,5)] = 43
>>   File "<stdin>", line 1
>>     d[1, 2, *range(3,5)] = 43
>>             ^
>> SyntaxError: invalid syntax
>
> I'm not sure what you mean about the parentheses here. AIUI iterable
> unpacking simply isn't supported inside subscripting. If that's an
> actual problem anywhere, I'm sure it could be added :)

Of course it's supported:

py> d = {}
py> d[(1, 2, *range(3, 5))] = 43
py> d
{(1, 2, 3, 4): 43}

Works just fine. But take out the parentheses and you get the SyntaxError.


From rosuav at gmail.com  Tue May 22 11:57:13 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 23 May 2018 01:57:13 +1000
Subject: "Data blocks" syntax specification draft
In-Reply-To: <CALwzidnW5=rpSkDWduHnnjE4FY69VR5gR6Gq48tQQRE49GcHkA@mail.gmail.com>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
 <CALwzid=z409FFgG-cBq=VO5u0sHC8J3hutwzn15vT_+fx0zv5A@mail.gmail.com>
 <CAPTjJmpS=9Nxr2aRDPbUfF05C9zOsDCsDnBJC_7=8+dwXB42ww@mail.gmail.com>
 <CALwzidnW5=rpSkDWduHnnjE4FY69VR5gR6Gq48tQQRE49GcHkA@mail.gmail.com>
Message-ID: <CAPTjJmq1+v2XX=ZEM7nzg1FjKuLHcRY-L9LCeK+Z9F=U=C47iQ@mail.gmail.com>

On Wed, May 23, 2018 at 1:43 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Tue, May 22, 2018 at 9:34 AM, Chris Angelico <rosuav at gmail.com> wrote:
>> On Wed, May 23, 2018 at 1:22 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
>>> On Tue, May 22, 2018 at 8:25 AM, Chris Angelico <rosuav at gmail.com> wrote:
>>>> On Tue, May 22, 2018 at 8:25 PM, bartc <bc at freeuk.com> wrote:
>>>>> Note that Python tuples don't always need a start symbol:
>>>>>
>>>>>    a = 10,20,30
>>>>>
>>>>> assigns a tuple to a.
>>>>
>>>> The tuple has nothing to do with the parentheses, except for the
>>>> special case of the empty tuple. It's the comma.
>>>
>>> Although, if the rule were really as simple as "commas make tuples",
>>> then this would be a list containing a tuple: [1, 2, 3].
>>
>> In an arbitrary expression, a comma between two expressions creates a
>> tuple. In other contexts, the comma has other meanings, which take
>> precedence:
>>
>> * Separating a function's arguments (both at definition and call)
>> * Enumerating import targets and global/nonlocal names
>> * Separating an assertion from its message
>> * Listing multiple context managers
>> * And probably some that I've forgotten.
>>
>> In those contexts, you can override the normal interpretation and
>> force the tuple by using parentheses, preventing it from being parsed
>> as something else, and making it instead a single expression:
>>
>> print((1, 2)) # prints a tuple
>> print(1, 2) # prints two items
>>
>> The comma is what makes the tuple, though, not the parentheses. The
>> parentheses merely prevent this from being something else.
>
> In other words, the rule is not really as simple as "commas make
> tuples". I stand by what I wrote.

Neither of us is wrong here. "Commas make tuples" is a useful
oversimplification in the same way that "asterisk means
multiplication" is. The asterisk has other meanings in specific
contexts (eg unpacking), but outside of those contexts, it means
multiplication.

ChrisA


From bc at freeuk.com  Tue May 22 13:51:30 2018
From: bc at freeuk.com (bartc)
Date: Tue, 22 May 2018 18:51:30 +0100
Subject: "Data blocks" syntax specification draft
In-Reply-To: <mailman.18.1526999168.18022.python-list@python.org>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
 <mailman.18.1526999168.18022.python-list@python.org>
Message-ID: <yMYMC.220721$oo.45532@fx35.am4>

On 22/05/2018 15:25, Chris Angelico wrote:
> On Tue, May 22, 2018 at 8:25 PM, bartc <bc at freeuk.com> wrote:
>> Note that Python tuples don't always need a start symbol:
>>
>>     a = 10,20,30
>>
>> assigns a tuple to a.
> 
> The tuple has nothing to do with the parentheses, except for the
> special case of the empty tuple. It's the comma.

No? Take these:

  a = (10,20,30)
  a = [10,20,30]
  a = {10,20,30}

If you print type(a) after each, only one of them is a tuple - the one 
with the round brackets.

The 10,20,30 in those other contexts doesn't create a tuple, nor does it 
here:

   f(10,20,30)

Or here:

   def g(a,b,c):

Or here in Python 2:

   print 10,20,30

and no doubt in a few other cases. It's just that special case I 
highlighted where an unbracketed sequence of expressions yields a tuple.

The comma is just generally used to separate expressions, it's not 
specific to tuples.

-- 
bart


From rosuav at gmail.com  Tue May 22 14:03:17 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 23 May 2018 04:03:17 +1000
Subject: "Data blocks" syntax specification draft
In-Reply-To: <yMYMC.220721$oo.45532@fx35.am4>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
 <mailman.18.1526999168.18022.python-list@python.org>
 <yMYMC.220721$oo.45532@fx35.am4>
Message-ID: <CAPTjJmr-DYvVh-b8K1+CqVQ5ZQ0MTMFH6ueTq6Fsaj8MshN94Q@mail.gmail.com>

On Wed, May 23, 2018 at 3:51 AM, bartc <bc at freeuk.com> wrote:
> On 22/05/2018 15:25, Chris Angelico wrote:
>>
>> On Tue, May 22, 2018 at 8:25 PM, bartc <bc at freeuk.com> wrote:
>>>
>>> Note that Python tuples don't always need a start symbol:
>>>
>>>     a = 10,20,30
>>>
>>> assigns a tuple to a.
>>
>>
>> The tuple has nothing to do with the parentheses, except for the
>> special case of the empty tuple. It's the comma.
>
>
> No? Take these:
>
>  a = (10,20,30)
>  a = [10,20,30]
>  a = {10,20,30}
>
> If you print type(a) after each, only one of them is a tuple - the one with
> the round brackets.

And this isn't a tuple either:

import os, sys, math

If you've actually read the other emails in this thread, you'll see
that this has already been said.

ChrisA


From nikos.at.superhost at gmail.com  Tue May 22 14:29:44 2018
From: nikos.at.superhost at gmail.com (=?UTF-8?B?zp3Or866zr/Pgg==?=)
Date: Tue, 22 May 2018 11:29:44 -0700 (PDT)
Subject: Target WSGI script cannot be loaded as Python module.
Message-ID: <e1da20e9-ba1f-41d1-b5ba-56f83377ca4d@googlegroups.com>

Hello all,

Iam tryign to run a bootle script iw rote as wsgi app and iam gettign the follwing eroor.

===============================================================
[Tue May 22 06:49:45.763808 2018] [:error] [pid 24298] [client 46.103.59.37:14500] mod_wsgi (pid=24298): Target WSGI script '/home/nikos/public_html/app.py' cannot be loaded as Python module.
[Tue May 22 06:49:45.763842 2018] [:error] [pid 24298] [client 46.103.59.37:14500] mod_wsgi (pid=24298): Exception occurred processing WSGI script '/home/nikos/public_html/app.py'.
[Tue May 22 06:49:45.763872 2018] [:error] [pid 24298] [client 46.103.59.37:14500] Traceback (most recent call last):
[Tue May 22 06:49:45.763911 2018] [:error] [pid 24298] [client 46.103.59.37:14500]   File "/home/nikos/public_html/app.py", line 4, in <module>
[Tue May 22 06:49:45.763951 2018] [:error] [pid 24298] [client 46.103.59.37:14500]     import re, os, sys, socket, time, datetime, locale, codecs, random, smtplib, subprocess, geoip2.database, bottle_pymysql
[Tue May 22 06:49:45.763976 2018] [:error] [pid 24298] [client 46.103.59.37:14500] ImportError: No module named geoip2.database
===============================================================

He is the relative httpd-vhosts.conf

<VirtualHost superhost:*>
    ServerName superhost.gr

    WSGIDaemonProcess public_html user=nikos group=nikos processes=1 threads=5
    WSGIScriptAlias / /home/nikos/public_html/app.py

    ProxyPass / http://superhost.gr:5000/
    ProxyPassReverse / http://superhost:5000/


    <Directory /home/nikos/public_html>
        WSGIProcessGroup public_html
        WSGIApplicationGroup %{GLOBAL}
        WSGIScriptReloading On

        Options -Indexes +IncludesNOEXEC +SymLinksIfOwnerMatch +ExecCGI

        AddHandler cgi-script .cgi .py
        AddHandler wsgi-script .wsgi .py

        AllowOverride None
        Require all granted
    </Directory>
</VirtualHost>


Any ideas as to why iam getting the above error although i have python36 isntalled along with all modules? why can it find it?


From abrault at mapgears.com  Tue May 22 15:55:33 2018
From: abrault at mapgears.com (Alexandre Brault)
Date: Tue, 22 May 2018 15:55:33 -0400
Subject: Target WSGI script cannot be loaded as Python module.
In-Reply-To: <e1da20e9-ba1f-41d1-b5ba-56f83377ca4d@googlegroups.com>
References: <e1da20e9-ba1f-41d1-b5ba-56f83377ca4d@googlegroups.com>
Message-ID: <66f5581a-f3e1-7b2d-fca7-83b3701f1719@mapgears.com>

On 2018-05-22 02:29 PM, ????? wrote:
> Hello all,
>
> Iam tryign to run a bootle script iw rote as wsgi app and iam gettign the follwing eroor.
>
> ===============================================================
> [Tue May 22 06:49:45.763808 2018] [:error] [pid 24298] [client 46.103.59.37:14500] mod_wsgi (pid=24298): Target WSGI script '/home/nikos/public_html/app.py' cannot be loaded as Python module.
> [Tue May 22 06:49:45.763842 2018] [:error] [pid 24298] [client 46.103.59.37:14500] mod_wsgi (pid=24298): Exception occurred processing WSGI script '/home/nikos/public_html/app.py'.
> [Tue May 22 06:49:45.763872 2018] [:error] [pid 24298] [client 46.103.59.37:14500] Traceback (most recent call last):
> [Tue May 22 06:49:45.763911 2018] [:error] [pid 24298] [client 46.103.59.37:14500]   File "/home/nikos/public_html/app.py", line 4, in <module>
> [Tue May 22 06:49:45.763951 2018] [:error] [pid 24298] [client 46.103.59.37:14500]     import re, os, sys, socket, time, datetime, locale, codecs, random, smtplib, subprocess, geoip2.database, bottle_pymysql
> [Tue May 22 06:49:45.763976 2018] [:error] [pid 24298] [client 46.103.59.37:14500] ImportError: No module named geoip2.database
> ===============================================================
>
> He is the relative httpd-vhosts.conf
>
> <VirtualHost superhost:*>
>     ServerName superhost.gr
>
>     WSGIDaemonProcess public_html user=nikos group=nikos processes=1 threads=5
>     WSGIScriptAlias / /home/nikos/public_html/app.py
>
>     ProxyPass / http://superhost.gr:5000/
>     ProxyPassReverse / http://superhost:5000/
>
>
>     <Directory /home/nikos/public_html>
>         WSGIProcessGroup public_html
>         WSGIApplicationGroup %{GLOBAL}
>         WSGIScriptReloading On
>
>         Options -Indexes +IncludesNOEXEC +SymLinksIfOwnerMatch +ExecCGI
>
>         AddHandler cgi-script .cgi .py
>         AddHandler wsgi-script .wsgi .py
>
>         AllowOverride None
>         Require all granted
>     </Directory>
> </VirtualHost>
>
>
> Any ideas as to why iam getting the above error although i have python36 isntalled along with all modules? why can it find it?
How did you install geoip2? Was it by any chance in a virtual
environment? If it was, you need to tell mod_wsgi to use this virtual
environment; otherwise, it'll use the global environment that probably
doesn't have geoip2 installed

Alex


From hjp-python at hjp.at  Tue May 22 15:59:47 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Tue, 22 May 2018 21:59:47 +0200
Subject: Spam levels.
In-Reply-To: <pdupd4$6ra$1@blaine.gmane.org>
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <5b027ca9$0$619$65785112@news.neostrada.pl>
 <20180521144801.GB7508@equipaje> <pdupd4$6ra$1@blaine.gmane.org>
Message-ID: <20180522195947.hrntcm47wjzvdbcr@hjp.at>

On 2018-05-21 15:42:28 +0000, Grant Edwards wrote:
> I switched from Usenet to Gmane mainly because references headers are
> bit more consistent on Gmane, so threading works somewhat better.

This is interesting, because Gmane was the reason I switched from
reading on usenet to reading the mailinglist: Every article coming
through the Gmane gateway had broken headers, which completely messed up
threading (It looked like Gmane was replacing Message-Ids with their
own). I haven't checked recently whether that is still the case.

On the mailing-list threading seems to work.

        hp


-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180522/aec04c9a/attachment.sig>

From hjp-python at hjp.at  Tue May 22 16:13:38 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Tue, 22 May 2018 22:13:38 +0200
Subject: what does := means simply?
In-Reply-To: <sr23gdhmq107n2fro4gcgj4pfjo4ii6j9d@4ax.com>
References: <CAPTjJmq=5tt-BXXAYq7jbqCv4nAMpfP+wf-0QxMkkNk5802g5A@mail.gmail.com>
 <mailman.225.1526693200.2761.python-list@python.org>
 <V3TLC.289245$CH6.116439@fx01.am4>
 <20180519113317.w7ijjsyaallwp2ud@hjp.at>
 <mailman.232.1526729599.2761.python-list@python.org>
 <BZULC.164040$ny5.143736@fx17.am4>
 <20180520091942.lr4ivj43hdnr3pb5@hjp.at>
 <mailman.252.1526807990.2761.python-list@python.org>
 <m7dMC.329719$nr7.291374@fx31.am4>
 <sr23gdhmq107n2fro4gcgj4pfjo4ii6j9d@4ax.com>
Message-ID: <20180522201338.xe5sywp7en5bevk6@hjp.at>

On 2018-05-20 11:37:14 -0400, Dennis Lee Bieber wrote:
> On Sun, 20 May 2018 12:38:59 +0100, bartc <bc at freeuk.com> declaimed the
> following:
> >Then the /same software/ probably wouldn't work anywhere else. I mean 
> >taking source which doesn't know or care about what system its on, and 
> >that operates on a ppm file downloaded from the internet.
> 
> 	And software that handles binary PPM on a big-endian system probably
> won't run on a little-endian system, if said PPM is using a maxval >255
> (meaning each R,G,B takes up two bytes, and said bytes would be seen in
> reverse order when moving from one system to the other).

The byte order in PPM files is well-defined.

It is trivial to write a portable C program which reads raw PPM files.
And by "portable" I mean that the same program works on big- or little
endian systems, on ASCII or EBCDIC systems, on systems where 1 byte is
more than 8 bits (as long as the file stores still one octet per byte),
etc.

        hp


-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180522/9c37bac7/attachment.sig>

From grant.b.edwards at gmail.com  Tue May 22 16:42:43 2018
From: grant.b.edwards at gmail.com (Grant Edwards)
Date: Tue, 22 May 2018 20:42:43 +0000 (UTC)
Subject: Spam levels.
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <5b027ca9$0$619$65785112@news.neostrada.pl>
 <20180521144801.GB7508@equipaje> <pdupd4$6ra$1@blaine.gmane.org>
 <20180522195947.hrntcm47wjzvdbcr@hjp.at>
Message-ID: <pe1vc3$sd$2@blaine.gmane.org>

On 2018-05-22, Peter J. Holzer <hjp-python at hjp.at> wrote:
> On 2018-05-21 15:42:28 +0000, Grant Edwards wrote:
>> I switched from Usenet to Gmane mainly because references headers are
>> bit more consistent on Gmane, so threading works somewhat better.
>
> This is interesting, because Gmane was the reason I switched from
> reading on usenet to reading the mailinglist: Every article coming
> through the Gmane gateway had broken headers, which completely messed up
> threading (It looked like Gmane was replacing Message-Ids with their
> own). I haven't checked recently whether that is still the case.
>
> On the mailing-list threading seems to work.

I've never tried reading the mailing list directly (I'm not willing to
give up slrn), but the last time I ran NNTP threading tests (I refuse
to admin how much time I spent writing a Python app to do that), My
Usenet feed was noticably worse than Gmane.  Gmane had a fair amount
of breakage as well, but was better than Usenet.

-- 
Grant Edwards               grant.b.edwards        Yow! Did YOU find a
                                  at               DIGITAL WATCH in YOUR box
                              gmail.com            of VELVEETA?



From hjp-python at hjp.at  Tue May 22 16:52:06 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Tue, 22 May 2018 22:52:06 +0200
Subject: what does := means simply?
In-Reply-To: <9c4a111d-2eac-078f-38e9-0db1e177555a@Damon-Family.org>
References: <mailman.240.1526759265.2761.python-list@python.org>
 <Ok1MC.165333$ny5.163789@fx17.am4>
 <2bg1gd55l010vujodr58g9uil0uvrogf5d@4ax.com>
 <mailman.244.1526776756.2761.python-list@python.org>
 <xY3MC.167349$7B3.74141@fx13.am4>
 <ktj1gdt31c2e6r427uhtnre4ohusm9v15d@4ax.com>
 <mailman.247.1526781497.2761.python-list@python.org>
 <FJcMC.34772$463.31746@fx21.am4>
 <kn53gd5rnbqgmjdc6243p3jooia0hpsno7@4ax.com>
 <9c4a111d-2eac-078f-38e9-0db1e177555a@Damon-Family.org>
Message-ID: <20180522205206.7ap5tsbo72xphkcf@hjp.at>

On 2018-05-20 16:36:12 -0400, Richard Damon wrote:
> 2) Try to maximize portability by not only looking at the specs, but
> also common implementations, and choosing the options that maximize the
> acceptability of your output to tools that don't fully meet the specs.
> Also, if a common implementation generates something not quite to the
> standard, try to make it so you can accept that output too.

This is the well-known "be conservative in what you send and liberal in
what you accept" principle. 

It has fallen into disfavour over the last decade or so. There are
several reasons:

* Being liberal in what you accept is problematic because you are
  accepting input which has no specified meaning and interpret it as you
  see fit - but there is no guarantee that this is the interpretation
  that the sender intended. This may result in silent data loss. In many
  cases an error message is better.
* Accepting non-standard input is also problematic because such input is
  probably not well-tested. The code is much more likely to contain
  bugs, maybe even security-critical bugs.
* If some features of a spec are rarely used, programmers may not
  implement them. When they are needed, they won't work. A recent
  example is that the TLS working group found that they can't use the
  version number field to signal the version number because too many
  implementations got it wrong (I have no idea how that happened. We are
  already on the 6th version and all previous upgrades used the version
  field).

Of course, if a popular implementation has known bugs you may have no
choice but make concessions.

        hp


-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180522/8a799acc/attachment.sig>

From nikos.at.superhost at gmail.com  Tue May 22 16:52:30 2018
From: nikos.at.superhost at gmail.com (=?UTF-8?B?zp3Or866zr/Pgg==?=)
Date: Tue, 22 May 2018 13:52:30 -0700 (PDT)
Subject: Target WSGI script cannot be loaded as Python module.
In-Reply-To: <mailman.27.1527018942.18022.python-list@python.org>
References: <e1da20e9-ba1f-41d1-b5ba-56f83377ca4d@googlegroups.com>
 <66f5581a-f3e1-7b2d-fca7-83b3701f1719@mapgears.com>
 <mailman.27.1527018942.18022.python-list@python.org>
Message-ID: <34bc9890-90c9-473d-bd26-3f62264aa781@googlegroups.com>

?? ?????, 22 ????? 2018 - 10:55:54 ?.?. UTC+3, ? ??????? Alexandre Brault 
> > Any ideas as to why iam getting the above error although i have python36 isntalled along with all modules? why can it find it?
> How did you install geoip2? Was it by any chance in a virtual
> environment? If it was, you need to tell mod_wsgi to use this virtual
> environment; otherwise, it'll use the global environment that probably
> doesn't have geoip2 installed

I have both python installed in parallel.
python2.7 and python3.6

I have installed the modules as

pip3.6 install bottle bottle-pymysql geopip2
and they were installed successfully.

I dont know why error log is complaining that it cnanot see the modules.



From hjp-python at hjp.at  Tue May 22 17:23:37 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Tue, 22 May 2018 23:23:37 +0200
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <20180520134354.GB2192@hermes.hilbert.loc>
References: <1a7951080901290824p424caee3jb74b1343ce884916@mail.gmail.com>
 <ec96e1390901290849g507dcb17tf2372e573f4a5bb5@mail.gmail.com>
 <mailman.8292.1233248983.3487.python-list@python.org>
 <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>
 <CANc-5Uxy8T+LKC=vw6ujxnY4K+yPpA1U7-boLXSYSeDbx8DgeQ@mail.gmail.com>
 <mailman.243.1526773687.2761.python-list@python.org>
 <27ef2bfb-e3ed-495c-bb98-f71e502d412a@googlegroups.com>
 <20180520134354.GB2192@hermes.hilbert.loc>
Message-ID: <20180522212337.cvtbh32tydvaft4r@hjp.at>

On 2018-05-20 15:43:54 +0200, Karsten Hilbert wrote:
> On Sun, May 20, 2018 at 04:59:12AM -0700, bellcanadardp at gmail.com wrote:
> 
> > On Saturday, 19 May 2018 19:48:20 UTC-4, Skip Montanaro  wrote:
> > > As Chris indicated, you'll have to figure out the correct encoding. You
> > > might want to check out the chardet module (available on PyPI, I believe)
> > > and see if it can come up with a better guess. I imagine there are other
> > > encoding guessers out there. That's just one I'm familiar with.
> > 
> > thank you for the reply, but how exactly am i supposed to find oout what is the correct encodeing??
> 
> One CAN NOT.
> 
> The best you can do is to go ask the canonical source of the
> file what encoding the file is _supposed_ to be in.

I disagree on both counts.

1) For any given file it is almost always possible to find the correct
   encoding (or *a* correct encoding, as there may be more than one).

   This may require domain-specific knowledge (e.g. it may be necessary
   to recognize the human language and know at least some distinctive
   words, or to know some special symbols likely to be used in a data
   file), and it almost always takes a bit of detective work and trial
   and error. But I don't think I ever encountered a file where I
   couldn't figure out the encoding.

   (If you have several files in the same encoding, it may not be
   possible to figure out the encoding from a subset of them. For
   example, the files may all be in ISO-8859-2, but the subset you have
   contains only characters <= 0x7F. But if you have several files, they
   may not all be the same encoding, either).

2) The canonical source of the file may not know. This is quite frequent
   when the source is some non-technical person. Then you get answers
   like "it's ASCII" (although the file contains umlauts, which aren't
   in ASCII) or "it's ANSI" (which isn't an encoding, although Windows
   pretends it is). Or they may not be aware that the file is converted
   somewhere in the pipeline, to that the file they generated isn't
   actually the file you received. So ask (or check the docs), but
   verify!

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180522/22dd0b5b/attachment.sig>

From rosuav at gmail.com  Tue May 22 17:38:27 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 23 May 2018 07:38:27 +1000
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <20180522212337.cvtbh32tydvaft4r@hjp.at>
References: <1a7951080901290824p424caee3jb74b1343ce884916@mail.gmail.com>
 <ec96e1390901290849g507dcb17tf2372e573f4a5bb5@mail.gmail.com>
 <mailman.8292.1233248983.3487.python-list@python.org>
 <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>
 <CANc-5Uxy8T+LKC=vw6ujxnY4K+yPpA1U7-boLXSYSeDbx8DgeQ@mail.gmail.com>
 <mailman.243.1526773687.2761.python-list@python.org>
 <27ef2bfb-e3ed-495c-bb98-f71e502d412a@googlegroups.com>
 <20180520134354.GB2192@hermes.hilbert.loc>
 <20180522212337.cvtbh32tydvaft4r@hjp.at>
Message-ID: <CAPTjJmqP86iiuoXrB0r1M-7U9kM8P5Xev=mEtLwmFr5zKV45AA@mail.gmail.com>

On Wed, May 23, 2018 at 7:23 AM, Peter J. Holzer <hjp-python at hjp.at> wrote:
>> The best you can do is to go ask the canonical source of the
>> file what encoding the file is _supposed_ to be in.
>
> I disagree on both counts.
>
> 1) For any given file it is almost always possible to find the correct
>    encoding (or *a* correct encoding, as there may be more than one).

You can find an encoding which is capable of decoding a file. That's
not the same thing.

>    This may require domain-specific knowledge (e.g. it may be necessary
>    to recognize the human language and know at least some distinctive
>    words, or to know some special symbols likely to be used in a data
>    file), and it almost always takes a bit of detective work and trial
>    and error. But I don't think I ever encountered a file where I
>    couldn't figure out the encoding.

Look up the old classic "bush hid the facts" hack with Windows
Notepad. A pure ASCII file that got misdetected based on the byte
patterns in it.

If you restrict yourself to ASCII-compatible eight-bit encodings, you
MAY be able to figure out what something is. (I have that exact
situation when parsing subtitles files.) Bizarre constructs like
"Tuuleen j?iseen m? nostan p??n" are a strong indication that the
encoding is wrong - if most of a word is ASCII, it's likely that the
non-ASCII bytes represent accented characters, not characters from a
completely different alphabet. But there are a number of annoyingly
similar encodings around, where a large number of the mappings are the
same, but you're left with just a few ambiguous bytes.

And if you're considering non-ASCII-compatible encodings, things get a
lot harder. UTF-16 can represent large slabs of Chinese text using the
same bytes that would represent alphanumeric characters; so how can
you distinguish it from base-64?

I have encountered MANY files where I couldn't figure out the
encoding. Some of them were quite possibly in ancient encodings (some
had CR line endings), some were ambiguous, and on multiple occasions,
I've had to deal with files that had more than one encoding in the
same block of content. (Or more frequently, not files but socket
connections. Same difference.) So no, you cannot always figure out a
file's encoding from its contents. Because that will, on some
occasions, violate the laws of physics - granted, that's merely a
misdemeanour in some states.

ChrisA


From grant.b.edwards at gmail.com  Tue May 22 17:52:16 2018
From: grant.b.edwards at gmail.com (Grant Edwards)
Date: Tue, 22 May 2018 21:52:16 +0000 (UTC)
Subject: Tkinter and root vs. Wayland
Message-ID: <pe23eg$kl4$1@blaine.gmane.org>

For a couple decades now, I've been distributing a couple smallish
Tkinter applications that need to run as root for a variety of reasons
(raw Ethernet access, starting/stopping daemons, loading and unloading
kernel modules, reading and writing config files that are owned by
root).

As part of RedHat's switch to Wayland, they've decided that GUI X11
apps running as root will no longer be allowed to connect to the
Wayland desktop server/compositor/whatever-it's-called.  When it was
pointed out to RedHat that this will break lots of applications, the
official word from on high is that all GUI apps requiring root
privileges need to be redesigned so that their GUI is running as a
normal user.

How does one do that in a Tkinter app?  Do I need to start as root and
fork a process that drops privledges and starts Tkinter and then the
two processes communicate via sockets or Posix queues or whatnot?

Can Python multiprocessing be used in this way?

-- 
Grant Edwards               grant.b.edwards        Yow! If our behavior is
                                  at               strict, we do not need fun!
                              gmail.com            



From hjp-python at hjp.at  Tue May 22 18:01:01 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Wed, 23 May 2018 00:01:01 +0200
Subject: Spam levels.
In-Reply-To: <pe1vc3$sd$2@blaine.gmane.org>
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <5b027ca9$0$619$65785112@news.neostrada.pl>
 <20180521144801.GB7508@equipaje> <pdupd4$6ra$1@blaine.gmane.org>
 <20180522195947.hrntcm47wjzvdbcr@hjp.at>
 <pe1vc3$sd$2@blaine.gmane.org>
Message-ID: <20180522220101.lvp6lsd7x77ndz2g@hjp.at>

On 2018-05-22 20:42:43 +0000, Grant Edwards wrote:
> On 2018-05-22, Peter J. Holzer <hjp-python at hjp.at> wrote:
> > On 2018-05-21 15:42:28 +0000, Grant Edwards wrote:
> >> I switched from Usenet to Gmane mainly because references headers are
> >> bit more consistent on Gmane, so threading works somewhat better.
> >
> > This is interesting, because Gmane was the reason I switched from
> > reading on usenet to reading the mailinglist: Every article coming
> > through the Gmane gateway had broken headers, which completely messed up
> > threading (It looked like Gmane was replacing Message-Ids with their
> > own). I haven't checked recently whether that is still the case.
> >
> > On the mailing-list threading seems to work.
> 
> I've never tried reading the mailing list directly (I'm not willing to
> give up slrn), but the last time I ran NNTP threading tests (I refuse
> to admin how much time I spent writing a Python app to do that), My
> Usenet feed was noticably worse than Gmane.  Gmane had a fair amount
> of breakage as well, but was better than Usenet.

I didn't read on Gmane. I read on my usenet server. But the broken
messages were all coming from Gmane. It is possible that the breakage
only occurs when Gmane passes the message to other Usenet servers,
although I have no idea how that could happen (frankly, I have no idea
why Gmane should replace message-ids at all - it just doesn't make
sense).

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180523/c8c252f7/attachment.sig>

From grant.b.edwards at gmail.com  Tue May 22 18:16:30 2018
From: grant.b.edwards at gmail.com (Grant Edwards)
Date: Tue, 22 May 2018 22:16:30 +0000 (UTC)
Subject: Spam levels.
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <5b027ca9$0$619$65785112@news.neostrada.pl>
 <20180521144801.GB7508@equipaje> <pdupd4$6ra$1@blaine.gmane.org>
 <20180522195947.hrntcm47wjzvdbcr@hjp.at> <pe1vc3$sd$2@blaine.gmane.org>
 <20180522220101.lvp6lsd7x77ndz2g@hjp.at>
Message-ID: <pe24ru$n0e$1@blaine.gmane.org>

On 2018-05-22, Peter J. Holzer <hjp-python at hjp.at> wrote:

> I didn't read on Gmane. I read on my usenet server. But the broken
> messages were all coming from Gmane. It is possible that the breakage
> only occurs when Gmane passes the message to other Usenet servers,
> although I have no idea how that could happen (frankly, I have no idea
> why Gmane should replace message-ids at all - it just doesn't make
> sense).

I never figured out exactly what the broken scenarios were nor did I
try to figure out which gateway was causing them.

Ignoring Google Groups, there are 9 possible combinations:

   Usenet <---[gateway]---> M-List <---[gateway]---> Gmane

 1. Usenet followup to M-List posting
 2. Usenet followup to Gmane posting
 3. Usenet followup to Usenet posting
 4. M-List followup to Usenet posting
 5. M-List followup to Gmane posting
 6. M-List followup to M-List posting
 7. Gmane  followup to Usenet posting
 8. Gmane  followup to M-List posting
 9. Gmane  followup to Gmane posting

Most of the combinations seem to work most of the time.  It looked
like there was at least 1 broken scenario when subscribed either via
Gmane or via "real" Usenet, but it's pretty difficult to glean the the
signal from the noise created by people with broken MUAs and/or NNTP
clients.

It's actually pretty impressive it all works as well as it does...

In any case, ignoring all postings from Google Groups is recommended.

-- 
Grant Edwards               grant.b.edwards        Yow! Today, THREE WINOS
                                  at               from DETROIT sold me a
                              gmail.com            framed photo of TAB HUNTER
                                                   before his MAKEOVER!



From hjp-python at hjp.at  Tue May 22 18:31:03 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Wed, 23 May 2018 00:31:03 +0200
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <CAPTjJmqP86iiuoXrB0r1M-7U9kM8P5Xev=mEtLwmFr5zKV45AA@mail.gmail.com>
References: <1a7951080901290824p424caee3jb74b1343ce884916@mail.gmail.com>
 <ec96e1390901290849g507dcb17tf2372e573f4a5bb5@mail.gmail.com>
 <mailman.8292.1233248983.3487.python-list@python.org>
 <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>
 <CANc-5Uxy8T+LKC=vw6ujxnY4K+yPpA1U7-boLXSYSeDbx8DgeQ@mail.gmail.com>
 <mailman.243.1526773687.2761.python-list@python.org>
 <27ef2bfb-e3ed-495c-bb98-f71e502d412a@googlegroups.com>
 <20180520134354.GB2192@hermes.hilbert.loc>
 <20180522212337.cvtbh32tydvaft4r@hjp.at>
 <CAPTjJmqP86iiuoXrB0r1M-7U9kM8P5Xev=mEtLwmFr5zKV45AA@mail.gmail.com>
Message-ID: <20180522223103.fmym5wsmvr7vaua3@hjp.at>

On 2018-05-23 07:38:27 +1000, Chris Angelico wrote:
> On Wed, May 23, 2018 at 7:23 AM, Peter J. Holzer <hjp-python at hjp.at> wrote:
> >> The best you can do is to go ask the canonical source of the
> >> file what encoding the file is _supposed_ to be in.
> >
> > I disagree on both counts.
> >
> > 1) For any given file it is almost always possible to find the correct
> >    encoding (or *a* correct encoding, as there may be more than one).
> 
> You can find an encoding which is capable of decoding a file. That's
> not the same thing.

If the result is correct, it is the same thing.

If I have an input file 

    4c 69 65 62 65 20 47 72 fc df 65 0a

and I decode it correctly to

    Liebe Gr??e

it doesn't matter whether I used ISO-8859-1 or ISO-8859-2. The mapping
for all bytes in the input file is the same in both encodings.


> >    This may require domain-specific knowledge (e.g. it may be necessary
> >    to recognize the human language and know at least some distinctive
> >    words, or to know some special symbols likely to be used in a data
> >    file), and it almost always takes a bit of detective work and trial
> >    and error. But I don't think I ever encountered a file where I
> >    couldn't figure out the encoding.
> 
> Look up the old classic "bush hid the facts" hack with Windows
> Notepad. A pure ASCII file that got misdetected based on the byte
> patterns in it.

And would you have made the same mistake as notepad? Nope, I'm quite
sure that you are able to recognize an ASCII file with an English
sentence as ASCII. You wouldn't even consider that it could be UTF-16LE.


> If you restrict yourself to ASCII-compatible eight-bit encodings, you
> MAY be able to figure out what something is.
[...]
> But there are a number of annoyingly similar encodings around, where a
> large number of the mappings are the same, but you're left with just a
> few ambiguous bytes.

They are rarely ambiguous if you speak the language.

> And if you're considering non-ASCII-compatible encodings, things get a
> lot harder. UTF-16 can represent large slabs of Chinese text using the
> same bytes that would represent alphanumeric characters; so how can
> you distinguish it from base-64?

I'll ask my Chinese colleague to read it. If he can read it, it's almost
certainly Chinese and not base-64.

As I said, domain knowledge may be necessary. If you are decoding a file
which may contain a Chinese text, you may have to know Chinese to check
whether the decoded text makes sense.

If your job is to figure out the encoding of files which you don't
understand (and hence can't check whether your results are correct) I
will concede that this is impossible.

> I have encountered MANY files where I couldn't figure out the
> encoding. Some of them were quite possibly in ancient encodings (some
> had CR line endings), some were ambiguous, and on multiple occasions,
> I've had to deal with files that had more than one encoding in the
> same block of content.

Well, files with multiple encodings break the assumption that there is
*one* correct encoding. While I have encountered such files, too (as
well as multi-encodings and random errors), I don't think we were
talking about that.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180523/483c5974/attachment.sig>

From rosuav at gmail.com  Tue May 22 18:43:02 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 23 May 2018 08:43:02 +1000
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <20180522223103.fmym5wsmvr7vaua3@hjp.at>
References: <1a7951080901290824p424caee3jb74b1343ce884916@mail.gmail.com>
 <ec96e1390901290849g507dcb17tf2372e573f4a5bb5@mail.gmail.com>
 <mailman.8292.1233248983.3487.python-list@python.org>
 <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>
 <CANc-5Uxy8T+LKC=vw6ujxnY4K+yPpA1U7-boLXSYSeDbx8DgeQ@mail.gmail.com>
 <mailman.243.1526773687.2761.python-list@python.org>
 <27ef2bfb-e3ed-495c-bb98-f71e502d412a@googlegroups.com>
 <20180520134354.GB2192@hermes.hilbert.loc>
 <20180522212337.cvtbh32tydvaft4r@hjp.at>
 <CAPTjJmqP86iiuoXrB0r1M-7U9kM8P5Xev=mEtLwmFr5zKV45AA@mail.gmail.com>
 <20180522223103.fmym5wsmvr7vaua3@hjp.at>
Message-ID: <CAPTjJmo5X-+v0RG5a-3KX4NVDpd_6hyjJHmnCf7t2An8H43tGA@mail.gmail.com>

On Wed, May 23, 2018 at 8:31 AM, Peter J. Holzer <hjp-python at hjp.at> wrote:
> On 2018-05-23 07:38:27 +1000, Chris Angelico wrote:
>> On Wed, May 23, 2018 at 7:23 AM, Peter J. Holzer <hjp-python at hjp.at> wrote:
>> >> The best you can do is to go ask the canonical source of the
>> >> file what encoding the file is _supposed_ to be in.
>> >
>> > I disagree on both counts.
>> >
>> > 1) For any given file it is almost always possible to find the correct
>> >    encoding (or *a* correct encoding, as there may be more than one).
>>
>> You can find an encoding which is capable of decoding a file. That's
>> not the same thing.
>
> If the result is correct, it is the same thing.
>
> If I have an input file
>
>     4c 69 65 62 65 20 47 72 fc df 65 0a
>
> and I decode it correctly to
>
>     Liebe Gr??e
>
> it doesn't matter whether I used ISO-8859-1 or ISO-8859-2. The mapping
> for all bytes in the input file is the same in both encodings.

Sure, but if you try it as ISO-8859-5 or  -7, you won't get an error,
but you also won't get that string. So it DOES matter.

ChrisA


From mikhailwas at gmail.com  Tue May 22 18:50:38 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Wed, 23 May 2018 01:50:38 +0300
Subject: "Data blocks" syntax specification draft
In-Reply-To: <pe0bn1$8ns$1@dont-email.me>
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
 <pdu324$l8j$1@blaine.gmane.org>
 <CAHiMU6cGz=X4LMcYac=_Us0+9ATPTrJPLZaeXmK07KbnNFSP2A@mail.gmail.com>
 <CAE6NSRA9sNDkL2RgpaUnziRv5ka2j_L4y1rScKoLJSnR+KCXpg@mail.gmail.com>
 <mailman.4.1526955481.18022.python-list@python.org>
 <pe0bn1$8ns$1@dont-email.me>
Message-ID: <CAE6NSRA4=wxwAWCXpJg9sXZgdDrFY5GN8_JybYg1zwgi-aYCQQ@mail.gmail.com>

On Tue, May 22, 2018 at 9:01 AM, Christian Gollwitzer <auriocus at gmx.de> wrote:
> Am 22.05.18 um 04:17 schrieb Mikhail V:
>>> YAML comes to mind
>>
>>
>> Actually plugging a data syntax in existing language is not a new idea.
>> Though I don't know real success stories.
>>
>
> Thing is, you can do it already now in the script, without modifying the
> Python interpreter, by parsing a triple-quoted string. See the examples
> right here: http://pyyaml.org/wiki/PyYAMLDocumentation
>


Yes. That is exactly what I wanted to discuss actually.
So the feature, which makes it possible in this case  is
triple quote string (TQS).

I think it would be appropriate to propose an alternative
to TQS for this specific purposes. Namely for making it
easier to implement parsers and embedded syntaxes.

So what do I have now with triple quoted strings -
a simple example:

if 1:
    s = """\
    print ("\n") \\
        foo = 5
    """

So there is a _possibility_ in the sense it is possible to do, so
let's say I have a lib with a parser, etc. Though now a developer
and a user will face quite real issues:

- TQS itself has its specific purpose already in many contents,
  which may mean for example hard-coded syntax highlighting
- there a lot of things happening here: e.g. in the above example
  I use "\n" which I assume a part of string, or \\ - but it is interpreted.
  Maybe some other things regarding escaping. This particular
  issue maybe a blocker for making use of TQS in some data cases,
  Say if the target source text need these very characters.

- indentation is the part of TQS. That is of couse by design
  so and it's quite logical, though it is hard-coded behaviour and thus
  does not make the presentation a natural part of blocks containing
  this string.
- appearance: imagine you have some small chunks of embedded
  code parts and you will still have the closing """ everywhere -
  that would be really hairy.


The alternative proposal therefore comes down to a "data block" syntax,
without much assumption about the contents of the block.

This should be simpler to implement, because it should not need a lot
of parsing rules - only some basic options. At the same time it enables
the 'embedding' of user-defined blocks/syntax more naturally
looking than TQS.

My thoughts on possible solution.
-------------

Problem one: make it look natural inside python source.
Current Python behaviour: very simply speaking, first leading white space
on a line is taken and compared with the one from the next line.
Its Okay for statements, but not okay for raw text data -
because probably I want custom leading whitespaces:

string =
     abc
   abc

(So the TQS takes it simple - grabs it from the line beginning)

So the idea:
- add such a block  to syntax
- *force explicit parameter for the indent charaters.*

Explanation:
[here i'll use same symbol /// for the data entry point, but of course it can
be changed if a better idea comes later. Also for now, just for simplicity -
the rule is that the contents of a block starts always on the new line.

So, e.g. this:

data = /// s4
    first line
    last line
the rest python code

- will parse the block and knock out leading 4 spaces.
i.e. if the first line has 5 leading spaces then 1 space will be left
in the string. Block parsing terminates when the next line does not
satisfy the indent sequence (4 spaces in this case).
Another obvious type: tabs:

data = /// t1
    first line
    last line
the rest python code

Will do the same but with one tabstop character.

Actually that's it!
Some further ideas:

data = /// ts
- "any whitespace" (mimic current Python behaviour)

data = /// s        # or
data = /// t
- simply count amount of spaces (tabs) from first
  line and proceed, otherwise terminate.

data = /// "???"
??? abc foo bar
???

- defines indent character by string: crazy idea but why not.

Language  parameter, e.g.:
data = /// t1."yaml"

-this can be reserved for future usage by code analysis tools
or dynamic syntax highlighting.

That's just a rough specification.

What should it give as result:

1. No clash with current TQS rules - less worries
  about reserved characters.

2. Built-in indentation parsing parameter makes it more or
  less natural continuation of Python blocks and is char-precise,
  which is very important here.

3. Independent of the indent of containing block!

4. Parameter descriptor can be developed in such manner
   that it allows more customisation and additions in the future.


Does seem to be more generalized problem-solving here.

One problem, as usual - tabs may be implicitly converted
to spaces by some software. That obviously could brake
something, but so is with any tabs, and its not related to
Python problem.


Is there something I miss here?
What caveats can be with such approach?



M


From digitig at gmail.com  Tue May 22 18:56:43 2018
From: digitig at gmail.com (digitig at gmail.com)
Date: Tue, 22 May 2018 15:56:43 -0700 (PDT)
Subject: Getting Unicode decode error using lxml.iterparse
Message-ID: <8e9fad93-b802-4ae0-921b-fce559e0621c@googlegroups.com>

I'm trying to read my iTunes library in Python using iterparse. My current stub is:

---- Snip ----

import sys
import datetime
import xml.etree.ElementTree as ET
import argparse
import re

class Library:
    
    unmarshallers = {
        # collections
        "array": lambda x: [v.text for v in x],
        "dict": lambda x:
            dict((x[i].text, x[i+1].text) for i in range(0, len(x), 2)),
        "key": lambda x: x.text or "",

        # simple types
        "string": lambda x: x.text or "",
        "data": lambda x: base64.decodestring(x.text or ""),
        "date": lambda x: datetime.datetime(*map(int, re.findall("\d+", x.text))),
        "true": lambda x: True,
        "false": lambda x: False,
        "real": lambda x: float(x.text),
        "integer": lambda x: int(x.text)
        }

    def load(self, file):
        print('Starting...')
        parser = ET.iterparse(file)
        for action, elem in parser:
            unmarshal = self.unmarshallers.get(elem.tag)
            if unmarshal:
                data = unmarshal(elem)
                elem.clear()
                elem.text = data
                print(elem.text)
            elif elem.tag != "plist":
                raise IOError("unknown plist type: %r" % elem.tag)
        return parser.root[0].text
    
    def __init__(self, infile):
        self.root = self.load(infile)

if __name__ == "__main__":
    parser = argparse.ArgumentParser(description = "Parse an iTunes library file to a set of CSV files suitable for import to a database.")
    parser.add_argument('infile', nargs='?', type=argparse.FileType('r'), default=sys.stdin)
    args=parser.parse_args()
    print('Infile = ', args.infile)
    library = Library(args.infile)


My input file (reduced to home in on the error) is:


---- snip -----

<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
	<dict>
		<key>15078</key>
		<dict>
			<key>Name</key><string>Part 2. The Death Of Enkidu. Skon P?itele M?ho Mne Zdeptal Te??e</string>
		</dict>
	</dict>
</dict>
</plist>

---- snip ----


<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
	<dict>
		<key>15078</key>
		<dict>
			<key>Name</key><string>Part 2. The Death Of Enkidu. Skon P?itele M?ho Mne Zdeptal Te??e</string>
		</dict>
	</dict>
</dict>
</plist>



I'm getting an error on one part of the XML:


 File "C:\Users\digit\Anaconda3\lib\encodings\cp1252.py", line 23, in decode
    return codecs.charmap_decode(input,self.errors,decoding_table)[0]

UnicodeDecodeError: 'charmap' codec can't decode byte 0x8d in position 202: character maps to <undefined>


I suspect the issue is that it's using cp1252.py, which I don't think is UTF-8 as specified in the XML prolog. Is this an iterparse problem, or am I using it wrongly?


Thanks.



From D.Strohl at F5.com  Tue May 22 19:25:36 2018
From: D.Strohl at F5.com (Dan Strohl)
Date: Tue, 22 May 2018 23:25:36 +0000
Subject: "Data blocks" syntax specification draft
In-Reply-To: <CAE6NSRA4=wxwAWCXpJg9sXZgdDrFY5GN8_JybYg1zwgi-aYCQQ@mail.gmail.com>
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
 <pdu324$l8j$1@blaine.gmane.org>
 <CAHiMU6cGz=X4LMcYac=_Us0+9ATPTrJPLZaeXmK07KbnNFSP2A@mail.gmail.com>
 <CAE6NSRA9sNDkL2RgpaUnziRv5ka2j_L4y1rScKoLJSnR+KCXpg@mail.gmail.com>
 <mailman.4.1526955481.18022.python-list@python.org>
 <pe0bn1$8ns$1@dont-email.me>
 <CAE6NSRA4=wxwAWCXpJg9sXZgdDrFY5GN8_JybYg1zwgi-aYCQQ@mail.gmail.com>
Message-ID: <9bf0783c8b044b348769942bda950043@F5.com>


> -----Original Message-----
> 
> I think it would be appropriate to propose an alternative to TQS for this
> specific purposes. Namely for making it easier to implement parsers and
> embedded syntaxes.
> 
> So what do I have now with triple quoted strings - a simple example:
> 
> if 1:
>     s = """\
>     print ("\n") \\
>         foo = 5
>     """
> 
> So there is a _possibility_ in the sense it is possible to do, so let's say I have a
> lib with a parser, etc. Though now a developer and a user will face quite real
> issues:
> 
> - TQS itself has its specific purpose already in many contents,
>   which may mean for example hard-coded syntax highlighting
> - there a lot of things happening here: e.g. in the above example
>   I use "\n" which I assume a part of string, or \\ - but it is interpreted.
>   Maybe some other things regarding escaping. This particular
>   issue maybe a blocker for making use of TQS in some data cases,
>   Say if the target source text need these very characters.
> 

Yup, I can see this, I do use """ in a number of ways, often to comment out large chunks of code. (OK, I probably should not, but I do).

> - indentation is the part of TQS. That is of couse by design
>   so and it's quite logical, though it is hard-coded behaviour and thus
>   does not make the presentation a natural part of blocks containing
>   this string.
> - appearance: imagine you have some small chunks of embedded
>   code parts and you will still have the closing """ everywhere -
>   that would be really hairy.
> 
> 

And yup, that does cause some challenges sometimes.

> 
> Explanation:
> [here i'll use same symbol /// for the data entry point, but of course it can be
> changed if a better idea comes later. Also for now, just for simplicity - the rule
> is that the contents of a block starts always on the new line.
> 
> So, e.g. this:
> 
> data = /// s4
>     first line
>     last line
> the rest python code
> 
> - will parse the block and knock out leading 4 spaces.
> i.e. if the first line has 5 leading spaces then 1 space will be left in the string.
> Block parsing terminates when the next line does not satisfy the indent
> sequence (4 spaces in this case).
> Another obvious type: tabs:

OK, I CAN see this as a potentially useful suggestion.  There are a number of times where I would like to define a large chunk of text, but using tqs and having it suddenly move to the left is painful visually.  Right now, I tend to either a) do it anyway, b) do it in a separate module and import the variables, or c) do it and parse the string to remove the extra spaces.

Personally though, I would not hard code it to knock out 4 leading spaces.   I would have it handle spaces the same was that the existing parser does, if there are 4 spaces indending the next line, then it removes 4 spaces, if there are 6 spaces, it removes 6 spaces, etc... ignoring additional spaces within the data-string object.  Once it hits a line that has the same number if indenting spaces as the initial token, the data-string object is finished.

> 
> data = /// t1
>     first line
>     last line
> the rest python code
> 
> Will do the same but with one tabstop character.
> 

Tabs / spaces should be handled as normal (up to the data-string object starts, after which, it pulls off the first x tabs or spaces, and leaves anything else) 

> Actually that's it!
> Some further ideas:
> 
> data = /// ts
> - "any whitespace" (mimic current Python behaviour)
> 
> data = /// s        # or
> data = /// t
> - simply count amount of spaces (tabs) from first
>   line and proceed, otherwise terminate.
> 
> data = /// "???"
> ??? abc foo bar
> ???
> 
> - defines indent character by string: crazy idea but why not.
> 

Nope, don't like this one... It's far enough from Python normal that it seems unlikely to not get through, and (personally at least), I struggle to see the benefit.

> Language  parameter, e.g.:
> data = /// t1."yaml"
> 
> -this can be reserved for future usage by code analysis tools or dynamic
> syntax highlighting.
> 

I can see where this might be interesting, but again, I just don't see the need, if the spec returns a string, you can use that string in any parser you want. If you want to customize how it's handled, then you can always create a custom object for it.

> That's just a rough specification.
> 
> What should it give as result:
> 

To me, this seems like a simply additional specification for a TQS, with the only enhancement being that it's an indented TQS basically, so the return is a string.

> 1. No clash with current TQS rules - less worries
>   about reserved characters.
> 
> 2. Built-in indentation parsing parameter makes it more or
>   less natural continuation of Python blocks and is char-precise,
>   which is very important here.
> 
> 3. Independent of the indent of containing block!
> 
> 4. Parameter descriptor can be developed in such manner
>    that it allows more customisation and additions in the future.
> 

I would not argue about this being in the spec, but it seems like a un-needed complexity.

> 
> Does seem to be more generalized problem-solving here.
> 




From bc at freeuk.com  Tue May 22 19:51:36 2018
From: bc at freeuk.com (bartc)
Date: Wed, 23 May 2018 00:51:36 +0100
Subject: "Data blocks" syntax specification draft
In-Reply-To: <mailman.25.1527004641.18022.python-list@python.org>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
 <CALwzid=z409FFgG-cBq=VO5u0sHC8J3hutwzn15vT_+fx0zv5A@mail.gmail.com>
 <CAPTjJmpS=9Nxr2aRDPbUfF05C9zOsDCsDnBJC_7=8+dwXB42ww@mail.gmail.com>
 <CALwzidnW5=rpSkDWduHnnjE4FY69VR5gR6Gq48tQQRE49GcHkA@mail.gmail.com>
 <CAPTjJmq1+v2XX=ZEM7nzg1FjKuLHcRY-L9LCeK+Z9F=U=C47iQ@mail.gmail.com>
 <mailman.25.1527004641.18022.python-list@python.org>
Message-ID: <822NC.219460$RH3.27875@fx27.am4>

On 22/05/2018 16:57, Chris Angelico wrote:
> On Wed, May 23, 2018 at 1:43 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:

>> In other words, the rule is not really as simple as "commas make
>> tuples". I stand by what I wrote.
> 
> Neither of us is wrong here.

Sorry, but I don't think you're right at all. unless the official 
references for the language specifically say that commas are primarily 
for constructing tuples, and all other uses are exceptions to that rule.

AFAICS, commas are used just like commas everywhere - used as 
separators. The context tells Python what the resulting sequence is.

  "Commas make tuples" is a useful
> oversimplification in the same way that "asterisk means
> multiplication" is. The asterisk has other meanings in specific
> contexts (eg unpacking), but outside of those contexts, it means
> multiplication.

I don't think that's quite right either. Asterisk is just an overloaded 
token but you will what it's for as soon as it's encountered.

Comma seems to be used only as a separator.


-- 
bartc


From mikhailwas at gmail.com  Tue May 22 22:35:09 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Wed, 23 May 2018 05:35:09 +0300
Subject: "Data blocks" syntax specification draft
In-Reply-To: <VeSMC.135109$ga6.33227@fx24.am4>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
Message-ID: <CAE6NSRDyeVO=+zqYcDSgoMvY9Rus3owgCLwdf+YPD-k=XK9nLw@mail.gmail.com>

On Tue, May 22, 2018 at 1:25 PM, bartc <bc at freeuk.com> wrote:
> On 22/05/2018 03:49, Mikhail V wrote:
>>
>> On Mon, May 21, 2018 at 3:48 PM, bartc <bc at freeuk.com> wrote:
>>
>> # t
>>     # t
>>        11  22  33
>>
>
> Is this example complete? Presumably it means ((11,22,33),).

Yep.

>
>> You get the point?
>> So basically all nice chars are already occupied.
>
> You mean for introducing tuple, list and dict literals?

No, I've meant the node (or whole data block) entry point chars ///.

So in such an language full of various operators, it is
just hard to find anything that does not clash with some
current meaning yet looks adequate and is ASCII.

A quick note: thanks for your comments, I'll  just note that I've
moved to some more promising related proposal (see last posts in this thread),
so the original one will move to later considerations.
so the nuances will be reconsidered anyway.


> Python already uses
> (, [ and { for those, with the advantage of having a closing ), ] and } to
> make it easier to see where each ends.

Ehm, for inline usage - i.e. everywhere on a line - closing tags are necessity.
My whole idea was about indentation based data - so there it is redundant noise.
You may disagree as well, since I've noticed in some previous thread
that you prefer Fortran-like termination tags. So that's quite personal I think.

As for more objective points: currently many brackets are 'overloaded'
and moreover, they are all almost "homoglyphs" - very similar characters.

For an inline solution I'd prefer it e.g.
for a tuple:

{t  11  22  33}

nested:
{t  11  {t  11  22}  22}

Yes, it IS worse than:
{11  {11  22}  22}

But still one might need _various types_ so brackets only - has
limited potential in this sense.


>>> The ///d dictionary example is ambiguous: can you have more than one
>>> key:value per line or not? If so, it would look like this:
>>>
>>>    ///d "a" "b" "c" "d" "e" "f"
>>
>>
>> ///d   "a" "b"    "c" "d"    "e" "f"
>>
>> Now better? :-)
>
>
> Not really.
> Suppose one got accidentally missed out, and there was some
> spurious name at the end,

Not sure about your case, but it is up to you to format it to make it
more readable - whitespace / newline separation gives enough possibilities to
do so. And for me the lack of commas is of great benefit.
 _Some_ punctuation can be added in some cases (see e.g. "node
stacking section" in original document - dicts may adopt this as well
but I see no necessity at least for this case)


> It's not clear whether:
>
>   ///d a b
>     c e
>     f x
>
> is allowed ?

allowed, but i'd say merely discouraged for industrial usage. better start
newline at least for multiline contents.

> I think this is an interesting first draft of an idea, but it doesn't seem
> rigorous. And people don't like that triple stroke prefix, or those single
> letter codes (why not just use 'tuple', 'list', 'dict')?
>
> For example, here is a proposal I've just made up for a similar idea, but to
> make such constructors obey similar rules to Python blocks:
>
>  tuple:
>      10
>      20
>      30
>
>  list:
>      list:
>          10
>          tuple: 5,6,7
>          30
>      "forty"
>      "fifty"
>

Cool, I've commented on similar option actually in some post before -
it might be ok
with type codes grayed-out and good coloring, but in black and white it is a bit
"wall of text" - not much emphasis on _structure_. But its ok - good option.


From mikhailwas at gmail.com  Tue May 22 23:32:32 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Wed, 23 May 2018 06:32:32 +0300
Subject: "Data blocks" syntax specification draft
In-Reply-To: <9bf0783c8b044b348769942bda950043@F5.com>
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
 <pdu324$l8j$1@blaine.gmane.org>
 <CAHiMU6cGz=X4LMcYac=_Us0+9ATPTrJPLZaeXmK07KbnNFSP2A@mail.gmail.com>
 <CAE6NSRA9sNDkL2RgpaUnziRv5ka2j_L4y1rScKoLJSnR+KCXpg@mail.gmail.com>
 <mailman.4.1526955481.18022.python-list@python.org>
 <pe0bn1$8ns$1@dont-email.me>
 <CAE6NSRA4=wxwAWCXpJg9sXZgdDrFY5GN8_JybYg1zwgi-aYCQQ@mail.gmail.com>
 <9bf0783c8b044b348769942bda950043@F5.com>
Message-ID: <CAE6NSRC9tDgMB8_tk8NsVYqLVE8G2YpV1LX3xhB5angE2is5pA@mail.gmail.com>

On Wed, May 23, 2018 at 2:25 AM, Dan Strohl <D.Strohl at f5.com> wrote:
>

>>
>> Explanation:
>> [here i'll use same symbol /// for the data entry point, but of course it can be
>> changed if a better idea comes later. Also for now, just for simplicity - the rule
>> is that the contents of a block starts always on the new line.
>>
>> So, e.g. this:
>>
>> data = /// s4
>>     first line
>>     last line
>> the rest python code
>>
>> - will parse the block and knock out leading 4 spaces.
>> i.e. if the first line has 5 leading spaces then 1 space will be left in the string.
>> Block parsing terminates when the next line does not satisfy the indent
>> sequence (4 spaces in this case).
>
>
> Personally though, I would not hard code it to knock out 4 leading spaces.
> I would have it handle spaces the same was that the existing parser does,

If I understand you correctly, then I think I have this option already
described,
i.e. these:

>> data = /// ts
>>
>> - "any whitespace" (mimic current Python behaviour)
>>
>> data = /// s        # or
>> data = /// t
>>
>> - simply count amount of spaces (tabs) from first
>>   line and proceed, otherwise terminate.


Though hard-coded knock-out is also very useful, e.g. for this:

data = /// s4
        First line indented more (8 spaces)
    second - less (4 spaces)
rest code

So this will preserve formatting.


>> data = /// "???"
>> ??? abc foo bar
>> ???
>>
>> - defines indent character by string: crazy idea but why not.
>>
>
> Nope, don't like this one... It's far enough from Python normal that it seems
> unlikely to not get through, and (personally at least), I struggle to see the benefit.

Heh, that was merely joke - but OTOH one could use it for hard-coded
indent sequences:

data = /// "    "
        First line indented more (8 spaces)
    second - less (4 spaces)
rest code

A bit sloppy look, but it generalizes some uses. But granted - I don't
see much real applications besides than space and tab indented block
anyway - so it's under question.


>> Language  parameter, e.g.:
>> data = /// t1."yaml"
>>
>> -this can be reserved for future usage by code analysis tools or dynamic
>> syntax highlighting.
>>
>
> I can see where this might be interesting, but again, I just don't see the need,

I think you're right  - if need a directive for some analysis tool then one
can make for example a consideration to precede the whole statement
with a directive, say in a comment:

# lang "yaml"
data = /// t
    first line
    last line
rest




Also I am thinking about this - there might be one useful 'hack".
One could even allow single-line usage, e.g.;
(with a semicolon)

data = /// s2:  first line

- so this would start parsing just after colon :
"pretending it is block.
This may be not so fat-fingered-proof and 'inconsistent',
but in the end of the day, might be a win actually.



M


From rosuav at gmail.com  Wed May 23 01:22:27 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 23 May 2018 15:22:27 +1000
Subject: "Data blocks" syntax specification draft
In-Reply-To: <822NC.219460$RH3.27875@fx27.am4>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
 <CALwzid=z409FFgG-cBq=VO5u0sHC8J3hutwzn15vT_+fx0zv5A@mail.gmail.com>
 <CAPTjJmpS=9Nxr2aRDPbUfF05C9zOsDCsDnBJC_7=8+dwXB42ww@mail.gmail.com>
 <CALwzidnW5=rpSkDWduHnnjE4FY69VR5gR6Gq48tQQRE49GcHkA@mail.gmail.com>
 <CAPTjJmq1+v2XX=ZEM7nzg1FjKuLHcRY-L9LCeK+Z9F=U=C47iQ@mail.gmail.com>
 <mailman.25.1527004641.18022.python-list@python.org>
 <822NC.219460$RH3.27875@fx27.am4>
Message-ID: <CAPTjJmoRQrmXLEyEnLZWdEec6gQ8bkP0RbT1t2Tg03dFbLOhsQ@mail.gmail.com>

On Wed, May 23, 2018 at 9:51 AM, bartc <bc at freeuk.com> wrote:
> On 22/05/2018 16:57, Chris Angelico wrote:
>>
>> On Wed, May 23, 2018 at 1:43 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
>
>
>>> In other words, the rule is not really as simple as "commas make
>>> tuples". I stand by what I wrote.
>>
>>
>> Neither of us is wrong here.
>
>
> Sorry, but I don't think you're right at all. unless the official references
> for the language specifically say that commas are primarily for constructing
> tuples, and all other uses are exceptions to that rule.

"A tuple consists of a number of values separated by commas"
https://docs.python.org/3/tutorial/datastructures.html#tuples-and-sequences

"Separating items with commas"
https://docs.python.org/3/library/stdtypes.html#tuple

"Note that tuples are not formed by the parentheses, but rather by use
of the comma operator."
https://docs.python.org/3/reference/expressions.html#parenthesized-forms

Enough examples? Commas make tuples, unless context specifies otherwise.

ChrisA


From sachinewx at gmail.com  Wed May 23 01:22:53 2018
From: sachinewx at gmail.com (SACHIN CHAVAN)
Date: Tue, 22 May 2018 22:22:53 -0700 (PDT)
Subject: how to handle captcha through machanize module  or any module
In-Reply-To: <2b488aa4-5698-4be8-b272-7f93c49d154c@googlegroups.com>
References: <2b488aa4-5698-4be8-b272-7f93c49d154c@googlegroups.com>
Message-ID: <1ed2f890-4181-4a39-97d9-42c0c5fc0524@googlegroups.com>

On Wednesday, December 18, 2013 at 6:26:17 PM UTC+5:30, Jai wrote:
> please do replay how to handle captcha through machanize module

I have the same issue, nothing find a solution yet!


From auriocus at gmx.de  Wed May 23 01:32:26 2018
From: auriocus at gmx.de (Christian Gollwitzer)
Date: Wed, 23 May 2018 07:32:26 +0200
Subject: "Data blocks" syntax specification draft
In-Reply-To: <mailman.43.1527052950.18022.python-list@python.org>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
 <CALwzid=z409FFgG-cBq=VO5u0sHC8J3hutwzn15vT_+fx0zv5A@mail.gmail.com>
 <CAPTjJmpS=9Nxr2aRDPbUfF05C9zOsDCsDnBJC_7=8+dwXB42ww@mail.gmail.com>
 <CALwzidnW5=rpSkDWduHnnjE4FY69VR5gR6Gq48tQQRE49GcHkA@mail.gmail.com>
 <CAPTjJmq1+v2XX=ZEM7nzg1FjKuLHcRY-L9LCeK+Z9F=U=C47iQ@mail.gmail.com>
 <mailman.25.1527004641.18022.python-list@python.org>
 <822NC.219460$RH3.27875@fx27.am4>
 <CAPTjJmoRQrmXLEyEnLZWdEec6gQ8bkP0RbT1t2Tg03dFbLOhsQ@mail.gmail.com>
 <mailman.43.1527052950.18022.python-list@python.org>
Message-ID: <pe2udb$s4m$1@dont-email.me>

Am 23.05.18 um 07:22 schrieb Chris Angelico:
> On Wed, May 23, 2018 at 9:51 AM, bartc <bc at freeuk.com> wrote:
>> Sorry, but I don't think you're right at all. unless the official references
>> for the language specifically say that commas are primarily for constructing
>> tuples, and all other uses are exceptions to that rule.
> 
> "A tuple consists of a number of values separated by commas"
> https://docs.python.org/3/tutorial/datastructures.html#tuples-and-sequences
> 
> "Separating items with commas"
> https://docs.python.org/3/library/stdtypes.html#tuple
> 
> "Note that tuples are not formed by the parentheses, but rather by use
> of the comma operator."
> https://docs.python.org/3/reference/expressions.html#parenthesized-forms
> 
> Enough examples? Commas make tuples, unless context specifies otherwise.

I'd think that the definitive answer is in the grammar, because that is 
what is used to build the Python parser:

	https://docs.python.org/3/reference/grammar.html

Actually, I'm a bit surprised that tuple, list etc. does not appear 
there as a non-terminal. It is a bit hard to find, and it seems that 
"atom:" is the starting point for parsing tuples, lists etc.

	Christian


From tjreedy at udel.edu  Wed May 23 02:01:10 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 23 May 2018 02:01:10 -0400
Subject: Tkinter and root vs. Wayland
In-Reply-To: <pe23eg$kl4$1@blaine.gmane.org>
References: <pe23eg$kl4$1@blaine.gmane.org>
Message-ID: <pe2vv4$152$1@blaine.gmane.org>

On 5/22/2018 5:52 PM, Grant Edwards wrote:
> For a couple decades now, I've been distributing a couple smallish
> Tkinter applications that need to run as root for a variety of reasons
> (raw Ethernet access, starting/stopping daemons, loading and unloading
> kernel modules, reading and writing config files that are owned by
> root).
> 
> As part of RedHat's switch to Wayland, they've decided that GUI X11
> apps running as root will no longer be allowed to connect to the
> Wayland desktop server/compositor/whatever-it's-called.  When it was
> pointed out to RedHat that this will break lots of applications, the
> official word from on high is that all GUI apps requiring root
> privileges need to be redesigned so that their GUI is running as a
> normal user.
> 
> How does one do that in a Tkinter app?  Do I need to start as root and
> fork a process that drops privledges and starts Tkinter and then the
> two processes communicate via sockets or Posix queues or whatnot?

IDLE starts as a GUI process.  It uses subprocess to start a user-code 
execution process.  They communicate via a socket.  This usually works, 
but not always, so I may someday look into using multiprocessing.

-- 
Terry Jan Reedy



From ian.g.kelly at gmail.com  Wed May 23 02:01:29 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Wed, 23 May 2018 00:01:29 -0600
Subject: "Data blocks" syntax specification draft
In-Reply-To: <pe2udb$s4m$1@dont-email.me>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
 <CALwzid=z409FFgG-cBq=VO5u0sHC8J3hutwzn15vT_+fx0zv5A@mail.gmail.com>
 <CAPTjJmpS=9Nxr2aRDPbUfF05C9zOsDCsDnBJC_7=8+dwXB42ww@mail.gmail.com>
 <CALwzidnW5=rpSkDWduHnnjE4FY69VR5gR6Gq48tQQRE49GcHkA@mail.gmail.com>
 <CAPTjJmq1+v2XX=ZEM7nzg1FjKuLHcRY-L9LCeK+Z9F=U=C47iQ@mail.gmail.com>
 <mailman.25.1527004641.18022.python-list@python.org>
 <822NC.219460$RH3.27875@fx27.am4>
 <CAPTjJmoRQrmXLEyEnLZWdEec6gQ8bkP0RbT1t2Tg03dFbLOhsQ@mail.gmail.com>
 <mailman.43.1527052950.18022.python-list@python.org>
 <pe2udb$s4m$1@dont-email.me>
Message-ID: <CALwzid=r9bmDZ_PZ9dpW4=yb60toTtu2vD5wVPacXM+dxkiRTA@mail.gmail.com>

On Tue, May 22, 2018 at 11:32 PM, Christian Gollwitzer <auriocus at gmx.de> wrote:
> Am 23.05.18 um 07:22 schrieb Chris Angelico:
>>
>> On Wed, May 23, 2018 at 9:51 AM, bartc <bc at freeuk.com> wrote:
>>>
>>> Sorry, but I don't think you're right at all. unless the official
>>> references
>>> for the language specifically say that commas are primarily for
>>> constructing
>>> tuples, and all other uses are exceptions to that rule.
>>
>>
>> "A tuple consists of a number of values separated by commas"
>>
>> https://docs.python.org/3/tutorial/datastructures.html#tuples-and-sequences
>>
>> "Separating items with commas"
>> https://docs.python.org/3/library/stdtypes.html#tuple
>>
>> "Note that tuples are not formed by the parentheses, but rather by use
>> of the comma operator."
>> https://docs.python.org/3/reference/expressions.html#parenthesized-forms
>>
>> Enough examples? Commas make tuples, unless context specifies otherwise.
>
>
> I'd think that the definitive answer is in the grammar, because that is what
> is used to build the Python parser:
>
>         https://docs.python.org/3/reference/grammar.html
>
> Actually, I'm a bit surprised that tuple, list etc. does not appear there as
> a non-terminal. It is a bit hard to find, and it seems that "atom:" is the
> starting point for parsing tuples, lists etc.

For enclosed tuples, yes. I believe that tuples without parentheses
can be produced by either 'exprlist' or 'testlist' (which is why some
cases permit iterable unpacking and some don't).


From dieter at handshake.de  Wed May 23 02:01:35 2018
From: dieter at handshake.de (dieter)
Date: Wed, 23 May 2018 08:01:35 +0200
Subject: Spam levels.
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <5b027ca9$0$619$65785112@news.neostrada.pl> <20180521144801.GB7508@equipaje>
 <pdupd4$6ra$1@blaine.gmane.org> <20180522195947.hrntcm47wjzvdbcr@hjp.at>
 <pe1vc3$sd$2@blaine.gmane.org> <20180522220101.lvp6lsd7x77ndz2g@hjp.at>
Message-ID: <87sh6i3o74.fsf@handshake.de>

"Peter J. Holzer" <hjp-python at hjp.at> writes:
> ...
> I didn't read on Gmane. I read on my usenet server. But the broken
> messages were all coming from Gmane.

I am reading with an NNTP client connected to the Gmane NNTP server and
and threading works - with very rare exceptions.
The exeptions are so rare, that they might have been caused by the
posters (sometimes someone opens an issue by answering to an exisiting
discussion; or starts a new thread for answering to a post in another thread).

Maybe something went wrong with the integration of your NTTP server
with the Gmane one?



From rosuav at gmail.com  Wed May 23 02:03:08 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 23 May 2018 16:03:08 +1000
Subject: "Data blocks" syntax specification draft
In-Reply-To: <pe2udb$s4m$1@dont-email.me>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
 <CALwzid=z409FFgG-cBq=VO5u0sHC8J3hutwzn15vT_+fx0zv5A@mail.gmail.com>
 <CAPTjJmpS=9Nxr2aRDPbUfF05C9zOsDCsDnBJC_7=8+dwXB42ww@mail.gmail.com>
 <CALwzidnW5=rpSkDWduHnnjE4FY69VR5gR6Gq48tQQRE49GcHkA@mail.gmail.com>
 <CAPTjJmq1+v2XX=ZEM7nzg1FjKuLHcRY-L9LCeK+Z9F=U=C47iQ@mail.gmail.com>
 <mailman.25.1527004641.18022.python-list@python.org>
 <822NC.219460$RH3.27875@fx27.am4>
 <CAPTjJmoRQrmXLEyEnLZWdEec6gQ8bkP0RbT1t2Tg03dFbLOhsQ@mail.gmail.com>
 <mailman.43.1527052950.18022.python-list@python.org>
 <pe2udb$s4m$1@dont-email.me>
Message-ID: <CAPTjJmo209RiozDBEuPbr-yk1amDP7ZMkrA_0OyxEmBTpkZ9rw@mail.gmail.com>

On Wed, May 23, 2018 at 3:32 PM, Christian Gollwitzer <auriocus at gmx.de> wrote:
> Am 23.05.18 um 07:22 schrieb Chris Angelico:
>>
>> On Wed, May 23, 2018 at 9:51 AM, bartc <bc at freeuk.com> wrote:
>>>
>>> Sorry, but I don't think you're right at all. unless the official
>>> references
>>> for the language specifically say that commas are primarily for
>>> constructing
>>> tuples, and all other uses are exceptions to that rule.
>>
>>
>> "A tuple consists of a number of values separated by commas"
>>
>> https://docs.python.org/3/tutorial/datastructures.html#tuples-and-sequences
>>
>> "Separating items with commas"
>> https://docs.python.org/3/library/stdtypes.html#tuple
>>
>> "Note that tuples are not formed by the parentheses, but rather by use
>> of the comma operator."
>> https://docs.python.org/3/reference/expressions.html#parenthesized-forms
>>
>> Enough examples? Commas make tuples, unless context specifies otherwise.
>
>
> I'd think that the definitive answer is in the grammar, because that is what
> is used to build the Python parser:
>
>         https://docs.python.org/3/reference/grammar.html
>
> Actually, I'm a bit surprised that tuple, list etc. does not appear there as
> a non-terminal. It is a bit hard to find, and it seems that "atom:" is the
> starting point for parsing tuples, lists etc.
>

The grammar's a bit hard to read for this sort of thing, as the only
hint of semantic meaning is in the labels at the beginning. For
example, there's a "dictorsetmaker" entry that grammatically could be
a dict comp or a set comp; distinguishing them is the job of other
parts of the code.

ChrisA


From steve+comp.lang.python at pearwood.info  Wed May 23 02:03:38 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Wed, 23 May 2018 06:03:38 +0000 (UTC)
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
References: <1a7951080901290824p424caee3jb74b1343ce884916@mail.gmail.com>
 <ec96e1390901290849g507dcb17tf2372e573f4a5bb5@mail.gmail.com>
 <mailman.8292.1233248983.3487.python-list@python.org>
 <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>
 <CANc-5Uxy8T+LKC=vw6ujxnY4K+yPpA1U7-boLXSYSeDbx8DgeQ@mail.gmail.com>
 <mailman.243.1526773687.2761.python-list@python.org>
 <27ef2bfb-e3ed-495c-bb98-f71e502d412a@googlegroups.com>
 <20180520134354.GB2192@hermes.hilbert.loc>
 <20180522212337.cvtbh32tydvaft4r@hjp.at>
 <CAPTjJmqP86iiuoXrB0r1M-7U9kM8P5Xev=mEtLwmFr5zKV45AA@mail.gmail.com>
 <20180522223103.fmym5wsmvr7vaua3@hjp.at>
Message-ID: <pe307p$d1p$1@blaine.gmane.org>

On Wed, 23 May 2018 00:31:03 +0200, Peter J. Holzer wrote:

> On 2018-05-23 07:38:27 +1000, Chris Angelico wrote:
[...]
>> You can find an encoding which is capable of decoding a file. That's
>> not the same thing.
> 
> If the result is correct, it is the same thing.

But how do you know what is correct and what isn't? In the most general 
case, even if you know the language nominally being used, you might not 
be able to recognise good output from bad:

    Max Steele strained his mighty thews against his bonds, but
    the ?-rays had left him as weak as a kitten. The evil Galactic
    Emperor, Gi?x-??in The Terrible of the planet ?e??, laughed: "I 
    have you now, Steele, and by this time tomorrow my armies will
    have overrun your pitiful Earth defences!"

If this text is encoding using MacRoman, then decoded in Latin-1, it 
works, and looks barely any more stupid than the original:

    Max Steele strained his mighty thews against his bonds, but
    the ?-rays had left him as weak as a kitten. The evil Galactic
    Emperor, Gi?x-??in The Terrible of the planet ?e??, laughed: "I
    have you now, Steele, and by this time tomorrow my armies will
    have overrun your pitiful Earth defences!"

but it clearly isn't the original text.

Mojibake is especially difficult to deal with when you are dealing with 
short text snippets like file names or user names which can contain 
arbitrary characters, where there is rarely any way to recognise the 
"correct" string. If you think Gi?x-??in The Terrible is a ludicrous 
example of text, you ought to look at user names on web forums.



-- 
Steve



From marko at pacujo.net  Wed May 23 02:05:40 2018
From: marko at pacujo.net (Marko Rauhamaa)
Date: Wed, 23 May 2018 09:05:40 +0300
Subject: "Data blocks" syntax specification draft
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
 <CALwzid=z409FFgG-cBq=VO5u0sHC8J3hutwzn15vT_+fx0zv5A@mail.gmail.com>
 <CAPTjJmpS=9Nxr2aRDPbUfF05C9zOsDCsDnBJC_7=8+dwXB42ww@mail.gmail.com>
 <CALwzidnW5=rpSkDWduHnnjE4FY69VR5gR6Gq48tQQRE49GcHkA@mail.gmail.com>
 <CAPTjJmq1+v2XX=ZEM7nzg1FjKuLHcRY-L9LCeK+Z9F=U=C47iQ@mail.gmail.com>
 <mailman.25.1527004641.18022.python-list@python.org>
 <822NC.219460$RH3.27875@fx27.am4>
 <CAPTjJmoRQrmXLEyEnLZWdEec6gQ8bkP0RbT1t2Tg03dFbLOhsQ@mail.gmail.com>
 <mailman.43.1527052950.18022.python-list@python.org>
 <pe2udb$s4m$1@dont-email.me>
Message-ID: <87wovu7vpn.fsf@elektro.pacujo.net>

Christian Gollwitzer <auriocus at gmx.de>:

> I'd think that the definitive answer is in the grammar, because that is
> what is used to build the Python parser:
>
> 	https://docs.python.org/3/reference/grammar.html
>
> Actually, I'm a bit surprised that tuple, list etc. does not appear
> there as a non-terminal. It is a bit hard to find, and it seems that
> "atom:" is the starting point for parsing tuples, lists etc.

testlist and testlist_comp are the interesting entities.

The syntax definition does not help you understand the semantics. For
example, omitting yield_expr and testlist_comp in

   atom: ('(' [yield_expr|testlist_comp] ')' |

evaluates to a tuple and nothing in

   testlist: test (',' test)* [',']

suggests what effect the the presence or absence of the final ',' could
have on the evaluation.


Marko


From ian.g.kelly at gmail.com  Wed May 23 02:06:33 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Wed, 23 May 2018 00:06:33 -0600
Subject: "Data blocks" syntax specification draft
In-Reply-To: <CALwzid=r9bmDZ_PZ9dpW4=yb60toTtu2vD5wVPacXM+dxkiRTA@mail.gmail.com>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
 <CALwzid=z409FFgG-cBq=VO5u0sHC8J3hutwzn15vT_+fx0zv5A@mail.gmail.com>
 <CAPTjJmpS=9Nxr2aRDPbUfF05C9zOsDCsDnBJC_7=8+dwXB42ww@mail.gmail.com>
 <CALwzidnW5=rpSkDWduHnnjE4FY69VR5gR6Gq48tQQRE49GcHkA@mail.gmail.com>
 <CAPTjJmq1+v2XX=ZEM7nzg1FjKuLHcRY-L9LCeK+Z9F=U=C47iQ@mail.gmail.com>
 <mailman.25.1527004641.18022.python-list@python.org>
 <822NC.219460$RH3.27875@fx27.am4>
 <CAPTjJmoRQrmXLEyEnLZWdEec6gQ8bkP0RbT1t2Tg03dFbLOhsQ@mail.gmail.com>
 <mailman.43.1527052950.18022.python-list@python.org>
 <pe2udb$s4m$1@dont-email.me>
 <CALwzid=r9bmDZ_PZ9dpW4=yb60toTtu2vD5wVPacXM+dxkiRTA@mail.gmail.com>
Message-ID: <CALwzidmDsSEhZ5_AgeEiySb=_eRbtiFEc_8ar5hNRuGTSmUpHA@mail.gmail.com>

On Wed, May 23, 2018 at 12:01 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Tue, May 22, 2018 at 11:32 PM, Christian Gollwitzer <auriocus at gmx.de> wrote:
>> Am 23.05.18 um 07:22 schrieb Chris Angelico:
>>>
>>> On Wed, May 23, 2018 at 9:51 AM, bartc <bc at freeuk.com> wrote:
>>>>
>>>> Sorry, but I don't think you're right at all. unless the official
>>>> references
>>>> for the language specifically say that commas are primarily for
>>>> constructing
>>>> tuples, and all other uses are exceptions to that rule.
>>>
>>>
>>> "A tuple consists of a number of values separated by commas"
>>>
>>> https://docs.python.org/3/tutorial/datastructures.html#tuples-and-sequences
>>>
>>> "Separating items with commas"
>>> https://docs.python.org/3/library/stdtypes.html#tuple
>>>
>>> "Note that tuples are not formed by the parentheses, but rather by use
>>> of the comma operator."
>>> https://docs.python.org/3/reference/expressions.html#parenthesized-forms
>>>
>>> Enough examples? Commas make tuples, unless context specifies otherwise.
>>
>>
>> I'd think that the definitive answer is in the grammar, because that is what
>> is used to build the Python parser:
>>
>>         https://docs.python.org/3/reference/grammar.html
>>
>> Actually, I'm a bit surprised that tuple, list etc. does not appear there as
>> a non-terminal. It is a bit hard to find, and it seems that "atom:" is the
>> starting point for parsing tuples, lists etc.
>
> For enclosed tuples, yes. I believe that tuples without parentheses
> can be produced by either 'exprlist' or 'testlist' (which is why some
> cases permit iterable unpacking and some don't).

Er, that should be "either 'testlist_star_expr' or 'testlist'".


From dieter at handshake.de  Wed May 23 02:25:09 2018
From: dieter at handshake.de (dieter)
Date: Wed, 23 May 2018 08:25:09 +0200
Subject: Getting Unicode decode error using lxml.iterparse
References: <8e9fad93-b802-4ae0-921b-fce559e0621c@googlegroups.com>
Message-ID: <87o9h63n3u.fsf@handshake.de>

digitig at gmail.com writes:

> I'm trying to read my iTunes library in Python using iterparse. My current stub is:
> ...
> My input file (reduced to home in on the error) is:
>
> ---- snip -----
>
> <?xml version="1.0" encoding="UTF-8"?>
> <plist version="1.0">
> <dict>
> 	<dict>
> 		<key>15078</key>
> 		<dict>
> 			<key>Name</key><string>Part 2. The Death Of Enkidu. Skon P?itele M?ho Mne Zdeptal Te??e</string>
> 		</dict>
> 	</dict>
> </dict>
> </plist>
> ...
> I'm getting an error on one part of the XML:
>
>
>  File "C:\Users\digit\Anaconda3\lib\encodings\cp1252.py", line 23, in decode
>     return codecs.charmap_decode(input,self.errors,decoding_table)[0]
>
> UnicodeDecodeError: 'charmap' codec can't decode byte 0x8d in position 202: character maps to <undefined>
>
>
> I suspect the issue is that it's using cp1252.py, which I don't think is UTF-8 as specified in the XML prolog. Is this an iterparse problem, or am I using it wrongly?

You can tell "lxml" which encoding it should use. Maybe, you did
and it was the wrong one.

If the encoding is not specified, "lxml" will try to determine it
and finally defaults to "utf-8" (which seems to be the correct encoding
for your case).

"lxml" sits on top of the C library "libxml2". It may be possible
that "libxml2" allows an envvar to specify the default encoding
and - maybe - this envvar has an unfortunate value in your case.

As a workaround, you can tell "lxml" explicitly to use "utf-8"
for your parsing.



From steve+comp.lang.python at pearwood.info  Wed May 23 02:47:22 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Wed, 23 May 2018 06:47:22 +0000 (UTC)
Subject: "Data blocks" syntax specification draft
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
 <mailman.18.1526999168.18022.python-list@python.org>
 <yMYMC.220721$oo.45532@fx35.am4>
Message-ID: <pe32pp$d1p$2@blaine.gmane.org>

On Tue, 22 May 2018 18:51:30 +0100, bartc wrote:

> On 22/05/2018 15:25, Chris Angelico wrote:
[...]
>> The tuple has nothing to do with the parentheses, except for the
>> special case of the empty tuple. It's the comma.
> 
> No? Take these:
> 
>   a = (10,20,30)
>   a = [10,20,30]
>   a = {10,20,30}
> 
> If you print type(a) after each, only one of them is a tuple - the one
> with the round brackets.

You haven't done enough testing. All you have done is found that "round 
brackets give a tuple, other brackets don't". But you need to test what 
happens if you take away the brackets to be sure that it is the round 
brackets which create the tuple:

    a = 10, 20, 30  # take away the ()

You still get a tuple. Taking away the [] and {} also give tuples.

What happens if you add extra brackets?

    a = ((10, 20, 30))  # tuple
    b = ([10, 20, 30])  # list
    c = ({10, 20, 30})  # set


The round brackets are just used for grouping. In fact, the bytecode 
generated is identical:

py> import dis
py> dis.dis("(99, x)")
  1           0 LOAD_CONST               0 (99)
              3 LOAD_NAME                0 (x)
              6 BUILD_TUPLE              2
              9 RETURN_VALUE
py> dis.dis("99, x")
  1           0 LOAD_CONST               0 (99)
              3 LOAD_NAME                0 (x)
              6 BUILD_TUPLE              2
              9 RETURN_VALUE

What if we take away the commas but leave the brackets? If "brackets make 
tuples", then the commas ought to be optional.

    a = (10 20 30)  # SyntaxError


What if we simple add a single comma to end end, outside of the brackets?

    a = (10, 20, 30),  # tuple inside tuple
    b = [10, 20, 30],  # list inside tuple
    c = {10, 20, 30},  # set inside tuple


Conclusion: it is the comma, not the round brackets, which defines tuples 
(aside from the empty tuple case).



> The 10,20,30 in those other contexts doesn't create a tuple, nor does it
> here:
> 
>    f(10,20,30)

That's okay. There's no rule that says commas are ONLY used for tuples, 
just as there is no rule that says "if" is ONLY be used for if 
statements. (It is also used in the ternary if operator, elif, and any 
valid identifier which happens to include the letters "if" in that order).


> It's just that special case I
> highlighted where an unbracketed sequence of expressions yields a tuple.

You have that backwards. An unbracketed sequence of expressions yielding 
a tuple is not the special case, it is the base case. If you want 
something which is not a tuple (a list, a set) you have to use square or 
curly brackets.

The round brackets are only neccessary for tuples to group items in case 
of ambiguity with other grammar rules. (And the empty tuple.)



> The comma is just generally used to separate expressions, it's not
> specific to tuples.

Nobody said it was specific to tuples. That would be an absurd thing to 
say. What was said is that the comma is what makes tuples, not the 
brackets.


-- 
Steve



From steve+comp.lang.python at pearwood.info  Wed May 23 02:49:14 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Wed, 23 May 2018 06:49:14 +0000 (UTC)
Subject: "Data blocks" syntax specification draft
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
 <CALwzid=z409FFgG-cBq=VO5u0sHC8J3hutwzn15vT_+fx0zv5A@mail.gmail.com>
 <CAPTjJmpS=9Nxr2aRDPbUfF05C9zOsDCsDnBJC_7=8+dwXB42ww@mail.gmail.com>
 <CALwzidnW5=rpSkDWduHnnjE4FY69VR5gR6Gq48tQQRE49GcHkA@mail.gmail.com>
Message-ID: <pe32t9$d1p$3@blaine.gmane.org>

On Tue, 22 May 2018 09:43:55 -0600, Ian Kelly wrote:

> In other words, the rule is not really as simple as "commas make
> tuples". I stand by what I wrote.

Being pedantic is great, but if you're going to be pedantic, it pays to 
be *absolutely correctly* pedantic *wink*

Chris is right to say "commas make tuples", and never implied that making 
tuples is *all* that commas do. That would be an absurd thing for him to 
say. Fortunately he didn't :-)

If your comment had been posed as an addition to Chris' comment ("By the 
by, commas also do this that and the other...") then it would have been 
unobjectionable. But by posing it as a correction ("Although, if the rule 
were really as simple ...") you left yourself wide-open to be criticised 
in turn for failing to be pedantic *enough*.

Of course commas can be used elsewhere, just as the use of "if" in if 
statements doesn't prevent us from using that same token in the ternary 
if operator.

In the context of the discussion (namely, the mistaken belief that tuples 
are created by parentheses, which we can often leave out) pointing out 
that commas are *also* used as separators in import statements, lists, 
dicts, function parameter lists etc adds noise but no insight to the 
understanding of tuples.


-- 
Steve



From ian.g.kelly at gmail.com  Wed May 23 05:02:48 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Wed, 23 May 2018 03:02:48 -0600
Subject: "Data blocks" syntax specification draft
In-Reply-To: <pe32t9$d1p$3@blaine.gmane.org>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
 <CALwzid=z409FFgG-cBq=VO5u0sHC8J3hutwzn15vT_+fx0zv5A@mail.gmail.com>
 <CAPTjJmpS=9Nxr2aRDPbUfF05C9zOsDCsDnBJC_7=8+dwXB42ww@mail.gmail.com>
 <CALwzidnW5=rpSkDWduHnnjE4FY69VR5gR6Gq48tQQRE49GcHkA@mail.gmail.com>
 <pe32t9$d1p$3@blaine.gmane.org>
Message-ID: <CALwzid=1-cRYO+oc9AA1njX08Er8ukKTDbGgRPZZX0te3B=VRg@mail.gmail.com>

On Wed, May 23, 2018 at 12:49 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Tue, 22 May 2018 09:43:55 -0600, Ian Kelly wrote:
>
>> In other words, the rule is not really as simple as "commas make
>> tuples". I stand by what I wrote.
>
> Being pedantic is great, but if you're going to be pedantic, it pays to
> be *absolutely correctly* pedantic *wink*
>
> Chris is right to say "commas make tuples", and never implied that making
> tuples is *all* that commas do. That would be an absurd thing for him to
> say. Fortunately he didn't :-)
>
> If your comment had been posed as an addition to Chris' comment ("By the
> by, commas also do this that and the other...") then it would have been
> unobjectionable. But by posing it as a correction ("Although, if the rule
> were really as simple ...") you left yourself wide-open to be criticised
> in turn for failing to be pedantic *enough*.

I don't understand why you read that as a correction and not as an
addition. I never said that Chris was *wrong*. I read my comment as
implying that he was correct, and also that there was more to it.
Maybe you are the one who is being overly pedantic.

> Of course commas can be used elsewhere, just as the use of "if" in if
> statements doesn't prevent us from using that same token in the ternary
> if operator.
>
> In the context of the discussion (namely, the mistaken belief that tuples
> are created by parentheses, which we can often leave out) pointing out
> that commas are *also* used as separators in import statements, lists,
> dicts, function parameter lists etc adds noise but no insight to the
> understanding of tuples.

Then you misunderstood my post. My point was not that commas are also
used for other purposes, but that there are other special cases beyond
the empty tuple where commas alone are insufficient and parentheses
are required to create a tuple.


From arj.python at gmail.com  Wed May 23 05:32:14 2018
From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer)
Date: Wed, 23 May 2018 13:32:14 +0400
Subject: "Data blocks" syntax specification draft
In-Reply-To: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
Message-ID: <CADrxXXmEjGtOvE3u03t7z0u7jDNheoYi8dHVAq7o5Q1ovO78AQ@mail.gmail.com>

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

Comments, suggestions are welcome.
>

nice effort

well as far as i've seen, it is more suited as a data standard than a
direct python integration

why?

same as why do we write .json files, xml files, csv files apart as,
in-source you want to emphasize logic, not data

if it works well and is adopted by nice projects etc, then it might make
it's way into py's support by that way

the only downside to a tab-based standard is readability unless you assure
more or less constant word length. same reasons the guys in here explained
to me why we should not align equal signs. if readability is not an issue,
then xml might be your friend

>


From bc at freeuk.com  Wed May 23 06:10:33 2018
From: bc at freeuk.com (bartc)
Date: Wed, 23 May 2018 11:10:33 +0100
Subject: "Data blocks" syntax specification draft
In-Reply-To: <mailman.51.1527058184.18022.python-list@python.org>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
 <mailman.18.1526999168.18022.python-list@python.org>
 <yMYMC.220721$oo.45532@fx35.am4> <pe32pp$d1p$2@blaine.gmane.org>
 <mailman.51.1527058184.18022.python-list@python.org>
Message-ID: <o6bNC.180812$Hc3.145291@fx30.am4>

On 23/05/2018 07:47, Steven D'Aprano wrote:
> On Tue, 22 May 2018 18:51:30 +0100, bartc wrote:
> 
>> On 22/05/2018 15:25, Chris Angelico wrote:
> [...]
>>> The tuple has nothing to do with the parentheses, except for the
>>> special case of the empty tuple. It's the comma.
>>
>> No? Take these:
>>
>>    a = (10,20,30)
>>    a = [10,20,30]
>>    a = {10,20,30}
>>
>> If you print type(a) after each, only one of them is a tuple - the one
>> with the round brackets.
> 
> You haven't done enough testing. All you have done is found that "round
> brackets give a tuple, other brackets don't". But you need to test what
> happens if you take away the brackets to be sure that it is the round
> brackets which create the tuple:
> 
>      a = 10, 20, 30  # take away the ()
> 
> You still get a tuple. Taking away the [] and {} also give tuples.

If ... is a comma-separated sequence of (2 or more) expressions, then:

  Enclosed with:             It yields:

  {...} brackets             Set (or dict with key:value items)
  [...] brackets             List
  (...) brackets             Tuple
   ...  (no) brackets        Tuple

Each ... contains commas. But it is what surrounds ..., or that doesn't 
surround ..., that determines what the construction yields. The commas 
are not specific to tuples.

> What happens if you add extra brackets?
> 
>      a = ((10, 20, 30))  # tuple
>      b = ([10, 20, 30])  # list
>      c = ({10, 20, 30})  # set

0 items within the list:

()    Empty tuple
[]    Empty list
{}    Empty dict

1 item within the list

(x)   Yields x
[x]   List of one item
{x}   Set of one item

Because () is used for normal bracketing of expression terms, it 
requires this special form to denote a tuple:

(x,)  Tuple of one item

which can ALSO be used to form one element lists, sets and dicts.

> What if we take away the commas but leave the brackets? If "brackets make
> tuples", then the commas ought to be optional.
> 
>      a = (10 20 30)  # SyntaxError

This will be a syntax error with [] and {} as well. I never said the 
commas were optional, only that the resulting type depends on bracketing 
(see above)

>> The comma is just generally used to separate expressions, it's not
>> specific to tuples.
> 
> Nobody said it was specific to tuples. That would be an absurd thing to
> say. What was said is that the comma is what makes tuples, not the
> brackets.

Suppose you were parsing Python source, had just processed a term of an 
expression, and the next token was a comma. What came before the term 
may have been (, {, [ or nothing. What comes next, would you call:

   readtuplesequence()

or:

   readexprsequence()

or:

   readexprsequence(type_of_sequence)     # ie. tuple, list etc

(assume recursive descent parser). Since they have to accomplish the 
same thing (read series of comma-separated terms), what would be the 
advantage in having a separate routine just for tuples?


-- 
bartc


From bc at freeuk.com  Wed May 23 06:17:15 2018
From: bc at freeuk.com (bartc)
Date: Wed, 23 May 2018 11:17:15 +0100
Subject: "Data blocks" syntax specification draft
In-Reply-To: <mailman.47.1527055391.18022.python-list@python.org>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
 <CALwzid=z409FFgG-cBq=VO5u0sHC8J3hutwzn15vT_+fx0zv5A@mail.gmail.com>
 <CAPTjJmpS=9Nxr2aRDPbUfF05C9zOsDCsDnBJC_7=8+dwXB42ww@mail.gmail.com>
 <CALwzidnW5=rpSkDWduHnnjE4FY69VR5gR6Gq48tQQRE49GcHkA@mail.gmail.com>
 <CAPTjJmq1+v2XX=ZEM7nzg1FjKuLHcRY-L9LCeK+Z9F=U=C47iQ@mail.gmail.com>
 <mailman.25.1527004641.18022.python-list@python.org>
 <822NC.219460$RH3.27875@fx27.am4>
 <CAPTjJmoRQrmXLEyEnLZWdEec6gQ8bkP0RbT1t2Tg03dFbLOhsQ@mail.gmail.com>
 <mailman.43.1527052950.18022.python-list@python.org>
 <pe2udb$s4m$1@dont-email.me>
 <CAPTjJmo209RiozDBEuPbr-yk1amDP7ZMkrA_0OyxEmBTpkZ9rw@mail.gmail.com>
 <mailman.47.1527055391.18022.python-list@python.org>
Message-ID: <GcbNC.229579$Vm6.37861@fx45.am4>

On 23/05/2018 07:03, Chris Angelico wrote:
> On Wed, May 23, 2018 at 3:32 PM, Christian Gollwitzer <auriocus at gmx.de> wrote:

>> I'd think that the definitive answer is in the grammar, because that is what
>> is used to build the Python parser:
>>
>>          https://docs.python.org/3/reference/grammar.html
>>
>> Actually, I'm a bit surprised that tuple, list etc. does not appear there as
>> a non-terminal. It is a bit hard to find, and it seems that "atom:" is the
>> starting point for parsing tuples, lists etc.
>>
> 
> The grammar's a bit hard to read for this sort of thing, as the only
> hint of semantic meaning is in the labels at the beginning. For
> example, there's a "dictorsetmaker" entry that grammatically could be
> a dict comp or a set comp; distinguishing them is the job of other
> parts of the code.

Looking at all the instances of "','" (and there are plenty), none of 
them are tied to anything to do with tuples. Actually 'tuple' doesn't 
appear at all.

'dict' does, presumably because a dict-constructor is different 
syntactically in requiring key:value pairs.

-- 
bartc


From steve+comp.lang.python at pearwood.info  Wed May 23 07:02:06 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Wed, 23 May 2018 11:02:06 +0000 (UTC)
Subject: "Data blocks" syntax specification draft
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
 <CALwzid=z409FFgG-cBq=VO5u0sHC8J3hutwzn15vT_+fx0zv5A@mail.gmail.com>
 <CAPTjJmpS=9Nxr2aRDPbUfF05C9zOsDCsDnBJC_7=8+dwXB42ww@mail.gmail.com>
 <CALwzidnW5=rpSkDWduHnnjE4FY69VR5gR6Gq48tQQRE49GcHkA@mail.gmail.com>
 <pe32t9$d1p$3@blaine.gmane.org>
 <CALwzid=1-cRYO+oc9AA1njX08Er8ukKTDbGgRPZZX0te3B=VRg@mail.gmail.com>
Message-ID: <pe3hnd$185$1@blaine.gmane.org>

On Wed, 23 May 2018 03:02:48 -0600, Ian Kelly wrote:

> Maybe you are the one who is being overly pedantic.

I resemble that remark!



-- 
Steve



From steve+comp.lang.python at pearwood.info  Wed May 23 09:11:36 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Wed, 23 May 2018 13:11:36 +0000 (UTC)
Subject: "Data blocks" syntax specification draft
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
 <mailman.18.1526999168.18022.python-list@python.org>
 <yMYMC.220721$oo.45532@fx35.am4> <pe32pp$d1p$2@blaine.gmane.org>
 <mailman.51.1527058184.18022.python-list@python.org>
 <o6bNC.180812$Hc3.145291@fx30.am4>
Message-ID: <pe3pa6$185$2@blaine.gmane.org>

On Wed, 23 May 2018 11:10:33 +0100, bartc wrote:

[...]
>> You haven't done enough testing. All you have done is found that "round
>> brackets give a tuple, other brackets don't". But you need to test what
>> happens if you take away the brackets to be sure that it is the round
>> brackets which create the tuple:
>> 
>>      a = 10, 20, 30  # take away the ()
>> 
>> You still get a tuple. Taking away the [] and {} also give tuples.
> 
> If ... is a comma-separated sequence of (2 or more) expressions, then:
> 
>   Enclosed with:             It yields:
> 
>   {...} brackets             Set (or dict with key:value items)
>   [...] brackets             List
>   (...) brackets             Tuple
>    ...  (no) brackets        Tuple

Indeed.

> Each ... contains commas. But it is what surrounds ..., or that doesn't
> surround ..., that determines what the construction yields. The commas
> are not specific to tuples.

Nobody said that they were. You are arguing against a strawman. The 
brackets are not part of tuple syntax. They are sometimes needed for 
grouping, when some other grammatical construct would otherwise take 
precedence. That is all.


>> What happens if you add extra brackets?
>> 
>>      a = ((10, 20, 30))  # tuple
>>      b = ([10, 20, 30])  # list
>>      c = ({10, 20, 30})  # set
> 
> 0 items within the list:
> 
> ()    Empty tuple
> []    Empty list
> {}    Empty dict

Aye ... as we've acknowledged numerous times now, the empty tuple *is* a 
genuine special case, one which *does* rely on an empty pair of round 
brackets.



> 1 item within the list
> 
> (x)   Yields x

Exactly! There is no comma, therefore, there is no tuple.

> [x]   List of one item
> {x}   Set of one item

Neither of these require commas, since you don't need a separator to 
separate a single item. The square brackets *do* specify that the item is 
a list; the curly brackets *do* specify a dict or set. The round brackets 
DO NOT specify a tuple (except in the empty tuple case).

No comma, no tuple, no matter how emphatically you insert round brackets 
around the item.


> Because () is used for normal bracketing of expression terms, it
> requires this special form to denote a tuple:
> 
> (x,)  Tuple of one item

Incorrect. Yet again, you have failed to do enough testing. No special 
form is required. Only a comma:

py> x = 1,
py> type(x)
<class 'tuple'>

It isn't enough to test examples which confirm a hypothesis. You need to 
test examples which also refute it, and see if your hypothesis survives 
the challenge.

Certainly commas are used as separators. They're used as separators in 
many different contexts: import statements, function calls, function 
declarations, class declarations, except statements, list displays, etc. 
We don't dispute that or deny it.

But in the context of "tuple displays" (the official terminology for 
tuple so-called "literal" syntax), the brackets are not part of the tuple 
display. It is the commas that tell the interpreter that the result is a 
tuple:

https://docs.python.org/3/reference/expressions.html#expression-lists

Because commas are used as separators in so many places, there is often a 
clash between one part of the grammar that uses commas and their use in 
tuples, requiring us to disambiguate the syntax with brackets.

https://docs.python.org/3/reference/expressions.html#parenthesized-forms


> which can ALSO be used to form one element lists, sets and dicts.

But *unlike* one-element lists, sets and dicts, where the comma is 
optional, it is *required* for tuples.


[...]
> Suppose you were parsing Python source, had just processed a term of an
> expression, and the next token was a comma. What came before the term
> may have been (, {, [ or nothing. What comes next, would you call:
[...]

I don't even understand what point you think you are making here. But it 
really doesn't matter. Ultimately, the grammar and documentation trumps 
any hypotheses we might have about what the language is doing, and they 
are absolutely clear about what is going on:


https://docs.python.org/3/reference/expressions.html#expression-lists
https://docs.python.org/3/reference/expressions.html#parenthesized-forms


-- 
Steve



From D.Strohl at F5.com  Wed May 23 09:19:04 2018
From: D.Strohl at F5.com (Dan Strohl)
Date: Wed, 23 May 2018 13:19:04 +0000
Subject: "Data blocks" syntax specification draft
In-Reply-To: <CAE6NSRC9tDgMB8_tk8NsVYqLVE8G2YpV1LX3xhB5angE2is5pA@mail.gmail.com>
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
 <pdu324$l8j$1@blaine.gmane.org>
 <CAHiMU6cGz=X4LMcYac=_Us0+9ATPTrJPLZaeXmK07KbnNFSP2A@mail.gmail.com>
 <CAE6NSRA9sNDkL2RgpaUnziRv5ka2j_L4y1rScKoLJSnR+KCXpg@mail.gmail.com>
 <mailman.4.1526955481.18022.python-list@python.org>
 <pe0bn1$8ns$1@dont-email.me>
 <CAE6NSRA4=wxwAWCXpJg9sXZgdDrFY5GN8_JybYg1zwgi-aYCQQ@mail.gmail.com>
 <9bf0783c8b044b348769942bda950043@F5.com>
 <CAE6NSRC9tDgMB8_tk8NsVYqLVE8G2YpV1LX3xhB5angE2is5pA@mail.gmail.com>
Message-ID: <bb119c2471a44481bf431c0f6000148e@F5.com>

First of all, I suggest splitting this into a separate proposal (new thread) that way you will avoid confusion for people who are still considering the older proposal, and for the (probably many) people who have stopped reding the old thread due to some of the more heated conversations in there.

> 
> Though hard-coded knock-out is also very useful, e.g. for this:
> 
> data = /// s4
>         First line indented more (8 spaces)
>     second - less (4 spaces)
> rest code
> 
> So this will preserve formatting.
> 

True, but in everything, there is a balance between flexibility and complexity.  Nothing else in python (that I can think of) forces people to use 4 spaces, that's merely a style thing.  If I want to use 2 spaces, I can, I've seen modules that use 3 spaces for indenting and it works fine.  So, the flexibility of adding the ability to further indent the first line seems to me to be outweighed by the added complexity of this being "different".

> 
> >> data = /// "???"
> >> ??? abc foo bar
> >> ???
> >>
> >> - defines indent character by string: crazy idea but why not.
> >>
> >
> > Nope, don't like this one... It's far enough from Python normal that
> > it seems unlikely to not get through, and (personally at least), I struggle to
> see the benefit.
> 
> Heh, that was merely joke - but OTOH one could use it for hard-coded indent
> sequences:
> 

Yeah, I get it (now <grin> ), I would caution against making jokes in the middle of an already controversial thread.  When they are missed, they tend to be used against your suggestion.


> data = /// "    "
>         First line indented more (8 spaces)
>     second - less (4 spaces)
> rest code
> 
> A bit sloppy look, but it generalizes some uses. But granted - I don't see much
> real applications besides than space and tab indented block anyway - so it's
> under question.
> 
> 
> >> Language  parameter, e.g.:
> >> data = /// t1."yaml"
> >>
> >> -this can be reserved for future usage by code analysis tools or
> >> dynamic syntax highlighting.
> >>
> >
> > I can see where this might be interesting, but again, I just don't see
> > the need,
> 
> I think you're right  - if need a directive for some analysis tool then one can
> make for example a consideration to precede the whole statement with a
> directive, say in a comment:
> 
> # lang "yaml"
> data = /// t
>     first line
>     last line
> rest
> 
> 

Again, you're complicating the thought without really providing enough benefit to it to justify the complication.   Something to keep in mind when you look at most languages, the simpler the language primitives the better, added flexibility can (and should) be added later in modules and functions.  But primitives should have as few caveats as possible, they should work pretty much anywhere with very little needed documentation.  To me, the idea of an indented TQS idea (data-string, data block, whatever) Is interesting.  Extra features are fine, but when they start making it "more complex" to use, then you should back off.

> 
> 
> Also I am thinking about this - there might be one useful 'hack".
> One could even allow single-line usage, e.g.; (with a semicolon)
> 
> data = /// s2:  first line
> 
> - so this would start parsing just after colon :
> "pretending it is block.
> This may be not so fat-fingered-proof and 'inconsistent', but in the end of the
> day, might be a win actually.
> 
> 

If you are thinking about this road, what about instead making another reserved word and approaching it like class or def, for example;

datablock data:
    first line
    second line

Then you can also add functions without "breaking" python approaches like:

datablock data(foo, bar, blah):
    First line
    Second line

(*having thrown this out, I don?t know the parser/compiler well enough to know if this would cause more problems or not).

Being honest, I'm not sure that even these would be enough to get it added without a stronger case, but the further you stray from the python norms, the less likely it is to even get consideration.  

From rosuav at gmail.com  Wed May 23 09:56:10 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 23 May 2018 23:56:10 +1000
Subject: "Data blocks" syntax specification draft
In-Reply-To: <pe3pa6$185$2@blaine.gmane.org>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
 <mailman.18.1526999168.18022.python-list@python.org>
 <yMYMC.220721$oo.45532@fx35.am4> <pe32pp$d1p$2@blaine.gmane.org>
 <mailman.51.1527058184.18022.python-list@python.org>
 <o6bNC.180812$Hc3.145291@fx30.am4> <pe3pa6$185$2@blaine.gmane.org>
Message-ID: <CAPTjJmqwNHr4cC4zEKr3dwA6ATh2EuqLceiFR=dfv0dMJcqmdA@mail.gmail.com>

On Wed, May 23, 2018 at 11:11 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Wed, 23 May 2018 11:10:33 +0100, bartc wrote:
>> 0 items within the list:
>>
>> ()    Empty tuple
>> []    Empty list
>> {}    Empty dict
>
> Aye ... as we've acknowledged numerous times now, the empty tuple *is* a
> genuine special case, one which *does* rely on an empty pair of round
> brackets.

We actually have THREE special cases and only two types that follow
the general case. Here's the general case:

List of three: [1, 2, 3] or [1, 2, 3,]
List of two: [1, 2] or [1, 2,]
List of one: [1] or [1,]
List of zero: []

Dict of three: {1:1, 2:2, 3:3} or {1:1, 2:2, 3:3,}
Dict of two: {1:1, 2:2} or {1:1, 2:2,}
Dict of one: {1:1} or {1:1,}
Dict of zero: {}

Perfect! Now let's try that with other types.

Tuple of three: 1, 2, 3 or 1, 2, 3,
Tuple of two: 1, 2 or 1, 2,
Tuple of one: 1, # no other way to do it
Tuple of zero: ()

Set of three: {1, 2, 3} or {1, 2, 3,}
Set of two: {1, 2} or {1, 2,}
Set of one: {1} or {1,}
Set of zero: set()

The empty set and empty tuple are special, as is the single-element
tuple (you can't omit the comma). So, yes, there are definitely
special cases in the grammar, and they come about because practicality
beats purity. If we wanted perfectly clean grammar with no special
cases, we'd probably have to use two-character bracketings, to ensure
that everything is uniquely spellable, and there'd be no omitting them
from tuples - so it really WOULD be the bracketing characters that
define a tuple. But what would we gain? Very little. A few less
special cases, maybe, in return for needing to write more verbose
syntax for every literal/display type.

ChrisA


From hjp-python at hjp.at  Wed May 23 11:06:42 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Wed, 23 May 2018 17:06:42 +0200
Subject: Usenet Gateway (was: Spam levels.)
In-Reply-To: <ulsagd1kamtcqn20ogpa87k1k5r02oafn2@4ax.com>
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <5b027ca9$0$619$65785112@news.neostrada.pl>
 <20180521144801.GB7508@equipaje> <pdupd4$6ra$1@blaine.gmane.org>
 <20180522195947.hrntcm47wjzvdbcr@hjp.at>
 <pe1vc3$sd$2@blaine.gmane.org>
 <20180522220101.lvp6lsd7x77ndz2g@hjp.at>
 <87sh6i3o74.fsf@handshake.de>
 <ulsagd1kamtcqn20ogpa87k1k5r02oafn2@4ax.com>
Message-ID: <20180523150642.p7ibahlgsl3jkfdo@hjp.at>

On 2018-05-23 10:00:56 -0400, Dennis Lee Bieber wrote:
> On Wed, 23 May 2018 08:01:35 +0200, dieter <dieter at handshake.de> declaimed
> the following:
> 
> >Maybe something went wrong with the integration of your NTTP server
> >with the Gmane one?
> 
> 	GMANE doesn't (to my knowledge) peer to NNTP servers. It provides an
> NNTP interface to archives of /mailing lists/.

I was quite sure that it did, but it is likely that I mis-remember.

I looked into the newsgroup and there are indeed no messages injected by
gmane. Messages posted to gmane are sent to the mailinglist and (like
all other messages from the mailinglist) injected into usenet through
the gateway at uni-berlin.de.

It seems that this gateway changes all message-ids to 
     <mailman.XXX.XXXXXXXXXX.XXXX.python-list at python.org>

Although the message ids look like they are generated by the mailing
list software (they contain "mailman" and "python-list"), they are only
in the usenet postings, not in the messages sent to mailing list
subscriberts, so I think it must be the gateway that generates these
ids.

(I checked this for a few recent messages from the mailing list). 

This is what I thought I saw gmane doing, so it is very likely that I
was mistaken and that it the gateway at uni-berlin.de all along.

I apologize for attributing the error to Gmane.

Are the persons running the gateway reading this list? Could you please
fix this? Changing message-ids is an absolute no-no.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180523/ada168aa/attachment.sig>

From gordon at panix.com  Wed May 23 11:17:57 2018
From: gordon at panix.com (John Gordon)
Date: Wed, 23 May 2018 15:17:57 +0000 (UTC)
Subject: Target WSGI script cannot be loaded as Python module.
References: <e1da20e9-ba1f-41d1-b5ba-56f83377ca4d@googlegroups.com>
 <66f5581a-f3e1-7b2d-fca7-83b3701f1719@mapgears.com>
 <mailman.27.1527018942.18022.python-list@python.org>
 <34bc9890-90c9-473d-bd26-3f62264aa781@googlegroups.com>
Message-ID: <pe40n5$mnp$1@reader1.panix.com>

In <34bc9890-90c9-473d-bd26-3f62264aa781 at googlegroups.com> =?UTF-8?B?zp3Or866zr/Pgg==?= <nikos.at.superhost at gmail.com> writes:

> I have both python installed in parallel.
> python2.7 and python3.6

> I have installed the modules as

> pip3.6 install bottle bottle-pymysql geopip2
> and they were installed successfully.

Is your web server using Python 2 or Python 3 to execute WSGI?

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon at panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"



From arj.python at gmail.com  Wed May 23 11:20:34 2018
From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer)
Date: Wed, 23 May 2018 19:20:34 +0400
Subject: Usenet Gateway (was: Spam levels.)
In-Reply-To: <20180523150642.p7ibahlgsl3jkfdo@hjp.at>
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <5b027ca9$0$619$65785112@news.neostrada.pl>
 <20180521144801.GB7508@equipaje> <pdupd4$6ra$1@blaine.gmane.org>
 <20180522195947.hrntcm47wjzvdbcr@hjp.at> <pe1vc3$sd$2@blaine.gmane.org>
 <20180522220101.lvp6lsd7x77ndz2g@hjp.at> <87sh6i3o74.fsf@handshake.de>
 <ulsagd1kamtcqn20ogpa87k1k5r02oafn2@4ax.com>
 <20180523150642.p7ibahlgsl3jkfdo@hjp.at>
Message-ID: <CADrxXXkj1_r=iOsgHVL5TjFNGhWk4XLELNRxvbZ=yo2AuFtSMg@mail.gmail.com>

can someone explain to me why the mailing list (spam free) is not used by
everybody?

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

>
>


From nikos.at.superhost at gmail.com  Wed May 23 12:01:50 2018
From: nikos.at.superhost at gmail.com (=?UTF-8?B?zp3Or866zr/Pgg==?=)
Date: Wed, 23 May 2018 09:01:50 -0700 (PDT)
Subject: Target WSGI script cannot be loaded as Python module.
In-Reply-To: <pe40n5$mnp$1@reader1.panix.com>
References: <e1da20e9-ba1f-41d1-b5ba-56f83377ca4d@googlegroups.com>
 <66f5581a-f3e1-7b2d-fca7-83b3701f1719@mapgears.com>
 <mailman.27.1527018942.18022.python-list@python.org>
 <34bc9890-90c9-473d-bd26-3f62264aa781@googlegroups.com>
 <pe40n5$mnp$1@reader1.panix.com>
Message-ID: <b7472802-bba6-4f61-973f-b0da51b456d7@googlegroups.com>

?? ???????, 23 ????? 2018 - 6:18:13 ?.?. UTC+3, ? ??????? John Gordon ??????:

> Is your web server using Python 2 or Python 3 to execute WSGI?

I really dont knwo that detail.
How can i check that?

From gheskett at shentel.net  Wed May 23 12:03:46 2018
From: gheskett at shentel.net (Gene Heskett)
Date: Wed, 23 May 2018 12:03:46 -0400
Subject: Usenet Gateway (was: Spam levels.)
In-Reply-To: <CADrxXXkj1_r=iOsgHVL5TjFNGhWk4XLELNRxvbZ=yo2AuFtSMg@mail.gmail.com>
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <20180523150642.p7ibahlgsl3jkfdo@hjp.at>
 <CADrxXXkj1_r=iOsgHVL5TjFNGhWk4XLELNRxvbZ=yo2AuFtSMg@mail.gmail.com>
Message-ID: <201805231203.46607.gheskett@shentel.net>

On Wednesday 23 May 2018 11:20:34 Abdur-Rahmaan Janhangeer wrote:

> can someone explain to me why the mailing list (spam free) is not used
> by everybody?
>
> Abdur-Rahmaan Janhangeer
> https://github.com/Abdur-rahmaanJ

Brain damaged by facebook, AOL, M$, Google, yahoo yadda yadda into 
thinking that webmail and forums are the only game in town?

They can run them thru their browser, and never were taught any 
different. My own ISP is so brain washed by imap users, that fetchmail 
is not allowed to delete what its has pulled, so I have to login to the 
webmail interface every day with a browser and delete by hand, those 
messages I've allready read with kmail. Its a time sink, and a right 
pain in the ass but thats how it is. With fetchmail/procmail/clamav and 
spamassassin handling the incoming mail, I am reduced to hitting the 
plus key to go to the next unread msg, select the reply mode if I reply, 
edit the response, and a ctrl+return sends it. You can't get it any 
simpler than that. Computers were sold to us as a way to do some of our 
work, but mention how my computer does all that for me and those folks 
are totally aghast at the thought of actually getting the computer to do 
it for them.  I ran out of sympathy for those folks nearly 2 decades 
ago, when I had a full house Amiga doing all that for me.

So I lurk here, hoping some python know how might stick to me, and issue 
a rant when I feel its needed. Sorry, but your post was a trigger, so I 
went into rant mode.

Take care now.  And enjoy the list but be aware that at times the spam is 
replaced with snarky stuff. Much of it well earned.

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


From hjp-python at hjp.at  Wed May 23 12:25:35 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Wed, 23 May 2018 18:25:35 +0200
Subject: Indented multi-line strings (was: "Data blocks" syntax specification
 draft)
In-Reply-To: <9bf0783c8b044b348769942bda950043@F5.com>
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
 <pdu324$l8j$1@blaine.gmane.org>
 <CAHiMU6cGz=X4LMcYac=_Us0+9ATPTrJPLZaeXmK07KbnNFSP2A@mail.gmail.com>
 <CAE6NSRA9sNDkL2RgpaUnziRv5ka2j_L4y1rScKoLJSnR+KCXpg@mail.gmail.com>
 <mailman.4.1526955481.18022.python-list@python.org>
 <pe0bn1$8ns$1@dont-email.me>
 <CAE6NSRA4=wxwAWCXpJg9sXZgdDrFY5GN8_JybYg1zwgi-aYCQQ@mail.gmail.com>
 <9bf0783c8b044b348769942bda950043@F5.com>
Message-ID: <20180523162535.xbtqnxi7yqv4ijlg@hjp.at>

On 2018-05-22 23:25:36 +0000, Dan Strohl via Python-list wrote:
> > So, e.g. this:
> > 
> > data = /// s4
> >     first line
> >     last line
> > the rest python code
> > 
> > - will parse the block and knock out leading 4 spaces.
> > i.e. if the first line has 5 leading spaces then 1 space will be left in the string.
> > Block parsing terminates when the next line does not satisfy the indent
> > sequence (4 spaces in this case).
> > Another obvious type: tabs:
> 
> OK, I CAN see this as a potentially useful suggestion.  There are a
> number of times where I would like to define a large chunk of text,
> but using tqs and having it suddenly move to the left is painful
> visually.  Right now, I tend to either a) do it anyway, b) do it in a
> separate module and import the variables, or c) do it and parse the
> string to remove the extra spaces.

Agreed.


> Personally though, I would not hard code it to knock out 4 leading
> spaces.   I would have it handle spaces the same was that the existing
> parser does, if there are 4 spaces indending the next line, then it
> removes 4 spaces, if there are 6 spaces, it removes 6 spaces, etc...
> ignoring additional spaces within the data-string object.  Once it
> hits a line that has the same number if indenting spaces as the
> initial token, the data-string object is finished.

How about this?

    x = ''''
        Here is a multi-line string
            with
          indentation.
        ''''

This would be equivalent to 

    x = 'Here is a multi-line string\n    with\n  indentation.'

Rules:

 * The leading and trailing '''' must be aligned vertically.
 * The contents of the string must be indented at least as far as the
   delimiters (and with consistent tabs/spaces).
   This leading white space is ignored.
 * All the leading white space beyond this 'left edge' is preserved.
 * The newlines after the leading '''' and before the trailing '''' are
   ignored, all the others preserved. (I thought about preserving the
   trailing newline, but it is easier to add one than remove one.)

        hp


-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180523/c077a283/attachment.sig>

From bc at freeuk.com  Wed May 23 12:29:21 2018
From: bc at freeuk.com (bartc)
Date: Wed, 23 May 2018 17:29:21 +0100
Subject: "Data blocks" syntax specification draft
In-Reply-To: <mailman.57.1527081238.18022.python-list@python.org>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
 <mailman.18.1526999168.18022.python-list@python.org>
 <yMYMC.220721$oo.45532@fx35.am4> <pe32pp$d1p$2@blaine.gmane.org>
 <mailman.51.1527058184.18022.python-list@python.org>
 <o6bNC.180812$Hc3.145291@fx30.am4> <pe3pa6$185$2@blaine.gmane.org>
 <mailman.57.1527081238.18022.python-list@python.org>
Message-ID: <vFgNC.128271$3a1.90571@fx11.am4>

On 23/05/2018 14:11, Steven D'Aprano wrote:
> On Wed, 23 May 2018 11:10:33 +0100, bartc wrote:
>> (x,)  Tuple of one item
> 
> Incorrect. Yet again, you have failed to do enough testing. No special
> form is required. Only a comma:
> 
> py> x = 1,
> py> type(x)
> <class 'tuple'>
> 
> It isn't enough to test examples which confirm a hypothesis. You need to
> test examples which also refute it, and see if your hypothesis survives
> the challenge.

I use this trailing comma scheme in my own own languages too. The reason 
is simple, it is to distinguish between these two:

   (x)     Ordinary bracketed expression
   (x)     A list (in my case) of one item.

That is not needed for one less item: (), or one more: (x,y). Like 
Python, that trailing comma is not needed for [x] (I don't have a {...} 
constructor).

In both languages, it's just a hack to get around a syntax clash in the 
language.

I don't say however, that the comma is the defining feature of a list.

Comma is used to separate items of /any/ kind of list, and that trailing 
comma is used when there is an ambiguity or a conflict.

-- 
bartc


From D.Strohl at F5.com  Wed May 23 12:38:25 2018
From: D.Strohl at F5.com (Dan Strohl)
Date: Wed, 23 May 2018 16:38:25 +0000
Subject: Indented multi-line strings (was: "Data blocks" syntax
 specification draft)
In-Reply-To: <20180523162535.xbtqnxi7yqv4ijlg@hjp.at>
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
 <pdu324$l8j$1@blaine.gmane.org>
 <CAHiMU6cGz=X4LMcYac=_Us0+9ATPTrJPLZaeXmK07KbnNFSP2A@mail.gmail.com>
 <CAE6NSRA9sNDkL2RgpaUnziRv5ka2j_L4y1rScKoLJSnR+KCXpg@mail.gmail.com>
 <mailman.4.1526955481.18022.python-list@python.org>
 <pe0bn1$8ns$1@dont-email.me>
 <CAE6NSRA4=wxwAWCXpJg9sXZgdDrFY5GN8_JybYg1zwgi-aYCQQ@mail.gmail.com>
 <9bf0783c8b044b348769942bda950043@F5.com>
 <20180523162535.xbtqnxi7yqv4ijlg@hjp.at>
Message-ID: <c988dae87f8a4a3b9199501dea81e65f@F5.com>


> 
> > Personally though, I would not hard code it to knock out 4 leading
> > spaces.   I would have it handle spaces the same was that the existing
> > parser does, if there are 4 spaces indending the next line, then it
> > removes 4 spaces, if there are 6 spaces, it removes 6 spaces, etc...
> > ignoring additional spaces within the data-string object.  Once it
> > hits a line that has the same number if indenting spaces as the
> > initial token, the data-string object is finished.
> 
> How about this?
> 
>     x = ''''
>         Here is a multi-line string
>             with
>           indentation.
>         ''''
> 
> This would be equivalent to
> 
>     x = 'Here is a multi-line string\n    with\n  indentation.'
> 

Looks right to me, I don't know if the quad quote overloads the ' and " character too much, but I'm not against it.


> Rules:
> 
>  * The leading and trailing '''' must be aligned vertically.
>  * The contents of the string must be indented at least as far as the
>    delimiters (and with consistent tabs/spaces).
>    This leading white space is ignored.
>  * All the leading white space beyond this 'left edge' is preserved.
>  * The newlines after the leading '''' and before the trailing '''' are
>    ignored, all the others preserved. (I thought about preserving the
>    trailing newline, but it is easier to add one than remove one.)
> 
>         hp
> 
> 


These sound good to me.




From cl at isbd.net  Wed May 23 12:45:57 2018
From: cl at isbd.net (Chris Green)
Date: Wed, 23 May 2018 17:45:57 +0100
Subject: Usenet Gateway
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <5b027ca9$0$619$65785112@news.neostrada.pl> <20180521144801.GB7508@equipaje>
 <pdupd4$6ra$1@blaine.gmane.org> <20180522195947.hrntcm47wjzvdbcr@hjp.at>
 <pe1vc3$sd$2@blaine.gmane.org> <20180522220101.lvp6lsd7x77ndz2g@hjp.at>
 <87sh6i3o74.fsf@handshake.de> <ulsagd1kamtcqn20ogpa87k1k5r02oafn2@4ax.com>
 <20180523150642.p7ibahlgsl3jkfdo@hjp.at>
 <CADrxXXkj1_r=iOsgHVL5TjFNGhWk4XLELNRxvbZ=yo2AuFtSMg@mail.gmail.com>
 <mailman.62.1527088849.18022.python-list@python.org>
Message-ID: <5figte-83e.ln1@esprimo.zbmc.eu>

Abdur-Rahmaan Janhangeer <arj.python at gmail.com> wrote:
> can someone explain to me why the mailing list (spam free) is not used by
> everybody?
> 
Because the Usenet/NNTP interface (with a good newsreader) is so much
better! :-)

-- 
Chris Green
?


From bc at freeuk.com  Wed May 23 12:46:39 2018
From: bc at freeuk.com (bartc)
Date: Wed, 23 May 2018 17:46:39 +0100
Subject: "Data blocks" syntax specification draft
In-Reply-To: <mailman.59.1527083774.18022.python-list@python.org>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
 <mailman.18.1526999168.18022.python-list@python.org>
 <yMYMC.220721$oo.45532@fx35.am4> <pe32pp$d1p$2@blaine.gmane.org>
 <mailman.51.1527058184.18022.python-list@python.org>
 <o6bNC.180812$Hc3.145291@fx30.am4> <pe3pa6$185$2@blaine.gmane.org>
 <CAPTjJmqwNHr4cC4zEKr3dwA6ATh2EuqLceiFR=dfv0dMJcqmdA@mail.gmail.com>
 <mailman.59.1527083774.18022.python-list@python.org>
Message-ID: <KVgNC.828394$MD7.676041@fx14.am4>

On 23/05/2018 14:56, Chris Angelico wrote:

> Perfect! Now let's try that with other types.
> 
> Tuple of three: 1, 2, 3 or 1, 2, 3,
Not requiring any bracketing is poor IMO.

If you wanted the tuple to co-exist with any other thing in an 
expression, rather than being the only thing the expression comprises, 
then you will run into problems. Try adding two tuples:

   1, 2, 3 + 4, 5, 6

This in fact gives you 1,2,7,5,6 rather than 5,7,9. (I don't know if 
tuples can actually be added like this, but the point is clear.)

-- 
bartc


From ian.g.kelly at gmail.com  Wed May 23 13:08:48 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Wed, 23 May 2018 11:08:48 -0600
Subject: Indented multi-line strings (was: "Data blocks" syntax
 specification draft)
In-Reply-To: <20180523162535.xbtqnxi7yqv4ijlg@hjp.at>
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
 <pdu324$l8j$1@blaine.gmane.org>
 <CAHiMU6cGz=X4LMcYac=_Us0+9ATPTrJPLZaeXmK07KbnNFSP2A@mail.gmail.com>
 <CAE6NSRA9sNDkL2RgpaUnziRv5ka2j_L4y1rScKoLJSnR+KCXpg@mail.gmail.com>
 <mailman.4.1526955481.18022.python-list@python.org>
 <pe0bn1$8ns$1@dont-email.me>
 <CAE6NSRA4=wxwAWCXpJg9sXZgdDrFY5GN8_JybYg1zwgi-aYCQQ@mail.gmail.com>
 <9bf0783c8b044b348769942bda950043@F5.com>
 <20180523162535.xbtqnxi7yqv4ijlg@hjp.at>
Message-ID: <CALwzidnMYFyxM5cqHZVpEd4KBDx-E51Gzx2gvhMuyPgx90PD9A@mail.gmail.com>

On Wed, May 23, 2018 at 10:25 AM, Peter J. Holzer <hjp-python at hjp.at> wrote:
> How about this?
>
>     x = ''''
>         Here is a multi-line string
>             with
>           indentation.
>         ''''
>
> This would be equivalent to
>
>     x = 'Here is a multi-line string\n    with\n  indentation.'
>
> Rules:
>
>  * The leading and trailing '''' must be aligned vertically.

Ick, why? What's wrong with letting the trailing delimiter be at the
end of a line, or the beginning with no indentation?

>  * The contents of the string must be indented at least as far as the
>    delimiters (and with consistent tabs/spaces).
>    This leading white space is ignored.
>  * All the leading white space beyond this 'left edge' is preserved.
>  * The newlines after the leading '''' and before the trailing '''' are
>    ignored, all the others preserved. (I thought about preserving the
>    trailing newline, but it is easier to add one than remove one.)

How about we instead just use the rules from PEP 257 so that there
aren't two different sets of multi-line string indentation rules to
have to remember?

https://www.python.org/dev/peps/pep-0257/#handling-docstring-indentation

Also, how about using a string prefix character instead of making
quad-quote meaningful? Apart from being hard to visually distinguish
from triple-quote, this would break existing triple-quote strings that
happen to start with the quote character, e.g ''''What?' she asked.'''

I don't know if 'i' would be the right prefix character for this, but
it's unused and is short for 'indented':

b = i'''
    Here is a multi-line string
    with indentation, which is
    determined from the second
    line.'''


From mikhailwas at gmail.com  Wed May 23 13:08:51 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Wed, 23 May 2018 20:08:51 +0300
Subject: Indented multi-line strings
Message-ID: <CAE6NSRAd=9wz4dyRuE8NKBbdSGxGy+Y12GxGehVCWkdFr-8snQ@mail.gmail.com>

On Wed, May 23, 2018 at 4:19 PM, Dan Strohl <D.Strohl at f5.com> wrote:
> First of all, I suggest splitting this into a separate proposal (new thread) that way you will avoid confusion for people who are still considering the older proposal, and for the (probably many) people who have stopped reding the old thread due to some of the more heated conversations in there.
>
>>
>> Though hard-coded knock-out is also very useful, e.g. for this:
>>
>> data = /// s4
>>         First line indented more (8 spaces)
>>     second - less (4 spaces)
>> rest code
>>
>> So this will preserve formatting.
>>

> True, but in everything, there is a balance between
> flexibility and complexity. Nothing else in python
> (that I can think of) forces people to use 4 spaces,
> that's merely a style thing.  If I want to use 2 spaces,
> I can, I've seen modules that use 3 spaces for
> indenting and it works fine.  So, the flexibility of
> adding the ability to further indent the first line seems
> to me to be outweighed by the added complexity
> of this being "different".

I think we might have a misunderstanding here.
I admit I have tendency to use false terms sometimes -
in this case I did not mean "hard-coded", but rather with
parameter which is taken by the parser.

Namely the proposal is to use 'de-dention' parameter in
such form:

data = /// sN         # and
data = /// tN

Where N - is the amount of characters, spaces (s) or
tabs (t).
This should cover most use cases.
It implies of course that the user should know himself
what he is doing.

More concrete example:

def func():
    foobar
    data = /// s2
      first line
      last line
    foobar

will store same data as:
data = "first linelast line"

(assuming of course no trailing spaces were
in original lines)

So obviously the minimal amount in a parameter is 1,
otherwise it will not work at all.

That's actually it. I am inclining to opinion that no
further parameters are necessary, but of course
there might be few other common use case.
IOW it would be not correct to totally disregard
considering some additional options.



>> # lang "yaml"
>> data = /// t
>>     first line
>>     last line
>> rest
>
> Again, you're complicating the thought without really
> [...] primitives should have as few caveats as possible.
> [...] Extra features are fine, but when they start making
> it "more complex" to use, then you should back off.>

I 100% agree with you. In this case it is better to concentrate
on the most 'low-level' behaviour.


>> Also I am thinking about this - there might be one useful 'hack".
>> One could even allow single-line usage, e.g.; (with a semicolon)
>>
>> data = /// s2:  first line
>>
>> - so this would start parsing just after colon :
>> "pretending it is block.
>> This may be not so fat-fingered-proof and 'inconsistent', but in the end of the
>> day, might be a win actually.
>>
>>
>
> If you are thinking about this road, what about
> instead making another reserved word and
> approaching it like class or def, for example;
>
> datablock data:
>     first line
>     second line

Well it looks ok, but traditionally it is forbidden to introduce
any new keywords, unless it is absolutely necessary.


M


From stefan_ml at behnel.de  Wed May 23 13:24:35 2018
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Wed, 23 May 2018 19:24:35 +0200
Subject: Getting Unicode decode error using lxml.iterparse
In-Reply-To: <87o9h63n3u.fsf@handshake.de>
References: <8e9fad93-b802-4ae0-921b-fce559e0621c@googlegroups.com>
 <87o9h63n3u.fsf@handshake.de>
Message-ID: <pe480i$crv$1@blaine.gmane.org>

dieter schrieb am 23.05.2018 um 08:25:
> If the encoding is not specified, "lxml" will try to determine it
> and finally defaults to "utf-8" (which seems to be the correct encoding
> for your case).

Being an XML parser, it does not do that. XML parsers are designed to
reject non-wellformed content, and that includes anything that cannot be
decoded.

In short, if no encoding is specified, then it's UTF-8, but if there is an
XML declaration that specifies that encoding, then it uses that encoding.

Here, the encoding is specifed as UTF-8, so that's what the parser uses.

Note, however, that the library that the OP uses is not lxml but xml.etree,
i.e. the ElementTree XML support in the standard library.

Stefan



From stefan_ml at behnel.de  Wed May 23 13:27:53 2018
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Wed, 23 May 2018 19:27:53 +0200
Subject: Getting Unicode decode error using lxml.iterparse
In-Reply-To: <8e9fad93-b802-4ae0-921b-fce559e0621c@googlegroups.com>
References: <8e9fad93-b802-4ae0-921b-fce559e0621c@googlegroups.com>
Message-ID: <pe486o$prd$1@blaine.gmane.org>

digitig at gmail.com schrieb am 23.05.2018 um 00:56:
> I'm trying to read my iTunes library in Python using iterparse. My current stub is:
> 
> ---- Snip ----
> 
> import sys
> import datetime
> import xml.etree.ElementTree as ET
> import argparse
> import re
> 
> class Library:
>     
>     unmarshallers = {
>         # collections
>         "array": lambda x: [v.text for v in x],
>         "dict": lambda x:
>             dict((x[i].text, x[i+1].text) for i in range(0, len(x), 2)),
>         "key": lambda x: x.text or "",
> 
>         # simple types
>         "string": lambda x: x.text or "",
>         "data": lambda x: base64.decodestring(x.text or ""),
>         "date": lambda x: datetime.datetime(*map(int, re.findall("\d+", x.text))),
>         "true": lambda x: True,
>         "false": lambda x: False,
>         "real": lambda x: float(x.text),
>         "integer": lambda x: int(x.text)
>         }
> 
>     def load(self, file):
>         print('Starting...')
>         parser = ET.iterparse(file)
>         for action, elem in parser:
>             unmarshal = self.unmarshallers.get(elem.tag)
>             if unmarshal:
>                 data = unmarshal(elem)
>                 elem.clear()
>                 elem.text = data
>                 print(elem.text)
>             elif elem.tag != "plist":
>                 raise IOError("unknown plist type: %r" % elem.tag)
>         return parser.root[0].text
>     
>     def __init__(self, infile):
>         self.root = self.load(infile)
> 
> if __name__ == "__main__":
>     parser = argparse.ArgumentParser(description = "Parse an iTunes library file to a set of CSV files suitable for import to a database.")
>     parser.add_argument('infile', nargs='?', type=argparse.FileType('r'), default=sys.stdin)
>     args=parser.parse_args()
>     print('Infile = ', args.infile)
>     library = Library(args.infile)
> 
> 
> My input file (reduced to home in on the error) is:
> 
> 
> ---- snip -----
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <plist version="1.0">
> <dict>
> 	<dict>
> 		<key>15078</key>
> 		<dict>
> 			<key>Name</key><string>Part 2. The Death Of Enkidu. Skon P?itele M?ho Mne Zdeptal Te??e</string>
> 		</dict>
> 	</dict>
> </dict>
> </plist>
> 
> ---- snip ----
> 
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <plist version="1.0">
> <dict>
> 	<dict>
> 		<key>15078</key>
> 		<dict>
> 			<key>Name</key><string>Part 2. The Death Of Enkidu. Skon P?itele M?ho Mne Zdeptal Te??e</string>
> 		</dict>
> 	</dict>
> </dict>
> </plist>
> 
> 
> 
> I'm getting an error on one part of the XML:
> 
> 
>  File "C:\Users\digit\Anaconda3\lib\encodings\cp1252.py", line 23, in decode
>     return codecs.charmap_decode(input,self.errors,decoding_table)[0]
> 
> UnicodeDecodeError: 'charmap' codec can't decode byte 0x8d in position 202: character maps to <undefined>
> 
> 
> I suspect the issue is that it's using cp1252.py, which I don't think is UTF-8 as specified in the XML prolog. Is this an iterparse problem, or am I using it wrongly?

You are not showing enough of the stack trace to properly diagnose this
problem, but seeing your code, my educated guess is that the problem is the
encoding of the file *path name* and not the *content* of the XML file.
I.e. it probably cannot even open the file.

Stefan



From D.Strohl at F5.com  Wed May 23 13:35:40 2018
From: D.Strohl at F5.com (Dan Strohl)
Date: Wed, 23 May 2018 17:35:40 +0000
Subject: Indented multi-line strings (was: "Data blocks" syntax
 specification draft)
In-Reply-To: <CALwzidnMYFyxM5cqHZVpEd4KBDx-E51Gzx2gvhMuyPgx90PD9A@mail.gmail.com>
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
 <pdu324$l8j$1@blaine.gmane.org>
 <CAHiMU6cGz=X4LMcYac=_Us0+9ATPTrJPLZaeXmK07KbnNFSP2A@mail.gmail.com>
 <CAE6NSRA9sNDkL2RgpaUnziRv5ka2j_L4y1rScKoLJSnR+KCXpg@mail.gmail.com>
 <mailman.4.1526955481.18022.python-list@python.org>
 <pe0bn1$8ns$1@dont-email.me>
 <CAE6NSRA4=wxwAWCXpJg9sXZgdDrFY5GN8_JybYg1zwgi-aYCQQ@mail.gmail.com>
 <9bf0783c8b044b348769942bda950043@F5.com>
 <20180523162535.xbtqnxi7yqv4ijlg@hjp.at>
 <CALwzidnMYFyxM5cqHZVpEd4KBDx-E51Gzx2gvhMuyPgx90PD9A@mail.gmail.com>
Message-ID: <ea564d22d6bb43f7b748571e60b63433@F5.com>



> 
> How about we instead just use the rules from PEP 257 so that there aren't two
> different sets of multi-line string indentation rules to have to remember?
> 
> https://www.python.org/dev/peps/pep-0257/#handling-docstring-indentation
> 


I like that, better to be closer to the existing standards. One could then see this as an extension of the doc-strings.

> Also, how about using a string prefix character instead of making quad-quote
> meaningful? Apart from being hard to visually distinguish from triple-quote,
> this would break existing triple-quote strings that happen to start with the
> quote character, e.g ''''What?' she asked.'''
> 
> I don't know if 'i' would be the right prefix character for this, but it's unused
> and is short for 'indented':
> 

Or go with a different character (or set of characters) altogether... like $, \, ~, ^, < ? (good catch on it  catching on ''''hello' I am not in this''', I forgot about that behavior)

I'm not against a prefix character, just throwing out alternatives. (though, to me, the 'i' indicated int)




From rosuav at gmail.com  Wed May 23 13:42:04 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Thu, 24 May 2018 03:42:04 +1000
Subject: Indented multi-line strings (was: "Data blocks" syntax
 specification draft)
In-Reply-To: <CALwzidnMYFyxM5cqHZVpEd4KBDx-E51Gzx2gvhMuyPgx90PD9A@mail.gmail.com>
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
 <pdu324$l8j$1@blaine.gmane.org>
 <CAHiMU6cGz=X4LMcYac=_Us0+9ATPTrJPLZaeXmK07KbnNFSP2A@mail.gmail.com>
 <CAE6NSRA9sNDkL2RgpaUnziRv5ka2j_L4y1rScKoLJSnR+KCXpg@mail.gmail.com>
 <mailman.4.1526955481.18022.python-list@python.org>
 <pe0bn1$8ns$1@dont-email.me>
 <CAE6NSRA4=wxwAWCXpJg9sXZgdDrFY5GN8_JybYg1zwgi-aYCQQ@mail.gmail.com>
 <9bf0783c8b044b348769942bda950043@F5.com>
 <20180523162535.xbtqnxi7yqv4ijlg@hjp.at>
 <CALwzidnMYFyxM5cqHZVpEd4KBDx-E51Gzx2gvhMuyPgx90PD9A@mail.gmail.com>
Message-ID: <CAPTjJmpiqr+SpBcU0yc5bgs_qv-EVuLF_g28DLUrA3PURhTbwA@mail.gmail.com>

On Thu, May 24, 2018 at 3:08 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> I don't know if 'i' would be the right prefix character for this, but
> it's unused and is short for 'indented':
>
> b = i'''
>     Here is a multi-line string
>     with indentation, which is
>     determined from the second
>     line.'''

Since this doesn't change the way the string is parsed, it doesn't
actually NEED to be a prefix letter. I'd like to see this instead:

b = '''
    Here is a multi-line string
    with indentation, which is
    determined from the second
    line.'''.dedent()

Implemented as a string method, it would be completely syntactically
forwards and backwards compatible, and could be easily documented
(s.dedent() <=> textwrap.dedent(s)). And methods on literals are open
to being optimized, as there's no way to mess with imports or
anything.

ChrisA


From grant.b.edwards at gmail.com  Wed May 23 13:58:31 2018
From: grant.b.edwards at gmail.com (Grant Edwards)
Date: Wed, 23 May 2018 17:58:31 +0000 (UTC)
Subject: Usenet Gateway (was: Spam levels.)
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <5b027ca9$0$619$65785112@news.neostrada.pl>
 <20180521144801.GB7508@equipaje> <pdupd4$6ra$1@blaine.gmane.org>
 <20180522195947.hrntcm47wjzvdbcr@hjp.at> <pe1vc3$sd$2@blaine.gmane.org>
 <20180522220101.lvp6lsd7x77ndz2g@hjp.at> <87sh6i3o74.fsf@handshake.de>
 <ulsagd1kamtcqn20ogpa87k1k5r02oafn2@4ax.com>
 <20180523150642.p7ibahlgsl3jkfdo@hjp.at>
 <CADrxXXkj1_r=iOsgHVL5TjFNGhWk4XLELNRxvbZ=yo2AuFtSMg@mail.gmail.com>
Message-ID: <pe4a47$uvf$1@blaine.gmane.org>

On 2018-05-23, Abdur-Rahmaan Janhangeer <arj.python at gmail.com> wrote:

> can someone explain to me why the mailing list (spam free) is not used by
> everybody?

 1) I perfer the user-interface offered by my NNTP client (slrn).

 2) I don't want to archive many years worth of dozens of mailing
    lists (I let gmane do that).

-- 
Grant Edwards               grant.b.edwards        Yow! I have many CHARTS
                                  at               and DIAGRAMS..
                              gmail.com            



From ned at nedbatchelder.com  Wed May 23 13:58:53 2018
From: ned at nedbatchelder.com (Ned Batchelder)
Date: Wed, 23 May 2018 13:58:53 -0400
Subject: Usenet Gateway
In-Reply-To: <201805231203.46607.gheskett@shentel.net>
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <20180523150642.p7ibahlgsl3jkfdo@hjp.at>
 <CADrxXXkj1_r=iOsgHVL5TjFNGhWk4XLELNRxvbZ=yo2AuFtSMg@mail.gmail.com>
 <201805231203.46607.gheskett@shentel.net>
Message-ID: <2f227ad4-e7be-7f70-4ab4-307e45166187@nedbatchelder.com>

On 5/23/18 12:03 PM, Gene Heskett wrote:
> On Wednesday 23 May 2018 11:20:34 Abdur-Rahmaan Janhangeer wrote:
>
>> can someone explain to me why the mailing list (spam free) is not used
>> by everybody?
>>
>> Abdur-Rahmaan Janhangeer
>> https://github.com/Abdur-rahmaanJ
> Brain damaged by facebook, AOL, M$, Google, yahoo yadda yadda into
> thinking that webmail and forums are the only game in town?
>
>

Please avoid accusing others of being brain damaged, even if it was 
meant in a humorous context. :(

--Ned.


From python at mrabarnett.plus.com  Wed May 23 14:01:19 2018
From: python at mrabarnett.plus.com (MRAB)
Date: Wed, 23 May 2018 19:01:19 +0100
Subject: how to handle captcha through machanize module or any module
In-Reply-To: <1ed2f890-4181-4a39-97d9-42c0c5fc0524@googlegroups.com>
References: <2b488aa4-5698-4be8-b272-7f93c49d154c@googlegroups.com>
 <1ed2f890-4181-4a39-97d9-42c0c5fc0524@googlegroups.com>
Message-ID: <8db5670f-8728-b464-4492-e6140296c9f2@mrabarnett.plus.com>

On 2018-05-23 06:22, SACHIN CHAVAN wrote:
> On Wednesday, December 18, 2013 at 6:26:17 PM UTC+5:30, Jai wrote:
>> please do replay how to handle captcha through machanize module
> 
> I have the same issue, nothing find a solution yet!
> 
The purpose of captcha is to ensure that talking to a human, not a bot. 
It does that by presenting a task that's impossible, or at least 
extremely difficult, to do, so it's not surprising that you haven't 
found a solution.


From grant.b.edwards at gmail.com  Wed May 23 14:03:41 2018
From: grant.b.edwards at gmail.com (Grant Edwards)
Date: Wed, 23 May 2018 18:03:41 +0000 (UTC)
Subject: Usenet Gateway
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <5b027ca9$0$619$65785112@news.neostrada.pl>
 <20180521144801.GB7508@equipaje> <pdupd4$6ra$1@blaine.gmane.org>
 <20180522195947.hrntcm47wjzvdbcr@hjp.at> <pe1vc3$sd$2@blaine.gmane.org>
 <20180522220101.lvp6lsd7x77ndz2g@hjp.at> <87sh6i3o74.fsf@handshake.de>
 <ulsagd1kamtcqn20ogpa87k1k5r02oafn2@4ax.com>
 <20180523150642.p7ibahlgsl3jkfdo@hjp.at>
 <CADrxXXkj1_r=iOsgHVL5TjFNGhWk4XLELNRxvbZ=yo2AuFtSMg@mail.gmail.com>
 <mailman.62.1527088849.18022.python-list@python.org>
 <5figte-83e.ln1@esprimo.zbmc.eu>
Message-ID: <pe4adt$uvf$2@blaine.gmane.org>

On 2018-05-23, Chris Green <cl at isbd.net> wrote:
> Abdur-Rahmaan Janhangeer <arj.python at gmail.com> wrote:
>> can someone explain to me why the mailing list (spam free) is not used by
>> everybody?
>
> Because the Usenet/NNTP interface (with a good newsreader) is so much
> better! :-)

Yes.  NNTP and NNTP clients were designed from the ground up to deal
with ongoing discussions shared by large groups of people posting lots
of messages, and they're _very_ good at.

Email was designed for one person sending one message to another.

Over the years, people have cobbled together bits and pieces and
features to try to make it work for shared discussions. As a result,
mailing lists mostly work (especially for low-volume "groups") and are
pretty decent compared to "web forums" and other such wastes of
electrons.

But IMO email pales in comparison to NNTP when there are more than a
few messages per day per group.

-- 
Grant Edwards               grant.b.edwards        Yow! ... I have read the
                                  at               INSTRUCTIONS ...
                              gmail.com            



From rosuav at gmail.com  Wed May 23 14:12:28 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Thu, 24 May 2018 04:12:28 +1000
Subject: how to handle captcha through machanize module or any module
In-Reply-To: <8db5670f-8728-b464-4492-e6140296c9f2@mrabarnett.plus.com>
References: <2b488aa4-5698-4be8-b272-7f93c49d154c@googlegroups.com>
 <1ed2f890-4181-4a39-97d9-42c0c5fc0524@googlegroups.com>
 <8db5670f-8728-b464-4492-e6140296c9f2@mrabarnett.plus.com>
Message-ID: <CAPTjJmrHeJ+o52Nf6W-BSCtBmpc0Ba+MvprpoUwCWEY6VALxvA@mail.gmail.com>

On Thu, May 24, 2018 at 4:01 AM, MRAB <python at mrabarnett.plus.com> wrote:
> On 2018-05-23 06:22, SACHIN CHAVAN wrote:
>>
>> On Wednesday, December 18, 2013 at 6:26:17 PM UTC+5:30, Jai wrote:
>>>
>>> please do replay how to handle captcha through machanize module
>>
>>
>> I have the same issue, nothing find a solution yet!
>>
> The purpose of captcha is to ensure that talking to a human, not a bot. It
> does that by presenting a task that's impossible, or at least extremely
> difficult, to do, so it's not surprising that you haven't found a solution.

Obligatory XKCD: https://xkcd.com/810/ (caution, language - contains a
precision F-strike)

ChrisA


From mikhailwas at gmail.com  Wed May 23 14:36:38 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Wed, 23 May 2018 21:36:38 +0300
Subject: Indented multi-line strings
In-Reply-To: <CAE6NSRAd=9wz4dyRuE8NKBbdSGxGy+Y12GxGehVCWkdFr-8snQ@mail.gmail.com>
References: <CAE6NSRAd=9wz4dyRuE8NKBbdSGxGy+Y12GxGehVCWkdFr-8snQ@mail.gmail.com>
Message-ID: <CAE6NSRB7oSbyp8tYuY458QiKzd3uxs+irYGBZbY4P-vKtyStRg@mail.gmail.com>

On Wed, May 23, 2018 at 8:08 PM, Mikhail V <mikhailwas at gmail.com> wrote:
> On Wed, May 23, 2018 at 4:19 PM, Dan Strohl <D.Strohl at f5.com> wrote:

> data = /// sN         # and
> data = /// tN
>
> Where N - is the amount of characters, spaces (s) or
> tabs (t).
> This should cover most use cases.
> It implies of course that the user should know himself
> what he is doing.
>
> More concrete example:
>
> def func():
>     foobar
>     data = /// s2
>       first line
>       last line
>     foobar
>
> will store same data as:
> data = "first linelast line"

oops, I meant it to be:
data = "first line\nlast line"

sorry for possible confusion

>
> (assuming of course no trailing spaces were
> in original lines)


From Joseph.Schachner at Teledyne.com  Wed May 23 15:58:37 2018
From: Joseph.Schachner at Teledyne.com (Schachner, Joseph)
Date: Wed, 23 May 2018 19:58:37 +0000
Subject: "Data blocks" syntax specification draft
In-Reply-To: <CAPTjJmqwNHr4cC4zEKr3dwA6ATh2EuqLceiFR=dfv0dMJcqmdA@mail.gmail.com>
References: <CAE6NSRC82dn6LrhqxqLWDyLvbYw8wkZW-BoA120WHt-Ry8zk5w@mail.gmail.com>
 <mailman.248.1526785116.2761.python-list@python.org>
 <MezMC.257592$6D.186888@fx05.am4>
 <CAE6NSRBXxgsSWOQYA9LHvLJDeM6mx+Yb4_+OE4aeo9gQD1hhfg@mail.gmail.com>
 <mailman.7.1526957382.18022.python-list@python.org>
 <VeSMC.135109$ga6.33227@fx24.am4>
 <CAPTjJmoVfjVvFiOtq-t6amV0ZV1dpAAUhWEsa8cOJbfYG57ekA@mail.gmail.com>
 <mailman.18.1526999168.18022.python-list@python.org>
 <yMYMC.220721$oo.45532@fx35.am4> <pe32pp$d1p$2@blaine.gmane.org>
 <mailman.51.1527058184.18022.python-list@python.org>
 <o6bNC.180812$Hc3.145291@fx30.am4> <pe3pa6$185$2@blaine.gmane.org>
 <CAPTjJmqwNHr4cC4zEKr3dwA6ATh2EuqLceiFR=dfv0dMJcqmdA@mail.gmail.com>
Message-ID: <e4432a929f584d6580abcc39f5352d7f@Teledyne.com>

I understand that the /// data representation is meant to emphasize data structure (and de-emphasize existing Python syntax for that purpose).  It's already been discussed that Python can export to pickle format, JSON, csv, XML and possibly others I can't think of right now.  So having a data representation format is not a foreign concept.

All I want to say is that I don't really feel that there is a need for another data representation.  Also, even if we leave out parentheses, "/// a,b,c" is 9 characters, whereas "(a,b,c)" is 7 characters. And "a,b,c" is only 5 characters.  I think I would actually prefer the usual Python syntax, because to me it is clear (I already know Python) and typing fewer characters to achieve the same result appeals to me.

Perhaps I just don't value the benefit of this data representation technique, or perhaps there really is a benefit that I didn't get. If so forgive me.  But I do think that a good exposition of the benefit obtained by using this data representation will need to be made, or you may find that there are many other people like me.

--- Joseph S.



-----Original Message-----
From: Chris Angelico <rosuav at gmail.com> 
Sent: Wednesday, May 23, 2018 9:56 AM
To: Python <python-list at python.org>
Subject: Re: "Data blocks" syntax specification draft

On Wed, May 23, 2018 at 11:11 PM, Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
> On Wed, 23 May 2018 11:10:33 +0100, bartc wrote:
>> 0 items within the list:
>>
>> ()    Empty tuple
>> []    Empty list
>> {}    Empty dict
>
> Aye ... as we've acknowledged numerous times now, the empty tuple *is* 
> a genuine special case, one which *does* rely on an empty pair of 
> round brackets.

We actually have THREE special cases and only two types that follow the general case. Here's the general case:

List of three: [1, 2, 3] or [1, 2, 3,]
List of two: [1, 2] or [1, 2,]
List of one: [1] or [1,]
List of zero: []

Dict of three: {1:1, 2:2, 3:3} or {1:1, 2:2, 3:3,} Dict of two: {1:1, 2:2} or {1:1, 2:2,} Dict of one: {1:1} or {1:1,} Dict of zero: {}

Perfect! Now let's try that with other types.

Tuple of three: 1, 2, 3 or 1, 2, 3,
Tuple of two: 1, 2 or 1, 2,
Tuple of one: 1, # no other way to do it Tuple of zero: ()

Set of three: {1, 2, 3} or {1, 2, 3,}
Set of two: {1, 2} or {1, 2,}
Set of one: {1} or {1,}
Set of zero: set()

The empty set and empty tuple are special, as is the single-element tuple (you can't omit the comma). So, yes, there are definitely special cases in the grammar, and they come about because practicality beats purity. If we wanted perfectly clean grammar with no special cases, we'd probably have to use two-character bracketings, to ensure that everything is uniquely spellable, and there'd be no omitting them from tuples - so it really WOULD be the bracketing characters that define a tuple. But what would we gain? Very little. A few less special cases, maybe, in return for needing to write more verbose syntax for every literal/display type.

ChrisA


From drsalists at gmail.com  Wed May 23 16:27:43 2018
From: drsalists at gmail.com (Dan Stromberg)
Date: Wed, 23 May 2018 13:27:43 -0700
Subject: best way to remove leading zeros from a tuple like string
In-Reply-To: <189bca64-1c7e-459f-a8a2-59db0e1752f8@googlegroups.com>
References: <189bca64-1c7e-459f-a8a2-59db0e1752f8@googlegroups.com>
Message-ID: <CAGGBd_pvmeynEDZa_y+FGrMRNX9gtQSo-hMbAgK8-hyUTPVFhA@mail.gmail.com>

On Sun, May 20, 2018 at 12:54 PM,  <bruceg113355 at gmail.com> wrote:
> Lets say I have the following tuple like string.
>   (128, 020, 008, 255)
>
> What is the best way to to remove leading zeroes and end up with the following.
>   (128, 20, 8, 255)        -- I do not care about spaces
>
> This is the solution I came up with
>     s = "(128, 020, 008, 255)"
>     v = s.replace ("(", "")
>     v = v.replace (")", "")
>     vv = ",".join([str(int(i)) for i in v.split(",")])
>     final = "(" + vv + ")"

I actually like your solution pretty well - especially the splitting
on "," and applying int() to the pieces. If you want a simple regex
solution though, the following should work on Python 1.5 through
3.7b3:

$ pythons --command 'import re; print("(" + re.sub("(\(| )0*", "",
"(128, 020, 008, 255)"))'
below cmd output started 2018 Wed May 23 01:23:00 PM PDT
/usr/local/cpython-1.0/bin/python (1.0.1) bad
    Traceback (innermost last):
      File "<string>", line 1
    ImportError: No module named re
/usr/local/cpython-1.1/bin/python (1.1) bad
    Traceback (innermost last):
      File "<string>", line 1, in ?
    ImportError: No module named re
/usr/local/cpython-1.2/bin/python (1.2) bad
    Traceback (innermost last):
      File "<string>", line 1, in ?
    ImportError: No module named re
/usr/local/cpython-1.3/bin/python (1.3) bad
    Traceback (innermost last):
      File "<string>", line 1, in ?
    ImportError: No module named re
/usr/local/cpython-1.4/bin/python (1.4) bad
    Traceback (innermost last):
      File "<string>", line 1, in ?
    ImportError: No module named re
/usr/local/cpython-1.5/bin/python (1.5.2) good (128,20,8,255)
/usr/local/cpython-1.6/bin/python (1.6.1) good (128,20,8,255)
/usr/local/cpython-2.0/bin/python (2.0.1) good (128,20,8,255)
/usr/local/cpython-2.1/bin/python (2.1.0) good (128,20,8,255)
/usr/local/cpython-2.2/bin/python (2.2.0) good (128,20,8,255)
/usr/local/cpython-2.3/bin/python (2.3.0) good (128,20,8,255)
/usr/local/cpython-2.4/bin/python (2.4.0) good (128,20,8,255)
/usr/local/cpython-2.5/bin/python (2.5.6) good (128,20,8,255)
/usr/local/cpython-2.6/bin/python (2.6.9) good (128,20,8,255)
/usr/local/cpython-2.7/bin/python (2.7.13) good (128,20,8,255)
/usr/local/cpython-3.0/bin/python (3.0.1) good (128,20,8,255)
/usr/local/cpython-3.1/bin/python (3.1.5) good (128,20,8,255)
/usr/local/cpython-3.2/bin/python (3.2.5) good (128,20,8,255)
/usr/local/cpython-3.3/bin/python (3.3.3) good (128,20,8,255)
/usr/local/cpython-3.4/bin/python (3.4.2) good (128,20,8,255)
/usr/local/cpython-3.5/bin/python (3.5.0) good (128,20,8,255)
/usr/local/cpython-3.6/bin/python (3.6.0) good (128,20,8,255)
/usr/local/cpython-3.7/bin/python (3.7.0b3) good (128,20,8,255)
/usr/local/jython-2.7/bin/jython (2.7.0) good (128,20,8,255)
/usr/local/pypy-5.10.0/bin/pypy (2.7.13) good (128,20,8,255)
/usr/local/pypy-5.3.1/bin/pypy (2.7.10) good (128,20,8,255)
/usr/local/pypy-5.9.0/bin/pypy (2.7.13) good (128,20,8,255)
/usr/local/pypy-6.0.0/bin/pypy (2.7.13) good (128,20,8,255)
/usr/local/pypy3-5.10.0/bin/pypy3 (3.5.3) good (128,20,8,255)
/usr/local/pypy3-5.5.0/bin/pypy3 (3.3.5) good (128,20,8,255)
/usr/local/pypy3-5.8.0-with-lzma-fixes/bin/pypy3 (3.5.3) good (128,20,8,255)
/usr/local/pypy3-5.8.0/bin/pypy3 (3.5.3) good (128,20,8,255)
/usr/local/pypy3-5.9.0/bin/pypy3 (3.5.3) good (128,20,8,255)
/usr/local/pypy3-6.0.0/bin/pypy3 (3.5.3) good (128,20,8,255)
/usr/local/micropython-git-2017-06-16/bin/micropython (3.4.0) good
(128,20,8,255)

HTH


From mike.junk.46 at att.net  Wed May 23 16:31:24 2018
From: mike.junk.46 at att.net (Mike McClain)
Date: Wed, 23 May 2018 13:31:24 -0700
Subject: decorat{or,ion}
In-Reply-To: <87in7hscu1.fsf@handshake.de>
References: <mailman.30.1526659203.31214.python-list@python.org>
 <20180519013116.GA16615@playground> <87in7kmaf0.fsf@handshake.de>
 <20180520010746.GA6699@playground> <87in7hscu1.fsf@handshake.de>
Message-ID: <20180523203124.GA5932@playground>

On Mon, May 21, 2018 at 09:11:02AM +0200, dieter wrote:
< lots if good info snipped >

Hi dieter,
    I'm still working my way through the info you posted
and making sense of it (mostly)
but didn't want to wait any longer to say 'Thanks.'

Thanks,
Mike
--
Even duct tape can't fix stupid ... But it can muffle the sound.


From python at mrabarnett.plus.com  Wed May 23 16:45:06 2018
From: python at mrabarnett.plus.com (MRAB)
Date: Wed, 23 May 2018 21:45:06 +0100
Subject: Indented multi-line strings
In-Reply-To: <CAE6NSRB7oSbyp8tYuY458QiKzd3uxs+irYGBZbY4P-vKtyStRg@mail.gmail.com>
References: <CAE6NSRAd=9wz4dyRuE8NKBbdSGxGy+Y12GxGehVCWkdFr-8snQ@mail.gmail.com>
 <CAE6NSRB7oSbyp8tYuY458QiKzd3uxs+irYGBZbY4P-vKtyStRg@mail.gmail.com>
Message-ID: <11d07abb-31be-814c-f924-130065e49a76@mrabarnett.plus.com>

On 2018-05-23 19:36, Mikhail V wrote:
> On Wed, May 23, 2018 at 8:08 PM, Mikhail V <mikhailwas at gmail.com> wrote:
>> On Wed, May 23, 2018 at 4:19 PM, Dan Strohl <D.Strohl at f5.com> wrote:
> 
>> data = /// sN         # and
>> data = /// tN
>>
>> Where N - is the amount of characters, spaces (s) or
>> tabs (t).
>> This should cover most use cases.
>> It implies of course that the user should know himself
>> what he is doing.
>>
>> More concrete example:
>>
>> def func():
>>     foobar
>>     data = /// s2
>>       first line
>>       last line
>>     foobar
>>
>> will store same data as:
>> data = "first linelast line"
> 
> oops, I meant it to be:
> data = "first line\nlast line"
> 
> sorry for possible confusion
> 
>>
>> (assuming of course no trailing spaces were
>> in original lines)
> 
Instead of the "s2", etc:

def func():
     foobar
     data = >> :
       first line
       last line
     foobar

Leading indentation to the level of the first line would be stripped.

As the last line also ends with '\n', the result should be 'first 
line\nlast line\n'.

If you want additional indentation, then provide a string literal:

def func():
     foobar
     data = >> '    ':
       first line
       last line
     foobar

for '    first line\n    last line\n' or:

def func():
     foobar
     data = >> '\t':
       first line
       last line
     foobar

for '\tfirst line\n\tlast line\n'.


From drsalists at gmail.com  Wed May 23 16:48:16 2018
From: drsalists at gmail.com (Dan Stromberg)
Date: Wed, 23 May 2018 13:48:16 -0700
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>
References: <1a7951080901290824p424caee3jb74b1343ce884916@mail.gmail.com>
 <ec96e1390901290849g507dcb17tf2372e573f4a5bb5@mail.gmail.com>
 <mailman.8292.1233248983.3487.python-list@python.org>
 <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>
Message-ID: <CAGGBd_ru0E8qZYBexoZ9VWVu4RRgATHe+pLYp1Ou9AFEPpk1Sg@mail.gmail.com>

On Sat, May 19, 2018 at 3:58 PM,  <bellcanadardp at gmail.com> wrote:
> On Thursday, 29 January 2009 12:09:29 UTC-5, Anjanesh Lekshminarayanan  wrote:
>> > It does auto-detect it as cp1252- look at the files in the traceback and
>> > you'll see lib\encodings\cp1252.py. Since cp1252 seems to be the wrong
>> > encoding, try opening it as utf-8 or latin1 and see if that fixes it.
>>
>> Thanks a lot ! utf-8 and latin1 were accepted !
>
> hello i am having same issue..i believe the code is written in python 2 and i am running python 3.6..i tried at the interpreter..f =
> open(filename, encoding="utf-8" and also latin-1..but then when i run my file i still get the error...also my line is at 7414..how do you find this line??...is it better to try to run the file .py in python 2??..thnxz

As suggested by others, if this is a text file, request the encoding
from the person who created it.  chardet can't really autodetect all
encodings, and neither can guessing encodings in a more manual way -
though if there's no one to ask, sometimes chardet is better than not
reading the file :)

Or, if the file is not text, if you want to treat it as a binary blob:

$ pythons --command 'file_ = open("/usr/local/pypy3-6.0.0/bin/pypy3",
"rb"); data = file_.read(); print(type(data)); file_.close()'
below cmd output started 2018 Wed May 23 01:43:35 PM PDT
/usr/local/cpython-1.0/bin/python (1.0.1) good <type 'string'>
/usr/local/cpython-1.1/bin/python (1.1) good <type 'string'>
/usr/local/cpython-1.2/bin/python (1.2) good <type 'string'>
/usr/local/cpython-1.3/bin/python (1.3) good <type 'string'>
/usr/local/cpython-1.4/bin/python (1.4) good <type 'string'>
/usr/local/cpython-1.5/bin/python (1.5.2) good <type 'string'>
/usr/local/cpython-1.6/bin/python (1.6.1) good <type 'string'>
/usr/local/cpython-2.0/bin/python (2.0.1) good <type 'string'>
/usr/local/cpython-2.1/bin/python (2.1.0) good <type 'string'>
/usr/local/cpython-2.2/bin/python (2.2.0) good <type 'str'>
/usr/local/cpython-2.3/bin/python (2.3.0) good <type 'str'>
/usr/local/cpython-2.4/bin/python (2.4.0) good <type 'str'>
/usr/local/cpython-2.5/bin/python (2.5.6) good <type 'str'>
/usr/local/cpython-2.6/bin/python (2.6.9) good <type 'str'>
/usr/local/cpython-2.7/bin/python (2.7.13) good <type 'str'>
/usr/local/cpython-3.0/bin/python (3.0.1) good <class 'bytes'>
/usr/local/cpython-3.1/bin/python (3.1.5) good <class 'bytes'>
/usr/local/cpython-3.2/bin/python (3.2.5) good <class 'bytes'>
/usr/local/cpython-3.3/bin/python (3.3.3) good <class 'bytes'>
/usr/local/cpython-3.4/bin/python (3.4.2) good <class 'bytes'>
/usr/local/cpython-3.5/bin/python (3.5.0) good <class 'bytes'>
/usr/local/cpython-3.6/bin/python (3.6.0) good <class 'bytes'>
/usr/local/cpython-3.7/bin/python (3.7.0b3) good <class 'bytes'>
/usr/local/jython-2.7/bin/jython (2.7.0) good <type 'str'>
/usr/local/pypy-5.10.0/bin/pypy (2.7.13) good <type 'str'>
/usr/local/pypy-5.3.1/bin/pypy (2.7.10) good <type 'str'>
/usr/local/pypy-5.9.0/bin/pypy (2.7.13) good <type 'str'>
/usr/local/pypy-6.0.0/bin/pypy (2.7.13) good <type 'str'>
/usr/local/pypy3-5.10.0/bin/pypy3 (3.5.3) good <class 'bytes'>
/usr/local/pypy3-5.5.0/bin/pypy3 (3.3.5) good <class 'bytes'>
/usr/local/pypy3-5.8.0-with-lzma-fixes/bin/pypy3 (3.5.3) good <class 'bytes'>
/usr/local/pypy3-5.8.0/bin/pypy3 (3.5.3) good <class 'bytes'>
/usr/local/pypy3-5.9.0/bin/pypy3 (3.5.3) good <class 'bytes'>
/usr/local/pypy3-6.0.0/bin/pypy3 (3.5.3) good <class 'bytes'>
/usr/local/micropython-git-2017-06-16/bin/micropython (3.4.0) good
<class 'bytes'>

HTH


From bob at mellowood.ca  Wed May 23 16:56:59 2018
From: bob at mellowood.ca (Bob van der Poel)
Date: Wed, 23 May 2018 13:56:59 -0700
Subject: Indented multi-line strings
In-Reply-To: <11d07abb-31be-814c-f924-130065e49a76@mrabarnett.plus.com>
References: <CAE6NSRAd=9wz4dyRuE8NKBbdSGxGy+Y12GxGehVCWkdFr-8snQ@mail.gmail.com>
 <CAE6NSRB7oSbyp8tYuY458QiKzd3uxs+irYGBZbY4P-vKtyStRg@mail.gmail.com>
 <11d07abb-31be-814c-f924-130065e49a76@mrabarnett.plus.com>
Message-ID: <CA+HdcZgj0rKnRBk=uLUWaEeBHM2q4EamW5NxLEaMbeQ+rJBT+w@mail.gmail.com>

On Wed, May 23, 2018 at 1:45 PM, MRAB <python at mrabarnett.plus.com> wrote:

> On 2018-05-23 19:36, Mikhail V wrote:
>
>> On Wed, May 23, 2018 at 8:08 PM, Mikhail V <mikhailwas at gmail.com> wrote:
>>
>>> On Wed, May 23, 2018 at 4:19 PM, Dan Strohl <D.Strohl at f5.com> wrote:
>>>
>>
>> data = /// sN         # and
>>> data = /// tN
>>>
>>> Where N - is the amount of characters, spaces (s) or
>>> tabs (t).
>>> This should cover most use cases.
>>> It implies of course that the user should know himself
>>> what he is doing.
>>>
>>> More concrete example:
>>>
>>> def func():
>>>     foobar
>>>     data = /// s2
>>>       first line
>>>       last line
>>>     foobar
>>>
>>> will store same data as:
>>> data = "first linelast line"
>>>
>>
>> oops, I meant it to be:
>> data = "first line\nlast line"
>>
>> sorry for possible confusion
>>
>>
>>> (assuming of course no trailing spaces were
>>> in original lines)
>>>
>>
>> Instead of the "s2", etc:
>
> def func():
>     foobar
>     data = >> :
>       first line
>       last line
>     foobar
>
> Leading indentation to the level of the first line would be stripped.
>
> As the last line also ends with '\n', the result should be 'first
> line\nlast line\n'.
>
> If you want additional indentation, then provide a string literal:
>
> def func():
>     foobar
>     data = >> '    ':
>       first line
>       last line
>     foobar
>
> for '    first line\n    last line\n' or:
>
> def func():
>     foobar
>     data = >> '\t':
>       first line
>       last line
>     foobar
>
> for '\tfirst line\n\tlast line\n'.
> --
> https://mail.python.org/mailman/listinfo/python-list
>

I think this is getting way too complex to fix a problem which doesn't
exist.

-- 

**** Listen to my FREE CD at http://www.mellowood.ca/music/cedars ****
Bob van der Poel ** Wynndel, British Columbia, CANADA **
EMAIL: bob at mellowood.ca
WWW:   http://www.mellowood.ca


From rosuav at gmail.com  Wed May 23 17:01:38 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Thu, 24 May 2018 07:01:38 +1000
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <CAGGBd_ru0E8qZYBexoZ9VWVu4RRgATHe+pLYp1Ou9AFEPpk1Sg@mail.gmail.com>
References: <1a7951080901290824p424caee3jb74b1343ce884916@mail.gmail.com>
 <ec96e1390901290849g507dcb17tf2372e573f4a5bb5@mail.gmail.com>
 <mailman.8292.1233248983.3487.python-list@python.org>
 <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>
 <CAGGBd_ru0E8qZYBexoZ9VWVu4RRgATHe+pLYp1Ou9AFEPpk1Sg@mail.gmail.com>
Message-ID: <CAPTjJmoRCVEKct0NJ7vwJouCz7NbHZBCmAp3e3qaxHGwOnghvQ@mail.gmail.com>

On Thu, May 24, 2018 at 6:48 AM, Dan Stromberg <drsalists at gmail.com> wrote:
> On Sat, May 19, 2018 at 3:58 PM,  <bellcanadardp at gmail.com> wrote:
>> On Thursday, 29 January 2009 12:09:29 UTC-5, Anjanesh Lekshminarayanan  wrote:
>>> > It does auto-detect it as cp1252- look at the files in the traceback and
>>> > you'll see lib\encodings\cp1252.py. Since cp1252 seems to be the wrong
>>> > encoding, try opening it as utf-8 or latin1 and see if that fixes it.
>>>
>>> Thanks a lot ! utf-8 and latin1 were accepted !
>>
>> hello i am having same issue..i believe the code is written in python 2 and i am running python 3.6..i tried at the interpreter..f =
>> open(filename, encoding="utf-8" and also latin-1..but then when i run my file i still get the error...also my line is at 7414..how do you find this line??...is it better to try to run the file .py in python 2??..thnxz
>
> As suggested by others, if this is a text file, request the encoding
> from the person who created it.  chardet can't really autodetect all
> encodings, and neither can guessing encodings in a more manual way -
> though if there's no one to ask, sometimes chardet is better than not
> reading the file :)

Yep. And if chardet says it's MacCyrillic, it's probably actually
Codepage 1256 - that's been my experience.

ChrisA


From __peter__ at web.de  Wed May 23 17:05:37 2018
From: __peter__ at web.de (Peter Otten)
Date: Wed, 23 May 2018 23:05:37 +0200
Subject: Getting Unicode decode error using lxml.iterparse
References: <8e9fad93-b802-4ae0-921b-fce559e0621c@googlegroups.com>
Message-ID: <pe4kv3$ph9$1@blaine.gmane.org>

digitig at gmail.com wrote:

> I'm trying to read my iTunes library in Python using iterparse. My current
> stub is:

>     parser.add_argument('infile', nargs='?',
>     type=argparse.FileType('r'), default=sys.stdin)

> I'm getting an error on one part of the XML:
> 
> 
>  File "C:\Users\digit\Anaconda3\lib\encodings\cp1252.py", line 23, in
>  decode
>     return codecs.charmap_decode(input,self.errors,decoding_table)[0]
> 
> UnicodeDecodeError: 'charmap' codec can't decode byte 0x8d in position
> 202: character maps to <undefined>

> I suspect the issue is that it's using cp1252.py, which I don't think is
> UTF-8 as specified in the XML prolog. Is this an iterparse problem, or am
> I using it wrongly?

The wrong encoding is specified implicitly in argparse.FileType("r"). Try 
FileType("rb") or FileType("r", encoding="utf-8") instead (my personal 
approach is to avoid FileType completely).




From asa32sd23 at gmail.com  Wed May 23 17:51:27 2018
From: asa32sd23 at gmail.com (asa32sd23 at gmail.com)
Date: Wed, 23 May 2018 14:51:27 -0700 (PDT)
Subject: how to get INDEX count, or last number of Index
Message-ID: <62f2efcf-e1ed-4fda-bff0-c2500324da3f@googlegroups.com>

s = "kitti"

0,1,2,3,4
k,i,t,t,i

how do i retrieve '4'. i know i can do a len(s)-1, but i assume there is a function that gives me last number of index

thanks


From rgaddi at highlandtechnology.invalid  Wed May 23 17:56:14 2018
From: rgaddi at highlandtechnology.invalid (Rob Gaddi)
Date: Wed, 23 May 2018 14:56:14 -0700
Subject: how to get INDEX count, or last number of Index
In-Reply-To: <62f2efcf-e1ed-4fda-bff0-c2500324da3f@googlegroups.com>
References: <62f2efcf-e1ed-4fda-bff0-c2500324da3f@googlegroups.com>
Message-ID: <pe4o1v$rj6$1@dont-email.me>

On 05/23/2018 02:51 PM, asa32sd23 at gmail.com wrote:
> s = "kitti"
> 
> 0,1,2,3,4
> k,i,t,t,i
> 
> how do i retrieve '4'. i know i can do a len(s)-1, but i assume there is a function that gives me last number of index
> 
> thanks
> 

Not sure I'm following your question; len(s)-1 is much faster than 
enumerating over the string just to get the last index.

If what you want is the current index, though, you can look at the 
enumerate function

s='kitti'
for i, c in enumerate(s):
     print(i, ':', c)

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.


From asa32sd23 at gmail.com  Wed May 23 18:03:58 2018
From: asa32sd23 at gmail.com (asa32sd23 at gmail.com)
Date: Wed, 23 May 2018 15:03:58 -0700 (PDT)
Subject: how to get INDEX count, or last number of Index
In-Reply-To: <pe4o1v$rj6$1@dont-email.me>
References: <62f2efcf-e1ed-4fda-bff0-c2500324da3f@googlegroups.com>
 <pe4o1v$rj6$1@dont-email.me>
Message-ID: <e9e3b272-c9fe-409c-a6e7-181b46124877@googlegroups.com>

On Wednesday, May 23, 2018 at 5:56:26 PM UTC-4, Rob Gaddi wrote:
> On 05/23/2018 02:51 PM, asa32sd23 at gmail.com wrote:
> > s = "kitti"
> > 
> > 0,1,2,3,4
> > k,i,t,t,i
> > 
> > how do i retrieve '4'. i know i can do a len(s)-1, but i assume there is a function that gives me last number of index
> > 
> > thanks
> > 
> 
> Not sure I'm following your question; len(s)-1 is much faster than 
> enumerating over the string just to get the last index.
> 
> If what you want is the current index, though, you can look at the 
> enumerate function
> 
> s='kitti'
> for i, c in enumerate(s):
>      print(i, ':', c)
> 
> -- 
> Rob Gaddi, Highland Technology -- www.highlandtechnology.com
> Email address domain is currently out of order.  See above to fix.

hi Rob,

you understand my question. Im new to Python so thought maybe there is a function that returns the last value of the index. BUT if len(s) -1 is the answer. ill go with that.


From bc at freeuk.com  Wed May 23 18:06:18 2018
From: bc at freeuk.com (bartc)
Date: Wed, 23 May 2018 23:06:18 +0100
Subject: how to get INDEX count, or last number of Index
In-Reply-To: <62f2efcf-e1ed-4fda-bff0-c2500324da3f@googlegroups.com>
References: <62f2efcf-e1ed-4fda-bff0-c2500324da3f@googlegroups.com>
Message-ID: <oBlNC.478404$LD3.137794@fx18.am4>

On 23/05/2018 22:51, asa32sd23 at gmail.com wrote:
> s = "kitti"
> 
> 0,1,2,3,4
> k,i,t,t,i
> 
> how do i retrieve '4'. i know i can do a len(s)-1, but i assume there is a function that gives me last number of index

Not for that trivial task. But you can create your own:

  def upb(x): return len(x)-1     # 'upb' means 'upper-bound'

  print (upb("kitti"))            # output: 4


From asa32sd23 at gmail.com  Wed May 23 18:07:41 2018
From: asa32sd23 at gmail.com (asa32sd23 at gmail.com)
Date: Wed, 23 May 2018 15:07:41 -0700 (PDT)
Subject: how to get INDEX count, or last number of Index
In-Reply-To: <62f2efcf-e1ed-4fda-bff0-c2500324da3f@googlegroups.com>
References: <62f2efcf-e1ed-4fda-bff0-c2500324da3f@googlegroups.com>
Message-ID: <e07fae4a-58ec-4fcb-9675-188ef74ba021@googlegroups.com>

On Wednesday, May 23, 2018 at 5:51:42 PM UTC-4, asa3... at gmail.com wrote:
> s = "kitti"
> 
> 0,1,2,3,4
> k,i,t,t,i
> 
> how do i retrieve '4'. i know i can do a len(s)-1, but i assume there is a function that gives me last number of index
> 
> thanks

thanks, it seems just a len(s) -1 is the right way to return it. thanks


From breamoreboy at gmail.com  Wed May 23 18:14:12 2018
From: breamoreboy at gmail.com (Mark Lawrence)
Date: Wed, 23 May 2018 23:14:12 +0100
Subject: how to get INDEX count, or last number of Index
In-Reply-To: <pe4o1v$rj6$1@dont-email.me>
References: <62f2efcf-e1ed-4fda-bff0-c2500324da3f@googlegroups.com>
 <pe4o1v$rj6$1@dont-email.me>
Message-ID: <pe4ovg$ech$1@blaine.gmane.org>

On 23/05/18 22:56, Rob Gaddi wrote:
> On 05/23/2018 02:51 PM, asa32sd23 at gmail.com wrote:
>> s = "kitti"
>>
>> 0,1,2,3,4
>> k,i,t,t,i
>>
>> how do i retrieve '4'. i know i can do a len(s)-1, but i assume there 
>> is a function that gives me last number of index
>>
>> thanks
>>
> 
> Not sure I'm following your question; len(s)-1 is much faster than 
> enumerating over the string just to get the last index.
> 

-1 is even faster.


-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence



From cs at cskk.id.au  Wed May 23 18:31:23 2018
From: cs at cskk.id.au (Cameron Simpson)
Date: Thu, 24 May 2018 08:31:23 +1000
Subject: how to get INDEX count, or last number of Index
In-Reply-To: <pe4ovg$ech$1@blaine.gmane.org>
References: <pe4ovg$ech$1@blaine.gmane.org>
Message-ID: <20180523223123.GA5223@cskk.homeip.net>

On 23May2018 23:14, Mark Lawrence <breamoreboy at gmail.com> wrote:
>On 23/05/18 22:56, Rob Gaddi wrote:
>>On 05/23/2018 02:51 PM, asa32sd23 at gmail.com wrote:
>>>s = "kitti"
>>>
>>>0,1,2,3,4
>>>k,i,t,t,i
>>>
>>>how do i retrieve '4'. i know i can do a len(s)-1, but i assume 
>>>there is a function that gives me last number of index
>>>
>>
>>Not sure I'm following your question; len(s)-1 is much faster than 
>>enumerating over the string just to get the last index.
>
>-1 is even faster.

For fetching the last element, sure. But possibly the OP needs to know the 
actual index. Example use case:

  chars = []
  last_per_char = {}
  for char in "some string here with letters and stuff":
    chars.append(char)
    last_per_char[char] = len(chars) - 1

That's only slightly contrived, but there are plenty of real world situations 
where you accrue data and need to know the absolute position of the latest 
instance of particular records.

Cheers,
Cameron Simpson <cs at cskk.id.au>


From gheskett at shentel.net  Wed May 23 18:32:05 2018
From: gheskett at shentel.net (Gene Heskett)
Date: Wed, 23 May 2018 18:32:05 -0400
Subject: Usenet Gateway
In-Reply-To: <5figte-83e.ln1@esprimo.zbmc.eu>
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <mailman.62.1527088849.18022.python-list@python.org>
 <5figte-83e.ln1@esprimo.zbmc.eu>
Message-ID: <201805231832.05483.gheskett@shentel.net>

On Wednesday 23 May 2018 12:45:57 Chris Green wrote:

> Abdur-Rahmaan Janhangeer <arj.python at gmail.com> wrote:
> > can someone explain to me why the mailing list (spam free) is not
> > used by everybody?
>
> Because the Usenet/NNTP interface (with a good newsreader) is so much
> better! :-)
>
> --
> Chris Green
> ?

You are stating an opinion, but no facts to back it up, so describe your 
environment that makes you write that, please.


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


From cl at isbd.net  Wed May 23 18:39:24 2018
From: cl at isbd.net (Chris Green)
Date: Wed, 23 May 2018 23:39:24 +0100
Subject: Usenet Gateway
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <mailman.62.1527088849.18022.python-list@python.org>
 <5figte-83e.ln1@esprimo.zbmc.eu> <201805231832.05483.gheskett@shentel.net>
 <mailman.87.1527114732.18022.python-list@python.org>
Message-ID: <s57hte-0l7.ln1@esprimo.zbmc.eu>

Gene Heskett <gheskett at shentel.net> wrote:
> On Wednesday 23 May 2018 12:45:57 Chris Green wrote:
> 
> > Abdur-Rahmaan Janhangeer <arj.python at gmail.com> wrote:
> > > can someone explain to me why the mailing list (spam free) is not
> > > used by everybody?
> >
> > Because the Usenet/NNTP interface (with a good newsreader) is so much
> > better! :-)
> >
> 
> You are stating an opinion, but no facts to back it up, so describe your 
> environment that makes you write that, please.
> 
Well from other comments here it seems I'm not alone but anyway:-

    Proper threading etc. is built in

    It's automatically archived and one can search back through
    threads for old postings, this is by design not an add on.

    Kill files and other similar filtering abilities are part of the
    user interface

    Automatic handling of new messages and a means to say "I've read
    everything here".

    I'm sure there's more....

-- 
Chris Green
?


From alan at csail.mit.edu  Wed May 23 19:24:52 2018
From: alan at csail.mit.edu (Alan Bawden)
Date: 23 May 2018 19:24:52 -0400
Subject: Usenet Gateway
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <mailman.62.1527088849.18022.python-list@python.org>
 <5figte-83e.ln1@esprimo.zbmc.eu> <201805231832.05483.gheskett@shentel.net>
 <mailman.87.1527114732.18022.python-list@python.org>
Message-ID: <867enu0xbv.fsf@richard.bawden.org>

Gene Heskett <gheskett at shentel.net> writes:

> You are stating an opinion, but no facts to back it up, so describe your 
> environment that makes you write that, please.

If he describes his environment and why he likes it, will that be a
"fact"?  Or will you dismiss that as just another "opinion"?

You asked:

> can someone explain to me why the mailing list (spam free) is not used by
> everybody?

And the fact is that in many people's opinions, "the Usenet/NNTP interface
(with a good newsreader) is so much better!"  That _is_ the answer to your
question.

I'm using Gnus myself, and I find that for a list/group like this, it works
better than any mail client I have ever used.  The threading support is
excellent.  And the scoring system lets me not only filter out the spam,
but it also lets me tune out the people I think are idiots, who would show
up even on the mailing list.

That's just my opinion, of course.  


From mikhailwas at gmail.com  Wed May 23 19:27:31 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Thu, 24 May 2018 02:27:31 +0300
Subject: Indented multi-line strings
In-Reply-To: <11d07abb-31be-814c-f924-130065e49a76@mrabarnett.plus.com>
References: <CAE6NSRAd=9wz4dyRuE8NKBbdSGxGy+Y12GxGehVCWkdFr-8snQ@mail.gmail.com>
 <CAE6NSRB7oSbyp8tYuY458QiKzd3uxs+irYGBZbY4P-vKtyStRg@mail.gmail.com>
 <11d07abb-31be-814c-f924-130065e49a76@mrabarnett.plus.com>
Message-ID: <CAE6NSRCaX0STrv5VpKRF5MjLS8O5o9dL9nxic=_J+8pA+4UPeg@mail.gmail.com>

On Wed, May 23, 2018 at 11:45 PM, MRAB <python at mrabarnett.plus.com> wrote:

>>> def func():
>>>     foobar
>>>     data = /// s2
>>>       first line
>>>       last line
>>>     foobar
>>>

> Instead of the "s2", etc:
>
> def func():
>     foobar
>     data = >> :
>       first line
>       last line
>     foobar
>
> Leading indentation to the level of the first line would be stripped.
>
> If you want additional indentation, then provide a string literal:
>
> def func():
>     foobar
>     data = >> '    ':
>       first line
>       last line
>     foobar

Such approach has its benefits.
and ">>" looks nice.

So the benefit here is that you make it more
compact - no parameters needed.
But as you see, it just cannot parse the text in
case of positive indent.
Or otherwise I need to edit the text and then, if say I want
to paste it back elsewhere - edit again. This small nuance can
get in the way.
Also semantically - I find it a bit of implication - it's something
automatic.


> As the last line also ends with '\n', the result should be 'first line\nlast
> line\n'.

Sorry, I can't see how this would be beneficial?
This would mean every string will have trailing \n.
Even if it is one word.
Maybe it could help in some cases, for example
if you write a code generator and then append to
a file consequently.
But in general I disagree with this approach.

Also it is counter-intuitive - for example if I open a
text editor and type "a", save it and then read it with
python script - then I get only "a" but not "a\n".

But maybe I am missing something.


From tjreedy at udel.edu  Wed May 23 19:44:50 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 23 May 2018 19:44:50 -0400
Subject: how to get INDEX count, or last number of Index
In-Reply-To: <pe4o1v$rj6$1@dont-email.me>
References: <62f2efcf-e1ed-4fda-bff0-c2500324da3f@googlegroups.com>
 <pe4o1v$rj6$1@dont-email.me>
Message-ID: <pe4u9g$74c$1@blaine.gmane.org>

On 5/23/2018 5:56 PM, Rob Gaddi wrote:
> On 05/23/2018 02:51 PM, asa32sd23 at gmail.com wrote:
>> s = "kitti"
>>
>> 0,1,2,3,4
>> k,i,t,t,i
>>
>> how do i retrieve '4'. i know i can do a len(s)-1,

Use -1, which is the same as len(s)-1 but faster.

 >>> s = 'kitty'
 >>> s[len(s)-1]
'y'
 >>> s[-1]
'y'


-- 
Terry Jan Reedy



From tjreedy at udel.edu  Wed May 23 19:45:38 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 23 May 2018 19:45:38 -0400
Subject: how to get INDEX count, or last number of Index
In-Reply-To: <e07fae4a-58ec-4fcb-9675-188ef74ba021@googlegroups.com>
References: <62f2efcf-e1ed-4fda-bff0-c2500324da3f@googlegroups.com>
 <e07fae4a-58ec-4fcb-9675-188ef74ba021@googlegroups.com>
Message-ID: <pe4ub0$74c$2@blaine.gmane.org>

On 5/23/2018 6:07 PM, asa32sd23 at gmail.com wrote:
> On Wednesday, May 23, 2018 at 5:51:42 PM UTC-4, asa3... at gmail.com wrote:
>> s = "kitti"
>>
>> 0,1,2,3,4
>> k,i,t,t,i
>>
>> how do i retrieve '4'. i know i can do a len(s)-1, but i assume there is a function that gives me last number of index
>>
>> thanks
> 
> thanks, it seems just a len(s) -1 is the right way to return it. thanks

No it is not.  Just use -1

 >>> s = 'kitty'
 >>> s[len(s)-1]
'y'
 >>> s[-1]
'y'

-- 
Terry Jan Reedy



From asa32sd23 at gmail.com  Wed May 23 19:57:48 2018
From: asa32sd23 at gmail.com (asa32sd23 at gmail.com)
Date: Wed, 23 May 2018 16:57:48 -0700 (PDT)
Subject: how to return last condition if other 2 not met?
Message-ID: <894810d9-74fa-4393-a75c-36c762b7fdf0@googlegroups.com>

i want to check/return for 3 conditions, it loops shortest str and finds diff in other
1. if difference is immediate before end of range, return index, exit
2. if string length is same and index loop is done, return 'identical'
3. if neither of above is found. it means the short loop ended and every letter was same so next letter of longer str is the diff, just return idex+1
but my last print statement always print. not sure how to end this

[code]
str1= "kitti cat"
str2= 'kitti catt'
lenStr1= len(str1)
lenStr2= len(str2)

#find shortest str and loop range with this one
if lenStr1 >= lenStr2:
    str= str2
else:
    str= str1
        
# loop each character of shortest string, compare to same index of longer string
# if any difference, exit and return index of difference
for idx in range(len(str)):
    a= str1[idx]
    b= str2[idx]
    if a != b:      #immeditely exit, since non-match found
        print(idx)
        break
    else:
       if len(str1) == len(str2) and idx == len(str1)-1: #if no difference print 'identical'
            print("identical")
            break

print(idx+1)
[/code]


From ben+python at benfinney.id.au  Wed May 23 19:59:14 2018
From: ben+python at benfinney.id.au (Ben Finney)
Date: Thu, 24 May 2018 09:59:14 +1000
Subject: how to handle captcha through machanize module  or any module
References: <2b488aa4-5698-4be8-b272-7f93c49d154c@googlegroups.com>
Message-ID: <85po1lkjot.fsf@benfinney.id.au>

Jai <jaiprakashsingh213 at gmail.com> writes:

> please do replay how to handle captcha through machanize module 

Step 1: ?import mechanize?.

Step 2: be an actual human, and interact manually with the CAPTCHA.

If you are attempting to fool a CAPTCHA with an automated tool, you are
entering an arms race against those who design the CAPTCHA to *prevent*
exactly what you're doing.

Any technique someone can describe to fool the CAPTCHA, will most likely
already be considered as part of the design of the more effective
CAPTCHAs, and so the technique will still not actually work reliably.

So, there is no general answer, other than to stop thinking that's a
race that you can win.

-- 
 \     ?DRM doesn't inconvenience [lawbreakers] ? indeed, over time it |
  `\     trains law-abiding users to become [lawbreakers] out of sheer |
_o__)                        frustration.? ?Charles Stross, 2010-05-09 |
Ben Finney



From gheskett at shentel.net  Wed May 23 20:00:15 2018
From: gheskett at shentel.net (Gene Heskett)
Date: Wed, 23 May 2018 20:00:15 -0400
Subject: Usenet Gateway
In-Reply-To: <867enu0xbv.fsf@richard.bawden.org>
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <mailman.87.1527114732.18022.python-list@python.org>
 <867enu0xbv.fsf@richard.bawden.org>
Message-ID: <201805232000.15721.gheskett@shentel.net>

On Wednesday 23 May 2018 19:24:52 Alan Bawden wrote:

> Gene Heskett <gheskett at shentel.net> writes:
> > You are stating an opinion, but no facts to back it up, so describe
> > your environment that makes you write that, please.
>
> If he describes his environment and why he likes it, will that be a
> "fact"?  Or will you dismiss that as just another "opinion"?
>
> You asked:
> > can someone explain to me why the mailing list (spam free) is not
> > used by everybody?
>
I did not ask that, somebody's quoting is miss adjusted.

> And the fact is that in many people's opinions, "the Usenet/NNTP
> interface (with a good newsreader) is so much better!"  That _is_ the
> answer to your question.

But it wasn't my question.

> I'm using Gnus myself, and I find that for a list/group like this, it
> works better than any mail client I have ever used.  The threading
> support is excellent.  And the scoring system lets me not only filter
> out the spam, but it also lets me tune out the people I think are
> idiots, who would show up even on the mailing list.
>
> That's just my opinion, of course.

Whereas I use kmail, with background helpers that do 99% of the work for 
me. It can search, thread, and all those things that a news reader like 
gnus or slrn can do. kmail is quite configurable, but note this is not 
the new kmail from kde, its the old kmail that TDE uses. Forked from the 
KDE-3.5 repo several years ago, with the emphasis since on fixing bugs 
that Ingo K. had no interest in fixing. In 2018 now, its Just Works(TM). 
But development continues to make it even more stable.

And of course thats just my opinion too. :) 

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


From bc at freeuk.com  Wed May 23 20:46:41 2018
From: bc at freeuk.com (bartc)
Date: Thu, 24 May 2018 01:46:41 +0100
Subject: how to get INDEX count, or last number of Index
In-Reply-To: <mailman.89.1527119101.18022.python-list@python.org>
References: <62f2efcf-e1ed-4fda-bff0-c2500324da3f@googlegroups.com>
 <pe4o1v$rj6$1@dont-email.me> <pe4u9g$74c$1@blaine.gmane.org>
 <mailman.89.1527119101.18022.python-list@python.org>
Message-ID: <KXnNC.206222$ta2.11122@fx03.am4>

On 24/05/2018 00:44, Terry Reedy wrote:
> On 5/23/2018 5:56 PM, Rob Gaddi wrote:
>> On 05/23/2018 02:51 PM, asa32sd23 at gmail.com wrote:
>>> s = "kitti"
>>>
>>> 0,1,2,3,4
>>> k,i,t,t,i
>>>
>>> how do i retrieve '4'. i know i can do a len(s)-1,
> 
> Use -1, which is the same as len(s)-1 but faster.

This illustrates one problem with having a example sequence of values 
being identical to the indices of those values.

I would have used 10,20,30,40,50 so there could be no such mix-up.

Because I assumed here that the OP wanted the index of the last value, 
the '4' they said they wanted, not the last value itself which would be 'i'.

And actually, the subject line seems to confirm that.

In that case, using a '-1' index won't work.

-- 
bartc


From bc at freeuk.com  Wed May 23 20:53:11 2018
From: bc at freeuk.com (bartc)
Date: Thu, 24 May 2018 01:53:11 +0100
Subject: how to get INDEX count, or last number of Index
In-Reply-To: <KXnNC.206222$ta2.11122@fx03.am4>
References: <62f2efcf-e1ed-4fda-bff0-c2500324da3f@googlegroups.com>
 <pe4o1v$rj6$1@dont-email.me> <pe4u9g$74c$1@blaine.gmane.org>
 <mailman.89.1527119101.18022.python-list@python.org>
 <KXnNC.206222$ta2.11122@fx03.am4>
Message-ID: <Q1oNC.195182$eg.144914@fx43.am4>

On 24/05/2018 01:46, bartc wrote:
> On 24/05/2018 00:44, Terry Reedy wrote:
>> On 5/23/2018 5:56 PM, Rob Gaddi wrote:
>>> On 05/23/2018 02:51 PM, asa32sd23 at gmail.com wrote:
>>>> s = "kitti"
>>>>
>>>> 0,1,2,3,4
>>>> k,i,t,t,i
>>>>
>>>> how do i retrieve '4'. i know i can do a len(s)-1,
>>
>> Use -1, which is the same as len(s)-1 but faster.
> 
> This illustrates one problem with having a example sequence of values 
> being identical to the indices of those values.
> 
> I would have used 10,20,30,40,50 so there could be no such mix-up.

Hmm, although my observation is valid, that's not the case here, as the 
0,1,2,3,4 /are/ the indices! Not the list of values of which they are 
trying to access the '4', and which /could/ be obtained with the -1 
index some people are talking about, that added to the confusion.



From python at mrabarnett.plus.com  Wed May 23 20:55:45 2018
From: python at mrabarnett.plus.com (MRAB)
Date: Thu, 24 May 2018 01:55:45 +0100
Subject: how to return last condition if other 2 not met?
In-Reply-To: <894810d9-74fa-4393-a75c-36c762b7fdf0@googlegroups.com>
References: <894810d9-74fa-4393-a75c-36c762b7fdf0@googlegroups.com>
Message-ID: <319353db-f1a6-0d29-1f96-5d7ba843b301@mrabarnett.plus.com>

On 2018-05-24 00:57, asa32sd23 at gmail.com wrote:
> i want to check/return for 3 conditions, it loops shortest str and finds diff in other
> 1. if difference is immediate before end of range, return index, exit
> 2. if string length is same and index loop is done, return 'identical'
> 3. if neither of above is found. it means the short loop ended and every letter was same so next letter of longer str is the diff, just return idex+1
> but my last print statement always print. not sure how to end this
> 
> [code]
> str1= "kitti cat"
> str2= 'kitti catt'
> lenStr1= len(str1)
> lenStr2= len(str2)
> 
> #find shortest str and loop range with this one
> if lenStr1 >= lenStr2:
>      str= str2
> else:
>      str= str1
>          
> # loop each character of shortest string, compare to same index of longer string
> # if any difference, exit and return index of difference
> for idx in range(len(str)):
>      a= str1[idx]
>      b= str2[idx]
>      if a != b:      #immeditely exit, since non-match found
>          print(idx)
>          break
>      else:
>         if len(str1) == len(str2) and idx == len(str1)-1: #if no difference print 'identical'
>              print("identical")
>              break
> 
> print(idx+1)
> [/code]
> 
The 'for' loop (and also the 'while' loop) can have an 'else' clause, 
which is run if it didn't break out of the loop:

for idx in range(len(str)):
     # body of loop
     ...
else:
     # didn't break out of the loop
     print(idx+1)


From tjreedy at udel.edu  Wed May 23 22:37:25 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 23 May 2018 22:37:25 -0400
Subject: how to get INDEX count, or last number of Index
In-Reply-To: <KXnNC.206222$ta2.11122@fx03.am4>
References: <62f2efcf-e1ed-4fda-bff0-c2500324da3f@googlegroups.com>
 <pe4o1v$rj6$1@dont-email.me> <pe4u9g$74c$1@blaine.gmane.org>
 <mailman.89.1527119101.18022.python-list@python.org>
 <KXnNC.206222$ta2.11122@fx03.am4>
Message-ID: <pe58d3$ohn$1@blaine.gmane.org>

On 5/23/2018 8:46 PM, bartc wrote:
> On 24/05/2018 00:44, Terry Reedy wrote:
>> On 5/23/2018 5:56 PM, Rob Gaddi wrote:
>>> On 05/23/2018 02:51 PM, asa32sd23 at gmail.com wrote:
>>>> s = "kitti"
>>>>
>>>> 0,1,2,3,4
>>>> k,i,t,t,i
>>>>
>>>> how do i retrieve '4'. i know i can do a len(s)-1,
>>
>> Use -1, which is the same as len(s)-1 but faster.
> 
> This illustrates one problem with having a example sequence of values 
> being identical to the indices of those values.
> 
> I would have used 10,20,30,40,50 so there could be no such mix-up.
> 
> Because I assumed here that the OP wanted the index of the last value, 
> the '4' they said they wanted, not the last value itself which would be 
> 'i'.
> 
> And actually, the subject line seems to confirm that.
> 
> In that case, using a '-1' index won't work.

You snipped the code that shows that -1 does work to fetch the last 
character.

 >>> s = 'kitty'
 >>> s[len(s)-1]
'y'
 >>> s[-1]
'y'



-- 
Terry Jan Reedy



From mikhailwas at gmail.com  Wed May 23 22:38:20 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Thu, 24 May 2018 05:38:20 +0300
Subject: Indented multi-line strings
In-Reply-To: <CA+HdcZgj0rKnRBk=uLUWaEeBHM2q4EamW5NxLEaMbeQ+rJBT+w@mail.gmail.com>
References: <CAE6NSRAd=9wz4dyRuE8NKBbdSGxGy+Y12GxGehVCWkdFr-8snQ@mail.gmail.com>
 <CAE6NSRB7oSbyp8tYuY458QiKzd3uxs+irYGBZbY4P-vKtyStRg@mail.gmail.com>
 <11d07abb-31be-814c-f924-130065e49a76@mrabarnett.plus.com>
 <CA+HdcZgj0rKnRBk=uLUWaEeBHM2q4EamW5NxLEaMbeQ+rJBT+w@mail.gmail.com>
Message-ID: <CAE6NSRBNZR9PYtdO-89r2oEwRHMg31tM1ZL+aYdsos5ZGmwyKg@mail.gmail.com>

On Wed, May 23, 2018 at 11:56 PM, Bob van der Poel <bob at mellowood.ca> wrote:
> On Wed, May 23, 2018 at 1:45 PM, MRAB <python at mrabarnett.plus.com> wrote:
>
>> If you want additional indentation, then provide a string literal:
>>
>> def func():
>>     foobar
>>     data = >> '    ':
>>       first line
>>       last line
>>     foobar
>>
>> for '    first line\n    last line\n' or:
>>
>> def func():
>>     foobar
>>     data = >> '\t':
>>       first line
>>       last line
>>     foobar
>>
>> for '\tfirst line\n\tlast line\n'.
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
> I think this is getting way too complex to fix a problem which doesn't
> exist.

@Bob
It is not clear at all about which issue are you writing the comment.
Also not clear to whom is it addressed (me or MRAB).

Please - can you be specific and respectful.

And a general note - It is hard to support the conversation when the
amount of rational content becomes low.
May be it surprises you but I _read_ the comments and try to
understand them.



M


From asa32sd23 at gmail.com  Wed May 23 23:11:10 2018
From: asa32sd23 at gmail.com (asa32sd23 at gmail.com)
Date: Wed, 23 May 2018 20:11:10 -0700 (PDT)
Subject: how to return last condition if other 2 not met?
In-Reply-To: <mailman.93.1527123348.18022.python-list@python.org>
References: <894810d9-74fa-4393-a75c-36c762b7fdf0@googlegroups.com>
 <319353db-f1a6-0d29-1f96-5d7ba843b301@mrabarnett.plus.com>
 <mailman.93.1527123348.18022.python-list@python.org>
Message-ID: <2c3f1927-761c-4a43-832a-fb2a45593411@googlegroups.com>

On Wednesday, May 23, 2018 at 8:55:59 PM UTC-4, MRAB wrote:
> On 2018-05-24 00:57, asa32sd23 at gmail.com wrote:
> > i want to check/return for 3 conditions, it loops shortest str and finds diff in other
> > 1. if difference is immediate before end of range, return index, exit
> > 2. if string length is same and index loop is done, return 'identical'
> > 3. if neither of above is found. it means the short loop ended and every letter was same so next letter of longer str is the diff, just return idex+1
> > but my last print statement always print. not sure how to end this
> > 
> > [code]
> > str1= "kitti cat"
> > str2= 'kitti catt'
> > lenStr1= len(str1)
> > lenStr2= len(str2)
> > 
> > #find shortest str and loop range with this one
> > if lenStr1 >= lenStr2:
> >      str= str2
> > else:
> >      str= str1
> >          
> > # loop each character of shortest string, compare to same index of longer string
> > # if any difference, exit and return index of difference
> > for idx in range(len(str)):
> >      a= str1[idx]
> >      b= str2[idx]
> >      if a != b:      #immeditely exit, since non-match found
> >          print(idx)
> >          break
> >      else:
> >         if len(str1) == len(str2) and idx == len(str1)-1: #if no difference print 'identical'
> >              print("identical")
> >              break
> > 
> > print(idx+1)
> > [/code]
> > 
> The 'for' loop (and also the 'while' loop) can have an 'else' clause, 
> which is run if it didn't break out of the loop:
> 
> for idx in range(len(str)):
>      # body of loop
>      ...
> else:
>      # didn't break out of the loop
>      print(idx+1)
---------------------

thats what it was... thank you!! i was stuck in the same thought process and couldnt see it


From greg.ewing at canterbury.ac.nz  Thu May 24 03:25:20 2018
From: greg.ewing at canterbury.ac.nz (Gregory Ewing)
Date: Thu, 24 May 2018 19:25:20 +1200
Subject: Usenet Gateway
In-Reply-To: <mailman.72.1527098338.18022.python-list@python.org>
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <20180523150642.p7ibahlgsl3jkfdo@hjp.at>
 <CADrxXXkj1_r=iOsgHVL5TjFNGhWk4XLELNRxvbZ=yo2AuFtSMg@mail.gmail.com>
 <201805231203.46607.gheskett@shentel.net>
 <2f227ad4-e7be-7f70-4ab4-307e45166187@nedbatchelder.com>
 <mailman.72.1527098338.18022.python-list@python.org>
Message-ID: <fmn7n0Fk9klU1@mid.individual.net>

Ned Batchelder wrote:
> On 5/23/18 12:03 PM, Gene Heskett wrote:
> 
>> Brain damaged by facebook, AOL, M$, Google, yahoo yadda yadda into
>> thinking that webmail and forums are the only game in town?
>>
> Please avoid accusing others of being brain damaged, even if it was 
> meant in a humorous context. :(

I think he meant "brainwashed".

-- 
Greg


From bc at freeuk.com  Thu May 24 04:29:54 2018
From: bc at freeuk.com (bartc)
Date: Thu, 24 May 2018 09:29:54 +0100
Subject: how to get INDEX count, or last number of Index
In-Reply-To: <mailman.95.1527129455.18022.python-list@python.org>
References: <62f2efcf-e1ed-4fda-bff0-c2500324da3f@googlegroups.com>
 <pe4o1v$rj6$1@dont-email.me> <pe4u9g$74c$1@blaine.gmane.org>
 <mailman.89.1527119101.18022.python-list@python.org>
 <KXnNC.206222$ta2.11122@fx03.am4> <pe58d3$ohn$1@blaine.gmane.org>
 <mailman.95.1527129455.18022.python-list@python.org>
Message-ID: <_JuNC.217786$Vs7.190213@fx41.am4>

On 24/05/2018 03:37, Terry Reedy wrote:
> On 5/23/2018 8:46 PM, bartc wrote:
>> On 24/05/2018 00:44, Terry Reedy wrote:
>>> On 5/23/2018 5:56 PM, Rob Gaddi wrote:
>>>> On 05/23/2018 02:51 PM, asa32sd23 at gmail.com wrote:
>>>>> s = "kitti"
>>>>>
>>>>> 0,1,2,3,4
>>>>> k,i,t,t,i
>>>>>
>>>>> how do i retrieve '4'. i know i can do a len(s)-1,
>>>
>>> Use -1, which is the same as len(s)-1 but faster.
>>
>> This illustrates one problem with having a example sequence of values 
>> being identical to the indices of those values.
>>
>> I would have used 10,20,30,40,50 so there could be no such mix-up.
>>
>> Because I assumed here that the OP wanted the index of the last value, 
>> the '4' they said they wanted, not the last value itself which would 
>> be 'i'.
>>
>> And actually, the subject line seems to confirm that.
>>
>> In that case, using a '-1' index won't work.
> 
> You snipped the code that shows that -1 does work to fetch the last 
> character.

<snip again>

I'm sure it does.

But it's not clear whether the OP wants the last character, or the index 
of the last character. The subject line suggests the latter.

-- 
bart


From subhabangalore at gmail.com  Thu May 24 06:13:32 2018
From: subhabangalore at gmail.com (subhabangalore at gmail.com)
Date: Thu, 24 May 2018 03:13:32 -0700 (PDT)
Subject: Some Issues on Tagging Text
Message-ID: <b8a8b685-d3b5-4f4a-93f0-3e5af5720fb2@googlegroups.com>

I have a text as, 

"Hawaii volcano generates toxic gas plume called laze PAHOA: The eruption of Kilauea volcano in Hawaii sparked new safety warnings about toxic gas on the Big Island's southern coastline after lava began flowing into the ocean and setting off a chemical reaction. Lava haze is made of dense white clouds of steam, toxic gas and tiny shards of volcanic glass. Janet Babb, a geologist with the Hawaiian Volcano Observatory, says the plume "looks innocuous, but it's not." "Just like if you drop a glass on your kitchen floor, there's some large pieces and there are some very, very tiny pieces," Babb said. "These little tiny pieces are the ones that can get wafted up in that steam plume." Scientists call the glass Limu O Pele, or Pele's seaweed, named after the Hawaiian goddess of volcano and fire"

and I want to see its tagged output as,

"Hawaii/TAG volcano generates toxic gas plume called laze PAHOA/TAG: The eruption of Kilauea/TAG volcano/TAG in Hawaii/TAG sparked new safety warnings about toxic gas on the Big Island's southern coastline after lava began flowing into the ocean and setting off a chemical reaction. Lava haze is made of dense white clouds of steam, toxic gas and tiny shards of volcanic glass. Janet/TAG Babb/TAG, a geologist with the Hawaiian/TAG Volcano/TAG Observatory/TAG, says the plume "looks innocuous, but it's not." "Just like if you drop a glass on your kitchen floor, there's some large pieces and there are some very, very tiny pieces," Babb/TAG said. "These little tiny pieces are the ones that can get wafted up in that steam plume." Scientists call the glass Limu/TAG O/TAG Pele/TAG, or Pele's seaweed, named after the Hawaiian goddess of volcano and fire"

To do this I generally try to take a list at the back end as, 

Hawaii
PAHOA
Kilauea 
volcano 
Janet 
Babb
Hawaiian 
Volcano 
Observatory
Babb 
Limu 
O 
Pele

and do a simple code as follows, 

def tag_text():
    corpus=open("/python27/volcanotxt.txt","r").read().split()
    wordlist=open("/python27/taglist.txt","r").read().split()
    list1=[]
    for word in corpus:
        if word in wordlist:
            word_new=word+"/TAG"
            list1.append(word_new)
        else:
            list1.append(word)
    lst1=list1
    tagged_text=" ".join(lst1)
    print tagged_text

get the results and hand repair unwanted tags Hawaiian/TAG goddess of volcano/TAG.

I am looking for a better approach of coding so that I need not spend time on hand repairing.

Here, corpus i.e., the volcanoxt is the untagged text given in the first and the wordlist, i.e., taglist
is list of words given just above the code. 

I am using Python2.7.15 on MS-Windows 7.

If any one may kindly suggest a solution.

Thanks in advance. 







From torriem at gmail.com  Thu May 24 07:44:26 2018
From: torriem at gmail.com (Michael Torrie)
Date: Thu, 24 May 2018 05:44:26 -0600
Subject: Usenet Gateway
In-Reply-To: <pe4adt$uvf$2@blaine.gmane.org>
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <5b027ca9$0$619$65785112@news.neostrada.pl> <20180521144801.GB7508@equipaje>
 <pdupd4$6ra$1@blaine.gmane.org> <20180522195947.hrntcm47wjzvdbcr@hjp.at>
 <pe1vc3$sd$2@blaine.gmane.org> <20180522220101.lvp6lsd7x77ndz2g@hjp.at>
 <87sh6i3o74.fsf@handshake.de> <ulsagd1kamtcqn20ogpa87k1k5r02oafn2@4ax.com>
 <20180523150642.p7ibahlgsl3jkfdo@hjp.at>
 <CADrxXXkj1_r=iOsgHVL5TjFNGhWk4XLELNRxvbZ=yo2AuFtSMg@mail.gmail.com>
 <mailman.62.1527088849.18022.python-list@python.org>
 <5figte-83e.ln1@esprimo.zbmc.eu> <pe4adt$uvf$2@blaine.gmane.org>
Message-ID: <ce5b7301-8554-e9eb-b0d9-853384fdd877@gmail.com>

On 05/23/2018 12:03 PM, Grant Edwards wrote:
> Yes.  NNTP and NNTP clients were designed from the ground up to deal
> with ongoing discussions shared by large groups of people posting lots
> of messages, and they're _very_ good at.
> 
> Email was designed for one person sending one message to another.
> 
> Over the years, people have cobbled together bits and pieces and
> features to try to make it work for shared discussions. As a result,
> mailing lists mostly work (especially for low-volume "groups") and are
> pretty decent compared to "web forums" and other such wastes of
> electrons.

I agree web forums really suck for any kind of multi-user conversation.

But mailing lists only working for low-volume groups?  That's news to
me.  But maybe I'm not a typical email user.
> But IMO email pales in comparison to NNTP when there are more than a
> few messages per day per group.

This is not my experience at all.  I used to use Usenet back in the day,
but for nearly the last two decades I've just used mailing lists,
procmail or other kinds of server-side filtering (including GMail's
filters) and a good IMAP email client like Thunderbird.  I read several
high-volume mailing lists this way and it works great. Each mailing list
goes into its own IMAP folder. The result is identical to Usenet in
functionality for me.  In fact, Thunderbird can work with Usenet and
IMAP all at the same time and you'd be hard pressed to see any difference.

GMail's web interface and mailing lists... ugh.  "Conversations" is not
threading no matter what Google calls it!

TL;DR version: with IMAP and server-side filtering of messages into
folders, the experience with email and mailing lists is very good
indeed.  Mailing lists every bit as well as Usenet given a good e-mail
client.


From torriem at gmail.com  Thu May 24 07:47:37 2018
From: torriem at gmail.com (Michael Torrie)
Date: Thu, 24 May 2018 05:47:37 -0600
Subject: Usenet Gateway
In-Reply-To: <s57hte-0l7.ln1@esprimo.zbmc.eu>
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <mailman.62.1527088849.18022.python-list@python.org>
 <5figte-83e.ln1@esprimo.zbmc.eu> <201805231832.05483.gheskett@shentel.net>
 <mailman.87.1527114732.18022.python-list@python.org>
 <s57hte-0l7.ln1@esprimo.zbmc.eu>
Message-ID: <d1b7d7a6-75b5-c8a1-b4e4-0da740c6e511@gmail.com>

Comparing to IMAP and Thunderbird:

On 05/23/2018 04:39 PM, Chris Green wrote:
> Well from other comments here it seems I'm not alone but anyway:-
> 
>     Proper threading etc. is built in

check.

> 
>     It's automatically archived and one can search back through
>     threads for old postings, this is by design not an add on.

point conceded, although I've never used this feature when I was on Usenet.

>     Kill files and other similar filtering abilities are part of the
>     user interface

true, but I can get the same job done with thunderbird and my normal
email filtering that I do.

>     Automatic handling of new messages and a means to say "I've read
>     everything here".

Yes I can mark an entire thread as "read" in IMAP.

> 
>     I'm sure there's more....




From steve+comp.lang.python at pearwood.info  Thu May 24 09:01:08 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Thu, 24 May 2018 13:01:08 +0000 (UTC)
Subject: Usenet Gateway
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <5b027ca9$0$619$65785112@news.neostrada.pl>
 <20180521144801.GB7508@equipaje> <pdupd4$6ra$1@blaine.gmane.org>
 <20180522195947.hrntcm47wjzvdbcr@hjp.at> <pe1vc3$sd$2@blaine.gmane.org>
 <20180522220101.lvp6lsd7x77ndz2g@hjp.at> <87sh6i3o74.fsf@handshake.de>
 <ulsagd1kamtcqn20ogpa87k1k5r02oafn2@4ax.com>
 <20180523150642.p7ibahlgsl3jkfdo@hjp.at>
 <CADrxXXkj1_r=iOsgHVL5TjFNGhWk4XLELNRxvbZ=yo2AuFtSMg@mail.gmail.com>
 <mailman.62.1527088849.18022.python-list@python.org>
 <5figte-83e.ln1@esprimo.zbmc.eu> <pe4adt$uvf$2@blaine.gmane.org>
 <ce5b7301-8554-e9eb-b0d9-853384fdd877@gmail.com>
Message-ID: <pe6d2k$mvr$1@blaine.gmane.org>

On Thu, 24 May 2018 05:44:26 -0600, Michael Torrie wrote:

> I agree web forums really suck for any kind of multi-user conversation.

Oh good. Because the Python core-devs are talking about moving to 
Github's web interface instead of email. Because Github is the future :-)

https://circleci.com/blog/its-the-future/

https://hackernoon.com/its-the-future-again-cd038b72dd0b


[...]
> GMail's web interface and mailing lists... ugh.  "Conversations" is not
> threading no matter what Google calls it!


Indeed. Gmail conversations are really good, right up to the moment when 
they're not and you want real threading, and then you're screwed 
seventeen ways to Sunday.

I especially love the way occasionally Gmail will decide that an email 
you sent to Joe Blogs with subject line "Let's go fishing!" and an email 
you sent to Peter Parker with subject line "Where's the beef?" belong to 
the same conversation, and as far as I can tell there's no way to 
convince it otherwise.



-- 
Steve



From cl at isbd.net  Thu May 24 09:10:56 2018
From: cl at isbd.net (Chris Green)
Date: Thu, 24 May 2018 14:10:56 +0100
Subject: Usenet Gateway
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <mailman.62.1527088849.18022.python-list@python.org>
 <5figte-83e.ln1@esprimo.zbmc.eu> <201805231832.05483.gheskett@shentel.net>
 <mailman.87.1527114732.18022.python-list@python.org>
 <s57hte-0l7.ln1@esprimo.zbmc.eu>
 <d1b7d7a6-75b5-c8a1-b4e4-0da740c6e511@gmail.com>
 <mailman.98.1527162462.18022.python-list@python.org>
Message-ID: <08qite-2lj.ln1@esprimo.zbmc.eu>

Michael Torrie <torriem at gmail.com> wrote:
> Comparing to IMAP and Thunderbird:
> 
> On 05/23/2018 04:39 PM, Chris Green wrote:
> > Well from other comments here it seems I'm not alone but anyway:-
> > 
> >     Proper threading etc. is built in
> 
> check.
> 
> > 
> >     It's automatically archived and one can search back through
> >     threads for old postings, this is by design not an add on.
> 
> point conceded, although I've never used this feature when I was on Usenet.
> 
> >     Kill files and other similar filtering abilities are part of the
> >     user interface
> 
> true, but I can get the same job done with thunderbird and my normal
> email filtering that I do.  

Possibly, but it's easier with most NNTP clients.  I use both mailing
lists (mutt) and Usenet (tin) and if I have the choice (as with
Python) then I always go for Usenet/tin.

> 
> >     Automatic handling of new messages and a means to say "I've read
> >     everything here".
> 
> Yes I can mark an entire thread as "read" in IMAP.
> 
A *thread* yes, but not a whole list.  I.e. if you read this using
mail/IMAP you can mark a thread read but you can't mark *all* Python
list messages read in one go can you?   With tin/Usenet I look at the
list of new subjects in the Python group, I may investigate a couple
of threads, then I just hit 'C' and all of the Python group is marked
as read.


-- 
Chris Green
?


From grant.b.edwards at gmail.com  Thu May 24 10:20:22 2018
From: grant.b.edwards at gmail.com (Grant Edwards)
Date: Thu, 24 May 2018 14:20:22 +0000 (UTC)
Subject: Usenet Gateway
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <5b027ca9$0$619$65785112@news.neostrada.pl>
 <20180521144801.GB7508@equipaje> <pdupd4$6ra$1@blaine.gmane.org>
 <20180522195947.hrntcm47wjzvdbcr@hjp.at> <pe1vc3$sd$2@blaine.gmane.org>
 <20180522220101.lvp6lsd7x77ndz2g@hjp.at> <87sh6i3o74.fsf@handshake.de>
 <ulsagd1kamtcqn20ogpa87k1k5r02oafn2@4ax.com>
 <20180523150642.p7ibahlgsl3jkfdo@hjp.at>
 <CADrxXXkj1_r=iOsgHVL5TjFNGhWk4XLELNRxvbZ=yo2AuFtSMg@mail.gmail.com>
 <mailman.62.1527088849.18022.python-list@python.org>
 <5figte-83e.ln1@esprimo.zbmc.eu> <pe4adt$uvf$2@blaine.gmane.org>
 <ce5b7301-8554-e9eb-b0d9-853384fdd877@gmail.com>
Message-ID: <pe6hn6$uvk$1@blaine.gmane.org>

On 2018-05-24, Michael Torrie <torriem at gmail.com> wrote:
> On 05/23/2018 12:03 PM, Grant Edwards wrote:

>> But IMO email pales in comparison to NNTP when there are more than a
>> few messages per day per group.
>
> This is not my experience at all.  I used to use Usenet back in the day,
> but for nearly the last two decades I've just used mailing lists,
> procmail or other kinds of server-side filtering (including GMail's
> filters)

That's sort of my point: with NNTP, you don't _need_ procmail and
three kinds of filtering in addition to your IMAP client.

> and a good IMAP email client like Thunderbird.  I read several
> high-volume mailing lists this way and it works great. Each mailing
> list goes into its own IMAP folder. The result is identical to
> Usenet in functionality for me.  In fact, Thunderbird can work with
> Usenet and IMAP all at the same time and you'd be hard pressed to
> see any difference.

But you had to jump through hoops with procmail and server/client side
filtering to get there.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm not available
                                  at               for comment..
                              gmail.com            



From chema at rinzewind.org  Thu May 24 10:23:14 2018
From: chema at rinzewind.org (=?utf-8?Q?Jos=C3=A9=20Mar=C3=ADa=20Mateos?=)
Date: Thu, 24 May 2018 10:23:14 -0400
Subject: Usenet Gateway
In-Reply-To: <08qite-2lj.ln1@esprimo.zbmc.eu>
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <mailman.62.1527088849.18022.python-list@python.org>
 <5figte-83e.ln1@esprimo.zbmc.eu>
 <201805231832.05483.gheskett@shentel.net>
 <mailman.87.1527114732.18022.python-list@python.org>
 <s57hte-0l7.ln1@esprimo.zbmc.eu>
 <d1b7d7a6-75b5-c8a1-b4e4-0da740c6e511@gmail.com>
 <mailman.98.1527162462.18022.python-list@python.org>
 <08qite-2lj.ln1@esprimo.zbmc.eu>
Message-ID: <1527171794.281788.1383476464.3B124B01@webmail.messagingengine.com>

On Thu, May 24, 2018, at 09:10, Chris Green wrote:
> > Yes I can mark an entire thread as "read" in IMAP.
> > 
> A *thread* yes, but not a whole list.  I.e. if you read this using
> mail/IMAP you can mark a thread read but you can't mark *all* Python
> list messages read in one go can you?   With tin/Usenet I look at the
> list of new subjects in the Python group, I may investigate a couple
> of threads, then I just hit 'C' and all of the Python group is marked
> as read.

Yes, you can, at least with mutt. I have a handy alias (ESC + m) that accomplish precisely that.

Cheers,

-- 
Jos? Mar?a (Chema) Mateos
https://rinzewind.org/blog-es || https://rinzewind.org/blog-en


From cl at isbd.net  Thu May 24 10:49:49 2018
From: cl at isbd.net (Chris Green)
Date: Thu, 24 May 2018 15:49:49 +0100
Subject: Usenet Gateway
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <5figte-83e.ln1@esprimo.zbmc.eu> <201805231832.05483.gheskett@shentel.net>
 <mailman.87.1527114732.18022.python-list@python.org>
 <s57hte-0l7.ln1@esprimo.zbmc.eu>
 <d1b7d7a6-75b5-c8a1-b4e4-0da740c6e511@gmail.com>
 <mailman.98.1527162462.18022.python-list@python.org>
 <08qite-2lj.ln1@esprimo.zbmc.eu>
 <1527171794.281788.1383476464.3B124B01@webmail.messagingengine.com>
 <mailman.102.1527172285.18022.python-list@python.org>
Message-ID: <d10jte-c6l.ln1@esprimo.zbmc.eu>

Jos? Mar?a Mateos <chema at rinzewind.org> wrote:
> On Thu, May 24, 2018, at 09:10, Chris Green wrote:
> > > Yes I can mark an entire thread as "read" in IMAP.
> > > 
> > A *thread* yes, but not a whole list.  I.e. if you read this using
> > mail/IMAP you can mark a thread read but you can't mark *all* Python
> > list messages read in one go can you?   With tin/Usenet I look at the
> > list of new subjects in the Python group, I may investigate a couple
> > of threads, then I just hit 'C' and all of the Python group is marked
> > as read.
> 
> Yes, you can, at least with mutt. I have a handy alias (ESC + m) that accomplish precisely that.
> 
OK, but you had to add that, it's built in with every NNTP client I've
ever come across.

-- 
Chris Green
?


From chester.davies at googlemail.com  Thu May 24 11:31:15 2018
From: chester.davies at googlemail.com (Chester Davies)
Date: Thu, 24 May 2018 16:31:15 +0100
Subject: Scripts not downloading Version 3.6.5
Message-ID: <1DAB52FC-75EC-47C1-A879-06EEAF7F251A@googlemail.com>

Hi! 

Yesterday I downloaded the latest version of Python, after some fiddling around with some command line, getting Python to open files etc, it wasn't able to find various pillows, so after a while, I decided to call it a night. I went to finish it off today, and discovered my computer had updated Windows, and so decided to uninstall everything and start from scratch. Upon redownloading Python 3.6.5, and moving to where I want it, I cannot use any of the functions required, mainly pip.exe. Upon looking in the scripts folder, it is completely empty. I have since tried to reinstall to no avail, and also attempted to do various repairs from the installer. How can I rectify this please?

Kind regards,

Chester

From chester.davies at googlemail.com  Thu May 24 11:31:42 2018
From: chester.davies at googlemail.com (Chester Davies)
Date: Thu, 24 May 2018 16:31:42 +0100
Subject: Scripts not downloading Version 3.6.5
Message-ID: <19CBEEC0-6666-4DE0-833F-DAFC2484691E@googlemail.com>

Hi! 

Yesterday I downloaded the latest version of Python, after some fiddling around with some command line, getting Python to open files etc, it wasn't able to find various pillows, so after a while, I decided to call it a night. I went to finish it off today, and discovered my computer had updated Windows, and so decided to uninstall everything and start from scratch. Upon redownloading Python 3.6.5, and moving to where I want it, I cannot use any of the functions required, mainly pip.exe. Upon looking in the scripts folder, it is completely empty. I have since tried to reinstall to no avail, and also attempted to do various repairs from the installer. How can I rectify this please?

Kind regards,

Chester

From steve+comp.lang.python at pearwood.info  Thu May 24 14:17:20 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Thu, 24 May 2018 18:17:20 +0000 (UTC)
Subject: List replication operator
Message-ID: <pe6vjf$g1l$1@blaine.gmane.org>

Python has a sequence replication operator:

py> [1, 2]*3
[1, 2, 1, 2, 1, 2]


Unfortunately, it is prone to a common "gotcha":

py> x = [[]]*5  # make a multi-dimensional list
py> x
[[], [], [], [], []]
py> x[0].append(1)
py> x
[[1], [1], [1], [1], [1]]


The reason for this behaviour is that * does not copy the original list's 
items, it simply replicates the references to the items. So we end up 
with a new list containing five references to the same inner list.


This is not a bug and changing the behaviour is not an option.

But what do people think about proposing a new list replication with copy 
operator?

    [[]]**5

would return a new list consisting of five shallow copies of the inner 
list.


Thoughts?



-- 
Steve



From rgaddi at highlandtechnology.invalid  Thu May 24 14:24:41 2018
From: rgaddi at highlandtechnology.invalid (Rob Gaddi)
Date: Thu, 24 May 2018 11:24:41 -0700
Subject: List replication operator
In-Reply-To: <mailman.105.1527185982.18022.python-list@python.org>
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <mailman.105.1527185982.18022.python-list@python.org>
Message-ID: <pe7019$957$1@dont-email.me>

On 05/24/2018 11:17 AM, Steven D'Aprano wrote:
> Python has a sequence replication operator:
> 
> py> [1, 2]*3
> [1, 2, 1, 2, 1, 2]
> 
> 
> Unfortunately, it is prone to a common "gotcha":
> 
> py> x = [[]]*5  # make a multi-dimensional list
> py> x
> [[], [], [], [], []]
> py> x[0].append(1)
> py> x
> [[1], [1], [1], [1], [1]]
> 
> 
> The reason for this behaviour is that * does not copy the original list's
> items, it simply replicates the references to the items. So we end up
> with a new list containing five references to the same inner list.
> 
> 
> This is not a bug and changing the behaviour is not an option.
> 
> But what do people think about proposing a new list replication with copy
> operator?
> 
>      [[]]**5
> 
> would return a new list consisting of five shallow copies of the inner
> list.
> 
> 
> Thoughts?
> 
> 
> 

I think the same people making that mistake now would still do so 
because they didn't know they needed the special operator.

[[] for _ in range(5)] works just as well without adding more syntax.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.


From ned at nedbatchelder.com  Thu May 24 15:12:09 2018
From: ned at nedbatchelder.com (Ned Batchelder)
Date: Thu, 24 May 2018 15:12:09 -0400
Subject: List replication operator
In-Reply-To: <pe6vjf$g1l$1@blaine.gmane.org>
References: <pe6vjf$g1l$1@blaine.gmane.org>
Message-ID: <5c29383b-d356-26e2-a8bf-92daa4361889@nedbatchelder.com>

On 5/24/18 2:17 PM, Steven D'Aprano wrote:
> Python has a sequence replication operator:
>
> py> [1, 2]*3
> [1, 2, 1, 2, 1, 2]
>
>
> Unfortunately, it is prone to a common "gotcha":
>
> py> x = [[]]*5  # make a multi-dimensional list
> py> x
> [[], [], [], [], []]
> py> x[0].append(1)
> py> x
> [[1], [1], [1], [1], [1]]
>
>
> The reason for this behaviour is that * does not copy the original list's
> items, it simply replicates the references to the items. So we end up
> with a new list containing five references to the same inner list.
>
>
> This is not a bug and changing the behaviour is not an option.
>
> But what do people think about proposing a new list replication with copy
> operator?
>
>      [[]]**5
>
> would return a new list consisting of five shallow copies of the inner
> list.
>
"shallow" will be the next problem.? Do we also need this?:

 ??? [[[]]]***5???????????? # j/k

--Ned.


From python at mrabarnett.plus.com  Thu May 24 16:02:23 2018
From: python at mrabarnett.plus.com (MRAB)
Date: Thu, 24 May 2018 21:02:23 +0100
Subject: List replication operator
In-Reply-To: <5c29383b-d356-26e2-a8bf-92daa4361889@nedbatchelder.com>
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <5c29383b-d356-26e2-a8bf-92daa4361889@nedbatchelder.com>
Message-ID: <1e298839-81b9-9bb2-aad7-4e0674023858@mrabarnett.plus.com>

On 2018-05-24 20:12, Ned Batchelder wrote:
> On 5/24/18 2:17 PM, Steven D'Aprano wrote:
>> Python has a sequence replication operator:
>>
>> py> [1, 2]*3
>> [1, 2, 1, 2, 1, 2]
>>
>>
>> Unfortunately, it is prone to a common "gotcha":
>>
>> py> x = [[]]*5  # make a multi-dimensional list
>> py> x
>> [[], [], [], [], []]
>> py> x[0].append(1)
>> py> x
>> [[1], [1], [1], [1], [1]]
>>
>>
>> The reason for this behaviour is that * does not copy the original list's
>> items, it simply replicates the references to the items. So we end up
>> with a new list containing five references to the same inner list.
>>
>>
>> This is not a bug and changing the behaviour is not an option.
>>
>> But what do people think about proposing a new list replication with copy
>> operator?
>>
>>      [[]]**5
>>
>> would return a new list consisting of five shallow copies of the inner
>> list.
>>
Why "**"? Why not "@"?

[[]] @ 5

> "shallow" will be the next problem.? Do we also need this?:
> 
>   ??? [[[]]]***5???????????? # j/k
> 
I suppose the choice should be limited to 2 options: shallow copy and 
deep copy.


From cs at cskk.id.au  Thu May 24 18:02:38 2018
From: cs at cskk.id.au (Cameron Simpson)
Date: Fri, 25 May 2018 08:02:38 +1000
Subject: List replication operator
In-Reply-To: <pe6vjf$g1l$1@blaine.gmane.org>
References: <pe6vjf$g1l$1@blaine.gmane.org>
Message-ID: <20180524220238.GA24039@cskk.homeip.net>

On 24May2018 18:17, Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
>Python has a sequence replication operator:
>
>py> [1, 2]*3
>[1, 2, 1, 2, 1, 2]
>
>Unfortunately, it is prone to a common "gotcha":
>
>py> x = [[]]*5  # make a multi-dimensional list
>py> x
>[[], [], [], [], []]
>py> x[0].append(1)
>py> x
>[[1], [1], [1], [1], [1]]
>
>The reason for this behaviour is that * does not copy the original list's
>items, it simply replicates the references to the items. So we end up
>with a new list containing five references to the same inner list.
>
>This is not a bug and changing the behaviour is not an option.
>
>But what do people think about proposing a new list replication with copy
>operator?
>
>    [[]]**5
>
>would return a new list consisting of five shallow copies of the inner
>list.

I think I'm against it.

Shallow copies are just as easy to get wrong, for much the same reason that * 
can produce a surprise.

So to me this introduces a new operator without much benefit, and possibly 
negative side effects (bcause it makes makes choosing an approach to sequence 
replication harder: which form should I use, per case)? The * is faster while 
the ** is safer... in very limited contexts.

I would rather there were just one model of this replication, and the model we 
have is simple and direct, with exactly the same pitfalls and benefits as 
Python's function parameter default values. So people already need this issue 
in mind to work in the language.

I'm also against the "**" spelling I find, for much the same reasons that 
people oppose allowing "=" and "==" in the same syntactic location: they're 
easy to get wrong through typing inaccuracy.

Cheers,
Cameron Simpson <cs at cskk.id.au>


From cs at cskk.id.au  Thu May 24 18:14:59 2018
From: cs at cskk.id.au (Cameron Simpson)
Date: Fri, 25 May 2018 08:14:59 +1000
Subject: Some Issues on Tagging Text
In-Reply-To: <b8a8b685-d3b5-4f4a-93f0-3e5af5720fb2@googlegroups.com>
References: <b8a8b685-d3b5-4f4a-93f0-3e5af5720fb2@googlegroups.com>
Message-ID: <20180524221459.GA59653@cskk.homeip.net>

First up, thank you for a well described problem! Remarks inline below.

On 24May2018 03:13, Subhabrata Banerjee <subhabangalore at gmail.com> wrote:
>I have a text as,
>
>"Hawaii volcano generates toxic gas plume called laze PAHOA: The eruption of Kilauea volcano in Hawaii sparked new safety warnings about toxic gas on the Big Island's southern coastline after lava began flowing into the ocean and setting off a chemical reaction. Lava haze is made of dense white clouds of steam, toxic gas and tiny shards of volcanic glass. Janet Babb, a geologist with the Hawaiian Volcano Observatory, says the plume "looks innocuous, but it's not." "Just like if you drop a glass on your kitchen floor, there's some large pieces and there are some very, very tiny pieces," Babb said. "These little tiny pieces are the ones that can get wafted up in that steam plume." Scientists call the glass Limu O Pele, or Pele's seaweed, named after the Hawaiian goddess of volcano and fire"
>
>and I want to see its tagged output as,
>
>"Hawaii/TAG volcano generates toxic gas plume called laze PAHOA/TAG: The eruption of Kilauea/TAG volcano/TAG in Hawaii/TAG sparked new safety warnings about toxic gas on the Big Island's southern coastline after lava began flowing into the ocean and setting off a chemical reaction. Lava haze is made of dense white clouds of steam, toxic gas and tiny shards of volcanic glass. Janet/TAG Babb/TAG, a geologist with the Hawaiian/TAG Volcano/TAG Observatory/TAG, says the plume "looks innocuous, but it's not." "Just like if you drop a glass on your kitchen floor, there's some large pieces and there are some very, very tiny pieces," Babb/TAG said. "These little tiny pieces are the ones that can get wafted up in that steam plume." Scientists call the glass Limu/TAG O/TAG Pele/TAG, or Pele's seaweed, named after the Hawaiian goddess of volcano and fire"
>
>To do this I generally try to take a list at the back end as,
>
>Hawaii
>PAHOA
>Kilauea
>volcano
>Janet
>Babb
>Hawaiian
>Volcano
>Observatory
>Babb
>Limu
>O
>Pele
>
>and do a simple code as follows,
>
>def tag_text():
>    corpus=open("/python27/volcanotxt.txt","r").read().split()
>    wordlist=open("/python27/taglist.txt","r").read().split()

You might want use this to compose "wordlist":

     wordlist=set(open("/python27/taglist.txt","r").read().split())

because it will make your "if word in wordlist" test O(1) instead of O(n), 
which will matter later if your wordlist grows.

>    list1=[]
>    for word in corpus:
>        if word in wordlist:
>            word_new=word+"/TAG"
>            list1.append(word_new)
>        else:
>            list1.append(word)
>    lst1=list1
>    tagged_text=" ".join(lst1)
>    print tagged_text
>
>get the results and hand repair unwanted tags Hawaiian/TAG goddess of volcano/TAG.
>I am looking for a better approach of coding so that I need not spend time on 
>hand repairing.

It isn't entirely clear to me why these two taggings are unwanted. Intuitively, 
they seem to be either because "Hawaiian goddess" is a compound term where you 
don't want "Hawaiian" to get a tag, or because "Hawaiian" has already received 
a tag earlier in the list. Or are there other criteria.

If you want to solve this problem with a programme you must first clearly 
define what makes an unwanted tag "unwanted".

For example, "Hawaiian" is an adjective, and therefore will always be part of a 
compound term.

Can you clarify what makes these taggings you mention "unwanted"?

Cheers,
Cameron Simpson <cs at cskk.id.au>


From bruceg113355 at gmail.com  Thu May 24 18:54:11 2018
From: bruceg113355 at gmail.com (bruceg113355 at gmail.com)
Date: Thu, 24 May 2018 15:54:11 -0700 (PDT)
Subject: convert a string to a variable
Message-ID: <21d54ddd-4797-44ad-ad76-931dbd9235ff@googlegroups.com>

I am trying to convert a string to a variable.

I got cases 1 & 2 to work, but not cases 3 & 4.

The print statement in cases 3 & 4 reports the following:
    builtins.AttributeError: type object 'animal' has no attribute 'tiger'
    
I am stuck on creating variables that can be accessed as follows.
          animal.tiger
          self.animal.tiger

Any suggestions?

Thanks,
Bruce


# Tested on Python 3.6.5

# Case 1: This works
indata = 'animal_tiger'
vars()[indata] = "Tigers, big and strong!"
print (animal_tiger)


# Case 2: This works
class animal():
    def create (self, indata):
        vars(self)[indata] = "Tigers, big and strong!"
        print (self.animal_tiger)

tmp = animal()
tmp.create('animal_tiger')


#############################################################

# Case 3: This does not work
indata = 'animal.tiger'
vars()[indata] = "Tigers, big and strong!"
print (animal.tiger)


#Case 4: This does not work
class animal():
    def create (self, indata):
        vars(self)[indata] = "Tigers, big and strong!"
        print (self.animal.tiger)

tmp = animal()
tmp.create('animal.tiger')













From tallpaul at gmail.com  Thu May 24 19:05:32 2018
From: tallpaul at gmail.com (Paul)
Date: Thu, 24 May 2018 16:05:32 -0700
Subject: List replication operator
In-Reply-To: <20180524220238.GA24039@cskk.homeip.net>
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <20180524220238.GA24039@cskk.homeip.net>
Message-ID: <CA+og5upwxdyW1X1cCxVR1VuUuSiHBBW0nMjNZTrCFRU0UbWMxA@mail.gmail.com>

How would one make a multi-dimensional list now, with truly-separate sub
lists?  Is there just no way to do it with the replication operator? IE,
would I just have to do
  X = [[], [], [], [], []]

or perhaps write a function to insert new sub lists into a list, or...?

 Thanks

> Paul C.
>
>


From ben+python at benfinney.id.au  Thu May 24 19:26:24 2018
From: ben+python at benfinney.id.au (Ben Finney)
Date: Fri, 25 May 2018 09:26:24 +1000
Subject: List replication operator
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <20180524220238.GA24039@cskk.homeip.net>
 <CA+og5upwxdyW1X1cCxVR1VuUuSiHBBW0nMjNZTrCFRU0UbWMxA@mail.gmail.com>
Message-ID: <85fu2gk53z.fsf@benfinney.id.au>

Paul <tallpaul at gmail.com> writes:

> How would one make a multi-dimensional list now, with truly-separate sub
> lists?  Is there just no way to do it with the replication operator? IE,
> would I just have to do
>   X = [[], [], [], [], []]

The expressions in a comprehension are evaluated each time through. So
this is another way to get that result:

    foo = [ [] for __ in range(5) ]

-- 
 \         ?We now have access to so much information that we can find |
  `\  support for any prejudice or opinion.? ?David Suzuki, 2008-06-27 |
_o__)                                                                  |
Ben Finney



From python at mrabarnett.plus.com  Thu May 24 19:31:18 2018
From: python at mrabarnett.plus.com (MRAB)
Date: Fri, 25 May 2018 00:31:18 +0100
Subject: List replication operator
In-Reply-To: <CA+og5upwxdyW1X1cCxVR1VuUuSiHBBW0nMjNZTrCFRU0UbWMxA@mail.gmail.com>
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <20180524220238.GA24039@cskk.homeip.net>
 <CA+og5upwxdyW1X1cCxVR1VuUuSiHBBW0nMjNZTrCFRU0UbWMxA@mail.gmail.com>
Message-ID: <f83f04db-0f7c-33b4-612f-4ce39a8bd34f@mrabarnett.plus.com>

On 2018-05-25 00:05, Paul wrote:
> How would one make a multi-dimensional list now, with truly-separate sub
> lists?  Is there just no way to do it with the replication operator? IE,
> would I just have to do
>    X = [[], [], [], [], []]
> 
> or perhaps write a function to insert new sub lists into a list, or...?
> 
For a list of 5 separate lists:

X = [[] for _ in range(5)]


From asa32sd23 at gmail.com  Thu May 24 20:50:53 2018
From: asa32sd23 at gmail.com (asa32sd23 at gmail.com)
Date: Thu, 24 May 2018 17:50:53 -0700 (PDT)
Subject: cleaner version of variable, new line
Message-ID: <6336b7ef-3163-4c25-a479-5ba7e5fb16ff@googlegroups.com>

hi just seeing if there is a cleaner way to write this. 
 
s1= "kitti"
s2= 'kitti'
i= 3
print(s1+ "\n" + "="*i + "^" + "\n" +s2)

> 
kitti
===^
kitti


From tjreedy at udel.edu  Thu May 24 21:25:50 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 24 May 2018 21:25:50 -0400
Subject: Scripts not downloading Version 3.6.5
In-Reply-To: <19CBEEC0-6666-4DE0-833F-DAFC2484691E@googlemail.com>
References: <19CBEEC0-6666-4DE0-833F-DAFC2484691E@googlemail.com>
Message-ID: <pe7oir$869$1@blaine.gmane.org>

On 5/24/2018 11:31 AM, Chester Davies via Python-list wrote:
> Hi!
> 
> Yesterday I downloaded the latest version of Python, after some fiddling around with some command line, getting Python to open files etc, it wasn't able to find various pillows, so after a while, I decided to call it a night. I went to finish it off today, and discovered my computer had updated Windows, and so decided to uninstall everything and start from scratch. Upon redownloading Python 3.6.5, and moving to where I want it, I cannot use any of the functions required, mainly pip.exe. Upon looking in the scripts folder, it is completely empty. I have since tried to reinstall to no avail, and also attempted to do various repairs from the installer. How can I rectify this please?

Run python -m ensurepip --upgrade
See https://docs.python.org/3/library/ensurepip.html#module-ensurepip
There should have been an option to do this with 'repair', but anyway...

-- 
Terry Jan Reedy



From steve+comp.lang.python at pearwood.info  Thu May 24 21:28:56 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 25 May 2018 01:28:56 +0000 (UTC)
Subject: List replication operator
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <mailman.105.1527185982.18022.python-list@python.org>
 <pe7019$957$1@dont-email.me>
Message-ID: <pe7oso$m3$1@blaine.gmane.org>

On Thu, 24 May 2018 11:24:41 -0700, Rob Gaddi wrote:

> On 05/24/2018 11:17 AM, Steven D'Aprano wrote:
[...]
>> But what do people think about proposing a new list replication with
>> copy operator?
>> 
>>      [[]]**5
>> 
>> would return a new list consisting of five shallow copies of the inner
>> list.
>> 
>> 
>> Thoughts?
>> 
>> 
>> 
>> 
> I think the same people making that mistake now would still do so
> because they didn't know they needed the special operator.

People aren't born knowing that * is usable with lists, so the fact that 
they won't be born knowing about ** either is not a point against it.

Wherever newbies are learning about * will soon teach them to use ** for 
multi-dimensional lists as well.

> [[] for _ in range(5)] works just as well without adding more syntax.

This doesn't add more syntax. ** is already valid syntax. It is just 
adding a new method to sequences.

For newbies, using a list comp is not obvious or easily discoverable.


-- 
Steve



From torriem at gmail.com  Thu May 24 21:44:39 2018
From: torriem at gmail.com (Michael Torrie)
Date: Thu, 24 May 2018 19:44:39 -0600
Subject: Usenet Gateway
In-Reply-To: <08qite-2lj.ln1@esprimo.zbmc.eu>
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <mailman.62.1527088849.18022.python-list@python.org>
 <5figte-83e.ln1@esprimo.zbmc.eu> <201805231832.05483.gheskett@shentel.net>
 <mailman.87.1527114732.18022.python-list@python.org>
 <s57hte-0l7.ln1@esprimo.zbmc.eu>
 <d1b7d7a6-75b5-c8a1-b4e4-0da740c6e511@gmail.com>
 <mailman.98.1527162462.18022.python-list@python.org>
 <08qite-2lj.ln1@esprimo.zbmc.eu>
Message-ID: <6fd9cd1b-684d-c8ea-f8ac-89232096536e@gmail.com>

On 05/24/2018 07:10 AM, Chris Green wrote:
> A *thread* yes, but not a whole list.  I.e. if you read this using 
> mail/IMAP you can mark a thread read but you can't mark *all* Python 
> list messages read in one go can you?   With tin/Usenet I look at
> the list of new subjects in the Python group, I may investigate a
> couple of threads, then I just hit 'C' and all of the Python group is
> marked as read.

Sure can.  Just right click on the folder that holds all the python
mailing list messages and click "mark folder read."



From torriem at gmail.com  Thu May 24 21:45:33 2018
From: torriem at gmail.com (Michael Torrie)
Date: Thu, 24 May 2018 19:45:33 -0600
Subject: Usenet Gateway
In-Reply-To: <pe6d2k$mvr$1@blaine.gmane.org>
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <5b027ca9$0$619$65785112@news.neostrada.pl> <20180521144801.GB7508@equipaje>
 <pdupd4$6ra$1@blaine.gmane.org> <20180522195947.hrntcm47wjzvdbcr@hjp.at>
 <pe1vc3$sd$2@blaine.gmane.org> <20180522220101.lvp6lsd7x77ndz2g@hjp.at>
 <87sh6i3o74.fsf@handshake.de> <ulsagd1kamtcqn20ogpa87k1k5r02oafn2@4ax.com>
 <20180523150642.p7ibahlgsl3jkfdo@hjp.at>
 <CADrxXXkj1_r=iOsgHVL5TjFNGhWk4XLELNRxvbZ=yo2AuFtSMg@mail.gmail.com>
 <mailman.62.1527088849.18022.python-list@python.org>
 <5figte-83e.ln1@esprimo.zbmc.eu> <pe4adt$uvf$2@blaine.gmane.org>
 <ce5b7301-8554-e9eb-b0d9-853384fdd877@gmail.com>
 <pe6d2k$mvr$1@blaine.gmane.org>
Message-ID: <dee388ad-13a7-d4b8-4b1b-04e0d2defa7b@gmail.com>

On 05/24/2018 07:01 AM, Steven D'Aprano wrote:
> On Thu, 24 May 2018 05:44:26 -0600, Michael Torrie wrote:
> 
>> I agree web forums really suck for any kind of multi-user conversation.
> 
> Oh good. Because the Python core-devs are talking about moving to 
> Github's web interface instead of email. Because Github is the future :-)
> 
> https://circleci.com/blog/its-the-future/
> 
> https://hackernoon.com/its-the-future-again-cd038b72dd0b

That's great news. Sigh.


From torriem at gmail.com  Thu May 24 21:55:43 2018
From: torriem at gmail.com (Michael Torrie)
Date: Thu, 24 May 2018 19:55:43 -0600
Subject: Usenet Gateway
In-Reply-To: <pe6hn6$uvk$1@blaine.gmane.org>
References: <4sd3le-ct4.ln1@tanner.seckford.org>
 <5b027ca9$0$619$65785112@news.neostrada.pl> <20180521144801.GB7508@equipaje>
 <pdupd4$6ra$1@blaine.gmane.org> <20180522195947.hrntcm47wjzvdbcr@hjp.at>
 <pe1vc3$sd$2@blaine.gmane.org> <20180522220101.lvp6lsd7x77ndz2g@hjp.at>
 <87sh6i3o74.fsf@handshake.de> <ulsagd1kamtcqn20ogpa87k1k5r02oafn2@4ax.com>
 <20180523150642.p7ibahlgsl3jkfdo@hjp.at>
 <CADrxXXkj1_r=iOsgHVL5TjFNGhWk4XLELNRxvbZ=yo2AuFtSMg@mail.gmail.com>
 <mailman.62.1527088849.18022.python-list@python.org>
 <5figte-83e.ln1@esprimo.zbmc.eu> <pe4adt$uvf$2@blaine.gmane.org>
 <ce5b7301-8554-e9eb-b0d9-853384fdd877@gmail.com>
 <pe6hn6$uvk$1@blaine.gmane.org>
Message-ID: <fa754449-1dda-a717-1f37-002ef9ff39c2@gmail.com>

On 05/24/2018 08:20 AM, Grant Edwards wrote:
> But you had to jump through hoops with procmail and server/client side
> filtering to get there.

True, but it takes maybe 30 seconds for each new list I sign up for, and
then it's out of sight, out of mind.  I already do a ton of filtering on
my inbox anyway to move family messages to their own folder, etc.  Hate
to say it, but GMail actually makes it pretty fast and easy to set up
the rule.  Mostly one-click automatic "filter messages like this one."

I agree NNTP is designed for all of this.  I used to spend a lot of time
on Usenet years ago when every uni had its own NNTP server.  And
thunderbird, my preferred client, can use NNTP.  But the mailing list
works and has, for me, almost no spam, so there's no real incentive for
me to change.



From python at mrabarnett.plus.com  Thu May 24 22:03:36 2018
From: python at mrabarnett.plus.com (MRAB)
Date: Fri, 25 May 2018 03:03:36 +0100
Subject: cleaner version of variable, new line
In-Reply-To: <6336b7ef-3163-4c25-a479-5ba7e5fb16ff@googlegroups.com>
References: <6336b7ef-3163-4c25-a479-5ba7e5fb16ff@googlegroups.com>
Message-ID: <68824db0-3325-62db-732a-2e120761b6cd@mrabarnett.plus.com>

On 2018-05-25 01:50, asa32sd23 at gmail.com wrote:
> hi just seeing if there is a cleaner way to write this.
>   
> s1= "kitti"
> s2= 'kitti'
> i= 3
> print(s1+ "\n" + "="*i + "^" + "\n" +s2)
> 
>> 
> kitti
> ===^
> kitti
> 
When printing, I'd probably just go for something clear and simple:

print(s1)
print("=" * i + "^")
print(s2)

There's no need to cram it all onto one line.


From asa32sd23 at gmail.com  Thu May 24 22:07:04 2018
From: asa32sd23 at gmail.com (asa32sd23 at gmail.com)
Date: Thu, 24 May 2018 19:07:04 -0700 (PDT)
Subject: cleaner version of variable, new line
In-Reply-To: <6336b7ef-3163-4c25-a479-5ba7e5fb16ff@googlegroups.com>
References: <6336b7ef-3163-4c25-a479-5ba7e5fb16ff@googlegroups.com>
Message-ID: <59784c15-3563-4c0e-9fae-195b3a663bc5@googlegroups.com>

On Thursday, May 24, 2018 at 8:51:07 PM UTC-4, asa3... at gmail.com wrote:
> hi just seeing if there is a cleaner way to write this. 
>  
> s1= "kitti"
> s2= 'kitti'
> i= 3
> print(s1+ "\n" + "="*i + "^" + "\n" +s2)
> 
> > 
> kitti
> ===^
> kitti

more legible that way... thks


From asa32sd23 at gmail.com  Thu May 24 22:12:33 2018
From: asa32sd23 at gmail.com (asa32sd23 at gmail.com)
Date: Thu, 24 May 2018 19:12:33 -0700 (PDT)
Subject: why do I get syntax error on if <code>: break
Message-ID: <eed6cc31-1f63-4cb3-8623-b2963abadad7@googlegroups.com>

here is the code, i keep getting an error, "break outside loop". if it is false just exit function


def d(idx):
    if type(idx) != int:
        break

d('k')


From steve+comp.lang.python at pearwood.info  Thu May 24 22:19:21 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 25 May 2018 02:19:21 +0000 (UTC)
Subject: cleaner version of variable, new line
References: <6336b7ef-3163-4c25-a479-5ba7e5fb16ff@googlegroups.com>
Message-ID: <pe7rr8$klt$1@blaine.gmane.org>

On Thu, 24 May 2018 17:50:53 -0700, asa32sd23 wrote:

> hi just seeing if there is a cleaner way to write this.
>  
> s1= "kitti"
> s2= 'kitti'
> i= 3
> print(s1+ "\n" + "="*i + "^" + "\n" +s2)


s = "kitti"
i = 3
print(s, "="*i + "^", s, sep='\n')





-- 
Steve



From robertvstepp at gmail.com  Thu May 24 22:21:47 2018
From: robertvstepp at gmail.com (boB Stepp)
Date: Thu, 24 May 2018 21:21:47 -0500
Subject: why do I get syntax error on if <code>: break
In-Reply-To: <eed6cc31-1f63-4cb3-8623-b2963abadad7@googlegroups.com>
References: <eed6cc31-1f63-4cb3-8623-b2963abadad7@googlegroups.com>
Message-ID: <CANDiX9LAarTwK3NVxUkvqUBb+NSqsLR_gz4ieAKPEnH7iBJTtA@mail.gmail.com>

On Thu, May 24, 2018 at 9:12 PM,  <asa32sd23 at gmail.com> wrote:
> here is the code, i keep getting an error, "break outside loop". if it is false just exit function
>
>
> def d(idx):
>     if type(idx) != int:
>         break
>
> d('k')

"break" (and "continue") are only meaningful inside for or while
loops.  You do not have one of these inside your function.  See
https://docs.python.org/3/reference/simple_stmts.html#break

-- 
boB


From steve+comp.lang.python at pearwood.info  Thu May 24 22:25:08 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 25 May 2018 02:25:08 +0000 (UTC)
Subject: List replication operator
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <5c29383b-d356-26e2-a8bf-92daa4361889@nedbatchelder.com>
Message-ID: <pe7s63$klt$2@blaine.gmane.org>

On Thu, 24 May 2018 15:12:09 -0400, Ned Batchelder wrote:

> On 5/24/18 2:17 PM, Steven D'Aprano wrote:
[...]
>> But what do people think about proposing a new list replication with
>> copy operator?
>>
>>      [[]]**5
>>
>> would return a new list consisting of five shallow copies of the inner
>> list.
>>
> "shallow" will be the next problem.? Do we also need this?:
> 
>  ??? [[[]]]***5???????????? # j/k

You might be right: on further thought, I think I want deep copies, not 
shallow.

Originally I thought that deep copies was an YAGNI. Have you *ever* seen 
anyone complain that * didn't make a deep copy of the list contents? I 
never have. But then I realised that if this works, people will surely 
try to use it to make three-dimensional lists as well as two, and for 
that we need deep copies.


-- 
Steve



From steve+comp.lang.python at pearwood.info  Thu May 24 22:27:25 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 25 May 2018 02:27:25 +0000 (UTC)
Subject: why do I get syntax error on if <code>: break
References: <eed6cc31-1f63-4cb3-8623-b2963abadad7@googlegroups.com>
Message-ID: <pe7sad$klt$3@blaine.gmane.org>

On Thu, 24 May 2018 19:12:33 -0700, asa32sd23 wrote:

> here is the code, i keep getting an error, "break outside loop". if it
> is false just exit function

break doesn't exit the function, it exits the loop. There is no loop to 
exit, so it is an error.

Believe the compiler when it tells you there is a syntax error with your 
code. The compiler is always correct.



-- 
Steve



From steve+comp.lang.python at pearwood.info  Thu May 24 22:30:30 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 25 May 2018 02:30:30 +0000 (UTC)
Subject: List replication operator
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <20180524220238.GA24039@cskk.homeip.net>
 <CA+og5upwxdyW1X1cCxVR1VuUuSiHBBW0nMjNZTrCFRU0UbWMxA@mail.gmail.com>
Message-ID: <pe7sg5$klt$4@blaine.gmane.org>

On Thu, 24 May 2018 16:05:32 -0700, Paul wrote:

> How would one make a multi-dimensional list now, with truly-separate sub
> lists?  Is there just no way to do it with the replication operator?

Correct. Let's say you want to make a 1-D list with three items 
initialised to zero. This works brilliantly:

py> [0]*3
[0, 0, 0]

This seems like it ought to create a 3x3 2-D list:

py> y = [[0]*3]*3
py> y
[[0, 0, 0], [0, 0, 0], [0, 0, 0]]


but alas, it's a trap:

py> y[0][0] = 1
py> y
[[1, 0, 0], [1, 0, 0], [1, 0, 0]]


The current recommended solution is:

py> y = [[0]*3 for _ in range(3)]
py> y[0][0] = 1
py> y
[[1, 0, 0], [0, 0, 0], [0, 0, 0]]


To get a three-dimensional 3x3x3 list is even more work:

py> z = [[[0]*3 for _ in range(3)] for _ in range(3)]
py> z[0][0][0] = 1
py> z[1][1][1] = 2
py> z[2][2][2] = 3
py> z
[[[1, 0, 0], [0, 0, 0], [0, 0, 0]], 
 [[0, 0, 0], [0, 2, 0], [0, 0, 0]],
 [[0, 0, 0], [0, 0, 0], [0, 0, 3]]]



With my suggestion, we get:

x = [0]**3  # one-dimensional
y = [[0]**3]**3  # two-dimensional
z = [[[0]**3]**3]**3  # three-dimensional

Or there's MRAB's suggestion of using @ instead.

The one-dimensional case can be optimized by using regular * replication 
instead of ** duplication, but that's an optimization for immutable 
objects.


Here's a subclass that implements a simple version of this for testing:

class ML(list):
    def __pow__(self, other):
        import copy
        L = []
        for i in range(other):
            L.extend(copy.deepcopy(obj) for obj in self)
        return ML(L)


And in use to generate a 3-D list:

py> z = ML([ML([ML([0])**3])**3])**3
py> z[0][0][0] = 1
py> z[1][1][1] = 2
py> z[2][2][2] = 3
py> z
[[[1, 0, 0], [0, 0, 0], [0, 0, 0]],
 [[0, 0, 0], [0, 2, 0], [0, 0, 0]],
 [[0, 0, 0], [0, 0, 0], [0, 0, 3]]]


The repeated calls to ML() are ugly and are only there because the [] 
syntax creates ordinary lists, not my subclass.


-- 
Steve



From steve+comp.lang.python at pearwood.info  Thu May 24 22:32:58 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 25 May 2018 02:32:58 +0000 (UTC)
Subject: List replication operator
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <20180524220238.GA24039@cskk.homeip.net>
Message-ID: <pe7skq$klt$5@blaine.gmane.org>

On Fri, 25 May 2018 08:02:38 +1000, Cameron Simpson wrote:

> I'm also against the "**" spelling I find, for much the same reasons
> that people oppose allowing "=" and "==" in the same syntactic location:
> they're easy to get wrong through typing inaccuracy.

Do you often write

   y = 2**x

when you meant 2*x?

In any case, I'm not wedded to the ** spelling, MRAB's suggestion of @ 
would work for me too.


-- 
Steve



From tallpaul at gmail.com  Thu May 24 22:45:38 2018
From: tallpaul at gmail.com (Paul)
Date: Fri, 25 May 2018 02:45:38 +0000
Subject: List replication operator
In-Reply-To: <pe7skq$klt$5@blaine.gmane.org>
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <20180524220238.GA24039@cskk.homeip.net>
 <pe7skq$klt$5@blaine.gmane.org>
Message-ID: <CA+og5uqYUQVbgMHnaeV+r2krmHHAc1R5MmUTcymQzxBL3PDB-Q@mail.gmail.com>

how often would people here have needed this new operator, if it had
existed?


From mikhailwas at gmail.com  Fri May 25 00:34:33 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Fri, 25 May 2018 07:34:33 +0300
Subject: Raw string statement (proposal)
Message-ID: <CAE6NSRBzDZrV8P+iJQxuENNAtmAAwSaNEbMnKMb_dgGw7yEH3Q@mail.gmail.com>

Hi.
I've put some thoughts together, and
need some feedback on this proposal.
Main question is:  Is it convincing?
Is there any flaw?
My own opinion - there IS something to chase.
Still the justification for such syntax is hard.



Raw string statement
--------------

Issue
---------

Vast majority of tasks include operations with text in
various grades of complexity. It is relevant even by
simple ubiquitous tasks, like for example defining file paths.
String literals are interpreted - i.e. special character "\" may
change the contents of a string.
Python raw string r"" has the least amount of such cases :
namely the inclusion of the quote character requires escaping.
There is still no string type which is totally uninterpreted.
As a result, any text piece that contains a quote must
be *edited* before it can be used in sources.

This may seem a minor problem, but if we count all
cases, then the cumulative long-term impact may be significant.
Also this problem may become more acute in cases related to:
- development of text/code generators
- and, in general, all text processing with a lot of
  literal data definition
- proofreading

Such applications may *require* a lot of embedded text definitions and
this may even lead to frustration by proofreading of 'escaped' pieces
and it adds necessity for keeping track of changes in these pieces.
Using external resources for these tasks could help, but it may lead to
even worse experience because of spread definitions
and increased maintenance times.

The most common solution in existing syntax - triple quoted
strings and raw strings has some additional issues:

- Data is parsed including indents. This may be a benefit for some
cases (e.g. start lines always without any indent) but it also may
become confusing for the readers when not aligned with
containing block. So-called "de-denting" is also needed.

- Triple quotes cause visual ambiguity in some edge-cases,
e.g. when a string starts or ends with a quote. Also in many fonts
a pair of single quotes is visually identical to one double quote.


Proposal
-----------

Current proposal suggests adding syntax for the "raw text" statement.
This should enable the possibility to define text pieces in source
code without the need for interpreted characters.
Thereby it should solve the mentioned issues.
Additionally it should solve some issues with visual appearance.


Specification
---------

Raw string statement has the following form:

    name >>> "condition_string"
    ... text ...

in example:

    data >>> "  "
      begin
      end
    #rest

will parse the block by comparing each next
line part with the string "  " (2 spaces here).
This will return: "  begin\n  end"

-- Additional option: parse and remove:

    data >>> !"  "
      begin
      end
    #rest

Will parse by the same rule but also remove
the string from the result: "begin\nend"

- Additional option: parse *until* condition:

    data >>> ?"#eof"
    begin
    end
    #eof

Will parse up to character sequence "#eof" (if it is on the
same level) and returns: "begin\nend".
The benefit of last option - the data can be put at zero
level. It may be also prefered due to explicit terminator.


General rules:
--------
- parsing is aware of the indent of containing
  block, i.e. no de-dention needed.
- single line assignment may be allowed with
  some restrictions.

Difficulties:
--------
- change of core parsing rules
- backward compatibility broken
- syntax highlighting may not work


From cs at cskk.id.au  Fri May 25 01:26:53 2018
From: cs at cskk.id.au (Cameron Simpson)
Date: Fri, 25 May 2018 15:26:53 +1000
Subject: List replication operator
In-Reply-To: <pe7skq$klt$5@blaine.gmane.org>
References: <pe7skq$klt$5@blaine.gmane.org>
Message-ID: <20180525052653.GA104@cskk.homeip.net>

On 25May2018 02:32, Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
>On Fri, 25 May 2018 08:02:38 +1000, Cameron Simpson wrote:
>
>> I'm also against the "**" spelling I find, for much the same reasons
>> that people oppose allowing "=" and "==" in the same syntactic location:
>> they're easy to get wrong through typing inaccuracy.
>
>Do you often write
>
>   y = 2**x
>
>when you meant 2*x?

Well, no, but in that context they mean very different things. Your * vs ** 
mean very similar things.

>In any case, I'm not wedded to the ** spelling, MRAB's suggestion of @
>would work for me too.

Hmm, perhaps.

I rarely use the * list replicator myself (though I used it just the other day 
to prefill a list with None). What's your commonest use case? And also, what's 
you're commonest use case which is prone the the issue a shallow copy would 
help with?

Cheers,
Cameron Simpson <cs at cskk.id.au>


From cs at cskk.id.au  Fri May 25 01:30:36 2018
From: cs at cskk.id.au (Cameron Simpson)
Date: Fri, 25 May 2018 15:30:36 +1000
Subject: List replication operator
In-Reply-To: <pe7s63$klt$2@blaine.gmane.org>
References: <pe7s63$klt$2@blaine.gmane.org>
Message-ID: <20180525053036.GA24957@cskk.homeip.net>

On 25May2018 02:25, Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
>On Thu, 24 May 2018 15:12:09 -0400, Ned Batchelder wrote:
>> On 5/24/18 2:17 PM, Steven D'Aprano wrote:
>[...]
>>> But what do people think about proposing a new list replication with
>>> copy operator?
>>>
>>>      [[]]**5
>>>
>>> would return a new list consisting of five shallow copies of the inner
>>> list.
>>>
>> "shallow" will be the next problem.? Do we also need this?:
>>
>>  ??? [[[]]]***5???????????? # j/k
>
>You might be right: on further thought, I think I want deep copies, not
>shallow.
>
>Originally I thought that deep copies was an YAGNI. Have you *ever* seen
>anyone complain that * didn't make a deep copy of the list contents? I
>never have. But then I realised that if this works, people will surely
>try to use it to make three-dimensional lists as well as two, and for
>that we need deep copies.

In the deep copy scenario I am far far less opposed - _that_ is practically 
exponential memory use, and so the "**" is much more apt :-)

I think I'm basicly against a shallow copy and not against a deep copy, because 
the shallow copy only pushes the issue out one layer.

So, how to various forms of multidimensional lists play out as code?

Cheers,
Cameron Simpson <cs at cskk.id.au>


From dieter at handshake.de  Fri May 25 01:55:50 2018
From: dieter at handshake.de (dieter)
Date: Fri, 25 May 2018 07:55:50 +0200
Subject: convert a string to a variable
References: <21d54ddd-4797-44ad-ad76-931dbd9235ff@googlegroups.com>
Message-ID: <87wovse0t5.fsf@handshake.de>

bruceg113355 at gmail.com writes:

> I am trying to convert a string to a variable.
>
> I got cases 1 & 2 to work, but not cases 3 & 4.
>
> The print statement in cases 3 & 4 reports the following:
>     builtins.AttributeError: type object 'animal' has no attribute 'tiger'
>     
> I am stuck on creating variables that can be accessed as follows.
>           animal.tiger
>           self.animal.tiger
>
> Any suggestions?
> ...
> # Case 3: This does not work
> indata = 'animal.tiger'
> vars()[indata] = "Tigers, big and strong!"
> print (animal.tiger)

In the expression "animal.tiger", the "variable" is "animal",
not "animal.tiger". It is evaluated as follows:
determine the object bound to "animal", access its attribute "tiger".
Your error message tells you that the first step (object bound
to "animal") has been successful, but the result lacks the
attribute "tiger".

> #Case 4: This does not work
> class animal():
>     def create (self, indata):
>         vars(self)[indata] = "Tigers, big and strong!"

Here you want to define the attribute "tiger" (I think),
not "animal.tiger". Note that the "." in a Python expression
(not a string) separates two individual steps: determine
an object corresponding to the leftside to the "."; access
the attribute corresponding to the name following the ".".
>         print (self.animal.tiger)
>
> tmp = animal()
> tmp.create('animal.tiger')



From stefan_ml at behnel.de  Fri May 25 02:11:52 2018
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 25 May 2018 08:11:52 +0200
Subject: List replication operator
In-Reply-To: <pe7s63$klt$2@blaine.gmane.org>
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <5c29383b-d356-26e2-a8bf-92daa4361889@nedbatchelder.com>
 <pe7s63$klt$2@blaine.gmane.org>
Message-ID: <pe89b7$ild$1@blaine.gmane.org>

Steven D'Aprano schrieb am 25.05.2018 um 04:25:
> On Thu, 24 May 2018 15:12:09 -0400, Ned Batchelder wrote:
> 
>> On 5/24/18 2:17 PM, Steven D'Aprano wrote:
> [...]
>>> But what do people think about proposing a new list replication with
>>> copy operator?
>>>
>>>      [[]]**5
>>>
>>> would return a new list consisting of five shallow copies of the inner
>>> list.
>>>
>> "shallow" will be the next problem.? Do we also need this?:
>>
>>  ??? [[[]]]***5???????????? # j/k
> 
> You might be right: on further thought, I think I want deep copies, not 
> shallow.

But how would that protocol work then? What would happen with a data
structure like this:

    [( 1, [1, 2, 3] )] ** 3

? Would it also deep copy the tuple, or ignore it? What about other,
non-builtin sequence types? The '**' operator cannot just recursively call
'**' on the items in the list, because they may not support it. Or they may
support it, but not in the expected way.

And limiting this to lists of lists seems rather arbitrary. What about
subtypes of lists?

Calling "copy.deepcopy()" internally instead of a recursive '**' doesn't
seem safe either, because it also wouldn't know where to stop.

Stefan



From steve+comp.lang.python at pearwood.info  Fri May 25 02:42:43 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 25 May 2018 06:42:43 +0000 (UTC)
Subject: List replication operator
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <5c29383b-d356-26e2-a8bf-92daa4361889@nedbatchelder.com>
 <pe7s63$klt$2@blaine.gmane.org> <pe89b7$ild$1@blaine.gmane.org>
Message-ID: <pe8b93$kpa$1@blaine.gmane.org>

On Fri, 25 May 2018 08:11:52 +0200, Stefan Behnel wrote:

> Steven D'Aprano schrieb am 25.05.2018 um 04:25:
[...]

>> You might be right: on further thought, I think I want deep copies, not
>> shallow.
> 
> But how would that protocol work then? What would happen with a data
> structure like this:
> 
>     [( 1, [1, 2, 3] )] ** 3
> 
> ? Would it also deep copy the tuple, or ignore it? 

It would deep-copy the items. It would do whatever copy.deepcopy() does, 
which is deep-copy the object *all the way down*.


> What about other, non-builtin sequence types?

I've concentrated on lists because that's usually the sequence type used. 
Adding ** (or @ if you prefer) could be made part of the sequence API if 
needed, but I'd be happy to start with lists and see if there is a demand 
to add it to other objects as well.


> The '**' operator cannot just recursively
> call '**' on the items in the list, because they may not support it. Or
> they may support it, but not in the expected way.

Nobody is talking about calling ** recursively.

I gave a simple implementation. No recursion is needed, except inside 
deepcopy, which is already a solved problem.


> And limiting this to lists of lists seems rather arbitrary. What about
> subtypes of lists?

Perhaps you have heard of inheritance? If lists support this, their 
subclasses will automatically support it too, unless you override the 
relevant methods.


> Calling "copy.deepcopy()" internally instead of a recursive '**' doesn't
> seem safe either, because it also wouldn't know where to stop.

Of course it does. It stops when it has copied everything, all the way 
down. That's what it does.



-- 
Steve



From steve+comp.lang.python at pearwood.info  Fri May 25 02:45:51 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 25 May 2018 06:45:51 +0000 (UTC)
Subject: List replication operator
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <20180524220238.GA24039@cskk.homeip.net> <pe7skq$klt$5@blaine.gmane.org>
 <CA+og5uqYUQVbgMHnaeV+r2krmHHAc1R5MmUTcymQzxBL3PDB-Q@mail.gmail.com>
Message-ID: <pe8beu$kpa$2@blaine.gmane.org>

On Fri, 25 May 2018 02:45:38 +0000, Paul wrote:

> how often would people here have needed this new operator, if it had
> existed?

It is common enough that it is a FAQ on the Python website.

The list * operator isn't the most heavily used operator, but it does get 
used a bit. It comes up quite frequently in tutorials, Stackoverflow, etc.

https://www.google.com/search?q=python+multidimensional+list




-- 
Steve



From steve+comp.lang.python at pearwood.info  Fri May 25 02:48:09 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 25 May 2018 06:48:09 +0000 (UTC)
Subject: List replication operator
References: <pe7s63$klt$2@blaine.gmane.org>
 <20180525053036.GA24957@cskk.homeip.net>
Message-ID: <pe8bj8$kpa$3@blaine.gmane.org>

On Fri, 25 May 2018 15:30:36 +1000, Cameron Simpson wrote:

> So, how to various forms of multidimensional lists play out as code?

With my suggestion, we get:

x = [0]**3  # one-dimensional
y = [[0]**3]**3  # two-dimensional
z = [[[0]**3]**3]**3  # three-dimensional

Or there's MRAB's suggestion of using @ instead of the ** operator.

The one-dimensional case can be optimized by using regular * replication
instead of ** duplication, but that's an optimization for immutable
objects. Its pretty much harmless to write ** instead of * for the common 
case of a list filled with immutable ints or None.



Here's a subclass that implements a simple version of this for testing:

class ML(list):
    def __pow__(self, other):
        import copy
        L = []
        for i in range(other):
            L.extend(copy.deepcopy(obj) for obj in self)
        return ML(L)


And in use to generate a 3-D list:

py> z = ML([ML([ML([0])**3])**3])**3
py> z[0][0][0] = 1
py> z[1][1][1] = 2
py> z[2][2][2] = 3
py> z
[[[1, 0, 0], [0, 0, 0], [0, 0, 0]],
 [[0, 0, 0], [0, 2, 0], [0, 0, 0]],
 [[0, 0, 0], [0, 0, 0], [0, 0, 3]]]


The repeated calls to ML() are ugly and are only there because the []
syntax creates ordinary lists, not my subclass.



-- 
Steve



From __peter__ at web.de  Fri May 25 03:28:01 2018
From: __peter__ at web.de (Peter Otten)
Date: Fri, 25 May 2018 09:28:01 +0200
Subject: List replication operator
References: <pe6vjf$g1l$1@blaine.gmane.org>
Message-ID: <pe8dpv$9as$1@blaine.gmane.org>

Steven D'Aprano wrote:

> But what do people think about proposing a new list replication with copy
> operator?
> 
>     [[]]**5
> 
> would return a new list consisting of five shallow copies of the inner
> list.

Yet another arcanum to learn for beginners with little return.
If you cannot refrain from tinkering with the language at least concentrate 
on the features with broad application.
Thank you.



From stefan_ml at behnel.de  Fri May 25 03:50:10 2018
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 25 May 2018 09:50:10 +0200
Subject: List replication operator
In-Reply-To: <pe8dpv$9as$1@blaine.gmane.org>
References: <pe6vjf$g1l$1@blaine.gmane.org> <pe8dpv$9as$1@blaine.gmane.org>
Message-ID: <pe8f3e$tom$1@blaine.gmane.org>

Peter Otten schrieb am 25.05.2018 um 09:28:
> Steven D'Aprano wrote:
> 
>> But what do people think about proposing a new list replication with copy
>> operator?
>>
>>     [[]]**5
>>
>> would return a new list consisting of five shallow copies of the inner
>> list.
> 
> Yet another arcanum to learn for beginners with little return.
> If you cannot refrain from tinkering with the language at least concentrate 
> on the features with broad application.
> Thank you.

I might have phrased this a little less ... short, but if it's really just
about avoiding a call to "copy.deepcopy()" in certain special cases at the
cost of adding new syntax, then I have to agree that we'd better avoid
adding the syntax instead.

Stefan




From rosuav at gmail.com  Fri May 25 04:06:00 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 25 May 2018 18:06:00 +1000
Subject: List replication operator
In-Reply-To: <pe8f3e$tom$1@blaine.gmane.org>
References: <pe6vjf$g1l$1@blaine.gmane.org> <pe8dpv$9as$1@blaine.gmane.org>
 <pe8f3e$tom$1@blaine.gmane.org>
Message-ID: <CAPTjJmrAgsPUR4S_f4g4b259Uq1zVinqfB_raW9fauXr_N0mdg@mail.gmail.com>

On Fri, May 25, 2018 at 5:50 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Peter Otten schrieb am 25.05.2018 um 09:28:
>> Steven D'Aprano wrote:
>>
>>> But what do people think about proposing a new list replication with copy
>>> operator?
>>>
>>>     [[]]**5
>>>
>>> would return a new list consisting of five shallow copies of the inner
>>> list.
>>
>> Yet another arcanum to learn for beginners with little return.
>> If you cannot refrain from tinkering with the language at least concentrate
>> on the features with broad application.
>> Thank you.
>
> I might have phrased this a little less ... short, but if it's really just
> about avoiding a call to "copy.deepcopy()" in certain special cases at the
> cost of adding new syntax, then I have to agree that we'd better avoid
> adding the syntax instead.
>

But the desire is to create a simple and obvious way to construct
lists of lists. Do a survey of moderately-skilled programmers in
various languages: "How would you create an array of five empty
arrays?" Will any of them reach for copy.deepcopy() or equivalent? I
doubt it. Most likely you'll get explicit loops. In Python, you'll
probably get a mixture of explicit loops, list comps, and the flawed
"[[]]*5". That's what this is being compared to.

I'm +0.25 on this. I wouldn't personally use it very often, but it
doesn't much hurt to have it. Downside: while it's all very well to
say that this is equivalent to copy.deepcopy(), that would imply
replicating copy.deepcopy's semantics in the core list type (unless
it's actually literally defined as importing a module and calling a
function), and deepcopy is a complicated function. I don't want to
have to debug issues where ([x]@2)[1] is semantically different from
copy.deepcopy(x) after some sort of upgrade.

ChrisA


From storchaka at gmail.com  Fri May 25 05:25:34 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Fri, 25 May 2018 12:25:34 +0300
Subject: List replication operator
In-Reply-To: <pe8dpv$9as$1@blaine.gmane.org>
References: <pe6vjf$g1l$1@blaine.gmane.org> <pe8dpv$9as$1@blaine.gmane.org>
Message-ID: <pe8kma$2np$1@blaine.gmane.org>

25.05.18 10:28, Peter Otten ????:
> Steven D'Aprano wrote:
> 
>> But what do people think about proposing a new list replication with copy
>> operator?
>>
>>      [[]]**5
>>
>> would return a new list consisting of five shallow copies of the inner
>> list.
> 
> Yet another arcanum to learn for beginners with little return.
> If you cannot refrain from tinkering with the language at least concentrate
> on the features with broad application.
> Thank you.

+1



From asa32sd23 at gmail.com  Fri May 25 06:08:53 2018
From: asa32sd23 at gmail.com (asa32sd23 at gmail.com)
Date: Fri, 25 May 2018 03:08:53 -0700 (PDT)
Subject: why do I get syntax error on if <code>: break
In-Reply-To: <eed6cc31-1f63-4cb3-8623-b2963abadad7@googlegroups.com>
References: <eed6cc31-1f63-4cb3-8623-b2963abadad7@googlegroups.com>
Message-ID: <7d258fbd-0757-442e-a221-a0f70213933a@googlegroups.com>

On Thursday, May 24, 2018 at 10:12:46 PM UTC-4, asa3... at gmail.com wrote:
> here is the code, i keep getting an error, "break outside loop". if it is false just exit function
> 
> 
> def d(idx):
>     if type(idx) != int:
>         break
> 
> d('k')

thanks... I believe the compiler. So how do I exit or return nothing?


From bc at freeuk.com  Fri May 25 06:15:55 2018
From: bc at freeuk.com (bartc)
Date: Fri, 25 May 2018 11:15:55 +0100
Subject: Raw string statement (proposal)
In-Reply-To: <mailman.127.1527222875.18022.python-list@python.org>
References: <CAE6NSRBzDZrV8P+iJQxuENNAtmAAwSaNEbMnKMb_dgGw7yEH3Q@mail.gmail.com>
 <mailman.127.1527222875.18022.python-list@python.org>
Message-ID: <lnRNC.222267$Vs7.138416@fx41.am4>

On 25/05/2018 05:34, Mikhail V wrote:

> Proposal
> -----------
> 
> Current proposal suggests adding syntax for the "raw text" statement.
> This should enable the possibility to define text pieces in source
> code without the need for interpreted characters.
> Thereby it should solve the mentioned issues.
> Additionally it should solve some issues with visual appearance.

> General rules:
> --------
> - parsing is aware of the indent of containing
>    block, i.e. no de-dention needed.
> - single line assignment may be allowed with
>    some restrictions.
> 
> Difficulties:
> --------
> - change of core parsing rules
> - backward compatibility broken
> - syntax highlighting may not work

I had one big problem with your proposal, which is that I couldn't make 
head or tail of your syntax. Such a thing should be immediately obvious.

(In your first two examples, what IS the exact string that you're trying 
to incorporate? That is not clear at all.)

The aim is to allow arbitrary text in program source which is to be 
interpreted as a string literal, and to be able to see the text as much 
in its natural form as possible.

One problem here is how to deal with embedded non-printable characters: 
CR, LF and TAB might become part of the normal source text, but how 
about anything else? Or would you only allow text that might appear in a 
text file where those characters would also cause issues?

Another thing that might come up: suppose you do come up with a workable 
scheme, and have a source file PROG1.PY which contains such raw strings.

Would it then be possible to create a source file PROG2.PY which 
contains PROG1.PY as a raw string? That is, without changing the text 
from PROG1.PY at all.

Here's one scheme I use in another language:

    print strinclude "file.txt"

'strinclude "file.txt"' is interpreted as a string literal which 
contains the contents of file.txt, with escapes used as needed. In fact 
it can be used for binary files too.

This ticks some of the boxes, but not all: the text isn't shown inline 
in the program source code. If you send someone this source code, they 
will also need FILE.TXT.

And it won't pass my PROG2/PROG1 test above (because both strincludes 
need expanding to strings, but the compiler won't recognise the one 
inside PROG1, as that is after all just text, not program code).

As for a better proposal, I'm inclined not to make it part of the 
language at all, but to make it an editor feature: insert a block of 
arbitrary text, and give a command to turn it into a string literal. 
With perhaps another command to take a string literal within a program 
and view it as un-escaped text.

-- 
bartc


From bc at freeuk.com  Fri May 25 06:17:33 2018
From: bc at freeuk.com (bartc)
Date: Fri, 25 May 2018 11:17:33 +0100
Subject: why do I get syntax error on if <code>: break
In-Reply-To: <7d258fbd-0757-442e-a221-a0f70213933a@googlegroups.com>
References: <eed6cc31-1f63-4cb3-8623-b2963abadad7@googlegroups.com>
 <7d258fbd-0757-442e-a221-a0f70213933a@googlegroups.com>
Message-ID: <SoRNC.222268$Vs7.173796@fx41.am4>

On 25/05/2018 11:08, asa32sd23 at gmail.com wrote:
> On Thursday, May 24, 2018 at 10:12:46 PM UTC-4, asa3... at gmail.com wrote:
>> here is the code, i keep getting an error, "break outside loop". if it is false just exit function
>>
>>
>> def d(idx):
>>      if type(idx) != int:
>>          break
>>
>> d('k')
> 
> thanks... I believe the compiler. So how do I exit or return nothing?
> 

Use 'return' instead of 'break'.




From ben.usenet at bsb.me.uk  Fri May 25 06:48:49 2018
From: ben.usenet at bsb.me.uk (Ben Bacarisse)
Date: Fri, 25 May 2018 11:48:49 +0100
Subject: List replication operator
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <20180524220238.GA24039@cskk.homeip.net>
 <CA+og5upwxdyW1X1cCxVR1VuUuSiHBBW0nMjNZTrCFRU0UbWMxA@mail.gmail.com>
 <pe7sg5$klt$4@blaine.gmane.org>
 <mailman.125.1527216137.18022.python-list@python.org>
Message-ID: <87y3g8roxa.fsf@bsb.me.uk>

Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:

> On Thu, 24 May 2018 16:05:32 -0700, Paul wrote:
>
>> How would one make a multi-dimensional list now, with truly-separate sub
>> lists?  Is there just no way to do it with the replication operator?
>
> Correct. Let's say you want to make a 1-D list with three items 
> initialised to zero. This works brilliantly:
>
> py> [0]*3
> [0, 0, 0]
>
> This seems like it ought to create a 3x3 2-D list:
>
> py> y = [[0]*3]*3
> py> y
> [[0, 0, 0], [0, 0, 0], [0, 0, 0]]
>
>
> but alas, it's a trap:
>
> py> y[0][0] = 1
> py> y
> [[1, 0, 0], [1, 0, 0], [1, 0, 0]]

Another way of looking at it would be in terms of evaluation rather than
copying.  [<stuff>] evaluates to a new list object, so if there were an
alternate version of L * n (for the sake of argument L ** n) that
evaluated the list expression n times to make the new list you would
also get the behaviour you want.

You would also be able to use it in situations like this:

  import random
  [random.randint(1,10)]**6

to get (for example) [2, 4, 7, 1, 1, 8].

Of course, this is just what the [L for _ in range(n)] solution does,
but maybe the situation merits a shorthand?

<snip>
-- 
Ben.


From email at paulstgeorge.com  Fri May 25 07:04:03 2018
From: email at paulstgeorge.com (Paul St George)
Date: Fri, 25 May 2018 13:04:03 +0200
Subject: The PIL show() method looks for the default viewer. How do I change
 this to a different viewer (of my choice)?
Message-ID: <ddedae8b-f085-dfa3-08a4-2c821975cc61@paulstgeorge.com>

I am using the Python Imaging Library (PIL), Python 2 and Raspberry Pi 3 B+

My code is simply:

 ??? from PIL import Image

 ??? im = Image.open(?somepic.jpg?)
 ??? im.show() # display image


But the show() method looks for the default viewer (probably xv). How do 
I change this (in the code, or in some settings) to a different viewer 
(of my choice)?

Thanks,
Paul



From subhabangalore at gmail.com  Fri May 25 07:23:17 2018
From: subhabangalore at gmail.com (subhabangalore at gmail.com)
Date: Fri, 25 May 2018 04:23:17 -0700 (PDT)
Subject: Some Issues on Tagging Text
In-Reply-To: <mailman.110.1527200981.18022.python-list@python.org>
References: <b8a8b685-d3b5-4f4a-93f0-3e5af5720fb2@googlegroups.com>
 <20180524221459.GA59653@cskk.homeip.net>
 <mailman.110.1527200981.18022.python-list@python.org>
Message-ID: <a945cff0-2ea4-4f76-8e74-423e70b15b94@googlegroups.com>

On Friday, May 25, 2018 at 3:59:57 AM UTC+5:30, Cameron Simpson wrote:
> First up, thank you for a well described problem! Remarks inline below.
> 
> On 24May2018 03:13, wrote:
> >I have a text as,
> >
> >"Hawaii volcano generates toxic gas plume called laze PAHOA: The eruption of Kilauea volcano in Hawaii sparked new safety warnings about toxic gas on the Big Island's southern coastline after lava began flowing into the ocean and setting off a chemical reaction. Lava haze is made of dense white clouds of steam, toxic gas and tiny shards of volcanic glass. Janet Babb, a geologist with the Hawaiian Volcano Observatory, says the plume "looks innocuous, but it's not." "Just like if you drop a glass on your kitchen floor, there's some large pieces and there are some very, very tiny pieces," Babb said. "These little tiny pieces are the ones that can get wafted up in that steam plume." Scientists call the glass Limu O Pele, or Pele's seaweed, named after the Hawaiian goddess of volcano and fire"
> >
> >and I want to see its tagged output as,
> >
> >"Hawaii/TAG volcano generates toxic gas plume called laze PAHOA/TAG: The eruption of Kilauea/TAG volcano/TAG in Hawaii/TAG sparked new safety warnings about toxic gas on the Big Island's southern coastline after lava began flowing into the ocean and setting off a chemical reaction. Lava haze is made of dense white clouds of steam, toxic gas and tiny shards of volcanic glass. Janet/TAG Babb/TAG, a geologist with the Hawaiian/TAG Volcano/TAG Observatory/TAG, says the plume "looks innocuous, but it's not." "Just like if you drop a glass on your kitchen floor, there's some large pieces and there are some very, very tiny pieces," Babb/TAG said. "These little tiny pieces are the ones that can get wafted up in that steam plume." Scientists call the glass Limu/TAG O/TAG Pele/TAG, or Pele's seaweed, named after the Hawaiian goddess of volcano and fire"
> >
> >To do this I generally try to take a list at the back end as,
> >
> >Hawaii
> >PAHOA
> >Kilauea
> >volcano
> >Janet
> >Babb
> >Hawaiian
> >Volcano
> >Observatory
> >Babb
> >Limu
> >O
> >Pele
> >
> >and do a simple code as follows,
> >
> >def tag_text():
> >    corpus=open("/python27/volcanotxt.txt","r").read().split()
> >    wordlist=open("/python27/taglist.txt","r").read().split()
> 
> You might want use this to compose "wordlist":
> 
>      wordlist=set(open("/python27/taglist.txt","r").read().split())
> 
> because it will make your "if word in wordlist" test O(1) instead of O(n), 
> which will matter later if your wordlist grows.
> 
> >    list1=[]
> >    for word in corpus:
> >        if word in wordlist:
> >            word_new=word+"/TAG"
> >            list1.append(word_new)
> >        else:
> >            list1.append(word)
> >    lst1=list1
> >    tagged_text=" ".join(lst1)
> >    print tagged_text
> >
> >get the results and hand repair unwanted tags Hawaiian/TAG goddess of volcano/TAG.
> >I am looking for a better approach of coding so that I need not spend time on 
> >hand repairing.
> 
> It isn't entirely clear to me why these two taggings are unwanted. Intuitively, 
> they seem to be either because "Hawaiian goddess" is a compound term where you 
> don't want "Hawaiian" to get a tag, or because "Hawaiian" has already received 
> a tag earlier in the list. Or are there other criteria.
> 
> If you want to solve this problem with a programme you must first clearly 
> define what makes an unwanted tag "unwanted".
> 
> For example, "Hawaiian" is an adjective, and therefore will always be part of a 
> compound term.
> 
> Can you clarify what makes these taggings you mention "unwanted"?
> 
> Cheers,
> 
Sir, Thank you for your kind time to write such a nice reply. 

By unwanted I did not mean anything so intricate. 
Unwanted meant things I did not want. 
For example, 
if my target phrases included terms like, 
government of Mexico, 

now in my list I would have words with their tags as,
government
of
Mexico

If I put these words in list it would tag 
government/TAG of/TAG Mexico

but would also tag all the "of" which may be
anywhere like haze is made of/TAG dense white,
clouds of/TAG steam, etc. 

Cleaning these unwanted places become a daunting task
to me. 

I have been experimenting around 
wordlist=["Kilauea volcano","Kilauea/TAG volcano/TAG"),("Hawaii","Hawaii/TAG"),...]
tag=reduce(lambda a, kv: a.replace(*kv), wordlist, corpus)

is giving me sizeably good result but size of the wordlist is slight concern. 



From steve+comp.lang.python at pearwood.info  Fri May 25 07:45:51 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 25 May 2018 11:45:51 +0000 (UTC)
Subject: List replication operator
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <20180524220238.GA24039@cskk.homeip.net>
 <CA+og5upwxdyW1X1cCxVR1VuUuSiHBBW0nMjNZTrCFRU0UbWMxA@mail.gmail.com>
 <pe7sg5$klt$4@blaine.gmane.org>
 <mailman.125.1527216137.18022.python-list@python.org>
 <87y3g8roxa.fsf@bsb.me.uk>
Message-ID: <pe8t1f$f9e$1@blaine.gmane.org>

On Fri, 25 May 2018 11:48:49 +0100, Ben Bacarisse wrote:

> Another way of looking at it would be in terms of evaluation rather than
> copying.  [<stuff>] evaluates to a new list object, so if there were an
> alternate version of L * n (for the sake of argument L ** n) that
> evaluated the list expression n times to make the new list you would
> also get the behaviour you want.

The problem is, the * operator doesn't seen the expression "[]" it sees 
the object. So there's no way of delaying the evaluation of the [] until 
after the * operator is called in current Python, nor any way of telling 
it when to evaluate the expression.

It would require special syntax, like the lambda syntax delays evaluation 
of the expression and returns a function, instead of evaluating the body 
of the function at the point of definition.

I'm not interested in adding a special case to the interpreter just for 
this specific issue. If there was a way to delay arbitrary expressions in 
arbitrary places for arbitrary uses, that would be interesting to 
consider, but to limit it to "list ** count" is not.



-- 
Steve



From steve+comp.lang.python at pearwood.info  Fri May 25 07:53:54 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 25 May 2018 11:53:54 +0000 (UTC)
Subject: List replication operator
References: <pe6vjf$g1l$1@blaine.gmane.org> <pe8dpv$9as$1@blaine.gmane.org>
Message-ID: <pe8tgi$h8n$1@blaine.gmane.org>

On Fri, 25 May 2018 09:28:01 +0200, Peter Otten wrote:

> Yet another arcanum to learn for beginners with little return. If you
> cannot refrain from tinkering with the language at least concentrate on
> the features with broad application. Thank you.

Broader than multi-dimensional arrays? There are a bazillion uses for 
them. How many do you need before it is "broad application"?

https://www.google.com/search?q=multidimensional+arrays

https://www.google.com/search?q=what+are+some+uses+for+multidimensional
+arrays

"My programming language doesn't support arithmetic, because I only 
provide features with broad application. Arithmetic is only useful for 
manipulating numbers."


Beginners already learn list * operator, and get *extremely emotional* 
when it doesn't copy lists like they expect:

https://bugs.python.org/issue33636

This is a frequent, recurring pain point. Experienced programmers forget 
how confusing the behaviour of * is because they're so used to the 
execution model. They forget that writing a list comp is not even close 
to obvious, not only for beginners but even some experienced Python 
programmers.




-- 
Steve



From Richard at Damon-Family.org  Fri May 25 08:05:36 2018
From: Richard at Damon-Family.org (Richard Damon)
Date: Fri, 25 May 2018 08:05:36 -0400
Subject: Some Issues on Tagging Text
In-Reply-To: <a945cff0-2ea4-4f76-8e74-423e70b15b94@googlegroups.com>
References: <b8a8b685-d3b5-4f4a-93f0-3e5af5720fb2@googlegroups.com>
 <20180524221459.GA59653@cskk.homeip.net>
 <mailman.110.1527200981.18022.python-list@python.org>
 <a945cff0-2ea4-4f76-8e74-423e70b15b94@googlegroups.com>
Message-ID: <71cac313-8069-e925-a851-bdf24a77513f@Damon-Family.org>

On 5/25/18 7:23 AM, subhabangalore at gmail.com wrote:
> On Friday, May 25, 2018 at 3:59:57 AM UTC+5:30, Cameron Simpson wrote:
>> First up, thank you for a well described problem! Remarks inline below.
>>
>> On 24May2018 03:13, wrote:
>>> I have a text as,
>>>
>>> "Hawaii volcano generates toxic gas plume called laze PAHOA: The eruption of Kilauea volcano in Hawaii sparked new safety warnings about toxic gas on the Big Island's southern coastline after lava began flowing into the ocean and setting off a chemical reaction. Lava haze is made of dense white clouds of steam, toxic gas and tiny shards of volcanic glass. Janet Babb, a geologist with the Hawaiian Volcano Observatory, says the plume "looks innocuous, but it's not." "Just like if you drop a glass on your kitchen floor, there's some large pieces and there are some very, very tiny pieces," Babb said. "These little tiny pieces are the ones that can get wafted up in that steam plume." Scientists call the glass Limu O Pele, or Pele's seaweed, named after the Hawaiian goddess of volcano and fire"
>>>
>>> and I want to see its tagged output as,
>>>
>>> "Hawaii/TAG volcano generates toxic gas plume called laze PAHOA/TAG: The eruption of Kilauea/TAG volcano/TAG in Hawaii/TAG sparked new safety warnings about toxic gas on the Big Island's southern coastline after lava began flowing into the ocean and setting off a chemical reaction. Lava haze is made of dense white clouds of steam, toxic gas and tiny shards of volcanic glass. Janet/TAG Babb/TAG, a geologist with the Hawaiian/TAG Volcano/TAG Observatory/TAG, says the plume "looks innocuous, but it's not." "Just like if you drop a glass on your kitchen floor, there's some large pieces and there are some very, very tiny pieces," Babb/TAG said. "These little tiny pieces are the ones that can get wafted up in that steam plume." Scientists call the glass Limu/TAG O/TAG Pele/TAG, or Pele's seaweed, named after the Hawaiian goddess of volcano and fire"
>>>
>>> To do this I generally try to take a list at the back end as,
>>>
>>> Hawaii
>>> PAHOA
>>> Kilauea
>>> volcano
>>> Janet
>>> Babb
>>> Hawaiian
>>> Volcano
>>> Observatory
>>> Babb
>>> Limu
>>> O
>>> Pele
>>>
>>> and do a simple code as follows,
>>>
>>> def tag_text():
>>>    corpus=open("/python27/volcanotxt.txt","r").read().split()
>>>    wordlist=open("/python27/taglist.txt","r").read().split()
>> You might want use this to compose "wordlist":
>>
>>      wordlist=set(open("/python27/taglist.txt","r").read().split())
>>
>> because it will make your "if word in wordlist" test O(1) instead of O(n), 
>> which will matter later if your wordlist grows.
>>
>>>    list1=[]
>>>    for word in corpus:
>>>        if word in wordlist:
>>>            word_new=word+"/TAG"
>>>            list1.append(word_new)
>>>        else:
>>>            list1.append(word)
>>>    lst1=list1
>>>    tagged_text=" ".join(lst1)
>>>    print tagged_text
>>>
>>> get the results and hand repair unwanted tags Hawaiian/TAG goddess of volcano/TAG.
>>> I am looking for a better approach of coding so that I need not spend time on 
>>> hand repairing.
>> It isn't entirely clear to me why these two taggings are unwanted. Intuitively, 
>> they seem to be either because "Hawaiian goddess" is a compound term where you 
>> don't want "Hawaiian" to get a tag, or because "Hawaiian" has already received 
>> a tag earlier in the list. Or are there other criteria.
>>
>> If you want to solve this problem with a programme you must first clearly 
>> define what makes an unwanted tag "unwanted".
>>
>> For example, "Hawaiian" is an adjective, and therefore will always be part of a 
>> compound term.
>>
>> Can you clarify what makes these taggings you mention "unwanted"?
>>
>> Cheers,
>>
> Sir, Thank you for your kind time to write such a nice reply. 
>
> By unwanted I did not mean anything so intricate. 
> Unwanted meant things I did not want. 
> For example, 
> if my target phrases included terms like, 
> government of Mexico, 
>
> now in my list I would have words with their tags as,
> government
> of
> Mexico
>
> If I put these words in list it would tag 
> government/TAG of/TAG Mexico
>
> but would also tag all the "of" which may be
> anywhere like haze is made of/TAG dense white,
> clouds of/TAG steam, etc. 
>
> Cleaning these unwanted places become a daunting task
> to me. 
>
> I have been experimenting around 
> wordlist=["Kilauea volcano","Kilauea/TAG volcano/TAG"),("Hawaii","Hawaii/TAG"),...]
> tag=reduce(lambda a, kv: a.replace(*kv), wordlist, corpus)
>
> is giving me sizeably good result but size of the wordlist is slight concern. 
>
The issue then sounds like you implemented tagging based on words, but
what you REALLY want is tagging based on phrases. It looks like you did
this in part because you had a tool that gave you words and not phrases.

The key here is to reframe the solution into the terms the problem
states or transforms the problem statement into something based on the
terms of the tools you are using.

Basically you had a plank of wood to attach to something and a screw,
and saw a hammer, so you hammered the screw in and wondered why it
didn't work that well.

-- 
Richard Damon



From ned at nedbatchelder.com  Fri May 25 08:06:05 2018
From: ned at nedbatchelder.com (Ned Batchelder)
Date: Fri, 25 May 2018 08:06:05 -0400
Subject: convert a string to a variable
In-Reply-To: <21d54ddd-4797-44ad-ad76-931dbd9235ff@googlegroups.com>
References: <21d54ddd-4797-44ad-ad76-931dbd9235ff@googlegroups.com>
Message-ID: <63c51ddc-c3b1-5831-96ac-9915ff0ad101@nedbatchelder.com>

On 5/24/18 6:54 PM, bruceg113355 at gmail.com wrote:
> I am trying to convert a string to a variable.
>
> I got cases 1 & 2 to work, but not cases 3 & 4.
>
> The print statement in cases 3 & 4 reports the following:
>      builtins.AttributeError: type object 'animal' has no attribute 'tiger'
>      
> I am stuck on creating variables that can be accessed as follows.
>            animal.tiger
>            self.animal.tiger
>
> Any suggestions?
>
>

Usually when people want to turn strings into variables, the best answer 
is to not make variables, but instead have a dictionary.

But I don't know what you are going to do with "animal.tiger", so I'm 
not sure the best answer.? Can you say more about the whole problem?

--Ned.


From nico.schloemer at gmail.com  Fri May 25 08:09:04 2018
From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=)
Date: Fri, 25 May 2018 14:09:04 +0200
Subject: cProfile, timed call tree
Message-ID: <CAK6Z60du+GX5iUmjfFQZz4bxSKifUQZ8hAa4vGf8qFTsOtaOXg@mail.gmail.com>

Hi everyone,

>From what I understand about the Python profilers, the type of information
you get from a stats object is

  * How much time was spent in function X,
  * what the callers and callees of function X are, and
  * and bunch of meta info about function X.

With the program
```
def prime(n):
    # compute the n-th prime number, takes longer for larger n
    return 2

def a():
    return prime(1)

def b():
    return prime(4000)

a()
b()
```
I would be able to find that `prime` took a lot of time, but not that it
took more time when called from `b()`. In other words: I cannot construct
the call tree with times from Stats.

Is this correct? If not, how to get a timed call tree from Stats? Perhaps
that's not the right think to work with?

Cheers,
Nico


From bc at freeuk.com  Fri May 25 08:36:58 2018
From: bc at freeuk.com (bartc)
Date: Fri, 25 May 2018 13:36:58 +0100
Subject: List replication operator
In-Reply-To: <mailman.105.1527185982.18022.python-list@python.org>
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <mailman.105.1527185982.18022.python-list@python.org>
Message-ID: <ArTNC.227166$oo.202952@fx35.am4>

On 24/05/2018 19:17, Steven D'Aprano wrote:

> But what do people think about proposing a new list replication with copy
> operator?
> 
>      [[]]**5
> 
> would return a new list consisting of five shallow copies of the inner
> list.
> 
> Thoughts?

Choice of ** doesn't seem right for a start, as it suggests it should 
mean []*[]*[]*[]*[], which it doesn't. (Apparently []*2 /is/ the same as 
[]+[].)


How about just:

    x = dupllist([[]], 5)
    x[0].append(777)
    print (x)

which gives:

    [[777], [], [], [], []]

Of course you have to implement dupllist(), but you'd have to implement 
** too, and that is harder. For this specific example, it can just be:

def dupllist(x,n):
     return [x[0].copy() for _ in range(n)]

-- 
bartc




From bc at freeuk.com  Fri May 25 08:44:21 2018
From: bc at freeuk.com (bartc)
Date: Fri, 25 May 2018 13:44:21 +0100
Subject: List replication operator
In-Reply-To: <ArTNC.227166$oo.202952@fx35.am4>
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <mailman.105.1527185982.18022.python-list@python.org>
 <ArTNC.227166$oo.202952@fx35.am4>
Message-ID: <vyTNC.289905$Xa4.287295@fx29.am4>

On 25/05/2018 13:36, bartc wrote:

> Of course you have to implement dupllist(), but you'd have to implement 
> ** too, and that is harder. For this specific example, it can just be:
> 
> def dupllist(x,n):
>  ??? return [x[0].copy() for _ in range(n)]
> 

On 25/05/2018 03:25, Steven D'Aprano wrote:
 > You might be right: on further thought, I think I want deep copies, not
 > shallow.

And my solution just becomes:

import copy

def dupllist(x,n):
     return [copy.deepcopy(x[0]) for i in range(n)]

(It needs to iterate repeatedly over the elements of x for a general 
list. Replacing [0] by [i%len(x)] might just do it.)


-- 
bartc


From rosuav at gmail.com  Fri May 25 08:46:37 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 25 May 2018 22:46:37 +1000
Subject: List replication operator
In-Reply-To: <ArTNC.227166$oo.202952@fx35.am4>
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <mailman.105.1527185982.18022.python-list@python.org>
 <ArTNC.227166$oo.202952@fx35.am4>
Message-ID: <CAPTjJmo0NztzXNTKLLUN-2iuTNG1WYEwYc11kQ9O+pzQ4fhetg@mail.gmail.com>

On Fri, May 25, 2018 at 10:36 PM, bartc <bc at freeuk.com> wrote:
> On 24/05/2018 19:17, Steven D'Aprano wrote:
>
>> But what do people think about proposing a new list replication with copy
>> operator?
>>
>>      [[]]**5
>>
>> would return a new list consisting of five shallow copies of the inner
>> list.
>>
>> Thoughts?
>
>
> Choice of ** doesn't seem right for a start, as it suggests it should mean
> []*[]*[]*[]*[], which it doesn't. (Apparently []*2 /is/ the same as []+[].)
>

We've already had a suggestion for [[]]@5 and that should deal with
that issue. Steven is proposing "multiply by copying" as an
alternative to "multiply by referencing", so an alternative
multiplication operator should fit that correctly. Steve, I don't want
to speak for you; can you confirm or deny acceptance of the matmul
operator as a better spelling?

ChrisA


From bc at freeuk.com  Fri May 25 08:58:03 2018
From: bc at freeuk.com (bartc)
Date: Fri, 25 May 2018 13:58:03 +0100
Subject: List replication operator
In-Reply-To: <mailman.145.1527252406.18022.python-list@python.org>
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <mailman.105.1527185982.18022.python-list@python.org>
 <ArTNC.227166$oo.202952@fx35.am4>
 <CAPTjJmo0NztzXNTKLLUN-2iuTNG1WYEwYc11kQ9O+pzQ4fhetg@mail.gmail.com>
 <mailman.145.1527252406.18022.python-list@python.org>
Message-ID: <kLTNC.335175$B36.97718@fx22.am4>

On 25/05/2018 13:46, Chris Angelico wrote:
> On Fri, May 25, 2018 at 10:36 PM, bartc <bc at freeuk.com> wrote:
>> On 24/05/2018 19:17, Steven D'Aprano wrote:
>>
>>> But what do people think about proposing a new list replication with copy
>>> operator?
>>>
>>>       [[]]**5
>>>
>>> would return a new list consisting of five shallow copies of the inner
>>> list.
>>>
>>> Thoughts?
>>
>>
>> Choice of ** doesn't seem right for a start, as it suggests it should mean
>> []*[]*[]*[]*[], which it doesn't. (Apparently []*2 /is/ the same as []+[].)
>>
> 
> We've already had a suggestion for [[]]@5 and that should deal with
> that issue.

I'm in general not in favour of piling in special symbols into a 
language just to solve some obscure or rare problem.

As I went on to demonstrate, function-like syntax (or even actual 
functions) could do that job better, by describing what the operation 
does and not leaving people scratching their heads so much when they 
encounter that funny-looking operator hidden in 20,000 lines of code.

As for '@', if a variable name can come before it /and/ after it, and 
either or both can be dotted, wouldn't that cause it to be highlighted 
as an email address in many circumstances? Such as in code posted here.

(OK, let's try it and see what happens. My Thunderbird doesn't do 
previews so I will have to post it first:

    abc at def
    abc at def.ghi)

I would find that rather annoying.

-- 
bartc


From mal at europython.eu  Fri May 25 09:20:44 2018
From: mal at europython.eu (M.-A. Lemburg)
Date: Fri, 25 May 2018 15:20:44 +0200
Subject: EuroPython 2018: Talk voting is open
Message-ID: <b8542f5d-7556-39b2-a856-c35faf024e42@europython.eu>

At EuroPython, we let our attendees have a significant say in the
selection of the sessions which are presented at the conference. We
call this ?talk voting? - attendees can tell us which submitted talks
they?d like to see at the conference.

To be eligible to vote for talks, you need to be a submitter of talks
and everyone who attended one of the previous year?s EuroPython
conferences.

	     Since we?re a bit short on time, talk voting
		will only be possible for a few days,
			until Sunday, May 27.


How talk voting works
---------------------

Please log in and proceed to the page
https://ep2018.europython.eu/en/speakers/talk-voting/ to vote for
talks.

The talk voting page lists all submitted proposals, including talks,
trainings and posters.

At the top of the page you find a few filters you can use to narrow
down the list by e.g. selecting tags you?re interested in or only show
one type of proposal and also to select the sorting order.

For each submission, you can find the talk title with a link to the
talk page.

In order to vote, have a look at the title/abstract and then indicate
your personal interest in attending this session. We have simplified
the voting process and you may chose between these four options: ?must
see?, ?want to see?, ?maybe? and ?not interested?. Please ignore the
option ?not voted? - it?s an alias for ?not interested?.

If you have questions about the talk, you can go to the talk page and
enter a comment.

Note that your votes are automatically saved to the backend without
the need to click on a save or submit button.

Talk selection
--------------

After the talk voting phase, the EuroPython Program Workgroup (WG)
will use the votes to select the talks and build a schedule.

The majority of the talks will be chosen based on the talk voting
results. Part of the available slots will be directly assigned by the
Program WG based on editorial criteria to e.g. increase diversity or
give a chance to less mainstream topics.

In general, the Program WG will try to give as many speakers a chance
to talk as possible. If speakers have submitted multiple talks, the
one with the highest rate will most likely get selected.

Help spread the word
--------------------

Please help us spread this message by sharing it on your social
networks as widely as possible. Thank you !

Link to the blog post:

https://blog.europython.eu/post/174240171877/europython-2018-talk-voting-is-open

Tweet:

https://twitter.com/europython/status/1000002457362190336


Enjoy,
--
EuroPython 2018 Team
https://ep2018.europython.eu/
https://www.europython-society.org/



From brucegoodstein at gmail.com  Fri May 25 09:44:05 2018
From: brucegoodstein at gmail.com (brucegoodstein at gmail.com)
Date: Fri, 25 May 2018 06:44:05 -0700 (PDT)
Subject: convert a string to a variable
In-Reply-To: <mailman.130.1527227761.18022.python-list@python.org>
References: <21d54ddd-4797-44ad-ad76-931dbd9235ff@googlegroups.com>
 <87wovse0t5.fsf@handshake.de>
 <mailman.130.1527227761.18022.python-list@python.org>
Message-ID: <a161463a-d9ae-4407-a669-0e545fc69005@googlegroups.com>

On Friday, May 25, 2018 at 1:56:14 AM UTC-4, dieter wrote:
> bruceg113355 at gmail.com writes:
> 
> > I am trying to convert a string to a variable.
> >
> > I got cases 1 & 2 to work, but not cases 3 & 4.
> >
> > The print statement in cases 3 & 4 reports the following:
> >     builtins.AttributeError: type object 'animal' has no attribute 'tiger'
> >     
> > I am stuck on creating variables that can be accessed as follows.
> >           animal.tiger
> >           self.animal.tiger
> >
> > Any suggestions?
> > ...
> > # Case 3: This does not work
> > indata = 'animal.tiger'
> > vars()[indata] = "Tigers, big and strong!"
> > print (animal.tiger)
> 
> In the expression "animal.tiger", the "variable" is "animal",
> not "animal.tiger". It is evaluated as follows:
> determine the object bound to "animal", access its attribute "tiger".
> Your error message tells you that the first step (object bound
> to "animal") has been successful, but the result lacks the
> attribute "tiger".
> 
> > #Case 4: This does not work
> > class animal():
> >     def create (self, indata):
> >         vars(self)[indata] = "Tigers, big and strong!"
> 
> Here you want to define the attribute "tiger" (I think),
> not "animal.tiger". Note that the "." in a Python expression
> (not a string) separates two individual steps: determine
> an object corresponding to the leftside to the "."; access
> the attribute corresponding to the name following the ".".
> >         print (self.animal.tiger)
> >
> > tmp = animal()
> > tmp.create('animal.tiger')


Hi Dieter,

After reading your response, I picked up on the 'attribute' word.

Updated case 3: (Success)

indata = 'tiger'
setattr (animal, indata, "Tigers, big and strong!!!")
print (animal.tiger)
animal.tiger = "Lions are bigger and stronger"
print (animal.tiger)

Output is:
Tigers, big and strong!!!
Lions are bigger and stronger

I am still working on case 4 using setattr.

Thanks,
Bruce



From brucegoodstein at gmail.com  Fri May 25 09:52:37 2018
From: brucegoodstein at gmail.com (brucegoodstein at gmail.com)
Date: Fri, 25 May 2018 06:52:37 -0700 (PDT)
Subject: convert a string to a variable
In-Reply-To: <mailman.143.1527249976.18022.python-list@python.org>
References: <21d54ddd-4797-44ad-ad76-931dbd9235ff@googlegroups.com>
 <63c51ddc-c3b1-5831-96ac-9915ff0ad101@nedbatchelder.com>
 <mailman.143.1527249976.18022.python-list@python.org>
Message-ID: <25f99dd5-a11b-4ed3-802f-7981cf468d0f@googlegroups.com>

On Friday, May 25, 2018 at 8:06:31 AM UTC-4, Ned Batchelder wrote:
> On 5/24/18 6:54 PM, bruceg113355 at gmail.com wrote:
> > I am trying to convert a string to a variable.
> >
> > I got cases 1 & 2 to work, but not cases 3 & 4.
> >
> > The print statement in cases 3 & 4 reports the following:
> >      builtins.AttributeError: type object 'animal' has no attribute 'tiger'
> >      
> > I am stuck on creating variables that can be accessed as follows.
> >            animal.tiger
> >            self.animal.tiger
> >
> > Any suggestions?
> >
> >
> 
> Usually when people want to turn strings into variables, the best answer 
> is to not make variables, but instead have a dictionary.
> 
> But I don't know what you are going to do with "animal.tiger", so I'm 
> not sure the best answer.? Can you say more about the whole problem?
> 
> --Ned.


Hi Ned,

I am writing a small interpreter just for fun.
My program reads and processes text from a file.
Good or bad, I prefer the variable syntax.

I got animal.tiger syntax to work. (thanks Dieter)
I am still trying to get self.animal.tiger syntax to work.

Thanks,
Bruce



From ned at nedbatchelder.com  Fri May 25 10:07:50 2018
From: ned at nedbatchelder.com (Ned Batchelder)
Date: Fri, 25 May 2018 10:07:50 -0400
Subject: convert a string to a variable
In-Reply-To: <25f99dd5-a11b-4ed3-802f-7981cf468d0f@googlegroups.com>
References: <21d54ddd-4797-44ad-ad76-931dbd9235ff@googlegroups.com>
 <63c51ddc-c3b1-5831-96ac-9915ff0ad101@nedbatchelder.com>
 <mailman.143.1527249976.18022.python-list@python.org>
 <25f99dd5-a11b-4ed3-802f-7981cf468d0f@googlegroups.com>
Message-ID: <822eea34-e174-c276-baa1-c87eba8cede6@nedbatchelder.com>

On 5/25/18 9:52 AM, brucegoodstein at gmail.com wrote:
> On Friday, May 25, 2018 at 8:06:31 AM UTC-4, Ned Batchelder wrote:
>> On 5/24/18 6:54 PM, bruceg113355 at gmail.com wrote:
>>> I am trying to convert a string to a variable.
>>>
>>> I got cases 1 & 2 to work, but not cases 3 & 4.
>>>
>>> The print statement in cases 3 & 4 reports the following:
>>>       builtins.AttributeError: type object 'animal' has no attribute 'tiger'
>>>       
>>> I am stuck on creating variables that can be accessed as follows.
>>>             animal.tiger
>>>             self.animal.tiger
>>>
>>> Any suggestions?
>>>
>>>
>> Usually when people want to turn strings into variables, the best answer
>> is to not make variables, but instead have a dictionary.
>>
>> But I don't know what you are going to do with "animal.tiger", so I'm
>> not sure the best answer.? Can you say more about the whole problem?
>>
>> --Ned.
>
> Hi Ned,
>
> I am writing a small interpreter just for fun.
> My program reads and processes text from a file.
> Good or bad, I prefer the variable syntax.

If your own code will never use these variable names, then all of your 
accesses, both reading and writing, will be through these awkward 
mechanisms, I think?? Wouldn't it be easier to use your own dictionary?

--Ned.


From rosuav at gmail.com  Fri May 25 11:27:30 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 26 May 2018 01:27:30 +1000
Subject: List replication operator
In-Reply-To: <kLTNC.335175$B36.97718@fx22.am4>
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <mailman.105.1527185982.18022.python-list@python.org>
 <ArTNC.227166$oo.202952@fx35.am4>
 <CAPTjJmo0NztzXNTKLLUN-2iuTNG1WYEwYc11kQ9O+pzQ4fhetg@mail.gmail.com>
 <mailman.145.1527252406.18022.python-list@python.org>
 <kLTNC.335175$B36.97718@fx22.am4>
Message-ID: <CAPTjJmoHSyV0U0UPytdRrENpiVGvMAZYDPCCqY6uNZV0fzpf9Q@mail.gmail.com>

On Fri, May 25, 2018 at 10:58 PM, bartc <bc at freeuk.com> wrote:
> I'm in general not in favour of piling in special symbols into a language
> just to solve some obscure or rare problem.
>
> As I went on to demonstrate, function-like syntax (or even actual functions)
> could do that job better, by describing what the operation does and not
> leaving people scratching their heads so much when they encounter that
> funny-looking operator hidden in 20,000 lines of code.
>
> As for '@', if a variable name can come before it /and/ after it, and either
> or both can be dotted, wouldn't that cause it to be highlighted as an email
> address in many circumstances? Such as in code posted here.
>
> (OK, let's try it and see what happens. My Thunderbird doesn't do previews
> so I will have to post it first:
>
>    abc at def
>    abc at def.ghi)
>
> I would find that rather annoying.
>

You're way WAY too late to debate the matrix multiplication operator.

ChrisA


From steve+comp.lang.python at pearwood.info  Fri May 25 11:27:56 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 25 May 2018 15:27:56 +0000 (UTC)
Subject: List replication operator
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <mailman.105.1527185982.18022.python-list@python.org>
 <ArTNC.227166$oo.202952@fx35.am4>
 <CAPTjJmo0NztzXNTKLLUN-2iuTNG1WYEwYc11kQ9O+pzQ4fhetg@mail.gmail.com>
 <mailman.145.1527252406.18022.python-list@python.org>
 <kLTNC.335175$B36.97718@fx22.am4>
Message-ID: <pe9a1s$iq$1@blaine.gmane.org>

On Fri, 25 May 2018 13:58:03 +0100, bartc wrote:

> As for '@', if a variable name can come before it /and/ after it, and
> either or both can be dotted, wouldn't that cause it to be highlighted
> as an email address in many circumstances? Such as in code posted here.

Sure.

And x/y might be formatted as a file system pathname in many 
circumstances, and x<y<z might be formatted as an (unclosed) HTML or XML 
tag under many circumstances, and when I write __dunder__ methods my news 
client displays them as underlined.

Fortunately I don't write code in my news client. I either use a 
programmers text editor which correctly shows Python syntax, or I use a 
basic editor which doesn't show *any* formatting at all.

What do you use?

I think it is ludicrous to expect Python to eschew any syntax which is 
given a different meaning in some other language, markup or file format.




-- 
Steve



From bc at freeuk.com  Fri May 25 11:40:34 2018
From: bc at freeuk.com (bartc)
Date: Fri, 25 May 2018 16:40:34 +0100
Subject: List replication operator
In-Reply-To: <mailman.149.1527262053.18022.python-list@python.org>
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <mailman.105.1527185982.18022.python-list@python.org>
 <ArTNC.227166$oo.202952@fx35.am4>
 <CAPTjJmo0NztzXNTKLLUN-2iuTNG1WYEwYc11kQ9O+pzQ4fhetg@mail.gmail.com>
 <mailman.145.1527252406.18022.python-list@python.org>
 <kLTNC.335175$B36.97718@fx22.am4>
 <CAPTjJmoHSyV0U0UPytdRrENpiVGvMAZYDPCCqY6uNZV0fzpf9Q@mail.gmail.com>
 <mailman.149.1527262053.18022.python-list@python.org>
Message-ID: <G7WNC.336437$sl2.259969@fx46.am4>

On 25/05/2018 16:27, Chris Angelico wrote:
> On Fri, May 25, 2018 at 10:58 PM, bartc <bc at freeuk.com> wrote:
>> I'm in general not in favour of piling in special symbols into a language
>> just to solve some obscure or rare problem.
>>
>> As I went on to demonstrate, function-like syntax (or even actual functions)
>> could do that job better, by describing what the operation does and not
>> leaving people scratching their heads so much when they encounter that
>> funny-looking operator hidden in 20,000 lines of code.
>>
>> As for '@', if a variable name can come before it /and/ after it, and either
>> or both can be dotted, wouldn't that cause it to be highlighted as an email
>> address in many circumstances? Such as in code posted here.
>>
>> (OK, let's try it and see what happens. My Thunderbird doesn't do previews
>> so I will have to post it first:
>>
>>     abc at def
>>     abc at def.ghi)
>>
>> I would find that rather annoying.
>>
> 
> You're way WAY too late to debate the matrix multiplication operator.

/The/ matrix multiplication operator?

In which language? And what was wrong with "*"?

(I've implemented matrix multiply in a language (although for 
specialised matrix types), and I used the same "*" symbol as was used to 
multiply anything else.)

Anyway this is not matrix multiplication, but replication, and using '@' 
seems more a consequence of there not being any better ones available as 
they are already used for other things.

-- 
bartc



From steve+comp.lang.python at pearwood.info  Fri May 25 11:40:41 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 25 May 2018 15:40:41 +0000 (UTC)
Subject: List replication operator
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <mailman.105.1527185982.18022.python-list@python.org>
 <ArTNC.227166$oo.202952@fx35.am4>
 <CAPTjJmo0NztzXNTKLLUN-2iuTNG1WYEwYc11kQ9O+pzQ4fhetg@mail.gmail.com>
Message-ID: <pe9app$5fo$1@blaine.gmane.org>

On Fri, 25 May 2018 22:46:37 +1000, Chris Angelico wrote:

> We've already had a suggestion for [[]]@5 and that should deal with that
> issue. Steven is proposing "multiply by copying" as an alternative to
> "multiply by referencing", so an alternative multiplication operator
> should fit that correctly. Steve, I don't want to speak for you; can you
> confirm or deny acceptance of the matmul operator as a better spelling?

I thought that ** would be less controversial than @ since that's much 
newer. Silly me.

Personally, I don't care much either way. Probably a microscopic 
preference for @ over ** since it is shorter, but not enough to matter.

The usefulness of * with lists is seriously compromised by the inability 
to copy mutable items in the list. Consequently, it is an on-going gotcha 
and pain point.

On the other hand, it is arguable that what we really need is a standard 
function to return an N-dimensional array/list:

# return a 3x4x5x6 4-D list initialised to all zeroes
arr = list.dimensions(3, 4, 5, 6, initial=0.0)




-- 
Steve



From steve+comp.lang.python at pearwood.info  Fri May 25 11:46:43 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 25 May 2018 15:46:43 +0000 (UTC)
Subject: List replication operator
References: <pe6vjf$g1l$1@blaine.gmane.org> <pe8dpv$9as$1@blaine.gmane.org>
 <pe8f3e$tom$1@blaine.gmane.org>
 <CAPTjJmrAgsPUR4S_f4g4b259Uq1zVinqfB_raW9fauXr_N0mdg@mail.gmail.com>
Message-ID: <pe9b53$h9m$1@blaine.gmane.org>

On Fri, 25 May 2018 18:06:00 +1000, Chris Angelico wrote:

> Downside: while it's all very well to say that this is equivalent to
> copy.deepcopy(), that would imply replicating copy.deepcopy's semantics
> in the core list type (unless it's actually literally defined as
> importing a module and calling a function), and deepcopy is a
> complicated function.

Betcha it's not as complicated as the import statement, and the bulk of 
that is now implemented as pure Python :-)

But you make a good point: deep copying is not a trivial operation.


-- 
Steve



From steve+comp.lang.python at pearwood.info  Fri May 25 11:47:13 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 25 May 2018 15:47:13 +0000 (UTC)
Subject: List replication operator
References: <pe6vjf$g1l$1@blaine.gmane.org> <pe8dpv$9as$1@blaine.gmane.org>
 <pe8f3e$tom$1@blaine.gmane.org>
 <CAPTjJmrAgsPUR4S_f4g4b259Uq1zVinqfB_raW9fauXr_N0mdg@mail.gmail.com>
Message-ID: <pe9b61$hig$1@blaine.gmane.org>

On Fri, 25 May 2018 18:06:00 +1000, Chris Angelico wrote:

> Downside: while it's all very well to say that this is equivalent to
> copy.deepcopy(), that would imply replicating copy.deepcopy's semantics
> in the core list type (unless it's actually literally defined as
> importing a module and calling a function), and deepcopy is a
> complicated function.

Betcha it's not as complicated as the import statement, and the bulk of 
that is now implemented as pure Python :-)

But you make a good point: deep copying is not a trivial operation.


-- 
Steve



From toby at tobiah.org  Fri May 25 11:49:17 2018
From: toby at tobiah.org (Tobiah)
Date: Fri, 25 May 2018 08:49:17 -0700
Subject: Undocumented unescape() method in HTMLParser?
Message-ID: <pe9b9t$kpf$1@gioia.aioe.org>

I came across its usage in StackOverflow somewhere, but didn't see
it in the docs.  I'm using 2.7.

I needed it while writing a class for generating text documents out of
HTML documents for attaching to emails, which lowers spam scores.  I lifted
the basis for this from the top answer here:  https://tinyurl.com/yb92x8ra

While not complete, I thought it might be of interest.  Improvements
welcome:

#####################################################

from HTMLParser import HTMLParser


def main():

         parser = TextExtractor()
         html = '''
                 <html><head>head</head><body>
                 <p>&quot;Hi there!&quot;</p>
                 <script> some javascript </script>
                 <style> class{style}</style>
                 <scrip>Print this</scrip>
                 <b>&lt;And this&gt;</b>
                 </body>
                 </html>
         '''

         print parser.strip_tags(html)


class TextExtractor(HTMLParser):

         def __init__(self):
                 HTMLParser.__init__(self)
                 self.silent_tag = None
                 self.fed = []
                 self.silent_tags = ['head', 'script', 'style']

         def handle_starttag(self, tag, atts):
                 if tag in self.silent_tags:
                         self.silent_tag = tag

         def handle_endtag(self, tag):
                 if tag == self.silent_tag:
                         self.silent_tag = None

         def handle_data(self, d):
                 if not self.silent_tag:
                         self.fed.append(d)

         def handle_entityref(self, name):
                 self.fed.append(self.unescape("&%s;" % name))

         def get_data(self):
                 return ''.join(self.fed)

         def strip_tags(self, html):
                 self.feed(html)
                 data = self.get_data()
                 self.fed = []
                 self.reset()
                 return data

main()

#####################################################

Output:


                 "Hi there!"


                 Print this
                 <And this>



Toby


From rosuav at gmail.com  Fri May 25 11:51:48 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 26 May 2018 01:51:48 +1000
Subject: List replication operator
In-Reply-To: <G7WNC.336437$sl2.259969@fx46.am4>
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <mailman.105.1527185982.18022.python-list@python.org>
 <ArTNC.227166$oo.202952@fx35.am4>
 <CAPTjJmo0NztzXNTKLLUN-2iuTNG1WYEwYc11kQ9O+pzQ4fhetg@mail.gmail.com>
 <mailman.145.1527252406.18022.python-list@python.org>
 <kLTNC.335175$B36.97718@fx22.am4>
 <CAPTjJmoHSyV0U0UPytdRrENpiVGvMAZYDPCCqY6uNZV0fzpf9Q@mail.gmail.com>
 <mailman.149.1527262053.18022.python-list@python.org>
 <G7WNC.336437$sl2.259969@fx46.am4>
Message-ID: <CAPTjJmrd1FUpOGP0MNxmtYPgLSD+e3rcauOyMpPWTQ+us=_3HA@mail.gmail.com>

On Sat, May 26, 2018 at 1:40 AM, bartc <bc at freeuk.com> wrote:
> On 25/05/2018 16:27, Chris Angelico wrote:
>>
>> On Fri, May 25, 2018 at 10:58 PM, bartc <bc at freeuk.com> wrote:
>>>
>>> I'm in general not in favour of piling in special symbols into a language
>>> just to solve some obscure or rare problem.
>>>
>>> As I went on to demonstrate, function-like syntax (or even actual
>>> functions)
>>> could do that job better, by describing what the operation does and not
>>> leaving people scratching their heads so much when they encounter that
>>> funny-looking operator hidden in 20,000 lines of code.
>>>
>>> As for '@', if a variable name can come before it /and/ after it, and
>>> either
>>> or both can be dotted, wouldn't that cause it to be highlighted as an
>>> email
>>> address in many circumstances? Such as in code posted here.
>>>
>>> (OK, let's try it and see what happens. My Thunderbird doesn't do
>>> previews
>>> so I will have to post it first:
>>>
>>>     abc at def
>>>     abc at def.ghi)
>>>
>>> I would find that rather annoying.
>>>
>>
>> You're way WAY too late to debate the matrix multiplication operator.
>
>
> /The/ matrix multiplication operator?

No, just *A* matrix multiplication operator, we come in sixpacks.

ChrisA


From rosuav at gmail.com  Fri May 25 11:56:52 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 26 May 2018 01:56:52 +1000
Subject: List replication operator
In-Reply-To: <pe9b53$h9m$1@blaine.gmane.org>
References: <pe6vjf$g1l$1@blaine.gmane.org> <pe8dpv$9as$1@blaine.gmane.org>
 <pe8f3e$tom$1@blaine.gmane.org>
 <CAPTjJmrAgsPUR4S_f4g4b259Uq1zVinqfB_raW9fauXr_N0mdg@mail.gmail.com>
 <pe9b53$h9m$1@blaine.gmane.org>
Message-ID: <CAPTjJmoCvHV=J1mHwvU1nt080Xgg8KsJPGCbnfnEuS3Cqu_DYQ@mail.gmail.com>

On Sat, May 26, 2018 at 1:46 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Fri, 25 May 2018 18:06:00 +1000, Chris Angelico wrote:
>
>> Downside: while it's all very well to say that this is equivalent to
>> copy.deepcopy(), that would imply replicating copy.deepcopy's semantics
>> in the core list type (unless it's actually literally defined as
>> importing a module and calling a function), and deepcopy is a
>> complicated function.
>
> Betcha it's not as complicated as the import statement, and the bulk of
> that is now implemented as pure Python :-)
>
> But you make a good point: deep copying is not a trivial operation.
>

Heh, true. But "a good bit" is not quite the same as if you had (don't
shoot me, this is just hypothetical) "spam".import() as a way to
obtain the same module you'd get from 'import spam'. To be a
method/operator on a core data type, it basically *all* has to be
implemented in C, otherwise there are going to be awkwardnesses.

I don't think that kills your idea, but it does mean it's a nontrivial
enhancement to the list type.

ChrisA


From abrault at mapgears.com  Fri May 25 12:11:04 2018
From: abrault at mapgears.com (Alexandre Brault)
Date: Fri, 25 May 2018 12:11:04 -0400
Subject: List replication operator
In-Reply-To: <G7WNC.336437$sl2.259969@fx46.am4>
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <mailman.105.1527185982.18022.python-list@python.org>
 <ArTNC.227166$oo.202952@fx35.am4>
 <CAPTjJmo0NztzXNTKLLUN-2iuTNG1WYEwYc11kQ9O+pzQ4fhetg@mail.gmail.com>
 <mailman.145.1527252406.18022.python-list@python.org>
 <kLTNC.335175$B36.97718@fx22.am4>
 <CAPTjJmoHSyV0U0UPytdRrENpiVGvMAZYDPCCqY6uNZV0fzpf9Q@mail.gmail.com>
 <mailman.149.1527262053.18022.python-list@python.org>
 <G7WNC.336437$sl2.259969@fx46.am4>
Message-ID: <5d43e76d-f8f2-e3dc-a321-2aa04e4315e0@mapgears.com>



On 2018-05-25 11:40 AM, bartc wrote:
> On 25/05/2018 16:27, Chris Angelico wrote:
>> You're way WAY too late to debate the matrix multiplication operator.
>
> /The/ matrix multiplication operator?
>
> In which language? And what was wrong with "*"?
>
In Python, the language we're discussing right now. What was wrong with
* is described in detail in PEP 465

> (I've implemented matrix multiply in a language (although for
> specialised matrix types), and I used the same "*" symbol as was used
> to multiply anything else.)
>
> Anyway this is not matrix multiplication, but replication, and using
> '@' seems more a consequence of there not being any better ones
> available as they are already used for other things.
>
You're right, it's not matrix multiplication. And Pathlib's use of / is
not division, nor do C++'s streams use bitshifting.
But overloading the matmul operator would allow this feature to work
without changing the syntax of the language, nor breaking existing code
(since no built-in types implement __matmul__).


From bc at freeuk.com  Fri May 25 12:12:12 2018
From: bc at freeuk.com (bartc)
Date: Fri, 25 May 2018 17:12:12 +0100
Subject: List replication operator
In-Reply-To: <mailman.151.1527262982.18022.python-list@python.org>
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <mailman.105.1527185982.18022.python-list@python.org>
 <ArTNC.227166$oo.202952@fx35.am4>
 <CAPTjJmo0NztzXNTKLLUN-2iuTNG1WYEwYc11kQ9O+pzQ4fhetg@mail.gmail.com>
 <pe9app$5fo$1@blaine.gmane.org>
 <mailman.151.1527262982.18022.python-list@python.org>
Message-ID: <lBWNC.481422$LD3.196195@fx18.am4>

On 25/05/2018 16:40, Steven D'Aprano wrote:
> On Fri, 25 May 2018 22:46:37 +1000, Chris Angelico wrote:
> 
>> We've already had a suggestion for [[]]@5 and that should deal with that
>> issue. Steven is proposing "multiply by copying" as an alternative to
>> "multiply by referencing", so an alternative multiplication operator
>> should fit that correctly. Steve, I don't want to speak for you; can you
>> confirm or deny acceptance of the matmul operator as a better spelling?
> 
> I thought that ** would be less controversial than @ since that's much
> newer. Silly me.
> 
> Personally, I don't care much either way. Probably a microscopic
> preference for @ over ** since it is shorter, but not enough to matter.
> 
> The usefulness of * with lists is seriously compromised by the inability
> to copy mutable items in the list. Consequently, it is an on-going gotcha
> and pain point.
> 
> On the other hand, it is arguable that what we really need is a standard
> function to return an N-dimensional array/list:
> 
> # return a 3x4x5x6 4-D list initialised to all zeroes
> arr = list.dimensions(3, 4, 5, 6, initial=0.0)
What stops you just writing such a function?



From steve+comp.lang.python at pearwood.info  Fri May 25 12:32:33 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 25 May 2018 16:32:33 +0000 (UTC)
Subject: "Data blocks" syntax specification draft
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
 <pdu324$l8j$1@blaine.gmane.org>
 <CAHiMU6cGz=X4LMcYac=_Us0+9ATPTrJPLZaeXmK07KbnNFSP2A@mail.gmail.com>
 <CAE6NSRA9sNDkL2RgpaUnziRv5ka2j_L4y1rScKoLJSnR+KCXpg@mail.gmail.com>
 <mailman.4.1526955481.18022.python-list@python.org>
 <pe0bn1$8ns$1@dont-email.me>
Message-ID: <pe9dr0$m88$1@blaine.gmane.org>

On Tue, 22 May 2018 08:01:05 +0200, Christian Gollwitzer wrote:

>>> If a block of static data is large enough to start to be ugly, a
>>> common approach is to load the data from some other file, in a
>>> language which is designed around structured data.
[...]

> Thing is, you can do it already now in the script, without modifying the
> Python interpreter, by parsing a triple-quoted string. See the examples
> right here: http://pyyaml.org/wiki/PyYAMLDocumentation


Indeed. But that requires the data be parsed at runtime, and requires 
either that you use only literals, or that you use some form of string 
interpolation.

Imagine if the only way to write a list in Python was:

    make_list("[1, 2, 3, %d, 5]" % n)

instead of [1, 2, 3, n, 5]. That would be annoying and inefficient. 
Parsing triple-quoted strings is a second-class solution. While I don't 
think much of Mikhail's proposed solution (except as a good example of 
how *not* to design programming syntax) the motivation is interesting: 
can we come up with a good syntax for table-based data?

Many years ago, people got frustrated with having to define dicts like 
this:

    d = {'key': value, 'a': 1, 'b': 2, ...}

and now the dict constructor allows keywords:

    d = dict(key=value, a=1, b=2, ...)

which covers the very common case of keys being strings and values being 
either identifiers or numeric literals, but cases where keys and values 
are both strings, and unlike dict displays {...} the compiler can't build 
the dict at compile-time. No compile-time optimization for us!

And I know I spend a lot of unproductive time editing tables of string 
constants, making sure all the strings are quoted, etc. I would hope 
there is a better way.

There are a very small number of languages with first-class literal 
syntax for (e.g.) XML:

Kawa
https://www.gnu.org/software/kawa/XML-literals.html

Racket
http://docs.racket-lang.org/xml/

VB.Net 
https://docs.microsoft.com/en-us/dotnet/visual-basic/programming-guide/
language-features/xml/xml-literals-overview

and possibly a few others. But it seems to be a niche feature.

There's also table-driven programming:

http://wiki.c2.com/?TableOrientedProgramming

an old, proven, but undervalued technique. Probably undervalued because 
it is *too simple for non-programmers to understand*.

https://blogs.msdn.microsoft.com/ericlippert/2004/02/24/table-driven-
programming/

I can't find any languages which have native data types for building 
tables. Have I missed any? Given how ubiquitous and useful tables of 
strings or numbers are, why aren't there simple ways to build such tables 
without parsing a string at runtime?

So there's a great big hole in programming languages here.



-- 
Steve



From steve+comp.lang.python at pearwood.info  Fri May 25 12:41:37 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 25 May 2018 16:41:37 +0000 (UTC)
Subject: List replication operator
References: <pe6vjf$g1l$1@blaine.gmane.org> <pe8dpv$9as$1@blaine.gmane.org>
 <pe8tgi$h8n$1@blaine.gmane.org>
 <6kbggd9ec3ac360d6ktbl49gervf1821ep@4ax.com>
Message-ID: <pe9ec1$epq$1@blaine.gmane.org>

On Fri, 25 May 2018 11:59:38 -0400, Dennis Lee Bieber wrote:

> 	What is your definition of a multi-dimensional array -- I tend to 
think
> of them as pre-declared sizes; not the variable (row|column) lengths
> possible when using nested lists.


Any fixed size array can be implemented using a variable-sized array and 
simply NOT increasing or shrinking the array.


Don't want to append an item to the end? Then don't append an item to the 
end :-)

(If you really care, you can subclass list and override the methods which 
modify the size of the list.)


-- 
Steve



From bc at freeuk.com  Fri May 25 12:43:51 2018
From: bc at freeuk.com (bartc)
Date: Fri, 25 May 2018 17:43:51 +0100
Subject: List replication operator
In-Reply-To: <mailman.157.1527265008.18022.python-list@python.org>
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <mailman.105.1527185982.18022.python-list@python.org>
 <ArTNC.227166$oo.202952@fx35.am4>
 <CAPTjJmo0NztzXNTKLLUN-2iuTNG1WYEwYc11kQ9O+pzQ4fhetg@mail.gmail.com>
 <mailman.145.1527252406.18022.python-list@python.org>
 <kLTNC.335175$B36.97718@fx22.am4>
 <CAPTjJmoHSyV0U0UPytdRrENpiVGvMAZYDPCCqY6uNZV0fzpf9Q@mail.gmail.com>
 <mailman.149.1527262053.18022.python-list@python.org>
 <G7WNC.336437$sl2.259969@fx46.am4>
 <5d43e76d-f8f2-e3dc-a321-2aa04e4315e0@mapgears.com>
 <mailman.157.1527265008.18022.python-list@python.org>
Message-ID: <%2XNC.227220$oo.122313@fx35.am4>

On 25/05/2018 17:11, Alexandre Brault wrote:
> 
> 
> On 2018-05-25 11:40 AM, bartc wrote:
>> On 25/05/2018 16:27, Chris Angelico wrote:
>>> You're way WAY too late to debate the matrix multiplication operator.
>>
>> /The/ matrix multiplication operator?
>>
>> In which language? And what was wrong with "*"?
>>
> In Python, the language we're discussing right now. What was wrong with
> * is described in detail in PEP 465
> 
>> (I've implemented matrix multiply in a language (although for
>> specialised matrix types), and I used the same "*" symbol as was used
>> to multiply anything else.)
>>
>> Anyway this is not matrix multiplication, but replication, and using
>> '@' seems more a consequence of there not being any better ones
>> available as they are already used for other things.
>>
> You're right, it's not matrix multiplication. And Pathlib's use of / is
> not division, nor do C++'s streams use bitshifting.

There's no need to be sarcastic.

The context here for those symbols is programming source code for which 
binary or infix +, -, * and / symbols are VERY commonly used for add, 
subtract, multiply and divide operations.

While some of them can sometimes be interpreted as various kinds of 
markup control when programming code is not distinguished from normal 
text, it can be particularly striking with @.

> But overloading the matmul operator would allow this feature to work
> without changing the syntax of the language, nor breaking existing code
> (since no built-in types implement __matmul__).

As I mentioned before, why does it need to be an operator?


From steve+comp.lang.python at pearwood.info  Fri May 25 12:49:10 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 25 May 2018 16:49:10 +0000 (UTC)
Subject: List replication operator
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <mailman.105.1527185982.18022.python-list@python.org>
 <ArTNC.227166$oo.202952@fx35.am4>
 <CAPTjJmo0NztzXNTKLLUN-2iuTNG1WYEwYc11kQ9O+pzQ4fhetg@mail.gmail.com>
 <pe9app$5fo$1@blaine.gmane.org>
 <mailman.151.1527262982.18022.python-list@python.org>
 <lBWNC.481422$LD3.196195@fx18.am4>
Message-ID: <pe9eq6$epq$2@blaine.gmane.org>

On Fri, 25 May 2018 17:12:12 +0100, bartc wrote:

> On 25/05/2018 16:40, Steven D'Aprano wrote:
[...]
>> On the other hand, it is arguable that what we really need is a
>> standard function to return an N-dimensional array/list:
>> 
>> # return a 3x4x5x6 4-D list initialised to all zeroes arr =
>> list.dimensions(3, 4, 5, 6, initial=0.0)
>
> What stops you just writing such a function?

Who says I haven't already?

Whether I have or not is not relevant to the question I'm asking.

Not every one-line function needs to be a built-in, but this is NOT a one-
line function, it isn't obviously easy to implement the right way (I 
started off thinking that shallow copies was the right solution, but then 
changed my mind), it is a repeated pain point in the language and a 
frequent gotcha.



-- 
Steve



From rosuav at gmail.com  Fri May 25 12:58:06 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 26 May 2018 02:58:06 +1000
Subject: List replication operator
In-Reply-To: <%2XNC.227220$oo.122313@fx35.am4>
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <mailman.105.1527185982.18022.python-list@python.org>
 <ArTNC.227166$oo.202952@fx35.am4>
 <CAPTjJmo0NztzXNTKLLUN-2iuTNG1WYEwYc11kQ9O+pzQ4fhetg@mail.gmail.com>
 <mailman.145.1527252406.18022.python-list@python.org>
 <kLTNC.335175$B36.97718@fx22.am4>
 <CAPTjJmoHSyV0U0UPytdRrENpiVGvMAZYDPCCqY6uNZV0fzpf9Q@mail.gmail.com>
 <mailman.149.1527262053.18022.python-list@python.org>
 <G7WNC.336437$sl2.259969@fx46.am4>
 <5d43e76d-f8f2-e3dc-a321-2aa04e4315e0@mapgears.com>
 <mailman.157.1527265008.18022.python-list@python.org>
 <%2XNC.227220$oo.122313@fx35.am4>
Message-ID: <CAPTjJmpnR2WFnACgsOCh5zZmpZHN1nh+Vc3+KhH96v19hdf+xw@mail.gmail.com>

On Sat, May 26, 2018 at 2:43 AM, bartc <bc at freeuk.com> wrote:
> On 25/05/2018 17:11, Alexandre Brault wrote:
>>
>>
>>
>> On 2018-05-25 11:40 AM, bartc wrote:
>>>
>>> On 25/05/2018 16:27, Chris Angelico wrote:
>>>>
>>>> You're way WAY too late to debate the matrix multiplication operator.
>>>
>>>
>>> /The/ matrix multiplication operator?
>>>
>>> In which language? And what was wrong with "*"?
>>>
>> In Python, the language we're discussing right now. What was wrong with
>> * is described in detail in PEP 465
>>
>>> (I've implemented matrix multiply in a language (although for
>>> specialised matrix types), and I used the same "*" symbol as was used
>>> to multiply anything else.)
>>>
>>> Anyway this is not matrix multiplication, but replication, and using
>>> '@' seems more a consequence of there not being any better ones
>>> available as they are already used for other things.
>>>
>> You're right, it's not matrix multiplication. And Pathlib's use of / is
>> not division, nor do C++'s streams use bitshifting.
>
>
> There's no need to be sarcastic.
>
> The context here for those symbols is programming source code for which
> binary or infix +, -, * and / symbols are VERY commonly used for add,
> subtract, multiply and divide operations.
>
> While some of them can sometimes be interpreted as various kinds of markup
> control when programming code is not distinguished from normal text, it can
> be particularly striking with @.

Why? Why is at-sign somehow more markuppy than asterisk, which is
*frequently* used to indicate emphasis? In fact, I have frequently run
into this, when sharing code snippets in chat systems that allow
Markdown or similar. Or if you're worried about linkification, the
humble period is far more significant. Your mail/news client might
choose to represent configure.ac as a link, since ".ac" is a valid
TLD. And datetime.date is technically valid as a domain name, though
I'm not sure if there's any actual dating site that shares a name with
this Python class.

Typable symbols are in short supply; they have different meanings in
different contexts.

ChrisA


From rgaddi at highlandtechnology.invalid  Fri May 25 12:58:19 2018
From: rgaddi at highlandtechnology.invalid (Rob Gaddi)
Date: Fri, 25 May 2018 09:58:19 -0700
Subject: List replication operator
In-Reply-To: <mailman.141.1527249376.18022.python-list@python.org>
References: <pe6vjf$g1l$1@blaine.gmane.org> <pe8dpv$9as$1@blaine.gmane.org>
 <pe8tgi$h8n$1@blaine.gmane.org>
 <mailman.141.1527249376.18022.python-list@python.org>
Message-ID: <pe9fbb$9ll$1@dont-email.me>

On 05/25/2018 04:53 AM, Steven D'Aprano wrote:
> On Fri, 25 May 2018 09:28:01 +0200, Peter Otten wrote:
> 
>> Yet another arcanum to learn for beginners with little return. If you
>> cannot refrain from tinkering with the language at least concentrate on
>> the features with broad application. Thank you.
> 
> Broader than multi-dimensional arrays? There are a bazillion uses for
> them. How many do you need before it is "broad application"?
> 
 > [snip]
> 
> This is a frequent, recurring pain point. Experienced programmers forget
> how confusing the behaviour of * is because they're so used to the
> execution model. They forget that writing a list comp is not even close
> to obvious, not only for beginners but even some experienced Python
> programmers.
> 

I agree that it's non-obvious, but I disagree with your diagnosis.  The 
non-obvious bit is that the empty list is a reference to a newly created 
mutable, not an immutable constant.  Or, more the point, that the word 
"mutable" is one that you need to know and think about in the first place.

The thing tripping the young pups is not understanding the underlying 
Python concepts of objects and their references.  And I sympathize; 
Python's handling there is seriously non-trival.  I guarantee everyone 
on this list got bit by it when they were starting out, either in this 
case or as a default argument.  I probably still manage to screw it up a 
couple times a year due to not thinking about it clearly enough.

So, in the spirit of explicit being better than implicit, please assume 
that for actual implementation replicate would be a static method of 
actual list, rather than the conveniently executable hackjob below.

_list = list
_nodefault = object()

class list(_list):
   @staticmethod
   def replicate(*n, fill=_nodefault, call=list):
     """Return a list of specified dimensions.

     Fill and call can be used to prime the list with initial values, the
     default is to create a list of empty lists.

     Parameters:
       n : List of dimensions
       fill: If provided, the fill object is used in all locations.
       call: If fill is not provided, the result of call (a function of
       no arguments) is used in all locations.

     Example:
       >>> a = list.replicate(2, 3)
       >>> a
       [[[], []], [[], []], [[], []]]
       >>> a[0][0].append('a')
       >>> a
       [[['a'], []], [[], []], [[], []]]

       >>> b = list.replicate(2, 3, fill=[])
       >>> b
       [[[], []], [[], []], [[], []]]
       >>> b[0][0].append('a')
       >>> b
       [[['a'], ['a']], [['a'], ['a']], [['a'], ['a']]]

       >>> c = list.replicate(2, 3, call=dict)
       >>> c
       [[{}, {}], [{}, {}], [{}, {}]]
       >>> c[0][0]['swallow'] = 'unladen'
       >>> c
       [[{'swallow': 'unladen'}, {}], [{}, {}], [{}, {}]]

       >>> d = list.replicate(2, 3, fill=0)
       >>> d
       [[0, 0], [0, 0], [0, 0]]
       >>> d[0][0] = 5
       >>> d
       [[5, 0], [0, 0], [0, 0]]
     """

     if n:
       this = n[-1]
       future = n[:-1]
       return [
         list.replicate(*future, fill=fill, call=call)
           for _ in range(this)
       ]
     elif fill is _nodefault:
       return call()
     else:
       return fill


-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.


From bc at freeuk.com  Fri May 25 13:13:40 2018
From: bc at freeuk.com (bartc)
Date: Fri, 25 May 2018 18:13:40 +0100
Subject: List replication operator
In-Reply-To: <pe9fbb$9ll$1@dont-email.me>
References: <pe6vjf$g1l$1@blaine.gmane.org> <pe8dpv$9as$1@blaine.gmane.org>
 <pe8tgi$h8n$1@blaine.gmane.org>
 <mailman.141.1527249376.18022.python-list@python.org>
 <pe9fbb$9ll$1@dont-email.me>
Message-ID: <ZuXNC.232553$Vm6.159577@fx45.am4>

On 25/05/2018 17:58, Rob Gaddi wrote:

> So, in the spirit of explicit being better than implicit, please assume 
> that for actual implementation replicate would be a static method of 
> actual list, rather than the conveniently executable hackjob below.
> 
> _list = list
> _nodefault = object()
> 
> class list(_list):
>  ? @staticmethod
>  ? def replicate(*n, fill=_nodefault, call=list):

That seems to work, but the dimensions are created in reverse order to 
what I expected. Which is to have the order of indices corresponding to 
the order of dimensions. So:

  x=list.replicate(2,3,4)

  print (len(x))
  print (len(x[0]))
  print (len(x[0][0]))

Gives output of 4, 3, 2 rather than 2, 3, 4.

Which means that x[0][0][3] is a bounds error.

-- 
bartc


From rgaddi at highlandtechnology.invalid  Fri May 25 13:41:08 2018
From: rgaddi at highlandtechnology.invalid (Rob Gaddi)
Date: Fri, 25 May 2018 10:41:08 -0700
Subject: List replication operator
In-Reply-To: <ZuXNC.232553$Vm6.159577@fx45.am4>
References: <pe6vjf$g1l$1@blaine.gmane.org> <pe8dpv$9as$1@blaine.gmane.org>
 <pe8tgi$h8n$1@blaine.gmane.org>
 <mailman.141.1527249376.18022.python-list@python.org>
 <pe9fbb$9ll$1@dont-email.me> <ZuXNC.232553$Vm6.159577@fx45.am4>
Message-ID: <pe9hrl$skt$1@dont-email.me>

On 05/25/2018 10:13 AM, bartc wrote:
> On 25/05/2018 17:58, Rob Gaddi wrote:
> 
>> So, in the spirit of explicit being better than implicit, please 
>> assume that for actual implementation replicate would be a static 
>> method of actual list, rather than the conveniently executable hackjob 
>> below.
>>
>> _list = list
>> _nodefault = object()
>>
>> class list(_list):
>> ?? @staticmethod
>> ?? def replicate(*n, fill=_nodefault, call=list):
> 
> That seems to work, but the dimensions are created in reverse order to 
> what I expected. Which is to have the order of indices corresponding to 
> the order of dimensions. So:
> 
>  ?x=list.replicate(2,3,4)
> 
>  ?print (len(x))
>  ?print (len(x[0]))
>  ?print (len(x[0][0]))
> 
> Gives output of 4, 3, 2 rather than 2, 3, 4.
> 
> Which means that x[0][0][3] is a bounds error.
> 

A fair point.  Something about multidimensional arrays always makes me 
semi-dyslexic.  And there I was wondering why making it work right had 
required I rip dimensions off the list from the end instead.

Corrected version below.  list.replicate(3, 2) now means "3 of 2 of 
this" as one would expect.  This is one of those days when doctest is my 
favorite thing about Python.

_list = list
_nodefault = object()

class list(_list):
   @staticmethod
   def replicate(*n, fill=_nodefault, call=list):
     """Return a list of specified dimensions.

     Fill and call can be used to prime the list with initial values, the
     default is to create a list of empty lists.

     Parameters:
       n : List of dimensions
       fill: If provided, the fill object is used in all locations.
       call: If fill is not provided, the result of call (a function of
       no arguments) is used in all locations.

     Example:
       >>> a = list.replicate(3, 2)
       >>> a
       [[[], []], [[], []], [[], []]]
       >>> a[0][0].append('a')
       >>> a
       [[['a'], []], [[], []], [[], []]]

       >>> b = list.replicate(3, 2, fill=[])
       >>> b
       [[[], []], [[], []], [[], []]]
       >>> b[0][0].append('a')
       >>> b
       [[['a'], ['a']], [['a'], ['a']], [['a'], ['a']]]

       >>> c = list.replicate(3, 2, call=dict)
       >>> c
       [[{}, {}], [{}, {}], [{}, {}]]
       >>> c[0][0]['swallow'] = 'unladen'
       >>> c
       [[{'swallow': 'unladen'}, {}], [{}, {}], [{}, {}]]

       >>> d = list.replicate(3, 2, fill=0)
       >>> d
       [[0, 0], [0, 0], [0, 0]]
       >>> d[0][0] = 5
       >>> d
       [[5, 0], [0, 0], [0, 0]]
     """

     if n:
       this = n[0]
       future = n[1:]
       return [
         list.replicate(*future, fill=fill, call=call)
           for _ in range(this)
       ]
     elif fill is _nodefault:
       return call()
     else:
       return fill


-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.


From python at mrabarnett.plus.com  Fri May 25 15:19:14 2018
From: python at mrabarnett.plus.com (MRAB)
Date: Fri, 25 May 2018 20:19:14 +0100
Subject: List replication operator
In-Reply-To: <7agggdptle6klkgs1vd1pidgecqsnbrql1@4ax.com>
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <mailman.105.1527185982.18022.python-list@python.org>
 <ArTNC.227166$oo.202952@fx35.am4>
 <CAPTjJmo0NztzXNTKLLUN-2iuTNG1WYEwYc11kQ9O+pzQ4fhetg@mail.gmail.com>
 <pe9app$5fo$1@blaine.gmane.org> <7agggdptle6klkgs1vd1pidgecqsnbrql1@4ax.com>
Message-ID: <439541be-82d4-1717-5de6-a575a8088196@mrabarnett.plus.com>

On 2018-05-25 18:05, Dennis Lee Bieber wrote:
> On Fri, 25 May 2018 15:40:41 +0000 (UTC), Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> declaimed the following:
> 
>>On Fri, 25 May 2018 22:46:37 +1000, Chris Angelico wrote:
>>
>>> We've already had a suggestion for [[]]@5 and that should deal with that
>>> issue. Steven is proposing "multiply by copying" as an alternative to
>>> "multiply by referencing", so an alternative multiplication operator
>>> should fit that correctly. Steve, I don't want to speak for you; can you
>>> confirm or deny acceptance of the matmul operator as a better spelling?
>>
>>I thought that ** would be less controversial than @ since that's much 
>>newer. Silly me.
>>
>>Personally, I don't care much either way. Probably a microscopic 
>>preference for @ over ** since it is shorter, but not enough to matter.
>>
> 
> 	@ requires use of the weaker/shorter "ring finger" on (for me) the
> weaker left hand.
> 
On my UK keyboard, @ is on the right-hand side.

> 	** makes use of the stronger right hand, and longest finger so less a
> stretch. And the timing for the second * isn't that much.
> 
> 
> 	Let me play devil's advocate... and propose a simple change, with no
> new operators...
> 
> 	sl = [] * n	#current behavior
> 	dl = n * []	#deep copy behavior
> 
Both orders are currently valid, and do the same thing, so a change 
would break someone's code.


From cs at cskk.id.au  Fri May 25 18:24:06 2018
From: cs at cskk.id.au (Cameron Simpson)
Date: Sat, 26 May 2018 08:24:06 +1000
Subject: Some Issues on Tagging Text
In-Reply-To: <a945cff0-2ea4-4f76-8e74-423e70b15b94@googlegroups.com>
References: <a945cff0-2ea4-4f76-8e74-423e70b15b94@googlegroups.com>
Message-ID: <20180525222406.GA18660@cskk.homeip.net>

On 25May2018 04:23, Subhabrata Banerjee <subhabangalore at gmail.com> wrote:
>On Friday, May 25, 2018 at 3:59:57 AM UTC+5:30, Cameron Simpson wrote:
>> On 24May2018 03:13, wrote:
>> >I have a text as,
>> >
>> >"Hawaii volcano generates toxic gas plume called laze PAHOA: The eruption of Kilauea volcano in Hawaii sparked new safety warnings about toxic gas on the Big Island's southern coastline after lava began flowing into the ocean and setting off a chemical reaction. Lava haze is made of dense white clouds of steam, toxic gas and tiny shards of volcanic glass. Janet Babb, a geologist with the Hawaiian Volcano Observatory, says the plume "looks innocuous, but it's not." "Just like if you drop a glass on your kitchen floor, there's some large pieces and there are some very, very tiny pieces," Babb said. "These little tiny pieces are the ones that can get wafted up in that steam plume." Scientists call the glass Limu O Pele, or Pele's seaweed, named after the Hawaiian goddess of volcano and fire"
>> >
>> >and I want to see its tagged output as,
>> >
>> >"Hawaii/TAG volcano generates toxic gas plume called laze PAHOA/TAG: The eruption of Kilauea/TAG volcano/TAG in Hawaii/TAG sparked new safety warnings about toxic gas on the Big Island's southern coastline after lava began flowing into the ocean and setting off a chemical reaction. Lava haze is made of dense white clouds of steam, toxic gas and tiny shards of volcanic glass. Janet/TAG Babb/TAG, a geologist with the Hawaiian/TAG Volcano/TAG Observatory/TAG, says the plume "looks innocuous, but it's not." "Just like if you drop a glass on your kitchen floor, there's some large pieces and there are some very, very tiny pieces," Babb/TAG said. "These little tiny pieces are the ones that can get wafted up in that steam plume." Scientists call the glass Limu/TAG O/TAG Pele/TAG, or Pele's seaweed, named after the Hawaiian goddess of volcano and fire"
>> >
>> >To do this I generally try to take a list at the back end as,
>> >
>> >Hawaii
>> >PAHOA
[...]
>> >and do a simple code as follows,
>> >
>> >def tag_text():
>> >    corpus=open("/python27/volcanotxt.txt","r").read().split()
>> >    wordlist=open("/python27/taglist.txt","r").read().split()
[...]
>> >    list1=[]
>> >    for word in corpus:
>> >        if word in wordlist:
>> >            word_new=word+"/TAG"
>> >            list1.append(word_new)
>> >        else:
>> >            list1.append(word)
>> >    lst1=list1
>> >    tagged_text=" ".join(lst1)
>> >    print tagged_text
>> >
>> >get the results and hand repair unwanted tags Hawaiian/TAG goddess of volcano/TAG.
>> >I am looking for a better approach of coding so that I need not spend time on
>> >hand repairing.
>>
>> It isn't entirely clear to me why these two taggings are unwanted. Intuitively,
>> they seem to be either because "Hawaiian goddess" is a compound term where you
>> don't want "Hawaiian" to get a tag, or because "Hawaiian" has already received
>> a tag earlier in the list. Or are there other criteria.
>>
>> If you want to solve this problem with a programme you must first clearly
>> define what makes an unwanted tag "unwanted". [...]
>
>By unwanted I did not mean anything so intricate.
>Unwanted meant things I did not want.

That much was clear, but you need to specify in your own mind _precisely_ what 
makes some things unwanted and others wanted. Without concrete criteria you 
can't write code to implement those criteria.

I'm not saying "you need to imagine code to match these things": you're clearly 
capable of doing that. I'm saying you need to have well defined concepts of 
what makes something unwanted (or, if that is easier to define, wanted).  You 
can do that iteratively: start with your basic concept and see how well it 
works. When those concepts don't give you the outcome you desire, consider a 
specific example which isn't working and try to figure out what additional 
criterion would let you distinguish it from a working example.

>For example,
>if my target phrases included terms like,
>government of Mexico,
>
>now in my list I would have words with their tags as,
>government
>of
>Mexico
>
>If I put these words in list it would tag
>government/TAG of/TAG Mexico
>
>but would also tag all the "of" which may be
>anywhere like haze is made of/TAG dense white,
>clouds of/TAG steam, etc.
>
>Cleaning these unwanted places become a daunting task
>to me.

Richard Damon has pointed out that you seem to want phrases instead of just 
words.

>I have been experimenting around
>wordlist=["Kilauea volcano","Kilauea/TAG volcano/TAG"),("Hawaii","Hawaii/TAG"),...]
>tag=reduce(lambda a, kv: a.replace(*kv), wordlist, corpus)
>
>is giving me sizeably good result but size of the wordlist is slight concern.

You can reduce that list by generating the "wordlist" form from something 
smaller:

  base_phrases = ["Kilauea volcano", "government of Mexico", "Hawaii"]
  wordlist = [
      (base_phrase, " ".join([word + "/TAG" for word in base_phrase.split()]))
      for base_phrase in base_phrases
  ]

You could even autosplit the longer phrases so that your base_phrases 
_automatically_ becomes:

  base_phrases = ["Kilauea volcano", "Kilauea", "volcano", "government of 
  Mexico", "government", "Mexico", "Hawaii"]

That way your "replace" call would find the longer phrases before the shorter 
phrases and thus _not_ tag the single words if they occurred in a longer 
phrase, while still tagging the single words when they _didn't_ land in a 
longer phrase.

Also, it is unclear to me whether "/TAG" is a fixed string or intended to be 
distinct such as "/PROPER_NOUN", "/LOCATION" etc. If they vary then you need a 
more elaborate setup.

It sounds like you want a more general purpose parser, and that depends upon 
your purposes. If you're coding to learn the basics of breaking up text, what 
you're doing is fine and I'd stick with it. But if you're just after the 
outcome (tags), you could use other libraries to break up the text.

For example, the Natural Language ToolKit (NLTK) will do structured parsing of 
text and return you a syntax tree, and it has many other facilities. Doco:

  http://www.nltk.org/

PyPI module:

  https://pypi.org/project/nltk/

which you can install with the command:

  pip install --user nltk

That would get you a tree structure of the corpus, which you could process more 
meaningfully. For example, you could traverse the tree and tag higher level 
nodes as you came across them, possibly then _not_ traversing their inner 
nodes. The effect of that would be that if you hit the grammatic node:

  government of Mexico

you might tags that node with "ORGANISATION", and choose not to descend inside 
it, thus avoiding tagging "government" and "of" and so forth because you have a 
high level tags. Nodes not specially recognised you're keep descending into, 
tagging smaller things.

Cheers,
Cameron Simpson <cs at cskk.id.au>


From steve+comp.lang.python at pearwood.info  Fri May 25 18:28:27 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 25 May 2018 22:28:27 +0000 (UTC)
Subject: List replication operator
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <mailman.105.1527185982.18022.python-list@python.org>
 <ArTNC.227166$oo.202952@fx35.am4>
 <CAPTjJmo0NztzXNTKLLUN-2iuTNG1WYEwYc11kQ9O+pzQ4fhetg@mail.gmail.com>
 <mailman.145.1527252406.18022.python-list@python.org>
 <kLTNC.335175$B36.97718@fx22.am4>
 <CAPTjJmoHSyV0U0UPytdRrENpiVGvMAZYDPCCqY6uNZV0fzpf9Q@mail.gmail.com>
 <mailman.149.1527262053.18022.python-list@python.org>
 <G7WNC.336437$sl2.259969@fx46.am4>
 <5d43e76d-f8f2-e3dc-a321-2aa04e4315e0@mapgears.com>
 <mailman.157.1527265008.18022.python-list@python.org>
 <%2XNC.227220$oo.122313@fx35.am4>
 <CAPTjJmpnR2WFnACgsOCh5zZmpZHN1nh+Vc3+KhH96v19hdf+xw@mail.gmail.com>
Message-ID: <pea2ma$oj4$1@blaine.gmane.org>

On Sat, 26 May 2018 02:58:06 +1000, Chris Angelico wrote:

> Your mail/news client might choose to represent configure.ac as a link,
> since ".ac" is a valid TLD.

Isn't *everything* a valid TLD now?

For the right price, at least.



-- 
Steve



From steve+comp.lang.python at pearwood.info  Fri May 25 18:31:15 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Fri, 25 May 2018 22:31:15 +0000 (UTC)
Subject: List replication operator
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <mailman.105.1527185982.18022.python-list@python.org>
 <ArTNC.227166$oo.202952@fx35.am4>
 <CAPTjJmo0NztzXNTKLLUN-2iuTNG1WYEwYc11kQ9O+pzQ4fhetg@mail.gmail.com>
 <pe9app$5fo$1@blaine.gmane.org>
 <7agggdptle6klkgs1vd1pidgecqsnbrql1@4ax.com>
Message-ID: <pea2ri$oj4$2@blaine.gmane.org>

On Fri, 25 May 2018 13:05:01 -0400, Dennis Lee Bieber wrote:

> 	Let me play devil's advocate... and propose a simple change, with 
no
> new operators...
> 
> 	sl = [] * n	#current behavior
> 	dl = n * []	#deep copy behavior

n*[] is already supported. You will suddenly change the behaviour of any 
existing Python code that uses it, depending on which version they happen 
to use.



-- 
Steve



From robertvstepp at gmail.com  Fri May 25 19:02:16 2018
From: robertvstepp at gmail.com (boB Stepp)
Date: Fri, 25 May 2018 18:02:16 -0500
Subject: The PIL show() method looks for the default viewer. How do I
 change this to a different viewer (of my choice)?
In-Reply-To: <ddedae8b-f085-dfa3-08a4-2c821975cc61@paulstgeorge.com>
References: <ddedae8b-f085-dfa3-08a4-2c821975cc61@paulstgeorge.com>
Message-ID: <CANDiX9+fF3ADqhee50RA47hecQRpsOVJjXML9=OAYzkAp9gNqw@mail.gmail.com>

On Fri, May 25, 2018 at 6:04 AM, Paul St George <email at paulstgeorge.com> wrote:
> I am using the Python Imaging Library (PIL), Python 2 and Raspberry Pi 3 B+
>
> My code is simply:
>
>     from PIL import Image
>
>     im = Image.open(?somepic.jpg?)
>     im.show() # display image
>
>
> But the show() method looks for the default viewer (probably xv). How do I
> change this (in the code, or in some settings) to a different viewer (of my
> choice)?

In the PIL docs for show() at
https://pillow.readthedocs.io/en/5.1.x/reference/Image.html#PIL.Image.Image.show
it says:

<quote>
Image.show(title=None, command=None)

Displays this image. This method is mainly intended for debugging purposes.

On Unix platforms, this method saves the image to a temporary PPM
file, and calls either the xv utility or the display utility,
depending on which one can be found.

On macOS, this method saves the image to a temporary BMP file, and
opens it with the native Preview application.

On Windows, it saves the image to a temporary BMP file, and uses the
standard BMP display utility to show it (usually Paint).

Parameters:

title ? Optional title to use for the image window, where possible.
command ? command used to show the image
</quote>

I have not had occasion to use PIL, but perhaps this command parameter
can be used to do what you want?  If not then perhaps you can write
your own function to load your image into your favorite image viewer.


-- 
boB


From drsalists at gmail.com  Fri May 25 19:26:36 2018
From: drsalists at gmail.com (Dan Stromberg)
Date: Fri, 25 May 2018 16:26:36 -0700
Subject: why do I get syntax error on if <code>: break
In-Reply-To: <eed6cc31-1f63-4cb3-8623-b2963abadad7@googlegroups.com>
References: <eed6cc31-1f63-4cb3-8623-b2963abadad7@googlegroups.com>
Message-ID: <CAGGBd_rtNCwHLNymH23WyXmU6W=-BeNZ8S832UVPYoCGWsxL2A@mail.gmail.com>

On Thu, May 24, 2018 at 7:12 PM, <asa32sd23 at gmail.com> wrote:

> here is the code, i keep getting an error, "break outside loop". if it is
> false just exit function
>
>
> def d(idx):
>     if type(idx) != int:
>         break
>
> d('k')


Not what you asked, but I believe pylint recommends using not isinstance
instead of type !=.


From ben+python at benfinney.id.au  Fri May 25 19:28:12 2018
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sat, 26 May 2018 09:28:12 +1000
Subject: Some Issues on Tagging Text
References: <a945cff0-2ea4-4f76-8e74-423e70b15b94@googlegroups.com>
 <20180525222406.GA18660@cskk.homeip.net>
Message-ID: <85bmd3joxf.fsf@benfinney.id.au>

Cameron Simpson <cs at cskk.id.au> writes:

> On 25May2018 04:23, Subhabrata Banerjee <subhabangalore at gmail.com> wrote:
> >On Friday, May 25, 2018 at 3:59:57 AM UTC+5:30, Cameron Simpson wrote:
> >> If you want to solve this problem with a programme you must first
> >> clearly define what makes an unwanted tag "unwanted". [...]
> >
> >By unwanted I did not mean anything so intricate.
> >Unwanted meant things I did not want.
>
> That much was clear, but you need to specify in your own mind
> _precisely_ what makes some things unwanted and others wanted. Without
> concrete criteria you can't write code to implement those criteria.

Importantly, ?define? means more than just coming up with examples.

    To determine with precision; to mark out with distinctness; to
    ascertain or exhibit clearly.

    <URL:https://en.wiktionary.org/wiki/define>

Before you can write code that will *reliably* select those parts you
want and exclude those parts you don't want, you need to precisely
define what should be matched such that it also excludes what should not
be matched.

Come up with statements about what you want, and ask ?if *any* text
matches this, does that necessarily mean it is wanted??

Then do exactly the same in reverse: ?if *any* text fails to match this,
does that necessarily mean it is unwanted??

Keep refining your statement until it is precise enough that you can say
?yes? to both those questions.

Then, you have a statement that is precise enough to write tests for,
and therefore to write in code.

-- 
 \       ?I have always wished for my computer to be as easy to use as |
  `\       my telephone; my wish has come true because I can no longer |
_o__)          figure out how to use my telephone.? ?Bjarne Stroustrup |
Ben Finney



From python at mrabarnett.plus.com  Fri May 25 20:01:43 2018
From: python at mrabarnett.plus.com (MRAB)
Date: Sat, 26 May 2018 01:01:43 +0100
Subject: Some Issues on Tagging Text
In-Reply-To: <20180525222406.GA18660@cskk.homeip.net>
References: <a945cff0-2ea4-4f76-8e74-423e70b15b94@googlegroups.com>
 <20180525222406.GA18660@cskk.homeip.net>
Message-ID: <7925bfa9-2058-2fdb-5a2d-e86fcb9d56bf@mrabarnett.plus.com>

On 2018-05-25 23:24, Cameron Simpson wrote:
[snip]
> You can reduce that list by generating the "wordlist" form from something
> smaller:
> 
>    base_phrases = ["Kilauea volcano", "government of Mexico", "Hawaii"]
>    wordlist = [
>        (base_phrase, " ".join([word + "/TAG" for word in base_phrase.split()]))
>        for base_phrase in base_phrases
>    ]
> 
> You could even autosplit the longer phrases so that your base_phrases
> _automatically_ becomes:
> 
>    base_phrases = ["Kilauea volcano", "Kilauea", "volcano", "government of
>    Mexico", "government", "Mexico", "Hawaii"]
> 
That list should also include "of".

As the OP doesn't want all instances of "of" to be tagged, there could 
be a separate exceptions list that contains those sub-phrases that 
should not be tagged; they would be dropped from the base_phrases list 
that was created.

[snip]


From steve+comp.lang.python at pearwood.info  Fri May 25 20:42:32 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sat, 26 May 2018 00:42:32 +0000 (UTC)
Subject: List replication operator
References: <pe6vjf$g1l$1@blaine.gmane.org> <pe8dpv$9as$1@blaine.gmane.org>
 <pe8tgi$h8n$1@blaine.gmane.org>
 <mailman.141.1527249376.18022.python-list@python.org>
 <pe9fbb$9ll$1@dont-email.me>
Message-ID: <peaahn$g7p$1@blaine.gmane.org>

On Fri, 25 May 2018 09:58:19 -0700, Rob Gaddi wrote:

[...]
>> This is a frequent, recurring pain point. Experienced programmers
>> forget how confusing the behaviour of * is because they're so used to
>> the execution model. They forget that writing a list comp is not even
>> close to obvious, not only for beginners but even some experienced
>> Python programmers.
>> 
>> 
> I agree that it's non-obvious, but I disagree with your diagnosis.  The
> non-obvious bit is that the empty list is a reference to a newly created
> mutable, not an immutable constant.  Or, more the point, that the word
> "mutable" is one that you need to know and think about in the first
> place.

I challenge you to read this bug report and claim that the poster's error 
was to *correctly* think that [[]]*5 made five references to the same 
list, but *incorrectly* failed to realise that list.append modified the 
list in place.

https://bugs.python.org/issue33636


> class list(_list):
>    @staticmethod
>    def replicate(*n, fill=_nodefault, call=list):
>      """Return a list of specified dimensions.
[...]

Interesting implementation to play with, thanks.



-- 
Steve



From greg.ewing at canterbury.ac.nz  Fri May 25 22:25:07 2018
From: greg.ewing at canterbury.ac.nz (Gregory Ewing)
Date: Sat, 26 May 2018 14:25:07 +1200
Subject: List replication operator
In-Reply-To: <G7WNC.336437$sl2.259969@fx46.am4>
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <mailman.105.1527185982.18022.python-list@python.org>
 <ArTNC.227166$oo.202952@fx35.am4>
 <CAPTjJmo0NztzXNTKLLUN-2iuTNG1WYEwYc11kQ9O+pzQ4fhetg@mail.gmail.com>
 <mailman.145.1527252406.18022.python-list@python.org>
 <kLTNC.335175$B36.97718@fx22.am4>
 <CAPTjJmoHSyV0U0UPytdRrENpiVGvMAZYDPCCqY6uNZV0fzpf9Q@mail.gmail.com>
 <mailman.149.1527262053.18022.python-list@python.org>
 <G7WNC.336437$sl2.259969@fx46.am4>
Message-ID: <fmrus5FblrsU1@mid.individual.net>

bartc wrote:
> /The/ matrix multiplication operator?
> 
> In which language? And what was wrong with "*"?

It seems you're unaware that Python *already* has an '@'
operator. It was added specifically so that numpy could
use it for matrix multiplication. A new operator was
needed because numpy already uses '*' for elementwise
multiplication.

So, the issue with @ being mistakenly marked up already
exists.

> (I've implemented matrix multiply in a language (although for 
> specialised matrix types), and I used the same "*" symbol as was used to 
> multiply anything else.)

Before '@' was added, numpy did this as well, but it
was a pain to have to use a whole different type just to
get one operator to behave differently. Painful enough
that Guido was eventually persuaded to add a new operator.

-- 
Greg


From greg.ewing at canterbury.ac.nz  Fri May 25 22:26:40 2018
From: greg.ewing at canterbury.ac.nz (Gregory Ewing)
Date: Sat, 26 May 2018 14:26:40 +1200
Subject: List replication operator
In-Reply-To: <mailman.162.1527267915.18022.python-list@python.org>
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <mailman.105.1527185982.18022.python-list@python.org>
 <ArTNC.227166$oo.202952@fx35.am4>
 <CAPTjJmo0NztzXNTKLLUN-2iuTNG1WYEwYc11kQ9O+pzQ4fhetg@mail.gmail.com>
 <pe9app$5fo$1@blaine.gmane.org> <7agggdptle6klkgs1vd1pidgecqsnbrql1@4ax.com>
 <mailman.162.1527267915.18022.python-list@python.org>
Message-ID: <fmruv0FblrsU2@mid.individual.net>

Dennis Lee Bieber wrote:
> 	@ requires use of the weaker/shorter "ring finger" on (for me) the
> weaker left hand.

But... choosing an operator on that basis would be
discriminating against left-handed people!

-- 
Greg


From steve+comp.lang.python at pearwood.info  Sat May 26 00:46:50 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sat, 26 May 2018 04:46:50 +0000 (UTC)
Subject: Enums: making a single enum
Message-ID: <peaorp$q4o$1@blaine.gmane.org>

Am I silly for wanting to make a single enum?

I have a three-state flag, True, False or Maybe. Is is confusing or bad 
practice to make a single enum for the Maybe case?


from enum import Enum
class State(Enum):
    Maybe = 2

Maybe = State.Maybe
del State




Is there a better way of handling a three-state flag like this?


-- 
Steve



From rosuav at gmail.com  Sat May 26 01:00:14 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 26 May 2018 15:00:14 +1000
Subject: Enums: making a single enum
In-Reply-To: <peaorp$q4o$1@blaine.gmane.org>
References: <peaorp$q4o$1@blaine.gmane.org>
Message-ID: <CAPTjJmqwU21ncFtxivGKm0v=S3gUM2VDLR5tUn4723WBdD-fng@mail.gmail.com>

On Sat, May 26, 2018 at 2:46 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> Am I silly for wanting to make a single enum?
>
> I have a three-state flag, True, False or Maybe. Is is confusing or bad
> practice to make a single enum for the Maybe case?
>
>
> from enum import Enum
> class State(Enum):
>     Maybe = 2
>
> Maybe = State.Maybe
> del State
>
> Is there a better way of handling a three-state flag like this?
>

Does it need to have a value of 2? If not:

# Tri-state logic
Maybe = object()

Though I have to say, you picked the wrong name for the third state.
Everyone knows it should be File_Not_Found.

ChrisA


From ian.g.kelly at gmail.com  Sat May 26 01:07:47 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Fri, 25 May 2018 23:07:47 -0600
Subject: Enums: making a single enum
In-Reply-To: <CAPTjJmqwU21ncFtxivGKm0v=S3gUM2VDLR5tUn4723WBdD-fng@mail.gmail.com>
References: <peaorp$q4o$1@blaine.gmane.org>
 <CAPTjJmqwU21ncFtxivGKm0v=S3gUM2VDLR5tUn4723WBdD-fng@mail.gmail.com>
Message-ID: <CALwzid=PBsxkQ03SD0MM0tCPTWYV1hziF6m5J3AVNKChWdrcAw@mail.gmail.com>

On Fri, May 25, 2018 at 11:00 PM, Chris Angelico <rosuav at gmail.com> wrote:
> On Sat, May 26, 2018 at 2:46 PM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> Am I silly for wanting to make a single enum?
>>
>> I have a three-state flag, True, False or Maybe. Is is confusing or bad
>> practice to make a single enum for the Maybe case?
>>
>>
>> from enum import Enum
>> class State(Enum):
>>     Maybe = 2
>>
>> Maybe = State.Maybe
>> del State
>>
>> Is there a better way of handling a three-state flag like this?
>>
>
> Does it need to have a value of 2? If not:
>
> # Tri-state logic
> Maybe = object()

The enum has a nice __str__ though.


From mikhailwas at gmail.com  Sat May 26 01:09:51 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Sat, 26 May 2018 08:09:51 +0300
Subject: Raw string statement (proposal)
In-Reply-To: <lnRNC.222267$Vs7.138416@fx41.am4>
References: <CAE6NSRBzDZrV8P+iJQxuENNAtmAAwSaNEbMnKMb_dgGw7yEH3Q@mail.gmail.com>
 <mailman.127.1527222875.18022.python-list@python.org>
 <lnRNC.222267$Vs7.138416@fx41.am4>
Message-ID: <CAE6NSRBrCSNwXJ8friR96BGu=_sxgEESphzYzaHSUoMv57a0TA@mail.gmail.com>

On Fri, May 25, 2018 at 1:15 PM, bartc <bc at freeuk.com> wrote:
> On 25/05/2018 05:34, Mikhail V wrote:
>

> I had one big problem with your proposal, which is that I couldn't make head
> or tail of your syntax. Such a thing should be immediately obvious.
>
> (In your first two examples, what IS the exact string that you're trying to
> incorporate? That is not clear at all.)

You re right, this part is not very clear.
I was working on syntax mainly, but the document is getting better.
I make constant changes to it, here is a link on github:

https://github.com/Mikhail22/Documents/blob/master/raw-strings.rst


> One problem here is how to deal with embedded non-printable characters: CR,
> LF and TAB might become part of the normal source text, but how about
> anything else? Or would you only allow text that might appear in a text file
> where those characters would also cause issues?

This syntax does not imply anything about text. From the editor's POV
it's just the same as it is now - you can insert anything in a .py file.
So it does not add new cases to current state of affairs in this regard.
But maybe I'm not completely understand your question.



> Another thing that might come up: suppose you do come up with a workable
> scheme, and have a source file PROG1.PY which contains such raw strings.
>
> Would it then be possible to create a source file PROG2.PY which contains
> PROG1.PY as a raw string? That is, without changing the text from PROG1.PY
> at all.

Should be fine, with only difference that you must
indent the PROG1.PY if it will be placed inside an indented suite.
I was thinking about this nuance - I've added a special case for this
in addition to the ? flag.

data >>> X"#tag"
...
#tag

It will treat the block "as is", namely grab everythin together with indents,
like in TQS. This may cover some edge-cases.


> Here's one scheme I use in another language:
>
>    print strinclude "file.txt"
>
> 'strinclude "file.txt"' is interpreted as a string literal which contains
> the contents of file.txt, with escapes used as needed. In fact it can be
> used for binary files too.
> [...]
> As for a better proposal, I'm inclined not to make it part of the language
> at all, but to make it an editor feature: insert a block of arbitrary text,
> and give a command to turn it into a string literal. With perhaps another
> command to take a string literal within a program and view it as un-escaped
> text.

I think it may be vice-versa - including links to external files
might be more effective approach in some sense. It only needs
some special kind of editor that would seamlessly embed them.
Though I don't know of such feature frankly speaking.
And there might be many caveats here.

And the feature to convert a text piece to Python string directly -
it is already possible in many editors - via macros or scripting.
But I think you falsely think that it is the solution to the problem.
Such changes - it's exactly what should be avoided.

In theory - an adequate feature like this (if it has real value)
will require the editor to track all manipulations - and give feedback.
You don't know when you have escaped some string or
not. And how do you save or see this events?
IOW this might be way harder to implement than the
approach with external text bits.


The simplest solution would be of course to write a translator.
For such syntax change - it is **millions** times easier than
what you've described.



M


From rosuav at gmail.com  Sat May 26 01:11:48 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 26 May 2018 15:11:48 +1000
Subject: Enums: making a single enum
In-Reply-To: <CALwzid=PBsxkQ03SD0MM0tCPTWYV1hziF6m5J3AVNKChWdrcAw@mail.gmail.com>
References: <peaorp$q4o$1@blaine.gmane.org>
 <CAPTjJmqwU21ncFtxivGKm0v=S3gUM2VDLR5tUn4723WBdD-fng@mail.gmail.com>
 <CALwzid=PBsxkQ03SD0MM0tCPTWYV1hziF6m5J3AVNKChWdrcAw@mail.gmail.com>
Message-ID: <CAPTjJmpoRS9qEY9YuY=KjmU5c2qRhjwencLHGYkrCsv29f0AcA@mail.gmail.com>

On Sat, May 26, 2018 at 3:07 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Fri, May 25, 2018 at 11:00 PM, Chris Angelico <rosuav at gmail.com> wrote:
>> On Sat, May 26, 2018 at 2:46 PM, Steven D'Aprano
>> <steve+comp.lang.python at pearwood.info> wrote:
>>> Am I silly for wanting to make a single enum?
>>>
>>> I have a three-state flag, True, False or Maybe. Is is confusing or bad
>>> practice to make a single enum for the Maybe case?
>>>
>>>
>>> from enum import Enum
>>> class State(Enum):
>>>     Maybe = 2
>>>
>>> Maybe = State.Maybe
>>> del State
>>>
>>> Is there a better way of handling a three-state flag like this?
>>>
>>
>> Does it need to have a value of 2? If not:
>>
>> # Tri-state logic
>> Maybe = object()
>
> The enum has a nice __str__ though.

Ah, good point. Then sure, go with the enum - but have a comment or
docstring explaining that this is augmented with the literals True and
False.

ChrisA


From dieter at handshake.de  Sat May 26 01:38:09 2018
From: dieter at handshake.de (dieter)
Date: Sat, 26 May 2018 07:38:09 +0200
Subject: cProfile, timed call tree
References: <CAK6Z60du+GX5iUmjfFQZz4bxSKifUQZ8hAa4vGf8qFTsOtaOXg@mail.gmail.com>
Message-ID: <87in7b3rjy.fsf@handshake.de>

Nico Schl?mer <nico.schloemer at gmail.com> writes:

> From what I understand about the Python profilers, the type of information
> you get from a stats object is
>
>   * How much time was spent in function X,
>   * what the callers and callees of function X are, and
>   * and bunch of meta info about function X.
>
> With the program
> ```
> def prime(n):
>     # compute the n-th prime number, takes longer for larger n
>     return 2
>
> def a():
>     return prime(1)
>
> def b():
>     return prime(4000)
>
> a()
> b()
> ```
> I would be able to find that `prime` took a lot of time, but not that it
> took more time when called from `b()`. In other words: I cannot construct
> the call tree with times from Stats.

You will see that "prime" was called both from "a" and "b" - and
*in this particular case*, you will see that the execution times
of "b" and "prime" are almost identical and derive that the "prime"
call of b was the expensive one.

But, in general, you are right: you cannot reconstruct complete
call trees. The reason is quite simple: maintaining information
for the complete caller ancestry (rather than just the immediate
caller) is expensive (both in terms of runtime and storage).
Profiling usually is used as a preparation for optimization.
Optimization has the greatest effects if applied to inner loops.
And for the analysis of inner loops, complete call tree information
is not necessary.

> Is this correct? If not, how to get a timed call tree from Stats? Perhaps
> that's not the right think to work with?

You will need to write your own profiler - one that keeps track
not only about the immediate caller of a function call but
of the whole caller ancestry (maybe recursion reduced).

You can see an example of a custom profiler
in "Products.ZopeProfiler" (--> PyPI).
It does not take into account the whole caller ancestry.
Instead it records additional information concerning higher level
Zope (a Web application framework) calls.



From junkaccount36 at outlook.com  Sat May 26 02:17:19 2018
From: junkaccount36 at outlook.com (junkaccount36 at outlook.com)
Date: Fri, 25 May 2018 23:17:19 -0700 (PDT)
Subject: Computations on pandas dataframes
Message-ID: <d0ec0173-7e3d-4d6f-9ea8-7d9a53e7e647@googlegroups.com>

Hi,

Python newbie here. I need help with the following two tasks I need to accomplish using Python:

------------------------

Creating a matrix of rolling variances

I have a pandas data frame of six columns, I would like to iteratively compute the variance along each column. Since I am a newbie, I don't really understand the niceties of the language and common usage patterns. What is the common Python idiom for achieving the following?

vars = []
for i in range(1, 100000):
    v = (data.iloc[range(0, i+1)].var()).values
    if len(vars) == 0:
        vars = v
    else:
        vars = np.vstack((vars, v))

Also, when I run this code, it takes a long time to execute. Can anyone suggest how to improve the running time?

------------------------

Pandas dataframe: sum of exponentially weighted correlation matrices per row

Consider the following dataframe:

df = pd.DataFrame(np.random.random((200,3)))
df['date'] = pd.date_range('2000-1-1', periods=200, freq='D')
df = df.set_index(['date'])


date 0 1 2 3 4 5 
2000-01-01 0.101782 0.111237 0.177719 0.229994 0.298786 0.747169
2000-01-02 0.348568 0.916997 0.527036 0.998144 0.544261 0.824907
2000-01-03 0.095015 0.480519 0.493345 0.632072 0.965326 0.244732
2000-01-04 0.502706 0.014287 0.045354 0.461621 0.359125 0.489150
2000-01-05 0.559364 0.337121 0.763715 0.460163 0.515309 0.732979
2000-01-06 0.488153 0.149655 0.015616 0.658693 0.864032 0.425497
2000-01-07 0.266161 0.392923 0.606358 0.286874 0.160191 0.573436
2000-01-08 0.786785 0.770826 0.202838 0.259263 0.732071 0.546918
2000-01-09 0.739847 0.886894 0.094900 0.257210 0.264688 0.005631
2000-01-10 0.615846 0.347249 0.516575 0.886096 0.347741 0.259998

Now, I want to treat each row as a vector and perform a multiplication like this:

[[0.101782]] [[0.101782 0.111237 0.177719 0.229994 0.298786 0.747169]]
[[0.111237]]
[[0.177719]]
[[0.229994]]
[[0.298786]]
[[0.747169]]

For the i-th row, let's call this X_i. Now I have a parameter alpha and I want to multiply X_i with alpha^i and sum across all the i's. In the real world, I can have thousands of rows so I need to do this with reasonably good performance.

------------------------

Many thanks in advance!


From steve+comp.lang.python at pearwood.info  Sat May 26 03:55:57 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sat, 26 May 2018 07:55:57 +0000 (UTC)
Subject: Raw string statement (proposal)
References: <CAE6NSRBzDZrV8P+iJQxuENNAtmAAwSaNEbMnKMb_dgGw7yEH3Q@mail.gmail.com>
 <mailman.127.1527222875.18022.python-list@python.org>
 <lnRNC.222267$Vs7.138416@fx41.am4>
 <CAE6NSRBrCSNwXJ8friR96BGu=_sxgEESphzYzaHSUoMv57a0TA@mail.gmail.com>
Message-ID: <peb3uc$q4o$2@blaine.gmane.org>

On Sat, 26 May 2018 08:09:51 +0300, Mikhail V wrote:

> On Fri, May 25, 2018 at 1:15 PM, bartc <bc at freeuk.com> wrote:
[...]
>> One problem here is how to deal with embedded non-printable characters:
>> CR, LF and TAB might become part of the normal source text, but how
>> about anything else? Or would you only allow text that might appear in
>> a text file where those characters would also cause issues?
> 
> This syntax does not imply anything about text. From the editor's POV
> it's just the same as it is now - you can insert anything in a .py file.
> So it does not add new cases to current state of affairs in this regard.
> But maybe I'm not completely understand your question.

Here is a string assigned to name `s` using Python's current syntax:

s = "some\ncharacters\0abc\x01\ndef\uFF0A\nhere"

How do you represent that assignment using your syntax?


And another example:

s = """this is some text
x = 'a'
y = 'b'"""
t = 'c'

How do we write that piece of code using your syntax?



>> Another thing that might come up: suppose you do come up with a
>> workable scheme, and have a source file PROG1.PY which contains such
>> raw strings.
>>
>> Would it then be possible to create a source file PROG2.PY which
>> contains PROG1.PY as a raw string? That is, without changing the text
>> from PROG1.PY at all.
> 
> Should be fine, with only difference that you must indent the PROG1.PY
> if it will be placed inside an indented suite.

Bart said WITHOUT CHANGING THE TEXT. Indenting it is changing the text.


> I was thinking about this
> nuance - I've added a special case for this in addition to the ? flag.

Oh good, another cryptic magical flag that changes the meaning of the 
syntax. Just what I was hoping for.



-- 
Steve



From steve+comp.lang.python at pearwood.info  Sat May 26 04:00:00 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sat, 26 May 2018 08:00:00 +0000 (UTC)
Subject: Enums: making a single enum
References: <peaorp$q4o$1@blaine.gmane.org>
 <CAPTjJmqwU21ncFtxivGKm0v=S3gUM2VDLR5tUn4723WBdD-fng@mail.gmail.com>
 <CALwzid=PBsxkQ03SD0MM0tCPTWYV1hziF6m5J3AVNKChWdrcAw@mail.gmail.com>
Message-ID: <peb460$q4o$3@blaine.gmane.org>

On Fri, 25 May 2018 23:07:47 -0600, Ian Kelly wrote:

> On Fri, May 25, 2018 at 11:00 PM, Chris Angelico <rosuav at gmail.com>
> wrote:
>> On Sat, May 26, 2018 at 2:46 PM, Steven D'Aprano
>> <steve+comp.lang.python at pearwood.info> wrote:
[...]
>>> Is there a better way of handling a three-state flag like this?
>>>
>>>
>> Does it need to have a value of 2? If not:
>>
>> # Tri-state logic
>> Maybe = object()
> 
> The enum has a nice __str__ though.

Yes, that's why I wanted to use enum.

Also because apparently Enums are the future and nobody uses object() any 
more :-)

Actually I don't really need all the features of Enums, I might just 
define my own class:


class Maybe:
     def __repr__(self):
         return "Maybe"

Maybe = Maybe()



I wish there was a simpler way to define symbols with identity but no 
state or behaviour...



-- 
Steve



From rosuav at gmail.com  Sat May 26 04:14:08 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 26 May 2018 18:14:08 +1000
Subject: Enums: making a single enum
In-Reply-To: <peb460$q4o$3@blaine.gmane.org>
References: <peaorp$q4o$1@blaine.gmane.org>
 <CAPTjJmqwU21ncFtxivGKm0v=S3gUM2VDLR5tUn4723WBdD-fng@mail.gmail.com>
 <CALwzid=PBsxkQ03SD0MM0tCPTWYV1hziF6m5J3AVNKChWdrcAw@mail.gmail.com>
 <peb460$q4o$3@blaine.gmane.org>
Message-ID: <CAPTjJmo4bHRNtcCpOFku56Dy62cmN1BAouy=W=TmYQ92V7N8MQ@mail.gmail.com>

On Sat, May 26, 2018 at 6:00 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> Actually I don't really need all the features of Enums, I might just
> define my own class:
>
>
> class Maybe:
>      def __repr__(self):
>          return "Maybe"
>
> Maybe = Maybe()
>
>
>
> I wish there was a simpler way to define symbols with identity but no
> state or behaviour...

You DO have behaviour though - the repr is a behaviour of that object.
So what you have there (reusing the name for the instance) seems
decent to me.

ChrisA


From steve+comp.lang.python at pearwood.info  Sat May 26 04:50:07 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sat, 26 May 2018 08:50:07 +0000 (UTC)
Subject: Enums: making a single enum
References: <peaorp$q4o$1@blaine.gmane.org>
 <CAPTjJmqwU21ncFtxivGKm0v=S3gUM2VDLR5tUn4723WBdD-fng@mail.gmail.com>
 <CALwzid=PBsxkQ03SD0MM0tCPTWYV1hziF6m5J3AVNKChWdrcAw@mail.gmail.com>
 <peb460$q4o$3@blaine.gmane.org>
 <CAPTjJmo4bHRNtcCpOFku56Dy62cmN1BAouy=W=TmYQ92V7N8MQ@mail.gmail.com>
Message-ID: <peb73u$q4o$4@blaine.gmane.org>

On Sat, 26 May 2018 18:14:08 +1000, Chris Angelico wrote:

> On Sat, May 26, 2018 at 6:00 PM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> Actually I don't really need all the features of Enums, I might just
>> define my own class:
>>
>>
>> class Maybe:
>>      def __repr__(self):
>>          return "Maybe"
>>
>> Maybe = Maybe()
>>
>>
>>
>> I wish there was a simpler way to define symbols with identity but no
>> state or behaviour...
> 
> You DO have behaviour though - the repr is a behaviour of that object.
> So what you have there (reusing the name for the instance) seems decent
> to me.

I *just knew* some clever Dick (or clever Chris in this case...) would 
point out that repr is behaviour. Technically you are correct (the best 
kind of correct...) but in a practical sense we don't really count having 
a repr as behaviour. All objects ought to have a repr: calling print(obj) 
or displaying the object in the REPL shouldn't raise an exception. Even 
None has a repr :-)

I want an easy way to make new objects like None and NotImplemented 
without having to explicitly define a class first. Some languages make 
that real easy (although the semantics might not be quite identical):

    Ruby                :Maybe
    Javascript          Symbol("Maybe")
    Julia               :Maybe or Symbol("Maybe")
    Scala               'Maybe
    Elixir              :Maybe
    Erland              maybe or 'Maybe'


Elixir and Erland call them atoms; Erland also requires them to begin 
with a lowercase letter, otherwise they must be surrounded by single 
quotes.


Hey-Chris-you-want-to-collaborate-on-a-PEP-for-this-ly y'rs,


-- 
Steve



From steve+comp.lang.python at pearwood.info  Sat May 26 05:17:22 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sat, 26 May 2018 09:17:22 +0000 (UTC)
Subject: Why cannot I use __slots__ and weakrefs together?
Message-ID: <peb8n2$q4o$5@blaine.gmane.org>

Here is my code:



---- cut here %< ----

import weakref
d = weakref.WeakValueDictionary()

class Spam:
    pass

class Eggs:
    __slots__ = ['spanish_inquisition']

d['a'] = Spam()  # Okay.
d['b'] = Eggs()  # Nobody will expect what happens next!

---- cut here %< ----


and the result I get is:


Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.5/weakref.py", line 158, in __setitem__
    self.data[key] = KeyedRef(value, self._remove, key)
  File "/usr/local/lib/python3.5/weakref.py", line 306, in __new__
    self = ref.__new__(type, ob, callback)
TypeError: cannot create weak reference to 'Eggs' object



Why does weakref hate my Eggs class?


-- 
Steve



From christian at python.org  Sat May 26 05:53:42 2018
From: christian at python.org (Christian Heimes)
Date: Sat, 26 May 2018 11:53:42 +0200
Subject: Why cannot I use __slots__ and weakrefs together?
In-Reply-To: <peb8n2$q4o$5@blaine.gmane.org>
References: <peb8n2$q4o$5@blaine.gmane.org>
Message-ID: <peban2$kca$1@blaine.gmane.org>

On 2018-05-26 11:17, Steven D'Aprano wrote:
> Here is my code:
> 
> 
> 
> ---- cut here %< ----
> 
> import weakref
> d = weakref.WeakValueDictionary()
> 
> class Spam:
>     pass
> 
> class Eggs:
>     __slots__ = ['spanish_inquisition']
> 
> d['a'] = Spam()  # Okay.
> d['b'] = Eggs()  # Nobody will expect what happens next!
> 
> ---- cut here %< ----
> 
> 
> and the result I get is:
> 
> 
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "/usr/local/lib/python3.5/weakref.py", line 158, in __setitem__
>     self.data[key] = KeyedRef(value, self._remove, key)
>   File "/usr/local/lib/python3.5/weakref.py", line 306, in __new__
>     self = ref.__new__(type, ob, callback)
> TypeError: cannot create weak reference to 'Eggs' object
> 
> 
> 
> Why does weakref hate my Eggs class?

Weakref needs some place to store reference information. It works if you
add "__weakref__" to your slots:

class Eggs:
     __slots__ = ['spanish_inquisition', '__weakref__']

Christian



From greg.ewing at canterbury.ac.nz  Sat May 26 06:04:42 2018
From: greg.ewing at canterbury.ac.nz (Gregory Ewing)
Date: Sat, 26 May 2018 22:04:42 +1200
Subject: Why cannot I use __slots__ and weakrefs together?
In-Reply-To: <mailman.183.1527326382.18022.python-list@python.org>
References: <peb8n2$q4o$5@blaine.gmane.org>
 <mailman.183.1527326382.18022.python-list@python.org>
Message-ID: <fmsppsFgag5U1@mid.individual.net>

Steven D'Aprano wrote:
> TypeError: cannot create weak reference to 'Eggs' object
> 
> Why does weakref hate my Eggs class?

Classes with __slots__ aren't automatically given a __weakref__ slot,
to save memory I suppose.

But you can give it one explicitly:

 >>> class Eggs:
...   __slots__ = ['spanish_inquisition', '__weakref__']
...
 >>> e = Eggs()
 >>> d['b'] = e
 >>>

-- 
Greg


From __peter__ at web.de  Sat May 26 06:30:07 2018
From: __peter__ at web.de (Peter Otten)
Date: Sat, 26 May 2018 12:30:07 +0200
Subject: Computations on pandas dataframes
References: <d0ec0173-7e3d-4d6f-9ea8-7d9a53e7e647@googlegroups.com>
Message-ID: <pebcrf$eoe$1@blaine.gmane.org>

junkaccount36 at outlook.com wrote:

> Hi,
> 
> Python newbie here. I need help with the following two tasks I need to
> accomplish using Python:
> 
> ------------------------
> 
> Creating a matrix of rolling variances
> 
> I have a pandas data frame of six columns, I would like to iteratively
> compute the variance along each column. Since I am a newbie, I don't
> really understand the niceties of the language and common usage patterns.
> What is the common Python idiom for achieving the following?

Knowledge of the language doesn't help much here; pandas and numpy are a 
world of its own. One rule I apply as an amateur: when you have to resort 
Python loops it gets slow ;)

> vars = []
> for i in range(1, 100000):
>     v = (data.iloc[range(0, i+1)].var()).values
>     if len(vars) == 0:
>         vars = v
>     else:
>         vars = np.vstack((vars, v))
> 
> Also, when I run this code, it takes a long time to execute. Can anyone
> suggest how to improve the running time?

I think I would forego pandas and use numpy

a = np.random.random((N, M))
vars = np.empty((N-1, M))
for i in range(1, N):
    vars[i-1] = a[:i+1].var(axis=0, ddof=1)

While it doesn't avoid the loop it may not need to copy as much data as your 
version.

> Pandas dataframe: sum of exponentially weighted correlation matrices per
> row
> 
> Consider the following dataframe:
> 
> df = pd.DataFrame(np.random.random((200,3)))
> df['date'] = pd.date_range('2000-1-1', periods=200, freq='D')
> df = df.set_index(['date'])
> 
> 
> date 0 1 2 3 4 5
> 2000-01-01 0.101782 0.111237 0.177719 0.229994 0.298786 0.747169
> 2000-01-02 0.348568 0.916997 0.527036 0.998144 0.544261 0.824907
> 2000-01-03 0.095015 0.480519 0.493345 0.632072 0.965326 0.244732
> 2000-01-04 0.502706 0.014287 0.045354 0.461621 0.359125 0.489150
> 2000-01-05 0.559364 0.337121 0.763715 0.460163 0.515309 0.732979
> 2000-01-06 0.488153 0.149655 0.015616 0.658693 0.864032 0.425497
> 2000-01-07 0.266161 0.392923 0.606358 0.286874 0.160191 0.573436
> 2000-01-08 0.786785 0.770826 0.202838 0.259263 0.732071 0.546918
> 2000-01-09 0.739847 0.886894 0.094900 0.257210 0.264688 0.005631
> 2000-01-10 0.615846 0.347249 0.516575 0.886096 0.347741 0.259998
> 
> Now, I want to treat each row as a vector and perform a multiplication
> like this:
> 
> [[0.101782]] [[0.101782 0.111237 0.177719 0.229994 0.298786 0.747169]]
> [[0.111237]]
> [[0.177719]]
> [[0.229994]]
> [[0.298786]]
> [[0.747169]]
> 
> For the i-th row, let's call this X_i. Now I have a parameter alpha and I
> want to multiply X_i with alpha^i and sum across all the i's. In the real
> world, I can have thousands of rows so I need to do this with reasonably
> good performance.

Again I'd use numpy directly. If I understand your second problem correctly

a = np.np.random.random((200, 3))
alpha = .5
b = alpha ** np.arange(200)
c = b * a ** 2
print(c.sum(axis=0))

If I got it wrong -- could you provide a complete (small!) example with the 
intermediate results?



From storchaka at gmail.com  Sat May 26 06:52:33 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sat, 26 May 2018 13:52:33 +0300
Subject: Enums: making a single enum
In-Reply-To: <CALwzid=PBsxkQ03SD0MM0tCPTWYV1hziF6m5J3AVNKChWdrcAw@mail.gmail.com>
References: <peaorp$q4o$1@blaine.gmane.org>
 <CAPTjJmqwU21ncFtxivGKm0v=S3gUM2VDLR5tUn4723WBdD-fng@mail.gmail.com>
 <CALwzid=PBsxkQ03SD0MM0tCPTWYV1hziF6m5J3AVNKChWdrcAw@mail.gmail.com>
Message-ID: <pebe5e$66m$1@blaine.gmane.org>

26.05.18 08:07, Ian Kelly ????:
> On Fri, May 25, 2018 at 11:00 PM, Chris Angelico <rosuav at gmail.com> wrote:
>> On Sat, May 26, 2018 at 2:46 PM, Steven D'Aprano
>> <steve+comp.lang.python at pearwood.info> wrote:
>>> Am I silly for wanting to make a single enum?
>>>
>>> I have a three-state flag, True, False or Maybe. Is is confusing or bad
>>> practice to make a single enum for the Maybe case?
>>>
>>>
>>> from enum import Enum
>>> class State(Enum):
>>>      Maybe = 2
>>>
>>> Maybe = State.Maybe
>>> del State
>>>
>>> Is there a better way of handling a three-state flag like this?
>>>
>>
>> Does it need to have a value of 2? If not:
>>
>> # Tri-state logic
>> Maybe = object()
> 
> The enum has a nice __str__ though.

Not very nice. It contains a reference to non-existing class State. The 
repr contains also the unrelevant here value of 2.

If you need just an identifiable singleton and don't bother about the 
exact representation, then a list can be enough:

Maybe = ['Maybe']



From marko at pacujo.net  Sat May 26 06:56:50 2018
From: marko at pacujo.net (Marko Rauhamaa)
Date: Sat, 26 May 2018 13:56:50 +0300
Subject: Enums: making a single enum
References: <peaorp$q4o$1@blaine.gmane.org>
 <CAPTjJmqwU21ncFtxivGKm0v=S3gUM2VDLR5tUn4723WBdD-fng@mail.gmail.com>
 <CALwzid=PBsxkQ03SD0MM0tCPTWYV1hziF6m5J3AVNKChWdrcAw@mail.gmail.com>
 <mailman.175.1527311314.18022.python-list@python.org>
Message-ID: <87bmd27ki5.fsf@elektro.pacujo.net>

Ian Kelly <ian.g.kelly at gmail.com>:
> On Fri, May 25, 2018 at 11:00 PM, Chris Angelico <rosuav at gmail.com> wrote:
>> # Tri-state logic
>> Maybe = object()
>
> The enum has a nice __str__ though.

I use strings for enums:

    class X:
       HERE = "HERE"
       THERE = "THERE"
       EVERYWHERE = "EVERYWHERE"

       def __init__(self):
           self.location = self.HERE

       def move_there(self):
           assert self.location is not self.EVERYWHERE
           self.location = self.THERE


1. Why self.THERE instead of X.THERE?

   X.THERE would work. It would even be preferable if the enums were
   used in a published API. However, in general I don't like to sprinkle
   the name of a class around its implementation.

2. Whe "is not" instead of "!="?

   The enums are defined as strings only as a matter of printing
   convenience. They are treated as arbitrary sentinel objects whose
   only functional property is their identity. Or course, such sentinel
   objects must not be used in contexts where ordinary strings would be
   possible values.


Marko


From subhabangalore at gmail.com  Sat May 26 07:02:48 2018
From: subhabangalore at gmail.com (subhabangalore at gmail.com)
Date: Sat, 26 May 2018 04:02:48 -0700 (PDT)
Subject: Some Issues on Tagging Text
In-Reply-To: <mailman.165.1527287059.18022.python-list@python.org>
References: <a945cff0-2ea4-4f76-8e74-423e70b15b94@googlegroups.com>
 <20180525222406.GA18660@cskk.homeip.net>
 <mailman.165.1527287059.18022.python-list@python.org>
Message-ID: <6eb1fdbb-7520-4c82-901d-675f8fd50c81@googlegroups.com>

On Saturday, May 26, 2018 at 3:54:37 AM UTC+5:30, Cameron Simpson wrote:
> On 25May2018 04:23, Subhabrata Banerjee  wrote:
> >On Friday, May 25, 2018 at 3:59:57 AM UTC+5:30, Cameron Simpson wrote:
> >> On 24May2018 03:13, wrote:
> >> >I have a text as,
> >> >
> >> >"Hawaii volcano generates toxic gas plume called laze PAHOA: The eruption of Kilauea volcano in Hawaii sparked new safety warnings about toxic gas on the Big Island's southern coastline after lava began flowing into the ocean and setting off a chemical reaction. Lava haze is made of dense white clouds of steam, toxic gas and tiny shards of volcanic glass. Janet Babb, a geologist with the Hawaiian Volcano Observatory, says the plume "looks innocuous, but it's not." "Just like if you drop a glass on your kitchen floor, there's some large pieces and there are some very, very tiny pieces," Babb said. "These little tiny pieces are the ones that can get wafted up in that steam plume." Scientists call the glass Limu O Pele, or Pele's seaweed, named after the Hawaiian goddess of volcano and fire"
> >> >
> >> >and I want to see its tagged output as,
> >> >
> >> >"Hawaii/TAG volcano generates toxic gas plume called laze PAHOA/TAG: The eruption of Kilauea/TAG volcano/TAG in Hawaii/TAG sparked new safety warnings about toxic gas on the Big Island's southern coastline after lava began flowing into the ocean and setting off a chemical reaction. Lava haze is made of dense white clouds of steam, toxic gas and tiny shards of volcanic glass. Janet/TAG Babb/TAG, a geologist with the Hawaiian/TAG Volcano/TAG Observatory/TAG, says the plume "looks innocuous, but it's not." "Just like if you drop a glass on your kitchen floor, there's some large pieces and there are some very, very tiny pieces," Babb/TAG said. "These little tiny pieces are the ones that can get wafted up in that steam plume." Scientists call the glass Limu/TAG O/TAG Pele/TAG, or Pele's seaweed, named after the Hawaiian goddess of volcano and fire"
> >> >
> >> >To do this I generally try to take a list at the back end as,
> >> >
> >> >Hawaii
> >> >PAHOA
> [...]
> >> >and do a simple code as follows,
> >> >
> >> >def tag_text():
> >> >    corpus=open("/python27/volcanotxt.txt","r").read().split()
> >> >    wordlist=open("/python27/taglist.txt","r").read().split()
> [...]
> >> >    list1=[]
> >> >    for word in corpus:
> >> >        if word in wordlist:
> >> >            word_new=word+"/TAG"
> >> >            list1.append(word_new)
> >> >        else:
> >> >            list1.append(word)
> >> >    lst1=list1
> >> >    tagged_text=" ".join(lst1)
> >> >    print tagged_text
> >> >
> >> >get the results and hand repair unwanted tags Hawaiian/TAG goddess of volcano/TAG.
> >> >I am looking for a better approach of coding so that I need not spend time on
> >> >hand repairing.
> >>
> >> It isn't entirely clear to me why these two taggings are unwanted. Intuitively,
> >> they seem to be either because "Hawaiian goddess" is a compound term where you
> >> don't want "Hawaiian" to get a tag, or because "Hawaiian" has already received
> >> a tag earlier in the list. Or are there other criteria.
> >>
> >> If you want to solve this problem with a programme you must first clearly
> >> define what makes an unwanted tag "unwanted". [...]
> >
> >By unwanted I did not mean anything so intricate.
> >Unwanted meant things I did not want.
> 
> That much was clear, but you need to specify in your own mind _precisely_ what 
> makes some things unwanted and others wanted. Without concrete criteria you 
> can't write code to implement those criteria.
> 
> I'm not saying "you need to imagine code to match these things": you're clearly 
> capable of doing that. I'm saying you need to have well defined concepts of 
> what makes something unwanted (or, if that is easier to define, wanted).  You 
> can do that iteratively: start with your basic concept and see how well it 
> works. When those concepts don't give you the outcome you desire, consider a 
> specific example which isn't working and try to figure out what additional 
> criterion would let you distinguish it from a working example.
> 
> >For example,
> >if my target phrases included terms like,
> >government of Mexico,
> >
> >now in my list I would have words with their tags as,
> >government
> >of
> >Mexico
> >
> >If I put these words in list it would tag
> >government/TAG of/TAG Mexico
> >
> >but would also tag all the "of" which may be
> >anywhere like haze is made of/TAG dense white,
> >clouds of/TAG steam, etc.
> >
> >Cleaning these unwanted places become a daunting task
> >to me.
> 
> Richard Damon has pointed out that you seem to want phrases instead of just 
> words.
> 
> >I have been experimenting around
> >wordlist=["Kilauea volcano","Kilauea/TAG volcano/TAG"),("Hawaii","Hawaii/TAG"),...]
> >tag=reduce(lambda a, kv: a.replace(*kv), wordlist, corpus)
> >
> >is giving me sizeably good result but size of the wordlist is slight concern.
> 
> You can reduce that list by generating the "wordlist" form from something 
> smaller:
> 
>   base_phrases = ["Kilauea volcano", "government of Mexico", "Hawaii"]
>   wordlist = [
>       (base_phrase, " ".join([word + "/TAG" for word in base_phrase.split()]))
>       for base_phrase in base_phrases
>   ]
> 
> You could even autosplit the longer phrases so that your base_phrases 
> _automatically_ becomes:
> 
>   base_phrases = ["Kilauea volcano", "Kilauea", "volcano", "government of 
>   Mexico", "government", "Mexico", "Hawaii"]
> 
> That way your "replace" call would find the longer phrases before the shorter 
> phrases and thus _not_ tag the single words if they occurred in a longer 
> phrase, while still tagging the single words when they _didn't_ land in a 
> longer phrase.
> 
> Also, it is unclear to me whether "/TAG" is a fixed string or intended to be 
> distinct such as "/PROPER_NOUN", "/LOCATION" etc. If they vary then you need a 
> more elaborate setup.
> 
> It sounds like you want a more general purpose parser, and that depends upon 
> your purposes. If you're coding to learn the basics of breaking up text, what 
> you're doing is fine and I'd stick with it. But if you're just after the 
> outcome (tags), you could use other libraries to break up the text.
> 
> For example, the Natural Language ToolKit (NLTK) will do structured parsing of 
> text and return you a syntax tree, and it has many other facilities. Doco:
> 
>   http://www.nltk.org/
> 
> PyPI module:
> 
>   https://pypi.org/project/nltk/
> 
> which you can install with the command:
> 
>   pip install --user nltk
> 
> That would get you a tree structure of the corpus, which you could process more 
> meaningfully. For example, you could traverse the tree and tag higher level 
> nodes as you came across them, possibly then _not_ traversing their inner 
> nodes. The effect of that would be that if you hit the grammatic node:
> 
>   government of Mexico
> 
> you might tags that node with "ORGANISATION", and choose not to descend inside 
> it, thus avoiding tagging "government" and "of" and so forth because you have a 
> high level tags. Nodes not specially recognised you're keep descending into, 
> tagging smaller things.
> 
> Cheers,
> Cameron Simpson 

Dear Sir, 

Thank you for your kind and valuable suggestions. Thank you for your kind time too. 
I know NLTK and machine learning. I am of belief if I may use language properly we need machine learning-the least. 
So, I am trying to design a tagger without the help of machine learning, by simple Python coding. I have thus removed standard Parts of Speech(PoS) or Named Entity (NE) tagging scheme. 
I am trying to design a basic model if required may be implemented on any one of these problems. 
Detecting longer phrase is slightly a problem now I am thinking to employ re.search(pattern,text). If this part is done I do not need machine learning. Maintaining so much data is a cumbersome issue in machine learning. 

My regards to all other esteemed coders and members of the group for their kind and valuable time and valuable suggestions. 




From __peter__ at web.de  Sat May 26 08:24:39 2018
From: __peter__ at web.de (Peter Otten)
Date: Sat, 26 May 2018 14:24:39 +0200
Subject: Enums: making a single enum
References: <peaorp$q4o$1@blaine.gmane.org>
Message-ID: <pebji7$kmb$1@blaine.gmane.org>

Steven D'Aprano wrote:

> Am I silly for wanting to make a single enum?
> 
> I have a three-state flag, True, False or Maybe. Is is confusing or bad
> practice to make a single enum for the Maybe case?
> 
> 
> from enum import Enum
> class State(Enum):
>     Maybe = 2
> 
> Maybe = State.Maybe
> del State

> Is there a better way of handling a three-state flag like this?

I think all three states should be created equal. Would a full-blown

>>> class State(enum.IntEnum):
...     false = False
...     true = True
...     maybe = 2
... 
>>> State.maybe
<State.maybe: 2>
>>> bool(State.false)
False
>>> State.true == True
True
>>> list(State)
[<State.false: 0>, <State.true: 1>, <State.maybe: 2>]
>>> State(True)
<State.true: 1>

complicate your actual code?



From grant.b.edwards at gmail.com  Sat May 26 09:30:24 2018
From: grant.b.edwards at gmail.com (Grant Edwards)
Date: Sat, 26 May 2018 13:30:24 +0000 (UTC)
Subject: why do I get syntax error on if <code>: break
References: <eed6cc31-1f63-4cb3-8623-b2963abadad7@googlegroups.com>
Message-ID: <pebnhg$rdf$1@blaine.gmane.org>

On 2018-05-25, asa32sd23 at gmail.com <asa32sd23 at gmail.com> wrote:

> here is the code, i keep getting an error, "break outside loop".

You get the "break outside loop" error because you're using the break
statement when you are not inside a loop.

> if it is false just exit function

You use the 'return' statement to exit a function.

> def d(idx):
>     if type(idx) != int:
>         break
>
> d('k')




From rosuav at gmail.com  Sat May 26 09:54:51 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 26 May 2018 23:54:51 +1000
Subject: Enums: making a single enum
In-Reply-To: <peb73u$q4o$4@blaine.gmane.org>
References: <peaorp$q4o$1@blaine.gmane.org>
 <CAPTjJmqwU21ncFtxivGKm0v=S3gUM2VDLR5tUn4723WBdD-fng@mail.gmail.com>
 <CALwzid=PBsxkQ03SD0MM0tCPTWYV1hziF6m5J3AVNKChWdrcAw@mail.gmail.com>
 <peb460$q4o$3@blaine.gmane.org>
 <CAPTjJmo4bHRNtcCpOFku56Dy62cmN1BAouy=W=TmYQ92V7N8MQ@mail.gmail.com>
 <peb73u$q4o$4@blaine.gmane.org>
Message-ID: <CAPTjJmrxbBU2d-mjZYeM0eK0gnW3JVORpxddLjqfE3+raZnNuw@mail.gmail.com>

On Sat, May 26, 2018 at 6:50 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Sat, 26 May 2018 18:14:08 +1000, Chris Angelico wrote:
>
>> On Sat, May 26, 2018 at 6:00 PM, Steven D'Aprano
>> <steve+comp.lang.python at pearwood.info> wrote:
>>> Actually I don't really need all the features of Enums, I might just
>>> define my own class:
>>>
>>>
>>> class Maybe:
>>>      def __repr__(self):
>>>          return "Maybe"
>>>
>>> Maybe = Maybe()
>>>
>>>
>>>
>>> I wish there was a simpler way to define symbols with identity but no
>>> state or behaviour...
>>
>> You DO have behaviour though - the repr is a behaviour of that object.
>> So what you have there (reusing the name for the instance) seems decent
>> to me.
>
> I *just knew* some clever Dick (or clever Chris in this case...) would
> point out that repr is behaviour. Technically you are correct (the best
> kind of correct...) but in a practical sense we don't really count having
> a repr as behaviour. All objects ought to have a repr: calling print(obj)
> or displaying the object in the REPL shouldn't raise an exception. Even
> None has a repr :-)

Sure, but the default repr is one behaviour, and a customized repr is
different behaviour. You do get a repr even without creating a class,
but you don't want that one, you want something more custom.

> I want an easy way to make new objects like None and NotImplemented
> without having to explicitly define a class first. Some languages make
> that real easy (although the semantics might not be quite identical):
>
>     Ruby                :Maybe
>     Javascript          Symbol("Maybe")
>     Julia               :Maybe or Symbol("Maybe")
>     Scala               'Maybe
>     Elixir              :Maybe
>     Erland              maybe or 'Maybe'
>
>
> Elixir and Erland call them atoms; Erland also requires them to begin
> with a lowercase letter, otherwise they must be surrounded by single
> quotes.
>
>
> Hey-Chris-you-want-to-collaborate-on-a-PEP-for-this-ly y'rs,

Sure. Basically it'd be a builtin that, whenever instantiated, returns
a new object (guaranteed to be unique) identified by the given string.
Pretty simple and straight-forward. In fact, I wouldn't even start a
PEP yet. Toss it out onto -ideas and see who's interested!

class Symbol: # or Atom:
    __slots__ = ("label",)
    def __init__(self, label):
        self.label = label
    def __repr__(self):
        return f"Symbol({self.label!r})"

Seems pretty non-controversial, which means it's almost guaranteed to
reach 100+ posts debating what the name should be.

ChrisA


From __peter__ at web.de  Sat May 26 09:57:05 2018
From: __peter__ at web.de (Peter Otten)
Date: Sat, 26 May 2018 15:57:05 +0200
Subject: List replication operator
References: <pe6vjf$g1l$1@blaine.gmane.org> <pe8dpv$9as$1@blaine.gmane.org>
 <pe8tgi$h8n$1@blaine.gmane.org>
Message-ID: <pebovm$808$1@blaine.gmane.org>

Steven D'Aprano wrote:

> On Fri, 25 May 2018 09:28:01 +0200, Peter Otten wrote:
> 
>> Yet another arcanum to learn for beginners with little return. If you
>> cannot refrain from tinkering with the language at least concentrate on
>> the features with broad application. Thank you.
> 
> Broader than multi-dimensional arrays? There are a bazillion uses for
> them. How many do you need before it is "broad application"?
> 
> https://www.google.com/search?q=multidimensional+arrays

Sorry, I don't see how your suggestion helps with multidimensional arrays 
which aren't even part of Python's stdlib.

In practice newbies will be told to replace

bins = [[]] * N

with 

bins = [[]] ** N

just as they are now told to replace it with

bins = [[] for dummy in range(N)]

Someone showing up with

[[[[0]*10]*10]*10]*10

should certainly be informed about numpy.

> https://www.google.com/search?q=what+are+some+uses+for+multidimensional
> +arrays
> 
> "My programming language doesn't support arithmetic, because I only
> provide features with broad application. Arithmetic is only useful for
> manipulating numbers."
> 
> 
> Beginners already learn list * operator, and get *extremely emotional*

I don't think there is a significant correlation between getting emotional 
and being right*.

> when it doesn't copy lists like they expect:
> 
> https://bugs.python.org/issue33636
> 
> This is a frequent, recurring pain point. Experienced programmers forget
> how confusing the behaviour of * is because they're so used to the
> execution model. They forget that writing a list comp is not even close
> to obvious, not only for beginners but even some experienced Python
> programmers.

It may be unexpected, just as

animal = Animal()

dog = animal
dog.noise = "woof"

cat = animal
cat.noise = "miaou"

or

def augmented(item, items=[]):
    items.append(item)
    return items

a = augmented(10)
b = augmented(20)
assert a == [10]
assert b == [20]

is if your mental model operates with values rather than references.


(*) Perhaps we should try to repeat the success of

from __future__ import braces

with

from __future__ import value_semantics




From email at paulstgeorge.com  Sat May 26 11:17:42 2018
From: email at paulstgeorge.com (Paul St George)
Date: Sat, 26 May 2018 17:17:42 +0200
Subject: The PIL show() method looks for the default viewer. How do I
 change this to a different viewer (of my choice)?
In-Reply-To: <CANDiX9+fF3ADqhee50RA47hecQRpsOVJjXML9=OAYzkAp9gNqw@mail.gmail.com>
References: <ddedae8b-f085-dfa3-08a4-2c821975cc61@paulstgeorge.com>
 <CANDiX9+fF3ADqhee50RA47hecQRpsOVJjXML9=OAYzkAp9gNqw@mail.gmail.com>
Message-ID: <0efaafaa-064f-726a-416f-9dc9d0756667@paulstgeorge.com>

Thank you.
You are very right. The show() method is intended for debugging purposes 
and is useful for that, but what method should I be using and is PIL the 
best imaging library for my purposes? I do not want to manipulate 
images, I only want to show images (full screen) on an external display. 
I want to use Python to control the timing of the images.

And, out of curiosity, as I will probably use a different method - how 
do I find out what commands can be used as parameters for show()? I read 
the docs at 
<https://pillow.readthedocs.io/en/5.1.x/reference/Image.html#PIL.Image.Image.show>, 
but I am none the wiser.


On 26/05/2018 01:02, boB Stepp wrote:
> On Fri, May 25, 2018 at 6:04 AM, Paul St George <email at paulstgeorge.com> wrote:
>> I am using the Python Imaging Library (PIL), Python 2 and Raspberry Pi 3 B+
>>
>> My code is simply:
>>
>>      from PIL import Image
>>
>>      im = Image.open(?somepic.jpg?)
>>      im.show() # display image
>>
>>
>> But the show() method looks for the default viewer (probably xv). How do I
>> change this (in the code, or in some settings) to a different viewer (of my
>> choice)?
> In the PIL docs for show() at
> https://pillow.readthedocs.io/en/5.1.x/reference/Image.html#PIL.Image.Image.show
> it says:
>
> <quote>
> Image.show(title=None, command=None)
>
> Displays this image. This method is mainly intended for debugging purposes.
>
> On Unix platforms, this method saves the image to a temporary PPM
> file, and calls either the xv utility or the display utility,
> depending on which one can be found.
>
> On macOS, this method saves the image to a temporary BMP file, and
> opens it with the native Preview application.
>
> On Windows, it saves the image to a temporary BMP file, and uses the
> standard BMP display utility to show it (usually Paint).
>
> Parameters:
>
> title ? Optional title to use for the image window, where possible.
> command ? command used to show the image
> </quote>
>
> I have not had occasion to use PIL, but perhaps this command parameter
> can be used to do what you want?  If not then perhaps you can write
> your own function to load your image into your favorite image viewer.
>
>



From mikhailwas at gmail.com  Sat May 26 11:22:15 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Sat, 26 May 2018 18:22:15 +0300
Subject: Raw string statement (proposal)
In-Reply-To: <peb3uc$q4o$2@blaine.gmane.org>
References: <CAE6NSRBzDZrV8P+iJQxuENNAtmAAwSaNEbMnKMb_dgGw7yEH3Q@mail.gmail.com>
 <mailman.127.1527222875.18022.python-list@python.org>
 <lnRNC.222267$Vs7.138416@fx41.am4>
 <CAE6NSRBrCSNwXJ8friR96BGu=_sxgEESphzYzaHSUoMv57a0TA@mail.gmail.com>
 <peb3uc$q4o$2@blaine.gmane.org>
Message-ID: <CAE6NSRAa-aOcRzfKEqCmyfnqv05MJ-snZQU+ZrbctFLJj-pGxA@mail.gmail.com>

On Sat, May 26, 2018 at 10:55 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Sat, 26 May 2018 08:09:51 +0300, Mikhail V wrote:
>
>> On Fri, May 25, 2018 at 1:15 PM, bartc <bc at freeuk.com> wrote:
> [...]
>>> One problem here is how to deal with embedded non-printable characters:
>>> CR, LF and TAB might become part of the normal source text, but how
>>> about anything else? Or would you only allow text that might appear in
>>> a text file where those characters would also cause issues?
>>
>> This syntax does not imply anything about text. From the editor's POV
>> it's just the same as it is now - you can insert anything in a .py file.
>> So it does not add new cases to current state of affairs in this regard.
>> But maybe I'm not completely understand your question.
>
> Here is a string assigned to name `s` using Python's current syntax:
>
> s = "some\ncharacters\0abc\x01\ndef\uFF0A\nhere"
>
> How do you represent that assignment using your syntax?

Hope its not mandatory to decipher your random example.
If for example I'd want to work with a lot of non-presentable
characters, I'd use a more human-oriented notation than this ^.
And that is exactly where raw strings are needed.

So I'd make a readable notation where I can present a character
by its ordinal enclosed in some tag for example {10}. Then just
write a function which collapses those depending on further needs:

data >>| abc{10}def
data = f(data)

And the notation itself can be chosen depending on my needs.
Hope you get the point.

>
>
> And another example:
>
> s = """this is some text
> x = 'a'
> y = 'b'"""
> t = 'c'
>
> How do we write that piece of code using your syntax?

That's too easy - maybe you can try it yourself?
I am not trying to imply anything, but I don't see how
this example can cause problems - just put the TQS in a block.


>>> Would it then be possible to create a source file PROG2.PY which
>>> contains PROG1.PY as a raw string? That is, without changing the text
>>> from PROG1.PY at all.
>>
>> Should be fine, with only difference that you must indent the PROG1.PY
>> if it will be placed inside an indented suite.
>
> Bart said WITHOUT CHANGING THE TEXT. Indenting it is changing the text.

I know. So you've decided to share that you also understood this?
Good, I'm glad that you understand :-)


From steve+comp.lang.python at pearwood.info  Sat May 26 11:40:19 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sat, 26 May 2018 15:40:19 +0000 (UTC)
Subject: Enums: making a single enum
References: <peaorp$q4o$1@blaine.gmane.org>
 <CAPTjJmqwU21ncFtxivGKm0v=S3gUM2VDLR5tUn4723WBdD-fng@mail.gmail.com>
 <CALwzid=PBsxkQ03SD0MM0tCPTWYV1hziF6m5J3AVNKChWdrcAw@mail.gmail.com>
 <peb460$q4o$3@blaine.gmane.org>
 <CAPTjJmo4bHRNtcCpOFku56Dy62cmN1BAouy=W=TmYQ92V7N8MQ@mail.gmail.com>
 <peb73u$q4o$4@blaine.gmane.org>
 <CAPTjJmrxbBU2d-mjZYeM0eK0gnW3JVORpxddLjqfE3+raZnNuw@mail.gmail.com>
Message-ID: <pebv52$q4o$6@blaine.gmane.org>

On Sat, 26 May 2018 23:54:51 +1000, Chris Angelico wrote:

> Seems pretty non-controversial, which means it's almost guaranteed to
> reach 100+ posts debating what the name should be.

Including:

* 27 posts declaring that using such singleton symbols is completely
  un-Pythonic and is sure to doom Python to irrelevancy;

* 13 posts stating that whether it is spelled "Symbol(name)" or 
  "Atom(name)" it will be completely confusing;

* 4 posts proposing spelling it "~~name!" instead;

* 25 posts agreeing that the functionality is important, but
  should only be allowed inside functions whose name starts 
  with a vowel;

* 11 posts insisting it should only be functions starting
  with a consonant;

* 3 posts saying it shouldn't be allowed in functions at all,
  only in module-level try...except statements, and only so
  long as there are no list comprehensions used in the module;

* 18 posts demanding a complete list of every use-case for the
  feature and why using object()/strings/enums/ints isn't
  sufficient;

* 7 posts stating that the author would personally use it if it
  were a built-in, and they wouldn't bother installing a third-
  party package from PyPI for it, but nevertheless it should be
  put on PyPI first to see if there is any community interest;

* 12 posts cherry-picking programming languages invented between
  August 2003 and May 2015 by people whose name starts with "B",
  proving categorically that the modern trend is to avoid this
  feature;

* and 17 posts discussing the history of Forth and Intercal.


Good thing I didn't propose a short-hand syntax for it as well :-)




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson



From steve+comp.lang.python at pearwood.info  Sat May 26 12:10:52 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sat, 26 May 2018 16:10:52 +0000 (UTC)
Subject: Raw string statement (proposal)
References: <CAE6NSRBzDZrV8P+iJQxuENNAtmAAwSaNEbMnKMb_dgGw7yEH3Q@mail.gmail.com>
 <mailman.127.1527222875.18022.python-list@python.org>
 <lnRNC.222267$Vs7.138416@fx41.am4>
 <CAE6NSRBrCSNwXJ8friR96BGu=_sxgEESphzYzaHSUoMv57a0TA@mail.gmail.com>
 <peb3uc$q4o$2@blaine.gmane.org>
 <CAE6NSRAa-aOcRzfKEqCmyfnqv05MJ-snZQU+ZrbctFLJj-pGxA@mail.gmail.com>
Message-ID: <pec0ub$q4o$7@blaine.gmane.org>

On Sat, 26 May 2018 18:22:15 +0300, Mikhail V wrote:

>> Here is a string assigned to name `s` using Python's current syntax:
>>
>> s = "some\ncharacters\0abc\x01\ndef\uFF0A\nhere"
>>
>> How do you represent that assignment using your syntax?
> 
> Hope its not mandatory to decipher your random example. If for example
> I'd want to work with a lot of non-presentable characters, I'd use a
> more human-oriented notation than this ^. And that is exactly where raw
> strings are needed.
> 
> So I'd make a readable notation where I can present a character by its
> ordinal enclosed in some tag for example {10}. Then just write a
> function which collapses those depending on further needs:
> 
> data >>| abc{10}def
> data = f(data)
> 
> And the notation itself can be chosen depending on my needs. Hope you
> get the point.

Loud and clear: your syntax has no way of representing the string s.

Okay, let's take a simpler example. You want to use {65290} to represent 
the Unicode code point \uFF0A. Fair enough. Everyone else in the world 
uses hexadecimal for this purpose, but whatever.

But isn't {65290} just another way of spelling an escape code? Isn't your 
syntax supposed to eliminate the need for escape codes?

So if I had:

    result = function("Mikhail's syntax for \uFF0A is {65290}")

your syntax would become:

    temp = >>| Mikhail's syntax for {65290} is {65290}
    result = function(f(temp))

where f is your (as yet non-existent?) function for collapsing the {} 
codes to characters.

Can you see the problem yet? How does your collapse function f() 
distinguish between the escape code {65290} and the literal string 
{65290}?

And we've gone from a single string literal, which is an expression that 
can be used anywhere, to a statement that cannot be used in expressions.



>> And another example:
>>
>> s = """this is some text
>> x = 'a'
>> y = 'b'"""
>> t = 'c'
>>
>> How do we write that piece of code using your syntax?
> 
> That's too easy - maybe you can try it yourself? I am not trying to
> imply anything, but I don't see how this example can cause problems -
> just put the TQS in a block.

I don't know what TQS is supposed to mean.

I'll give it a try, and see if I understand your syntax. The idea is to 
avoid needing to put BEGIN END delimiters such as quotation marks around 
the string, right?


s = >>>
this is some text
x = 'a'
y = 'b'
t = 'c'


Am I close?

How is the interpreter supposed to know that the final line is not part 
of the string, but a line of actual Python code?

[...]
>> Bart said WITHOUT CHANGING THE TEXT. Indenting it is changing the text.
> 
> I know. So you've decided to share that you also understood this? Good,
> I'm glad that you understand :-)

I believe that the whole point of your proposal to avoid needing to 
change the text in any way when you paste it into your source code. If 
that's not the point, then what is the point?


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson



From __peter__ at web.de  Sat May 26 13:11:12 2018
From: __peter__ at web.de (Peter Otten)
Date: Sat, 26 May 2018 19:11:12 +0200
Subject: The PIL show() method looks for the default viewer. How do I
 change this to a different viewer (of my choice)?
References: <ddedae8b-f085-dfa3-08a4-2c821975cc61@paulstgeorge.com>
 <CANDiX9+fF3ADqhee50RA47hecQRpsOVJjXML9=OAYzkAp9gNqw@mail.gmail.com>
 <0efaafaa-064f-726a-416f-9dc9d0756667@paulstgeorge.com>
Message-ID: <pec4bf$3a7$1@blaine.gmane.org>

Paul St George wrote:

> Thank you.
> You are very right. The show() method is intended for debugging purposes
> and is useful for that, but what method should I be using and is PIL the
> best imaging library for my purposes? I do not want to manipulate
> images, I only want to show images (full screen) on an external display.
> I want to use Python to control the timing of the images.
> 
> And, out of curiosity, as I will probably use a different method - how
> do I find out what commands can be used as parameters for show()? I read
> the docs at
> <https://pillow.readthedocs.io/en/5.1.x/reference/Image.html
> #PIL.Image.Image.show>,
> but I am none the wiser.

If you look into the source code

https://github.com/python-pillow/Pillow/blob/master/src/PIL/Image.py#L1967

after a few indirections

show --> _show --> _showxv --> ImageShow.show

you will end up in the file

https://github.com/python-pillow/Pillow/blob/master/src/PIL/ImageShow.py

which is short enough to read completely ;)

At first glance it looks like the command argument is silently discarded, so 
here's plan B:

It turns out that you can register() Viewer instances, and the pre-
registered viewers for unixoids -- and thus probably the Pi are 
DisplayViewer and XVViewer.

Using these as a template I came up with the following simple viewer that 
shows an image with firefox:

#!/usr/bin/env python3
import os
import sys

from PIL import Image, ImageShow


class Firefox(ImageShow.UnixViewer):

    # store the image in a format understood by the browser
    format = "jpeg"

    def get_command_ex(self, file, **options):
        return ("firefox",) * 2

    def show_file(self, file, **options):
        quote = ImageShow.quote

        command, executable = self.get_command_ex(file, **options)

        # firefox returns immediately, so let's sleep a few seconds
        # to give it time to actually open the image file
        command = "(%s %s; sleep 10; rm -f %s)&" % (
            command, quote("file://" + file), quote(file)
        )
        os.system(command)
        return 1


# the -1 means our viewer will be inserted before the others
# and thus become the default
ImageShow.register(Firefox(), -1)


if __name__ == "__main__":
    try:
        file = sys.argv[1]
    except IndexError:
        print("Please provide an image file", file=sys.stderr)
    else:
        image = Image.open(file)
        image.show()


Here's another, even simpler one:

class Gwenview(ImageShow.UnixViewer):
    def get_command_ex(self, file, **options):
        return ("gwenview",) * 2




From ethan at stoneleaf.us  Sat May 26 13:38:11 2018
From: ethan at stoneleaf.us (Ethan Furman)
Date: Sat, 26 May 2018 10:38:11 -0700
Subject: Enums: making a single enum
In-Reply-To: <peb460$q4o$3@blaine.gmane.org>
References: <peaorp$q4o$1@blaine.gmane.org>
 <CAPTjJmqwU21ncFtxivGKm0v=S3gUM2VDLR5tUn4723WBdD-fng@mail.gmail.com>
 <CALwzid=PBsxkQ03SD0MM0tCPTWYV1hziF6m5J3AVNKChWdrcAw@mail.gmail.com>
 <peb460$q4o$3@blaine.gmane.org>
Message-ID: <5B099B83.4080507@stoneleaf.us>

On 05/26/2018 01:00 AM, Steven D'Aprano wrote:

> I wish there was a simpler way to define symbols with identity but no
> state or behaviour...

Check out the Constant class in aenum.  You still might want to customize the repr, though.

--
~Ethan~



From mikhailwas at gmail.com  Sat May 26 15:13:27 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Sat, 26 May 2018 22:13:27 +0300
Subject: Raw string statement (proposal)
In-Reply-To: <pec0ub$q4o$7@blaine.gmane.org>
References: <CAE6NSRBzDZrV8P+iJQxuENNAtmAAwSaNEbMnKMb_dgGw7yEH3Q@mail.gmail.com>
 <mailman.127.1527222875.18022.python-list@python.org>
 <lnRNC.222267$Vs7.138416@fx41.am4>
 <CAE6NSRBrCSNwXJ8friR96BGu=_sxgEESphzYzaHSUoMv57a0TA@mail.gmail.com>
 <peb3uc$q4o$2@blaine.gmane.org>
 <CAE6NSRAa-aOcRzfKEqCmyfnqv05MJ-snZQU+ZrbctFLJj-pGxA@mail.gmail.com>
 <pec0ub$q4o$7@blaine.gmane.org>
Message-ID: <CAE6NSRBpChzWhrvQEWxDhD-+Ot58Rb9uOfG9knvJu4iTt=nKtg@mail.gmail.com>

On Sat, May 26, 2018 at 7:10 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Sat, 26 May 2018 18:22:15 +0300, Mikhail V wrote:
>
>>> Here is a string assigned to name `s` using Python's current syntax:
>>>
>>> s = "some\ncharacters\0abc\x01\ndef\uFF0A\nhere"
>>>
>>> How do you represent that assignment using your syntax?
>>
>> Hope its not mandatory to decipher your random example. If for example
>> I'd want to work with a lot of non-presentable characters, I'd use a
>> more human-oriented notation than this ^. And that is exactly where raw
>> strings are needed.
>>
>> So I'd make a readable notation where I can present a character by its
>> ordinal enclosed in some tag for example {10}. Then just write a
>> function which collapses those depending on further needs:
>>
>> data >>| abc{10}def
>> data = f(data)
>>
>> And the notation itself can be chosen depending on my needs. Hope you
>> get the point.
>
> Loud and clear: your syntax has no way of representing the string s.

Just 5 lines before it is - you did not notice.


>     temp = >>| Mikhail's syntax for {65290} is {65290}
> Can you see the problem yet? How does your collapse function f()
> distinguish between the escape code {65290} and the literal string
> {65290}?

Look, there is no any problem here. You can choose
whatever YOU want to write "{" and "}". e.g. I'd pick {<} {>}.

    temp = >>| Mikhail's syntax for {65290} is {<}65290{>}


I just show you that syntax allows you not only input TEXT
without any manipulations, but also it allows to solve any task related
to custom presentation - in this case you want work with
ordinals for example. And you may end up with a scheme which
reads way better than your cryptic example.

This motivation is covered in documentation, but maybe
not good enough? anyway you're welcome to make suggestion for
the documentation.

I'll also ask you a question  -
Which such non-text codes you may need to
generate C code? Python code? HTML code?


>
> And we've gone from a single string literal, which is an expression that
> can be used anywhere, to a statement that cannot be used in expressions.

Ok show me your suggestion for a raw string definition for expressions
(no modifications to source text and no usage of invisible control chars).

> I don't know what TQS is supposed to mean.
Triple Quoted String



> s = >>>
> this is some text
> x = 'a'
> y = 'b'
> t = 'c'
>
>
> Am I close?

Yes very close, just shift it with a char of your choice, e.g. 1 space:
s >>> !" "
 this is some text
 x = 'a'
 y = 'b'
t = 'c'

or use a tag of your choice (no shifting needed in this case):

s >>> ?"#your favorite closing tag"
this is some text
x = 'a'
y = 'b'
#your favorite closing tag
t = 'c'

There can be other suggestions for symbols, etc.


From rosuav at gmail.com  Sat May 26 15:21:38 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sun, 27 May 2018 05:21:38 +1000
Subject: Raw string statement (proposal)
In-Reply-To: <CAE6NSRBpChzWhrvQEWxDhD-+Ot58Rb9uOfG9knvJu4iTt=nKtg@mail.gmail.com>
References: <CAE6NSRBzDZrV8P+iJQxuENNAtmAAwSaNEbMnKMb_dgGw7yEH3Q@mail.gmail.com>
 <mailman.127.1527222875.18022.python-list@python.org>
 <lnRNC.222267$Vs7.138416@fx41.am4>
 <CAE6NSRBrCSNwXJ8friR96BGu=_sxgEESphzYzaHSUoMv57a0TA@mail.gmail.com>
 <peb3uc$q4o$2@blaine.gmane.org>
 <CAE6NSRAa-aOcRzfKEqCmyfnqv05MJ-snZQU+ZrbctFLJj-pGxA@mail.gmail.com>
 <pec0ub$q4o$7@blaine.gmane.org>
 <CAE6NSRBpChzWhrvQEWxDhD-+Ot58Rb9uOfG9knvJu4iTt=nKtg@mail.gmail.com>
Message-ID: <CAPTjJmrZ3v-BtoQ2WNb9UOexRWExssXGJdYFKUUL5cwKY+YpCw@mail.gmail.com>

On Sun, May 27, 2018 at 5:13 AM, Mikhail V <mikhailwas at gmail.com> wrote:
> On Sat, May 26, 2018 at 7:10 PM, Steven D'Aprano

>>     temp = >>| Mikhail's syntax for {65290} is {65290}
>> Can you see the problem yet? How does your collapse function f()
>> distinguish between the escape code {65290} and the literal string
>> {65290}?
>
> Look, there is no any problem here. You can choose
> whatever YOU want to write "{" and "}". e.g. I'd pick {<} {>}.
>
>     temp = >>| Mikhail's syntax for {65290} is {<}65290{>}

Whatever notation you pick, you need some way to represent it
literally. Don't you see? All you're doing is dodging the issue by
making your literal syntax more and more complicated.

> I just show you that syntax allows you not only input TEXT
> without any manipulations, but also it allows to solve any task related
> to custom presentation - in this case you want work with
> ordinals for example. And you may end up with a scheme which
> reads way better than your cryptic example.

How about a simple notation that bases everything on a single typable
character like REVERSE SOLIDUS?

> I'll also ask you a question  -
> Which such non-text codes you may need to
> generate C code? Python code? HTML code?

What do you mean?

>> And we've gone from a single string literal, which is an expression that
>> can be used anywhere, to a statement that cannot be used in expressions.
>
> Ok show me your suggestion for a raw string definition for expressions
> (no modifications to source text and no usage of invisible control chars).

Ahh but "no modifications to source text" was YOUR rule, not ours.
Most of us are perfectly happy for string literals to be spelled with
quotes around them and a straight-forward system of escapes.

Or if we want NO modifications whatsoever, then we use another very
standard way of delimiting the contents: put it in a separate file and
then read that in. Oh wow, look at that, we can just put what we like
and it doesn't break anything!

I'm done. Argue with brick walls for the rest of eternity if you like.

ChrisA


From mikhailwas at gmail.com  Sat May 26 17:09:11 2018
From: mikhailwas at gmail.com (Mikhail V)
Date: Sun, 27 May 2018 00:09:11 +0300
Subject: Raw string statement (proposal)
In-Reply-To: <CAPTjJmrZ3v-BtoQ2WNb9UOexRWExssXGJdYFKUUL5cwKY+YpCw@mail.gmail.com>
References: <CAE6NSRBzDZrV8P+iJQxuENNAtmAAwSaNEbMnKMb_dgGw7yEH3Q@mail.gmail.com>
 <mailman.127.1527222875.18022.python-list@python.org>
 <lnRNC.222267$Vs7.138416@fx41.am4>
 <CAE6NSRBrCSNwXJ8friR96BGu=_sxgEESphzYzaHSUoMv57a0TA@mail.gmail.com>
 <peb3uc$q4o$2@blaine.gmane.org>
 <CAE6NSRAa-aOcRzfKEqCmyfnqv05MJ-snZQU+ZrbctFLJj-pGxA@mail.gmail.com>
 <pec0ub$q4o$7@blaine.gmane.org>
 <CAE6NSRBpChzWhrvQEWxDhD-+Ot58Rb9uOfG9knvJu4iTt=nKtg@mail.gmail.com>
 <CAPTjJmrZ3v-BtoQ2WNb9UOexRWExssXGJdYFKUUL5cwKY+YpCw@mail.gmail.com>
Message-ID: <CAE6NSRCszSfwGd7ZHg6NEossrC83ZQ3Qdr4JTjep2EFyOiKacQ@mail.gmail.com>

On Sat, May 26, 2018 at 10:21 PM, Chris Angelico <rosuav at gmail.com> wrote:

>
> I'm done. Argue with brick walls for the rest of eternity if you like.

I see you like me, but I can reciprocate your feelings.


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


From cs at cskk.id.au  Sat May 26 17:11:12 2018
From: cs at cskk.id.au (Cameron Simpson)
Date: Sun, 27 May 2018 07:11:12 +1000
Subject: Some Issues on Tagging Text
In-Reply-To: <6eb1fdbb-7520-4c82-901d-675f8fd50c81@googlegroups.com>
References: <6eb1fdbb-7520-4c82-901d-675f8fd50c81@googlegroups.com>
Message-ID: <20180526211112.GA21422@cskk.homeip.net>

On 26May2018 04:02, Subhabrata Banerjee <subhabangalore at gmail.com> wrote:
>On Saturday, May 26, 2018 at 3:54:37 AM UTC+5:30, Cameron Simpson wrote:
>> It sounds like you want a more general purpose parser, and that depends upon
>> your purposes. If you're coding to learn the basics of breaking up text, what
>> you're doing is fine and I'd stick with it. But if you're just after the
>> outcome (tags), you could use other libraries to break up the text.
>>
>> For example, the Natural Language ToolKit (NLTK) will do structured parsing of
>> text and return you a syntax tree, and it has many other facilities. Doco:
>>
>>   http://www.nltk.org/
>>
>> PyPI module:
>>
>>   https://pypi.org/project/nltk/
>>
>> which you can install with the command:
>>
>>   pip install --user nltk
>>
>> That would get you a tree structure of the corpus, which you could process more
>> meaningfully. For example, you could traverse the tree and tag higher level
>> nodes as you came across them, possibly then _not_ traversing their inner
>> nodes. The effect of that would be that if you hit the grammatic node:
>>
>>   government of Mexico
>>
>> you might tags that node with "ORGANISATION", and choose not to descend inside
>> it, thus avoiding tagging "government" and "of" and so forth because you have a
>> high level tags. Nodes not specially recognised you're keep descending into,
>> tagging smaller things.
>>
>> Cheers,
>> Cameron Simpson
>
>Dear Sir,
>
>Thank you for your kind and valuable suggestions. Thank you for your kind time too.
>I know NLTK and machine learning. I am of belief if I may use language properly we need machine learning-the least.

I have similar beliefs: not that machine learning is not useful, but that it 
has a tendency to produce black boxes in terms of the results it produces 
because its categorisation rules are not overt, rather they tend to be side 
effects of weights in a graph.

So one might end up with a useful tool, but not understand how or why it works.

>So, I am trying to design a tagger without the help of machine learning, by simple Python coding. I have thus removed standard Parts of Speech(PoS) or Named Entity (NE) tagging scheme.
>I am trying to design a basic model if required may be implemented on any one of these problems.
>Detecting longer phrase is slightly a problem now I am thinking to employ 
>re.search(pattern,text). If this part is done I do not need machine learning. 
>Maintaining so much data is a cumbersome issue in machine learning.

NLTK is not machine learning (I believe). It can parse the corpus for you, 
emitting grammatical structures. So that would aid you in recognising words, 
phrases, nouns, verbs and so forth. With that structure you can then make 
better decisions about what to tag and how.

Using the re module is a very hazard prone way of parsing text. It can be 
useful for finding fairly fixed text, particularly in machine generated text, 
but it is terrible for prose.

Cheers,
Cameron Simpson <cs at cskk.id.au>


From mike.junk.46 at att.net  Sat May 26 19:19:45 2018
From: mike.junk.46 at att.net (Mike McClain)
Date: Sat, 26 May 2018 16:19:45 -0700
Subject: '_' and '__'
In-Reply-To: <mailman.1612.1527331964.18019.python-list@python.org>
References: <mailman.1612.1527331964.18019.python-list@python.org>
Message-ID: <20180526231945.GA14349@playground>

    In their discussion of 'List replication operator'
Steven D'Aprano and Ben Finney used these '_' and '__'.
Steve said, "[[] for _ in range(5)]".
Ben said, "[ [] for __ in range(5) ]".

    These aren't listed separately in the index, where might I find
written discussion of these?
Thanks,
Mike
--
"There are three kinds of men. The ones who learn by reading. The
few who learn by observation. The rest of them have to pee on the
electric fence for themselves." --- Will Rogers


From tjol at tjol.eu  Sat May 26 19:40:59 2018
From: tjol at tjol.eu (Thomas Jollans)
Date: Sun, 27 May 2018 01:40:59 +0200
Subject: '_' and '__'
In-Reply-To: <20180526231945.GA14349@playground>
References: <mailman.1612.1527331964.18019.python-list@python.org>
 <20180526231945.GA14349@playground>
Message-ID: <14dcde29-079e-d319-b59d-35c2df921dd6@tjol.eu>

On 27/05/18 01:19, Mike McClain wrote:
>     In their discussion of 'List replication operator'
> Steven D'Aprano and Ben Finney used these '_' and '__'.
> Steve said, "[[] for _ in range(5)]".
> Ben said, "[ [] for __ in range(5) ]".
> 
>     These aren't listed separately in the index, where might I find
> written discussion of these?

There's nothing special about _, it's just a possible name of a
variable, albeit a very short and entirely uninformative one. Normally,
it's not something you'd actually want to name a variable, of course.

As such, _ has become an idiomatic name for dummy variables, i.e.
something you use when syntax requires you to give a variable name, but
you don't actually want one (probably because you're throwing the
variable away). This mostly happens in generator expressions/list
comprehensions.

-- Thomas


From rosuav at gmail.com  Sat May 26 19:46:01 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Sun, 27 May 2018 09:46:01 +1000
Subject: '_' and '__'
In-Reply-To: <14dcde29-079e-d319-b59d-35c2df921dd6@tjol.eu>
References: <mailman.1612.1527331964.18019.python-list@python.org>
 <20180526231945.GA14349@playground>
 <14dcde29-079e-d319-b59d-35c2df921dd6@tjol.eu>
Message-ID: <CAPTjJmoEw6phLXDQc2ZjA4=UcG8-DH88nKZb=mF+wVFyuiiJFw@mail.gmail.com>

On Sun, May 27, 2018 at 9:40 AM, Thomas Jollans <tjol at tjol.eu> wrote:
> On 27/05/18 01:19, Mike McClain wrote:
>>     In their discussion of 'List replication operator'
>> Steven D'Aprano and Ben Finney used these '_' and '__'.
>> Steve said, "[[] for _ in range(5)]".
>> Ben said, "[ [] for __ in range(5) ]".
>>
>>     These aren't listed separately in the index, where might I find
>> written discussion of these?
>
> There's nothing special about _, it's just a possible name of a
> variable, albeit a very short and entirely uninformative one. Normally,
> it's not something you'd actually want to name a variable, of course.
>
> As such, _ has become an idiomatic name for dummy variables, i.e.
> something you use when syntax requires you to give a variable name, but
> you don't actually want one (probably because you're throwing the
> variable away). This mostly happens in generator expressions/list
> comprehensions.

Yes, and also in stand-alone 'for' loops where you don't care about
the iteration variable:

for _ in range(3): datafile.skipline()

The only actual significance of this name is that the interactive
interpreter will stash the result of the previous expression in that
variable.

>>> 6 * 7
42
>>> _ + 1
43

Other than that, it is simply an ordinary name, but one that has some
conventions attached to it.

ChrisA


From cs at cskk.id.au  Sat May 26 20:14:49 2018
From: cs at cskk.id.au (Cameron Simpson)
Date: Sun, 27 May 2018 10:14:49 +1000
Subject: '_' and '__'
In-Reply-To: <CAPTjJmoEw6phLXDQc2ZjA4=UcG8-DH88nKZb=mF+wVFyuiiJFw@mail.gmail.com>
References: <CAPTjJmoEw6phLXDQc2ZjA4=UcG8-DH88nKZb=mF+wVFyuiiJFw@mail.gmail.com>
Message-ID: <20180527001449.GA91256@cskk.homeip.net>

On 27May2018 09:46, Chris Angelico <rosuav at gmail.com> wrote:
>On Sun, May 27, 2018 at 9:40 AM, Thomas Jollans <tjol at tjol.eu> wrote:
>> There's nothing special about _, it's just a possible name of a
>> variable, albeit a very short and entirely uninformative one. Normally,
>> it's not something you'd actually want to name a variable, of course.
>>
>> As such, _ has become an idiomatic name for dummy variables, i.e.
>> something you use when syntax requires you to give a variable name, but
>> you don't actually want one (probably because you're throwing the
>> variable away). This mostly happens in generator expressions/list
>> comprehensions.
>
>Yes, and also in stand-alone 'for' loops where you don't care about
>the iteration variable:
>
>for _ in range(3): datafile.skipline()
>
>The only actual significance of this name is that the interactive
>interpreter will stash the result of the previous expression in that
>variable.
>
>>>> 6 * 7
>42
>>>> _ + 1
>43
>
>Other than that, it is simply an ordinary name, but one that has some
>conventions attached to it.

Also, various lint tools know that the name "_" is used in this way, and don't 
complain that a variable is assigned to and not used if its name is "_".

Cheers,
Cameron Simpson <cs at cskk.id.au>


From ben+python at benfinney.id.au  Sat May 26 20:36:30 2018
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sun, 27 May 2018 10:36:30 +1000
Subject: '_' and '__'
References: <mailman.1612.1527331964.18019.python-list@python.org>
 <20180526231945.GA14349@playground>
Message-ID: <857enqj5o1.fsf@benfinney.id.au>

Mike McClain <mike.junk.46 at att.net> writes:

> Steven D'Aprano and Ben Finney used these '_' and '__'.
> Steve said, "[[] for _ in range(5)]".
> Ben said, "[ [] for __ in range(5) ]".
>
>     These aren't listed separately in the index

That's right, the names ?_? and ?__? have no special meaning in
Python-the-language so they don't appear in the index.

Steven and I both used those respective names to communicate ?never
going to use this value but the syntax requires a name here?.

> where might I find written discussion of these?

I find Nick Coghlan's answer on StackOverflow
<URL:https://stackoverflow.com/questions/5893163/what-is-the-purpose-of-the-single-underscore-variable-in-python/5893946#5893946>
to be especially helpful.

Nick also explains that, because the name ?_? has too many conventional
meanings already, the name ?__? is better for ?don't need this value but
I am required to specify a name?.

-- 
 \         ?The double standard that exempts religious activities from |
  `\       almost all standards of accountability should be dismantled |
_o__)                   once and for all.? ?Daniel Dennett, 2010-01-12 |
Ben Finney



From steve+comp.lang.python at pearwood.info  Sun May 27 00:47:02 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sun, 27 May 2018 04:47:02 +0000 (UTC)
Subject: Why cannot I use __slots__ and weakrefs together?
References: <peb8n2$q4o$5@blaine.gmane.org> <peban2$kca$1@blaine.gmane.org>
Message-ID: <pedd86$q4o$8@blaine.gmane.org>

On Sat, 26 May 2018 11:53:42 +0200, Christian Heimes wrote:

>> Why does weakref hate my Eggs class?
> 
> Weakref needs some place to store reference information. It works if you
> add "__weakref__" to your slots:
> 
> class Eggs:
>      __slots__ = ['spanish_inquisition', '__weakref__']


Thanks!






-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson



From steve+comp.lang.python at pearwood.info  Sun May 27 00:48:24 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sun, 27 May 2018 04:48:24 +0000 (UTC)
Subject: List replication operator
References: <pe6vjf$g1l$1@blaine.gmane.org> <pe8dpv$9as$1@blaine.gmane.org>
 <pe8tgi$h8n$1@blaine.gmane.org>
 <mailman.141.1527249376.18022.python-list@python.org>
 <pe9fbb$9ll$1@dont-email.me>
Message-ID: <peddao$q4o$9@blaine.gmane.org>

On Fri, 25 May 2018 09:58:19 -0700, Rob Gaddi wrote:

> I agree that it's non-obvious, but I disagree with your diagnosis.

A further data point:

    "I was not properly appreciating that that these 
    repeated objects were the *same identical* objects 
    that were in the pre-replicated list."

https://mail.python.org/pipermail/tutor/2018-May/113080.html



-- 
Steve



From alan at csail.mit.edu  Sun May 27 02:28:50 2018
From: alan at csail.mit.edu (Alan Bawden)
Date: 27 May 2018 02:28:50 -0400
Subject: List replication operator
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <mailman.105.1527185982.18022.python-list@python.org>
Message-ID: <861sdx1ujh.fsf@richard.bawden.org>

If the behaviour of * on a sequence is confusing, then isn't the following
behaviour also confusing for exactly the same reason?

   >>> a = [[]]
   >>> b = a + a
   >>> b
   [[], []]
   >>> b[0].append(5)
   >>> b
   [[5], [5]]

And if so, shouldn't there also be a concatenation operator that performs
a copy of some kind on its operands?

-- 
Alan Bawden


From Karsten.Hilbert at gmx.net  Sun May 27 04:40:08 2018
From: Karsten.Hilbert at gmx.net (Karsten Hilbert)
Date: Sun, 27 May 2018 10:40:08 +0200
Subject: '_' and '__'
In-Reply-To: <857enqj5o1.fsf@benfinney.id.au>
References: <mailman.1612.1527331964.18019.python-list@python.org>
 <20180526231945.GA14349@playground>
 <857enqj5o1.fsf@benfinney.id.au>
Message-ID: <20180527084008.GB3358@hermes.hilbert.loc>

On Sun, May 27, 2018 at 10:36:30AM +1000, Ben Finney wrote:

> Nick also explains that, because the name ?_? has too many conventional
> meanings already, the name ?__? is better for ?don't need this value but
> I am required to specify a name?.

_() is often bound to gettext.gettext() in the global
namespace, so we'd better avoid that or else ...

	[ _(_) for _ in '123' ]

... will fail :-)

Karsten
-- 


From subhabangalore at gmail.com  Sun May 27 07:43:10 2018
From: subhabangalore at gmail.com (subhabangalore at gmail.com)
Date: Sun, 27 May 2018 04:43:10 -0700 (PDT)
Subject: Some Issues on Tagging Text
In-Reply-To: <mailman.201.1527369085.18022.python-list@python.org>
References: <6eb1fdbb-7520-4c82-901d-675f8fd50c81@googlegroups.com>
 <20180526211112.GA21422@cskk.homeip.net>
 <mailman.201.1527369085.18022.python-list@python.org>
Message-ID: <dbfb8971-3f0f-40e1-bd2e-84e3a52ec10f@googlegroups.com>

On Sunday, May 27, 2018 at 2:41:43 AM UTC+5:30, Cameron Simpson wrote:
> On 26May2018 04:02, Subhabrata Banerjee  wrote:
> >On Saturday, May 26, 2018 at 3:54:37 AM UTC+5:30, Cameron Simpson wrote:
> >> It sounds like you want a more general purpose parser, and that depends upon
> >> your purposes. If you're coding to learn the basics of breaking up text, what
> >> you're doing is fine and I'd stick with it. But if you're just after the
> >> outcome (tags), you could use other libraries to break up the text.
> >>
> >> For example, the Natural Language ToolKit (NLTK) will do structured parsing of
> >> text and return you a syntax tree, and it has many other facilities. Doco:
> >>
> >>   http://www.nltk.org/
> >>
> >> PyPI module:
> >>
> >>   https://pypi.org/project/nltk/
> >>
> >> which you can install with the command:
> >>
> >>   pip install --user nltk
> >>
> >> That would get you a tree structure of the corpus, which you could process more
> >> meaningfully. For example, you could traverse the tree and tag higher level
> >> nodes as you came across them, possibly then _not_ traversing their inner
> >> nodes. The effect of that would be that if you hit the grammatic node:
> >>
> >>   government of Mexico
> >>
> >> you might tags that node with "ORGANISATION", and choose not to descend inside
> >> it, thus avoiding tagging "government" and "of" and so forth because you have a
> >> high level tags. Nodes not specially recognised you're keep descending into,
> >> tagging smaller things.
> >>
> >> Cheers,
> >> Cameron Simpson
> >
> >Dear Sir,
> >
> >Thank you for your kind and valuable suggestions. Thank you for your kind time too.
> >I know NLTK and machine learning. I am of belief if I may use language properly we need machine learning-the least.
> 
> I have similar beliefs: not that machine learning is not useful, but that it 
> has a tendency to produce black boxes in terms of the results it produces 
> because its categorisation rules are not overt, rather they tend to be side 
> effects of weights in a graph.
> 
> So one might end up with a useful tool, but not understand how or why it works.
> 
> >So, I am trying to design a tagger without the help of machine learning, by simple Python coding. I have thus removed standard Parts of Speech(PoS) or Named Entity (NE) tagging scheme.
> >I am trying to design a basic model if required may be implemented on any one of these problems.
> >Detecting longer phrase is slightly a problem now I am thinking to employ 
> >re.search(pattern,text). If this part is done I do not need machine learning. 
> >Maintaining so much data is a cumbersome issue in machine learning.
> 
> NLTK is not machine learning (I believe). It can parse the corpus for you, 
> emitting grammatical structures. So that would aid you in recognising words, 
> phrases, nouns, verbs and so forth. With that structure you can then make 
> better decisions about what to tag and how.
> 
> Using the re module is a very hazard prone way of parsing text. It can be 
> useful for finding fairly fixed text, particularly in machine generated text, 
> but it is terrible for prose.
> 
> Cheers,
> Cameron Simpson 

Dear Sir, 

Thank you for your kind time to discuss the matter. 
I am very clear in Statistics but as I am a Linguist too I feel the modern day
craziness on theories is going no where. Many theories but hardly anything of
practical value, bit like post Chomskyan Linguistics scenario. Theories of parsing
are equally bad. Only advantage of statistics is if it is not giving result you may 
abandon them quickly. 

I do not feel Parsing theories of Linguistics lead anywhere esp if data is really big. 

I am looking for patterns. Like if you say Organizations in documents are mostly all
capital lettered acronyms. So no need of taking ML solution for that rather a simple
code line of [word for word in words if word.isupper()] does the job. In the same way
there are many interesting patterns in language if you observe them. I made many, making
many more. All you need some good time to observe the data patiently. 

NLTK is a library mainly built for students practice but now everyone uses it. 
They have many corpora and tools (most of them are built with ML based approach),
but they have many more ML libraries which you may use on user defined data and standard.
NLTK integrates nicely with other Python based libraries like Scikit or Gensim or Java based 
ones like Stanford. The code lines are nicely documented if you feel you may read as proper
references are mostly given. 

I got good results in re earlier but I would surely check your point.

Thank you again for your kind time and a nice discussion.






From Richard at Damon-Family.org  Sun May 27 08:18:22 2018
From: Richard at Damon-Family.org (Richard Damon)
Date: Sun, 27 May 2018 08:18:22 -0400
Subject: Some Issues on Tagging Text
In-Reply-To: <dbfb8971-3f0f-40e1-bd2e-84e3a52ec10f@googlegroups.com>
References: <6eb1fdbb-7520-4c82-901d-675f8fd50c81@googlegroups.com>
 <20180526211112.GA21422@cskk.homeip.net>
 <mailman.201.1527369085.18022.python-list@python.org>
 <dbfb8971-3f0f-40e1-bd2e-84e3a52ec10f@googlegroups.com>
Message-ID: <0a0a172e-bec8-a091-1978-27d4c1a0c544@Damon-Family.org>

On 5/27/18 7:43 AM, subhabangalore at gmail.com wrote:
> On Sunday, May 27, 2018 at 2:41:43 AM UTC+5:30, Cameron Simpson wrote:
>> On 26May2018 04:02, Subhabrata Banerjee  wrote:
>>> On Saturday, May 26, 2018 at 3:54:37 AM UTC+5:30, Cameron Simpson wrote:
>>>> It sounds like you want a more general purpose parser, and that depends upon
>>>> your purposes. If you're coding to learn the basics of breaking up text, what
>>>> you're doing is fine and I'd stick with it. But if you're just after the
>>>> outcome (tags), you could use other libraries to break up the text.
>>>>
>>>> For example, the Natural Language ToolKit (NLTK) will do structured parsing of
>>>> text and return you a syntax tree, and it has many other facilities. Doco:
>>>>
>>>>   http://www.nltk.org/
>>>>
>>>> PyPI module:
>>>>
>>>>   https://pypi.org/project/nltk/
>>>>
>>>> which you can install with the command:
>>>>
>>>>   pip install --user nltk
>>>>
>>>> That would get you a tree structure of the corpus, which you could process more
>>>> meaningfully. For example, you could traverse the tree and tag higher level
>>>> nodes as you came across them, possibly then _not_ traversing their inner
>>>> nodes. The effect of that would be that if you hit the grammatic node:
>>>>
>>>>   government of Mexico
>>>>
>>>> you might tags that node with "ORGANISATION", and choose not to descend inside
>>>> it, thus avoiding tagging "government" and "of" and so forth because you have a
>>>> high level tags. Nodes not specially recognised you're keep descending into,
>>>> tagging smaller things.
>>>>
>>>> Cheers,
>>>> Cameron Simpson
>>> Dear Sir,
>>>
>>> Thank you for your kind and valuable suggestions. Thank you for your kind time too.
>>> I know NLTK and machine learning. I am of belief if I may use language properly we need machine learning-the least.
>> I have similar beliefs: not that machine learning is not useful, but that it 
>> has a tendency to produce black boxes in terms of the results it produces 
>> because its categorisation rules are not overt, rather they tend to be side 
>> effects of weights in a graph.
>>
>> So one might end up with a useful tool, but not understand how or why it works.
>>
>>> So, I am trying to design a tagger without the help of machine learning, by simple Python coding. I have thus removed standard Parts of Speech(PoS) or Named Entity (NE) tagging scheme.
>>> I am trying to design a basic model if required may be implemented on any one of these problems.
>>> Detecting longer phrase is slightly a problem now I am thinking to employ 
>>> re.search(pattern,text). If this part is done I do not need machine learning. 
>>> Maintaining so much data is a cumbersome issue in machine learning.
>> NLTK is not machine learning (I believe). It can parse the corpus for you, 
>> emitting grammatical structures. So that would aid you in recognising words, 
>> phrases, nouns, verbs and so forth. With that structure you can then make 
>> better decisions about what to tag and how.
>>
>> Using the re module is a very hazard prone way of parsing text. It can be 
>> useful for finding fairly fixed text, particularly in machine generated text, 
>> but it is terrible for prose.
>>
>> Cheers,
>> Cameron Simpson 
> Dear Sir, 
>
> Thank you for your kind time to discuss the matter. 
> I am very clear in Statistics but as I am a Linguist too I feel the modern day
> craziness on theories is going no where. Many theories but hardly anything of
> practical value, bit like post Chomskyan Linguistics scenario. Theories of parsing
> are equally bad. Only advantage of statistics is if it is not giving result you may 
> abandon them quickly. 
>
> I do not feel Parsing theories of Linguistics lead anywhere esp if data is really big. 
>
> I am looking for patterns. Like if you say Organizations in documents are mostly all
> capital lettered acronyms. So no need of taking ML solution for that rather a simple
> code line of [word for word in words if word.isupper()] does the job. In the same way
> there are many interesting patterns in language if you observe them. I made many, making
> many more. All you need some good time to observe the data patiently. 
>
> NLTK is a library mainly built for students practice but now everyone uses it. 
> They have many corpora and tools (most of them are built with ML based approach),
> but they have many more ML libraries which you may use on user defined data and standard.
> NLTK integrates nicely with other Python based libraries like Scikit or Gensim or Java based 
> ones like Stanford. The code lines are nicely documented if you feel you may read as proper
> references are mostly given. 
>
> I got good results in re earlier but I would surely check your point.
>
> Thank you again for your kind time and a nice discussion.
>
I will point out that I still haven't heard a statement of what you
actually are trying to do. The first step of designing an Expert System
(a computer system designed to do something that people can do) is come
up with a clear goal of what is to be done that makes no reference to
'computers'. This later part is important as you really want to go to
the final users and think about their needs. To frame things in computer
terms means that you have made the computers and their methods more
important that the final users. The second step is asking the experts
who do this themselves how they do it (they might be using computers to
do some of this, but you want to get the details of the 'wetware'
processing involved, not computer algorithms). Only after you get a good
description in human terms of what and how do you turn to thinking about
how to implement on a computer.

-- 
Richard Damon



From santiago.basulto at gmail.com  Sun May 27 12:00:12 2018
From: santiago.basulto at gmail.com (Santiago Basulto)
Date: Sun, 27 May 2018 12:00:12 -0400
Subject: Possible bug in ThreadPoolExecutor, or just misinterpretation
Message-ID: <CAPmap1fadZKy_B4vVjz112bd0y5bv-DYU6ap9gXkUowxyv9AXQ@mail.gmail.com>

Hey list! I might have encountered a "bug", or maybe it's just a "design
decision" :)

Here's some example code:
https://gist.github.com/santiagobasulto/3513a50ec0dc939e8f7bb2ecfa8d4ae2

The problem is `ThreadPoolExecutor.map()`. It's not returning tasks "as
completed" but sequentially.  I understand that might be the desired
behavior since the function is `map()` and you *might* be expecting the
results "in order".

So, the questions are: Is this expected behavior? Is there any chance to
add an `map_unordered` as multiprocessing has
<https://docs.python.org/3/library/multiprocessing.html#multiprocessing.pool.Pool.imap_unordered>?
Another option might be making `as_completed` work with map results too
(which was my original intention).

Thanks for your answers in advance!

-- 
Santiago Basulto.-
Up!


From drsalists at gmail.com  Sun May 27 12:54:03 2018
From: drsalists at gmail.com (Dan Stromberg)
Date: Sun, 27 May 2018 09:54:03 -0700
Subject: Raw string statement (proposal)
In-Reply-To: <CAE6NSRBzDZrV8P+iJQxuENNAtmAAwSaNEbMnKMb_dgGw7yEH3Q@mail.gmail.com>
References: <CAE6NSRBzDZrV8P+iJQxuENNAtmAAwSaNEbMnKMb_dgGw7yEH3Q@mail.gmail.com>
Message-ID: <CAGGBd_r_aKvWXkLNhbJjrN8eVoivxfTCw4rXddYwrjNgA2523w@mail.gmail.com>

On Thu, May 24, 2018 at 9:34 PM, Mikhail V <mikhailwas at gmail.com> wrote:

> Hi.
> I've put some thoughts together, and
> need some feedback on this proposal.
> Main question is:  Is it convincing?
> Is there any flaw?
> My own opinion - there IS something to chase.
> Still the justification for such syntax is hard.
>
This is a strange syntax that is quite unnecessary; just use triple-quoted
strings.

Please, please, please don't add it.

I believe Python's core language should be kept small.  Big libraries are
fine - important even.  But the core language should be easy to learn but
powerful.


From songofacandy at gmail.com  Sun May 27 12:55:53 2018
From: songofacandy at gmail.com (INADA Naoki)
Date: Mon, 28 May 2018 01:55:53 +0900
Subject: Possible bug in ThreadPoolExecutor, or just misinterpretation
In-Reply-To: <CAPmap1fadZKy_B4vVjz112bd0y5bv-DYU6ap9gXkUowxyv9AXQ@mail.gmail.com>
References: <CAPmap1fadZKy_B4vVjz112bd0y5bv-DYU6ap9gXkUowxyv9AXQ@mail.gmail.com>
Message-ID: <CAEfz+TwkwY7bBU5GUaMXV+jTcNxLH-Lu33k7oZHDraTJ-VXi1A@mail.gmail.com>

On Mon, May 28, 2018 at 1:12 AM Santiago Basulto
<santiago.basulto at gmail.com>
wrote:

> Hey list! I might have encountered a "bug", or maybe it's just a "design
> decision" :)

> Here's some example code:
> https://gist.github.com/santiagobasulto/3513a50ec0dc939e8f7bb2ecfa8d4ae2

> The problem is `ThreadPoolExecutor.map()`. It's not returning tasks "as
> completed" but sequentially.  I understand that might be the desired
> behavior since the function is `map()` and you *might* be expecting the
> results "in order".

> So, the questions are: Is this expected behavior?

Yes, you can use `future.as_completed()` instead.

>   Is there any chance to
> add an `map_unordered` as multiprocessing has
> <
https://docs.python.org/3/library/multiprocessing.html#multiprocessing.pool.Pool.imap_unordered
> ?

I don't it's reasonable.
You can use multiprocessing.ThreadPool instead.

> Another option might be making `as_completed` work with map results too
> (which was my original intention).

I don't like this idea.

Regards,

-- 
INADA Naoki  <songofacandy at gmail.com>


From email at paulstgeorge.com  Sun May 27 13:59:41 2018
From: email at paulstgeorge.com (Paul St George)
Date: Sun, 27 May 2018 19:59:41 +0200
Subject: The PIL show() method looks for the default viewer. How do I
 change this to a different viewer (of my choice)?
In-Reply-To: <fr5jgd50bkjrroudnlsdhe3t78gcpt61nn@4ax.com>
References: <ddedae8b-f085-dfa3-08a4-2c821975cc61@paulstgeorge.com>
 <CANDiX9+fF3ADqhee50RA47hecQRpsOVJjXML9=OAYzkAp9gNqw@mail.gmail.com>
 <0efaafaa-064f-726a-416f-9dc9d0756667@paulstgeorge.com>
 <fr5jgd50bkjrroudnlsdhe3t78gcpt61nn@4ax.com>
Message-ID: <01feca98-20d6-2b96-5cc4-df8f616c87f3@paulstgeorge.com>

So, on Unix I would use

Image.show(title=None, nameofdisplayutilty), or Image.show(title=None, 
scriptname) #where script with name scriptname invokes the program

I will try this now! And thank you.


On 26/05/2018 19:30, Dennis Lee Bieber wrote:
> On Sat, 26 May 2018 17:17:42 +0200, Paul St George <email at paulstgeorge.com>
> declaimed the following:
>
>> And, out of curiosity, as I will probably use a different method - how
>> do I find out what commands can be used as parameters for show()? I read
>> the docs at
>> <https://pillow.readthedocs.io/en/5.1.x/reference/Image.html#PIL.Image.Image.show>,
>> but I am none the wiser.
>>
> 	AS the examples ("On OS-of-choice...") illustrate... command is any
> external executable program that can handle the temporary file, I presume
> using the name of the temporary and not via redirection of stdin... If you
> have a hex-editor, you could even supply that as "command". If you need to
> provide more than the program name, you may have to instead create a
> shell-script, set it executable, and pass the script name -- have the
> script then invoke the program with the options and forwarding the
> temporary file name to it.
>
>

-- 
Paul St George
http://www.paulstgeorge.com
http://www.devices-of-wonder.com

+44(0)7595 37 1302



From email at paulstgeorge.com  Sun May 27 14:15:02 2018
From: email at paulstgeorge.com (Paul St George)
Date: Sun, 27 May 2018 20:15:02 +0200
Subject: The PIL show() method looks for the default viewer. How
 do I change this to a different viewer (of my choice)?
In-Reply-To: <pec4bf$3a7$1@blaine.gmane.org>
References: <ddedae8b-f085-dfa3-08a4-2c821975cc61@paulstgeorge.com>
 <CANDiX9+fF3ADqhee50RA47hecQRpsOVJjXML9=OAYzkAp9gNqw@mail.gmail.com>
 <0efaafaa-064f-726a-416f-9dc9d0756667@paulstgeorge.com>
 <pec4bf$3a7$1@blaine.gmane.org>
Message-ID: <6d5f6b18-99ac-cc6f-8cfb-0caf23224c51@paulstgeorge.com>

This is very helpful indeed, thank you. Awe-inspiring.

It occurred to me that I could edit the PIL/ImageShow.py, replacing ?xv? 
(in five places) with the utility of my choice and using ?executable? as 
the command.

Or, is this just not done?

On 26/05/2018 19:11, Peter Otten wrote:
> Paul St George wrote:
>
>> Thank you.
>> You are very right. The show() method is intended for debugging purposes
>> and is useful for that, but what method should I be using and is PIL the
>> best imaging library for my purposes? I do not want to manipulate
>> images, I only want to show images (full screen) on an external display.
>> I want to use Python to control the timing of the images.
>>
>> And, out of curiosity, as I will probably use a different method - how
>> do I find out what commands can be used as parameters for show()? I read
>> the docs at
>> <https://pillow.readthedocs.io/en/5.1.x/reference/Image.html
>> #PIL.Image.Image.show>,
>> but I am none the wiser.
> If you look into the source code
>
> https://github.com/python-pillow/Pillow/blob/master/src/PIL/Image.py#L1967
>
> after a few indirections
>
> show --> _show --> _showxv --> ImageShow.show
>
> you will end up in the file
>
> https://github.com/python-pillow/Pillow/blob/master/src/PIL/ImageShow.py
>
> which is short enough to read completely ;)
>
> At first glance it looks like the command argument is silently discarded, so
> here's plan B:
>
> It turns out that you can register() Viewer instances, and the pre-
> registered viewers for unixoids -- and thus probably the Pi are
> DisplayViewer and XVViewer.
>
> Using these as a template I came up with the following simple viewer that
> shows an image with firefox:
>
> #!/usr/bin/env python3
> import os
> import sys
>
> from PIL import Image, ImageShow
>
>
> class Firefox(ImageShow.UnixViewer):
>
>      # store the image in a format understood by the browser
>      format = "jpeg"
>
>      def get_command_ex(self, file, **options):
>          return ("firefox",) * 2
>
>      def show_file(self, file, **options):
>          quote = ImageShow.quote
>
>          command, executable = self.get_command_ex(file, **options)
>
>          # firefox returns immediately, so let's sleep a few seconds
>          # to give it time to actually open the image file
>          command = "(%s %s; sleep 10; rm -f %s)&" % (
>              command, quote("file://" + file), quote(file)
>          )
>          os.system(command)
>          return 1
>
>
> # the -1 means our viewer will be inserted before the others
> # and thus become the default
> ImageShow.register(Firefox(), -1)
>
>
> if __name__ == "__main__":
>      try:
>          file = sys.argv[1]
>      except IndexError:
>          print("Please provide an image file", file=sys.stderr)
>      else:
>          image = Image.open(file)
>          image.show()
>
>
> Here's another, even simpler one:
>
> class Gwenview(ImageShow.UnixViewer):
>      def get_command_ex(self, file, **options):
>          return ("gwenview",) * 2
>
>
>

-- 
Paul St George
http://www.paulstgeorge.com
http://www.devices-of-wonder.com

+44(0)7595 37 1302



From tallpaul at gmail.com  Sun May 27 17:17:57 2018
From: tallpaul at gmail.com (Paul)
Date: Sun, 27 May 2018 21:17:57 +0000
Subject: how to read a syntax diagram
Message-ID: <CA+og5uojWB7WANfkT4-dJo6c4u6QK446sZ49h9FucOBLqw8njg@mail.gmail.com>

hi,
   I'm using the Google Sheets API (the client library rather than the
RESTful interface) and I'm confused about the meaning of the syntax
diagrams.  This is from
https://developers.google.com/resources/api-libraries/documentation/sheets/v4/python/latest/sheets_v4.spreadsheets.values.html#update

efaults to ROWS.
  }

update(spreadsheetId=*, range=*, body=*, valueInputOption=None,
x__xgafv=None, responseValueRenderOption=None,
includeValuesInResponse=None, responseDateTimeRenderOption=None)

Sets values in a range of a spreadsheet.
The caller must specify the spreadsheet ID, range, and
a valueInputOption.

Args:
  spreadsheetId: string, The ID of the spreadsheet to update. (required)
  range: string, The A1 notation of the values to update. (required)
  body: object, The request body. (required)
    The object takes the form of:

{ # Data within a range of the spreadsheet.
  "range": "A String", # The range the values cover, in A1 notation.
      # For output, this range indicates the entire requested range,
      # even though the values will exclude trailing rows and columns.
      # When appending values, this field represents the range to search for a
      # table, after which values will be appended.
  "values": [ # The data that was read or to be written.  This is an
array of arrays,
      # the outer array representing all the data and each inner array
      # representing a major dimension. Each item in the inner array
      # corresponds with one cell.
      #
      # For output, empty trailing rows and columns will not be included.
      #
      # For input, supported value types are: bool, string, and double.
      # Null values will be skipped.
      # To set a cell to an empty value, set the string value to an
empty string.
    [
      "",
    ],
  ],
  "majorDimension": "A String", # The major dimension of the values.
      #
      # For output, if the spreadsheet data is: `A1=1,B1=2,A2=3,B2=4`,
      # then requesting `range=A1:B2,majorDimension=ROWS` will return
      # `[[1,2],[3,4]]`,
      # whereas requesting `range=A1:B2,majorDimension=COLUMNS` will return
      # `[[1,3],[2,4]]`.
      #
      # For input, with `range=A1:B2,majorDimension=ROWS` then `[[1,2],[3,4]]`
      # will set `A1=1,B1=2,A2=3,B2=4`. With
`range=A1:B2,majorDimension=COLUMNS`
      # then `[[1,2],[3,4]]` will set `A1=1,B1=3,A2=2,B2=4`.
      #
      # When writing, if this field is not set, it defaults to ROWS.
}

  valueInputOption: string, How the input data should be
interpreted....// I CUT IT OFF, HERE


My specific questions are:
   1) is this standard (python?) syntax notation?  I haven't found a key to
this form of documentation.
   1)  What does  '=*' mean?
   2)  What does '=None' mean?    [my guess is that this means "no default
value"].
   3)  Note that it says that range is required.  Through trial, I see that
*one* of the 'range' specifications is required.  I.E., I can specify
'range' outside body, or 'range' as part of body, or both, but I must have
'range' someplace.   This is a bit confusing to me ( as opposed to my usual
understanding of "required").  Also, what does range mean, in these two
different spots, and what does it mean if two different values of range are
specified?

thanks
  Paul Czyzewski


From tallpaul at gmail.com  Sun May 27 17:19:15 2018
From: tallpaul at gmail.com (Paul)
Date: Sun, 27 May 2018 21:19:15 +0000
Subject: how to read a syntax diagram
In-Reply-To: <CA+og5uojWB7WANfkT4-dJo6c4u6QK446sZ49h9FucOBLqw8njg@mail.gmail.com>
References: <CA+og5uojWB7WANfkT4-dJo6c4u6QK446sZ49h9FucOBLqw8njg@mail.gmail.com>
Message-ID: <CA+og5up+JShSzXNHXYQpNjo9Wt8z6cUvLs5ZYAAAqj7=FSdDDw@mail.gmail.com>

oops, please ignore the bit before "update(spreadsheetId=*, range=*, ..."

On Sun, May 27, 2018 at 9:17 PM, Paul <tallpaul at gmail.com> wrote:

> hi,
>    I'm using the Google Sheets API (the client library rather than the
> RESTful interface) and I'm confused about the meaning of the syntax
> diagrams.  This is from
> https://developers.google.com/resources/api-libraries/
> documentation/sheets/v4/python/latest/sheets_v4.spreadsheets.values.html#
> update
>
> efaults to ROWS.
>   }
>
> update(spreadsheetId=*, range=*, body=*, valueInputOption=None,
> x__xgafv=None, responseValueRenderOption=None,
> includeValuesInResponse=None, responseDateTimeRenderOption=None)
>
> Sets values in a range of a spreadsheet.
> The caller must specify the spreadsheet ID, range, and
> a valueInputOption.
>
> Args:
>   spreadsheetId: string, The ID of the spreadsheet to update. (required)
>   range: string, The A1 notation of the values to update. (required)
>   body: object, The request body. (required)
>     The object takes the form of:
>
> { # Data within a range of the spreadsheet.
>   "range": "A String", # The range the values cover, in A1 notation.
>       # For output, this range indicates the entire requested range,
>       # even though the values will exclude trailing rows and columns.
>       # When appending values, this field represents the range to search for a
>       # table, after which values will be appended.
>   "values": [ # The data that was read or to be written.  This is an array of arrays,
>       # the outer array representing all the data and each inner array
>       # representing a major dimension. Each item in the inner array
>       # corresponds with one cell.
>       #
>       # For output, empty trailing rows and columns will not be included.
>       #
>       # For input, supported value types are: bool, string, and double.
>       # Null values will be skipped.
>       # To set a cell to an empty value, set the string value to an empty string.
>     [
>       "",
>     ],
>   ],
>   "majorDimension": "A String", # The major dimension of the values.
>       #
>       # For output, if the spreadsheet data is: `A1=1,B1=2,A2=3,B2=4`,
>       # then requesting `range=A1:B2,majorDimension=ROWS` will return
>       # `[[1,2],[3,4]]`,
>       # whereas requesting `range=A1:B2,majorDimension=COLUMNS` will return
>       # `[[1,3],[2,4]]`.
>       #
>       # For input, with `range=A1:B2,majorDimension=ROWS` then `[[1,2],[3,4]]`
>       # will set `A1=1,B1=2,A2=3,B2=4`. With `range=A1:B2,majorDimension=COLUMNS`
>       # then `[[1,2],[3,4]]` will set `A1=1,B1=3,A2=2,B2=4`.
>       #
>       # When writing, if this field is not set, it defaults to ROWS.
> }
>
>   valueInputOption: string, How the input data should be interpreted....// I CUT IT OFF, HERE
>
>
> My specific questions are:
>    1) is this standard (python?) syntax notation?  I haven't found a key
> to this form of documentation.
>    1)  What does  '=*' mean?
>    2)  What does '=None' mean?    [my guess is that this means "no default
> value"].
>    3)  Note that it says that range is required.  Through trial, I see
> that *one* of the 'range' specifications is required.  I.E., I can specify
> 'range' outside body, or 'range' as part of body, or both, but I must have
> 'range' someplace.   This is a bit confusing to me ( as opposed to my usual
> understanding of "required").  Also, what does range mean, in these two
> different spots, and what does it mean if two different values of range are
> specified?
>
> thanks
>   Paul Czyzewski
>


From cs at cskk.id.au  Sun May 27 17:58:36 2018
From: cs at cskk.id.au (Cameron Simpson)
Date: Mon, 28 May 2018 07:58:36 +1000
Subject: The PIL show() method looks for the default viewer. How do I
 change this to a different viewer (of my choice)?
In-Reply-To: <6d5f6b18-99ac-cc6f-8cfb-0caf23224c51@paulstgeorge.com>
References: <6d5f6b18-99ac-cc6f-8cfb-0caf23224c51@paulstgeorge.com>
Message-ID: <20180527215836.GA6330@cskk.homeip.net>

On 27May2018 20:15, Paul St George <email at paulstgeorge.com> wrote:
>This is very helpful indeed, thank you. Awe-inspiring.
>
>It occurred to me that I could edit the PIL/ImageShow.py, replacing 
>?xv? (in five places) with the utility of my choice and using 
>?executable? as the command.
>
>Or, is this just not done?

It becomes a maintenance problem.

Alternatively you could:

Just write your own show function which accepts an Image and displays it with 
your program of choice. You might need to write some equivalent code which 
saves the Image to a file first, and removes it afterwards.

You could copy the show() code into a function of your own (i.e. in your own 
codebase) modify that to suit, then monkeypatch the class:

  Image.show = your_personal_show_function

when your programme starts. That way the code changes are not in the PIL code.

Cheers,
Cameron Simpson <cs at cskk.id.au>


From steve+comp.lang.python at pearwood.info  Sun May 27 19:24:57 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Sun, 27 May 2018 23:24:57 +0000 (UTC)
Subject: how to read a syntax diagram
References: <CA+og5uojWB7WANfkT4-dJo6c4u6QK446sZ49h9FucOBLqw8njg@mail.gmail.com>
Message-ID: <pefeo9$q4o$10@blaine.gmane.org>

On Sun, 27 May 2018 21:17:57 +0000, Paul wrote:

> hi,
>    I'm using the Google Sheets API (the client library rather than the
> RESTful interface) and I'm confused about the meaning of the syntax
> diagrams.

*Diagrams*? As in, *pictures*?


> update(spreadsheetId=*, range=*, body=*, valueInputOption=None,
> x__xgafv=None, responseValueRenderOption=None,
> includeValuesInResponse=None, responseDateTimeRenderOption=None)
[...]

> My specific questions are:
>    1) is this standard (python?) syntax notation?  I haven't found a key
>    to this form of documentation.

No.

>    1)  What does  '=*' mean?

No idea.

>    2)  What does '=None' mean?    [my guess is that this means "no
>    default value"].

If they are using the same meaning as the standard convention in Python, 
it means the opposite: that None is the default.

If they mean something else, your guess is as good as mine.


>    3)  Note that it says that range is required.  Through trial, I see
>    that
> *one* of the 'range' specifications is required.  I.E., I can specify
> 'range' outside body, or 'range' as part of body, or both, but I must
> have 'range' someplace.   This is a bit confusing to me ( as opposed to
> my usual understanding of "required").  Also, what does range mean, in
> these two different spots, and what does it mean if two different values
> of range are specified?

No idea.


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson



From python at mrabarnett.plus.com  Sun May 27 19:43:39 2018
From: python at mrabarnett.plus.com (MRAB)
Date: Mon, 28 May 2018 00:43:39 +0100
Subject: how to read a syntax diagram
In-Reply-To: <CA+og5uojWB7WANfkT4-dJo6c4u6QK446sZ49h9FucOBLqw8njg@mail.gmail.com>
References: <CA+og5uojWB7WANfkT4-dJo6c4u6QK446sZ49h9FucOBLqw8njg@mail.gmail.com>
Message-ID: <95f325a8-e0fd-ca47-c254-ec5d5fa367e0@mrabarnett.plus.com>

On 2018-05-27 22:17, Paul wrote:
> hi,
>     I'm using the Google Sheets API (the client library rather than the
> RESTful interface) and I'm confused about the meaning of the syntax
> diagrams.  This is from
> https://developers.google.com/resources/api-libraries/documentation/sheets/v4/python/latest/sheets_v4.spreadsheets.values.html#update
> 
> efaults to ROWS.
>    }
> 
> update(spreadsheetId=*, range=*, body=*, valueInputOption=None,
> x__xgafv=None, responseValueRenderOption=None,
> includeValuesInResponse=None, responseDateTimeRenderOption=None)
> 
> Sets values in a range of a spreadsheet.
> The caller must specify the spreadsheet ID, range, and
> a valueInputOption.
> 
> Args:
>    spreadsheetId: string, The ID of the spreadsheet to update. (required)
>    range: string, The A1 notation of the values to update. (required)
>    body: object, The request body. (required)
>      The object takes the form of:
> 
> { # Data within a range of the spreadsheet.
>    "range": "A String", # The range the values cover, in A1 notation.
>        # For output, this range indicates the entire requested range,
>        # even though the values will exclude trailing rows and columns.
>        # When appending values, this field represents the range to search for a
>        # table, after which values will be appended.


[snip]
> 
> My specific questions are:
>     1) is this standard (python?) syntax notation?  I haven't found a key to
> this form of documentation.

Note quite.

>     1)  What does  '=*' mean?

In the descriptions that follow, those that have '=*' also have 
'(required)', so I think it means that the parameter is required. That's 
not standard Python notation, AFAIK.

>     2)  What does '=None' mean?    [my guess is that this means "no default
> value"].

In standard Python notation it means that the default is None, which 
usually means that there's some kind of default. For example, if the 
parameter is for defining a date format, None would mean to use a 
standard date format, such as ISO-whatever or the system-defined date 
format for the current locale.

>     3)  Note that it says that range is required.  Through trial, I see that
> *one* of the 'range' specifications is required.  I.E., I can specify
> 'range' outside body, or 'range' as part of body, or both, but I must have
> 'range' someplace.   This is a bit confusing to me ( as opposed to my usual
> understanding of "required").  Also, what does range mean, in these two
> different spots, and what does it mean if two different values of range are
> specified?
> 
For range it mentions "A1 notation". In spreadsheet applications, 
columns are labelled by letter (A, B, C, etc.) and rows by number (1, 2, 
3, etc.), so the top-left cell is "A1". You specify a range by giving 
the labels of 2 opposite corners, e.g. "A1B3".


From Richard at Damon-Family.org  Sun May 27 23:46:23 2018
From: Richard at Damon-Family.org (Richard Damon)
Date: Sun, 27 May 2018 23:46:23 -0400
Subject: List replication operator
In-Reply-To: <pea2ma$oj4$1@blaine.gmane.org>
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <mailman.105.1527185982.18022.python-list@python.org>
 <ArTNC.227166$oo.202952@fx35.am4>
 <CAPTjJmo0NztzXNTKLLUN-2iuTNG1WYEwYc11kQ9O+pzQ4fhetg@mail.gmail.com>
 <mailman.145.1527252406.18022.python-list@python.org>
 <kLTNC.335175$B36.97718@fx22.am4>
 <CAPTjJmoHSyV0U0UPytdRrENpiVGvMAZYDPCCqY6uNZV0fzpf9Q@mail.gmail.com>
 <mailman.149.1527262053.18022.python-list@python.org>
 <G7WNC.336437$sl2.259969@fx46.am4>
 <5d43e76d-f8f2-e3dc-a321-2aa04e4315e0@mapgears.com>
 <mailman.157.1527265008.18022.python-list@python.org>
 <%2XNC.227220$oo.122313@fx35.am4>
 <CAPTjJmpnR2WFnACgsOCh5zZmpZHN1nh+Vc3+KhH96v19hdf+xw@mail.gmail.com>
 <pea2ma$oj4$1@blaine.gmane.org>
Message-ID: <cd0126c7-1ab9-88ce-79fd-a9cd4f8929b8@Damon-Family.org>

On 5/25/18 6:28 PM, Steven D'Aprano wrote:
> On Sat, 26 May 2018 02:58:06 +1000, Chris Angelico wrote:
>
>> Your mail/news client might choose to represent configure.ac as a link,
>> since ".ac" is a valid TLD.
> Isn't *everything* a valid TLD now?
>
> For the right price, at least.
>
Not quite, .invalid has been promised (I beleive) to NEVER be a valid TLD

Also, I think two letter TLDs are reserved for country codes, and not up
for sale (except by getting ISO to assign you a country code).

-- 
Richard Damon



From rosuav at gmail.com  Mon May 28 00:13:57 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Mon, 28 May 2018 14:13:57 +1000
Subject: List replication operator
In-Reply-To: <cd0126c7-1ab9-88ce-79fd-a9cd4f8929b8@Damon-Family.org>
References: <pe6vjf$g1l$1@blaine.gmane.org>
 <mailman.105.1527185982.18022.python-list@python.org>
 <ArTNC.227166$oo.202952@fx35.am4>
 <CAPTjJmo0NztzXNTKLLUN-2iuTNG1WYEwYc11kQ9O+pzQ4fhetg@mail.gmail.com>
 <mailman.145.1527252406.18022.python-list@python.org>
 <kLTNC.335175$B36.97718@fx22.am4>
 <CAPTjJmoHSyV0U0UPytdRrENpiVGvMAZYDPCCqY6uNZV0fzpf9Q@mail.gmail.com>
 <mailman.149.1527262053.18022.python-list@python.org>
 <G7WNC.336437$sl2.259969@fx46.am4>
 <5d43e76d-f8f2-e3dc-a321-2aa04e4315e0@mapgears.com>
 <mailman.157.1527265008.18022.python-list@python.org>
 <%2XNC.227220$oo.122313@fx35.am4>
 <CAPTjJmpnR2WFnACgsOCh5zZmpZHN1nh+Vc3+KhH96v19hdf+xw@mail.gmail.com>
 <pea2ma$oj4$1@blaine.gmane.org>
 <cd0126c7-1ab9-88ce-79fd-a9cd4f8929b8@Damon-Family.org>
Message-ID: <CAPTjJmp4_3oC1J1P8eTs2X4+-CUVhDNGG=T+2kRrHFg6TeStRw@mail.gmail.com>

On Mon, May 28, 2018 at 1:46 PM, Richard Damon <Richard at damon-family.org> wrote:
> On 5/25/18 6:28 PM, Steven D'Aprano wrote:
>> On Sat, 26 May 2018 02:58:06 +1000, Chris Angelico wrote:
>>
>>> Your mail/news client might choose to represent configure.ac as a link,
>>> since ".ac" is a valid TLD.
>> Isn't *everything* a valid TLD now?
>>
>> For the right price, at least.
>>
> Not quite, .invalid has been promised (I beleive) to NEVER be a valid TLD
>
> Also, I think two letter TLDs are reserved for country codes, and not up
> for sale (except by getting ISO to assign you a country code).
>

Cool, I'll just start my own country then.

ChrisA


From auriocus at gmx.de  Mon May 28 00:34:30 2018
From: auriocus at gmx.de (Christian Gollwitzer)
Date: Mon, 28 May 2018 06:34:30 +0200
Subject: The PIL show() method looks for the default viewer. How do I
 change this to a different viewer (of my choice)?
In-Reply-To: <mailman.19.1527458326.2804.python-list@python.org>
References: <6d5f6b18-99ac-cc6f-8cfb-0caf23224c51@paulstgeorge.com>
 <20180527215836.GA6330@cskk.homeip.net>
 <mailman.19.1527458326.2804.python-list@python.org>
Message-ID: <peg0sn$46i$1@dont-email.me>

Am 27.05.18 um 23:58 schrieb Cameron Simpson:
> On 27May2018 20:15, Paul St George <email at paulstgeorge.com> wrote:
>> This is very helpful indeed, thank you. Awe-inspiring.
>>
>> It occurred to me that I could edit the PIL/ImageShow.py, replacing 
>> ?xv? (in five places) with the utility of my choice and using 
>> ?executable? as the command.
>>
>> Or, is this just not done?
> 
> It becomes a maintenance problem.
> 
> Alternatively you could:
> 
> Just write your own show function which accepts an Image and displays it 
> with your program of choice. You might need to write some equivalent 
> code which saves the Image to a file first, and removes it afterwards.
> 
> You could copy the show() code into a function of your own (i.e. in your 
> own codebase) modify that to suit, then monkeypatch the class:
> 
>  ?Image.show = your_personal_show_function
> 
> when your programme starts. That way the code changes are not in the PIL 
> code.

I think this is a bug/misfeature in the PIL code. On all 3 major 
platforms there is a way to invoke the standard program for a given file 
or URL. On Windows, it is "cmd.exe /c start ...", on OSX it is "open 
...." and on Linux it is "xdg-open ...". That way the file is opened by 
whatever the user has set in his desktop environment.

Technically, xdg-open needs not to be present on Linux, though it is 
usually installed.

	Christian


From nico.schloemer at gmail.com  Mon May 28 03:33:03 2018
From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=)
Date: Mon, 28 May 2018 09:33:03 +0200
Subject: cProfile, timed call tree
In-Reply-To: <87in7b3rjy.fsf@handshake.de>
References: <CAK6Z60du+GX5iUmjfFQZz4bxSKifUQZ8hAa4vGf8qFTsOtaOXg@mail.gmail.com>
 <87in7b3rjy.fsf@handshake.de>
Message-ID: <CAK6Z60dEgMzYMz8SGrA0zAxWPRTQLTiZ-uP5Vt9RG=2aGkFsbA@mail.gmail.com>

Thanks, Dieter, for the concise answer.

Cheers,
Nico

On Sat, May 26, 2018 at 7:42 AM dieter <dieter at handshake.de> wrote:

> Nico Schl?mer <nico.schloemer at gmail.com> writes:
>
> > From what I understand about the Python profilers, the type of
> information
> > you get from a stats object is
> >
> >   * How much time was spent in function X,
> >   * what the callers and callees of function X are, and
> >   * and bunch of meta info about function X.
> >
> > With the program
> > ```
> > def prime(n):
> >     # compute the n-th prime number, takes longer for larger n
> >     return 2
> >
> > def a():
> >     return prime(1)
> >
> > def b():
> >     return prime(4000)
> >
> > a()
> > b()
> > ```
> > I would be able to find that `prime` took a lot of time, but not that it
> > took more time when called from `b()`. In other words: I cannot construct
> > the call tree with times from Stats.
>
> You will see that "prime" was called both from "a" and "b" - and
> *in this particular case*, you will see that the execution times
> of "b" and "prime" are almost identical and derive that the "prime"
> call of b was the expensive one.
>
> But, in general, you are right: you cannot reconstruct complete
> call trees. The reason is quite simple: maintaining information
> for the complete caller ancestry (rather than just the immediate
> caller) is expensive (both in terms of runtime and storage).
> Profiling usually is used as a preparation for optimization.
> Optimization has the greatest effects if applied to inner loops.
> And for the analysis of inner loops, complete call tree information
> is not necessary.
>
> > Is this correct? If not, how to get a timed call tree from Stats? Perhaps
> > that's not the right think to work with?
>
> You will need to write your own profiler - one that keeps track
> not only about the immediate caller of a function call but
> of the whole caller ancestry (maybe recursion reduced).
>
> You can see an example of a custom profiler
> in "Products.ZopeProfiler" (--> PyPI).
> It does not take into account the whole caller ancestry.
> Instead it records additional information concerning higher level
> Zope (a Web application framework) calls.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>


From Alexander  Mon May 28 04:13:52 2018
From: Alexander (Alexander)
Date: Mon, 28 May 2018 10:13:52 +0200
Subject: PyConDE 2018 (Germany) & PyData Karlsruhe CfP extended.
Message-ID: <814AA063-DED2-4EBC-89CE-BA0F14FC57A9@hendorf.com>

The CfP has been extended for one more week until Sunday June 3 24:00 AoE (Anywhere on Earth).

PyCon.DE is where Pythonistas in Germany can meet to learn about new and upcoming Python libraries, tools, software and data science. 
We welcome Python enthusiasts, programmers, data scientists and everyone else from around the world to join us in Karlsruhe this year.
It's the second time our team runs the conference and we expect more than 500 participants for this year's conference. 
The conference lasts 3 days + 2 days of sprints featuring about 60 talks, tutorials and hands on sessions.

The conference will be held in English language only.

Dates:
main conference: Wednesday October 24 - Friday October 26
sprints: Saturday October 27 - Sunday October 28

Karlsruhe is a major engineering hub of Germany with an elite university KIT. 
Companies in the area include Bosch, Daimler, Porsche, and SAP.
It's easy to reach Karlsruhe by high speed train ICE/TGV or plane (directly of via Frankfurt + high speed train or via Stuttgart).

Proposals
==========

We?re looking for proposals on every aspect of Python: programming from novice to advanced levels, applications and frameworks, or how you have been involved in introducing Python into your organization. PyConDE is a community conference and we are eager to hear about your experience.

CfP: 

The conferences addresses:

* Data Scientists
* Software Developers
* System Administrators
* Academic Scientists
* Technology Enthusiasts
* Innovation Managers
* AI Engineers

We are looking for:

* 15 minute presentations - keeping a long story short (no Q&A)
* 30 minute presentations (incl. optional 5 minute Q&A)
* 45 minute presentations (incl. optional 5 minute Q&A)
* 90 minute workshops
* Posters

PyData @ PyConDE 2018
======================
There will be a PyData track at this year?s conference. 
Please submit your papers for the PyData track through the PyConDE form.

CfP will close Sunday June 3 24:00 AoE (Anywhere on Earth).
We plan to notify speakers by second week of June
and release a draft schedule in June.

As many other PyCon conferences, everyone must buy a ticket. 
Contributors are entitled to a ticket at early bird price.

To foster diversity and to make PyConDE accessible for any pocket size,
we do have a financial support program, more details here:
https://de.pycon.org/blog/fin-aid/ <https://de.pycon.org/blog/fin-aid/>

Please familiarise yourself with the conference code of conduct 
https://de.pycon.org/code-of-conduct/ <https://de.pycon.org/code-of-conduct/>




Alexander Hendorf
@hendorf

as PyConDE & PyData Karlsruhe 2018 program chair & organiser

PyConDE & PyData Karlsruhe 2018:
https://de.pycon.org <https://de.pycon.org/>
https://twitter.com/pyconde <https://twitter.com/pyconde>



From vijayteja at eunimart.com  Mon May 28 06:13:45 2018
From: vijayteja at eunimart.com (Mutyala Veera Vijaya Teja)
Date: Mon, 28 May 2018 15:43:45 +0530
Subject: help
Message-ID: <CAJfivEeSx3_f4rWAh0o2-92Uo1RwWxyzrjiBwdRWQw2OzaqVEw@mail.gmail.com>

 Hello,
          This is vijayteja am getting an error like ssl certificate
failure when try to install packages. I've searched in the internet I've
not got any correct solution please maintain python's official blog which
contains all python issues and problems and how to solve them.

Thanks & Regards,


Mutyala Veera Vijay Teja

Software Developer

(M) +91- 8341841937

Skype ID: Veera Vijay Teja

<http://www.eunimart.com/>

[image: Facebook icon] <http://www.facebook.com/vijayteja30>[image:
LinkedIn icon] <http://www.linkedin.com/vijayteja30> [image: Twitter icon]
<https://twitter.com/eunimartltd> [image: Youtube icon]
<https://www.youtube.com/channel/UCmGtodAnLo8OeKHjgq6dBGQ>


From __peter__ at web.de  Tue May 29 02:58:56 2018
From: __peter__ at web.de (Peter Otten)
Date: Tue, 29 May 2018 08:58:56 +0200
Subject: The PIL show() method looks for the default viewer. How
 do I change this to a different viewer (of my choice)?
References: <ddedae8b-f085-dfa3-08a4-2c821975cc61@paulstgeorge.com>
 <CANDiX9+fF3ADqhee50RA47hecQRpsOVJjXML9=OAYzkAp9gNqw@mail.gmail.com>
 <0efaafaa-064f-726a-416f-9dc9d0756667@paulstgeorge.com>
 <pec4bf$3a7$1@blaine.gmane.org>
 <6d5f6b18-99ac-cc6f-8cfb-0caf23224c51@paulstgeorge.com>
Message-ID: <peitjc$jjq$1@blaine.gmane.org>

Paul St George wrote:

> This is very helpful indeed, thank you. Awe-inspiring.
> 
> It occurred to me that I could edit the PIL/ImageShow.py, replacing ?xv?
> (in five places) with the utility of my choice and using ?executable? as
> the command.
> 
> Or, is this just not done?

No, this tends to become a maintenance problem. Instead write a little 
module of your own


from PIL import ImageShow

class MyViewer(ImageShow.UnixViewer):
    def __init__(self, command):
        self.command = command
    def get_command_ex(self, file, **options):
        return (self.command,) * 2

ImageShow.register(MyViewer("gwenview"), -1)


(replace "gwenview" with your favourite viewer) and import it before using 
Image.show().



From steve+comp.lang.python at pearwood.info  Tue May 29 03:21:44 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Tue, 29 May 2018 07:21:44 +0000 (UTC)
Subject: help
References: <CAJfivEeSx3_f4rWAh0o2-92Uo1RwWxyzrjiBwdRWQw2OzaqVEw@mail.gmail.com>
Message-ID: <peiv28$q4o$11@blaine.gmane.org>

On Mon, 28 May 2018 15:43:45 +0530, Mutyala Veera Vijaya Teja wrote:

> Hello,
>           This is vijayteja am getting an error like ssl certificate
> failure when try to install packages.

You get an error *like* SSL certificate failure? Is it a secret what the 
error is? Would you like us to try to guess?

The best way to get help is to COPY AND PASTE (do not re-type from 
memory, do not paraphrase or summarise) the EXACT errors you are getting. 
We need to know *exactly* what you are trying to do (if you are using 
pip, copy and paste the EXACT pip command you are using, if something 
else, you need to tell us exactly what).

The only exception to the rule to show EXACT commands is that you should 
cross out passwords and sensitive usernames or other private data. E.g. 
if you have a password in the command, replace it with "*******".

Please do not send screen shots as this mailing list will delete them. If 
you must provide a screen shot, post it on https://imgur.com/ and send us 
the link.

But you should not need to send a screen shot. Copy and paste any command 
you are running. DO NOT take a screen shot of the command.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson



From ftg at lutix.org  Tue May 29 03:55:51 2018
From: ftg at lutix.org (ftg at lutix.org)
Date: Tue, 29 May 2018 07:55:51 +0000
Subject: String encoding in Py2.7
Message-ID: <860802c914d39f5802b2a4c0443aecc8@webmail.lutix.org>

Hello,
Using Python 2.7 (will switch to Py3 soon but Before I'd like to understand how string encoding worked)
Could you please tell me is I understood well what occurs in Python's mind:
in a .py file:
if I write s="h?h?h?", if my file is declared as unicode coding, python will store in memory s='hx82hx82hx82'
however this is not yet unicode for python interpreter this is just raw bytes. Right? 
By the way, why 'h' is not turned into hexa value? Because it is already in the ASCII table?
If I want python interpreter to recognize my string as unicode I have to declare it as unicode s=u'h?h?h?' and magically python will look for those 
hex values 'x82' in the Unicode table. Still OK?
Now: how come when I declare s='h?h?h?', print(s) displays well 'h?h?h?'? Is it because of my shell windows that is dealing well with unicode? Or is it 
because the print function is magic?

Thanks


From hjp-python at hjp.at  Tue May 29 04:15:28 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Tue, 29 May 2018 10:15:28 +0200
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <CAPTjJmo5X-+v0RG5a-3KX4NVDpd_6hyjJHmnCf7t2An8H43tGA@mail.gmail.com>
References: <mailman.8292.1233248983.3487.python-list@python.org>
 <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>
 <CANc-5Uxy8T+LKC=vw6ujxnY4K+yPpA1U7-boLXSYSeDbx8DgeQ@mail.gmail.com>
 <mailman.243.1526773687.2761.python-list@python.org>
 <27ef2bfb-e3ed-495c-bb98-f71e502d412a@googlegroups.com>
 <20180520134354.GB2192@hermes.hilbert.loc>
 <20180522212337.cvtbh32tydvaft4r@hjp.at>
 <CAPTjJmqP86iiuoXrB0r1M-7U9kM8P5Xev=mEtLwmFr5zKV45AA@mail.gmail.com>
 <20180522223103.fmym5wsmvr7vaua3@hjp.at>
 <CAPTjJmo5X-+v0RG5a-3KX4NVDpd_6hyjJHmnCf7t2An8H43tGA@mail.gmail.com>
Message-ID: <20180529081528.v7esb22ccgmksmvd@hjp.at>

On 2018-05-23 08:43:02 +1000, Chris Angelico wrote:
> On Wed, May 23, 2018 at 8:31 AM, Peter J. Holzer <hjp-python at hjp.at> wrote:
> > On 2018-05-23 07:38:27 +1000, Chris Angelico wrote:
> >> > 1) For any given file it is almost always possible to find the correct
> >> >    encoding (or *a* correct encoding, as there may be more than one).
> >>
> >> You can find an encoding which is capable of decoding a file. That's
> >> not the same thing.
> >
> > If the result is correct, it is the same thing.
> >
> > If I have an input file
> >
> >     4c 69 65 62 65 20 47 72 fc df 65 0a
> >
> > and I decode it correctly to
> >
> >     Liebe Gr??e
> >
> > it doesn't matter whether I used ISO-8859-1 or ISO-8859-2. The mapping
> > for all bytes in the input file is the same in both encodings.
> 
> Sure, but if you try it as ISO-8859-5 or  -7, you won't get an error,
> but you also won't get that string. So it DOES matter.

I get
    Liebe Gr??e
or
    Liebe Gr??e
which I can immediately recognize as wrong: They mix Cyrillic resp.
Greek letters with Latin letters in the same word which doesn't happen
in any natural language. Of course "Gr??e" could be a nickname in an
online forum (I've seen stranger names than that), but since "Liebe
Gr??e" is a common German phrase it is much much more likely to the
correct interpretation. Also, a real file will usually contain more than
two words. So if the text is German it will contain more words with
umlauts and each byte which is part of a correctly spelled German word
when interpreted according to ISO-8859-1 increases the probability that
decoding with ISO-8859-1 will produce the correct result. There remains
a tiny probability that all those matches are mere coincidence, but I
wrote "almost always", not "always", so I can live with an error rate of
0.000001% (or something like that).

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180529/78038034/attachment.sig>

From hjp-python at hjp.at  Tue May 29 04:34:50 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Tue, 29 May 2018 10:34:50 +0200
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <pe307p$d1p$1@blaine.gmane.org>
References: <mailman.8292.1233248983.3487.python-list@python.org>
 <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>
 <CANc-5Uxy8T+LKC=vw6ujxnY4K+yPpA1U7-boLXSYSeDbx8DgeQ@mail.gmail.com>
 <mailman.243.1526773687.2761.python-list@python.org>
 <27ef2bfb-e3ed-495c-bb98-f71e502d412a@googlegroups.com>
 <20180520134354.GB2192@hermes.hilbert.loc>
 <20180522212337.cvtbh32tydvaft4r@hjp.at>
 <CAPTjJmqP86iiuoXrB0r1M-7U9kM8P5Xev=mEtLwmFr5zKV45AA@mail.gmail.com>
 <20180522223103.fmym5wsmvr7vaua3@hjp.at>
 <pe307p$d1p$1@blaine.gmane.org>
Message-ID: <20180529083450.j7vzktw6tmywwkqb@hjp.at>

On 2018-05-23 06:03:38 +0000, Steven D'Aprano wrote:
> On Wed, 23 May 2018 00:31:03 +0200, Peter J. Holzer wrote:
> > On 2018-05-23 07:38:27 +1000, Chris Angelico wrote:
> >> You can find an encoding which is capable of decoding a file. That's
> >> not the same thing.
> > 
> > If the result is correct, it is the same thing.
> 
> But how do you know what is correct and what isn't? In the most general 
> case, even if you know the language nominally being used, you might not 
> be able to recognise good output from bad:
> 
>     Max Steele strained his mighty thews against his bonds, but
>     the ?-rays had left him as weak as a kitten. The evil Galactic
>     Emperor, Gi?x-??in The Terrible of the planet ?e??, laughed: "I 
>     have you now, Steele, and by this time tomorrow my armies will
>     have overrun your pitiful Earth defences!"
> 
> If this text is encoding using MacRoman, then decoded in Latin-1, it 
> works, and looks barely any more stupid than the original:
> 
>     Max Steele strained his mighty thews against his bonds, but
>     the ?-rays had left him as weak as a kitten. The evil Galactic
>     Emperor, Gi?x-??in The Terrible of the planet ?e??, laughed: "I
>     have you now, Steele, and by this time tomorrow my armies will
>     have overrun your pitiful Earth defences!"
> 
> but it clearly isn't the original text.

Please note that I wrote "almost always", not "always". It is of course
possible to construct contrived examples where it is impossible to find
the correct encoding, because all encodings lead to equally ludicrous
results.

I would still maintain that the kind of person who invents names like
this for their fanfic is also unlikely to be able to tell you what
encoding they used ("What's an encoding? I just clicked on 'Save'!").


> Mojibake is especially difficult to deal with when you are dealing with 
> short text snippets like file names or user names which can contain 
> arbitrary characters, where there is rarely any way to recognise the 
> "correct" string.

For single file names or user names, sure. But if you have a list of
them, there is still a high probability that many of them will contain
recognizable words which can be used to deduce the (or a) correct
encoding. (Unless it's from the Ministry of Silly Names).

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180529/8828191f/attachment.sig>

From tjol at tjol.eu  Tue May 29 05:09:54 2018
From: tjol at tjol.eu (Thomas Jollans)
Date: Tue, 29 May 2018 11:09:54 +0200
Subject: String encoding in Py2.7
In-Reply-To: <860802c914d39f5802b2a4c0443aecc8@webmail.lutix.org>
References: <860802c914d39f5802b2a4c0443aecc8@webmail.lutix.org>
Message-ID: <127b30dc-687c-6247-f1f4-5ce96682d830@tjol.eu>

On 2018-05-29 09:55, ftg at lutix.org wrote:
> Hello,
> Using Python 2.7 (will switch to Py3 soon but Before I'd like to understand how string encoding worked)

Oh dear. This is probably the exact wrong way to go about it: the
interplay between string encoding, unicode and bytes is much less clear
and easy to understand in Python 2.

> Could you please tell me is I understood well what occurs in Python's mind:
> in a .py file:
> if I write s="h?h?h?", if my file is declared as unicode coding, python will store in memory s='hx82hx82hx82'

No, it doesn't. At the very least, you're missing some backslashes ? and
I don't know of any character encoding that using 0x82 to encode ?.

On my system, I see

>>> s = 'h?h?h?'
>>> s
'h\xc3\xa9h\xc3\xa9h\xc3\xa9'

My system uses UTF-8. If your PC is set up to uses an encoding like ISO
8859-15 or Windows-1252, you should see

'h\xe9h\xe9h\xe9'

The \x?? are just Python notation.

> however this is not yet unicode for python interpreter this is just raw bytes. Right?

Right, this is a bunch of bytes:

>>> s
'h\xe9h\xe9h\xe9'
>>> [ord(c) for c in s]
[104, 233, 104, 233, 104, 233]
>>> [hex(ord(c)) for c in s]
['0x68', '0xe9', '0x68', '0xe9', '0x68', '0xe9']
>>>


> By the way, why 'h' is not turned into hexa value? Because it is already in the ASCII table?

That's just how Python 2 likes to display stuff.

> If I want python interpreter to recognize my string as unicode I have to declare it as unicode s=u'h?h?h?' and magically python will look for those 
> hex values 'x82' in the Unicode table. Still OK?

In principle, the unicode table has nothing to do with anything here. It
so happens that for some characters in some encodings the value is equal
to the code point, but that's neither here nor there.

> Now: how come when I declare s='h?h?h?', print(s) displays well 'h?h?h?'? Is it because of my shell windows that is dealing well with unicode? Or is it 
> because the print function is magic?

It's because the print statement is magic.

Actually, this *only* works if the encoding of your file matches the
default encoding required by your console. This is usually the case as
long as you stay on the same PC, but this assumption can fall apart
quite easily when you move code and data between systems, especially if
they use different operating systems or (human) languages.


Just use Python 3. There, the print function is not magic, which makes
life so much more logical.


-- Thomas


From hjp-python at hjp.at  Tue May 29 05:19:19 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Tue, 29 May 2018 11:19:19 +0200
Subject: Indented multi-line strings (was: "Data blocks" syntax
 specification draft)
In-Reply-To: <CALwzidnMYFyxM5cqHZVpEd4KBDx-E51Gzx2gvhMuyPgx90PD9A@mail.gmail.com>
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
 <pdu324$l8j$1@blaine.gmane.org>
 <CAHiMU6cGz=X4LMcYac=_Us0+9ATPTrJPLZaeXmK07KbnNFSP2A@mail.gmail.com>
 <CAE6NSRA9sNDkL2RgpaUnziRv5ka2j_L4y1rScKoLJSnR+KCXpg@mail.gmail.com>
 <mailman.4.1526955481.18022.python-list@python.org>
 <pe0bn1$8ns$1@dont-email.me>
 <CAE6NSRA4=wxwAWCXpJg9sXZgdDrFY5GN8_JybYg1zwgi-aYCQQ@mail.gmail.com>
 <9bf0783c8b044b348769942bda950043@F5.com>
 <20180523162535.xbtqnxi7yqv4ijlg@hjp.at>
 <CALwzidnMYFyxM5cqHZVpEd4KBDx-E51Gzx2gvhMuyPgx90PD9A@mail.gmail.com>
Message-ID: <20180529091919.xxr7rt5yoplwdge6@hjp.at>

On 2018-05-23 11:08:48 -0600, Ian Kelly wrote:
> On Wed, May 23, 2018 at 10:25 AM, Peter J. Holzer <hjp-python at hjp.at> wrote:
> > How about this?
> >
> >     x = ''''
> >         Here is a multi-line string
> >             with
> >           indentation.
> >         ''''
> >
> > This would be equivalent to
> >
> >     x = 'Here is a multi-line string\n    with\n  indentation.'
> >
> > Rules:
> >
> >  * The leading and trailing '''' must be aligned vertically.
> 
> Ick, why?

To create an unambiguous left edge.

> What's wrong with letting the trailing delimiter be at the
> end of a line, or the beginning with no indentation?

If "no indentation" means "its indentation defines the left edge", so
that 

    a_very_long_variable_name = ''''
        A string.
      ''''

is equivalent to "  A string.", I could live with that. The downside is
that the parser has to scan to the end of the string before it knows how
much whitespace to strip from each line. OTOH it makes consistent
indentation with tabs easier:

    a_very_long_variable_name = ''''
    ????????????????????????????  A string.
    ????????????????????????????''''

Are the quad-quotes aligned? It depends on how wide a tab is. (I used
???? to visualize a tab)

If "no indentation literally means no indentation, like this:

    a = foo()
    b = ''''
          A string.
''''
    c = bar()

then the reason for not allowing this is that it subverts the reason for
proposing this feature (to have multiline strings which nicely align
with the indentation of the code and don't stick out to the left like a
sore thumb). 

Similarily, if "no indentation" means "no additional indentation
relative to the surrounding code", then reason is that in a multiline
statement, the continuation lines should be indented more than the first
line (seep PEP 8).

The trailing delimiter could be at the end of the line to signify that
there is no newline at the end of the string:

    s = ''''
          A string.''''
    t = ''''
          A string.
        ''''

would then be equivalent to 

    s = '  A string.'
    t = '  A string.\n'

Then the indentation of the first delimiter alone determines how much
white space is stripped. I think this looks untidy, though, and my rule
4 is more symmetrical.


> >  * The contents of the string must be indented at least as far as the
> >    delimiters (and with consistent tabs/spaces).
> >    This leading white space is ignored.
> >  * All the leading white space beyond this 'left edge' is preserved.
> >  * The newlines after the leading '''' and before the trailing '''' are
> >    ignored, all the others preserved. (I thought about preserving the
> >    trailing newline, but it is easier to add one than remove one.)
> 
> How about we instead just use the rules from PEP 257 so that there
> aren't two different sets of multi-line string indentation rules to
> have to remember?
> 
> https://www.python.org/dev/peps/pep-0257/#handling-docstring-indentation

These rules are nice for a specific application, but I think they are
too ad-hoc and not general enough for a language feature which should be
able to represent arbitrary strings.

In particular:

| will strip a uniform amount of indentation from the second and further
| lines of the docstring, equal to the minimum indentation of all
| non-blank lines after the first line

What if I want all lines to start with some white space? 

|  Any indentation in the first line of the docstring (i.e., up to the
|  first newline) is insignificant and removed.

What if I want the string to start with white space?

|  Blank lines should be removed from the beginning and end of the
|  docstring.

What if I want leading or trailing blank lines?


> Also, how about using a string prefix character instead of making
> quad-quote meaningful? Apart from being hard to visually distinguish
> from triple-quote, this would break existing triple-quote strings that
> happen to start with the quote character, e.g ''''What?' she asked.'''

No confusion here, since in my proposal there is always a newline after
the leading delimiter, since otherwise the first line wouldn't line up
with the rest. So the parser would notice that this is a triple-quote
and not a quad-quote as soon as it sees the "W". 

A prefix might still be a good idea, but .. see below.


> I don't know if 'i' would be the right prefix character for this, but
> it's unused and is short for 'indented':

'i' is fine by me.

> b = i'''
>     Here is a multi-line string
>     with indentation, which is
>     determined from the second
>     line.'''

Visually, that letter doesn't look like a part of the quote, so I would
like to pull the contents of the string over to align with the quote:

b = i'''
     Here is a multi-line string
     with indentation, which is
     determined from the second
     line.'''

But that creates an ambiguity: Is the whole string now indented one
space or not? Where is the left edge?

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180529/64f38f59/attachment.sig>

From fabienluce at gmail.com  Tue May 29 05:19:52 2018
From: fabienluce at gmail.com (Fabien LUCE)
Date: Tue, 29 May 2018 09:19:52 +0000
Subject: String encoding in Py2.7
In-Reply-To: <127b30dc-687c-6247-f1f4-5ce96682d830@tjol.eu>
References: <127b30dc-687c-6247-f1f4-5ce96682d830@tjol.eu>
 <860802c914d39f5802b2a4c0443aecc8@webmail.lutix.org>
Message-ID: <f55371ce385b6119c640d5d2139b2b66@webmail.lutix.org>

May 29 2018 11:12 AM, "Thomas Jollans" <tjol at tjol.eu> wrote:
> On 2018-05-29 09:55, ftg at lutix.org wrote:
> 
>> Hello,
>> Using Python 2.7 (will switch to Py3 soon but Before I'd like to understand how string encoding
>> worked)
> 
> Oh dear. This is probably the exact wrong way to go about it: the
> interplay between string encoding, unicode and bytes is much less clear
> and easy to understand in Python 2.

Ok I will quickly jump into py3 then.

> 
>> Could you please tell me is I understood well what occurs in Python's mind:
>> in a .py file:
>> if I write s="h?h?h?", if my file is declared as unicode coding, python will store in memory
>> s='hx82hx82hx82'
> 
> No, it doesn't. At the very least, you're missing some backslashes ? and
> I don't know of any character encoding that using 0x82 to encode ?.
> 
 surprinsingly backslash were removed from my initial text...
ok so stored raw bytes are the one processed by the system encoder. If my console were utf-8 I would have same raw bytes string than you. 
  

> On my system, I see
> 
>>>> s = 'h?h?h?'
>>>> s
> 
> 'h\xc3\xa9h\xc3\xa9h\xc3\xa9'
> 
> My system uses UTF-8. If your PC is set up to uses an encoding like ISO
> 8859-15 or Windows-1252, you should see
> 
> 'h\xe9h\xe9h\xe9'
> 
> The \x?? are just Python notation.
> 
>> however this is not yet unicode for python interpreter this is just raw bytes. Right?
> 
> Right, this is a bunch of bytes:
> 
>>>> s
> 
> 'h\xe9h\xe9h\xe9'
> 
>>>> [ord(c) for c in s]
> 
> [104, 233, 104, 233, 104, 233]
> 
>>>> [hex(ord(c)) for c in s]
> 
> ['0x68', '0xe9', '0x68', '0xe9', '0x68', '0xe9']
> 
>>>> 
>> 
>> By the way, why 'h' is not turned into hexa value? Because it is already in the ASCII table?
> 
> That's just how Python 2 likes to display stuff.
> 
>> If I want python interpreter to recognize my string as unicode I have to declare it as unicode
>> s=u'h?h?h?' and magically python will look for those
>> hex values 'x82' in the Unicode table. Still OK?
> 
> In principle, the unicode table has nothing to do with anything here. It
> so happens that for some characters in some encodings the value is equal
> to the code point, but that's neither here nor there.
> 
>> Now: how come when I declare s='h?h?h?', print(s) displays well 'h?h?h?'? Is it because of my shell
>> windows that is dealing well with unicode? Or is it
>> because the print function is magic?
> 
> It's because the print statement is magic.
> 
> Actually, this *only* works if the encoding of your file matches the
> default encoding required by your console. This is usually the case as
> long as you stay on the same PC, but this assumption can fall apart
> quite easily when you move code and data between systems, especially if
> they use different operating systems or (human) languages.
> 
> Just use Python 3. There, the print function is not magic, which makes
> life so much more logical.

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


From hjp-python at hjp.at  Tue May 29 05:27:24 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Tue, 29 May 2018 11:27:24 +0200
Subject: how to handle captcha through machanize module  or any module
In-Reply-To: <85po1lkjot.fsf@benfinney.id.au>
References: <2b488aa4-5698-4be8-b272-7f93c49d154c@googlegroups.com>
 <85po1lkjot.fsf@benfinney.id.au>
Message-ID: <20180529092724.z32ajsm6tcj44thl@hjp.at>

On 2018-05-24 09:59:14 +1000, Ben Finney wrote:
> If you are attempting to fool a CAPTCHA with an automated tool, you are
> entering an arms race against those who design the CAPTCHA to *prevent*
> exactly what you're doing.
> 
> Any technique someone can describe to fool the CAPTCHA, will most likely
> already be considered as part of the design of the more effective
> CAPTCHAs, and so the technique will still not actually work reliably.

And any technique that someone can describe to fool programs will most
likely already be considered by those who write programs to break
captchas, and so the technique will still not actually work reliably.


> So, there is no general answer, other than to stop thinking that's a
> race that you can win.

I agree that there is no *general* answer. For any specific captcha,
there probably is a way to break it automatically, and possibly with
higher reliability than a human can (many captchas are hard and
frustrating for humans).

It *is* an arms race and who wins depends on who where to break-even
point between effort and value is for the defender and the attacker.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180529/0a9c2af2/attachment.sig>

From rosuav at gmail.com  Tue May 29 05:46:24 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 29 May 2018 19:46:24 +1000
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <20180529081528.v7esb22ccgmksmvd@hjp.at>
References: <mailman.8292.1233248983.3487.python-list@python.org>
 <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>
 <CANc-5Uxy8T+LKC=vw6ujxnY4K+yPpA1U7-boLXSYSeDbx8DgeQ@mail.gmail.com>
 <mailman.243.1526773687.2761.python-list@python.org>
 <27ef2bfb-e3ed-495c-bb98-f71e502d412a@googlegroups.com>
 <20180520134354.GB2192@hermes.hilbert.loc>
 <20180522212337.cvtbh32tydvaft4r@hjp.at>
 <CAPTjJmqP86iiuoXrB0r1M-7U9kM8P5Xev=mEtLwmFr5zKV45AA@mail.gmail.com>
 <20180522223103.fmym5wsmvr7vaua3@hjp.at>
 <CAPTjJmo5X-+v0RG5a-3KX4NVDpd_6hyjJHmnCf7t2An8H43tGA@mail.gmail.com>
 <20180529081528.v7esb22ccgmksmvd@hjp.at>
Message-ID: <CAPTjJmrqoLWToz+7w8qEuFKS7xaVAr4tjC6j5fHGDhkjDuZQuw@mail.gmail.com>

On Tue, May 29, 2018 at 6:15 PM, Peter J. Holzer <hjp-python at hjp.at> wrote:
> So if the text is German it will contain more words with
> umlauts and each byte which is part of a correctly spelled German word
> when interpreted according to ISO-8859-1 increases the probability that
> decoding with ISO-8859-1 will produce the correct result. There remains
> a tiny probability that all those matches are mere coincidence, but I
> wrote "almost always", not "always", so I can live with an error rate of
> 0.000001% (or something like that).

That's basically what the chardet module does, and its error rate is
far FAR higher than that. If you think it's easy to detect encodings,
I'm sure the chardet maintainers will be happy to accept pull
requests!

ChrisA


From rosuav at gmail.com  Tue May 29 05:47:37 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 29 May 2018 19:47:37 +1000
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <20180529083450.j7vzktw6tmywwkqb@hjp.at>
References: <mailman.8292.1233248983.3487.python-list@python.org>
 <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>
 <CANc-5Uxy8T+LKC=vw6ujxnY4K+yPpA1U7-boLXSYSeDbx8DgeQ@mail.gmail.com>
 <mailman.243.1526773687.2761.python-list@python.org>
 <27ef2bfb-e3ed-495c-bb98-f71e502d412a@googlegroups.com>
 <20180520134354.GB2192@hermes.hilbert.loc>
 <20180522212337.cvtbh32tydvaft4r@hjp.at>
 <CAPTjJmqP86iiuoXrB0r1M-7U9kM8P5Xev=mEtLwmFr5zKV45AA@mail.gmail.com>
 <20180522223103.fmym5wsmvr7vaua3@hjp.at> <pe307p$d1p$1@blaine.gmane.org>
 <20180529083450.j7vzktw6tmywwkqb@hjp.at>
Message-ID: <CAPTjJmoc2Tbu3ii3=1m5x3HQho-59y7EYZTGD9NZkOLMBGzmSQ@mail.gmail.com>

On Tue, May 29, 2018 at 6:34 PM, Peter J. Holzer <hjp-python at hjp.at> wrote:
> On 2018-05-23 06:03:38 +0000, Steven D'Aprano wrote:
>> Mojibake is especially difficult to deal with when you are dealing with
>> short text snippets like file names or user names which can contain
>> arbitrary characters, where there is rarely any way to recognise the
>> "correct" string.
>
> For single file names or user names, sure. But if you have a list of
> them, there is still a high probability that many of them will contain
> recognizable words which can be used to deduce the (or a) correct
> encoding. (Unless it's from the Ministry of Silly Names).

Ohh... are you assuming that, in a list of file names, all of them use
the same encoding? Ah, yes, well, that WOULD make it easier, wouldn't
it. Sadly, not the case.

ChrisA


From hjp-python at hjp.at  Tue May 29 05:50:50 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Tue, 29 May 2018 11:50:50 +0200
Subject: The PIL show() method looks for the default viewer. How do I
 change this to a different viewer (of my choice)?
In-Reply-To: <peg0sn$46i$1@dont-email.me>
References: <6d5f6b18-99ac-cc6f-8cfb-0caf23224c51@paulstgeorge.com>
 <20180527215836.GA6330@cskk.homeip.net>
 <mailman.19.1527458326.2804.python-list@python.org>
 <peg0sn$46i$1@dont-email.me>
Message-ID: <20180529095050.eodfzju6miyuuyi6@hjp.at>

On 2018-05-28 06:34:30 +0200, Christian Gollwitzer wrote:
> I think this is a bug/misfeature in the PIL code. On all 3 major platforms
> there is a way to invoke the standard program for a given file or URL. On
> Windows, it is "cmd.exe /c start ...", on OSX it is "open ...." and on Linux
> it is "xdg-open ...". That way the file is opened by whatever the user has
> set in his desktop environment.
> 
> Technically, xdg-open needs not to be present on Linux, though it is usually
> installed.

xv and display don't need to be installed either. In fact, xv is
unlikely to be installed (it's non-free (shareware) and hasn't been
maintained in ages[1]). Display is part of imagemagick, which is also
optional (though quite likely to be installed - among other things CUPS
depends on it). And display isn't very useful either (for example, there
doesn't seem to be a way to scale down large images to the size of the
display).

OTOH, xdg-open is part of the free desktop specification, so if you have
any kind of linux desktop, it is very probable that you have xdg-open
and that it is reasonably configured.

I agree that show should call xdg-open preferentially and maybe fall
back to display. And of course silently ignoring a documented parameter
is clearly a bug (if it's true - I notice that the Pillow docs don't mention
that parameter and the original PIL seems to unmaintained).

        hp

[1] Which is a pity, because I loved it.


-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180529/5586ad36/attachment.sig>

From rosuav at gmail.com  Tue May 29 06:01:41 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 29 May 2018 20:01:41 +1000
Subject: String encoding in Py2.7
In-Reply-To: <860802c914d39f5802b2a4c0443aecc8@webmail.lutix.org>
References: <860802c914d39f5802b2a4c0443aecc8@webmail.lutix.org>
Message-ID: <CAPTjJmrUd+CAummk5QcwicJ19+ro2ei572-GaWrRP3Cm7j_iig@mail.gmail.com>

On Tue, May 29, 2018 at 5:55 PM,  <ftg at lutix.org> wrote:
> Hello,
> Using Python 2.7 (will switch to Py3 soon but Before I'd like to understand how string encoding worked)
> Could you please tell me is I understood well what occurs in Python's mind:
> in a .py file:
> if I write s="h?h?h?", if my file is declared as unicode coding, python will store in memory s='hx82hx82hx82'
> however this is not yet unicode for python interpreter this is just raw bytes. Right?
> By the way, why 'h' is not turned into hexa value? Because it is already in the ASCII table?
> If I want python interpreter to recognize my string as unicode I have to declare it as unicode s=u'h?h?h?' and magically python will look for those
> hex values 'x82' in the Unicode table. Still OK?
> Now: how come when I declare s='h?h?h?', print(s) displays well 'h?h?h?'? Is it because of my shell windows that is dealing well with unicode? Or is it
> because the print function is magic?

What actually happens is this:

1) Your file contains bytes. Hopefully, your editor will follow the
same encoding that you've declared for your file, but that's not
guaranteed.
2) The string contains bytes. If you ask for the representation of
that string, some of them will be shown as characters, but that 'h' is
exactly the same as "\x68".
3) Printing that string sends those bytes to your console.

If EVERYTHING is using the exact same encoding, it all appears to work
correctly. But if your editor saves the file as UTF-8 and your console
is set to Codepage 1252, you'll get a nonsense.

When you use the u-prefix string literal, here's what happens:

1) As above, your file contains bytes, hopefully in the encoding that
you've declared.
2) The Python interpreter reads those bytes using the encoding you
declared. The string contains Unicode characters.
3) Those characters really are characters. They are LATIN SMALL LETTER
H and LATIN SMALL LETTER E WITH ACUTE.
4) Printing that string causes those characters to be sent to your
console in the best way possible for Unicode characters (Python and
the console can negotiate that between them).

If you switch to Python 3 and remove the file's encoding declaration,
here's what happens:

1) Your file contains bytes. Your editor should use UTF-8 because it's
the most logical default; check for this but it's probably going to
happen without any effort.
2) The Python interpreter reads those bytes and understands them as
UTF-8. Your string, like all your source code, contains Unicode
characters.
3) As in the second case, you have those two characters.
4) As above, Python and the console negotiate the best way to display text.

It's a LOT easier. All you have to do is make sure everything's using
UTF-8, and then the defaults will just work. For most text editors,
you don't need to think about this at all, because they're already
configured that way.

As a bonus: Since, in Python 3, *all* your source code is Unicode
text, you can actually switch things around.

>>> s="h?h?h?"
>>> h?h?h?="s"
>>> print(s)
h?h?h?
>>> print(h?h?h?)
s

Yep, that's non-ASCII letters in a variable name. Doesn't bother
Python 3 at all!

ChrisA


From hjp-python at hjp.at  Tue May 29 06:02:58 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Tue, 29 May 2018 12:02:58 +0200
Subject: cProfile, timed call tree
In-Reply-To: <87in7b3rjy.fsf@handshake.de>
References: <CAK6Z60du+GX5iUmjfFQZz4bxSKifUQZ8hAa4vGf8qFTsOtaOXg@mail.gmail.com>
 <87in7b3rjy.fsf@handshake.de>
Message-ID: <20180529100258.4wpn2gexmjfhtw5u@hjp.at>

On 2018-05-26 07:38:09 +0200, dieter wrote:
> But, in general, you are right: you cannot reconstruct complete
> call trees. The reason is quite simple: maintaining information
> for the complete caller ancestry (rather than just the immediate
> caller) is expensive (both in terms of runtime and storage).
> Profiling usually is used as a preparation for optimization.
> Optimization has the greatest effects if applied to inner loops.
> And for the analysis of inner loops, complete call tree information
> is not necessary.

I disagree. I have used Tim Bunce's excellent perl profiler
(Devel::NYTProf, for the two people here who also use Perl and don't
already know it), which does record whole call trees, and this is very
useful. You not only see that a function is called 1.5 million times,
you also see where it is called (not just from which functions, but from
which lines) and how much time is spent in calls from each location. 
Often this allowed me find ways to avoid calling a function altogether
or prevented me from chasing down the wrong rabbit hole.

Sometimes it is also useful to find out how your code works, when you
get back to it after a few months ;-).

        hp


-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180529/ee859b3b/attachment.sig>

From valerio.maggio at gmail.com  Tue May 29 06:04:42 2018
From: valerio.maggio at gmail.com (Valerio Maggio)
Date: Tue, 29 May 2018 12:04:42 +0200
Subject: ANN: EuroScipy 2018
Message-ID: <CAEt-TDwMG=T-wiaDaYtf9EMj181U_wvotB1D2YaJZsCvowmEaw@mail.gmail.com>

*** Apologies if you receive multiple copies ***

Dear Colleagues,

We are delighted to invite you to join us for the
**11th European Conference on Python in Science**.

The EuroSciPy 2018 (https://www.euroscipy.org/2018/) Conference
will be organised by Fondazione Bruno Kessler (FBK)
and will take place from August 28 to September 1 in **Trento, Italy**.

The EuroSciPy meeting is a cross-disciplinary gathering focused on the use
and
development of the Python language in scientific research.
This event strives to bring together both users and developers of
scientific tools, as well as academic research and state of the art
industry.

The conference will be structured as it follows:
Aug, 28-29 : Tutorials and Hands-on
Aug, 30-31 : Main Conference
Sep, 1     : Sprint


TOPICS OF INTEREST:
===================

Presentations of scientific tools and libraries using the Python language,
including but not limited to:
- Algorithms implemented or exposed in Python
- Astronomy
- Data Visualisation
- Deep Learning & AI
- Earth, Ocean and Geo Science
- General-purpose Python tools that can be of special interest to the
scientific community.
- Image Processing
- Materials Science
- Parallel computing
- Political and Social Sciences
- Project Jupyter
- Reports on the use of Python in scientific achievements or ongoing
projects.
- Robotics & IoT
- Scientific data flow and persistence
- Scientific visualization
- Simulation
- Statistics
- Vector and array manipulation
- Web applications and portals for science and engineering
- 3D Printing


CALL FOR PROPOSALS:
===================

EuroScipy will accept three different kinds of contributions:

* Regular Talks: standard talks for oral presentations, allocated in time
slots of 15, or 30 minutes, depending on your preference and scheduling
constraints. Each time slot considers a Q&A session at the end of the talk
(at least, 5 mins).

* Hands-on Tutorials: These are beginner or advanced training sessions to
dive
into the subject with all details. These sessions are 90 minutes long,
and the audience will be strongly encouraged to bring a laptop to
experiment.

* Poster: EuroScipy will host two poster sessions during the two days of
Main Conference. So attendees and students are highly encourage to present
their work and/or preliminary results as posters.

Proposals should be submitted using the EuroScipy submission system at
https://pretalx.com/euroscipy18.

**Submission deadline is May, 31st 2018**.


REGISTRATION & FEES:
====================

To register to EuroScipy 2018, please go to
http://euroscipy2018.eventbrite.co.uk or to http://www.euroscipy.org/2018/

Fees:
-----

| Tutorials                   | Student*  | Academic/Individual | Industry|
|-----------------------------|----------|---------------------|----------|
| Early Bird (till July, 1st) | ? 50,00  | ? 70,00             | ? 125,00 |
| Regular (till Aug, 5th      | ? 100,00 | ? 110,00            | ? 250,00 |
| Late (till Aug, 22nd)       | ? 135,00 | ? 135,00            | ? 300,00 |


| Main Conference             | Student*  | Academic/Individual | Industry|
|-----------------------------|----------|---------------------|----------|
| Early Bird (till July, 1st) | ? 50,00  | ? 70,00             | ? 125,00 |
| Regular (till Aug, 5th      | ? 100,00 | ? 110,00            | ? 250,00 |
| Late (till Aug, 22nd)       | ? 135,00 | ? 135,00            | ? 300,00 |

* A proof of student status will be required at time of the registration.


kind regards,
Valerio

EuroScipy 2018 Organising Committee,
Email: info at euroscipy.org
Website: http://www.euroscipy.org/2018
twitter: @euroscipy


From hjp-python at hjp.at  Tue May 29 06:09:18 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Tue, 29 May 2018 12:09:18 +0200
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <CAPTjJmrqoLWToz+7w8qEuFKS7xaVAr4tjC6j5fHGDhkjDuZQuw@mail.gmail.com>
References: <CANc-5Uxy8T+LKC=vw6ujxnY4K+yPpA1U7-boLXSYSeDbx8DgeQ@mail.gmail.com>
 <mailman.243.1526773687.2761.python-list@python.org>
 <27ef2bfb-e3ed-495c-bb98-f71e502d412a@googlegroups.com>
 <20180520134354.GB2192@hermes.hilbert.loc>
 <20180522212337.cvtbh32tydvaft4r@hjp.at>
 <CAPTjJmqP86iiuoXrB0r1M-7U9kM8P5Xev=mEtLwmFr5zKV45AA@mail.gmail.com>
 <20180522223103.fmym5wsmvr7vaua3@hjp.at>
 <CAPTjJmo5X-+v0RG5a-3KX4NVDpd_6hyjJHmnCf7t2An8H43tGA@mail.gmail.com>
 <20180529081528.v7esb22ccgmksmvd@hjp.at>
 <CAPTjJmrqoLWToz+7w8qEuFKS7xaVAr4tjC6j5fHGDhkjDuZQuw@mail.gmail.com>
Message-ID: <20180529100918.pymciog6ahuronan@hjp.at>

On 2018-05-29 19:46:24 +1000, Chris Angelico wrote:
> On Tue, May 29, 2018 at 6:15 PM, Peter J. Holzer <hjp-python at hjp.at> wrote:
> > So if the text is German it will contain more words with
> > umlauts and each byte which is part of a correctly spelled German word
> > when interpreted according to ISO-8859-1 increases the probability that
> > decoding with ISO-8859-1 will produce the correct result. There remains
> > a tiny probability that all those matches are mere coincidence, but I
> > wrote "almost always", not "always", so I can live with an error rate of
> > 0.000001% (or something like that).
> 
> That's basically what the chardet module does, and its error rate is
> far FAR higher than that. If you think it's easy to detect encodings,
> I'm sure the chardet maintainers will be happy to accept pull
> requests!

We were talking about humans, not programs.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180529/5ba613d1/attachment.sig>

From hjp-python at hjp.at  Tue May 29 06:17:23 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Tue, 29 May 2018 12:17:23 +0200
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <CAPTjJmoc2Tbu3ii3=1m5x3HQho-59y7EYZTGD9NZkOLMBGzmSQ@mail.gmail.com>
References: <CANc-5Uxy8T+LKC=vw6ujxnY4K+yPpA1U7-boLXSYSeDbx8DgeQ@mail.gmail.com>
 <mailman.243.1526773687.2761.python-list@python.org>
 <27ef2bfb-e3ed-495c-bb98-f71e502d412a@googlegroups.com>
 <20180520134354.GB2192@hermes.hilbert.loc>
 <20180522212337.cvtbh32tydvaft4r@hjp.at>
 <CAPTjJmqP86iiuoXrB0r1M-7U9kM8P5Xev=mEtLwmFr5zKV45AA@mail.gmail.com>
 <20180522223103.fmym5wsmvr7vaua3@hjp.at>
 <pe307p$d1p$1@blaine.gmane.org>
 <20180529083450.j7vzktw6tmywwkqb@hjp.at>
 <CAPTjJmoc2Tbu3ii3=1m5x3HQho-59y7EYZTGD9NZkOLMBGzmSQ@mail.gmail.com>
Message-ID: <20180529101723.6phaeqqxn4vxtq7c@hjp.at>

On 2018-05-29 19:47:37 +1000, Chris Angelico wrote:
> On Tue, May 29, 2018 at 6:34 PM, Peter J. Holzer <hjp-python at hjp.at> wrote:
> > On 2018-05-23 06:03:38 +0000, Steven D'Aprano wrote:
> >> Mojibake is especially difficult to deal with when you are dealing with
> >> short text snippets like file names or user names which can contain
> >> arbitrary characters, where there is rarely any way to recognise the
> >> "correct" string.
> >
> > For single file names or user names, sure. But if you have a list of
> > them, there is still a high probability that many of them will contain
> > recognizable words which can be used to deduce the (or a) correct
> > encoding. (Unless it's from the Ministry of Silly Names).
> 
> Ohh... are you assuming that, in a list of file names, all of them use
> the same encoding? Ah, yes, well, that WOULD make it easier, wouldn't
> it. Sadly, not the case.

Not in general, but it *IS* the case we were talking about here. The
task is to find *an* encoding which can be used to decode *a* file. This
of course assumes that such an encoding exists. If there are several
encodings in the same file (I use "file" loosely here), then there is no
single encoding which can be used to decode it, so the task is
impossible. (You may still be able to split the file into chunks where
each chunk uses a specific encoding and determine that, but this is a
different task - and one for which the solution "ask the source" is even
less likely to work.)

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180529/9111a6c8/attachment.sig>

From rosuav at gmail.com  Tue May 29 06:28:54 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 29 May 2018 20:28:54 +1000
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <20180529100918.pymciog6ahuronan@hjp.at>
References: <CANc-5Uxy8T+LKC=vw6ujxnY4K+yPpA1U7-boLXSYSeDbx8DgeQ@mail.gmail.com>
 <mailman.243.1526773687.2761.python-list@python.org>
 <27ef2bfb-e3ed-495c-bb98-f71e502d412a@googlegroups.com>
 <20180520134354.GB2192@hermes.hilbert.loc>
 <20180522212337.cvtbh32tydvaft4r@hjp.at>
 <CAPTjJmqP86iiuoXrB0r1M-7U9kM8P5Xev=mEtLwmFr5zKV45AA@mail.gmail.com>
 <20180522223103.fmym5wsmvr7vaua3@hjp.at>
 <CAPTjJmo5X-+v0RG5a-3KX4NVDpd_6hyjJHmnCf7t2An8H43tGA@mail.gmail.com>
 <20180529081528.v7esb22ccgmksmvd@hjp.at>
 <CAPTjJmrqoLWToz+7w8qEuFKS7xaVAr4tjC6j5fHGDhkjDuZQuw@mail.gmail.com>
 <20180529100918.pymciog6ahuronan@hjp.at>
Message-ID: <CAPTjJmpnQmkcZESGnK=micKbZz4t8UA4BvpZdChkWbcEArvPvQ@mail.gmail.com>

On Tue, May 29, 2018 at 8:09 PM, Peter J. Holzer <hjp-python at hjp.at> wrote:
> On 2018-05-29 19:46:24 +1000, Chris Angelico wrote:
>> On Tue, May 29, 2018 at 6:15 PM, Peter J. Holzer <hjp-python at hjp.at> wrote:
>> > So if the text is German it will contain more words with
>> > umlauts and each byte which is part of a correctly spelled German word
>> > when interpreted according to ISO-8859-1 increases the probability that
>> > decoding with ISO-8859-1 will produce the correct result. There remains
>> > a tiny probability that all those matches are mere coincidence, but I
>> > wrote "almost always", not "always", so I can live with an error rate of
>> > 0.000001% (or something like that).
>>
>> That's basically what the chardet module does, and its error rate is
>> far FAR higher than that. If you think it's easy to detect encodings,
>> I'm sure the chardet maintainers will be happy to accept pull
>> requests!
>
> We were talking about humans, not programs.
>

Sure, but you're describing a set of rules. If you can define a set of
rules that pin down the encoding, you could teach chardet to follow
those rules. If you can't teach chardet to follow those rules, you
can't teach a human to follow them either. What is the human going to
do? Guess?

ChrisA


From steve+comp.lang.python at pearwood.info  Tue May 29 06:39:54 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Tue, 29 May 2018 10:39:54 +0000 (UTC)
Subject: String encoding in Py2.7
References: <127b30dc-687c-6247-f1f4-5ce96682d830@tjol.eu>
 <860802c914d39f5802b2a4c0443aecc8@webmail.lutix.org>
 <f55371ce385b6119c640d5d2139b2b66@webmail.lutix.org>
Message-ID: <pejalq$q4o$12@blaine.gmane.org>

On Tue, 29 May 2018 09:19:52 +0000, Fabien LUCE wrote:

> May 29 2018 11:12 AM, "Thomas Jollans" <tjol at tjol.eu> wrote:
>> On 2018-05-29 09:55, ftg at lutix.org wrote:
>> 
>>> Hello,
>>> Using Python 2.7 (will switch to Py3 soon but Before I'd like to
>>> understand how string encoding worked)
>> 
>> Oh dear. This is probably the exact wrong way to go about it: the
>> interplay between string encoding, unicode and bytes is much less clear
>> and easy to understand in Python 2.
> 
> Ok I will quickly jump into py3 then.

Why I applaud this decision -- the latest Python 3.x series is much 
better than 2.7 -- please don't imagine that moving to Python 3 will 
eliminate all encoding issues, especially when dealing with real-world 
data that comes to you in a mix of weird and often broken encodings.

Python 3 eliminates one common source of problems: unlike Python 2, it 
won't try to guess what you mean when you combines bytes and Unicode 
text. In Python 2, that worked for the simple cases, and was often 
convenient, but at the cost of leading to hard to diagnose and hard to 
fix errors in the complex cases. Python 3 no longer guesses, which means 
you have to be more diligent in converting bytes to text and vice versa.

Also, it has to be said that Python 3 makes one use-case harder: mixed 
binary bytes plus ASCII text. (Or so I've been told.)

But for the common case where you have human readable text in Unicode, 
and machine readable bytes in hex bytes, and can keep them separate, 
Python 3 is much better.

I recommend you start with reading these if you haven't already:

https://nedbatchelder.com/text/unipain.html

https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-
software-developer-absolutely-positively-must-know-about-unicode-and-
character-sets-no-excuses/

Sorry for the huge URL, try this if your mail client breaks it: 
https://tinyurl.com/h8yg9d7




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson



From rosuav at gmail.com  Tue May 29 06:48:03 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 29 May 2018 20:48:03 +1000
Subject: String encoding in Py2.7
In-Reply-To: <pejalq$q4o$12@blaine.gmane.org>
References: <127b30dc-687c-6247-f1f4-5ce96682d830@tjol.eu>
 <860802c914d39f5802b2a4c0443aecc8@webmail.lutix.org>
 <f55371ce385b6119c640d5d2139b2b66@webmail.lutix.org>
 <pejalq$q4o$12@blaine.gmane.org>
Message-ID: <CAPTjJmq6_jyvDG4QO2b7eLvPAnJrvpcOriV-sHNeiqH-LXZj5A@mail.gmail.com>

On Tue, May 29, 2018 at 8:39 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Tue, 29 May 2018 09:19:52 +0000, Fabien LUCE wrote:
>
>> May 29 2018 11:12 AM, "Thomas Jollans" <tjol at tjol.eu> wrote:
>>> On 2018-05-29 09:55, ftg at lutix.org wrote:
>>>
>>>> Hello,
>>>> Using Python 2.7 (will switch to Py3 soon but Before I'd like to
>>>> understand how string encoding worked)
>>>
>>> Oh dear. This is probably the exact wrong way to go about it: the
>>> interplay between string encoding, unicode and bytes is much less clear
>>> and easy to understand in Python 2.
>>
>> Ok I will quickly jump into py3 then.
>
> Why I applaud this decision -- the latest Python 3.x series is much
> better than 2.7 -- please don't imagine that moving to Python 3 will
> eliminate all encoding issues, especially when dealing with real-world
> data that comes to you in a mix of weird and often broken encodings.
>
> Python 3 eliminates one common source of problems: unlike Python 2, it
> won't try to guess what you mean when you combines bytes and Unicode
> text. In Python 2, that worked for the simple cases, and was often
> convenient, but at the cost of leading to hard to diagnose and hard to
> fix errors in the complex cases. Python 3 no longer guesses, which means
> you have to be more diligent in converting bytes to text and vice versa.

Python 3 eliminates a number of common sources of problems; in fact,
it eliminates a large number of problems. But you're right that it's
no panacea, since there cannot ever be a perfect solution.

> Also, it has to be said that Python 3 makes one use-case harder: mixed
> binary bytes plus ASCII text. (Or so I've been told.)

Early versions of Py3 yes, but the latest versions have had features
added that restore this to its Py2 simplicity (for ASCII
specifically).

ChrisA


From hjp-python at hjp.at  Tue May 29 06:59:29 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Tue, 29 May 2018 12:59:29 +0200
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <CAPTjJmpnQmkcZESGnK=micKbZz4t8UA4BvpZdChkWbcEArvPvQ@mail.gmail.com>
References: <27ef2bfb-e3ed-495c-bb98-f71e502d412a@googlegroups.com>
 <20180520134354.GB2192@hermes.hilbert.loc>
 <20180522212337.cvtbh32tydvaft4r@hjp.at>
 <CAPTjJmqP86iiuoXrB0r1M-7U9kM8P5Xev=mEtLwmFr5zKV45AA@mail.gmail.com>
 <20180522223103.fmym5wsmvr7vaua3@hjp.at>
 <CAPTjJmo5X-+v0RG5a-3KX4NVDpd_6hyjJHmnCf7t2An8H43tGA@mail.gmail.com>
 <20180529081528.v7esb22ccgmksmvd@hjp.at>
 <CAPTjJmrqoLWToz+7w8qEuFKS7xaVAr4tjC6j5fHGDhkjDuZQuw@mail.gmail.com>
 <20180529100918.pymciog6ahuronan@hjp.at>
 <CAPTjJmpnQmkcZESGnK=micKbZz4t8UA4BvpZdChkWbcEArvPvQ@mail.gmail.com>
Message-ID: <20180529105929.xebyilz4mgsl42ar@hjp.at>

On 2018-05-29 20:28:54 +1000, Chris Angelico wrote:
> On Tue, May 29, 2018 at 8:09 PM, Peter J. Holzer <hjp-python at hjp.at> wrote:
> > On 2018-05-29 19:46:24 +1000, Chris Angelico wrote:
> >> That's basically what the chardet module does, and its error rate is
> >> far FAR higher than that. If you think it's easy to detect encodings,
> >> I'm sure the chardet maintainers will be happy to accept pull
> >> requests!
> >
> > We were talking about humans, not programs.
> >
> 
> Sure, but you're describing a set of rules. If you can define a set of
> rules that pin down the encoding, you could teach chardet to follow
> those rules. If you can't teach chardet to follow those rules, you
> can't teach a human to follow them either. What is the human going to
> do? Guess?

Xkcd to the rescue:

https://xkcd.com/1425/

There are a lot of things which are easy to do for a human (recognize a
bird, understand a sentence), but very hard to write a program for
(mostly because we don't understand how our brain works, I think).

I haven't looked in detail on how chardet works but it looks like has a
few simple statistical models for the probability of characters and
character sequences. This is very different from what a human does, who
a) recognises whole words, and b) knows what they mean and whether they
make sense in context.

For a sufficiently narrow range of texts, you can write a program which
is better at recognizing encoding or language than any human can (As an
obvious improvement to chardet, you could supply it with dictionaries of
all languages). However, in the general case that would need a strong
AI. And we aren't there yet, by far.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180529/adf7dcdd/attachment.sig>

From rosuav at gmail.com  Tue May 29 07:13:43 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 29 May 2018 21:13:43 +1000
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <20180529105929.xebyilz4mgsl42ar@hjp.at>
References: <27ef2bfb-e3ed-495c-bb98-f71e502d412a@googlegroups.com>
 <20180520134354.GB2192@hermes.hilbert.loc>
 <20180522212337.cvtbh32tydvaft4r@hjp.at>
 <CAPTjJmqP86iiuoXrB0r1M-7U9kM8P5Xev=mEtLwmFr5zKV45AA@mail.gmail.com>
 <20180522223103.fmym5wsmvr7vaua3@hjp.at>
 <CAPTjJmo5X-+v0RG5a-3KX4NVDpd_6hyjJHmnCf7t2An8H43tGA@mail.gmail.com>
 <20180529081528.v7esb22ccgmksmvd@hjp.at>
 <CAPTjJmrqoLWToz+7w8qEuFKS7xaVAr4tjC6j5fHGDhkjDuZQuw@mail.gmail.com>
 <20180529100918.pymciog6ahuronan@hjp.at>
 <CAPTjJmpnQmkcZESGnK=micKbZz4t8UA4BvpZdChkWbcEArvPvQ@mail.gmail.com>
 <20180529105929.xebyilz4mgsl42ar@hjp.at>
Message-ID: <CAPTjJmqpFWkuN+UQyNchmHv8qRsLOGMynTwzmMde5w2BVyiBPg@mail.gmail.com>

On Tue, May 29, 2018 at 8:59 PM, Peter J. Holzer <hjp-python at hjp.at> wrote:
> On 2018-05-29 20:28:54 +1000, Chris Angelico wrote:
>> Sure, but you're describing a set of rules. If you can define a set of
>> rules that pin down the encoding, you could teach chardet to follow
>> those rules. If you can't teach chardet to follow those rules, you
>> can't teach a human to follow them either. What is the human going to
>> do? Guess?
>
> Xkcd to the rescue:
>
> https://xkcd.com/1425/
>
> There are a lot of things which are easy to do for a human (recognize a
> bird, understand a sentence), but very hard to write a program for
> (mostly because we don't understand how our brain works, I think).
>
> I haven't looked in detail on how chardet works but it looks like has a
> few simple statistical models for the probability of characters and
> character sequences. This is very different from what a human does, who
> a) recognises whole words, and b) knows what they mean and whether they
> make sense in context.
>
> For a sufficiently narrow range of texts, you can write a program which
> is better at recognizing encoding or language than any human can (As an
> obvious improvement to chardet, you could supply it with dictionaries of
> all languages). However, in the general case that would need a strong
> AI. And we aren't there yet, by far.

I would go further. Some things aren't just beyond current technology
(the "is it a bird" example is just now coming into current tech), and
others are fundamentally impossible. Here's a challenge: Go through a
collection of usernames and identify the language that they were
derived from. Some of them are arbitrary collections of letters and
have no "base language". Others are concatenations of words, not
individual words. A few are going to be mash-ups. Others might be
reversed or otherwise mangled. Okay. Now figure out how to pronounce
those, because that depends on the language.

Impossible? Yep. Now replace "language" with "encoding" and it's still
just as impossible. Sometimes you'll get it wrong and it won't matter
(because the end result of your guess is the same as the end result of
the actual encoding), but other times it will matter.

You can always solve a subset of problems. Using your own knowledge of
German, you are able to better solve problems involving German text.
But that doesn't make you any better than chardet at validating
Chinese text, or Korean text, or Klingon text, or any other language
you don't know. In fact, you are WORSE than a computer, because a
computer can be programmed to be fluent in six million forms of
communication, where a human is notable with six. (My apologies if you
happen to know Chinese, Korean, or Klingon. Pick other languages.)
Suppose you were to teach a machine all your tricks for understanding
German text - but someone else teaches the same machine how to
understand other languages too. We're right back where we started,
unable to recognize which language something is. Or needing external
information about the language in order to better guess the encoding.

ChrisA


From hjp-python at hjp.at  Tue May 29 08:04:19 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Tue, 29 May 2018 14:04:19 +0200
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <CAPTjJmqpFWkuN+UQyNchmHv8qRsLOGMynTwzmMde5w2BVyiBPg@mail.gmail.com>
References: <20180522212337.cvtbh32tydvaft4r@hjp.at>
 <CAPTjJmqP86iiuoXrB0r1M-7U9kM8P5Xev=mEtLwmFr5zKV45AA@mail.gmail.com>
 <20180522223103.fmym5wsmvr7vaua3@hjp.at>
 <CAPTjJmo5X-+v0RG5a-3KX4NVDpd_6hyjJHmnCf7t2An8H43tGA@mail.gmail.com>
 <20180529081528.v7esb22ccgmksmvd@hjp.at>
 <CAPTjJmrqoLWToz+7w8qEuFKS7xaVAr4tjC6j5fHGDhkjDuZQuw@mail.gmail.com>
 <20180529100918.pymciog6ahuronan@hjp.at>
 <CAPTjJmpnQmkcZESGnK=micKbZz4t8UA4BvpZdChkWbcEArvPvQ@mail.gmail.com>
 <20180529105929.xebyilz4mgsl42ar@hjp.at>
 <CAPTjJmqpFWkuN+UQyNchmHv8qRsLOGMynTwzmMde5w2BVyiBPg@mail.gmail.com>
Message-ID: <20180529120419.6ncjlbefvkisezvy@hjp.at>

On 2018-05-29 21:13:43 +1000, Chris Angelico wrote:
> You can always solve a subset of problems. Using your own knowledge of
> German, you are able to better solve problems involving German text.
> But that doesn't make you any better than chardet at validating
> Chinese text, or Korean text, or Klingon text, or any other language
> you don't know.

But I don't have to. Chardet has to be reasonably good at identifying
any encoding. I only have to be good at identifying the encoding of
files which I need to import (or otherwise process.).

Please go back to the original posting. The poster has one file which he
wants to read, and asked how to determine the encoding. He was told
categorically that this is impossible and he must ask the source.

THIS is what I'm responding to, not the problem of finding a generic
solution which works for every possible file.

The OP has one file. He wants to read it. The very fact that he wants to
read this particular file makes it very likely that he knows something
about the contents of the file. So he has domain knowledge. Which makes
it very likely that he can distinguish a correct from an incorrect
decoding. He probably can't distinguish Korean poetry from a Vietnamese
shopping list, but his file probably isn't either.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180529/d428d054/attachment.sig>

From mal at europython.eu  Tue May 29 08:25:34 2018
From: mal at europython.eu (M.-A. Lemburg)
Date: Tue, 29 May 2018 14:25:34 +0200
Subject: EuroPython 2018: Financial Aid Program
Message-ID: <24f90337-f850-a6ee-070e-bf5d91404d8b@europython.eu>

As part of our commitment to the Python community, we are pleased to
announce that we offer special grants for people in need of a
financial aid to attend EuroPython 2018.

We offer financial aid conference grants in these 3 categories:

- Free and discounted ticket: Get a standard ticket for the conference
  for free (including access to conference days (Wed-Fri), Beginners?
  Day workshop and sprints.). Note: training passes are NOT included
  in the free conference ticket.

- Travel costs: We will cover the travel costs pro rata, depending on
  what you are applying for.

- Accommodation: We can partially cover your accommodation costs

Grant Eligibility
-----------------

Our grants are open to all people in need of financial aid. We will
specifically take into account the following criteria in the selection
process:

- Contributors: Potential speakers/trainers of EuroPython (people who
  submitted a proposal) and all who contribute to EuroPython and/or
  Python community projects.

- Economic factors: We want everybody to have a chance to come to
  EuroPython, regardless of economic situation or income level.

- Diversity: We seek the most diverse and inclusive event possible.

How to apply
------------

You can apply for financial aid by filling the form on the EuroPython
2018 Finance Aid page:

     https://ep2018.europython.eu/en/registration/financial-aid/

If you have any questions, please read the FAQ or send an email to
finaid at europython.eu

Timeline
--------

- June 5th (2018-06-05)  - the deadline for submitting the applications
- June 12th (2018-06-12) - applicants will be notified by e-mail around
- June 17th (2018-06-17) - deadline for applicants to accept the grant
- June 20th (2018-06-20) - applicants will receive confirmation notific
- July 23rd (2018-07-23) - last day when we accept invoices

Refund management
-----------------

Free ticket: The individual coupons will be generated for a free
ticket.

Accommodation and Travel grant: All grants involving reimbursements
will be reimbursed by PayPal or bank transfer. Please send us your
receipts (hotel invoice, plane/bus/train ticket) before the conference
for approval.

Become a special Finance Aid and Diversity sponsor!

You or your company can support our finaid initiative by becoming a sponsor.

We have a special sponsor package ?Financial aid sponsor? and a
?Financial aid donation? option that can be booked separately or in
combination with a sponsor package:

- https://ep2018.europython.eu/en/sponsor/packages/#Financial-Aid-Sponsor
- https://ep2018.europython.eu/en/sponsor/options/

For more information please contact the sponsor work group at
sponsoring at europython.eu.

Bring us a new sponsor and get free ticket for EuroPython 2018!


Help spread the word
--------------------

Please help us spread this message by sharing it on your social
networks as widely as possible. Thank you !

Link to the blog post:

https://blog.europython.eu/post/174368323052/europython-2018-financial-aid-program

Tweet:

https://twitter.com/europython/status/1001437296816742401


Enjoy,
--
EuroPython 2018 Team
https://ep2018.europython.eu/
https://www.europython-society.org/



From steve+comp.lang.python at pearwood.info  Tue May 29 08:44:28 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Tue, 29 May 2018 12:44:28 +0000 (UTC)
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
References: <mailman.8292.1233248983.3487.python-list@python.org>
 <e7a5785b-aa36-430a-837e-7dd32de57c6b@googlegroups.com>
 <CANc-5Uxy8T+LKC=vw6ujxnY4K+yPpA1U7-boLXSYSeDbx8DgeQ@mail.gmail.com>
 <mailman.243.1526773687.2761.python-list@python.org>
 <27ef2bfb-e3ed-495c-bb98-f71e502d412a@googlegroups.com>
 <20180520134354.GB2192@hermes.hilbert.loc>
 <20180522212337.cvtbh32tydvaft4r@hjp.at>
 <CAPTjJmqP86iiuoXrB0r1M-7U9kM8P5Xev=mEtLwmFr5zKV45AA@mail.gmail.com>
 <20180522223103.fmym5wsmvr7vaua3@hjp.at> <pe307p$d1p$1@blaine.gmane.org>
 <20180529083450.j7vzktw6tmywwkqb@hjp.at>
Message-ID: <pejhvb$q4o$13@blaine.gmane.org>

On Tue, 29 May 2018 10:34:50 +0200, Peter J. Holzer wrote:

> On 2018-05-23 06:03:38 +0000, Steven D'Aprano wrote:
>> On Wed, 23 May 2018 00:31:03 +0200, Peter J. Holzer wrote:
>> > On 2018-05-23 07:38:27 +1000, Chris Angelico wrote:
>> >> You can find an encoding which is capable of decoding a file. That's
>> >> not the same thing.
>> > 
>> > If the result is correct, it is the same thing.
>> 
>> But how do you know what is correct and what isn't? 
[...]
>> If this text is encoding using MacRoman, then decoded in Latin-1, it
>> works, and looks barely any more stupid than the original:
>> 
>>     Max Steele strained his mighty thews against his bonds, but the
>>     ?-rays had left him as weak as a kitten. The evil Galactic Emperor,
>>     Gi?x-??in The Terrible of the planet ?e??, laughed: "I have you
>>     now, Steele, and by this time tomorrow my armies will have overrun
>>     your pitiful Earth defences!"
>> 
>> but it clearly isn't the original text.
> 
> Please note that I wrote "almost always", not "always". It is of course
> possible to construct contrived examples where it is impossible to find
> the correct encoding, because all encodings lead to equally ludicrous
> results.

Whether they are ludicrous is not the point, the point is whether it is 
the original text intended.

What you describe works for the EASY cases: you have a small number of 
text files in some human-readable language, the text files are all valid 
texts in that language, and you have an expert in that language on hand 
able to distinguish between such valid and invalid decoded texts.

If that applies for your text files, great, you have nothing to fear from 
encoding issues! Even if the supplier of the files wouldn't know ASCII 
from EBCDIC if it fell on them from a great height, you can probably make 
an educated guess what the encoding is. Wonderful.

But that's not always the case. In the real world, especially now that we 
interchange documents from all over the world, it isn't the hard cases 
that are contrived. Depending on the type of document (e.g. web pages you 
scrape are probably different from emails, which are different from 
commercial CSV files...) being able to just look at the file and deduce 
the correct encoding is the contrived example.

Depending on where the text is coming from:

- you might not have an expert on hand who can distinguish between
  valid and invalid text;

- you might have to process a large number of files (thousands or
  millions) automatically, and cannot hand-process those that have
  encoding problems;

- your files might not even be in a single consistent encoding, or
  may have Mojibake introduced at some earlier point that you do not
  have control over;

- you might not know what language the text is supposed to be;

- or it might contain isolated words in some unknown language;

  e.g. your text might be nearly all ASCII English, except for a word
  "?ezare" (if using the Czech Kamenick? encoding) or "?ezare" (if
  using the Polish Mazovia encoding) or "?ezare" (Mac Roman).

  How many languages do you need to check to determine which is 
  correct? (Hint: all three words are valid.)

- not all encoding problems are as equally easy to resolve as
  your earlier German/Russian example.

E.g. Like Japanese, Russian has a number of incompatible and popular 
encodings. Mojibake is a Japanese term, but the Russians have their own 
word for it: krakozyabry (???????????).


Dealing with bad data is *hard*.

https://www.safaribooksonline.com/library/view/bad-data-
handbook/9781449324957/ch04.html


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson



From ian.g.kelly at gmail.com  Tue May 29 09:57:18 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Tue, 29 May 2018 07:57:18 -0600
Subject: Indented multi-line strings (was: "Data blocks" syntax
 specification draft)
In-Reply-To: <20180529091919.xxr7rt5yoplwdge6@hjp.at>
References: <CAE6NSRB9y7sxoqf08gznMWsOmCYWDKi3gDRQUrsZW060sqoBjg@mail.gmail.com>
 <pdu324$l8j$1@blaine.gmane.org>
 <CAHiMU6cGz=X4LMcYac=_Us0+9ATPTrJPLZaeXmK07KbnNFSP2A@mail.gmail.com>
 <CAE6NSRA9sNDkL2RgpaUnziRv5ka2j_L4y1rScKoLJSnR+KCXpg@mail.gmail.com>
 <mailman.4.1526955481.18022.python-list@python.org>
 <pe0bn1$8ns$1@dont-email.me>
 <CAE6NSRA4=wxwAWCXpJg9sXZgdDrFY5GN8_JybYg1zwgi-aYCQQ@mail.gmail.com>
 <9bf0783c8b044b348769942bda950043@F5.com>
 <20180523162535.xbtqnxi7yqv4ijlg@hjp.at>
 <CALwzidnMYFyxM5cqHZVpEd4KBDx-E51Gzx2gvhMuyPgx90PD9A@mail.gmail.com>
 <20180529091919.xxr7rt5yoplwdge6@hjp.at>
Message-ID: <CALwzidkQQshcfDfqzONtP18D4c7QshsPeaXfArWQUt=2SxoyFQ@mail.gmail.com>

On Tue, May 29, 2018 at 3:19 AM, Peter J. Holzer <hjp-python at hjp.at> wrote:
> On 2018-05-23 11:08:48 -0600, Ian Kelly wrote:
>>
>> How about we instead just use the rules from PEP 257 so that there
>> aren't two different sets of multi-line string indentation rules to
>> have to remember?
>>
>> https://www.python.org/dev/peps/pep-0257/#handling-docstring-indentation
>
> These rules are nice for a specific application, but I think they are
> too ad-hoc and not general enough for a language feature which should be
> able to represent arbitrary strings.
>
> In particular:
>
> | will strip a uniform amount of indentation from the second and further
> | lines of the docstring, equal to the minimum indentation of all
> | non-blank lines after the first line
>
> What if I want all lines to start with some white space?
>
> |  Any indentation in the first line of the docstring (i.e., up to the
> |  first newline) is insignificant and removed.
>
> What if I want the string to start with white space?
>
> |  Blank lines should be removed from the beginning and end of the
> |  docstring.
>
> What if I want leading or trailing blank lines?

Fair points. I still dislike reinventing the wheel here. Note that
even as I proposed reusing the single existing indentation-removal
scheme in the language, I misremembered a few things about how it
works.

>> Also, how about using a string prefix character instead of making
>> quad-quote meaningful? Apart from being hard to visually distinguish
>> from triple-quote, this would break existing triple-quote strings that
>> happen to start with the quote character, e.g ''''What?' she asked.'''
>
> No confusion here, since in my proposal there is always a newline after
> the leading delimiter, since otherwise the first line wouldn't line up
> with the rest. So the parser would notice that this is a triple-quote
> and not a quad-quote as soon as it sees the "W".

Then how about a triple-quote string that starts with a quote
character followed by a newline?

>> b = i'''
>>     Here is a multi-line string
>>     with indentation, which is
>>     determined from the second
>>     line.'''
>
> Visually, that letter doesn't look like a part of the quote, so I would
> like to pull the contents of the string over to align with the quote:
>
> b = i'''
>      Here is a multi-line string
>      with indentation, which is
>      determined from the second
>      line.'''
>
> But that creates an ambiguity: Is the whole string now indented one
> space or not? Where is the left edge?

I don't follow. In the first case you have a multi-line string where
every line is indented four spaces, so four spaces are to be removed
from every line. In the second case you have a multi-line string where
every line is indented by five spaces, so five spaces are to be
removed from every line. What about the second string would make the
algorithm think that four spaces are to be removed from every line,
leaving one? Why not remove three, leaving two? Or remove one, leaving
four? And why is the first string safe from this?

In any case, Chris made a good point that I agree with. This doesn't
really need to be syntax at all, but could just be implemented as a
new string method.


From mike.junk.46 at att.net  Tue May 29 10:10:07 2018
From: mike.junk.46 at att.net (Mike McClain)
Date: Tue, 29 May 2018 07:10:07 -0700
Subject: '_' and '__'
In-Reply-To: <857enqj5o1.fsf@benfinney.id.au>
References: <mailman.1612.1527331964.18019.python-list@python.org>
 <20180526231945.GA14349@playground>
 <857enqj5o1.fsf@benfinney.id.au>
Message-ID: <20180529141007.GA15867@playground>

To the many who responded, many thanks.
I,too, found Nick Coghlan's answer iluminating.
Mike
--
    There are always gossips everywhere you go and few of them
limit themselves to veracity when what they consider a good
story is available to keep their audience entertained.
    - MM


From email at paulstgeorge.com  Tue May 29 11:39:27 2018
From: email at paulstgeorge.com (Paul St George)
Date: Tue, 29 May 2018 17:39:27 +0200
Subject: The PIL show() method looks for the default viewer. How do I
 change this to a different viewer (of my choice)?
In-Reply-To: <peg0sn$46i$1@dont-email.me>
References: <6d5f6b18-99ac-cc6f-8cfb-0caf23224c51@paulstgeorge.com>
 <20180527215836.GA6330@cskk.homeip.net>
 <mailman.19.1527458326.2804.python-list@python.org>
 <peg0sn$46i$1@dont-email.me>
Message-ID: <b23696a0-d9eb-fb7e-ee25-76882a771637@paulstgeorge.com>

Should the PIL code be corrected?


On 28/05/2018 06:34, Christian Gollwitzer wrote:
> Am 27.05.18 um 23:58 schrieb Cameron Simpson:
>> On 27May2018 20:15, Paul St George <email at paulstgeorge.com> wrote:
>>> This is very helpful indeed, thank you. Awe-inspiring.
>>>
>>> It occurred to me that I could edit the PIL/ImageShow.py, replacing 
>>> ?xv? (in five places) with the utility of my choice and using 
>>> ?executable? as the command.
>>>
>>> Or, is this just not done?
>>
>> It becomes a maintenance problem.
>>
>> Alternatively you could:
>>
>> Just write your own show function which accepts an Image and displays 
>> it with your program of choice. You might need to write some 
>> equivalent code which saves the Image to a file first, and removes it 
>> afterwards.
>>
>> You could copy the show() code into a function of your own (i.e. in 
>> your own codebase) modify that to suit, then monkeypatch the class:
>>
>> ??Image.show = your_personal_show_function
>>
>> when your programme starts. That way the code changes are not in the 
>> PIL code.
>
> I think this is a bug/misfeature in the PIL code. On all 3 major 
> platforms there is a way to invoke the standard program for a given 
> file or URL. On Windows, it is "cmd.exe /c start ...", on OSX it is 
> "open ...." and on Linux it is "xdg-open ...". That way the file is 
> opened by whatever the user has set in his desktop environment.
>
> Technically, xdg-open needs not to be present on Linux, though it is 
> usually installed.
>
> ????Christian
>

-- 
Paul St George
http://www.paulstgeorge.com
http://www.devices-of-wonder.com

+44(0)7595 37 1302



From email at paulstgeorge.com  Tue May 29 11:40:57 2018
From: email at paulstgeorge.com (Paul St George)
Date: Tue, 29 May 2018 17:40:57 +0200
Subject: The PIL show() method looks for the default viewer. How do I
 change this to a different viewer (of my choice)?
In-Reply-To: <20180527215836.GA6330@cskk.homeip.net>
References: <6d5f6b18-99ac-cc6f-8cfb-0caf23224c51@paulstgeorge.com>
 <20180527215836.GA6330@cskk.homeip.net>
Message-ID: <a3893e52-b60b-2f22-cd00-41490c9de8a6@paulstgeorge.com>

Thank you. For the advice, and for the new word 'monkeypatch'.


On 27/05/2018 23:58, Cameron Simpson wrote:
> On 27May2018 20:15, Paul St George <email at paulstgeorge.com> wrote:
>> This is very helpful indeed, thank you. Awe-inspiring.
>>
>> It occurred to me that I could edit the PIL/ImageShow.py, replacing 
>> ?xv? (in five places) with the utility of my choice and using 
>> ?executable? as the command.
>>
>> Or, is this just not done?
>
> It becomes a maintenance problem.
>
> Alternatively you could:
>
> Just write your own show function which accepts an Image and displays 
> it with your program of choice. You might need to write some 
> equivalent code which saves the Image to a file first, and removes it 
> afterwards.
>
> You could copy the show() code into a function of your own (i.e. in 
> your own codebase) modify that to suit, then monkeypatch the class:
>
> ?Image.show = your_personal_show_function
>
> when your programme starts. That way the code changes are not in the 
> PIL code.
>
> Cheers,
> Cameron Simpson <cs at cskk.id.au>
>

-- 
Paul St George
http://www.paulstgeorge.com
http://www.devices-of-wonder.com

+44(0)7595 37 1302



From email at paulstgeorge.com  Tue May 29 11:55:05 2018
From: email at paulstgeorge.com (Paul St George)
Date: Tue, 29 May 2018 17:55:05 +0200
Subject: The PIL show() method looks for the default viewer. How do I
 change this to a different viewer (of my choice)?
In-Reply-To: <et2mgdt2pi2pi8r3k8gnffd3gtqh8kre36@4ax.com>
References: <ddedae8b-f085-dfa3-08a4-2c821975cc61@paulstgeorge.com>
 <CANDiX9+fF3ADqhee50RA47hecQRpsOVJjXML9=OAYzkAp9gNqw@mail.gmail.com>
 <0efaafaa-064f-726a-416f-9dc9d0756667@paulstgeorge.com>
 <fr5jgd50bkjrroudnlsdhe3t78gcpt61nn@4ax.com>
 <01feca98-20d6-2b96-5cc4-df8f616c87f3@paulstgeorge.com>
 <et2mgdt2pi2pi8r3k8gnffd3gtqh8kre36@4ax.com>
Message-ID: <35ccae80-79f5-e83c-2d75-c55e5871401f@paulstgeorge.com>

I tried this anyway. The error was:

 ??? non-keyword arg after keyword arg



On 27/05/2018 21:51, Dennis Lee Bieber wrote:
> On Sun, 27 May 2018 19:59:41 +0200, Paul St George <email at paulstgeorge.com>
> declaimed the following:
>
>> So, on Unix I would use
>>
>> Image.show(title=None, nameofdisplayutilty), or Image.show(title=None,
>> scriptname) #where script with name scriptname invokes the program
>>
>> I will try this now! And thank you.
>>
> 	That is based upon my interpretation of the documentation... If the
> other participant is right, however, then the "command" parameter may not
> even be getting used at the lower levels, and only the list of registered
> viewers is examined. In that case one would have to register a function to
> invoke the viewer.
>
>

-- 
Paul St George
http://www.paulstgeorge.com
http://www.devices-of-wonder.com

+44(0)7595 37 1302



From steve+comp.lang.python at pearwood.info  Tue May 29 12:20:36 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Tue, 29 May 2018 16:20:36 +0000 (UTC)
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
References: <20180522212337.cvtbh32tydvaft4r@hjp.at>
 <CAPTjJmqP86iiuoXrB0r1M-7U9kM8P5Xev=mEtLwmFr5zKV45AA@mail.gmail.com>
 <20180522223103.fmym5wsmvr7vaua3@hjp.at>
 <CAPTjJmo5X-+v0RG5a-3KX4NVDpd_6hyjJHmnCf7t2An8H43tGA@mail.gmail.com>
 <20180529081528.v7esb22ccgmksmvd@hjp.at>
 <CAPTjJmrqoLWToz+7w8qEuFKS7xaVAr4tjC6j5fHGDhkjDuZQuw@mail.gmail.com>
 <20180529100918.pymciog6ahuronan@hjp.at>
 <CAPTjJmpnQmkcZESGnK=micKbZz4t8UA4BvpZdChkWbcEArvPvQ@mail.gmail.com>
 <20180529105929.xebyilz4mgsl42ar@hjp.at>
 <CAPTjJmqpFWkuN+UQyNchmHv8qRsLOGMynTwzmMde5w2BVyiBPg@mail.gmail.com>
 <20180529120419.6ncjlbefvkisezvy@hjp.at>
Message-ID: <pejukj$sr1$1@blaine.gmane.org>

On Tue, 29 May 2018 14:04:19 +0200, Peter J. Holzer wrote:

> The OP has one file. 

We don't know that. All we know is that he had one file which he was 
unable to read. For all we know, he has a million files, and this was 
merely the first of many failures.


> He wants to read it. The very fact that he wants to
> read this particular file makes it very likely that he knows something
> about the contents of the file. So he has domain knowledge.

An unjustified assumption. I've wanted to read many files with only the 
vaguest guess of what they might contain.

As for his domain knowledge, look again at the OP's post. His solution 
was to paper over the error, make the error go away, by moving to Python 
2 which is more lax about getting the encoding right:

"i actually got my script to function by running it in python 2.7"

So he didn't identify the correct encoding, nor did he use an error 
handler, or fix the bug in his code. He just downgraded to an older 
version of Python, because it made the exception (but not the error) go 
away.

My prediction is that he has replaced an explicit exception with a silent 
failure, preferring mojibake to actually dealing with the problem.


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson



From email at paulstgeorge.com  Tue May 29 14:02:22 2018
From: email at paulstgeorge.com (Paul St George)
Date: Tue, 29 May 2018 20:02:22 +0200
Subject: The PIL show() method looks for the default viewer.
 How do I change this to a different viewer (of my choice)?
In-Reply-To: <peitjc$jjq$1@blaine.gmane.org>
References: <ddedae8b-f085-dfa3-08a4-2c821975cc61@paulstgeorge.com>
 <CANDiX9+fF3ADqhee50RA47hecQRpsOVJjXML9=OAYzkAp9gNqw@mail.gmail.com>
 <0efaafaa-064f-726a-416f-9dc9d0756667@paulstgeorge.com>
 <pec4bf$3a7$1@blaine.gmane.org>
 <6d5f6b18-99ac-cc6f-8cfb-0caf23224c51@paulstgeorge.com>
 <peitjc$jjq$1@blaine.gmane.org>
Message-ID: <083a74fd-94c0-8cae-c052-17205a1b9f7b@paulstgeorge.com>

Is there, somewhere, a list of viewers and their names (for the purposes 
of this script)?

I am assuming that if I want to ImageMagick (for example), there would 
be some shorter name - such as 'magick' - and it would be lower case .


On 29/05/2018 08:58, Peter Otten wrote:
> Paul St George wrote:
>
>> This is very helpful indeed, thank you. Awe-inspiring.
>>
>> It occurred to me that I could edit the PIL/ImageShow.py, replacing ?xv?
>> (in five places) with the utility of my choice and using ?executable? as
>> the command.
>>
>> Or, is this just not done?
> No, this tends to become a maintenance problem. Instead write a little
> module of your own
>
>
> from PIL import ImageShow
>
> class MyViewer(ImageShow.UnixViewer):
>      def __init__(self, command):
>          self.command = command
>      def get_command_ex(self, file, **options):
>          return (self.command,) * 2
>
> ImageShow.register(MyViewer("gwenview"), -1)
>
>
> (replace "gwenview" with your favourite viewer) and import it before using
> Image.show().
>
>

-- 
Paul St George
http://www.paulstgeorge.com
http://www.devices-of-wonder.com

+44(0)7595 37 1302



From george at fischhof.hu  Tue May 29 16:34:48 2018
From: george at fischhof.hu (George Fischhof)
Date: Tue, 29 May 2018 22:34:48 +0200
Subject: [ANN] pluggable-info-monitor 0.2.1 released!
Message-ID: <CAFwcP0gp5ci=rKMgAdj56j2E_8=naW-LcEVKJJBxu4Qa_njPcg@mail.gmail.com>

Hi everyone,

I?m very excited to announce the release of pluggable-info-monitor 0.2.1
First public release.

You can download it form bitbucket:
https://bitbucket.org/GeorgeFischhof/pluggable_info_monitor

package index page:
https://pypi.python.org/pypi/pluggable-info-monitor


What is pluggable-info-monitor?

A web application that shows the information you gathered with your plugin.
It can be anything ;-) examples:
- in a development environment, bug statistics, build and test results
- in education, some education material
- in an office it can show the weather foreast, namedays, daily quotes
- it can be used as a dashboard for system administrators
- etc

There are example plugins to help developing your own plugins.


Please note:

The full feature set requires Python 3.4 and later.



Have fun using pluggable-info-monitor
George


From steve+comp.lang.python at pearwood.info  Tue May 29 20:31:23 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Wed, 30 May 2018 00:31:23 +0000 (UTC)
Subject: The PIL show() method looks for the default viewer. How do I
 change this to a different viewer (of my choice)?
References: <ddedae8b-f085-dfa3-08a4-2c821975cc61@paulstgeorge.com>
 <CANDiX9+fF3ADqhee50RA47hecQRpsOVJjXML9=OAYzkAp9gNqw@mail.gmail.com>
 <0efaafaa-064f-726a-416f-9dc9d0756667@paulstgeorge.com>
 <pec4bf$3a7$1@blaine.gmane.org>
 <6d5f6b18-99ac-cc6f-8cfb-0caf23224c51@paulstgeorge.com>
 <peitjc$jjq$1@blaine.gmane.org>
 <083a74fd-94c0-8cae-c052-17205a1b9f7b@paulstgeorge.com>
Message-ID: <pekrcq$sr1$2@blaine.gmane.org>

On Tue, 29 May 2018 20:02:22 +0200, Paul St George wrote:

> Is there, somewhere, a list of viewers and their names (for the purposes
> of this script)?

Do you mean a list of programs capable of viewing graphics? Do you think 
there is some sort of central authority that registers the names of all 
such programs? *wink*


You can start here:

https://en.wikipedia.org/wiki/Category:Graphics_software

but that's probably the closest you're going to get.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson



From ian.g.kelly at gmail.com  Tue May 29 21:04:06 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Tue, 29 May 2018 19:04:06 -0600
Subject: The PIL show() method looks for the default viewer. How do I
 change this to a different viewer (of my choice)?
In-Reply-To: <0efaafaa-064f-726a-416f-9dc9d0756667@paulstgeorge.com>
References: <ddedae8b-f085-dfa3-08a4-2c821975cc61@paulstgeorge.com>
 <CANDiX9+fF3ADqhee50RA47hecQRpsOVJjXML9=OAYzkAp9gNqw@mail.gmail.com>
 <0efaafaa-064f-726a-416f-9dc9d0756667@paulstgeorge.com>
Message-ID: <CALwzidnnwovzuk7jZr+1obHOa+w2FQJughe1DHVU4Auduvqe1w@mail.gmail.com>

On Sat, May 26, 2018 at 9:17 AM, Paul St George <email at paulstgeorge.com> wrote:
> Thank you.
> You are very right. The show() method is intended for debugging purposes and
> is useful for that, but what method should I be using and is PIL the best
> imaging library for my purposes? I do not want to manipulate images, I only
> want to show images (full screen) on an external display. I want to use
> Python to control the timing of the images.

You probably shouldn't be using PIL at all then. Why open the file in
Python just to export it and re-open it in an image viewer? It would
be simpler just to point whichever image viewer you prefer at the
original file directly. Your entire script could just be something
like this:

import subprocess

# Some timing logic

subprocess.call("display " + imagepath, shell=True)


From Ruifeng.Guo at synopsys.com  Tue May 29 21:07:38 2018
From: Ruifeng.Guo at synopsys.com (Ruifeng Guo)
Date: Wed, 30 May 2018 01:07:38 +0000
Subject: a Python bug report
Message-ID: <822990BCB7F3DD47806E56C8771DCC79017790A8E1@US01WEMBX2.internal.synopsys.com>

Hello,
We encountered a bug in Python recently, we checked the behavior for Python version 2.7.12, and 3.1.1, both version show the same behavior. Please see below the unexpected behavior in "red text".

Thanks,
Ruifeng Guo

From: Brian Archer
Sent: Tuesday, May 29, 2018 5:57 PM
To: Ruifeng Guo <rfguo at synopsys.com>
Subject: Python Bug

Python 3.1.1 (r311:74480, Nov 20 2012, 09:11:57)
[GCC 4.2.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a=1017.0
>>> print(int(a))
1017
>>> b=1000*1.017
>>> print(b)
1017.0
>>> int(b)
1016
>>> c=1017.0
>>> int(c)
1017
>>>





From chema at rinzewind.org  Tue May 29 21:34:21 2018
From: chema at rinzewind.org (=?iso-8859-1?Q?Jos=E9_Mar=EDa?= Mateos)
Date: Tue, 29 May 2018 21:34:21 -0400
Subject: a Python bug report
In-Reply-To: <822990BCB7F3DD47806E56C8771DCC79017790A8E1@US01WEMBX2.internal.synopsys.com>
References: <822990BCB7F3DD47806E56C8771DCC79017790A8E1@US01WEMBX2.internal.synopsys.com>
Message-ID: <20180530013421.GA11551@equipaje>

On Wed, May 30, 2018 at 01:07:38AM +0000, Ruifeng Guo wrote:
> Hello,
> We encountered a bug in Python recently, we checked the behavior for Python version 2.7.12, and 3.1.1, both version show the same behavior. Please see below the unexpected behavior in "red text".

Have you tried the round() function, however?

In [1]: round(1000 * 1.017)
Out[1]: 1017.0

This is a floating point precision "issue". int() only gets rid of the 
decimals.

In [2]: int(3.9)
Out[2]: 3

Because:

In [3]: 1000 * 1.017
Out[3]: 1016.9999999999999

So there you have it.

Some more reading: 
https://stackoverflow.com/questions/43660910/python-difference-between-round-and-int

Cheers,

-- 
Jos? Mar?a (Chema) Mateos
https://rinzewind.org/blog-es || https://rinzewind.org/blog-en


From ian.g.kelly at gmail.com  Tue May 29 22:11:06 2018
From: ian.g.kelly at gmail.com (Ian Kelly)
Date: Tue, 29 May 2018 20:11:06 -0600
Subject: a Python bug report
In-Reply-To: <822990BCB7F3DD47806E56C8771DCC79017790A8E1@US01WEMBX2.internal.synopsys.com>
References: <822990BCB7F3DD47806E56C8771DCC79017790A8E1@US01WEMBX2.internal.synopsys.com>
Message-ID: <CALwzid=T814tNneAyBkhAf0q3WZi26Gb1xR66HV+yNB=1xP1Lg@mail.gmail.com>

On Tue, May 29, 2018 at 7:07 PM, Ruifeng Guo <Ruifeng.Guo at synopsys.com> wrote:
> Hello,
> We encountered a bug in Python recently, we checked the behavior for Python version 2.7.12, and 3.1.1, both version show the same behavior. Please see below the unexpected behavior in "red text".
>
> Thanks,
> Ruifeng Guo
>
> From: Brian Archer
> Sent: Tuesday, May 29, 2018 5:57 PM
> To: Ruifeng Guo <rfguo at synopsys.com>
> Subject: Python Bug
>
> Python 3.1.1 (r311:74480, Nov 20 2012, 09:11:57)
> [GCC 4.2.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> a=1017.0
>>>> print(int(a))
> 1017
>>>> b=1000*1.017
>>>> print(b)
> 1017.0
>>>> int(b)
> 1016
>>>> c=1017.0
>>>> int(c)
> 1017

Try this, and you'll see what the problem is:

>>> repr(b)
'1016.9999999999999'

The value of b is not really 1017, but fractionally less as a result
of floating point rounding error, because 1.017 cannot be exactly
represented as a float.

In Python 3.2, the str() of the float type was changed to match the
repr(), so that when you use print() as above you will also get this
result:

>>> print(b)
1016.9999999999999

By the way, Python 3.1.1 is really old (six years!). I recommend
upgrading if possible.


From Ronaldon2018 at gmail.com  Wed May 30 01:44:55 2018
From: Ronaldon2018 at gmail.com (MrMagoo2018)
Date: Tue, 29 May 2018 22:44:55 -0700 (PDT)
Subject: Simple question: how do I print output from .get() method
Message-ID: <6e98879a-922d-47a1-94be-cd1c354569e3@googlegroups.com>

Hello folks, imagine I have the code below and I am getting the "error" message when attempting to print() the output of 'sw_report'. 
Can you suggest which method I should use to retrieve this? Is that a dictionary maybe?

from arista import arista
m = arista()
m.authenticate ("user","password")
sw_report = m.np.sw_report.get("swType="EOS",swMajorVersion="5.0")
print (sw_report)
<generator object arista._result_iterate at 0x7fdb30f0af10>


From dieter at handshake.de  Wed May 30 01:45:07 2018
From: dieter at handshake.de (dieter)
Date: Wed, 30 May 2018 07:45:07 +0200
Subject: cProfile, timed call tree
References: <CAK6Z60du+GX5iUmjfFQZz4bxSKifUQZ8hAa4vGf8qFTsOtaOXg@mail.gmail.com>
 <87in7b3rjy.fsf@handshake.de> <20180529100258.4wpn2gexmjfhtw5u@hjp.at>
Message-ID: <87wovlzogs.fsf@handshake.de>

"Peter J. Holzer" <hjp-python at hjp.at> writes:

> On 2018-05-26 07:38:09 +0200, dieter wrote:
>> But, in general, you are right: you cannot reconstruct complete
>> call trees. The reason is quite simple: maintaining information
>> for the complete caller ancestry (rather than just the immediate
>> caller) is expensive (both in terms of runtime and storage).
>> Profiling usually is used as a preparation for optimization.
>> Optimization has the greatest effects if applied to inner loops.
>> And for the analysis of inner loops, complete call tree information
>> is not necessary.
>
> I disagree. I have used Tim Bunce's excellent perl profiler
> (Devel::NYTProf, for the two people here who also use Perl and don't
> already know it), which does record whole call trees, and this is very
> useful. You not only see that a function is called 1.5 million times,
> you also see where it is called (not just from which functions, but from
> which lines) and how much time is spent in calls from each location. 
> Often this allowed me find ways to avoid calling a function altogether
> or prevented me from chasing down the wrong rabbit hole.

If the profile information is sampled for the call location (rather then
the call function), you still do not get the "complete call tree".
If you want to get results based on call paths (rather than the immediate
caller), the sampling must (in general) sample for call paths (and
not only the immediate caller) -- which means, you must implement
your own profiler.



From rosuav at gmail.com  Wed May 30 01:51:58 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 30 May 2018 15:51:58 +1000
Subject: Simple question: how do I print output from .get() method
In-Reply-To: <6e98879a-922d-47a1-94be-cd1c354569e3@googlegroups.com>
References: <6e98879a-922d-47a1-94be-cd1c354569e3@googlegroups.com>
Message-ID: <CAPTjJmrvhuMRDu=c0=gTeH3G3iRYj3GMkABt6P_dgS5CxSeN6w@mail.gmail.com>

On Wed, May 30, 2018 at 3:44 PM, MrMagoo2018 <Ronaldon2018 at gmail.com> wrote:
> Hello folks, imagine I have the code below and I am getting the "error" message when attempting to print() the output of 'sw_report'.
> Can you suggest which method I should use to retrieve this? Is that a dictionary maybe?
>
> from arista import arista
> m = arista()
> m.authenticate ("user","password")
> sw_report = m.np.sw_report.get("swType="EOS",swMajorVersion="5.0")
> print (sw_report)
> <generator object arista._result_iterate at 0x7fdb30f0af10>

That's not an error message. You asked Python to print it out, and it
printed it out. As it happens, the display isn't particularly useful,
but it's not an error.

What you have is a *generator object*, which is something you can
iterate over. I don't know about the arista library, so I don't know
what you'll get from that, but at its simplest, you could convert that
to a list:

print(list(sw_report))

ChrisA


From sapna.intell at gmail.com  Wed May 30 02:59:35 2018
From: sapna.intell at gmail.com (Priya Singh)
Date: Tue, 29 May 2018 23:59:35 -0700 (PDT)
Subject: Fitting cubic spline on 2D array
Message-ID: <617d5a0e-b39b-4c42-b2a0-767157288dbb@googlegroups.com>

Hello all,

Can anyone tell me how can I get the functional form of the fitted cubic spline
function on to my 2D array? For eg. when we fit the Gaussian on to an array so we have the functional form with the parameters best fitted to my data likewise how can we do for the cubic spline function? Actually, I want to express my array as

A = summation_i,j(C_ij * value_ij)

Where i and j are the array indices of my 2D array and C_ij should be the functional form of the cubic spline and value_ij is the value of A at that ij index.

Can anyone has an idea, it's very urgent. Any help will be of great use to me.

Thanks in advance!

Regards,
Priya


From mal at europython.eu  Wed May 30 03:41:04 2018
From: mal at europython.eu (M.-A. Lemburg)
Date: Wed, 30 May 2018 09:41:04 +0200
Subject: EuroPython 2018: Early Bird Ticket Sales
Message-ID: <034e749f-493b-b4ad-d74f-3cf53eecdb25@europython.eu>

We are happy to announce that we?ll start early bird tickets on

		   Thursday, at around 12:00 CEST.

We have 200 conference tickets available at the Early Bird rate and
they usually sell out within a day or two.

Invoices will be available in a few weeks
-----------------------------------------

Since we?re running the conference in the UK this year and conference
tickets are taxed at the location of the conference, we have to charge
and pay 20% UK VAT on the tickets.

In order to do this, we need a UK VAT registration and associated VAT
ID. Unfortunately, this whole process has taken way too long and so
we?re starting ticket sales without issuing invoices at this time,
simply because we would not be able to issue valid VAT invoices.

We will issues these as soon as we have the UK VAT ID, which should be
within the next couple of weeks if all goes well.

We?ll announce this on the blog and you will then be able to download
the invoices in your website account.



Help spread the word
--------------------

Please help us spread this message by sharing it on your social
networks as widely as possible. Thank you !

Link to the blog post:

https://blog.europython.eu/post/174396639222/europython-2018-early-bird-ticket-sales

Tweet:

https://twitter.com/europython/status/1001728629917863936

Enjoy,
--
EuroPython 2018 Team
https://ep2018.europython.eu/
https://www.europython-society.org/



From frank at chagford.com  Wed May 30 04:48:06 2018
From: frank at chagford.com (Frank Millman)
Date: Wed, 30 May 2018 10:48:06 +0200
Subject: Problem with OrderedDict
Message-ID: <peloc4$o31$1@blaine.gmane.org>

Hi all

I want to work backwards to solve this problem, so I have to explain it 
forwards to put you in the picture.

I have an Ordered Dictionary. Under certain circumstances I am getting this 
error -

    RuntimeError: OrderedDict mutated during iteration

I can see why this is happening, and I am pretty sure I can fix it by making 
a copy to iterate over.

However, the error seems to be intermittent - there are times when it should 
fail, but does not - so I want to investigate further.

I tried to reduce it to a simple example. I succeeded, but there are two 
problems -

1. It always fails, so I have not reproduced the intermittent nature yet.

2. It gives a different error -

    RuntimeError: dictionary changed size during iteration

So my first question is, what is the difference between the two error 
messages? I am using an OrderedDict for my test as well, so the difference 
is not caused by using a normal dictionary.

I am using Python 3.6.0.

Thanks

Frank Millman




From tjreedy at udel.edu  Wed May 30 05:03:02 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 30 May 2018 05:03:02 -0400
Subject: Problem with OrderedDict
In-Reply-To: <peloc4$o31$1@blaine.gmane.org>
References: <peloc4$o31$1@blaine.gmane.org>
Message-ID: <pelp84$8p3$1@blaine.gmane.org>

On 5/30/2018 4:48 AM, Frank Millman wrote:
> Hi all
> 
> I want to work backwards to solve this problem, so I have to explain it 
> forwards to put you in the picture.
> 
> I have an Ordered Dictionary. Under certain circumstances I am getting 
> this error -
> 
>  ?? RuntimeError: OrderedDict mutated during iteration

This should mean that the value associated with a key was sometimes changed.

> I can see why this is happening, and I am pretty sure I can fix it by 
> making a copy to iterate over.
> 
> However, the error seems to be intermittent - there are times when it 
> should fail, but does not - so I want to investigate further.
> 
> I tried to reduce it to a simple example. I succeeded, but there are two 
> problems -
> 
> 1. It always fails, so I have not reproduced the intermittent nature yet.
> 
> 2. It gives a different error -
> 
>  ?? RuntimeError: dictionary changed size during iteration

This should mean that a new key-value pair was always added or removed.

> So my first question is, what is the difference between the two error 
> messages? I am using an OrderedDict for my test as well, so the 
> difference is not caused by using a normal dictionary.
> 
> I am using Python 3.6.0.

-- 
Terry Jan Reedy




From rhodri at kynesim.co.uk  Wed May 30 08:00:24 2018
From: rhodri at kynesim.co.uk (Rhodri James)
Date: Wed, 30 May 2018 13:00:24 +0100
Subject: Simple question: how do I print output from .get() method
In-Reply-To: <CAPTjJmrvhuMRDu=c0=gTeH3G3iRYj3GMkABt6P_dgS5CxSeN6w@mail.gmail.com>
References: <6e98879a-922d-47a1-94be-cd1c354569e3@googlegroups.com>
 <CAPTjJmrvhuMRDu=c0=gTeH3G3iRYj3GMkABt6P_dgS5CxSeN6w@mail.gmail.com>
Message-ID: <726aaf7f-e62b-117d-13fd-85f8b04ba0ca@kynesim.co.uk>

On 30/05/18 06:51, Chris Angelico wrote:
> On Wed, May 30, 2018 at 3:44 PM, MrMagoo2018 <Ronaldon2018 at gmail.com> wrote:
>> Hello folks, imagine I have the code below and I am getting the "error" message when attempting to print() the output of 'sw_report'.
>> Can you suggest which method I should use to retrieve this? Is that a dictionary maybe?
>>
>> from arista import arista
>> m = arista()
>> m.authenticate ("user","password")
>> sw_report = m.np.sw_report.get("swType="EOS",swMajorVersion="5.0")
>> print (sw_report)
>> <generator object arista._result_iterate at 0x7fdb30f0af10>
> 
> That's not an error message. You asked Python to print it out, and it
> printed it out. As it happens, the display isn't particularly useful,
> but it's not an error.
> 
> What you have is a *generator object*, which is something you can
> iterate over. I don't know about the arista library, so I don't know
> what you'll get from that, but at its simplest, you could convert that
> to a list:
> 
> print(list(sw_report))

Be aware that if you do this, you will exhaust the generator and won't 
be able to use it anywhere else.

 >>> def foo():
...     yield 1
...     yield 2
...     yield 3
...
 >>> l = foo()
 >>> print(l)
<generator object foo at 0x7f9010223150>
 >>> print(list(l))
[1, 2, 3]
 >>> print(list(l))
[]


-- 
Rhodri James *-* Kynesim Ltd


From steve+comp.lang.python at pearwood.info  Wed May 30 08:55:39 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Wed, 30 May 2018 12:55:39 +0000 (UTC)
Subject: Problem with OrderedDict
References: <peloc4$o31$1@blaine.gmane.org> <pelp84$8p3$1@blaine.gmane.org>
Message-ID: <pem70a$lm6$1@blaine.gmane.org>

On Wed, 30 May 2018 05:03:02 -0400, Terry Reedy wrote:

> On 5/30/2018 4:48 AM, Frank Millman wrote:
>> Hi all
>> 
>> I want to work backwards to solve this problem, so I have to explain it
>> forwards to put you in the picture.
>> 
>> I have an Ordered Dictionary. Under certain circumstances I am getting
>> this error -
>> 
>>  ?? RuntimeError: OrderedDict mutated during iteration
> 
> This should mean that the value associated with a key was sometimes
> changed.

I don't think so. It should be legal to iterate over a dict and change 
the values. At least it works for me:

import random
from collections import OrderedDict
d = OrderedDict(zip(range(1, 10), "abcdefghi"))
for i in range(10000):  # just in case of intermittent errors
    for value in d.values():
        d[random.randrange(1, 10)] = random.random()


I get no errors.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson



From steve+comp.lang.python at pearwood.info  Wed May 30 08:59:11 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Wed, 30 May 2018 12:59:11 +0000 (UTC)
Subject: Problem with OrderedDict
References: <peloc4$o31$1@blaine.gmane.org>
Message-ID: <pem76v$lm6$2@blaine.gmane.org>

On Wed, 30 May 2018 10:48:06 +0200, Frank Millman wrote:

> So my first question is, what is the difference between the two error
> messages? I am using an OrderedDict for my test as well, so the
> difference is not caused by using a normal dictionary.

>From Object/orderdict.c I find:

    /* Check for unsupported changes. */
    if (di->di_odict->od_state != di->di_state) {
        PyErr_SetString(PyExc_RuntimeError,
                        "OrderedDict mutated during iteration");
        goto done;
    }
    if (di->di_size != PyODict_SIZE(di->di_odict)) {
        PyErr_SetString(PyExc_RuntimeError,
                        "OrderedDict changed size during iteration");
        di->di_size = -1; /* Make this state sticky */
        return NULL;
    }


but I have no idea what that means :-)



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson



From songofacandy at gmail.com  Wed May 30 09:05:52 2018
From: songofacandy at gmail.com (INADA Naoki)
Date: Wed, 30 May 2018 22:05:52 +0900
Subject: Problem with OrderedDict
In-Reply-To: <peloc4$o31$1@blaine.gmane.org>
References: <peloc4$o31$1@blaine.gmane.org>
Message-ID: <CAEfz+TycstntQYrhcoUB+HOKS+M+Hruc+Q6Tt4XhjF_TdzVWHA@mail.gmail.com>

> However, the error seems to be intermittent - there are times when it
should
> fail, but does not - so I want to investigate further.


CPython raise RuntimeError *by chance*.
Detecting all invalid usage will increase runtime cost.
So CPython may and may not raise RuntimeError.

> I tried to reduce it to a simple example. I succeeded, but there are two
> problems -

> 1. It always fails, so I have not reproduced the intermittent nature yet.

> 2. It gives a different error -

>      RuntimeError: dictionary changed size during iteration

> So my first question is, what is the difference between the two error
> messages?

2nd error will happen when internal hash table is rebuilt while iterating.
If you read C source code, you can expect when it happens.

-- 
INADA Naoki  <songofacandy at gmail.com>


From rosuav at gmail.com  Wed May 30 09:05:53 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 30 May 2018 23:05:53 +1000
Subject: Problem with OrderedDict
In-Reply-To: <pem70a$lm6$1@blaine.gmane.org>
References: <peloc4$o31$1@blaine.gmane.org> <pelp84$8p3$1@blaine.gmane.org>
 <pem70a$lm6$1@blaine.gmane.org>
Message-ID: <CAPTjJmr2osyB00Z=m4Pd7EvvSE4HUANqZzN5tRq=25i94H64CQ@mail.gmail.com>

On Wed, May 30, 2018 at 10:55 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Wed, 30 May 2018 05:03:02 -0400, Terry Reedy wrote:
>
>> On 5/30/2018 4:48 AM, Frank Millman wrote:
>>> Hi all
>>>
>>> I want to work backwards to solve this problem, so I have to explain it
>>> forwards to put you in the picture.
>>>
>>> I have an Ordered Dictionary. Under certain circumstances I am getting
>>> this error -
>>>
>>>     RuntimeError: OrderedDict mutated during iteration
>>
>> This should mean that the value associated with a key was sometimes
>> changed.
>
> I don't think so. It should be legal to iterate over a dict and change
> the values. At least it works for me:
>
> import random
> from collections import OrderedDict
> d = OrderedDict(zip(range(1, 10), "abcdefghi"))
> for i in range(10000):  # just in case of intermittent errors
>     for value in d.values():
>         d[random.randrange(1, 10)] = random.random()
>
>
> I get no errors.
>

You can always change the *values*, but not the *order* of the keys.

>>> from collections import OrderedDict
>>> d = OrderedDict(zip(range(1, 10), "abcdefghi"))
>>> for x in d:
...   if x == 5: d.move_to_end(x)
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: OrderedDict mutated during iteration

ChrisA


From steve+comp.lang.python at pearwood.info  Wed May 30 09:16:05 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Wed, 30 May 2018 13:16:05 +0000 (UTC)
Subject: Problem with OrderedDict
References: <peloc4$o31$1@blaine.gmane.org> <pelp84$8p3$1@blaine.gmane.org>
 <pem70a$lm6$1@blaine.gmane.org>
 <CAPTjJmr2osyB00Z=m4Pd7EvvSE4HUANqZzN5tRq=25i94H64CQ@mail.gmail.com>
Message-ID: <pem86l$lm6$3@blaine.gmane.org>

On Wed, 30 May 2018 23:05:53 +1000, Chris Angelico wrote:

> You can always change the *values*, but not the *order* of the keys.

Okay, so far we have these operations which are allowed:

- changing a value associated with a key

and these operations which all raise RuntimeError with the "mutated" 
error message:

- changing the position of a key;

- deleting a key (using either del or popitem);

- adding a new key;

- deleting a key and adding it back again;

- deleting a key and adding a new key.

This is the only thing I've found so far that gives the "changed size" 
error message:

- clearing the dictionary with d.clear()


Phew! I was starting to think Frank was imagining it, and that the 
"changed size" test was dead code :-)



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson



From steve+comp.lang.python at pearwood.info  Wed May 30 09:18:32 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Wed, 30 May 2018 13:18:32 +0000 (UTC)
Subject: Problem with OrderedDict
References: <peloc4$o31$1@blaine.gmane.org>
Message-ID: <pem8b8$lm6$4@blaine.gmane.org>

On Wed, 30 May 2018 10:48:06 +0200, Frank Millman wrote:

> I tried to reduce it to a simple example. I succeeded, but there are two
> problems -
> 
> 1. It always fails, so I have not reproduced the intermittent nature
> yet.
> 
> 2. It gives a different error -
> 
>     RuntimeError: dictionary changed size during iteration


Can you share your simple example?



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson



From frank at chagford.com  Wed May 30 10:32:29 2018
From: frank at chagford.com (Frank Millman)
Date: Wed, 30 May 2018 16:32:29 +0200
Subject: Problem with OrderedDict
In-Reply-To: <pem8b8$lm6$4@blaine.gmane.org>
References: <peloc4$o31$1@blaine.gmane.org> <pem8b8$lm6$4@blaine.gmane.org>
Message-ID: <pemchs$r12$1@blaine.gmane.org>

"Steven D'Aprano"  wrote in message news:pem8b8$lm6$4 at blaine.gmane.org...
>
> On Wed, 30 May 2018 10:48:06 +0200, Frank Millman wrote:
>
> > I tried to reduce it to a simple example. I succeeded, but there are two
> > problems -
> >
> > 1. It always fails, so I have not reproduced the intermittent nature
> > yet.
> >
> > 2. It gives a different error -
> >
> >     RuntimeError: dictionary changed size during iteration
>
>
> Can you share your simple example?
>

I can, but I actually found my error.

I habitually type -
    from collections import OrderedDict as OD
and
    from collections import defaultdict as DD

My fingers typed the second version by mistake (my brain had nothing to do 
with it!).

Now that I am using the correct version, I consistently get the 'OrderedDict 
mutated during iteration' message.

So working backwards, I have solved the first problem. I am no nearer to 
figuring out why it fails intermittently in my live program. The message 
from INADA Naoki suggests that it could be inherent in CPython, but I am not 
ready to accept that as an answer yet. I will keep plugging away and report 
back with any findings.

Frank




From songofacandy at gmail.com  Wed May 30 11:21:54 2018
From: songofacandy at gmail.com (INADA Naoki)
Date: Thu, 31 May 2018 00:21:54 +0900
Subject: Problem with OrderedDict
In-Reply-To: <pemchs$r12$1@blaine.gmane.org>
References: <peloc4$o31$1@blaine.gmane.org> <pem8b8$lm6$4@blaine.gmane.org>
 <pemchs$r12$1@blaine.gmane.org>
Message-ID: <CAEfz+TwK-rOux=LU3oSA3H89H1S7oZi45X0dASj1Va5nCavt-Q@mail.gmail.com>

>
> So working backwards, I have solved the first problem. I am no nearer to
> figuring out why it fails intermittently in my live program. The message
> from INADA Naoki suggests that it could be inherent in CPython, but I am
not
> ready to accept that as an answer yet. I will keep plugging away and
report
> back with any findings.
>

C implementation of OrderedDict checks
?all ?
"key change"
?(remove or insert key) ?
while iteration always.
But you can bypass the check by using dict methods
?.

Both of dict and OrdredDict checks size is not changed from start of
iteration.
So dict can't detect "remove + insert".

>>> od = collections.OrderedDict.fromkeys("abc")
>>> for k in od:
...     if k == "b":
...         del od["a"]
...         od["a"] = "new"
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: OrderedDict mutated during iteration
>>> d = dict.fromkeys("abc")
>>> for k in d:
...     if k == "b":
...         del d["a"]
...         d["a"] = "new"
...
>>> d
{'b': None, 'c': None, 'a': 'new'}


BTW, ?y
our original mail said "RuntimeError: dictionary changed size during
iteration".
Since it says "dictionary", the error was raised from dict, not
OrderedDict.?
You won't see "OrderedDict changed size" in normal code, because
OrderedDict checks all mutations.

>>> od = collections.OrderedDict.fromkeys("abc")
>>> for k in od:
...     if k == "b":
...         dict.__setitem__(od, "d", None)  # bypass OrderedDict checks
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: OrderedDict changed size during iteration



Currently, dict doesn't detect remove + insert.  But the Python language
doesn't permit it.

Learning these implementation detail should be just for a hobby, or for
developing Python interpreter.
When programming in Python, you should avoid these implementation details.

Regards,


From chris at withers.org  Wed May 30 11:58:59 2018
From: chris at withers.org (Chris Withers)
Date: Wed, 30 May 2018 16:58:59 +0100
Subject: MailingLogger 5.0.0 Released!
Message-ID: <b54505f4-042f-1c75-a57d-fe9dde87eab6@withers.org>

Hi All,

I'm pleased to announce the release of MailingLogger 5.0.0.

Mailinglogger provides two handlers for the standard python
logging framework that enable log entries to be emailed either as the
entries are logged or as a summary at the end of the running process.

The handlers have the following features:

- customisable and dynamic subject lines for emails sent

- emails sent with a configurable headers for easy filtering

- flood protection to ensure the number of emails sent is not excessive

- support for SMTP servers that require authentication

- fully documented and tested

This release primarily adds support for Python 3.

Thanks to Max Shepherd for breaking the back of the Python 3 work.

Full docs can be found here:

http://mailinglogger.readthedocs.io/en/latest/

For more information, please see:

https://github.com/Simplistix/mailinglogger/

cheers,

Chris


From rgaddi at highlandtechnology.invalid  Wed May 30 13:02:06 2018
From: rgaddi at highlandtechnology.invalid (Rob Gaddi)
Date: Wed, 30 May 2018 10:02:06 -0700
Subject: Pink Floyd: is there anybody in here?
In-Reply-To: <87vab52jcq.fsf@nightsong.com>
References: <87vab52jcq.fsf@nightsong.com>
Message-ID: <pemlef$dj8$1@dont-email.me>

On 05/30/2018 09:34 AM, Paul Rubin wrote:
> I think Usenet posts are no longer getting forwarded to the mailing
> list, but now I wonder if this is getting out at all, even to usenet.
> 
> Does anyone see it?
> 

Can't speak for the mailing list, but this came out to Usenet just fine.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.


From tallpaul at gmail.com  Wed May 30 13:35:07 2018
From: tallpaul at gmail.com (Paul)
Date: Wed, 30 May 2018 10:35:07 -0700
Subject: Pink Floyd: is there anybody in here?
In-Reply-To: <pemlef$dj8$1@dont-email.me>
References: <87vab52jcq.fsf@nightsong.com> <pemlef$dj8$1@dont-email.me>
Message-ID: <CA+og5uozGp1Ka4P0yWbPAx1bVDtxpVWrSDV7M-=hDDbA7s2Qgg@mail.gmail.com>

I see it on the mailing list.
Paul C

On Wed, May 30, 2018, 10:07 AM Rob Gaddi <rgaddi at highlandtechnology.invalid>
wrote:

> On 05/30/2018 09:34 AM, Paul Rubin wrote:
> > I think Usenet posts are no longer getting forwarded to the mailing
> > list, but now I wonder if this is getting out at all, even to usenet.
> >
> > Does anyone see it?
> >
>
> Can't speak for the mailing list, but this came out to Usenet just fine.
>
> --
> Rob Gaddi, Highland Technology -- www.highlandtechnology.com
> Email address domain is currently out of order.  See above to fix.
> --
> https://mail.python.org/mailman/listinfo/python-list
>


From __peter__ at web.de  Wed May 30 14:29:10 2018
From: __peter__ at web.de (Peter Otten)
Date: Wed, 30 May 2018 20:29:10 +0200
Subject: Pink Floyd: is there anybody in here?
References: <87vab52jcq.fsf@nightsong.com> <pemlef$dj8$1@dont-email.me>
Message-ID: <pemqdj$l7b$1@blaine.gmane.org>

Rob Gaddi wrote:

> On 05/30/2018 09:34 AM, Paul Rubin wrote:
>> I think Usenet posts are no longer getting forwarded to the mailing
>> list, but now I wonder if this is getting out at all, even to usenet.
>> 
>> Does anyone see it?
>> 
> 
> Can't speak for the mailing list, but this came out to Usenet just fine.
> 

The original did not appear on gmane.



From email at paulstgeorge.com  Wed May 30 16:01:35 2018
From: email at paulstgeorge.com (Paul St George)
Date: Wed, 30 May 2018 22:01:35 +0200
Subject: The PIL show() method looks for the default viewer. How
 do I change this to a different viewer (of my choice)?
In-Reply-To: <CALwzidnnwovzuk7jZr+1obHOa+w2FQJughe1DHVU4Auduvqe1w@mail.gmail.com>
References: <ddedae8b-f085-dfa3-08a4-2c821975cc61@paulstgeorge.com>
 <CANDiX9+fF3ADqhee50RA47hecQRpsOVJjXML9=OAYzkAp9gNqw@mail.gmail.com>
 <0efaafaa-064f-726a-416f-9dc9d0756667@paulstgeorge.com>
 <CALwzidnnwovzuk7jZr+1obHOa+w2FQJughe1DHVU4Auduvqe1w@mail.gmail.com>
Message-ID: <770eb1b5-d8ad-140f-50e8-5206cb95f058@paulstgeorge.com>

True, but I wanted to have some control over the image window, 
fullscreen, colour depth, etc. I am also exploring pygame. I will try 
your suggestion as it is so much simpler.

Being a novice, I had been frightened off using shell=True. See 
<https://docs.python.org/2/library/subprocess.html#frequently-used-arguments>.

Is this equivalent?
p = subprocess.Popen('display',? + imagepath)

so

p = subprocess.Popen('display',? 'test.png')





On 30/05/2018 03:04, Ian Kelly wrote:
> On Sat, May 26, 2018 at 9:17 AM, Paul St George <email at paulstgeorge.com> wrote:
>> Thank you.
>> You are very right. The show() method is intended for debugging purposes and
>> is useful for that, but what method should I be using and is PIL the best
>> imaging library for my purposes? I do not want to manipulate images, I only
>> want to show images (full screen) on an external display. I want to use
>> Python to control the timing of the images.
> You probably shouldn't be using PIL at all then. Why open the file in
> Python just to export it and re-open it in an image viewer? It would
> be simpler just to point whichever image viewer you prefer at the
> original file directly. Your entire script could just be something
> like this:
>
> import subprocess
>
> # Some timing logic
>
> subprocess.call("display " + imagepath, shell=True)
>

-- 
Paul St George
http://www.paulstgeorge.com
http://www.devices-of-wonder.com

+44(0)7595 37 1302



From email at paulstgeorge.com  Wed May 30 16:08:45 2018
From: email at paulstgeorge.com (Paul St George)
Date: Wed, 30 May 2018 22:08:45 +0200
Subject: The PIL show() method looks for the default viewer. How do I
 change this to a different viewer (of my choice)?
In-Reply-To: <pekrcq$sr1$2@blaine.gmane.org>
References: <ddedae8b-f085-dfa3-08a4-2c821975cc61@paulstgeorge.com>
 <CANDiX9+fF3ADqhee50RA47hecQRpsOVJjXML9=OAYzkAp9gNqw@mail.gmail.com>
 <0efaafaa-064f-726a-416f-9dc9d0756667@paulstgeorge.com>
 <pec4bf$3a7$1@blaine.gmane.org>
 <6d5f6b18-99ac-cc6f-8cfb-0caf23224c51@paulstgeorge.com>
 <peitjc$jjq$1@blaine.gmane.org>
 <083a74fd-94c0-8cae-c052-17205a1b9f7b@paulstgeorge.com>
 <pekrcq$sr1$2@blaine.gmane.org>
Message-ID: <34d564d7-b6f3-5fa8-9abd-269b63887889@paulstgeorge.com>

Ha! No, my question was clumsy.

If I know the name of the viewer that I want to use (say for example: 
?ImageMagick?), where do I find the argument that should be used in a 
line of code such as this:

ImageShow.register(MyViewer("gwenview"), -1)

I want to replace ?gwenview? with the name of my favourite viewer (for 
example: ?ImageMagick?).



On 30/05/2018 02:31, Steven D'Aprano wrote:
> On Tue, 29 May 2018 20:02:22 +0200, Paul St George wrote:
>
>> Is there, somewhere, a list of viewers and their names (for the purposes
>> of this script)?
> Do you mean a list of programs capable of viewing graphics? Do you think
> there is some sort of central authority that registers the names of all
> such programs? *wink*
>
>
> You can start here:
>
> https://en.wikipedia.org/wiki/Category:Graphics_software
>
> but that's probably the closest you're going to get.
>
>
>

-- 
Paul St George
http://www.paulstgeorge.com
http://www.devices-of-wonder.com

+44(0)7595 37 1302



From python at mrabarnett.plus.com  Wed May 30 16:29:39 2018
From: python at mrabarnett.plus.com (MRAB)
Date: Wed, 30 May 2018 21:29:39 +0100
Subject: The PIL show() method looks for the default viewer. How do I
 change this to a different viewer (of my choice)?
In-Reply-To: <770eb1b5-d8ad-140f-50e8-5206cb95f058@paulstgeorge.com>
References: <ddedae8b-f085-dfa3-08a4-2c821975cc61@paulstgeorge.com>
 <CANDiX9+fF3ADqhee50RA47hecQRpsOVJjXML9=OAYzkAp9gNqw@mail.gmail.com>
 <0efaafaa-064f-726a-416f-9dc9d0756667@paulstgeorge.com>
 <CALwzidnnwovzuk7jZr+1obHOa+w2FQJughe1DHVU4Auduvqe1w@mail.gmail.com>
 <770eb1b5-d8ad-140f-50e8-5206cb95f058@paulstgeorge.com>
Message-ID: <31bf47c5-f117-3291-9564-1e4147a742bb@mrabarnett.plus.com>

On 2018-05-30 21:01, Paul St George wrote:
> True, but I wanted to have some control over the image window,
> fullscreen, colour depth, etc. I am also exploring pygame. I will try
> your suggestion as it is so much simpler.
> 
> Being a novice, I had been frightened off using shell=True. See
> <https://docs.python.org/2/library/subprocess.html#frequently-used-arguments>.
> 
> Is this equivalent?
> p = subprocess.Popen('display',? + imagepath)
> 
p = subprocess.Popen(['display',  imagepath])

> so
> 
> p = subprocess.Popen('display',? 'test.png')
> 
p = subprocess.Popen(['display',  'test.png'])

Remembering to provide the full paths (unless it's/they're on the 
system's search path).

> 
> On 30/05/2018 03:04, Ian Kelly wrote:
>> On Sat, May 26, 2018 at 9:17 AM, Paul St George <email at paulstgeorge.com> wrote:
>>> Thank you.
>>> You are very right. The show() method is intended for debugging purposes and
>>> is useful for that, but what method should I be using and is PIL the best
>>> imaging library for my purposes? I do not want to manipulate images, I only
>>> want to show images (full screen) on an external display. I want to use
>>> Python to control the timing of the images.
>> You probably shouldn't be using PIL at all then. Why open the file in
>> Python just to export it and re-open it in an image viewer? It would
>> be simpler just to point whichever image viewer you prefer at the
>> original file directly. Your entire script could just be something
>> like this:
>>
>> import subprocess
>>
>> # Some timing logic
>>
>> subprocess.call("display " + imagepath, shell=True)
>>
> 



From ben.usenet at bsb.me.uk  Wed May 30 16:53:05 2018
From: ben.usenet at bsb.me.uk (Ben Bacarisse)
Date: Wed, 30 May 2018 21:53:05 +0100
Subject: Pink Floyd: is there anybody in here?
References: <87vab52jcq.fsf@nightsong.com> <pemlef$dj8$1@dont-email.me>
Message-ID: <87efhs27da.fsf@bsb.me.uk>

Rob Gaddi <rgaddi at highlandtechnology.invalid> writes:

> On 05/30/2018 09:34 AM, Paul Rubin wrote:
>> I think Usenet posts are no longer getting forwarded to the mailing
>> list, but now I wonder if this is getting out at all, even to usenet.
>>
>> Does anyone see it?
>
> Can't speak for the mailing list, but this came out to Usenet just
> fine.

Snap.  The original and the reply.

-- 
Ben.


From hjp-python at hjp.at  Wed May 30 17:01:17 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Wed, 30 May 2018 23:01:17 +0200
Subject: The PIL show() method looks for the default viewer. How do I
 change this to a different viewer (of my choice)?
In-Reply-To: <34d564d7-b6f3-5fa8-9abd-269b63887889@paulstgeorge.com>
References: <ddedae8b-f085-dfa3-08a4-2c821975cc61@paulstgeorge.com>
 <CANDiX9+fF3ADqhee50RA47hecQRpsOVJjXML9=OAYzkAp9gNqw@mail.gmail.com>
 <0efaafaa-064f-726a-416f-9dc9d0756667@paulstgeorge.com>
 <pec4bf$3a7$1@blaine.gmane.org>
 <6d5f6b18-99ac-cc6f-8cfb-0caf23224c51@paulstgeorge.com>
 <peitjc$jjq$1@blaine.gmane.org>
 <083a74fd-94c0-8cae-c052-17205a1b9f7b@paulstgeorge.com>
 <pekrcq$sr1$2@blaine.gmane.org>
 <34d564d7-b6f3-5fa8-9abd-269b63887889@paulstgeorge.com>
Message-ID: <20180530210117.d3rtjiv62sulckyn@hjp.at>

On 2018-05-30 22:08:45 +0200, Paul St George wrote:
> Ha! No, my question was clumsy.
> 
> If I know the name of the viewer that I want to use (say for example:
> ?ImageMagick?), where do I find the argument that should be used in a line
> of code such as this:
> 
> ImageShow.register(MyViewer("gwenview"), -1)
> 
> I want to replace ?gwenview? with the name of my favourite viewer (for
> example: ?ImageMagick?).

If your favourite viewer is 'ImageMagick?, then the name is
'ImageMagick'. However, I doubt this is the case, since ImageMagick
isn't a viewer, it is a collection of programs for manipulating images.
The viewer included in the ImageMagick package is simply called
'display' (and it is already the default viewer in PIL, so you don't
have to do anything to use it).

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180530/dfca5fb4/attachment.sig>

From Karsten.Hilbert at gmx.net  Wed May 30 17:09:32 2018
From: Karsten.Hilbert at gmx.net (Karsten Hilbert)
Date: Wed, 30 May 2018 23:09:32 +0200
Subject: The PIL show() method looks for the default viewer. How do I
 change this to a different viewer (of my choice)?
In-Reply-To: <20180530210117.d3rtjiv62sulckyn@hjp.at>
References: <ddedae8b-f085-dfa3-08a4-2c821975cc61@paulstgeorge.com>
 <CANDiX9+fF3ADqhee50RA47hecQRpsOVJjXML9=OAYzkAp9gNqw@mail.gmail.com>
 <0efaafaa-064f-726a-416f-9dc9d0756667@paulstgeorge.com>
 <pec4bf$3a7$1@blaine.gmane.org>
 <6d5f6b18-99ac-cc6f-8cfb-0caf23224c51@paulstgeorge.com>
 <peitjc$jjq$1@blaine.gmane.org>
 <083a74fd-94c0-8cae-c052-17205a1b9f7b@paulstgeorge.com>
 <pekrcq$sr1$2@blaine.gmane.org>
 <34d564d7-b6f3-5fa8-9abd-269b63887889@paulstgeorge.com>
 <20180530210117.d3rtjiv62sulckyn@hjp.at>
Message-ID: <20180530210931.GA2258@hermes.hilbert.loc>

On Wed, May 30, 2018 at 11:01:17PM +0200, Peter J. Holzer wrote:

> On 2018-05-30 22:08:45 +0200, Paul St George wrote:
> > Ha! No, my question was clumsy.
> > 
> > If I know the name of the viewer that I want to use (say for example:
> > ?ImageMagick?), where do I find the argument that should be used in a line
> > of code such as this:
> > 
> > ImageShow.register(MyViewer("gwenview"), -1)

	$> man -k ImageMagick
	$> man whatever_you_found_with_the_above

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


From hjp-python at hjp.at  Wed May 30 17:10:44 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Wed, 30 May 2018 23:10:44 +0200
Subject: cProfile, timed call tree
In-Reply-To: <87wovlzogs.fsf@handshake.de>
References: <CAK6Z60du+GX5iUmjfFQZz4bxSKifUQZ8hAa4vGf8qFTsOtaOXg@mail.gmail.com>
 <87in7b3rjy.fsf@handshake.de>
 <20180529100258.4wpn2gexmjfhtw5u@hjp.at>
 <87wovlzogs.fsf@handshake.de>
Message-ID: <20180530211044.52u4g6lou7vkhdfc@hjp.at>

On 2018-05-30 07:45:07 +0200, dieter wrote:
> "Peter J. Holzer" <hjp-python at hjp.at> writes:
> > On 2018-05-26 07:38:09 +0200, dieter wrote:
> >> But, in general, you are right: you cannot reconstruct complete
> >> call trees. The reason is quite simple: maintaining information
> >> for the complete caller ancestry (rather than just the immediate
> >> caller) is expensive (both in terms of runtime and storage).
> >> Profiling usually is used as a preparation for optimization.
> >> Optimization has the greatest effects if applied to inner loops.
> >> And for the analysis of inner loops, complete call tree information
> >> is not necessary.
> >
> > I disagree. I have used Tim Bunce's excellent perl profiler
> > (Devel::NYTProf, for the two people here who also use Perl and don't
> > already know it), which does record whole call trees, and this is very
> > useful. You not only see that a function is called 1.5 million times,
> > you also see where it is called (not just from which functions, but from
> > which lines) and how much time is spent in calls from each location. 
> > Often this allowed me find ways to avoid calling a function altogether
> > or prevented me from chasing down the wrong rabbit hole.
> 
> If the profile information is sampled for the call location (rather then
> the call function), you still do not get the "complete call tree".
> If you want to get results based on call paths (rather than the immediate
> caller), the sampling must (in general) sample for call paths (and
> not only the immediate caller) -- which means, you must implement
> your own profiler.

I don't dispute that you would have to implement your own profiler.
I do dispute that this information is useless. As I said, I have used
Devel::NYTProf for Perl, and after using that cProfile feels like a huge
step backwards. There are some areas where Python is ahead of Perl, but
the profiler definitely isn't one of them :-(.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180530/9f36de34/attachment.sig>

From hjp-python at hjp.at  Wed May 30 17:21:46 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Wed, 30 May 2018 23:21:46 +0200
Subject: a Python bug report
In-Reply-To: <20180530013421.GA11551@equipaje>
References: <822990BCB7F3DD47806E56C8771DCC79017790A8E1@US01WEMBX2.internal.synopsys.com>
 <20180530013421.GA11551@equipaje>
Message-ID: <20180530212146.3risulijwavpp5ut@hjp.at>

On 2018-05-29 21:34:21 -0400, Jos? Mar?a Mateos wrote:
> On Wed, May 30, 2018 at 01:07:38AM +0000, Ruifeng Guo wrote:
> > We encountered a bug in Python recently, we checked the behavior for Python version 2.7.12, and 3.1.1, both version show the same behavior. Please see below the unexpected behavior in "red text".
[...]
> In [3]: 1000 * 1.017
> Out[3]: 1016.9999999999999
> 
> So there you have it.

To expand a bit on that, the reason, why 1000 * 1.017 isn't 1017 isn't
that an x86 processor can't multiply, it is that 1017/1000 cannot be exactly
represented in a binary fraction (just like 1/7 cannot be exactly
represented in a decimal fraction).

So when you type 1.017, the computer really stores
1.016999999999999904076730672386474907398223876953125 and when you
multiply that by 1000, the result would be
1016.999999999999904076730672386474907398223876953125, but that needs a
few bits too much, so it rounded down to
1016.9999999999998863131622783839702606201171875.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180530/239215a8/attachment.sig>

From hjp-python at hjp.at  Wed May 30 17:32:15 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Wed, 30 May 2018 23:32:15 +0200
Subject: Pink Floyd: is there anybody in here?
In-Reply-To: <pemlef$dj8$1@dont-email.me>
References: <87vab52jcq.fsf@nightsong.com>
 <pemlef$dj8$1@dont-email.me>
Message-ID: <20180530213215.6oaot222ifmgpryu@hjp.at>

On 2018-05-30 10:02:06 -0700, Rob Gaddi wrote:
> On 05/30/2018 09:34 AM, Paul Rubin wrote:
> > I think Usenet posts are no longer getting forwarded to the mailing
> > list, but now I wonder if this is getting out at all, even to usenet.
> > 
> > Does anyone see it?
> > 
> 
> Can't speak for the mailing list, but this came out to Usenet just fine.

I see your posting on the mailing list, but not Paul Rubin's.
Looking back through my archive, I don't see any posting by Paul (but
quite a few followups to his), so his postings are probably filtered for
some reason.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180530/93029766/attachment.sig>

From hjp-python at hjp.at  Wed May 30 18:08:19 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Thu, 31 May 2018 00:08:19 +0200
Subject: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in
 position 10442: character maps to <undefined>
In-Reply-To: <pejukj$sr1$1@blaine.gmane.org>
References: <20180522223103.fmym5wsmvr7vaua3@hjp.at>
 <CAPTjJmo5X-+v0RG5a-3KX4NVDpd_6hyjJHmnCf7t2An8H43tGA@mail.gmail.com>
 <20180529081528.v7esb22ccgmksmvd@hjp.at>
 <CAPTjJmrqoLWToz+7w8qEuFKS7xaVAr4tjC6j5fHGDhkjDuZQuw@mail.gmail.com>
 <20180529100918.pymciog6ahuronan@hjp.at>
 <CAPTjJmpnQmkcZESGnK=micKbZz4t8UA4BvpZdChkWbcEArvPvQ@mail.gmail.com>
 <20180529105929.xebyilz4mgsl42ar@hjp.at>
 <CAPTjJmqpFWkuN+UQyNchmHv8qRsLOGMynTwzmMde5w2BVyiBPg@mail.gmail.com>
 <20180529120419.6ncjlbefvkisezvy@hjp.at>
 <pejukj$sr1$1@blaine.gmane.org>
Message-ID: <20180530220819.q5ocvjza4bpsx2py@hjp.at>

On 2018-05-29 16:20:36 +0000, Steven D'Aprano wrote:
> On Tue, 29 May 2018 14:04:19 +0200, Peter J. Holzer wrote:
> 
> > The OP has one file. 
> 
> We don't know that. All we know is that he had one file which he was 
> unable to read. For all we know, he has a million files, and this was 
> merely the first of many failures.

This is of course possible. It is also possible that the file is updated
daily and the person updating the file is always choosing a random
encoding[2], so his program will always fail the next day. 

But that isn't what he has told us. And I don't find it very helpful to
invent some specific scenario and base the answers on that invented
scenario instead of what the OP has told us.


> > He wants to read it. The very fact that he wants to
> > read this particular file makes it very likely that he knows something
> > about the contents of the file. So he has domain knowledge.
> 
> An unjustified assumption. I've wanted to read many files with only the 
> vaguest guess of what they might contain.
> 
> As for his domain knowledge, look again at the OP's post. His solution 
> was to paper over the error, make the error go away, by moving to Python 
> 2 which is more lax about getting the encoding right:

By "domain knowledge" I didn't mean knowledge of Python or encodings. I
meant knowledge about whatever the contents of the file are about.

My users (mostly) have no idea what an "encoding" is. But they know what
their data is about, and can tell me whether an unidentified character
in the "unit" field is a ? or a ?[1] (and also whether the value is
nominal or real or PPP-adjusted and lots of other stuff I don't need to
know to determine the encoding but may (or may not) need to import the
data correctly).


> "i actually got my script to function by running it in python 2.7"
> 
> So he didn't identify the correct encoding,

No, but just because he didn't doesn't mean it is impossible.

        hp

[1] I don't know if there are actually two encodings where these two
    have the same encoding. This is an invented example.

[2] BTDT (almost).

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180531/dbdc104c/attachment.sig>

From hjp-python at hjp.at  Wed May 30 18:47:33 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Thu, 31 May 2018 00:47:33 +0200
Subject: Indented multi-line strings (was: "Data blocks" syntax
 specification draft)
In-Reply-To: <CALwzidkQQshcfDfqzONtP18D4c7QshsPeaXfArWQUt=2SxoyFQ@mail.gmail.com>
References: <CAHiMU6cGz=X4LMcYac=_Us0+9ATPTrJPLZaeXmK07KbnNFSP2A@mail.gmail.com>
 <CAE6NSRA9sNDkL2RgpaUnziRv5ka2j_L4y1rScKoLJSnR+KCXpg@mail.gmail.com>
 <mailman.4.1526955481.18022.python-list@python.org>
 <pe0bn1$8ns$1@dont-email.me>
 <CAE6NSRA4=wxwAWCXpJg9sXZgdDrFY5GN8_JybYg1zwgi-aYCQQ@mail.gmail.com>
 <9bf0783c8b044b348769942bda950043@F5.com>
 <20180523162535.xbtqnxi7yqv4ijlg@hjp.at>
 <CALwzidnMYFyxM5cqHZVpEd4KBDx-E51Gzx2gvhMuyPgx90PD9A@mail.gmail.com>
 <20180529091919.xxr7rt5yoplwdge6@hjp.at>
 <CALwzidkQQshcfDfqzONtP18D4c7QshsPeaXfArWQUt=2SxoyFQ@mail.gmail.com>
Message-ID: <20180530224733.6qai7jsw4bknkukr@hjp.at>

On 2018-05-29 07:57:18 -0600, Ian Kelly wrote:
> On Tue, May 29, 2018 at 3:19 AM, Peter J. Holzer <hjp-python at hjp.at> wrote:
> > On 2018-05-23 11:08:48 -0600, Ian Kelly wrote:
> >>

[...]
> > What if I want all lines to start with some white space?
[...]
> 
> Fair points.
[...]

> >> Also, how about using a string prefix character instead of making
> >> quad-quote meaningful? Apart from being hard to visually distinguish
> >> from triple-quote, this would break existing triple-quote strings that
> >> happen to start with the quote character, e.g ''''What?' she asked.'''
> >
> > No confusion here, since in my proposal there is always a newline after
> > the leading delimiter, since otherwise the first line wouldn't line up
> > with the rest. So the parser would notice that this is a triple-quote
> > and not a quad-quote as soon as it sees the "W".
> 
> Then how about a triple-quote string that starts with a quote
> character followed by a newline?

Collateral damage. Seriously, if you write something like this

    s = ''''
            A quoted
            multline
            string
''''

instead of this

    s = """'
            A quoted
            multline
            string
'"""

outside of an obfuscation contest, you get what you deserve.

> >> b = i'''
> >>     Here is a multi-line string
> >>     with indentation, which is
> >>     determined from the second
> >>     line.'''
> >
> > Visually, that letter doesn't look like a part of the quote, so I would
> > like to pull the contents of the string over to align with the quote:
> >
> > b = i'''
> >      Here is a multi-line string
> >      with indentation, which is
> >      determined from the second
> >      line.'''
> >
> > But that creates an ambiguity: Is the whole string now indented one
> > space or not? Where is the left edge?
> 
> I don't follow. In the first case you have a multi-line string where
> every line is indented four spaces, so four spaces are to be removed
> from every line. In the second case you have a multi-line string where
> every line is indented by five spaces, so five spaces are to be
> removed from every line.

Nope. Remember that I want to be able to have *all* lines start with
white space.

So I can't simply strip all the common whitespace.

This is the reason why I want the quote (leading or trailing, preferably
both) to indicate where the left edge of the string is.

For a quad quote this is IMHO unambiguous:

    b = ''''
           Py-
          thon
        ''''

The first line starts with 3 spaces, the second one with 2.

But the prefix makes is visually ambiguous: Is the left edge where the
prefix is or where the first quote character is.

This is of course not a problem if the *trailing* quote determines the
indentation:

    a_multi_line_string = i'''
           Py-
          thon
        '''


> What about the second string would make the algorithm think that four
> spaces are to be removed from every line, leaving one?

Because you have to skip 4 spaces to get below the "i" which starts the
quote.

> Why not remove three, leaving two? Or remove one, leaving
> four? And why is the first string safe from this?

Not sure what you mean by "first string". The way you wrote has either
no leading whitespace (if the "i" signals the left edge) or is a syntax
error (if the first "'" signals the left edge, because then
non-whitespace characters would have to be discarded).

> In any case, Chris made a good point that I agree with. This doesn't
> really need to be syntax at all, but could just be implemented as a
> new string method.

Depending on the details, not quite. A method wouldn't get the
horizontal position of the leading quote. It could infer the position of
the trailing quote, though.

So, yes, it would be possible. And the optimizer might call the method
at compile time instead of runtime. There is still the visual noise,
though.

This is a bit of a pet peeve of mine: It is common to indent code in all
languages invented in the 40 years or so (and even older languages like
Fortran have adopted that convention). But *none*[1] of them has syntax
to let the programmer write multiline strings that are  properly aligned
with the rest of the code. Not even Python, where indentation is part of
the syntax.

[1] I exaggerate. SPL is the one exception I know. And there are
    probably a few other similarly obscure languages.

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180531/a74eb253/attachment.sig>

From cs at cskk.id.au  Wed May 30 19:34:12 2018
From: cs at cskk.id.au (Cameron Simpson)
Date: Thu, 31 May 2018 09:34:12 +1000
Subject: The PIL show() method looks for the default viewer. How do I
 change this to a different viewer (of my choice)?
In-Reply-To: <31bf47c5-f117-3291-9564-1e4147a742bb@mrabarnett.plus.com>
References: <31bf47c5-f117-3291-9564-1e4147a742bb@mrabarnett.plus.com>
Message-ID: <20180530233412.GA73712@cskk.homeip.net>

On 30May2018 21:29, MRAB <python at mrabarnett.plus.com> wrote:
>On 2018-05-30 21:01, Paul St George wrote:
>>Is this equivalent?
>>p = subprocess.Popen('display',? + imagepath)
>>
>p = subprocess.Popen(['display',  imagepath])
>
>>so
>>
>>p = subprocess.Popen('display',? 'test.png')
>>
>p = subprocess.Popen(['display',  'test.png'])
>
>Remembering to provide the full paths (unless it's/they're on the system's 
>search path).

Personally, I am generally against the "use a full path" advice.

Using a full path to the executable is (a) nonportable because executables may 
be in different places on different systems and (b) obstructive to the user, 
because they may have built or installed  their own version of the app for 
specific purposes, such as the vendor provided version being out of date.

For example, Paul's problem might also be addressable by writing his own 
"display" shell script invoking the tool of his choice. Like Python, the 
executable command name is a dynamic lookup!

IMO it is the programme caller's task to provide the execution environment, and 
the programme should expect $PATH (UNIX execution search path) to be suitable 
already.

Every hardwired path is a maintenance and fragility nightmare.

Cheers,
Cameron Simpson <cs at cskk.id.au>


From steve+comp.lang.python at pearwood.info  Wed May 30 20:06:37 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Thu, 31 May 2018 00:06:37 +0000 (UTC)
Subject: Pink Floyd: is there anybody in here?
References: <87vab52jcq.fsf@nightsong.com> <pemlef$dj8$1@dont-email.me>
 <87efhs27da.fsf@bsb.me.uk>
Message-ID: <penead$1f4$1@blaine.gmane.org>

On Wed, 30 May 2018 21:53:05 +0100, Ben Bacarisse wrote:

> Rob Gaddi <rgaddi at highlandtechnology.invalid> writes:
> 
>> On 05/30/2018 09:34 AM, Paul Rubin wrote:
>>> I think Usenet posts are no longer getting forwarded to the mailing
>>> list, but now I wonder if this is getting out at all, even to usenet.
>>>
>>> Does anyone see it?
>>
>> Can't speak for the mailing list, but this came out to Usenet just
>> fine.
> 
> Snap.  The original and the reply.

You shouldn't generalise about Usenet, as individual news servers can and 
do drop messages. In this case, gmane seems to be dropping Paul Rubin's 
posts.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson



From rosuav at gmail.com  Wed May 30 20:12:14 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Thu, 31 May 2018 10:12:14 +1000
Subject: The PIL show() method looks for the default viewer. How do I
 change this to a different viewer (of my choice)?
In-Reply-To: <20180530233412.GA73712@cskk.homeip.net>
References: <31bf47c5-f117-3291-9564-1e4147a742bb@mrabarnett.plus.com>
 <20180530233412.GA73712@cskk.homeip.net>
Message-ID: <CAPTjJmpwZmQo7pRX_5mSPY8QWKL-pz=AOUYnvXRcuV3tw9CzmQ@mail.gmail.com>

On Thu, May 31, 2018 at 9:34 AM, Cameron Simpson <cs at cskk.id.au> wrote:
> On 30May2018 21:29, MRAB <python at mrabarnett.plus.com> wrote:
>>
>> On 2018-05-30 21:01, Paul St George wrote:
>>>
>>> Is this equivalent?
>>> p = subprocess.Popen('display',  + imagepath)
>>>
>> p = subprocess.Popen(['display',  imagepath])
>>
>>> so
>>>
>>> p = subprocess.Popen('display',  'test.png')
>>>
>> p = subprocess.Popen(['display',  'test.png'])
>>
>> Remembering to provide the full paths (unless it's/they're on the system's
>> search path).
>
>
> Personally, I am generally against the "use a full path" advice.
>
> Using a full path to the executable is (a) nonportable because executables
> may be in different places on different systems and (b) obstructive to the
> user, because they may have built or installed  their own version of the app
> for specific purposes, such as the vendor provided version being out of
> date.
>
> For example, Paul's problem might also be addressable by writing his own
> "display" shell script invoking the tool of his choice. Like Python, the
> executable command name is a dynamic lookup!
>
> IMO it is the programme caller's task to provide the execution environment,
> and the programme should expect $PATH (UNIX execution search path) to be
> suitable already.
>
> Every hardwired path is a maintenance and fragility nightmare.

Bless you, it all depends! [1]

A hardwired path is safe against someone externally messing with your
script. But a pathless name allows you to make use of
externally-configured $PATH. Sometimes you want the safety; sometimes
you want the flexibility.

Using just the name is very similar to typing the command at the
shell, but it's not identical to that either; shell aliases can mean
that typing "grep foo bar" is not the same as "`which grep` foo bar".
So it's that bit harder to explain, and you HAVE to want the behaviour
that it gives.

Make an intelligent decision as to whether you want a hard-coded path
or just a name.

ChrisA

[1] I'm on the wrong mailing list to expect everyone to recognize that
line. It's from "The Mikado" by Gilbert & Sullivan.


From jlee54 at gmail.com  Wed May 30 20:50:14 2018
From: jlee54 at gmail.com (Jim Lee)
Date: Wed, 30 May 2018 17:50:14 -0700
Subject: leetv 1.12 released
Message-ID: <c09b8fc3-4f41-ba64-28ed-6349d50382a8@gmail.com>

Hello, python-list members!


This is my first post.? I have created 'leetv', a Python application.? 
You can find it at:


https://github.com/oregonjim/leetv


There are several 'firsts' here (besides my first post...).? This is my 
first time using Github.? This is my first major Python effort, though I 
have been a C/C++/Asm/Embedded developer for several decades.? As a 
result, I'm sure the code is more C-onic than Pythonic at this point.? 
This is a project that I've wanted to do for a long time, as well as 
learn Python, so I combined the two.


Here is a short excerpt from the README:

---

Do you have a large collection of TV shows stored on a hard drive 
somewhere? Have you spent weeks (or months) ripping all your TV and 
movie DVDs to media files? Have you ever wanted a program that could 
take your entire collection and just play it according to a daily 
schedule, all day long, every day (like a real TV station does), without 
requiring you to do anything beyond the initial schedule programming? Do 
you wish you could choose your OWN commercials to play between shows 
(perhaps some memorable favorites from your childhood, or maybe a few of 
those SuperBowl halftime legends) rather than watch the drivel that 
plagues today's television? Want to get rid of Cable because you 
realized that you're paying for 1000 channels worth of stuff that 
doesn't interest you?

That's what LeeTV is for. It's a set-it-and-forget-it application that 
turns an unused computer into an always on, always playing personal TV 
station - one that plays the content YOU want.

My own setup has been running continuously for months now. It requires 
nothing of me. I will occasionally ssh into my LeeTV box to change a 
schedule, or to add a few more commercials that I found on YouTube, but 
that's it. I don't even have to stop or restart anything. It works so 
well that I added a wireless HDMI transmitter so that the signal is 
available on any TV in the house!

---

Thanks for reading,

--Jim Lee




From ben.usenet at bsb.me.uk  Wed May 30 23:02:32 2018
From: ben.usenet at bsb.me.uk (Ben Bacarisse)
Date: Thu, 31 May 2018 04:02:32 +0100
Subject: Pink Floyd: is there anybody in here?
References: <87vab52jcq.fsf@nightsong.com> <pemlef$dj8$1@dont-email.me>
 <87efhs27da.fsf@bsb.me.uk> <penead$1f4$1@blaine.gmane.org>
 <mailman.108.1527725345.2804.python-list@python.org>
Message-ID: <87in74zfw7.fsf@bsb.me.uk>

Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:

> On Wed, 30 May 2018 21:53:05 +0100, Ben Bacarisse wrote:
>
>> Rob Gaddi <rgaddi at highlandtechnology.invalid> writes:
>> 
>>> On 05/30/2018 09:34 AM, Paul Rubin wrote:
>>>> I think Usenet posts are no longer getting forwarded to the mailing
>>>> list, but now I wonder if this is getting out at all, even to usenet.
>>>>
>>>> Does anyone see it?
>>>
>>> Can't speak for the mailing list, but this came out to Usenet just
>>> fine.
>> 
>> Snap.  The original and the reply.
>
> You shouldn't generalise about Usenet, as individual news servers can and 
> do drop messages. In this case, gmane seems to be dropping Paul Rubin's 
> posts.

Was I generalising?  I didn't intend to.  I only meant I saw both on
Usenet.

-- 
Ben.


From nad at python.org  Thu May 31 00:32:14 2018
From: nad at python.org (Ned Deily)
Date: Thu, 31 May 2018 00:32:14 -0400
Subject: [RELEASE] Python 3.7.0b5 bonus beta!
Message-ID: <CC1A7AC5-5D16-4852-A0E5-8CD715AF2C6F@python.org>

A 3.7 update: Python 3.7.0b5 is now the final beta preview of Python 3.7,
the next feature release of Python. 3.7.0b4 was intended to be the final
beta but, due to some unexpected compatibility issues discovered during
beta testing of third-party packages, we decided to revert some changes
in how Python's 3.7 Abstract Syntax Tree parser deals with docstrings;
3.7.0b5 now behaves like 3.6.x and previous releases (refer to the
3.7.0b5 changelog for more information).

**If your code makes use of the ast module, you are strongly encouraged
to test (or retest) that code with 3.7.0b5, especially if you previously
made changes to work with earlier preview versons of 3.7.0.**

As always, please report issues found to bugs.python.org as soon as
possible. Please keep in mind that this is a preview release and its use
is not recommended for production environments. Attention macOS users:
there is now a new installer variant for macOS 10.9+ that includes a
built-in version of Tcl/Tk 8.6. This variant is expected to become the
default version when 3.7.0 releases. Check it out!

The next (and final, we hope!) preview release will be the release
candidate which is now planned for 2018-06-11, followed by the official
release of 3.7.0, now planned for 2018-06-27. You can find Python 3.7.0b5
and more information here:

    https://www.python.org/downloads/release/python-370b5/

--
  Ned Deily
  nad at python.org -- []



From frank at chagford.com  Thu May 31 04:05:43 2018
From: frank at chagford.com (Frank Millman)
Date: Thu, 31 May 2018 10:05:43 +0200
Subject: Problem with OrderedDict - progress report
In-Reply-To: <pemchs$r12$1@blaine.gmane.org>
References: <peloc4$o31$1@blaine.gmane.org> <pem8b8$lm6$4@blaine.gmane.org>
 <pemchs$r12$1@blaine.gmane.org>
Message-ID: <peoa8n$fa7$1@blaine.gmane.org>

"Frank Millman"  wrote in message news:pemchs$r12$1 at blaine.gmane.org...
>
> So working backwards, I have solved the first problem. I am no nearer to
figuring out why it fails intermittently in my live program. The message
from INADA Naoki suggests that it could be inherent in CPython, but I am not
ready to accept that as an answer yet. I will keep plugging away and report
back with any findings.
>

Ok, I have not found the root cause yet, but I have moved the problem to a 
different place, which is progress.

>From the interpreter session below, you will see that adding a key while 
processing the *last* key in an OrderedDict does not give rise to an 
exception. Adding a key while processing any prior key in an OrderedDict 
does raise the exception. I have checked this fairly thoroughly and it 
behaves the same way every time.

>>> from collections import OrderedDict as OD
>>> d = OD()
>>> d[1] = 'one'
>>> d[2] = 'two'
>>> for k in d:
...   if k == 2:
...     d[3] = 'three'
...
>>> d = OD()
>>> d[1] = 'one'
>>> d[2] = 'two'
>>> for k in d:
...   if k == 1:
...     d[3] = 'three'
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: OrderedDict mutated during iteration
>>>

The intermittent nature of my problem stems from the above - sometimes I add 
a key while processing the last key, sometimes a prior one. I don't know why 
this is happening, so I am still investigating, but it has moved into the 
realm of normal debugging, not chasing shadows.

Frank




From hjp-python at hjp.at  Thu May 31 05:56:15 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Thu, 31 May 2018 11:56:15 +0200
Subject: Pink Floyd: is there anybody in here?
In-Reply-To: <penead$1f4$1@blaine.gmane.org>
References: <87vab52jcq.fsf@nightsong.com> <pemlef$dj8$1@dont-email.me>
 <87efhs27da.fsf@bsb.me.uk> <penead$1f4$1@blaine.gmane.org>
Message-ID: <20180531095615.3lfd7kzivzrsiosd@hjp.at>

On 2018-05-31 00:06:37 +0000, Steven D'Aprano wrote:
> On Wed, 30 May 2018 21:53:05 +0100, Ben Bacarisse wrote:
> > Rob Gaddi <rgaddi at highlandtechnology.invalid> writes:
> >> On 05/30/2018 09:34 AM, Paul Rubin wrote:
> >>> I think Usenet posts are no longer getting forwarded to the mailing
> >>> list, but now I wonder if this is getting out at all, even to usenet.
> >>>
> >>> Does anyone see it?
> >>
> >> Can't speak for the mailing list, but this came out to Usenet just
> >> fine.
> > 
> > Snap.  The original and the reply.
> 
> You shouldn't generalise about Usenet, as individual news servers can and 
> do drop messages.

True.

> In this case, gmane seems to be dropping Paul Rubin's posts.

As has been recently discussed, gmane isn't directly connected to
Usenet. It gets all its messages from the mailing list. Since Paul's
message didn't make it to the mailing list, it didn't make it to gmane
either.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180531/a32da385/attachment.sig>

From hendorf at europython.eu  Thu May 31 07:31:09 2018
From: hendorf at europython.eu (Alexander C. S. Hendorf)
Date: Thu, 31 May 2018 13:31:09 +0200
Subject: EuroPython 2018: First list of accepted sessions available
Message-ID: <6d3bda58-5144-4fed-a854-21fb07233c28@Spark>

We have received an amazing collection of 376 proposals.
Thank you all for your contributions!

Given the overwhelming quality of the proposals,
we had some very difficult decisions to make.
Nonetheless we are happy to announce
we have published the first 120+ sessions.
https://ep2018.europython.eu/en/events/sessions/

Here?s what we have on offer so far:
* 12 Trainings (complete)
* 98 Talks (some more will follow)
* 6 help desks (complete)
* 10 posters (complete)

More sessions to come
=================

We have informed all speakers with accepted submissions by email.
We are further selecting a second wave of talks, that will be announced soon.

Please see the session list for details and abstracts.
In case you wonder what poster, interactive and help desk sessions are,
please check the call for proposals.
https://ep2018.europython.eu/en/call-for-proposals/

Enjoy,
?
EuroPython 2018 Team
https://ep2018.europython.eu/
https://www.europython-society.org/

Alexander Hendorf

as EuroPython vice chair & chair of the program work group

Twitter: @hendorf
LinkedIn:?https://www.linkedin.com/in/hendorf

EuroPython:
https://www.europython.eu/
https://twitter.com/europython
https://www.facebook.com/europython

EuroPython Society:
http://www.europython-society.org/


From marko at pacujo.net  Thu May 31 08:03:06 2018
From: marko at pacujo.net (Marko Rauhamaa)
Date: Thu, 31 May 2018 15:03:06 +0300
Subject: Why exception from os.path.exists()?
Message-ID: <87tvqoghhh.fsf@elektro.pacujo.net>


This surprising exception can even be a security issue:

   >>> os.path.exists("\0")
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
     File "/usr/lib64/python3.6/genericpath.py", line 19, in exists
       os.stat(path)
   ValueError: embedded null byte

Most other analogous reasons *don't* generate an exception, nor is that
possibility mentioned in the specification:

   https://docs.python.org/3/library/os.path.html?#os.path.exists

Is the behavior a bug? Shouldn't it be:

   >>> os.path.exists("\0")
   False


Marko


From rosuav at gmail.com  Thu May 31 08:46:35 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Thu, 31 May 2018 22:46:35 +1000
Subject: Why exception from os.path.exists()?
In-Reply-To: <87tvqoghhh.fsf@elektro.pacujo.net>
References: <87tvqoghhh.fsf@elektro.pacujo.net>
Message-ID: <CAPTjJmrhddtg_WEpL=jJtPuPhKfOw8=_NGNH2do8XXn1xgbzww@mail.gmail.com>

On Thu, May 31, 2018 at 10:03 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
>
> This surprising exception can even be a security issue:
>
>    >>> os.path.exists("\0")
>    Traceback (most recent call last):
>      File "<stdin>", line 1, in <module>
>      File "/usr/lib64/python3.6/genericpath.py", line 19, in exists
>        os.stat(path)
>    ValueError: embedded null byte
>
> Most other analogous reasons *don't* generate an exception, nor is that
> possibility mentioned in the specification:
>
>    https://docs.python.org/3/library/os.path.html?#os.path.exists
>
> Is the behavior a bug? Shouldn't it be:
>
>    >>> os.path.exists("\0")
>    False

A Unix path name cannot contain a null byte, so what you have is a
fundamentally invalid name. ValueError is perfectly acceptable.

ChrisA


From steve+comp.lang.python at pearwood.info  Thu May 31 08:58:52 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Thu, 31 May 2018 12:58:52 +0000 (UTC)
Subject: Problem with OrderedDict - progress report
References: <peloc4$o31$1@blaine.gmane.org> <pem8b8$lm6$4@blaine.gmane.org>
 <pemchs$r12$1@blaine.gmane.org> <peoa8n$fa7$1@blaine.gmane.org>
Message-ID: <peorib$1f4$2@blaine.gmane.org>

On Thu, 31 May 2018 10:05:43 +0200, Frank Millman wrote:

> "Frank Millman"  wrote in message news:pemchs$r12$1 at blaine.gmane.org...
>>
>> So working backwards, I have solved the first problem. I am no nearer
>> to
> figuring out why it fails intermittently in my live program. The message
> from INADA Naoki suggests that it could be inherent in CPython, but I am
> not ready to accept that as an answer yet. I will keep plugging away and
> report back with any findings.
>>
>>
> Ok, I have not found the root cause yet, but I have moved the problem to
> a different place, which is progress.
> 
> From the interpreter session below, you will see that adding a key while
> processing the *last* key in an OrderedDict does not give rise to an
> exception.

If you mutate the dict, and then stop iterating over it, there is no 
check that the dict was mutated.

It isn't an error to mutate the dict. It is an error to mutate it while 
it is being iterated over. If you stop the iteration, there's no problem.

py> d = dict(zip(range(5), "abcde"))
py> for x in d:
...     d[999] = 'mutation!'
...     break
...
py> d  # no error occurred
{0: 'a', 1: 'b', 2: 'c', 3: 'd', 4: 'e', 999: 'mutation!'}


To be more precise, the checks against mutation occur when next() is 
called. If you don't call next(), the checks don't run.

py> it = iter(d)
py> next(it)
0
py> del d[4]
py> next(it)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: dictionary changed size during iteration



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson



From marko at pacujo.net  Thu May 31 09:03:01 2018
From: marko at pacujo.net (Marko Rauhamaa)
Date: Thu, 31 May 2018 16:03:01 +0300
Subject: Why exception from os.path.exists()?
References: <87tvqoghhh.fsf@elektro.pacujo.net>
 <CAPTjJmrhddtg_WEpL=jJtPuPhKfOw8=_NGNH2do8XXn1xgbzww@mail.gmail.com>
 <mailman.117.1527770804.2804.python-list@python.org>
Message-ID: <87o9gwgepm.fsf@elektro.pacujo.net>

Chris Angelico <rosuav at gmail.com>:

> On Thu, May 31, 2018 at 10:03 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
>>
>> This surprising exception can even be a security issue:
>>
>>    >>> os.path.exists("\0")
>>    Traceback (most recent call last):
>>      File "<stdin>", line 1, in <module>
>>      File "/usr/lib64/python3.6/genericpath.py", line 19, in exists
>>        os.stat(path)
>>    ValueError: embedded null byte
>
> [...]
>
> A Unix path name cannot contain a null byte, so what you have is a
> fundamentally invalid name. ValueError is perfectly acceptable.

At the very least, that should be emphasized in the documentation. The
pathname may come from an external source. It is routine to check for
"/", "." and ".." but most developers (!?) would not think of checking
for "\0". That means few test suites would catch this issue and few
developers would think of catching ValueError here. The end result is
unpredictable.


Marko


From rosuav at gmail.com  Thu May 31 09:10:01 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Thu, 31 May 2018 23:10:01 +1000
Subject: Why exception from os.path.exists()?
In-Reply-To: <87o9gwgepm.fsf@elektro.pacujo.net>
References: <87tvqoghhh.fsf@elektro.pacujo.net>
 <CAPTjJmrhddtg_WEpL=jJtPuPhKfOw8=_NGNH2do8XXn1xgbzww@mail.gmail.com>
 <mailman.117.1527770804.2804.python-list@python.org>
 <87o9gwgepm.fsf@elektro.pacujo.net>
Message-ID: <CAPTjJmq0CKzzLJKdBDx9-zYAnf8EBugFuai3b5-rM1oTeFTg4A@mail.gmail.com>

On Thu, May 31, 2018 at 11:03 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
> Chris Angelico <rosuav at gmail.com>:
>
>> On Thu, May 31, 2018 at 10:03 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
>>>
>>> This surprising exception can even be a security issue:
>>>
>>>    >>> os.path.exists("\0")
>>>    Traceback (most recent call last):
>>>      File "<stdin>", line 1, in <module>
>>>      File "/usr/lib64/python3.6/genericpath.py", line 19, in exists
>>>        os.stat(path)
>>>    ValueError: embedded null byte
>>
>> [...]
>>
>> A Unix path name cannot contain a null byte, so what you have is a
>> fundamentally invalid name. ValueError is perfectly acceptable.
>
> At the very least, that should be emphasized in the documentation. The
> pathname may come from an external source. It is routine to check for
> "/", "." and ".." but most developers (!?) would not think of checking
> for "\0". That means few test suites would catch this issue and few
> developers would think of catching ValueError here. The end result is
> unpredictable.

The rules for paths come from the underlying system. You'll get quite
different results on Windows than you do on Unix. What should be
documented? Should it also be documented that you can get strange
errors when your path involves three different operating systems and
five different file systems? Is that Python's responsibility, or
should it be generally accepted that invalid values can cause
ValueError?

Do you have an actual use-case where it is correct for an invalid path
to be treated as not existing?

ChrisA


From marko at pacujo.net  Thu May 31 09:38:27 2018
From: marko at pacujo.net (Marko Rauhamaa)
Date: Thu, 31 May 2018 16:38:27 +0300
Subject: Why exception from os.path.exists()?
References: <87tvqoghhh.fsf@elektro.pacujo.net>
 <CAPTjJmrhddtg_WEpL=jJtPuPhKfOw8=_NGNH2do8XXn1xgbzww@mail.gmail.com>
 <mailman.117.1527770804.2804.python-list@python.org>
 <87o9gwgepm.fsf@elektro.pacujo.net>
 <CAPTjJmq0CKzzLJKdBDx9-zYAnf8EBugFuai3b5-rM1oTeFTg4A@mail.gmail.com>
 <mailman.119.1527772205.2804.python-list@python.org>
Message-ID: <87k1rkgd2k.fsf@elektro.pacujo.net>

Chris Angelico <rosuav at gmail.com>:
> Do you have an actual use-case where it is correct for an invalid path
> to be treated as not existing?

Note that os.path.exists() returns False for other types of errors
including:

 * File might exist but you have no access rights

 * The pathname is too long for the file system

 * The pathname is a broken symbolic link

 * The pathname is a circular symbolic link

 * The hard disk ball bearings are chipped

I'm not aware of any other kind of a string argument that would trigger
an exception except the presence of a NUL byte.

The reason for the different treatment is that the former errors are
caught by the kernel and converted to False by os.path.exists(). The NUL
byte check is carried out by Python's standard library.


Marko


From rosuav at gmail.com  Thu May 31 10:01:46 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 1 Jun 2018 00:01:46 +1000
Subject: Why exception from os.path.exists()?
In-Reply-To: <87k1rkgd2k.fsf@elektro.pacujo.net>
References: <87tvqoghhh.fsf@elektro.pacujo.net>
 <CAPTjJmrhddtg_WEpL=jJtPuPhKfOw8=_NGNH2do8XXn1xgbzww@mail.gmail.com>
 <mailman.117.1527770804.2804.python-list@python.org>
 <87o9gwgepm.fsf@elektro.pacujo.net>
 <CAPTjJmq0CKzzLJKdBDx9-zYAnf8EBugFuai3b5-rM1oTeFTg4A@mail.gmail.com>
 <mailman.119.1527772205.2804.python-list@python.org>
 <87k1rkgd2k.fsf@elektro.pacujo.net>
Message-ID: <CAPTjJmq9W2MAbmJoOYA3EQvAiiRyX-i-80HXR1rJvhZBzuMAVw@mail.gmail.com>

On Thu, May 31, 2018 at 11:38 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
> Chris Angelico <rosuav at gmail.com>:
>> Do you have an actual use-case where it is correct for an invalid path
>> to be treated as not existing?
>
> Note that os.path.exists() returns False for other types of errors
> including:
>
>  * File might exist but you have no access rights
>
>  * The pathname is too long for the file system
>
>  * The pathname is a broken symbolic link
>
>  * The pathname is a circular symbolic link
>
>  * The hard disk ball bearings are chipped

All of those are conceptually valid filenames, and it's perfectly
reasonable to ask if the file exists. Running the same program inside
a chroot might result in a True.

> I'm not aware of any other kind of a string argument that would trigger
> an exception except the presence of a NUL byte.

With a zero byte in the file name, it is not a valid file name under
any Unix-based OS. Regardless of the file system, "\0" is not valid.

> The reason for the different treatment is that the former errors are
> caught by the kernel and converted to False by os.path.exists(). The NUL
> byte check is carried out by Python's standard library.

That's because the kernel, having declared that zero bytes are
invalid, uses ASCIIZ filenames. It's way simpler that way. So the
Python string cannot validly be turned into input for the kernel. It's
on par with trying to represent 2**53+1.0 - it's not representable and
will behave differently. With floats, you get something close to the
requested value; with strings, they'd be truncated. But either way,
you absolutely cannot represent the file name "spam\0ham" to any Unix
kernel, because the file name is fundamentally invalid.

Can someone on Windows see if there are other path names that raise
ValueError there? Windows has a whole lot more invalid characters, and
invalid names as well.

ChrisA


From greg.ewing at canterbury.ac.nz  Thu May 31 10:14:58 2018
From: greg.ewing at canterbury.ac.nz (Gregory Ewing)
Date: Fri, 01 Jun 2018 02:14:58 +1200
Subject: Why exception from os.path.exists()?
In-Reply-To: <mailman.117.1527770804.2804.python-list@python.org>
References: <87tvqoghhh.fsf@elektro.pacujo.net>
 <CAPTjJmrhddtg_WEpL=jJtPuPhKfOw8=_NGNH2do8XXn1xgbzww@mail.gmail.com>
 <mailman.117.1527770804.2804.python-list@python.org>
Message-ID: <fnaeb4F40vqU1@mid.individual.net>

Chris Angelico wrote:

> A Unix path name cannot contain a null byte, so what you have is a
> fundamentally invalid name. ValueError is perfectly acceptable.

It would also make sense for it could simply return False, since
a file with such a name can't exist.

This is analogous to the way comparing objects of different types
for equality returns False instead of raising an exception.

-- 
Greg


From toby at tobiah.org  Thu May 31 10:18:11 2018
From: toby at tobiah.org (Tobiah)
Date: Thu, 31 May 2018 07:18:11 -0700
Subject: Sorting and spaces.
Message-ID: <pep073$kv3$1@gioia.aioe.org>

I had a case today where I needed to sort two string:

	['Awards', 'Award Winners']

I consulted a few sources to get a suggestion as to
what would be correct.  My first idea was to throw them
through a Linux command line sort:

	Awards
	Award Winners

Then I did some Googling, and found that most US systems seem
to prefer that one ignore spaces when alphabetizing.  The sort
program seemed to agree.

I put the items into the database that way, but I had forgotten
that my applications used python to sort them anyway.  The result
was different:

	>>> a = ['Awards', 'Award Winners']
	>>> sorted(a)
	['Award Winners', 'Awards']

So python evaluated the space as a lower ASCII value.

Thoughts?  Are there separate tools for alphabetizing
rather then sorting?


Thanks,


Tobiah


From frank at chagford.com  Thu May 31 10:37:39 2018
From: frank at chagford.com (Frank Millman)
Date: Thu, 31 May 2018 16:37:39 +0200
Subject: Problem with OrderedDict - progress report
In-Reply-To: <peorib$1f4$2@blaine.gmane.org>
References: <peloc4$o31$1@blaine.gmane.org> <pem8b8$lm6$4@blaine.gmane.org>
 <pemchs$r12$1@blaine.gmane.org> <peoa8n$fa7$1@blaine.gmane.org>
 <peorib$1f4$2@blaine.gmane.org>
Message-ID: <pep17g$m25$1@blaine.gmane.org>

"Steven D'Aprano"  wrote in message news:peorib$1f4$2 at blaine.gmane.org...
>
> On Thu, 31 May 2018 10:05:43 +0200, Frank Millman wrote:
>
> > From the interpreter session below, you will see that adding a key while
> > processing the *last* key in an OrderedDict does not give rise to an
> > exception.
>
> If you mutate the dict, and then stop iterating over it, there is no
> check that the dict was mutated.
>
> It isn't an error to mutate the dict. It is an error to mutate it while
> it is being iterated over. If you stop the iteration, there's no problem.
>

Agreed, but my gut feel, and the following example, suggest that when 
processing the last key in a dictionary while iterating over it, you have 
not yet stopped iterating.

>>> d = {}
>>> d[1] = 'one'
>>> d[2] = 'two'
>>> for k in d:
...   if k == 2:
...     d[3] = 'three'
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: dictionary changed size during iteration
>>>

OrderedDict seems to behave differently in this regard -

>>> from collections import OrderedDict as OD
>>> d = OD()
>>> d[1] = 'one'
>>> d[2] = 'two'
>>> for k in d:
...   if k == 2:
...     d[3] = 'three'
...
>>> d
OrderedDict([(1, 'one'), (2, 'two'), (3, 'three')])
>>>

Frank





From D.Strohl at F5.com  Thu May 31 10:39:17 2018
From: D.Strohl at F5.com (Dan Strohl)
Date: Thu, 31 May 2018 14:39:17 +0000
Subject: Indented multi-line strings (was: "Data blocks" syntax
 specification draft)
In-Reply-To: <20180530224733.6qai7jsw4bknkukr@hjp.at>
References: <CAHiMU6cGz=X4LMcYac=_Us0+9ATPTrJPLZaeXmK07KbnNFSP2A@mail.gmail.com>
 <CAE6NSRA9sNDkL2RgpaUnziRv5ka2j_L4y1rScKoLJSnR+KCXpg@mail.gmail.com>
 <mailman.4.1526955481.18022.python-list@python.org>
 <pe0bn1$8ns$1@dont-email.me>
 <CAE6NSRA4=wxwAWCXpJg9sXZgdDrFY5GN8_JybYg1zwgi-aYCQQ@mail.gmail.com>
 <9bf0783c8b044b348769942bda950043@F5.com>
 <20180523162535.xbtqnxi7yqv4ijlg@hjp.at>
 <CALwzidnMYFyxM5cqHZVpEd4KBDx-E51Gzx2gvhMuyPgx90PD9A@mail.gmail.com>
 <20180529091919.xxr7rt5yoplwdge6@hjp.at>
 <CALwzidkQQshcfDfqzONtP18D4c7QshsPeaXfArWQUt=2SxoyFQ@mail.gmail.com>
 <20180530224733.6qai7jsw4bknkukr@hjp.at>
Message-ID: <48620ae1be64499abf9baf065273e4c3@F5.com>

> This is of course not a problem if the *trailing* quote determines the
> indentation:
> 
>     a_multi_line_string = i'''
>            Py-
>           thon
>         '''

I get the point, but it feels like it would be a pain to use, and it "Feels" different from the other python indenting, which is something that I would want to stay away from changing.

> > In any case, Chris made a good point that I agree with. This doesn't
> > really need to be syntax at all, but could just be implemented as a
> > new string method.
> 
> Depending on the details, not quite. A method wouldn't get the horizontal
> position of the leading quote. It could infer the position of the trailing quote,
> though.
> 

What about if we used Chris's approach, but added a parameter to the method to handle the indent? 

For example, 

Test = """
        Hello, this is a
     Multiline indented
    String
    """.outdent(4)


The outdent method could look like:

string.outdent(size=None)
    """
    :param size : The number of spaces to remove from the beginning of each line in the string.  Non space characters will not be removed.  IF this is None, the number of characters in the first line of the string will be used.  If this is an iterable, the numbers returned from each iteration will be used for their respective lines.  If there are more lines than iterations, the last iteration will be used for subsequent lines.

This solves the problem in a very pythonic way, while allowing the flexibility to handle different needs.



From D.Strohl at F5.com  Thu May 31 10:49:57 2018
From: D.Strohl at F5.com (Dan Strohl)
Date: Thu, 31 May 2018 14:49:57 +0000
Subject: Override built in types... possible?  or proposal.
Message-ID: <6c01e72e594e4a51b2cff6ed4de5b9ff@F5.com>

Is it possible to override the assignment of built in types to the shorthand representations?   And if not, is it a reasonable thought to consider adding?

For example, right now, if I do:

test = "this is a string",

I get back str("this is a string").  What if I want to return this as my_string("this is a string")  (OK, I know I have a recursive issue in my example, but hopefully you get the point).

Or;

Test = ['item1', 'item2', 'item3'] returns a list, what if I want to add functionality to all lists in my module?  (and yes, I know I could simply not do [] and always do my_list('item1', 'item2', 'item3']

I am envisioning something in the header like an import statement where I could do;

override str=my_string
override list=my_list

This would only be scoped to the current module and would not be imported when that module was imported.

Thoughts?

Dan Strohl


From python at mrabarnett.plus.com  Thu May 31 10:51:06 2018
From: python at mrabarnett.plus.com (MRAB)
Date: Thu, 31 May 2018 15:51:06 +0100
Subject: Why exception from os.path.exists()?
In-Reply-To: <87k1rkgd2k.fsf@elektro.pacujo.net>
References: <87tvqoghhh.fsf@elektro.pacujo.net>
 <CAPTjJmrhddtg_WEpL=jJtPuPhKfOw8=_NGNH2do8XXn1xgbzww@mail.gmail.com>
 <mailman.117.1527770804.2804.python-list@python.org>
 <87o9gwgepm.fsf@elektro.pacujo.net>
 <CAPTjJmq0CKzzLJKdBDx9-zYAnf8EBugFuai3b5-rM1oTeFTg4A@mail.gmail.com>
 <mailman.119.1527772205.2804.python-list@python.org>
 <87k1rkgd2k.fsf@elektro.pacujo.net>
Message-ID: <8730e978-2a48-fc43-b68c-e001e43eac0b@mrabarnett.plus.com>

On 2018-05-31 14:38, Marko Rauhamaa wrote:
> Chris Angelico <rosuav at gmail.com>:
>> Do you have an actual use-case where it is correct for an invalid path
>> to be treated as not existing?
> 
> Note that os.path.exists() returns False for other types of errors
> including:
> 
>   * File might exist but you have no access rights
> 
>   * The pathname is too long for the file system
> 
>   * The pathname is a broken symbolic link
> 
>   * The pathname is a circular symbolic link
> 
>   * The hard disk ball bearings are chipped
> 
> I'm not aware of any other kind of a string argument that would trigger
> an exception except the presence of a NUL byte.
> 
> The reason for the different treatment is that the former errors are
> caught by the kernel and converted to False by os.path.exists(). The NUL
> byte check is carried out by Python's standard library.
> 
On Windows, the path '<' is invalid, but os.path.exists('<') returns 
False, not an error.

The path '' is also invalid, but os.path.exists('') returns False, not 
an error.

I don't see why '\0' should behave any differently.


From p.f.moore at gmail.com  Thu May 31 10:55:40 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 31 May 2018 15:55:40 +0100
Subject: Why exception from os.path.exists()?
In-Reply-To: <CAPTjJmq9W2MAbmJoOYA3EQvAiiRyX-i-80HXR1rJvhZBzuMAVw@mail.gmail.com>
References: <87tvqoghhh.fsf@elektro.pacujo.net>
 <CAPTjJmrhddtg_WEpL=jJtPuPhKfOw8=_NGNH2do8XXn1xgbzww@mail.gmail.com>
 <mailman.117.1527770804.2804.python-list@python.org>
 <87o9gwgepm.fsf@elektro.pacujo.net>
 <CAPTjJmq0CKzzLJKdBDx9-zYAnf8EBugFuai3b5-rM1oTeFTg4A@mail.gmail.com>
 <mailman.119.1527772205.2804.python-list@python.org>
 <87k1rkgd2k.fsf@elektro.pacujo.net>
 <CAPTjJmq9W2MAbmJoOYA3EQvAiiRyX-i-80HXR1rJvhZBzuMAVw@mail.gmail.com>
Message-ID: <CACac1F-NYVTOhovEsCQmuPopakrF6ypmH-SWC-xJQug_u3e+Sg@mail.gmail.com>

On 31 May 2018 at 15:01, Chris Angelico <rosuav at gmail.com> wrote:
> Can someone on Windows see if there are other path names that raise
> ValueError there? Windows has a whole lot more invalid characters, and
> invalid names as well.

On Windows:

>>> os.path.exists('\0')
ValueError: stat: embedded null character in path

>>> os.path.exists('?')
False

>>> os.path.exists('\u77412')
False

>>> os.path.exists('\t')
False

Honestly, I think the OP's point is correct. os.path.exists should
simply return False if the filename has an embedded \0 - at least on
Unix. I don't know if Windows allows \0 in filenames, but if it does,
then os.path.exists should respect that...

Although I wouldn't consider this as anything even remotely like a
significant issue...

Paul


From steve+comp.lang.python at pearwood.info  Thu May 31 11:11:36 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Thu, 31 May 2018 15:11:36 +0000 (UTC)
Subject: Why exception from os.path.exists()?
References: <87tvqoghhh.fsf@elektro.pacujo.net>
 <CAPTjJmrhddtg_WEpL=jJtPuPhKfOw8=_NGNH2do8XXn1xgbzww@mail.gmail.com>
Message-ID: <pep3b8$1f4$3@blaine.gmane.org>

On Thu, 31 May 2018 22:46:35 +1000, Chris Angelico wrote:
[...]
>> Most other analogous reasons *don't* generate an exception, nor is that
>> possibility mentioned in the specification:
>>
>>    https://docs.python.org/3/library/os.path.html?#os.path.exists
>>
>> Is the behavior a bug? Shouldn't it be:
>>
>>    >>> os.path.exists("\0")
>>    False
> 
> A Unix path name cannot contain a null byte, so what you have is a
> fundamentally invalid name. ValueError is perfectly acceptable.

It should still be documented.

What does it do on Windows if the path is illegal?



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson



From p.f.moore at gmail.com  Thu May 31 11:30:16 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 31 May 2018 16:30:16 +0100
Subject: Why exception from os.path.exists()?
In-Reply-To: <pep3b8$1f4$3@blaine.gmane.org>
References: <87tvqoghhh.fsf@elektro.pacujo.net>
 <CAPTjJmrhddtg_WEpL=jJtPuPhKfOw8=_NGNH2do8XXn1xgbzww@mail.gmail.com>
 <pep3b8$1f4$3@blaine.gmane.org>
Message-ID: <CACac1F9mse+ih8vRqmCcxLrHDztKARHwLV_zgA6Xa-g9GDdJzA@mail.gmail.com>

On 31 May 2018 at 16:11, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Thu, 31 May 2018 22:46:35 +1000, Chris Angelico wrote:
> [...]
>>> Most other analogous reasons *don't* generate an exception, nor is that
>>> possibility mentioned in the specification:
>>>
>>>    https://docs.python.org/3/library/os.path.html?#os.path.exists
>>>
>>> Is the behavior a bug? Shouldn't it be:
>>>
>>>    >>> os.path.exists("\0")
>>>    False
>>
>> A Unix path name cannot contain a null byte, so what you have is a
>> fundamentally invalid name. ValueError is perfectly acceptable.
>
> It should still be documented.
>
> What does it do on Windows if the path is illegal?

Returns False (confirmed with paths of '?' and ':', among others).

Paul


From python at mrabarnett.plus.com  Thu May 31 11:33:24 2018
From: python at mrabarnett.plus.com (MRAB)
Date: Thu, 31 May 2018 16:33:24 +0100
Subject: Sorting and spaces.
In-Reply-To: <pep073$kv3$1@gioia.aioe.org>
References: <pep073$kv3$1@gioia.aioe.org>
Message-ID: <fdfe0540-bd85-1559-6a8c-2c4c8b31bc4a@mrabarnett.plus.com>

On 2018-05-31 15:18, Tobiah wrote:
> I had a case today where I needed to sort two string:
> 
> 	['Awards', 'Award Winners']
> 
> I consulted a few sources to get a suggestion as to
> what would be correct.  My first idea was to throw them
> through a Linux command line sort:
> 
> 	Awards
> 	Award Winners
> 
> Then I did some Googling, and found that most US systems seem
> to prefer that one ignore spaces when alphabetizing.  The sort
> program seemed to agree.
> 
> I put the items into the database that way, but I had forgotten
> that my applications used python to sort them anyway.  The result
> was different:
> 
> 	>>> a = ['Awards', 'Award Winners']
> 	>>> sorted(a)
> 	['Award Winners', 'Awards']
> 
> So python evaluated the space as a lower ASCII value.
> 
> Thoughts?  Are there separate tools for alphabetizing
> rather then sorting?
> 
You could split the string first:
 >>> a = ['Awards', 'Award Winners']
 >>> sorted(a, key=str.split)
['Award Winners', 'Awards']

If you want it to be case-insensitive:

 >>> sorted(a, key=lambda s: s.lower().split())
['Award Winners', 'Awards']


From python at mrabarnett.plus.com  Thu May 31 11:44:10 2018
From: python at mrabarnett.plus.com (MRAB)
Date: Thu, 31 May 2018 16:44:10 +0100
Subject: Indented multi-line strings
In-Reply-To: <48620ae1be64499abf9baf065273e4c3@F5.com>
References: <CAHiMU6cGz=X4LMcYac=_Us0+9ATPTrJPLZaeXmK07KbnNFSP2A@mail.gmail.com>
 <CAE6NSRA9sNDkL2RgpaUnziRv5ka2j_L4y1rScKoLJSnR+KCXpg@mail.gmail.com>
 <mailman.4.1526955481.18022.python-list@python.org>
 <pe0bn1$8ns$1@dont-email.me>
 <CAE6NSRA4=wxwAWCXpJg9sXZgdDrFY5GN8_JybYg1zwgi-aYCQQ@mail.gmail.com>
 <9bf0783c8b044b348769942bda950043@F5.com>
 <20180523162535.xbtqnxi7yqv4ijlg@hjp.at>
 <CALwzidnMYFyxM5cqHZVpEd4KBDx-E51Gzx2gvhMuyPgx90PD9A@mail.gmail.com>
 <20180529091919.xxr7rt5yoplwdge6@hjp.at>
 <CALwzidkQQshcfDfqzONtP18D4c7QshsPeaXfArWQUt=2SxoyFQ@mail.gmail.com>
 <20180530224733.6qai7jsw4bknkukr@hjp.at>
 <48620ae1be64499abf9baf065273e4c3@F5.com>
Message-ID: <889761ba-616e-7825-bbbe-a026e2853820@mrabarnett.plus.com>

On 2018-05-31 15:39, Dan Strohl via Python-list wrote:
>> This is of course not a problem if the *trailing* quote determines the
>> indentation:
>> 
>>     a_multi_line_string = i'''
>>            Py-
>>           thon
>>         '''
> 
> I get the point, but it feels like it would be a pain to use, and it "Feels" different from the other python indenting, which is something that I would want to stay away from changing.
> 
>> > In any case, Chris made a good point that I agree with. This doesn't
>> > really need to be syntax at all, but could just be implemented as a
>> > new string method.
>> 
>> Depending on the details, not quite. A method wouldn't get the horizontal
>> position of the leading quote. It could infer the position of the trailing quote,
>> though.
>> 
> 
> What about if we used Chris's approach, but added a parameter to the method to handle the indent?
> 
> For example,
> 
> Test = """
>          Hello, this is a
>       Multiline indented
>      String
>      """.outdent(4)
> 
> 
> The outdent method could look like:
> 
> string.outdent(size=None)
>      """
>      :param size : The number of spaces to remove from the beginning of each line in the string.  Non space characters will not be removed.  IF this is None, the number of characters in the first line of the string will be used.  If this is an iterable, the numbers returned from each iteration will be used for their respective lines.  If there are more lines than iterations, the last iteration will be used for subsequent lines.
> 
> This solves the problem in a very pythonic way, while allowing the flexibility to handle different needs.
> 
That string starts with a blank line, after the initial quotes.

I was also thinking that it could take the indentation from the first 
line, but that if you wanted the first line to have a larger indent than 
the remaining lines, you could replace the first space that you want to 
keep with a non-whitespace character and then pass that character to the 
method.

For example:

Test = """\
      _   Hello, this is a
       Multiline indented
      String
      """.outdent(padding='_')

Outdent so that the first line is flush to the margin:

_   Hello, this is a
  Multiline indented
String

The padding argument tells it to replace the initial '_':

     Hello, this is a
  Multiline indented
String


From email at paulstgeorge.com  Thu May 31 12:47:46 2018
From: email at paulstgeorge.com (Paul St George)
Date: Thu, 31 May 2018 18:47:46 +0200
Subject: The PIL show() method looks for the default viewer. How
 do I change this to a different viewer (of my choice)?
In-Reply-To: <20180530210931.GA2258@hermes.hilbert.loc>
References: <ddedae8b-f085-dfa3-08a4-2c821975cc61@paulstgeorge.com>
 <CANDiX9+fF3ADqhee50RA47hecQRpsOVJjXML9=OAYzkAp9gNqw@mail.gmail.com>
 <0efaafaa-064f-726a-416f-9dc9d0756667@paulstgeorge.com>
 <pec4bf$3a7$1@blaine.gmane.org>
 <6d5f6b18-99ac-cc6f-8cfb-0caf23224c51@paulstgeorge.com>
 <peitjc$jjq$1@blaine.gmane.org>
 <083a74fd-94c0-8cae-c052-17205a1b9f7b@paulstgeorge.com>
 <pekrcq$sr1$2@blaine.gmane.org>
 <34d564d7-b6f3-5fa8-9abd-269b63887889@paulstgeorge.com>
 <20180530210117.d3rtjiv62sulckyn@hjp.at>
 <20180530210931.GA2258@hermes.hilbert.loc>
Message-ID: <ac0f981e-d918-0d98-c8fd-732c385c6bb2@paulstgeorge.com>

That's what I wanted! But, I didn't know the question because I didn't 
know the answer.


On 30/05/2018 23:09, Karsten Hilbert wrote:
> On Wed, May 30, 2018 at 11:01:17PM +0200, Peter J. Holzer wrote:
>
>> On 2018-05-30 22:08:45 +0200, Paul St George wrote:
>>> Ha! No, my question was clumsy.
>>>
>>> If I know the name of the viewer that I want to use (say for example:
>>> ?ImageMagick?), where do I find the argument that should be used in a line
>>> of code such as this:
>>>
>>> ImageShow.register(MyViewer("gwenview"), -1)
> 	$> man -k ImageMagick
> 	$> man whatever_you_found_with_the_above
>
> Karsten

-- 
Paul St George
http://www.paulstgeorge.com
http://www.devices-of-wonder.com

+44(0)7595 37 1302



From rgaddi at highlandtechnology.invalid  Thu May 31 12:51:30 2018
From: rgaddi at highlandtechnology.invalid (Rob Gaddi)
Date: Thu, 31 May 2018 09:51:30 -0700
Subject: Override built in types... possible? or proposal.
In-Reply-To: <mailman.124.1527778431.2804.python-list@python.org>
References: <6c01e72e594e4a51b2cff6ed4de5b9ff@F5.com>
 <mailman.124.1527778431.2804.python-list@python.org>
Message-ID: <pep96k$u5r$1@dont-email.me>

On 05/31/2018 07:49 AM, Dan Strohl wrote:
> Is it possible to override the assignment of built in types to the shorthand representations?   And if not, is it a reasonable thought to consider adding?
> 
> For example, right now, if I do:
> 
> test = "this is a string",
> 
> I get back str("this is a string").  What if I want to return this as my_string("this is a string")  (OK, I know I have a recursive issue in my example, but hopefully you get the point).
> 
> Or;
> 
> Test = ['item1', 'item2', 'item3'] returns a list, what if I want to add functionality to all lists in my module?  (and yes, I know I could simply not do [] and always do my_list('item1', 'item2', 'item3']
> 
> I am envisioning something in the header like an import statement where I could do;
> 
> override str=my_string
> override list=my_list
> 
> This would only be scoped to the current module and would not be imported when that module was imported.
> 
> Thoughts?
> 
> Dan Strohl
> 

My problem with this idea is that it breaks expectations.  If I know one 
thing as a Python programmer, it's that 'Bob' is a str.  Each time and 
every time.  If you could override the meaning of basic constant 
identifiers to where I have no idea how they behave, that creates an 
easy thing to miss that changes the entire meaning of the things you've 
written.

What's the use case here?  And why is that use case better than, for 
instance, simply defining a function in the module that does the things 
you want done to strings?  Not everything has to be an object method.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.


From __peter__ at web.de  Thu May 31 12:53:58 2018
From: __peter__ at web.de (Peter Otten)
Date: Thu, 31 May 2018 18:53:58 +0200
Subject: Sorting and spaces.
References: <pep073$kv3$1@gioia.aioe.org>
Message-ID: <pep973$rro$1@blaine.gmane.org>

Tobiah wrote:

> I had a case today where I needed to sort two string:
> 
> ['Awards', 'Award Winners']
> 
> I consulted a few sources to get a suggestion as to
> what would be correct.  My first idea was to throw them
> through a Linux command line sort:
> 
> Awards
> Award Winners
> 
> Then I did some Googling, and found that most US systems seem
> to prefer that one ignore spaces when alphabetizing.  The sort
> program seemed to agree.
> 
> I put the items into the database that way, but I had forgotten
> that my applications used python to sort them anyway.  The result
> was different:
> 
> >>> a = ['Awards', 'Award Winners']
> >>> sorted(a)
> ['Award Winners', 'Awards']
> 
> So python evaluated the space as a lower ASCII value.
> 
> Thoughts?  Are there separate tools for alphabetizing
> rather then sorting?

>>> items = ["Awards", "Award Winners", "awards"]
>>> sorted(items)
['Award Winners', 'Awards', 'awards']
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "en_US.UTF-8")
'en_US.UTF-8'
>>> sorted(items, key=locale.strxfrm)
['awards', 'Awards', 'Award Winners']
>>> locale.setlocale(locale.LC_ALL, "C")
'C'
>>> sorted(items, key=locale.strxfrm)
['Award Winners', 'Awards', 'awards']




From tjreedy at udel.edu  Thu May 31 12:59:05 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 31 May 2018 12:59:05 -0400
Subject: Why exception from os.path.exists()?
In-Reply-To: <87tvqoghhh.fsf@elektro.pacujo.net>
References: <87tvqoghhh.fsf@elektro.pacujo.net>
Message-ID: <pep9gl$ud7$1@blaine.gmane.org>

On 5/31/2018 8:03 AM, Marko Rauhamaa wrote:
> 
> This surprising exception can even be a security issue:
> 
>     >>> os.path.exists("\0")
>     Traceback (most recent call last):
>       File "<stdin>", line 1, in <module>
>       File "/usr/lib64/python3.6/genericpath.py", line 19, in exists
>         os.stat(path)
>     ValueError: embedded null byte
> 
> Most other analogous reasons *don't* generate an exception, nor is that
> possibility mentioned in the specification:
> 
>     https://docs.python.org/3/library/os.path.html?#os.path.exists
> 
> Is the behavior a bug? Shouldn't it be:
> 
>     >>> os.path.exists("\0")
>     False

Please open an issue on the tracker if there is not one for this already.


-- 
Terry Jan Reedy



From tjreedy at udel.edu  Thu May 31 13:12:22 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 31 May 2018 13:12:22 -0400
Subject: Indented multi-line strings
In-Reply-To: <48620ae1be64499abf9baf065273e4c3@F5.com>
References: <CAHiMU6cGz=X4LMcYac=_Us0+9ATPTrJPLZaeXmK07KbnNFSP2A@mail.gmail.com>
 <CAE6NSRA9sNDkL2RgpaUnziRv5ka2j_L4y1rScKoLJSnR+KCXpg@mail.gmail.com>
 <mailman.4.1526955481.18022.python-list@python.org>
 <pe0bn1$8ns$1@dont-email.me>
 <CAE6NSRA4=wxwAWCXpJg9sXZgdDrFY5GN8_JybYg1zwgi-aYCQQ@mail.gmail.com>
 <9bf0783c8b044b348769942bda950043@F5.com>
 <20180523162535.xbtqnxi7yqv4ijlg@hjp.at>
 <CALwzidnMYFyxM5cqHZVpEd4KBDx-E51Gzx2gvhMuyPgx90PD9A@mail.gmail.com>
 <20180529091919.xxr7rt5yoplwdge6@hjp.at>
 <CALwzidkQQshcfDfqzONtP18D4c7QshsPeaXfArWQUt=2SxoyFQ@mail.gmail.com>
 <20180530224733.6qai7jsw4bknkukr@hjp.at>
 <48620ae1be64499abf9baf065273e4c3@F5.com>
Message-ID: <pepa9j$80c$1@blaine.gmane.org>

On 5/31/2018 10:39 AM, Dan Strohl via Python-list wrote:
>> This is of course not a problem if the *trailing* quote determines the
>> indentation:
>>
>>      a_multi_line_string = i'''
>>             Py-
>>            thon
>>          '''
> 
> I get the point, but it feels like it would be a pain to use, and it "Feels" different from the other python indenting, which is something that I would want to stay away from changing.
> 
>>> In any case, Chris made a good point that I agree with. This doesn't
>>> really need to be syntax at all, but could just be implemented as a
>>> new string method.
>>
>> Depending on the details, not quite. A method wouldn't get the horizontal
>> position of the leading quote. It could infer the position of the trailing quote,
>> though.
>>
> 
> What about if we used Chris's approach, but added a parameter to the method to handle the indent?
> 
> For example,
> 
> Test = """
>          Hello, this is a
>       Multiline indented
>      String
>      """.outdent(4)
> 
> 
> The outdent method could look like:
> 
> string.outdent(size=None)
>      """
>      :param size : The number of spaces to remove from the beginning of each line in the string.  Non space characters will not be removed.  IF this is None, the number of characters in the first line of the string will be used.  If this is an iterable, the numbers returned from each iteration will be used for their respective lines.  If there are more lines than iterations, the last iteration will be used for subsequent lines.
> 
> This solves the problem in a very pythonic way, while allowing the flexibility to handle different needs.

string = (
     "     Hello, this is a concatenated   \n"
     "   multiline variably indented       \n"
     "string with variable trailing blanks.\n"
     "    It works now and always has!     ")

-- 
Terry Jan Reedy



From marko at pacujo.net  Thu May 31 13:21:40 2018
From: marko at pacujo.net (Marko Rauhamaa)
Date: Thu, 31 May 2018 20:21:40 +0300
Subject: Why exception from os.path.exists()?
References: <87tvqoghhh.fsf@elektro.pacujo.net> <pep9gl$ud7$1@blaine.gmane.org>
 <mailman.132.1527785953.2804.python-list@python.org>
Message-ID: <87d0xb3fmj.fsf@elektro.pacujo.net>

Terry Reedy <tjreedy at udel.edu>:

> On 5/31/2018 8:03 AM, Marko Rauhamaa wrote:
>> Is the behavior a bug? Shouldn't it be:
>>
>>     >>> os.path.exists("\0")
>>     False
>
> Please open an issue on the tracker if there is not one for this
> already.

issue 33721 created


Marko


From D.Strohl at F5.com  Thu May 31 13:24:11 2018
From: D.Strohl at F5.com (Dan Strohl)
Date: Thu, 31 May 2018 17:24:11 +0000
Subject: Override built in types... possible? or proposal.
In-Reply-To: <pep96k$u5r$1@dont-email.me>
References: <6c01e72e594e4a51b2cff6ed4de5b9ff@F5.com>
 <mailman.124.1527778431.2804.python-list@python.org>
 <pep96k$u5r$1@dont-email.me>
Message-ID: <39fad224f474454aabac26aee7dd9a18@F5.com>

> >
> > I am envisioning something in the header like an import statement
> > where I could do;
> >
> > override str=my_string
> > override list=my_list
> >
> > This would only be scoped to the current module and would not be
> imported when that module was imported.
> >
> > Thoughts?
> >
> > Dan Strohl
> >
> 
> My problem with this idea is that it breaks expectations.  If I know one thing as
> a Python programmer, it's that 'Bob' is a str.  Each time and every time.  If you
> could override the meaning of basic constant identifiers to where I have no
> idea how they behave, that creates an easy thing to miss that changes the
> entire meaning of the things you've written.
> 

True, though, to determine what almost anything is, you should look at the imports anyway, just in case I happened to do something like;

Import my_sys as sys

> What's the use case here?  And why is that use case better than, for instance,
> simply defining a function in the module that does the things you want done
> to strings?  Not everything has to be an object method.

It's not necessarily better, it simply provides more flexibility in how things are approached.  In most cases I would probably define a function for something as you suggested, or define a new class and just instantiate that  object instead when needed, but I can see a time when it would be nice to be able to simply say, "I really want to handle all of my dictionaries in this module in a certain way", then not have to worry about it.

To me, one of the things I like about Python is that I can override many of the way things are handled via sub-classes, magic methods, importing "as" etc... this is simply an extension of that existing flexibility.

And yes, it gives developers another tool they can shoot themselves pretty easily in the foot with if they aren't careful in how they use it, but so many of the good tools do that already.

Honestly, I am not so locked into this that I would scream about it not working, but there have been times when it would have been helpful in the past, so I figured I would bring it up and see what others thought.

Dan





From rosuav at gmail.com  Thu May 31 13:25:57 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 1 Jun 2018 03:25:57 +1000
Subject: Why exception from os.path.exists()?
In-Reply-To: <8730e978-2a48-fc43-b68c-e001e43eac0b@mrabarnett.plus.com>
References: <87tvqoghhh.fsf@elektro.pacujo.net>
 <CAPTjJmrhddtg_WEpL=jJtPuPhKfOw8=_NGNH2do8XXn1xgbzww@mail.gmail.com>
 <mailman.117.1527770804.2804.python-list@python.org>
 <87o9gwgepm.fsf@elektro.pacujo.net>
 <CAPTjJmq0CKzzLJKdBDx9-zYAnf8EBugFuai3b5-rM1oTeFTg4A@mail.gmail.com>
 <mailman.119.1527772205.2804.python-list@python.org>
 <87k1rkgd2k.fsf@elektro.pacujo.net>
 <8730e978-2a48-fc43-b68c-e001e43eac0b@mrabarnett.plus.com>
Message-ID: <CAPTjJmpo0WvvBS_y=sOGaWpuZPAFYjFK-Kia+Lni7_9g=PnM1Q@mail.gmail.com>

On Fri, Jun 1, 2018 at 12:51 AM, MRAB <python at mrabarnett.plus.com> wrote:
> On 2018-05-31 14:38, Marko Rauhamaa wrote:
>>
>> Chris Angelico <rosuav at gmail.com>:
>>>
>>> Do you have an actual use-case where it is correct for an invalid path
>>> to be treated as not existing?
>>
>>
>> Note that os.path.exists() returns False for other types of errors
>> including:
>>
>>   * File might exist but you have no access rights
>>
>>   * The pathname is too long for the file system
>>
>>   * The pathname is a broken symbolic link
>>
>>   * The pathname is a circular symbolic link
>>
>>   * The hard disk ball bearings are chipped
>>
>> I'm not aware of any other kind of a string argument that would trigger
>> an exception except the presence of a NUL byte.
>>
>> The reason for the different treatment is that the former errors are
>> caught by the kernel and converted to False by os.path.exists(). The NUL
>> byte check is carried out by Python's standard library.
>>
> On Windows, the path '<' is invalid, but os.path.exists('<') returns False,
> not an error.
>
> The path '' is also invalid, but os.path.exists('') returns False, not an
> error.
>
> I don't see why '\0' should behave any differently.

Okay, if it's just returning False for all the Windows invalid paths,
then sure, the Unix invalid paths can behave the same way.

Thanks for checking that (you and Paul equally).

ChrisA


From rosuav at gmail.com  Thu May 31 13:35:04 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 1 Jun 2018 03:35:04 +1000
Subject: Problem with OrderedDict - progress report
In-Reply-To: <pep17g$m25$1@blaine.gmane.org>
References: <peloc4$o31$1@blaine.gmane.org> <pem8b8$lm6$4@blaine.gmane.org>
 <pemchs$r12$1@blaine.gmane.org> <peoa8n$fa7$1@blaine.gmane.org>
 <peorib$1f4$2@blaine.gmane.org> <pep17g$m25$1@blaine.gmane.org>
Message-ID: <CAPTjJmpdRhexbhV5vJWzX8cNydwh9YeoU7_9m+ZVjsdJbgPr9g@mail.gmail.com>

On Fri, Jun 1, 2018 at 12:37 AM, Frank Millman <frank at chagford.com> wrote:
> "Steven D'Aprano"  wrote in message news:peorib$1f4$2 at blaine.gmane.org...
>>
>>
>> On Thu, 31 May 2018 10:05:43 +0200, Frank Millman wrote:
>>
>> > From the interpreter session below, you will see that adding a key while
>> > processing the *last* key in an OrderedDict does not give rise to an
>> > exception.
>>
>> If you mutate the dict, and then stop iterating over it, there is no
>> check that the dict was mutated.
>>
>> It isn't an error to mutate the dict. It is an error to mutate it while
>> it is being iterated over. If you stop the iteration, there's no problem.
>>
>
> Agreed, but my gut feel, and the following example, suggest that when
> processing the last key in a dictionary while iterating over it, you have
> not yet stopped iterating.

If it's easier to understand, here's an alternative wording:

It is an error to mutate the dictionary *and then continue to iterate over it*.

ChrisA


From grant.b.edwards at gmail.com  Thu May 31 13:43:28 2018
From: grant.b.edwards at gmail.com (Grant Edwards)
Date: Thu, 31 May 2018 17:43:28 +0000 (UTC)
Subject: Why exception from os.path.exists()?
References: <87tvqoghhh.fsf@elektro.pacujo.net>
 <CAPTjJmrhddtg_WEpL=jJtPuPhKfOw8=_NGNH2do8XXn1xgbzww@mail.gmail.com>
 <mailman.117.1527770804.2804.python-list@python.org>
 <87o9gwgepm.fsf@elektro.pacujo.net>
 <CAPTjJmq0CKzzLJKdBDx9-zYAnf8EBugFuai3b5-rM1oTeFTg4A@mail.gmail.com>
 <mailman.119.1527772205.2804.python-list@python.org>
 <87k1rkgd2k.fsf@elektro.pacujo.net>
 <CAPTjJmq9W2MAbmJoOYA3EQvAiiRyX-i-80HXR1rJvhZBzuMAVw@mail.gmail.com>
 <CACac1F-NYVTOhovEsCQmuPopakrF6ypmH-SWC-xJQug_u3e+Sg@mail.gmail.com>
Message-ID: <pepc80$m5k$1@blaine.gmane.org>

On 2018-05-31, Paul Moore <p.f.moore at gmail.com> wrote:
> On 31 May 2018 at 15:01, Chris Angelico <rosuav at gmail.com> wrote:
>> Can someone on Windows see if there are other path names that raise
>> ValueError there? Windows has a whole lot more invalid characters, and
>> invalid names as well.
>
> On Windows:
>
>>>> os.path.exists('\0')
> ValueError: stat: embedded null character in path
>
>>>> os.path.exists('?')
> False
>
>>>> os.path.exists('\u77412')
> False
>
>>>> os.path.exists('\t')
> False
>
> Honestly, I think the OP's point is correct. os.path.exists should
> simply return False if the filename has an embedded \0 - at least on
> Unix.

Except on the platform in quetion filenames _don't_ contain an
embedded \0.  What was passed was _not_ a path/filename.

You might as well have passed a floating point number or a dict.

> Although I wouldn't consider this as anything even remotely like a
> significant issue...

Agreed, but the thread will continue for months and generate hundreds
of followup.

-- 
Grant Edwards               grant.b.edwards        Yow! You were s'posed
                                  at               to laugh!
                              gmail.com            



From rosuav at gmail.com  Thu May 31 13:55:31 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 1 Jun 2018 03:55:31 +1000
Subject: Indented multi-line strings (was: "Data blocks" syntax
 specification draft)
In-Reply-To: <48620ae1be64499abf9baf065273e4c3@F5.com>
References: <CAHiMU6cGz=X4LMcYac=_Us0+9ATPTrJPLZaeXmK07KbnNFSP2A@mail.gmail.com>
 <CAE6NSRA9sNDkL2RgpaUnziRv5ka2j_L4y1rScKoLJSnR+KCXpg@mail.gmail.com>
 <mailman.4.1526955481.18022.python-list@python.org>
 <pe0bn1$8ns$1@dont-email.me>
 <CAE6NSRA4=wxwAWCXpJg9sXZgdDrFY5GN8_JybYg1zwgi-aYCQQ@mail.gmail.com>
 <9bf0783c8b044b348769942bda950043@F5.com>
 <20180523162535.xbtqnxi7yqv4ijlg@hjp.at>
 <CALwzidnMYFyxM5cqHZVpEd4KBDx-E51Gzx2gvhMuyPgx90PD9A@mail.gmail.com>
 <20180529091919.xxr7rt5yoplwdge6@hjp.at>
 <CALwzidkQQshcfDfqzONtP18D4c7QshsPeaXfArWQUt=2SxoyFQ@mail.gmail.com>
 <20180530224733.6qai7jsw4bknkukr@hjp.at>
 <48620ae1be64499abf9baf065273e4c3@F5.com>
Message-ID: <CAPTjJmrhCNOTZc0dE2XdPWpxE3VBvN=c3tqk1cYzEX3+bR=ugA@mail.gmail.com>

On Fri, Jun 1, 2018 at 12:39 AM, Dan Strohl via Python-list
<python-list at python.org> wrote:
>> This is of course not a problem if the *trailing* quote determines the
>> indentation:
>>
>>     a_multi_line_string = i'''
>>            Py-
>>           thon
>>         '''
>
> I get the point, but it feels like it would be a pain to use, and it "Feels" different from the other python indenting, which is something that I would want to stay away from changing.
>
>> > In any case, Chris made a good point that I agree with. This doesn't
>> > really need to be syntax at all, but could just be implemented as a
>> > new string method.
>>
>> Depending on the details, not quite. A method wouldn't get the horizontal
>> position of the leading quote. It could infer the position of the trailing quote,
>> though.
>>
>
> What about if we used Chris's approach, but added a parameter to the method to handle the indent?
>
> For example,
>
> Test = """
>         Hello, this is a
>      Multiline indented
>     String
>     """.outdent(4)
>
>
> The outdent method could look like:
>
> string.outdent(size=None)
>     """
>     :param size : The number of spaces to remove from the beginning of each line in the string.  Non space characters will not be removed.  IF this is None, the number of characters in the first line of the string will be used.  If this is an iterable, the numbers returned from each iteration will be used for their respective lines.  If there are more lines than iterations, the last iteration will be used for subsequent lines.
>
> This solves the problem in a very pythonic way, while allowing the flexibility to handle different needs.
>

Sure! Though I'd drop the iterable option - YAGNI. Keep the basic API
simple. Just an integer or None, where None's is defined in terms of
the string itself.

ChrisA


From tjreedy at udel.edu  Thu May 31 14:33:36 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 31 May 2018 14:33:36 -0400
Subject: Override built in types... possible? or proposal.
In-Reply-To: <6c01e72e594e4a51b2cff6ed4de5b9ff@F5.com>
References: <6c01e72e594e4a51b2cff6ed4de5b9ff@F5.com>
Message-ID: <pepf1t$vgv$1@blaine.gmane.org>

On 5/31/2018 10:49 AM, Dan Strohl via Python-list wrote:
> Is it possible to override the assignment of built in types to the shorthand representations?

By which I presume you mean literals and overt (non-comprehension) 
displays.  So you wish that Python should be even more dynamic.  (Some 
wish it were less so ;-)

The CPython parser is generated by a parser-generator program from the 
python grammar and a table of non-default functions to call when the 
parser recognizes certain grammatical productions.  For instance, 
*stringliteral* is mapped to str.  I assume that the mapping is 
currently direct, and not routed through the builtins dict.  I don't 
know what other implementations do.

To change this, I believe you would have to introduce indirect mapping 
functions.  One possibility would be C equivalents of functions like

def get_str(): return builtins['str']

Then you could change future parsing by executing
   builtins['str'] = mystr\

However, this would affect the parsing of imported modules, if and when 
they are parsed, and exec and eval calls made within imported functions. 
  This would not be good.

So I believe you would also need to introduce a module copy of a subset 
of builtins, call it '__modclass__', whose keys would be the classes 
called by the parser, and use that in the get_xyz functions.  Then I 
believe you could change parsing within a module by executing
    __modclass__['str'] = mystr

> and yes, I know I could simply not do [] and always do my_list('item1', 'item2', 'item3')

I think we should stick with this.

> This would only be scoped to the current module and would not be imported when that module was imported.

The harder part, I think, is "and not affect parsing of imported modules 
if they are not already parsed and not affect exec and eval calls in 
imported modules.


-- 
Terry Jan Reedy



From bruceg113355 at gmail.com  Thu May 31 15:49:00 2018
From: bruceg113355 at gmail.com (bruceg113355 at gmail.com)
Date: Thu, 31 May 2018 12:49:00 -0700 (PDT)
Subject: How do I list only the methods I define in a class?
Message-ID: <36e40db6-c962-4f92-80ae-ecd41b02007c@googlegroups.com>

How do I list only the methods I define in a class?

For example:

class Produce():
    def __init__ (self):
        print (dir (Produce))
    
    def apples(self):
        pass
    
    def peaches(self):
        pass
    
    def pumpkin (self):
        pass

The print (dir(Produce)) statement displays:
['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__le__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', 'apples', 'peaches', 'pumpkin']

I am only interested in 'apples', 'peaches', 'pumpkin'

The above is only an example.
In my real code there are methods with and without leading "__". 

Can I assume methods after __weakref__ are the methods I defined?
Is there a Python function to do what I need?

Thanks,
Bruce


From beliavsky at aol.com  Thu May 31 16:26:56 2018
From: beliavsky at aol.com (beliavsky at aol.com)
Date: Thu, 31 May 2018 13:26:56 -0700 (PDT)
Subject: Python library to break text into words
Message-ID: <086f13d1-018a-4433-967f-881e95410b2a@googlegroups.com>

I bought some e-books in a Humble Bundle. The file names are shown below. I would like to hyphenate words within the file names, so that the first three titles are

a_devils_chaplain.pdf
atomic_accidents.pdf
chaos_making_a_new_science.pdf

Is there a Python library that uses intelligent guesses to break sequences of characters into words? The general strategy would be to break strings into the longest words possible. The library would need to "know" a sizable subset of words in English.

adevilschaplain.pdf
atomicaccidents.pdf
chaos_makinganewscience.pdf
dinosaurswithoutbones.pdf
essaysinscience.pdf
genius_thelifeandscienceofrichardfeynman.pdf
louisagassiz_creatorofamericanscience.pdf
martiansummer.pdf
mind_aunifiedtheoryoflifeandintelligence.pdf
noturningback.pdf
onshakyground.pdf
scienceandphilosophy.pdf
sevenelementsthatchangedtheworld.pdf
strangeangel.pdf
theboywhoplayedwithfusion.pdf
thecanon.pdf
theedgeofphysics.pdf
thegenome.pdf
thegoldilocksenigma.pdf
thesphinxatdawn.pdf
unnaturalselection.pdf
water_thefateofourmostpreciousresource.pdf
x-15diary.pdf


From rosuav at gmail.com  Thu May 31 16:45:59 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 1 Jun 2018 06:45:59 +1000
Subject: Python library to break text into words
In-Reply-To: <086f13d1-018a-4433-967f-881e95410b2a@googlegroups.com>
References: <086f13d1-018a-4433-967f-881e95410b2a@googlegroups.com>
Message-ID: <CAPTjJmpfgr55=rGZmrP3jz-BCTB+YoTaNeJ_pvOVg+GznKEO9w@mail.gmail.com>

On Fri, Jun 1, 2018 at 6:26 AM, beliavsky--- via Python-list
<python-list at python.org> wrote:
> I bought some e-books in a Humble Bundle. The file names are shown below. I would like to hyphenate words within the file names, so that the first three titles are
>
> a_devils_chaplain.pdf
> atomic_accidents.pdf
> chaos_making_a_new_science.pdf
>
> Is there a Python library that uses intelligent guesses to break sequences of characters into words? The general strategy would be to break strings into the longest words possible. The library would need to "know" a sizable subset of words in English.
>
> adevilschaplain.pdf
> atomicaccidents.pdf
> chaos_makinganewscience.pdf

Let's start with the easy bit. On many MANY Unix-like systems, you can
find a dictionary of words in the user's language (not necessarily
English, but that's appropriate here - it means your script will work
on a French or German or Turkish or Russian system as well) at
/usr/share/dict/words. All you have to do is:

with open("/usr/share/dict/words") as f:
    words = f.read().strip().split("\n")

Tada! That'll give you somewhere between 50K and 650K words, for
English. (I have eight English dictionaries installed, ranging from
american-english-small and british-english-small at 51K all the way up
to their corresponding -insane variants at 650K.) Most likely you'll
have about 100K words, which is a good number to be working with. If
you're on Windows, see if you can just download something from
wordlist.sourceforge.net or similar; it should be in the same format.

So! Now for the next step. You need to split a pile of letters such
that each of the resulting pieces is a word. You're probably going to
find some that just don't work ("x-15diary" seems dubious), but for
the most part, you should get at least _some_ result. You suggested a
general strategy of breaking strings into the longest words possible,
which would be easy enough to code. A basic algorithm of "take as many
letters as you can while still finding a word" is likely to give you
fairly decent results. You'll need a way of backtracking in the event
that the rest of the letters don't work ("theedgeofphysics" will take
a first word of "thee", but then "dgeofphysics" isn't going to work
out well), but otherwise, I think your basic idea is sound.

Should be a fun project!

ChrisA


From tallpaul at gmail.com  Thu May 31 16:51:24 2018
From: tallpaul at gmail.com (Paul)
Date: Thu, 31 May 2018 13:51:24 -0700
Subject: Sorting and spaces.
In-Reply-To: <pep973$rro$1@blaine.gmane.org>
References: <pep073$kv3$1@gioia.aioe.org> <pep973$rro$1@blaine.gmane.org>
Message-ID: <CA+og5uquE01oAqaKXGpD118=xqZHaE-KewofZo6Ep2VW63Z_DA@mail.gmail.com>

In the US, at least, spaces should sort before letters.

MRAB brought up an important point. It depends on your purpose, of course,
but having all the capitalized-beginning items appear separately from all
of the lower-cased-beginning items can be very annoying to a user.


From hjp-python at hjp.at  Thu May 31 17:05:35 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Thu, 31 May 2018 23:05:35 +0200
Subject: Indented multi-line strings (was: "Data blocks" syntax
 specification draft)
In-Reply-To: <48620ae1be64499abf9baf065273e4c3@F5.com>
References: <mailman.4.1526955481.18022.python-list@python.org>
 <pe0bn1$8ns$1@dont-email.me>
 <CAE6NSRA4=wxwAWCXpJg9sXZgdDrFY5GN8_JybYg1zwgi-aYCQQ@mail.gmail.com>
 <9bf0783c8b044b348769942bda950043@F5.com>
 <20180523162535.xbtqnxi7yqv4ijlg@hjp.at>
 <CALwzidnMYFyxM5cqHZVpEd4KBDx-E51Gzx2gvhMuyPgx90PD9A@mail.gmail.com>
 <20180529091919.xxr7rt5yoplwdge6@hjp.at>
 <CALwzidkQQshcfDfqzONtP18D4c7QshsPeaXfArWQUt=2SxoyFQ@mail.gmail.com>
 <20180530224733.6qai7jsw4bknkukr@hjp.at>
 <48620ae1be64499abf9baf065273e4c3@F5.com>
Message-ID: <20180531210535.pbgtlwtgsbk6fh3c@hjp.at>

[Strange: I didn't get this mail through the list, only directly]

On 2018-05-31 14:39:17 +0000, Dan Strohl wrote:
> > This is of course not a problem if the *trailing* quote determines the
> > indentation:
> > 
> >     a_multi_line_string = i'''
> >            Py-
> >           thon
> >         '''
> 
> I get the point, but it feels like it would be a pain to use, and it
> "Feels" different from the other python indenting, which is something
> that I would want to stay away from changing.

Yes, it's the wrong way around. The indentation should be determined by
the start quote. That's why I initially wrote that the quotes must
line up vertically.

Unfortunately you can't write 

    a_multi_line_string = 
        i'''
            Py-
           thon
         '''

although you can write 

    a_multi_line_string = \
        i'''
            Py-
           thon
         '''

which is visually not much worse.

> > > In any case, Chris made a good point that I agree with. This doesn't
> > > really need to be syntax at all, but could just be implemented as a
> > > new string method.
> > 
> > Depending on the details, not quite. A method wouldn't get the horizontal
> > position of the leading quote. It could infer the position of the trailing quote,
> > though.
> > 
> 
> What about if we used Chris's approach, but added a parameter to the
> method to handle the indent? 
> 
> For example, 
> 
> Test = """
>         Hello, this is a
>      Multiline indented
>     String
>     """.outdent(4)

Eek! No, I don't think that's a good idea. It means that the programmer
has to count spaces and has to remember to adjust the parameter if the
indentation changes (e.g. because the block is wrapped in a loop or
factored out to a function).


> The outdent method could look like:
> 
> string.outdent(size=None)
>     """
>     :param size : The number of spaces to remove from the beginning of
>     each line in the string.  Non space characters will not be
>     removed.  IF this is None, the number of characters in the first
>     line of the string will be used.

The default should be the minimum number of leading spaces on non-empty
lines, I think. This is compatible with PEP 257. And in fact it allows
all lines to start with whitespace if the string ends with a newline
(which is a weird dependency, but probably not much of a restriction in
practice).


>     If this is an iterable, the numbers returned from each iteration
>     will be used for their respective lines.  If there are more lines
>     than iterations, the last iteration will be used for subsequent
>     lines.

This looks like overkill to me. What would be the use case?

> This solves the problem in a very pythonic way,

Everybody has their own definition of "pythonic", I guess.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180531/9f0840c1/attachment.sig>

From maillist at schwertberger.de  Thu May 31 17:09:58 2018
From: maillist at schwertberger.de (Dietmar Schwertberger)
Date: Thu, 31 May 2018 23:09:58 +0200
Subject: Python library to break text into words
In-Reply-To: <086f13d1-018a-4433-967f-881e95410b2a@googlegroups.com>
References: <086f13d1-018a-4433-967f-881e95410b2a@googlegroups.com>
Message-ID: <24d4f9c6-69b4-ce57-0c66-b8806b9269ae@schwertberger.de>

On 5/31/2018 10:26 PM, beliavsky--- via Python-list wrote:
> Is there a Python library that uses intelligent guesses to break sequences of characters into words? The general strategy would be to break strings into the longest words possible. The library would need to "know" a sizable subset of words in English.

No need to re-invent the wheel:

import webbrowswer
webbrowser.open( 
"https://www.google.com/search?q=%s"%"atomicaccidents.pdf"+"+amazon", new=0)


Copy the title from the browser window and paste it into your script's 
window which will read it with input() and rename the file.

Regards,

Dietmar




From hjp-python at hjp.at  Thu May 31 17:16:10 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Thu, 31 May 2018 23:16:10 +0200
Subject: Indented multi-line strings
In-Reply-To: <889761ba-616e-7825-bbbe-a026e2853820@mrabarnett.plus.com>
References: <pe0bn1$8ns$1@dont-email.me>
 <CAE6NSRA4=wxwAWCXpJg9sXZgdDrFY5GN8_JybYg1zwgi-aYCQQ@mail.gmail.com>
 <9bf0783c8b044b348769942bda950043@F5.com>
 <20180523162535.xbtqnxi7yqv4ijlg@hjp.at>
 <CALwzidnMYFyxM5cqHZVpEd4KBDx-E51Gzx2gvhMuyPgx90PD9A@mail.gmail.com>
 <20180529091919.xxr7rt5yoplwdge6@hjp.at>
 <CALwzidkQQshcfDfqzONtP18D4c7QshsPeaXfArWQUt=2SxoyFQ@mail.gmail.com>
 <20180530224733.6qai7jsw4bknkukr@hjp.at>
 <48620ae1be64499abf9baf065273e4c3@F5.com>
 <889761ba-616e-7825-bbbe-a026e2853820@mrabarnett.plus.com>
Message-ID: <20180531211610.mafcf6kjfadog777@hjp.at>

On 2018-05-31 16:44:10 +0100, MRAB wrote:
> I was also thinking that it could take the indentation from the first line,
> but that if you wanted the first line to have a larger indent than the
> remaining lines, you could replace the first space that you want to keep
> with a non-whitespace character and then pass that character to the method.
> 
> For example:
> 
> Test = """\
>      _   Hello, this is a
>       Multiline indented
>      String
>      """.outdent(padding='_')
> 
> Outdent so that the first line is flush to the margin:
> 
> _   Hello, this is a
>  Multiline indented
> String
> 
> The padding argument tells it to replace the initial '_':
> 
>     Hello, this is a
>  Multiline indented
> String

I would prefer to remove the padding, like this:

    Test = """
        |    Hello, this is a
        | Multiline indented
        |String
        """.outdent(padding='|')

Or write it like this?

    Test = """|    Hello, this is a
              | Multiline indented
              |String
              """.outdent(padding='|')

Hmm, the sign of Zorro! :-)

I'm starting to like outdent(), but that may be my TIMTOWTDIism
speaking.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180531/5f2e64b9/attachment.sig>

From hjp-python at hjp.at  Thu May 31 17:24:44 2018
From: hjp-python at hjp.at (Peter J. Holzer)
Date: Thu, 31 May 2018 23:24:44 +0200
Subject: Indented multi-line strings (was: "Data blocks" syntax
 specification draft)
In-Reply-To: <20180531210535.pbgtlwtgsbk6fh3c@hjp.at>
References: <pe0bn1$8ns$1@dont-email.me>
 <CAE6NSRA4=wxwAWCXpJg9sXZgdDrFY5GN8_JybYg1zwgi-aYCQQ@mail.gmail.com>
 <9bf0783c8b044b348769942bda950043@F5.com>
 <20180523162535.xbtqnxi7yqv4ijlg@hjp.at>
 <CALwzidnMYFyxM5cqHZVpEd4KBDx-E51Gzx2gvhMuyPgx90PD9A@mail.gmail.com>
 <20180529091919.xxr7rt5yoplwdge6@hjp.at>
 <CALwzidkQQshcfDfqzONtP18D4c7QshsPeaXfArWQUt=2SxoyFQ@mail.gmail.com>
 <20180530224733.6qai7jsw4bknkukr@hjp.at>
 <48620ae1be64499abf9baf065273e4c3@F5.com>
 <20180531210535.pbgtlwtgsbk6fh3c@hjp.at>
Message-ID: <20180531212444.6dmoztjc5lqltp7o@hjp.at>

On 2018-05-31 23:05:35 +0200, Peter J. Holzer wrote:
> [Strange: I didn't get this mail through the list, only directly]

Found it. For some reason "Avoid duplicate copies of messages" was
enabled. I normally always disable this when I subscribe to a
mailinglist and I'm surprised that I haven't noticed it before.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180531/a3d79a84/attachment.sig>

From rosuav at gmail.com  Thu May 31 17:35:29 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 1 Jun 2018 07:35:29 +1000
Subject: Sorting and spaces.
In-Reply-To: <CA+og5uquE01oAqaKXGpD118=xqZHaE-KewofZo6Ep2VW63Z_DA@mail.gmail.com>
References: <pep073$kv3$1@gioia.aioe.org> <pep973$rro$1@blaine.gmane.org>
 <CA+og5uquE01oAqaKXGpD118=xqZHaE-KewofZo6Ep2VW63Z_DA@mail.gmail.com>
Message-ID: <CAPTjJmp1+xfNAQxeOWR9qsjGO46s4Qy11Ba5_B5GXB+eZALYjA@mail.gmail.com>

On Fri, Jun 1, 2018 at 6:51 AM, Paul <tallpaul at gmail.com> wrote:
> In the US, at least, spaces should sort before letters.
>
> MRAB brought up an important point. It depends on your purpose, of course,
> but having all the capitalized-beginning items appear separately from all
> of the lower-cased-beginning items can be very annoying to a user.

And that's why locale-based sorting exists. You can't set a single
definition of sorting and expect it to work for everyone. In fact,
even within a language, there can be different sorting rules for
different types of data (a list of names might be sorted one way, but
a list of book titles differently). Peter's recommendation covers most
of that, modulo the types-of-data complexity; you should be able to
sort German text according to German rules, and Dutch text according
to Dutch rules.

ChrisA


From rosuav at gmail.com  Thu May 31 17:41:35 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 1 Jun 2018 07:41:35 +1000
Subject: Indented multi-line strings (was: "Data blocks" syntax
 specification draft)
In-Reply-To: <20180531210535.pbgtlwtgsbk6fh3c@hjp.at>
References: <mailman.4.1526955481.18022.python-list@python.org>
 <pe0bn1$8ns$1@dont-email.me>
 <CAE6NSRA4=wxwAWCXpJg9sXZgdDrFY5GN8_JybYg1zwgi-aYCQQ@mail.gmail.com>
 <9bf0783c8b044b348769942bda950043@F5.com>
 <20180523162535.xbtqnxi7yqv4ijlg@hjp.at>
 <CALwzidnMYFyxM5cqHZVpEd4KBDx-E51Gzx2gvhMuyPgx90PD9A@mail.gmail.com>
 <20180529091919.xxr7rt5yoplwdge6@hjp.at>
 <CALwzidkQQshcfDfqzONtP18D4c7QshsPeaXfArWQUt=2SxoyFQ@mail.gmail.com>
 <20180530224733.6qai7jsw4bknkukr@hjp.at>
 <48620ae1be64499abf9baf065273e4c3@F5.com>
 <20180531210535.pbgtlwtgsbk6fh3c@hjp.at>
Message-ID: <CAPTjJmpts7Hb7e24htMOxnFtEo-SCf=MKp9UZ7JKsDU1r8va0A@mail.gmail.com>

On Fri, Jun 1, 2018 at 7:05 AM, Peter J. Holzer <hjp-python at hjp.at> wrote:
> [Strange: I didn't get this mail through the list, only directly]
>
> On 2018-05-31 14:39:17 +0000, Dan Strohl wrote:
>> The outdent method could look like:
>>
>> string.outdent(size=None)
>>     """
>>     :param size : The number of spaces to remove from the beginning of
>>     each line in the string.  Non space characters will not be
>>     removed.  IF this is None, the number of characters in the first
>>     line of the string will be used.
>
> The default should be the minimum number of leading spaces on non-empty
> lines, I think. This is compatible with PEP 257. And in fact it allows
> all lines to start with whitespace if the string ends with a newline
> (which is a weird dependency, but probably not much of a restriction in
> practice).

Exactly. The default will be the most commonly used option when
working with string literals; explicitly setting it is there if you
need it, but won't be the normal way you do things.

Either way, if attached to a string literal, with either no parameter
or a literal integer, this would be a valid candidate for constant
folding. (There's no way to monkeypatch or shadow anything.) At that
point, we would have all the benefits of a new string literal type,
with no syntactic changes, just the creation of the method.

ChrisA


From rosuav at gmail.com  Thu May 31 17:42:31 2018
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 1 Jun 2018 07:42:31 +1000
Subject: Python library to break text into words
In-Reply-To: <24d4f9c6-69b4-ce57-0c66-b8806b9269ae@schwertberger.de>
References: <086f13d1-018a-4433-967f-881e95410b2a@googlegroups.com>
 <24d4f9c6-69b4-ce57-0c66-b8806b9269ae@schwertberger.de>
Message-ID: <CAPTjJmpdxo0+qnP=TfP5z6gHwsNEL-AbXk7ozKUeLb4G_ULUcw@mail.gmail.com>

On Fri, Jun 1, 2018 at 7:09 AM, Dietmar Schwertberger
<maillist at schwertberger.de> wrote:
> On 5/31/2018 10:26 PM, beliavsky--- via Python-list wrote:
>>
>> Is there a Python library that uses intelligent guesses to break sequences
>> of characters into words? The general strategy would be to break strings
>> into the longest words possible. The library would need to "know" a sizable
>> subset of words in English.
>
>
> No need to re-invent the wheel:
>
> import webbrowswer
> webbrowser.open(
> "https://www.google.com/search?q=%s"%"atomicaccidents.pdf"+"+amazon", new=0)
>
>
> Copy the title from the browser window and paste it into your script's
> window which will read it with input() and rename the file.

10/10 for grin-worthy solutions :)

ChrisA


From tallpaul at gmail.com  Thu May 31 17:42:39 2018
From: tallpaul at gmail.com (Paul)
Date: Thu, 31 May 2018 14:42:39 -0700
Subject: Attachments? Re: Indented multi-line strings (was: "Data blocks"
 syntax specification draft)
Message-ID: <CA+og5up=UG2wD_brvCXK9xRBeUVT_YjkR5MHKs+Z+FGPJLY40w@mail.gmail.com>

I have heard that attachments to messages are not allowed on this list,
which makes sense. However I notice that messages from Peter do have an
attachment, i.e., a signature.asc file.

I'm just curious; why and how do those particular attachments get through?
And should they get through, I guess? E.G., what if I attach a malicious
file labeled as .asc?

[Peter, I am not suggesting anything about you!  ;). ]

Paul C.


From beliavsky at aol.com  Thu May 31 18:12:36 2018
From: beliavsky at aol.com (beliavsky at aol.com)
Date: Thu, 31 May 2018 15:12:36 -0700 (PDT)
Subject: Python library to break text into words
In-Reply-To: <mailman.145.1527802295.2804.python-list@python.org>
References: <086f13d1-018a-4433-967f-881e95410b2a@googlegroups.com>
 <24d4f9c6-69b4-ce57-0c66-b8806b9269ae@schwertberger.de>
 <mailman.145.1527802295.2804.python-list@python.org>
Message-ID: <05e78263-3570-49db-8349-95cca44edf8c@googlegroups.com>

On Thursday, May 31, 2018 at 5:31:48 PM UTC-4, Dietmar Schwertberger wrote:
> On 5/31/2018 10:26 PM, beliavsky--- via Python-list wrote:
> > Is there a Python library that uses intelligent guesses to break sequences of characters into words? The general strategy would be to break strings into the longest words possible. The library would need to "know" a sizable subset of words in English.
> 
> No need to re-invent the wheel:
> 
> import webbrowswer
> webbrowser.open( 
> "https://www.google.com/search?q=%s"%"atomicaccidents.pdf"+"+amazon", new=0)
> 
> 
> Copy the title from the browser window and paste it into your script's 
> window which will read it with input() and rename the file.
> 
> Regards,
> 
> Dietmar

Thanks to both of you.


From steve+comp.lang.python at pearwood.info  Thu May 31 19:50:34 2018
From: steve+comp.lang.python at pearwood.info (Steven D'Aprano)
Date: Thu, 31 May 2018 23:50:34 +0000 (UTC)
Subject: Override built in types... possible? or proposal.
References: <6c01e72e594e4a51b2cff6ed4de5b9ff@F5.com>
 <mailman.124.1527778431.2804.python-list@python.org>
 <pep96k$u5r$1@dont-email.me>
Message-ID: <peq1o9$1f4$4@blaine.gmane.org>

On Thu, 31 May 2018 09:51:30 -0700, Rob Gaddi wrote:

> On 05/31/2018 07:49 AM, Dan Strohl wrote:
>> Is it possible to override the assignment of built in types to the
>> shorthand representations?   And if not, is it a reasonable thought to
>> consider adding?
[...]

> My problem with this idea is that it breaks expectations.

No worse than shadowing builtin names.



> If I know one
> thing as a Python programmer, it's that 'Bob' is a str.

True. But if there were such a feature as Dan asked for, you would learn 
that "Bob" might be anything, depending on the current state of the 
module. That's not much worse than the idea that int("123") might return 
anything, depending on the current state of the module and builtins.

Still, I agree that this is probably a tad too much dynamism even for a 
language as dynamic as Python.


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson



From bgailer at gmail.com  Thu May 31 22:18:17 2018
From: bgailer at gmail.com (bob gailer)
Date: Thu, 31 May 2018 22:18:17 -0400
Subject: How do I list only the methods I define in a class?
In-Reply-To: <36e40db6-c962-4f92-80ae-ecd41b02007c@googlegroups.com>
References: <36e40db6-c962-4f92-80ae-ecd41b02007c@googlegroups.com>
Message-ID: <cd85c7a9-1de0-29ad-6ed1-b222a260f1ae@gmail.com>

On 5/31/2018 3:49 PM, bruceg113355 at gmail.com wrote:
 > How do I list only the methods I define in a class?
Here's a class with some method, defined in various ways:

 >>> class x():
...???? a=3
...???? def f():pass
...???? g = lambda: None
...

 >>> l=[v for v in x.__dict__.items()]; print(l)
[('a', 3), ('f', <function x.f at 0x000001DEDD693840>), ('__module__', 
'__main__'), ('__dict__', <attribute '__dict__' of 'x' objects>), 
('__doc__', None), ('__weakref__', <attribute '__weakref__' of 'x' 
objects>)]

 >>> import inspect
 >>> [(key, value) for key, value in l if inspect.isfunction(i[1])]
[('f', <function x.f at 0x000001DEDD6936A8>), ('g', <function x.<lambda> 
at 0x000001DEDD693620>)]

HTH



From mike.junk.46 at att.net  Thu May 31 22:26:48 2018
From: mike.junk.46 at att.net (Mike McClain)
Date: Thu, 31 May 2018 19:26:48 -0700
Subject: ... (ellipsis)
In-Reply-To: <mailman.30.1527436804.26438.python-list@python.org>
References: <mailman.30.1527436804.26438.python-list@python.org>
Message-ID: <20180601022648.GA32039@playground>

    I'm having understanding the use if the ellipsis.
I keep reading that it is used in slices but every time I use it I get
'Syntax error' in 2.7 if 'Type error' in 3.2.

In python2.7:
l=range(15)
l[...:11]
Syntax error
l[3:...]
Syntax error
l[3:...:11]
Syntax error

In python3.2 it becomes 'Type error'  but still doesn't give me
anything usable.

Is the ellipsis really useable in anything other than documentation or
does it actually have a function in python?
If the latter would someone please provide an example showing how it
is used?

Thanks,
Mike
--
I Don't care how little your country is, you got a right to run it like
you want to. When big nations quit meddling then the world will have peace.
    - Will Rogers


From mike.junk.46 at att.net  Thu May 31 22:44:35 2018
From: mike.junk.46 at att.net (Mike McClain)
Date: Thu, 31 May 2018 19:44:35 -0700
Subject: version
In-Reply-To: <mailman.30.1527436804.26438.python-list@python.org>
References: <mailman.30.1527436804.26438.python-list@python.org>
Message-ID: <20180601024435.GA32258@playground>

    OK so I installed python 3.2, which is the latest available as a
package in Debian Wheezy, because I've seen so many folks say it's a
waste of time to play with Py2.7.
    Immediately my python playground 'my.python.py' failed as soon as
I changes the '#!' line to python3.2.
    Most of the errors were because I had used 'print' without parens
which 2.7 liked but 3.2 doesn't.
Is there a way in a script to know which version of python is being
run so I can write:
    If (version == 2.7):
        do it this way
    elsif (version == 3.2):
        do it another way

Thanks,
Mike
--
I Don't care how little your country is, you got a right to run it like
you want to. When big nations quit meddling then the world will have peace.
    - Will Rogers


From arj.python at gmail.com  Thu May 31 22:45:53 2018
From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer)
Date: Fri, 1 Jun 2018 06:45:53 +0400
Subject: Attachments? Re: Indented multi-line strings (was: "Data blocks"
 syntax specification draft)
In-Reply-To: <CA+og5up=UG2wD_brvCXK9xRBeUVT_YjkR5MHKs+Z+FGPJLY40w@mail.gmail.com>
References: <CA+og5up=UG2wD_brvCXK9xRBeUVT_YjkR5MHKs+Z+FGPJLY40w@mail.gmail.com>
Message-ID: <CADrxXXknXjv7NToKMPgpNoc__Sq_3zvPn+pqOnJkubRTEDo9Xg@mail.gmail.com>

as this sig file is a common occurance, attaching the topic to the data
blocks thread is not really necessary

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

On Fri, 1 Jun 2018, 01:49 Paul, <tallpaul at gmail.com> wrote:

> I have heard that attachments to messages are not allowed on this list,
> which makes sense. However I notice that messages from Peter do have an
> attachment, i.e., a signature.asc file.
>
> I'm just curious; why and how do those particular attachments get through?
> And should they get through, I guess? E.G., what if I attach a malicious
> file labeled as .asc?
>
> [Peter, I am not suggesting anything about you!  ;). ]
>
> Paul C.
> --
> https://mail.python.org/mailman/listinfo/python-list
>


From tjreedy at udel.edu  Thu May 31 23:00:13 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 31 May 2018 23:00:13 -0400
Subject: ... (ellipsis)
In-Reply-To: <20180601022648.GA32039@playground>
References: <mailman.30.1527436804.26438.python-list@python.org>
 <20180601022648.GA32039@playground>
Message-ID: <peqcnq$464$1@blaine.gmane.org>

On 5/31/2018 10:26 PM, Mike McClain wrote:
>      I'm having understanding the use if the ellipsis.
> I keep reading that it is used in slices

By numpy for numpy multidimensional arrays, which have their own 
__getitem__, which recognizes and gives meaning to ...

-- 
Terry Jan Reedy



From jlgimeno71 at gmail.com  Thu May 31 23:08:20 2018
From: jlgimeno71 at gmail.com (Jorge Gimeno)
Date: Thu, 31 May 2018 20:08:20 -0700
Subject: version
In-Reply-To: <20180601024435.GA32258@playground>
References: <mailman.30.1527436804.26438.python-list@python.org>
 <20180601024435.GA32258@playground>
Message-ID: <CANfN=K_oE+Esfwz-1Xrw0wbXGPke8fHezX2N27Pqz36H04V01A@mail.gmail.com>

Look at the six module

On Thu, May 31, 2018, 7:57 PM Mike McClain <mike.junk.46 at att.net> wrote:

>     OK so I installed python 3.2, which is the latest available as a
> package in Debian Wheezy, because I've seen so many folks say it's a
> waste of time to play with Py2.7.
>     Immediately my python playground 'my.python.py' failed as soon as
> I changes the '#!' line to python3.2.
>     Most of the errors were because I had used 'print' without parens
> which 2.7 liked but 3.2 doesn't.
> Is there a way in a script to know which version of python is being
> run so I can write:
>     If (version == 2.7):
>         do it this way
>     elsif (version == 3.2):
>         do it another way
>
> Thanks,
> Mike
> --
> I Don't care how little your country is, you got a right to run it like
> you want to. When big nations quit meddling then the world will have peace.
>     - Will Rogers
> --
> https://mail.python.org/mailman/listinfo/python-list
>


From arj.python at gmail.com  Thu May 31 23:29:27 2018
From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer)
Date: Fri, 1 Jun 2018 07:29:27 +0400
Subject: Python library to break text into words
In-Reply-To: <086f13d1-018a-4433-967f-881e95410b2a@googlegroups.com>
References: <086f13d1-018a-4433-967f-881e95410b2a@googlegroups.com>
Message-ID: <CADrxXXmHaUgU-59wWpczb_PVyjm9mvTSwdjRYT9vmBT36YVj7A@mail.gmail.com>

1-> search in dict, identify all words example :

meaningsofoffers

.. identified words :

me
an
mean
in
meaning
meanings
so
of
of
offer
offers

2-> next filter duplicates, i.e. of above in a new list as the original
list serves as chronological reference

3-> next chose the words whose lengths make up the length of the string

4-> if several solutions choose non-overlapping and chronologically sound
ones

5-> unused letters are treated as words where non-natural words are
included, that can be problematic if sub words are found in it and point 7
might be the way to go

6-> in the case of non-regular words included, the program returns the best
solutions for the user to choose from

i have branded the above 6 points algorithm as the Arj.mu Algorithm of Word
Extraction in Connected Letters

7-> if machine learning is enacted, the above point (6) serves as training
(on an everyday usage app) or it can directly train on predefined examples

8-> if typos are assumed to be found titles, then the title should be
assumed to have the corrected words and a new search is done on this
assumed title. in which case the results are added to the non corrected
version and then point 6 above is executed

8.1-> for assumptions in 8, Natural Language modules might be used

9-> titles can contain numbers, dates, author names and others and as such
is not covered by the points above


Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ


From tallpaul at gmail.com  Thu May 31 23:32:22 2018
From: tallpaul at gmail.com (Paul)
Date: Fri, 1 Jun 2018 03:32:22 +0000
Subject: Attachments? Re: Indented multi-line strings (was: "Data blocks"
 syntax specification draft)
In-Reply-To: <CADrxXXknXjv7NToKMPgpNoc__Sq_3zvPn+pqOnJkubRTEDo9Xg@mail.gmail.com>
References: <CA+og5up=UG2wD_brvCXK9xRBeUVT_YjkR5MHKs+Z+FGPJLY40w@mail.gmail.com>
 <CADrxXXknXjv7NToKMPgpNoc__Sq_3zvPn+pqOnJkubRTEDo9Xg@mail.gmail.com>
Message-ID: <CA+og5up=xRSf89BJkqJCL4B3R7pTULepW+YGdQn0k1GFLKB0Wg@mail.gmail.com>

I gave it a different subject line.

On Fri, Jun 1, 2018 at 2:45 AM, Abdur-Rahmaan Janhangeer <
arj.python at gmail.com> wrote:

> as this sig file is a common occurance, attaching the topic to the data
> blocks thread is not really necessary
>
> Abdur-Rahmaan Janhangeer
> https://github.com/Abdur-rahmaanJ
>
> On Fri, 1 Jun 2018, 01:49 Paul, <tallpaul at gmail.com> wrote:
>
>> I have heard that attachments to messages are not allowed on this list,
>> which makes sense. However I notice that messages from Peter do have an
>> attachment, i.e., a signature.asc file.
>>
>> I'm just curious; why and how do those particular attachments get through?
>> And should they get through, I guess? E.G., what if I attach a malicious
>> file labeled as .asc?
>>
>> [Peter, I am not suggesting anything about you!  ;). ]
>>
>> Paul C.
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>


From arj.python at gmail.com  Thu May 31 23:35:57 2018
From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer)
Date: Fri, 1 Jun 2018 07:35:57 +0400
Subject: Python library to break text into words
In-Reply-To: <24d4f9c6-69b4-ce57-0c66-b8806b9269ae@schwertberger.de>
References: <086f13d1-018a-4433-967f-881e95410b2a@googlegroups.com>
 <24d4f9c6-69b4-ce57-0c66-b8806b9269ae@schwertberger.de>
Message-ID: <CADrxXXk-42d5okvmr=P3+iaTGUc12q8x1wddArrer2M_ghh2kQ@mail.gmail.com>

Dietmar's answer is the best, piggybacking on search engines' algorithms

and probably instead of a dictionary of english words, we'd need a
dictionary of titles, making search much more efficient

regards,

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

No need to re-invent the wheel:
>
> import webbrowswer
> webbrowser.open(
> "https://www.google.com/search?q=%s"%"atomicaccidents.pdf"+"+amazon",
> new=0)
>
> Copy the title from the browser window and paste it into your script's
> window which will read it with input() and rename the file.
>
> Regards,
>
> Dietmar
>


From ralf at schoenian-online.de  Thu May 31 23:47:34 2018
From: ralf at schoenian-online.de (Ralf Schoenian)
Date: Fri, 1 Jun 2018 05:47:34 +0200
Subject: version
In-Reply-To: <20180601024435.GA32258@playground>
References: <mailman.30.1527436804.26438.python-list@python.org>
 <20180601024435.GA32258@playground>
Message-ID: <398fede2-8241-704c-e492-06165e1ede65@schoenian-online.de>

Hi Mike,

you can check for the major version with

import sys
sys.version_info.major


On 01.06.2018 04:44, Mike McClain wrote:
>      OK so I installed python 3.2, which is the latest available as a
> package in Debian Wheezy, because I've seen so many folks say it's a
> waste of time to play with Py2.7.
>      Immediately my python playground 'my.python.py' failed as soon as
> I changes the '#!' line to python3.2.
>      Most of the errors were because I had used 'print' without parens
> which 2.7 liked but 3.2 doesn't.
> Is there a way in a script to know which version of python is being
> run so I can write:
>      If (version == 2.7):
>          do it this way
>      elsif (version == 3.2):
>          do it another way
>
> Thanks,
> Mike
> --
> I Don't care how little your country is, you got a right to run it like
> you want to. When big nations quit meddling then the world will have peace.
>      - Will Rogers