Re: [Python-ideas] A more readable way to nest functions

[C Anthony Risinger]

On Fri, Jan 27, 2017 at 3:28 PM, Ethan Furman  wrote:

> On 01/27/2017 01:07 PM, Brent Brinkley wrote:
>
>> Suggested structure:
>>
>>   print() <| some_func() <| another_func("Hello")
>>
>
> My first question is what does this look like when print() and some_func()
> have other parameters?  In other words, what would this look like?
>
> print('hello', name, some_func('whatsit', another_func('good-bye')),
> sep=' .-. ')


The Elixir pipe operator looks pretty close to the suggested style, but the
argument order is reversed:

another_func('good-bye') |> some_func('whatsit') |> print('hello', name,
sep=' .-. ')

This isn't exactly equivalent to the example though because the result of
each call is passed as the first argument to the next function. I think it
looks nice when it's the right fit, but it's limited to the first argument.

-- 

C Anthony
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Is it Python 3 yet?

[C Anthony Risinger]

On Jan 27, 2017 4:51 PM, "Random832"  wrote:

On Fri, Jan 27, 2017, at 12:54, C Anthony Risinger wrote:
> I know the scientific community is a big and important part of the
> Python ecosystem, but I honestly believe other parts of Python are
> suffering from any dragging of feet at this point. Python 3 has been
> out nearly a decade, and I think it would be super for the community
> to take a bold stance (is it still bold 9 years later?) and really
> stand behind Python 3, prominently, almost actively working to
> diminish Python 2.

This particular subthread is regarding whether to make a 64-bit version
of python 2 and/or 3 (whatever is done regarding the other question) the
default download button for users coming from Win64 browsers. At least,
the bits you're responding to are talking about 32-bit libraries rather
than Python 2.


Yeah, I guess I was trying to push against any further stagnation, of any
kind, on forward-facing questions like 32/64 bit and 2/3 version. I
hesitated to say anything because I don't feel I'm adding much concrete or
even useful information to the conversation, but it's something that's been
building internally for a long time while observing the overarching tone
and outcomes of Python threads.

I can't articulate it we'll, or even fully isolate the reasons for it. All
I really know is how I feel when peers ask me about Python or the reading I
get when others speak about their experience using it. Python is absolutely
one of my favorite languages to write, yet I find myself recommending
against it, and watching others do the same. Python comes with caveats and
detailed explanations out the gate and people simply perceive higher
barriers and more chores.

I don't have any truly constructive input so I'll stop here; I only wanted
to voice that in my tiny tiny bubble, I'm watching market share diminish,
it's unfortunate, and I'm not sure what to do about it.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A more readable way to nest functions

[Ethan Furman]

On 01/27/2017 01:07 PM, Brent Brinkley wrote:


I’m relatively new to the world of python


Welcome!


 but in my short time here I’ve
 fallen in love with how readable this language is. One issue that I’ve
 seen in a lot of languages struggle with is nested function calls.
 Parenthesis when nested inherently create readability issues. I stumbled
 upon what I believe is an elegant solution within the elm platform in
 their use of the backward pipe operator <|.


Please use text -- it save responders from having to reenter the non-text 
content>


Suggested structure:

  print() <| some_func() <| another_func("Hello")


My first question is what does this look like when print() and some_func() have 
other parameters?  In other words, what would this look like?

print('hello', name, some_func('whatsit', another_func('good-bye')), sep=' 
.-. ')

Currently, I would format that as:

   print(
'hello',
name,
some_func(
 'whatsit',
 another_func(
 'good-bye')
 ),
  ),
sep=' .-. ',
)

Okay, maybe a few more new-lines than such a short example requires, but that's 
the idea.

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A more readable way to nest functions

[João Santos]

Hi,

This would break apart as soon as one of left functions takes more than one
parameter.

Best regards,
João Santos

On Fri, 27 Jan 2017, 22:08 Brent Brinkley,  wrote:

> HI Everyone,
>
> I’m relatively new to the world of python but in my short time here I’ve
> fallen in love with how readable this language is. One issue that I’ve seen
> in a lot of languages struggle with is nested function calls. Parenthesis
> when nested inherently create readability issues. I stumbled upon what I
> believe is an elegant solution within the elm platform in their use of the
> backward pipe operator <|.
>
>
> Current Ex.
>
>
> Suggested Structure
>
> This aligns with the Zen of Python in the following ways
>
>
>- Simple is better than complex
>- Flat is better than nested
>- Sparse is better than dense
>- Readability counts
>- Practicality beats purity
>
>
> Ways it may conflict
>
>
>- Explicit is better than implicit
>- Special cases aren't special enough to break the rules
>
>
> Just curious to see what the rest of the community thinks 
>
> Best Regards,
>
> Brent
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] A more readable way to nest functions

[Brent Brinkley]

HI Everyone,

I’m relatively new to the world of python but in my short time here I’ve fallen 
in love with how readable this language is. One issue that I’ve seen in a lot 
of languages struggle with is nested function calls. Parenthesis when nested 
inherently create readability issues. I stumbled upon what I believe is an 
elegant solution within the elm platform in their use of the backward pipe 
operator <|.  


Current Ex.



Suggested Structure


This aligns with the Zen of Python in the following ways

Simple is better than complex
Flat is better than nested
Sparse is better than dense
Readability counts 
Practicality beats purity

Ways it may conflict

Explicit is better than implicit
Special cases aren't special enough to break the rules

Just curious to see what the rest of the community thinks 

Best Regards,

Brent___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Is it Python 3 yet?

[C Anthony Risinger]

So I realize this is subjective and just a personal experience, but over
the last 3-5 years I've really watched Python usage and popularity decline
in the "hearts and minds" of my peers, across a few different companies I
work with. At my current gig we don't even use Python anymore for tools
that will be distributed to an end user; we only use Python for internal
tooling.

With a still difficult distribution/compatibility story, I've watched
dozens of instances where people choose something else, usually Node or
Golang. The primary uses here are api and microservice-type applications,
developer tooling, and CLI apps. Even recent additions like `async` keyword
are causing more problems because it's not a useful general-purpose
concurrency primitive eg. like a goroutine or greenlets.

I know the scientific community is a big and important part of the Python
ecosystem, but I honestly believe other parts of Python are suffering from
any dragging of feet at this point. Python 3 has been out nearly a decade,
and I think it would be super for the community to take a bold stance (is
it still bold 9 years later?) and really stand behind Python 3,
prominently, almost actively working to diminish Python 2.

I've been hearing and reading about both for a long time, and honestly I'd
love one of them to go away! I don't even care which :-)

On Fri, Jan 27, 2017 at 4:25 AM, Terry Reedy  wrote:

> On 1/27/2017 4:38 AM, Nathaniel Smith wrote:
>
>> On Fri, Jan 27, 2017 at 1:32 AM, Stephan Houben <
>> stephanh42-re5jqeeqqe8avxtiumw...@public.gmane.org> wrote:
>>
>>> Hi all,
>>>
>>> FWIW, I got the following statement from here:
>>>
>>> https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows
>>>
>>> "Standard numpy and scipy binary releases on Windows use pre-compiled
>>> ATLAS
>>> libraries and are 32-bit only because of the difficulty of compiling
>>> ATLAS
>>> on 64-bit Windows. "
>>>
>>> Might want to double-check with the numpy folks; it would
>>> be too bad if numpy wouldn't work on the preferred Windows Python.
>>>
>>
>> That's out of date
>>
>
> Would be nice if it were updated...
>
>  -- official numpy releases have switched from ATLAS
>
>> to OpenBLAS (which requires some horrible frankencompiler system, but
>> it seems to work for now...), and there are 32- and 64-bit Windows
>> wheels up on PyPI: https://pypi.python.org/pypi/numpy/
>>
>
> and from
>
> NumPy, a fundamental package needed for scientific computing with Python.
> Numpy+MKL is linked to the Intel® Math Kernel Library and includes
> required DLLs in the numpy.core directory.
>
> numpy‑1.11.3+mkl‑cp27‑cp27m‑win32.whl
> numpy‑1.11.3+mkl‑cp27‑cp27m‑win_amd64.whl
> etc.
>
> All the several packages that require numpy also come in both versions.
>
> 64-bit is definitely what I'd recommend as a default to someone
>> wanting to use numpy, because when working with arrays it's too easy
>> to hit the 32-bit address space limit.
>>
>> -n
>>
>>
>
> --
> Terry Jan Reedy
>
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 

C Anthony
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Is it Python 3 yet?

[Terry Reedy]

On 1/27/2017 4:38 AM, Nathaniel Smith wrote:

On Fri, Jan 27, 2017 at 1:32 AM, Stephan Houben 
 wrote:

Hi all,

FWIW, I got the following statement from here:

https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows

"Standard numpy and scipy binary releases on Windows use pre-compiled ATLAS
libraries and are 32-bit only because of the difficulty of compiling ATLAS
on 64-bit Windows. "

Might want to double-check with the numpy folks; it would
be too bad if numpy wouldn't work on the preferred Windows Python.


That's out of date


Would be nice if it were updated...

 -- official numpy releases have switched from ATLAS

to OpenBLAS (which requires some horrible frankencompiler system, but
it seems to work for now...), and there are 32- and 64-bit Windows
wheels up on PyPI: https://pypi.python.org/pypi/numpy/


and from

NumPy, a fundamental package needed for scientific computing with Python.
Numpy+MKL is linked to the Intel® Math Kernel Library and includes 
required DLLs in the numpy.core directory.


numpy‑1.11.3+mkl‑cp27‑cp27m‑win32.whl
numpy‑1.11.3+mkl‑cp27‑cp27m‑win_amd64.whl
etc.

All the several packages that require numpy also come in both versions.


64-bit is definitely what I'd recommend as a default to someone
wanting to use numpy, because when working with arrays it's too easy
to hit the 32-bit address space limit.

-n




--
Terry Jan Reedy


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Is it Python 3 yet?

[Nathaniel Smith]

On Fri, Jan 27, 2017 at 1:32 AM, Stephan Houben  wrote:
> Hi all,
>
> FWIW, I got the following statement from here:
>
> https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows
>
> "Standard numpy and scipy binary releases on Windows use pre-compiled ATLAS
> libraries and are 32-bit only because of the difficulty of compiling ATLAS
> on 64-bit Windows. "
>
> Might want to double-check with the numpy folks; it would
> be too bad if numpy wouldn't work on the preferred Windows Python.

That's out of date -- official numpy releases have switched from ATLAS
to OpenBLAS (which requires some horrible frankencompiler system, but
it seems to work for now...), and there are 32- and 64-bit Windows
wheels up on PyPI: https://pypi.python.org/pypi/numpy/

64-bit is definitely what I'd recommend as a default to someone
wanting to use numpy, because when working with arrays it's too easy
to hit the 32-bit address space limit.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Is it Python 3 yet?

[Stephan Houben]

Hi all,

FWIW, I got the following statement from here:

https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows

"Standard numpy and scipy binary releases on Windows use pre-compiled ATLAS
libraries and are 32-bit only because of the difficulty of compiling ATLAS
on 64-bit Windows. "

Might want to double-check with the numpy folks; it would
be too bad if numpy wouldn't work on the preferred Windows Python.

Stephan

2017-01-27 9:45 GMT+01:00 Paul Moore :

> Resending because Google Groups handling of mailing lists is broken
> :-( Sorry to anyone who gets double posts.
>
> On 27 January 2017 at 08:39, Paul Moore  wrote:
> > On 27 January 2017 at 06:22, Denis Akhiyarov 
> wrote:
> >> The problem is not in Python packages, but when gluing Python with
> other Windows apps or libraries.
> >
> > I would argue that anyone doing that is capable of looking for the
> > version they need. The proposal is simply to make the 64-bit version
> > what we offer by default, not to remove the 32-bit versions or even to
> > make them less prominent anywhere other than on the front page.
> >
> > Paul
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Default Python Windows version on python.org (was: Is it Python 3 yet?)

[M.-A. Lemburg]

On 27.01.2017 06:13, Terry Reedy wrote:
> On 1/26/2017 5:32 PM, M.-A. Lemburg wrote:
> 
>> Many applications on Windows are still 32-bit applications and
>> unless you process large amounts of data, a 32-bit Python
>> system is well worth using. In some cases, it's even needed,
>> e.g. if you have to use an extension which links to a 32-bit
>> library.
> 
> I look through the list of a few hundred windows packages at
> http://www.lfd.uci.edu/~gohlke/pythonlibs/
> 
> The two packages that require CUDA 8 and CUDNN are 64-bit only.  As far
> as I saw in a careful check, all other windows binaries are available in
> both 32- and 64-bit versions.  The situation may be different on PyPI,
> but win64 will cover most thing likely to be used by a beginner.

32-bit vs. 64-bit is a still very much a conscious choice on
Windows x64, and so whether or not a beginner chose to install
3rd party libs as 32-bit or 64-bit version is not something
we can really tell from looking at the browser info.

It would probably be better to make the choice for Python a
conscious one as well by offering both alternatives or at
least make it clear that the default is e.g. x64.

Some cases where you'd prefer 32-bit over 64-bit:
- MS Office:
https://support.office.com/en-us/article/Choose-the-64-bit-or-32-bit-version-of-Office-2dee7807-8f95-4d0c-b5fe-6c6f49b8d261
- LibreOffice:
https://ask.libreoffice.org/en/question/55819/version-5-choose-32-bit-or-64-bit/
- Anything to do with media codecs
- Anything that still supports older Windows versions
  (vendors often don't ship 64-bit variants due to this)

You just have to compare the number of entries in your
"Programs" dir with the "Programs (x86)" dir to see how
common 32-bit applications are today.

It's also possible that an application of library installs
both 32-bit and 64-bit variants. You can then run into issues
when configuring these. The ODBC manager on Windows x64 is a
prominent example: there are actually two versions of this,
one for 32-bit drivers and one for 64-bit drivers - using distinct
configurations. 32-bit apps only see the drivers configured with
the 32-bit manager, 64-bit apps only the ones configured with
the 64-bit variant.

Anyway, I agree that defaulting to x64 is the way forward, and
defaulting to x64 for Python on Windows x64 is a good approach,
but making the default choice clear to the beginner is probably
just as needed to at least give them a hint at what the cause
of their problems could be.

They have to make the same choice with many other applications
as well, so it's not like they've never seen this before.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jan 27 2017)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Is it Python 3 yet?

[Paul Moore]

Resending because Google Groups handling of mailing lists is broken
:-( Sorry to anyone who gets double posts.

On 27 January 2017 at 08:39, Paul Moore  wrote:
> On 27 January 2017 at 06:22, Denis Akhiyarov  
> wrote:
>> The problem is not in Python packages, but when gluing Python with other 
>> Windows apps or libraries.
>
> I would argue that anyone doing that is capable of looking for the
> version they need. The proposal is simply to make the 64-bit version
> what we offer by default, not to remove the 32-bit versions or even to
> make them less prominent anywhere other than on the front page.
>
> Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/