Re: [Python-ideas] Re: Magnitude and ProtoMagnitude ABCs — primarily for argument validation

[Marco Sulla via Python-list]

On Tue, 10 Mar 2020 at 13:41, Chris Angelico  wrote:
> It makes good sense for
> division by 0 and division by 0.0 to both result in the same
> exception.

But Python 3 returns a float, for example, in division between
integers. 4 / 2 == 2.0. So some_integer / +0 should return +Infinity.
This is what IEEE 754 says.
Luckily Python does not adhere completely to IEEE 754.

Furthermore, there's a precedence in Python: decimal. decimal.Decimal
does not returns NaN in any of the operations that should return it:
https://en.wikipedia.org/wiki/NaN#Operations_generating_NaN
On the contrary, it returns decimal.InvalidOperation.

@Alan Bawden: thank you for letting me know about William Kahan. I
think it's analysis of IEEE 754 is very detailed, and I didn't know
that traps exist.
And yes, I agree that traps and exceptions slows down the computation.
But in a language like Python, when simplicity and usability is a
priority, and when "no exception should pass silently", IMHO
operations that returns NaN are only an heritage from C, since Python
is written in C.

PS: I'm quoting import this with Tim Peters in the discussion, to Alan
Bawden... It's like teaching physics to Fermi.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Installation of python

[Marco Sulla via Python-list]

*Ahem* I already posted the solution to your problem. I quote myself:

I suppose you also downloaded the required sources from here:
https://data.mendeley.com/datasets/s2x4d542dc/1

It seems the problem is that the above sources are generated by an old
version of Cython:

https://github.com/mcfletch/pyopengl/issues/11

You have "simply" to enter any subdir of PoissonSolver that ends with
"_cy" and remove the .c file inside them.

After that, you'll be able to compile. The result is three ELF files. On
my PC, for example, one of the the generated shared libraries is

PoissonSolver/PoissonSolver/ps3d.cpython-38-x86_64-linux-gnu.so

You have also to rename them. Follow the README.



On Mon, 9 Mar 2020 at 15:23, Tim Ko  wrote:
>
> Hello,
>
> I am trying to install a custom Python package but ran into an error. The 
> error presumably associated with cython. I tried a different compiler since 
> Intel compiler often crashes when using cython, but couldn't get it working.
>
> Attached is the installation error log. I have installed and updated all 
> essential packages such as numpy and scipy. Could someone please give me 
> advice to resolve this issue? Many thanks in advance.
>
> Sincerely,
> TK
>
>
> ===
> $ python setup.py build_ext -b PoissonSolver/
> running build_ext
> skipping 'PoissonSolver/MV_2D_cy/matvec2D.c' Cython extension (up-to-date)
> skipping 'PoissonSolver/MV_1D_cy/matvec1D.c' Cython extension (up-to-date)
> skipping 'PoissonSolver/PS_3D_cy/ps3d.c' Cython extension (up-to-date)
> building 'matvec2D' extension
> icc -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC 
> -I/home01/r782a03/.conda/envs/hko_env/lib/python3.7/site-packages/numpy/core/include
>  -I/home01/r782a03/.conda/envs/hko_env/include/python3.7m -c 
> PoissonSolver/MV_2D_cy/matvec2D.c -o 
> build/temp.linux-x86_64-3.7/PoissonSolver/MV_2D_cy/matvec2D.o -ffast-math
> icc: command line warning #10006: ignoring unknown option '-ffast-math'
> In file included from 
> /home01/r782a03/.conda/envs/hko_env/lib/python3.7/site-packages/numpy/core/include/numpy/ndarraytypes.h(1830),
>  from 
> /home01/r782a03/.conda/envs/hko_env/lib/python3.7/site-packages/numpy/core/include/numpy/ndarrayobject.h(12),
>  from 
> /home01/r782a03/.conda/envs/hko_env/lib/python3.7/site-packages/numpy/core/include/numpy/arrayobject.h(4),
>  from PoissonSolver/MV_2D_cy/matvec2D.c(232):
> /home01/r782a03/.conda/envs/hko_env/lib/python3.7/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h(17):
>  warning #1224: #warning directive: "Using deprecated NumPy API, disable it 
> with "  "#define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION"
>   #warning "Using deprecated NumPy API, disable it with " \
>^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17500): error: struct "_ts" has no field 
> "exc_type"
>   *type = tstate->exc_type;
>   ^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17501): error: struct "_ts" has no field 
> "exc_value"
>   *value = tstate->exc_value;
>^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17502): error: struct "_ts" has no field 
> "exc_traceback"
>   *tb = tstate->exc_traceback;
> ^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17514): error: struct "_ts" has no field 
> "exc_type"
>   tmp_type = tstate->exc_type;
>  ^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17515): error: struct "_ts" has no field 
> "exc_value"
>   tmp_value = tstate->exc_value;
>   ^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17516): error: struct "_ts" has no field 
> "exc_traceback"
>   tmp_tb = tstate->exc_traceback;
>^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17517): error: struct "_ts" has no field 
> "exc_type"
>   tstate->exc_type = type;
>   ^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17518): error: struct "_ts" has no field 
> "exc_value"
>   tstate->exc_value = value;
>   ^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17519): error: struct "_ts" has no field 
> "exc_traceback"
>   tstate->exc_traceback = tb;
>   ^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17562): error: struct "_ts" has no field 
> "exc_type"
>   tmp_type = tstate->exc_type;
>  ^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17563): error: struct "_ts" has no field 
> "exc_value"
>   tmp_value = tstate->exc_value;
>   ^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17564): error: struct "_ts" has no field 
> "exc_traceback"
>   tmp_tb = tstate->exc_traceback;
>^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17565): error: struct "_ts" has no field 
> "exc_type"
>   tstate->exc_type = local_type;
>   ^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17566): error: struct "_ts" has no field 
> "exc_value"
>   tstate->exc_value = local_value;
>   ^
>
> PoissonSol

Re: Error while installing a python code

[Marco Sulla via Python-list]

Little errata: you have only to install or update Cython, remove the
.c files as I wrote before and run again

python setup.py build_ext -b PoissonSolver/

No intermediate steps are required. The generated ELF files are three.
You have also to rename them with the names in the README file.


On Mon, 9 Mar 2020 at 22:36, Marco Sulla  wrote:
>
> I suppose you tried to use this setup.py:
> https://github.com/breathe/coffee_conda_package/blob/master/0001-Add-alternative-setup.py-script.patch
>
> It's not well written IMHO... anyway this is not the problem.
>
> I suppose you also downloaded the required sources from here:
> https://data.mendeley.com/datasets/s2x4d542dc/1
>
> It seems the problem is that the above sources are generated by an old
> version of Cython:
>
> https://github.com/mcfletch/pyopengl/issues/11
>
> You have "simply" to enter any subdir of PoissonSolver that ends with
> "_cy", remove the .c file inside and do:
> python setup.py build_ext --inplace
>
> After that, you'll be able to compile. The result is an ELF file. On
> my PC, the generated file is
> PoissonSolver/PoissonSolver/ps3d.cpython-38-x86_64-linux-gnu.so
>
> On Mon, 9 Mar 2020 at 15:27, Tim Ko  wrote:
> >
> > Hello,
> >
> > I am trying to install a custom Python code but ran into an error. The 
> > error presumably associated with cython. I tried a different compiler since 
> > Intel compiler often crashes when using cython, but couldn't get it working.
> >
> > Attached is the installation error log. I have installed and updated all 
> > essential packages such as numpy and scipy. Could someone please give me 
> > advice to resolve this issue? Many thanks in advance.
> >
> > Sincerely,
> > TK
> >
> >
> > ===
> > $ python setup.py build_ext -b PoissonSolver/
> > running build_ext
> > skipping 'PoissonSolver/MV_2D_cy/matvec2D.c' Cython extension (up-to-date)
> > skipping 'PoissonSolver/MV_1D_cy/matvec1D.c' Cython extension (up-to-date)
> > skipping 'PoissonSolver/PS_3D_cy/ps3d.c' Cython extension (up-to-date)
> > building 'matvec2D' extension
> > icc -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC 
> > -I/home01/r782a03/.conda/envs/hko_env/lib/python3.7/site-packages/numpy/core/include
> >  -I/home01/r782a03/.conda/envs/hko_env/include/python3.7m -c 
> > PoissonSolver/MV_2D_cy/matvec2D.c -o 
> > build/temp.linux-x86_64-3.7/PoissonSolver/MV_2D_cy/matvec2D.o -ffast-math
> > icc: command line warning #10006: ignoring unknown option '-ffast-math'
> > In file included from 
> > /home01/r782a03/.conda/envs/hko_env/lib/python3.7/site-packages/numpy/core/include/numpy/ndarraytypes.h(1830),
> >  from 
> > /home01/r782a03/.conda/envs/hko_env/lib/python3.7/site-packages/numpy/core/include/numpy/ndarrayobject.h(12),
> >  from 
> > /home01/r782a03/.conda/envs/hko_env/lib/python3.7/site-packages/numpy/core/include/numpy/arrayobject.h(4),
> >  from PoissonSolver/MV_2D_cy/matvec2D.c(232):
> > /home01/r782a03/.conda/envs/hko_env/lib/python3.7/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h(17):
> >  warning #1224: #warning directive: "Using deprecated NumPy API, disable it 
> > with "  "#define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION"
> >   #warning "Using deprecated NumPy API, disable it with " \
> >^
> >
> > PoissonSolver/MV_2D_cy/matvec2D.c(17500): error: struct "_ts" has no field 
> > "exc_type"
> >   *type = tstate->exc_type;
> >   ^
> >
> > PoissonSolver/MV_2D_cy/matvec2D.c(17501): error: struct "_ts" has no field 
> > "exc_value"
> >   *value = tstate->exc_value;
> >^
> >
> > PoissonSolver/MV_2D_cy/matvec2D.c(17502): error: struct "_ts" has no field 
> > "exc_traceback"
> >   *tb = tstate->exc_traceback;
> > ^
> >
> > PoissonSolver/MV_2D_cy/matvec2D.c(17514): error: struct "_ts" has no field 
> > "exc_type"
> >   tmp_type = tstate->exc_type;
> >  ^
> >
> > PoissonSolver/MV_2D_cy/matvec2D.c(17515): error: struct "_ts" has no field 
> > "exc_value"
> >   tmp_value = tstate->exc_value;
> >   ^
> >
> > PoissonSolver/MV_2D_cy/matvec2D.c(17516): error: struct "_ts" has no field 
> > "exc_traceback"
> >   tmp_tb = tstate->exc_traceback;
> >^
> >
> > PoissonSolver/MV_2D_cy/matvec2D.c(17517): error: struct "_ts" has no field 
> > "exc_type"
> >   tstate->exc_type = type;
> >   ^
> >
> > PoissonSolver/MV_2D_cy/matvec2D.c(17518): error: struct "_ts" has no field 
> > "exc_value"
> >   tstate->exc_value = value;
> >   ^
> >
> > PoissonSolver/MV_2D_cy/matvec2D.c(17519): error: struct "_ts" has no field 
> > "exc_traceback"
> >   tstate->exc_traceback = tb;
> >   ^
> >
> > PoissonSolver/MV_2D_cy/matvec2D.c(17562): error: struct "_ts" has no field 
> > "exc_type"
> >   tmp_type = tstate->exc_type;
> >  ^
> >
> >

Re: Python question

[Marco Sulla via Python-list]

On Fri, 6 Mar 2020 at 17:30, Souvik Dutta  wrote:
> And you cannot form opinions for
> other people's by saying them not to support a person. That is injustice
> and rude.

I would reply, but I was already too much off topic. I want only to
write what Gmail reports to me about the last message of the person
that started this discussion:

> This message seems dangerous
> Many people marked similar messages as phishing scams, so this might contain 
> unsafe content. Avoid clicking links, downloading attachments or replying 
> with personal information.

I never saw this message before in Gmail. Didn't your Gmail warned
about this, Souvik Dutta?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pip UX Studies - help improve the usability of pip

[Marco Sulla via Python-list]

On Mon, 9 Mar 2020 at 16:09, Paul Moore  wrote:
> We've had some questions as to whether this survey is legitimate. I
> can confirm it is (speaking as a pip core developer).

Thank you a lot!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Python-ideas] Re: New explicit methods to trim strings

[Marco Sulla via Python-list]

I agree with Steven D'Aprano.
I never had problems with strip(), but if people find it confusing,
Python can simply leave strip() and all the other function as they are
and add another functions, like crop() or snip() or shear() prune() or
mow(). Personally I prefer crop() or prune().

This way there will be no breaking changes.

On Sat, 7 Mar 2020 at 02:58, Ethan Furman  wrote:
>
> On 03/06/2020 04:03 PM, Steven D'Aprano wrote:
> > On Thu, Mar 05, 2020 at 12:45:28PM -0800, Andrew Barnert via Python-ideas 
> > wrote:
>
> >> Well, I like the idea if someone can come up with a good naming
> >> scheme—something that at least reminds me which function is the “set
> >> of chars” stripper and which the “substring” stripper,
> >
> > You've been a Python programmer for how many years now? Do you currently
> > have trouble remembering what lstrip and rstrip do?
>
> Speaking for myself, about 13 years.  And, yes, I do occasionally forget that 
> the strips are character based.  I can easily imagine it's worse for polyglot 
> programmers.
>
>
> > We already have `[l|r]strip` methods. If we want to associate the new
> > methods with those, I suggest
> >
> >  strip_prefix
> >  strip_suffix
>
> Works for me.  Easy to add to bytes, too, if somebody is so inclined.
>
> --
> ~Ethan~
> ___
> Python-ideas mailing list -- python-id...@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-id...@python.org/message/JKBILM3G2C4TQ7XEVIH3V7M7CKCJ4R6Y/
> Code of Conduct: http://python.org/psf/codeofconduct/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Python-ideas] Re: Magnitude and ProtoMagnitude ABCs — primarily for argument validation

[Marco Sulla via Python-list]

I think that implementing TotallyOrderable and PartiallyOrderable is a
good idea. But is it useful?
I mean, I don't know how much people needs really to order sets. Maybe
some mathematician. But they can simply use Sage:
http://doc.sagemath.org/html/en/reference/categories/sage/categories/posets.html

The real problem is NaN. If NaN would not exists, floats will be
perfectly total orderable.
Yes, IEEE 754-2019 defines a total order: -NaN is a number minor that
-Infinity, and +NaN is a number greater than +Infinity. And a NaN is
greater than another NaN if its payload is greater.

But IEEE 754 says also that the division by +0 should return
+Infinity, and by -0 -Infinity.

On the contrary, Python decided to not adhere to IEEE 754 in this case
and do a very wise choice: raise an exception.

The question is: why Python does not do the same for operations that
now return NaN?

Raising a NanError seems to me the only way to eliminate the NaN
problem. Indeed NaN was created for languages like C, that does not
support exceptions.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Error while installing a python code

[Marco Sulla via Python-list]

I suppose you tried to use this setup.py:
https://github.com/breathe/coffee_conda_package/blob/master/0001-Add-alternative-setup.py-script.patch

It's not well written IMHO... anyway this is not the problem.

I suppose you also downloaded the required sources from here:
https://data.mendeley.com/datasets/s2x4d542dc/1

It seems the problem is that the above sources are generated by an old
version of Cython:

https://github.com/mcfletch/pyopengl/issues/11

You have "simply" to enter any subdir of PoissonSolver that ends with
"_cy", remove the .c file inside and do:
python setup.py build_ext --inplace

After that, you'll be able to compile. The result is an ELF file. On
my PC, the generated file is
PoissonSolver/PoissonSolver/ps3d.cpython-38-x86_64-linux-gnu.so

On Mon, 9 Mar 2020 at 15:27, Tim Ko  wrote:
>
> Hello,
>
> I am trying to install a custom Python code but ran into an error. The error 
> presumably associated with cython. I tried a different compiler since Intel 
> compiler often crashes when using cython, but couldn't get it working.
>
> Attached is the installation error log. I have installed and updated all 
> essential packages such as numpy and scipy. Could someone please give me 
> advice to resolve this issue? Many thanks in advance.
>
> Sincerely,
> TK
>
>
> ===
> $ python setup.py build_ext -b PoissonSolver/
> running build_ext
> skipping 'PoissonSolver/MV_2D_cy/matvec2D.c' Cython extension (up-to-date)
> skipping 'PoissonSolver/MV_1D_cy/matvec1D.c' Cython extension (up-to-date)
> skipping 'PoissonSolver/PS_3D_cy/ps3d.c' Cython extension (up-to-date)
> building 'matvec2D' extension
> icc -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC 
> -I/home01/r782a03/.conda/envs/hko_env/lib/python3.7/site-packages/numpy/core/include
>  -I/home01/r782a03/.conda/envs/hko_env/include/python3.7m -c 
> PoissonSolver/MV_2D_cy/matvec2D.c -o 
> build/temp.linux-x86_64-3.7/PoissonSolver/MV_2D_cy/matvec2D.o -ffast-math
> icc: command line warning #10006: ignoring unknown option '-ffast-math'
> In file included from 
> /home01/r782a03/.conda/envs/hko_env/lib/python3.7/site-packages/numpy/core/include/numpy/ndarraytypes.h(1830),
>  from 
> /home01/r782a03/.conda/envs/hko_env/lib/python3.7/site-packages/numpy/core/include/numpy/ndarrayobject.h(12),
>  from 
> /home01/r782a03/.conda/envs/hko_env/lib/python3.7/site-packages/numpy/core/include/numpy/arrayobject.h(4),
>  from PoissonSolver/MV_2D_cy/matvec2D.c(232):
> /home01/r782a03/.conda/envs/hko_env/lib/python3.7/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h(17):
>  warning #1224: #warning directive: "Using deprecated NumPy API, disable it 
> with "  "#define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION"
>   #warning "Using deprecated NumPy API, disable it with " \
>^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17500): error: struct "_ts" has no field 
> "exc_type"
>   *type = tstate->exc_type;
>   ^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17501): error: struct "_ts" has no field 
> "exc_value"
>   *value = tstate->exc_value;
>^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17502): error: struct "_ts" has no field 
> "exc_traceback"
>   *tb = tstate->exc_traceback;
> ^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17514): error: struct "_ts" has no field 
> "exc_type"
>   tmp_type = tstate->exc_type;
>  ^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17515): error: struct "_ts" has no field 
> "exc_value"
>   tmp_value = tstate->exc_value;
>   ^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17516): error: struct "_ts" has no field 
> "exc_traceback"
>   tmp_tb = tstate->exc_traceback;
>^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17517): error: struct "_ts" has no field 
> "exc_type"
>   tstate->exc_type = type;
>   ^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17518): error: struct "_ts" has no field 
> "exc_value"
>   tstate->exc_value = value;
>   ^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17519): error: struct "_ts" has no field 
> "exc_traceback"
>   tstate->exc_traceback = tb;
>   ^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17562): error: struct "_ts" has no field 
> "exc_type"
>   tmp_type = tstate->exc_type;
>  ^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17563): error: struct "_ts" has no field 
> "exc_value"
>   tmp_value = tstate->exc_value;
>   ^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17564): error: struct "_ts" has no field 
> "exc_traceback"
>   tmp_tb = tstate->exc_traceback;
>^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17565): error: struct "_ts" has no field 
> "exc_type"
>   tstate->exc_type = local_type;
>   ^
>
> PoissonSolver/MV_2D_cy/matvec2D.c(17566): error: struct "_ts" has no field 
> "exc_val

Re: pip UX Studies - help improve the usability of pip

[Marco Sulla via Python-list]

There's someone of the pip team that can confirm this?

On Sat, 7 Mar 2020 at 02:49, Bernard Tyers - Sane UX Design
 wrote:
>
> Hi there,
>
> My name is Bernard Tyers. I'm a UX designer and have recently started
> working on the PSF project to improve the usability of pip, funded by
> MOSS/CZI.
>
> I want to let you know about the pip UX Studies we've started today, and
> encourage you to sign-up and take part.
>
> The pip Team is looking for Python users who use pip to take part in our
> UX Studies. Your input will have a direct impact on improving pip.
>
> We want to speak with as diverse a group as possible. We'd particularly
> like to speak with people with accessibility needs.
>
> You _don't_ have to be a Python expert to take part - I can't stress
> this enough!
>
> You can find out all the details you'll need and find the sign-up link
> on this blogpost:
>
> http://www.ei8fdb.org/thoughts/2020/03/pip-ux-study-recruitment/
>
> If you do have questions I've not answered there, let me know.
>
> We'd also appreciate some signal boosting to reach as wide an audience
> as possible. Please share the blog post with people in different Python
> using communities.
>
> If you're a Twitter/Mastodon user we'd appreciate a signal boost of
> these also:
>
> https://twitter.com/bernardtyers/status/123603961730017
> https://social.ei8fdb.org/@bernard/103778645553767728
>
>
> Thank you for your attention!
>
> Best wishes,
>
> Bernard
> --
>
> Bernard Tyers, User research & Interaction Design
>
> T: @bernardtyers
> M: @bern...@social.ei8fdb.org
> PGP Key: keybase.io/ei8fdb
>
>
> I work on User-Centred Design, Open Source Software and Privacy.
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pip UX Studies - help improve the usability of pip

[Marco Sulla via Python-list]

Subscribed. I have a little suggestion IMHO "What is you favourite
pip command or functionality?" is not very useful... of course the
most useful command is "install" :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Help building python application from source

[Marco Sulla via Python-list]

Mh. I hoped not, but unluckily I expected a response like this.

People of Python List, I strongly discourage you to support this user.
He is quite suspicious for the following reasons:

1. he go so far as he offers money for, IMHO, a trivial task
2. he does not trust binaries from pip. He is so careful that he wants
to freeze the libraries he will use and he want to compile them, so he
can see the code and be sure that the binary was generated by that
code. A lack of trust in open source projects that is quite unusual
3. I don't trust any cryptocurrency.

I believe in privacy,  but not in financial privacy. Yes,
cryptocurrencies can be useful for circumvent bans from tyrannic
states. But they can, and _are_ used, primarily to:
 - wash dirty money, by criminals and mafias
 - evade taxes
 - buy highly unethical "products", like weapons... and who know what other
 - finance tyrannies.

I do _not_ think that all people that uses cryptocurrencies are
criminals. I had, for example, some co-workers that invested in
BitCoins, only for profit.

But I do not trust this man, and I hope no one will offer support to
him. By my side, I'll report this discussion to moderators.


On Tue, 3 Mar 2020 at 04:24, Mr. Lee Chiffre  wrote:
>
>
> > I think I have the solution, but can I ask you why are you creating a
> > bitcoin server?
> >
> Yes. I am a crypto anarchist. I have a bitcoin node to do my part to
> running the bitcoin network and help remain it decentralized and
> resilient. The more people that run a node the better it is. When it comes
> to hosting servers I believe I am able to do so in a highly secure manner.
> So I am doing my part in secure the bitcoin network and documenting what I
> do to help others do the same thing.
>
> I support the bitcoin project because it is a liberty enhancing technology
> to counter act over reaching government and expanding tyranny. People have
> a right to financial privacy. And the world needs a secure financial
> network to replace the existing institutional one that suffers from fraud
> and theft.In a cyber dystopian world we live in there is a war on cash
> and privacy to push us into a digital monetary system where governments
> are able to spy on and control everything and everyone. If there is a need
> for digital money let it be one that supports liberty instead of weakening
> it. It is vital that cypher tech outpaces the police state. What we do
> determines the future. We can let ourselves be enslaved and passive. Or we
> can be active and support the solutions that create a better world and
> preserve what is good.
>
> Right now it is a full node and not used for any other services or
> purposes. If possible I would like to add electrumx so users of the
> electrum wallet can use my server. Electrum is a very popular wallet and
> is what comes pre installed with TAILS.
>
> --
> lee.chif...@secmail.pro
> PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35
>
-- 
https://mail.python.org/mailman/listinfo/python-list

`async def` breaks encapsulation?

[Marco Sulla via Python-list]

I worked a lot with `asyncio` many years ago, when `aiohttp` was first
born. Now I'm working again with it, since a library that I need
requires it.

asyncio is much more simple to use now, but there's something that
still make me doubtful: the require of the `async` keyword for
coroutines.

When I developed the aiohttp app, many times I changed my mind and an
async function turned back to be a normal one. But in the meanwhile
I'd used it for a bunch of coroutines, that I used for a bunch of
coroutines etc... so I had to check all the affected coroutines and
remove the `async` keyword from them.

This recall me checked exceptions in Java. If you add to a Java method
messTheCode() a `throws SomeException`, and subsequently you refactor
the code so the exception is no more raised, you have to remove the
`throws SomeException` from the function signature and to all the
functions that used `messTheCode()` that decided to not handle the
exception.

(This is why I do not use checked exceptions in Java... I wrap them in
unchecked ones. Yes, I'm an heretical :-D)

The fact that puzzles me is that no additional keyword for coroutines
was needed. A coroutines was simply a function with a `yield`. If it
quacks...

Why can't an asynchronous coroutine be simply a coroutine that has an
`async` or an `await` in its code, without `async` in the signature?
-- 
https://mail.python.org/mailman/listinfo/python-list

Why there's no __json__()?

[Marco Sulla via Python-list]

As title. For example, `copy.copy` can use the __copy__() method of a
class, if defined.

Is this not possible with `json`?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why this message was rejected?

[Marco Sulla via Python-list]

Ok, I sent a message as I did before to the discussion "Re: Friday Finking:
Poly more thick", with only "test" as body.




On Mon, 2 Mar 2020 at 22:48, Marco Sulla  wrote:
>
> On Mon, 2 Mar 2020 at 22:36, Ethan Furman  wrote:
> > Questions like this should go to python-list-owner at python dot org.  If 
> > this message hadn't been flagged we may not have noticed it.
>
> Sorry, I posted to python-list-owner before reading this message.
>
> > When the mailing list software received your post, the python-list address 
> > was not in the To: nor Cc: headers
>
> Well, this is quite strange, since I rechecked my mails and the
> python-list address is in Cc.
> I think the problem was caused by the fact I added the user concerned
> to To:, and the list to Cc. All the rejected messages has this in
> common. Indeed, this message was not rejected because I added only the
> list to the To: field.
>
> > Try the same steps you did before and I'll keep a copy of the message for 
> > further debugging.
>
> As you wish :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why this message was rejected?

[Marco Sulla via Python-list]

On Mon, 2 Mar 2020 at 22:36, Ethan Furman  wrote:
> Questions like this should go to python-list-owner at python dot org.  If 
> this message hadn't been flagged we may not have noticed it.

Sorry, I posted to python-list-owner before reading this message.

> When the mailing list software received your post, the python-list address 
> was not in the To: nor Cc: headers

Well, this is quite strange, since I rechecked my mails and the
python-list address is in Cc.
I think the problem was caused by the fact I added the user concerned
to To:, and the list to Cc. All the rejected messages has this in
common. Indeed, this message was not rejected because I added only the
list to the To: field.

> Try the same steps you did before and I'll keep a copy of the message for 
> further debugging.

As you wish :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Why this message was rejected?

[Marco Sulla via Python-list]

One of my post on this list was rejected. The reason is:

> Blind carbon copies or other implicit destinations are not allowed.
>Try reposting your message by explicitly including the list address in
> the To: or Cc: fields.

I rechecked my mail and I added the user to the To: field, and the
python list address to the Cc field. I don't added any Bcc. I do not
understand why my message was blocked.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Data model and attribute resolution in subclasses

[Marco Sulla via Python-list]

On Fri, 28 Feb 2020 at 08:28, Adam Preble  wrote:
>
> I have been making some progress on my custom interpreter project

Is your project published somewhere? What changes have you done to the
interpreter?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Have you some experience / link about difference between Python builded with gcc and clang?

[Marco Sulla via Python-list]

Oooohhh uff, I have to install latest clang... or better, compile
it as I did for gcc. And I have to read the install docs to see if
there's some trick to optimize it... and I have to read the docs of
pyperformance too (I only used pyperf until now)...

Oh well, tomorrow :-D

On Mon, 2 Mar 2020 at 00:58, Skip Montanaro  wrote:
>>
>> Have you compiled it optimized (--enable-optimizations --with-lto)?
>
>
> Nope, just ./configure. Further investigation is left as an exercise for the 
> reader. :-)
>
> Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Have you some experience / link about difference between Python builded with gcc and clang?

[Marco Sulla via Python-list]

Good! Have you compiled it optimized (--enable-optimizations --with-lto)?

On Sun, 1 Mar 2020 at 23:48, Skip Montanaro  wrote:
>
> > As title. Currently I'm using gcc 9.2.0 and its compilation seems to
> > work well and fast. But I would know by your experience if clang can
> > produce, on a *nix system, a "faster Python".
>
> I took a quick run at this as I was wanting to give pyperformance a try. 
> Comparing GCC 9 with CLANG 8 on my Ubuntu laptop here's what I got. It seems 
> that GCC was a bit faster than CLANG pretty much across the board.
>
> +-+-+---+
> | Benchmark   | gcc | clang |
> +=+=+===+
> | 2to3| 403 ms  | 440 ms: 1.09x slower (+9%)|
> +-+-+---+
> | chameleon   | 12.6 ms | 13.5 ms: 1.07x slower (+7%)   |
> +-+-+---+
> | chaos   | 148 ms  | 169 ms: 1.14x slower (+14%)   |
> +-+-+---+
> | crypto_pyaes| 145 ms  | 157 ms: 1.08x slower (+8%)|
> +-+-+---+
> | deltablue   | 9.79 ms | 11.4 ms: 1.17x slower (+17%)  |
> +-+-+---+
> | django_template | 69.9 ms | 77.6 ms: 1.11x slower (+11%)  |
> +-+-+---+
> | dulwich_log | 89.3 ms | 92.6 ms: 1.04x slower (+4%)   |
> +-+-+---+
> | fannkuch| 590 ms  | 602 ms: 1.02x slower (+2%)|
> +-+-+---+
> | float   | 150 ms  | 160 ms: 1.07x slower (+7%)|
> +-+-+---+
> | genshi_text | 35.9 ms | 39.4 ms: 1.10x slower (+10%)  |
> +-+-+---+
> | genshi_xml  | 74.8 ms | 81.8 ms: 1.09x slower (+9%)   |
> +-+-+---+
> | go  | 339 ms  | 390 ms: 1.15x slower (+15%)   |
> +-+-+---+
> | hexiom  | 12.9 ms | 14.3 ms: 1.11x slower (+11%)  |
> +-+-+---+
> | json_dumps  | 16.4 ms | 17.6 ms: 1.07x slower (+7%)   |
> +-+-+---+
> | json_loads  | 32.9 us | 34.6 us: 1.05x slower (+5%)   |
> +-+-+---+
> | logging_format  | 13.9 us | 15.2 us: 1.09x slower (+9%)   |
> +-+-+---+
> | logging_silent  | 253 ns  | 298 ns: 1.18x slower (+18%)   |
> +-+-+---+
> | logging_simple  | 12.6 us | 14.1 us: 1.12x slower (+12%)  |
> +-+-+---+
> | mako| 21.8 ms | 24.2 ms: 1.11x slower (+11%)  |
> +-+-+---+
> | meteor_contest  | 128 ms  | 133 ms: 1.04x slower (+4%)|
> +-+-+---+
> | nbody   | 181 ms  | 190 ms: 1.05x slower (+5%)|
> +-+-+---+
> | nqueens | 128 ms  | 135 ms: 1.05x slower (+5%)|
> +-+-+---+
> | pathlib | 26.3 ms | 27.1 ms: 1.03x slower (+3%)   |
> +-+-+---+
> | pickle  | 13.3 us | 13.5 us: 1.01x slower (+1%)   |
> +-+-+---+
> | pickle_dict | 33.8 us | 33.6 us: 1.01x faster (-1%)   |
> +-+-+---+
> | pickle_list | 4.82 us | 5.18 us: 1.07x slower (+7%)   |
> +-+-+---+
> | pickle_pure_python  | 613 us  | 725 us: 1.18x slower (+18%)   |
> +-+-+---+
> | pidigits| 210 ms  | 218 ms: 1.04x slower (+4%)|
> +-+-+---+
> | pyflate | 871 ms  | 1.00 sec: 1.15x slower (+15%) |
> +-+-+---+
> | python_startup  | 10.3 ms | 10.4 ms: 1.01

Have you some experience / link about difference between Python builded with gcc and clang?

[Marco Sulla via Python-list]

As title. Currently I'm using gcc 9.2.0 and its compilation seems to
work well and fast. But I would know by your experience if clang can
produce, on a *nix system, a "faster Python".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Most elegant way to do something N times

[Marco Sulla via Python-list]

Anyway, from itertools recipes:

def repeatfunc(func, times=None, *args):
"""Repeat calls to func with specified arguments.

Example:  repeatfunc(random.random)
"""
if times is None:
return starmap(func, repeat(args))
return starmap(func, repeat(args, times))

On Tue, 24 Dec 2019 at 21:41, Marco Sulla  wrote:
>
> On Tue, 24 Dec 2019 at 01:07, Chris Angelico  wrote:
> > On Tue, Dec 24, 2019 at 10:45 AM Marco Sulla <...> wrote:
> > > ??? Excuse me, but why you needed to call the same function SIX times? 
> > > This
> > > seems to me not elegant in primis.
> > >
> > > Can you give us a practical example?
> >
> > File parsing. You read a section header and want to ignore that
> > section, so you ignore the next 15 lines.
>
> mmap and find?
>
>
> On Tue, 24 Dec 2019 at 01:35, DL Neil via Python-list
>  wrote:
> > Taking the top/bottom six from a sorted list of occurrences.
>
> Slicing?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lists And Extra Commas at end

[Marco Sulla via Python-list]

On Wed, 25 Dec 2019 at 00:56, Avi Gross
 wrote:
> I may not be understanding what you are objecting to

I, sir, am objecting that I replied to a topic, and you answered to
me, but in another topic. You could have respond to me in the correct
topic, and then  create this other one (that I'm not really
interested).

Anyway.

About the extra comma, it's da**ed useful:

a = (
42,
1981,
8,
19,
23,
)

If I have to comment out the last line, I can, **without having to
remove the comma before**. And if I have to add another number at the
end, I have not to remember to add the comma before.



The real problem is this one:

a = 1,

Unreadable and prone to subtle errors, because maybe you added the
comma by mistake. Caution: Debugging Nightmares.
The solution, IMHO?

DeprecationWarning, use (1, )

Explicit is better blablabla.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: More efficient/elegant branching

[Marco Sulla via Python-list]

I agree with Chris Angelico, branch1 is "the way to go". Maybe you
have to add a default at start, maybe None, and maybe raise an
exception if
res is None. Anyway, despite I'm a pain in the... arse and I usually
activate ALL the possible warnings in the world, I always disable
cyclomatic complexity warnings in all linters, in any language :D

# Off topic - START

I proposed a switch-case some years ago. I was brutally condemned like
an heretic :D It was something like:

when expr match arg1, arg2, :
[...]
match *args:
[...]
[...]
else: # optional
[...]

expr was evaluated, and checked if equal to one of the arguments. At
the first positive check, the relative code was evaluated, and the
when breaks. No break keyword, like if-elif. If no check passed and an
else clause is present, its code will be evaluated.

Anyway this is not helpful in your case, since you have more
complicated checks. Mine was only a suggestion to introduce the simple
C switch-case in Python, for making easier trivial if-elif chains and
for code optimization (C switch-case is optimized by C compilers)

# Of topic - END
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lists And Missing Commas

[Marco Sulla via Python-list]

On Tue, 24 Dec 2019 at 19:05, Avi Gross via Python-list
 wrote:
> There are some lint programs that check your code and supply warnings and I
> see some languages have the option to generate warnings when the two strings
> are on the same line. I wonder if a Python lint does that. It may at least
> warn of this usage in time to check the code and put back the comma.

IMHO it's not something that should be delegated to linter, but to the
AST compiler itself. A SyntaxWarning should be displayed.

One time I spent HOURS because I forgot one single comma in a list of
strings. After that, my life is changed. I'm no more an ingenuous,
little boy, that trusted the stacktrace.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lists And Extra Commas at end

[Marco Sulla via Python-list]

On Tue, 24 Dec 2019 at 22:51, Avi Gross via Python-list
 wrote:
> So, is that a feature you want warnings about? After all, a dangling comma 
> may simply mean you left something out and meant to add later?

.completely OT. I responded to a topic named "List and missing
commas", and suggested a warning for implicit concatenation between
adjacent strings. I don't really know why you renamed it "Lists And
Extra Commas at end". Have you read the thread and my post?

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

Re: Most elegant way to do something N times

[Marco Sulla via Python-list]

On Tue, 24 Dec 2019 at 01:07, Chris Angelico  wrote:
> On Tue, Dec 24, 2019 at 10:45 AM Marco Sulla <...> wrote:
> > ??? Excuse me, but why you needed to call the same function SIX times? This
> > seems to me not elegant in primis.
> >
> > Can you give us a practical example?
>
> File parsing. You read a section header and want to ignore that
> section, so you ignore the next 15 lines.

mmap and find?


On Tue, 24 Dec 2019 at 01:35, DL Neil via Python-list
 wrote:
> Taking the top/bottom six from a sorted list of occurrences.

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

Re: Why Python has no equivalent of JDBC of Java?

[Marco Sulla via Python-list]

On Tue, 21 May 2019 at 01:20, Michael Torrie  wrote:

> On 05/20/2019 04:23 PM, Andrew Z wrote:
> I assume
>

Nope, it requires the instantclient and, on Linux only, also the
installclient-devel package. And a bunch of obscure and terrible settings,
like LD_LIBRARY_PATH...

On Tue, 21 May 2019 at 03:42, Chris Angelico  wrote:

> From the sound of
> things, the choice of database back end has already been made, and the
> Python script just has to cope. Otherwise, PostgreSQL would be an
> entirely better alternative.
>

Yes it's that the problem.
Well I love Postgres, but IMHO the big disadvantages over Oracle are two:
BLOBs and performance.

On Tue, 21 May 2019 at 15:14, Paul Moore  wrote:

> Because a commercial product like Oracle doesn't document
> those protocols, open-source reimplementations are hard, if not
> impossible.
>

IMHO this is the more logical answer to my doubts.

On Tue, 21 May 2019 at 18:17, Dennis Lee Bieber 
wrote:

> It wouldn't surprise me to find that they include the JDBC
> driver layer for Oracle database in the Java package}


It would surprise _me_. Oracle did not even uploaded ojdbc to the maven
repository...

On Sun, 26 May 2019 at 15:37, Bischoop  wrote:

> On 2019-05-19, Marco Sulla  wrote:
> >blablabla
> >blablablalbla
> >blablalblalbalblabla
>
> There's no perfect language mate, in some one is easier in other not,
> normal surprised you notice it so late.


I discovered it two years and an half ago, when I started to program in
Java too. Sorry if I didn't had the time to post but I'm working. And sorry
again, I don't know the whole basics of every programming language in the
world. I only programmed in Python 2 and 3, Cython, C, C++, Fortran, Qt,
PHP, Visual Basic .NET, LabView and  Javascript.


On Sun, 26 May 2019 at 19:53, Christian Gollwitzer  wrote:

> Python closer to the metal than Java? This is nonsense.
>

Well, it seems to me the majority of python db drivers uses Cython, Python
C API or external C libraries. So in this particular case Python *could* be
more performant than Java. I don't know, you should do some benchmark with
different queries, different in nature, complexity and number of rows
retrieved, on the same db, accessed once with Java and once with Python.
The problem is benchmarking Java not so easy as Python. It's very boring.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python has no equivalent of JDBC of Java?

[Marco Sulla via Python-list]

On Mon, 20 May 2019 at 17:32, Thomas Jollans  wrote:

> Python has a the "Python Database API" (DB API 2.0)
> https://www.python.org/dev/peps/pep-0249/
>

So why Oracle need instantclient for using cx_Oracle? They say they use
DB-API:

> *cx_Oracle* is a Python extension module that enables access to Oracle
> Database. It conforms to the Python database API 2.0 specification
 with
> a considerable number of additions and a couple of exclusions.

https://oracle.github.io/python-cx_Oracle/


On Sun, 19 May 2019 at 23:47, Chris Angelico  wrote:

> I've no idea what the hassles are with Oracle, as it's a database
> engine that I don't use. But with PostgreSQL, which I *do* use, I can
> assure you that it's much easier
>

I use Postgres if I can choose, but companies uses Oracle unluckily. Oracle
and MSSQL. And I must say that surprisingly, being a Microsoft product, I
find MSSQL more simple to install than Oracle, like Postregres, and has an
easier SQL syntax.  Like Postgres.
-- 
https://mail.python.org/mailman/listinfo/python-list

Why Python has no equivalent of JDBC of Java?

[Marco Sulla via Python-list]

I programmed in Python 2 and 3 for many years, and I find it a fantastic
language.

Now I'm programming in Java by m ore than 2 years, and even if I found its
code much more boilerplate, I admit that JDBC is fantastic.

One example over all: Oracle. If you want to access an Oracle DB from
Python, you have to:

1. download the Oracle instantclient and install/unzip it
2. on Linux, you have also to install/unzip Development and Runtime package
3. on windows, you have to add the instantclient to PATH
4. on Linux, you have to create a script to source that sets PATH,
ORACLE_HOME and LD_LIBRARY_PATH

Finally, you can use cx_Oracle.

Java? You have only to download ojdbcN.jar and add it to Maven/Gradle.

Why Python has no equivalent to JDBC?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python slang

[Marco Sulla via Python-list]

On 6 August 2016 at 03:35, Chris Angelico  wrote:
> On Sat, Aug 6, 2016 at 11:14 AM, Steven D'Aprano
>  wrote:
>>> I don't ask about `None` instead of `null` because I suppose here it's
>>> a matter of disambiguation (null, in many languages, is not equal to
>>> null).
>>
>> Really? Which languages? That's not true in Pascal, C, Ruby or Javascript.
>>
>
> SQL (shown here with PostgreSQL's CLI):
>
> rosuav=> \pset null NULL
> Null display is "NULL".
> rosuav=> select NULL = NULL;
>  ?column?
> --
>  NULL
> (1 row)
>
> But SQL's NULL is a cross between C's NULL, IEEE's NaN, Cthulhu, and Emrakul.

Yes, I was thinking manly to SQL. That furthermore is NOT a
programming language. So I suppose I have also to ask why "None"
instead of "Null"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python slang

[Marco Sulla via Python-list]

On 6 August 2016 at 03:14, Steven D'Aprano  wrote:
> On Sat, 6 Aug 2016 08:00 am, Marco Sulla wrote:
>> I'm referring to:
>> * `except` instead of `catch`
>
> Because this isn't a game of "catch the ball". They're called "exceptions",
> not "catchions". You *try* something, and if an *exception* happens, the
> except block runs.

So if I try to pick up a girl, I have to knock back the refuse?


>> * `self` instead of `this` (I know, it's not enforced, but it's a de
>> facto standard and some IDEs like PyDev gives you an error if you
>> declare a non-static method without `self` as first parameter)
>
> Because "this" is a stupid name.
>
> In English, we refer to ourselves in the first person as I, me, myself, and
> sometimes "self", never as "this". One can say "this one has a hat", for
> example, but it sounds weird, like something the Borg would say about a
> specific Borg unit.

It's simply a matter of point of view. In the point of view of class,
you are referring to the class itself, so "self" it's a good word.
>From the point of view of the programmer, you're referring to this
class, so "this" is a good word as well. I don't see a semantic
advantage of "self".


>> * `dict` instead of `map`
>
> Because "map" is a piece of paper showing a visual representation of a
> territory, and a dict (dictionary) is a set of words (the keys) followed by
> their definitions (the values).

If map is only a piece of paper, dictionary is only a book, isn't it?
Dictionary is a book, and inside it there's a set of words followed by
their definitions, as you said.
Map is a piece of paper, and every element of the map represent some
other element, in a 1-1 relationship.


>> * `str.strip()` instead of `str.trim()`
>
> Because "trim" is a stupid name for stripping whitespace from the ends of a
> string. When you trim hair or a plant, you unconditionally cut it and make
> it shorter.

Not at all. "trim" word is used when you have to remove something that
is useless, usually. On the contrary, "strip" can be used also in
other means.


>> * `True`, `False` and None instead of `true`, `false` and `none` (they
>> seems classes)
>
> You'd have to ask other languages why they use 'true', 'false' and 'none'
> (they seem like ordinary variables).

I think you find the reason. Not sure it was a good idea (also vim has
syntax highlighting).


>> * and furthermore much abbreviation, like `str` instead of `string`
>> and `len()` instead of `length()`, that seems to contrast with the
>> readability goal of Python.
>
> Just because something is short doesn't make it less readable. According to
> Wolfram Alpha, the average length of words in English is 5.1 characters:
>
> http://www.wolframalpha.com/input/?i=average+english+word+length
>
> but of the ten most common words themselves, nine are of three or fewer
> characters:
>
> "the of to and a in is it you that"

And according to Wolfram Alpha, the readability of Huckleberry Finn is
5.5. I think it doesn't fit in this discussion in the same way :P
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python slang

[Marco Sulla via Python-list]

On 6 August 2016 at 02:13, Chris Angelico  wrote:
> On Sat, Aug 6, 2016 at 9:21 AM, Marco Sulla
>  wrote:
>> I want to clarify that when I say "different from the other
>> languages", I mean "different from the most used languages", that in
>> my mind are C/C++, C#, Java, PHP and Javascript, mainly.
>>
>
> Ah, well, that's because those are all one family of languages. If
> instead you were familiar with four LISPy languages, you'd have a
> completely different set of expectations.

Well, they are the most used languages. I think about the 80% of
programmers knows at least one of that languages. It's more simple to
learn a new language if it's similar to the others.


>> I agree it's not hard to understand that `str` is the string type and
>> `len()` is the function that gives you the length, even if you don't
>> know Python (and it's shorter to type...) But it's hard to remember,
>> in particular if you code also in other languages. When I come back to
>> Python, I always ends to write  `somelist.length` instead of
>> `len(somelist)`, some arcane words come out my mouth and a little
>> fairy dies.
>>
>
> You open your mouth and a fairy dies hmm. Can I offer you a breath mint? 
> :)

Do you have also a plenary indulgence?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python slang

[Marco Sulla via Python-list]

On 6 August 2016 at 20:03, Michael Selik  wrote:
> On Sat, Aug 6, 2016, 10:10 AM Marco Sulla via Python-list
>  wrote:
>>
>> On 6 August 2016 at 00:31, Chris Angelico  wrote:
>> > "map" has many other meanings (most notably the action wherein you
>> > call a function on every member of a collection to produce another
>> > collection).
>>
>> Well, the word `map` of the `map` function is a verb. IMO there would
>> be no ambiguity.
>
>
> Are you thinking of Lisp-2 where functions have a separate namespace from
> everything else?

Nope, I was thinking that "map()" should be a method of an iterable.
But this is another topic :)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python slang

[Marco Sulla via Python-list]

On 6 August 2016 at 00:31, Chris Angelico  wrote:
> On Sat, Aug 6, 2016 at 8:00 AM, Marco Sulla via Python-list
>  wrote:
> This isn't slang; it's jargon

Right.


>> * `raise` instead of `throw`
>
> Quite a few other languages talk about raising exceptions rather than
> throwing them. Those would be the two most common terms, I think.
>
>> * `self` instead of `this` (I know, it's not enforced, but it's a de
>> facto standard and some IDEs like PyDev gives you an error if you
>> declare a non-static method without `self` as first parameter)
>
> Smalltalk and friends also use "self", so again, this would be the
> other common word for the parameter.
>
>> * `str.strip()` instead of `str.trim()`
>
> Another case where both words are in common use.

I want to clarify that when I say "different from the other
languages", I mean "different from the most used languages", that in
my mind are C/C++, C#, Java, PHP and Javascript, mainly.


>> * `dict` instead of `map`
>
> "map" has many other meanings (most notably the action wherein you
> call a function on every member of a collection to produce another
> collection).

Well, the word `map` of the `map` function is a verb. IMO there would
be no ambiguity.


>> * `list.append()` instead of `list.push()`
>
> Better description of what it does, IMO. It's adding something to the
> end of the list - appending to the list.

I agree.


>> * and furthermore much abbreviation, like `str` instead of `string`
>> and `len()` instead of `length()`, that seems to contrast with the
>> readability goal of Python.
>
> Brevity can improve clarity, if it is obtained without the expense of
> accuracy.

I agree it's not hard to understand that `str` is the string type and
`len()` is the function that gives you the length, even if you don't
know Python (and it's shorter to type...) But it's hard to remember,
in particular if you code also in other languages. When I come back to
Python, I always ends to write  `somelist.length` instead of
`len(somelist)`, some arcane words come out my mouth and a little
fairy dies.


> Hope that helps a bit!

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

Python slang

[Marco Sulla via Python-list]

I have a simple curiosity: why Python has much keywords, and some
builtin types and methods, that are different from the other
languages? What is the rationale?

I'm referring to:
* `except` instead of `catch`
* `raise` instead of `throw`
* `self` instead of `this` (I know, it's not enforced, but it's a de
facto standard and some IDEs like PyDev gives you an error if you
declare a non-static method without `self` as first parameter)
* `dict` instead of `map`
* `list.append()` instead of `list.push()`
* `str.strip()` instead of `str.trim()`
* `True`, `False` and None instead of `true`, `false` and `none` (they
seems classes)
* and furthermore much abbreviation, like `str` instead of `string`
and `len()` instead of `length()`, that seems to contrast with the
readability goal of Python.

I don't ask about `None` instead of `null` because I suppose here it's
a matter of disambiguation (null, in many languages, is not equal to
null).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How asyncio works? and event loop vs exceptions

[Marco Sulla via Python-list]

On 23 July 2016 at 16:06, Ian Kelly  wrote:
> On Fri, Jul 22, 2016 at 6:27 PM, Marco S. via Python-list
>  wrote:
>> Furthermore I have a question about exceptions in asyncio. If I
>> understand well how it works, tasks exceptions can be caught only if
>> you wait for task completion, with yield from, await or
>> loop.run_until_complete(future). But in this case the coroutine blocks
>> the execution of the program until it returns. On the contrary you can
>> execute the coroutine inside an asyncio task and it will be
>> non-blocking, but in this case exceptions can't be caught in a try
>> statement.
>
> If you don't want to block the current function on the task, then spin
> off another task to do the error handling.  Instead of this:
>
> async def do_something():
> try:
> await do_something_else()
> except DidNothingError as e:
> handle_error(e)
> ...
>
> Consider this:
>
> async def do_something():
> get_event_loop().create_task(await_and_handle(do_something_else()))
> ...
>
> async def await_and_handle(awaitable):
> try:
> await awaitable
> except DidNothingError as e:
> handle_error(e)

Really good suggestion, thank you.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?

[Marco Sulla via Python-list]

On 24 July 2016 at 14:48, Chris Angelico  wrote:
> Maybe the people who are most worried about this can enact a
> simple rule: no dedent without a blank line? That can easily be
> verified by a script, and it'd protect against most of the given
> examples. It's not too much effort (after any reasonable-sized block
> you'll probably have a blank anyway, so it's only the tiniest of loops
> that would be affected). And no language changes are needed :)

I'm incredibly in favor of such a modification, but maybe this is work
for a linter.

Honestly, I find the "pass" statement very clear and simple. There's
more misleading problems in Python syntax, like this:

someFunction(
"param1"
"param2"  # comma missed, there will be only one parameter "param1param2"
)

and this one too:

class Parent(Base):
__tablename__ = 'parent'
id = Column(Integer, primary_key=True)
children = relationship("Child"),  # comma inserted by error.
children will be a tuple and SQLAlchemy will fail with misleading
errors
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion: make sequence and map interfaces more similar

[Marco Sulla via Python-list]

I want also to add that we are focusing on sequences, but my proposal
is also to make map interface more similar, introducing a vdict type
that iterates over values, and this will be for me really more
practical. PEP 234 (  http://legacy.python.org/dev/peps/pep-0234/ )
never convinced me. Van Rossum said:

> The symmetry between "if x in y" and "for x in y"
> suggests that it should iterate over keys.  This symmetry has been
> observed by many independently and has even been used to "explain"
> one using the other.  This is because for sequences, "if x in y"
> iterates over y comparing the iterated values to x.

This argument will never convinced me. It's a lot more practical (as
Van Rossum admitted further) to iterate over values by default on
maps. Furthermore I see much more symmetry between keys of maps and
indexes of sequences, so it's much more natural to make map iteration
over values by default, as for sequences. This is why I proposed a
vdict.


On 31 March 2016 at 14:30, Mark Lawrence via Python-list
 wrote:
> Note that dict also supports
> __getitem__() and __len__(), but is considered a mapping rather than a
> sequence because the lookups use arbitrary immutable keys rather than
> integers.

Thank you for confirming for what I already wrote and quoted, but I suppose you
missed some of my previous messages, my dear friend.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion: make sequence and map interfaces more similar

[Marco Sulla via Python-list]

On 31 March 2016 at 04:40, Steven D'Aprano  wrote:
> Enough of the hypothetical arguments about what one could do or might do.
> Let's see a concrete example of actual real world code used in production,
> not a mickey-mouse toy program, where it is desirable that adding or
> deleting one key will modify the rest of the keys in the mapping.


1. the example was for confuting your assertion that an implementation
of sequences as extended classes of maps violate the map contract.
2. I already linked a real-world example previously. Google it and you
can find tons of examples like that.


On 31 March 2016 at 04:44, Steven D'Aprano  wrote:
> for a, b in zip(spam, eggs):
> # do some stuff, sometimes assign x[a] or b[a] or who knows what?
>
>
> Does this mean that "lists, dicts and zip" should all support the same
> interface?

I do not understand what you mean with this example. A zip object is
not a sequence nor a map. My definition of sequences as "ordered maps
with integer keys that start from zero and have no gaps" is perfectly
valid as I demonstrated to you, while zip objects have nothing in
common with sequences and maps, apart the fact they are all iterables.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion: make sequence and map interfaces more similar

[Marco Sulla via Python-list]

Let me also add that even if it seems that my idea will not break any
official contracts, I can create a new ABC class and let maps and
sequence types inherit from it. IMHO it's absolutely not needed, but
at least the discussion will be no more distracted my secondary
considerations, since the main topic is about the usefulness and the
advantage to have a base contract for maps and sequences.

PS: I intend to write:
You've demonstrated to be a fair thinker, so do not fall into
temptation to play with
words.
My English is terrible as much as StrangeDict code.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion: make sequence and map interfaces more similar

[Marco Sulla via Python-list]

On 30 March 2016 at 02:55, Terry Reedy  wrote:
> To me [seq.items() and seq.keys()] are useless and confusing duplications 
> since enumerate()(seq)
> and range(len(seq)) are quite different from dict.items and dict.keys.

It's true. Indeed IMHO it's enumerate() that will be a confusing duplication.


On 30 March 2016 at 02:55, Terry Reedy  wrote:
> At least in CPython, changing a dict disables view iterators.

OrderedDict does not.


On 30 March 2016 at 07:43, Steven D'Aprano
 wrote:
> This is not an argument about dicts being mutable, because clearly they
> aren't. This is an argument about key:value pairs being stable.


So you basically say "I expect to get the value x from key y". Let me
apply your point of view to lists. In lists, I expect to get the value
x from index y. If I insert an item in a position before index y, I
expect to get x at index y+1. But what if I write a class with a
method insertPlus() that sets None at y+1 and x at y+2? I can say it
does not violate the list contract, since you're extending the base
class and implementing a new method that is not present in base class.

If you extend a dict to act as a list, you're only adding
*constraints* to existing methods and adding new methods. You're not
completely change the existing ones, so the implementation is
perfectly valid.

Finally, let me quote the official docs:

A mapping object maps hashable values to arbitrary objects [...] A
dictionary’s keys are almost arbitrary values [...]
https://docs.python.org/3/library/stdtypes.html#dict

Mapping:A container object that supports arbitrary key lookups
https://docs.python.org/3/glossary.html#term-mapping

A sequence satisfies all these requirements, with the only exception
that keys are not arbitrary. But no one will tell you that a child
class that make a *restriction* over the original one will break
rules.

On 30 March 2016 at 17:56, Steven D'Aprano  wrote:
> If the OP wants to create his own "StrangeDict", which he himself described
> as "terrible", then he can do so. But to make all dicts and lists behave in
> this "terrible" and "strange" way is a terrible idea.

You did not understand well what I mean, my dear friend. I applied the
word "terrible" to my code, not to the concept. You've demonstrated
that a fair thinker, so do not fall in the temptation to play with
words.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion: make sequence and map interfaces more similar

[Marco Sulla via Python-list]

On 29 March 2016 at 16:31, Chris Angelico  wrote:
> But the definition of a sequence, and likewise the definition of a
> mapping, goes deeper than that. A sequence has *relative* stability;
> if one item is at a lower index than another, it will continue to be
> at a lower index, until you change one of those two items. Changes
> elsewhere in the sequence might bring them closer together or push
> them further apart, but one of them is still earlier in the sequence
> than the other. A mapping, on the other hand, has *absolute*
> stability. Any given key->value relationship is stable in and of
> itself. If you stuff a thing into a dict under a particular key, you
> expect to be able to get it back using that key, not some other.

It's the same arguments of Steven D'Aprano. Let me counter these
arguments with this example:

>>> class StrangeDict(dict):
... def insert(self, k, v):
... if k in self:
... for key in [x for x in sorted(self.keys()) if x >= k]:
... v_next = self[key]
... self[key] = v
... v = v_next
...
... self[key+1] = v
...
>>> a = StrangeDict({0:5, 1:7, 2: 14})
>>> a.insert(1, 5)
>>> a
{0: 5, 1: 5, 2: 7, 3: 14}

Yes, it's a terrible class and lacks a lot of safety checks, but I
don't think at all it violates the map contract. You can continue and
add some constraint at __init__() about key types and their
contiguity, some other methods and voila', you'll get a list-like
class.

Let me add that an items() and keys() for sequences will be also
useful for day-by-day programming, since they will be a shortcut for
enumerate(seq) and range(len(seq))

> The whole idea of making sequences and mappings more similar is highly
> distasteful to me, and I've figured out why. It's the exact problem
> with the PHP array - it's not sure whether to act as a mapping or a
> sequence

This is a good point. This is not true for mutable sequences (lists),
since they will have a lot of methods (append, pop etc) that allows
you to distinguish them, but immutable sequences like tuples will be
not easily distinguishable using duck typing.

I think the main problem is in __getitem__. __getitem__ can be used as
slice method checking if its parameter is a slice. If the slice method
was a separated method, this problem will not arise.


On 27 March 2016 at 21:24, Mark Lawrence  wrote:
> Why do you need a new interace if all you're trying to do is create a
> vdict class that has "iter(d) == iter(d.values()), and should also
> have a count() method, like sequence types"?

Since simply adding get(), items(), keys(), values() to existing
sequence interface will likely break existing code, I would try also
to write new sequence types, using a common interface with maps. This
is my idea.
-- 
https://mail.python.org/mailman/listinfo/python-list