Re: [Python-ideas] Null coalescing operator

[Nick Badger]

The problem with doing that is that it's ambiguous. There's no way of
telling which attribute is allowed to coalesce.

I think one of the best arguments for a coalescing operator in Python is
that it allows you to be more explicit, without the hassle of nested try:
except AttributeError blocks. You lose that with something like
attrgetter('b.x.z', coalesce=True) -- it would behave identically,
regardless of whether b, x, or z were missing, which is (oftentimes) not
what you want.


Nick Badger
https://www.muterra.io
https://www.nickbadger.com

2016-10-27 15:28 GMT-07:00 Barry Warsaw :

> On Oct 27, 2016, at 06:27 PM, Joonas Liik wrote:
>
> >perhaps just having a utility function can get us some of the way there..
> >
> >#may error
> >r = a.b.x.z
> >
> ># will default to None
> >r = a?.b?.x?.z
> >r = get_null_aware(a, "b.x.z") # long but no new syntax, can be
> >implemented today.
>
> You could probably do this by extending operator.attrgetter() to take an
> optional 'coalesce' keyword.  It wouldn't be super pretty, but it has the
> advantage of no magical new syntax.  E.g. your example would be:
>
> from operator import attrgetter
> r = attrgetter('b.x.z', coalesce=True)
>
> That might be good enough for honestly how rare I think this use case is.
> (Similarly with itemgetter().)
>
> Cheers,
> -Barry
>
> ___
> 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] Smart/Curly Quote Marks and cPython

[Mikhail V]

On 27 October 2016 at 21:51, M.-A. Lemburg  wrote:
> On 27.10.2016 20:28, Mikhail V wrote:
>> So what about curly quotes? This would make at
>> least some sense, regardless of unicode.
>
> -1. This would break code using curly quotes in string literals,
> break existing Python IDEs and parsers.
>
> BTW: I have yet to find a keyboard which allows me to enter
> such quotes. I think you simply have to accept that MS Word is
> not a supported editor for Python applications ;-)
>
> --
> Marc-Andre Lemburg

Hehe :)

For me, putting them in is simply as having this
in my vimrc config:

inoremap  147
inoremap  148

Currently I don't become code from outer applications
so I type them in, so for new code it will not cause
much problems. For old code I think it not so infeasible
to make batch convert to the new format.

AND you know, even in VIM with its spartanic "Courier New"
monowidth font, those quotes look sooo much better, that
I really want it. And in my code there tons of quotes
in concatenating string for console commands.

So I am +1 on this, but of course I cannot argue that it
is very "uncomfortable" change in general.

Mikhail
___
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] Distribution agnostic Python project packaging

[Barry Warsaw]

On Oct 27, 2016, at 02:50 PM, James Pic wrote:

>Now I'm fully aware of distribution specific packaging solutions like
>dh-virtualenv shared by Spotify but here's my mental problem: I love to
>learn and to hack. I'm always trying now distributions and I rarely run the
>one that's in production in my company and when I'm deploying personal
>projects I like funny distributions like arch, Alpine Linux,  or
>interesting paas solutions such as cloudfoundry, openshift, rancher and
>many others.
>
>So that's the idea I'm trying to share: I'd like to b able to build a file
>with my dependencies and my project in it.

You might want to look at the Snap ecosystem.  It's fairly new, but it is
cross-distro and cross-arch, and in many ways a very cool way to build
self-contained applications where you control all the dependencies.  You don't
have to worry so much about each distribution's peculiarities, and Python gets
first-class support[*].

There are lots of technical and philosophical aspects to Snaps that are
off-topic for this mailing list, so I'll just point you to where you can
explore it on your own:

http://snapcraft.io/

Disclosure: I work for Canonical in my day job, which invented the technology,
but it is in very large part an open source community project.

Cheers,
-Barry

[*] In fact, the nice convenience front-end to building snaps is a Python 3
application.


pgpVdSY4u4DeG.pgp
Description: OpenPGP digital signature
___
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] Smart/Curly Quote Marks and cPython

[Mikhail V]

On 27 October 2016 at 21:40, Random832  wrote:
> On Thu, Oct 27, 2016, at 14:28, Mikhail V wrote:
>> So you need umlauts to describe an algorithm and to explain yourself in
>> turkish?
>> Cool story. Poor uncle Garamond spins in his coffin...
>
> Why do you need 26 letters? The Romans didn't have so many. Hawaiian
> gets by with half as many - even if you count the accented vowels and
> the ʻokina it's still only 18.
>
> Why upper and lower case? Do we *really* need digits, can't we just use
> the first ten letters?
>
> Allowing each language to use its own alphabet, even if any of them may
> be inefficient and all of them together certainly are, is the only
> reasonable place to draw the line.

Hi Random,

Yes that is what I am trying to tell, but some paint
a "bigot" of me.
So there is no contradiction here. You know you "local"
script and you know Latin. So it belongs to my human
right if I want to choose a more effective one, so
since Latin is most effective now, I take it.
Simply like I take a wheel without defects and with
tight pressure in tyre. I don't have emotions
or sadness that I will forget my strange old
letters.
And if we return to problem of universal
communication "kind of standard"
then what the sense to take a defect wheel?
I am not the one to allow or disallow anything,
but I respect the works of Garamond and his predecessors
who made it possible for me to read without pain in eyes
and I disrespect attempts to ruin it. And beleive me,
it is *very* easy to ruin it all by putting umlauts and accents,
just like putting stones in the tyre.

Mikhail
___
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] Smart/Curly Quote Marks and cPython

[Mikhail V]

On 27 October 2016 at 06:24, Chris Angelico  wrote:
> On Thu, Oct 27, 2016 at 2:06 PM, Mikhail V  wrote:
>> Yep, double quotes , dashes and bullets are very valuable both for typography
>> and code (which to the largest part is the same)
>> So if just blank out this maximalistic BS:
>> ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö
>>
>> And add few good bullets/blocks, probably arrows, then it would be a
>> reasonable set to
>> use for most cases.
>
> You've missed out a half a dozen characters needed by Turkish or
> Hungarian, and completely missed the point that the Latin script is
> *NOT SUFFICIENT* for Python. If you want to argue that we should
> restrict the world to 256 characters, go blog somewhere and let people
> ignore you there, rather than ignoring you here. Unicode is here to
> stay.
>
> ChrisA

So you need umlauts to describe an algorithm and to explain yourself in turkish?
Cool story. Poor uncle Garamond spins in his coffin...

So what about curly quotes? This would make at
least some sense, regardless of unicode.

Mikhail
___
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] Smart/Curly Quote Marks and cPython

[Ned Batchelder]

On 10/27/16 10:12 AM, Mikhail V wrote:
> On 27 October 2016 at 06:24, Chris Angelico  wrote:
>
>> Unicode is here to stay.
> Congratulations. And chillax. I don't blog anywhere, have no time for that.
It's not clear at all where this thread is going, but it's clear to me
that it is off-topic.

--Ned.
___
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] Null coalescing operator

[Random832]

On Thu, Oct 27, 2016, at 11:27, Joonas Liik wrote:
> perhaps just having a utility function can get us some of the way there..
> 
> #may error
> r = a.b.x.z
> 
> # will default to None
> r = a?.b?.x?.z

If a.b can't or shouldn't be None, this should be a?.b.x.z

I'm not certain how your utility function is supposed to differentiate
this case, or handle subscripts or method calls.

> r = get_null_aware(a, "b.x.z") # long but no new syntax, can be
> implemented today.
___
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] More user-friendly version for string.translate()

[Chris Barker]

>>return string.translate(collections.defaultdict(lambda: None,
**table))

Nice! I forgot about defautdict -- so this just needs a recipe somewhere --
maybe even in the docs for str.translate.

BTW, great use case for defautdict -- I had been wondering what the point
was, given that a regular dict as .setdefault

-CHB




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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] Distribution agnostic Python project packaging

[Chris Barker]

OT, but

Assuming your dependencies have version agnostic wheels (either manylinux
> or pure python), what would be the advantage to you of putting everything
> together in a single file?
>
> That being said, I suppose it would be possible to create your own
> manylinux wheels that include all the necessary dependencies, but that
> would make building more difficult and opens up the possibility that the
> installed modules will conflict with users' existing installed packages.
>

which is why conda exists -- conda can package up many things besides
python packages, and you WILL need things besides python pacakges.

building conda packages for everything you need, and then creating an
environment.yaml file, and you can create a consistent environment very
easy across systems (even across OSs) There is even a project (I forgot
what its called -- "collections" maybe?) that bundles up a bunch of conda
packages for you.

and with conda-forge, there are an awful lot of packages already to go.

If you need even more control over your environment, then Docker is the way
to go -- you can even use conda inside docker...

-CHB










>
> Another possibility would be to use docker to create a container [2] that
> includes everything you need to run the code in an isolated environment
> that won't conflict
>
> [1] https://github.com/pypa/manylinux
> [2] https://www.digitalocean.com/community/tutorials/docker-
> explained-how-to-containerize-python-web-applications
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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] Null coalescing operator

[Joonas Liik]

perhaps just having a utility function can get us some of the way there..

#may error
r = a.b.x.z

# will default to None
r = a?.b?.x?.z
r = get_null_aware(a, "b.x.z") # long but no new syntax, can be
implemented today.
___
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] Distribution agnostic Python project packaging

[Steven D'Aprano]

On Thu, Oct 27, 2016 at 02:50:52PM +0200, James Pic wrote:

> And I'm always facing the same problem: I have to either build runtime
> dependencies on the server, either package my thing in the platform
> specific way. I feel like I've spent a really huge amount of time doing
> this king of thing. But the java people, they have jars, and they have
> smooth deployments no matter where they deploy it.
> 
> So that's the idea I'm trying to share: I'd like to b able to build a file
> with my dependencies and my project in it.
[...]
> So I wonder, do you think the best solution for me would be to build an elf
> binary with my Python and dependencies that I could just run on any
> distribution given its on the right architecture ? Note that I like to use
> Arm too, so I know I'd need to be able to cross compile too.

Your question is off-topic for this list. This list is for proposing new 
features for the Python language, but you don't seem to proposing 
anything new.

To ask for advice on using Python (including things like packaging 
dependencies), you probably should ask on the Python-List mailing list, 
also available on usenet as comp.lang.python. There may be some other 
dedicated mailing lists that specialise in packaging questions, check 
the mailing list server here:

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

I can't really help you with your question, except to point you in the 
direction of a little-known feature of Python: zip file application 
support:

https://www.python.org/dev/peps/pep-0441/

https://docs.python.org/3/library/zipapp.html



-- 
Steve
___
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] Distribution agnostic Python project packaging

[Todd]

On Thu, Oct 27, 2016 at 8:50 AM, James Pic  wrote:

> Hi all !
>
> Ive heard some people saying it was rude to post on a mailing list without
> introducing yourself so here goes something: my name is James Pic and I've
> been developing and deploying a wide variety fof Python projects Python for
> the last 8 years, I love to learn and share and writing documentation
> amongst other things such as selling liquor.
>
> The way I've been deploying Python projects so far is probably similar to
> what a lot of people do and it almost always includes building runtime
> dependencies on the production server. So, nobody is going to congratulate
> me for that for sure but I think a lot of us have been doing so.
>
> Now I'm fully aware of distribution specific packaging solutions like
> dh-virtualenv shared by Spotify but here's my mental problem: I love to
> learn and to hack. I'm always trying now distributions and I rarely run the
> one that's in production in my company and when I'm deploying personal
> projects I like funny distributions like arch, Alpine Linux,  or
> interesting paas solutions such as cloudfoundry, openshift, rancher and
> many others.
>
> And I'm always facing the same problem: I have to either build runtime
> dependencies on the server, either package my thing in the platform
> specific way. I feel like I've spent a really huge amount of time doing
> this king of thing. But the java people, they have jars, and they have
> smooth deployments no matter where they deploy it.
>
> So that's the idea I'm trying to share: I'd like to b able to build a file
> with my dependencies and my project in it. I'm not sure packaging only
> Python bytecode would work here because of c modules. Also, I'm always
> developing against a different Python version because I'm using different
> distributions because it's part of my passions in life, as ridiculous as it
> could sound to most people, I'm expecting at least some understanding from
> this list :)
>
> So I wonder, do you think the best solution for me would be to build an
> elf binary with my Python and dependencies that I could just run on any
> distribution given its on the right architecture ? Note that I like to use
> Arm too, so I know I'd need to be able to cross compile too.
>
> Thanks a lot for reading and if you can to take some time to share your
> thoughts and even better : point me in a direction, if that idea is the
> right solution and I'm going to be the only one interested I don't care if
> it's going to take years for me to achieve this.
>
> Thanks a heap !
>
> Beat regards
>
> PS: I'm currently at the openstack summit in Barcelona if anybody there
> would like to talk about it in person, in which case I'll buy you the
> drinks ;)
>

Are you sure this is really what you need to do?  With dependency handling,
you can define the dependencies of your project and they will automatically
get installed from pypi when the user tries to install the package (if they
aren't already installed).  manylinux wheels [1] allow you to distribute
your own code in a manner that is compatible with most linux distributions,
and many c-based projects now offer such wheels.

Assuming your dependencies have version agnostic wheels (either manylinux
or pure python), what would be the advantage to you of putting everything
together in a single file?

That being said, I suppose it would be possible to create your own
manylinux wheels that include all the necessary dependencies, but that
would make building more difficult and opens up the possibility that the
installed modules will conflict with users' existing installed packages.

Another possibility would be to use docker to create a container [2] that
includes everything you need to run the code in an isolated environment
that won't conflict

[1] https://github.com/pypa/manylinux
[2]
https://www.digitalocean.com/community/tutorials/docker-explained-how-to-containerize-python-web-applications
___
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] Distribution agnostic Python project packaging

[Chris Angelico]

On Thu, Oct 27, 2016 at 11:50 PM, James Pic  wrote:
> So that's the idea I'm trying to share: I'd like to b able to build a file
> with my dependencies and my project in it. I'm not sure packaging only
> Python bytecode would work here because of c modules. Also, I'm always
> developing against a different Python version because I'm using different
> distributions because it's part of my passions in life, as ridiculous as it
> could sound to most people, I'm expecting at least some understanding from
> this list :)
>
> So I wonder, do you think the best solution for me would be to build an elf
> binary with my Python and dependencies that I could just run on any
> distribution given its on the right architecture ? Note that I like to use
> Arm too, so I know I'd need to be able to cross compile too.

In theory, you could do that. You'd have to include *all* of Python,
and all of everything else you might depend on, because you can't be
sure what is and isn't available, so you might as well ship your app
as a VM image or something, with an entire operating system.

In practice, you're probably going to need to deal with some sort of
package manager, and that's where the difficulties start. You can
probably cover most of the Debian-based Linuxes by targeting either
Debian Stable or Ubuntu LTS and creating a .deb file that specifies
what versions of various libraries you need. There's probably a way to
aim an RPM build that will work on RHEL, Fedora, SUSE, etc, but I'm
not familiar with that family tree and where their library versions
tend to sit. The trouble is that as soon as you land on an OS version
that's too far distant from the one you built on, stuff will break.
Between the bleeding-edge rolling distros and the super-stable ones
could be over a decade of development (RHEL 4, released in 2005, is
still supported).

What you can probably do is ignore the absolute bleeding edge (anyone
who's working on Debian Unstable or Arch or Crunchbang is probably
aware of the issues and can solve them), and then decide how far back
you support by looking at what you depend on, probably losing the very
oldest of distributions. It should be possible to hit 95% of Linuxes
out there by providing one .deb and one .rpm (per architecture, if you
support multiple), but don't quote me on that figure.

Unfortunately, the problem you're facing is virtually unsolvable,
simply because the freedom of open systems means there is a LOT of
variation out there. But most people on the outskirts are accustomed
to doing their own dependency management (like when I used to work
primarily on OS/2 - nobody supports it much, so you support it
yourself).

With all sincerity I say to you, good luck. Try not to lose the
enthusiasm that I'm hearing from you at the moment!

ChrisA
___
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] Distribution agnostic Python project packaging

[James Pic]

Hi all !

Ive heard some people saying it was rude to post on a mailing list without
introducing yourself so here goes something: my name is James Pic and I've
been developing and deploying a wide variety fof Python projects Python for
the last 8 years, I love to learn and share and writing documentation
amongst other things such as selling liquor.

The way I've been deploying Python projects so far is probably similar to
what a lot of people do and it almost always includes building runtime
dependencies on the production server. So, nobody is going to congratulate
me for that for sure but I think a lot of us have been doing so.

Now I'm fully aware of distribution specific packaging solutions like
dh-virtualenv shared by Spotify but here's my mental problem: I love to
learn and to hack. I'm always trying now distributions and I rarely run the
one that's in production in my company and when I'm deploying personal
projects I like funny distributions like arch, Alpine Linux,  or
interesting paas solutions such as cloudfoundry, openshift, rancher and
many others.

And I'm always facing the same problem: I have to either build runtime
dependencies on the server, either package my thing in the platform
specific way. I feel like I've spent a really huge amount of time doing
this king of thing. But the java people, they have jars, and they have
smooth deployments no matter where they deploy it.

So that's the idea I'm trying to share: I'd like to b able to build a file
with my dependencies and my project in it. I'm not sure packaging only
Python bytecode would work here because of c modules. Also, I'm always
developing against a different Python version because I'm using different
distributions because it's part of my passions in life, as ridiculous as it
could sound to most people, I'm expecting at least some understanding from
this list :)

So I wonder, do you think the best solution for me would be to build an elf
binary with my Python and dependencies that I could just run on any
distribution given its on the right architecture ? Note that I like to use
Arm too, so I know I'd need to be able to cross compile too.

Thanks a lot for reading and if you can to take some time to share your
thoughts and even better : point me in a direction, if that idea is the
right solution and I'm going to be the only one interested I don't care if
it's going to take years for me to achieve this.

Thanks a heap !

Beat regards

PS: I'm currently at the openstack summit in Barcelona if anybody there
would like to talk about it in person, in which case I'll buy you the
drinks ;)
___
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 better interactive prompt

[Steven D'Aprano]

On Thu, Oct 27, 2016 at 10:35:32AM +0100, Paul Moore wrote:

> The Windows default command line editing experience is a lot better
> (IMO) than the (non-readline) Unix default, and it's common throughout
> all interactive prompts (Python's REPL included). As a result, when
> readline is installed (pyreadline on Windows, which used to be needed
> for IPython) it disrupts the "normal" editing experience. It's
> possible that with a bit of configuration and practice I could get
> used to the readline experience, but then I get a different experience
> when in a venv where I don't have pyreadline installed.

Ah, that makes sense.


> The idea that simply having a module called "readline" available,
> changes the REPL behaviour, with no way to configure that, seems
> incredibly hostile to me.

I think that making readline less aggressive (at least for Windows 
users) may be a reasonable feature request for 3.7.


-- 
Steve
___
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 better interactive prompt

[Paul Moore]

On 27 October 2016 at 01:49, Steven D'Aprano  wrote:
>> (a bit like readline,
>> but I dislike the way you can't switch off readline integration if
>> it's installed)?
>
> This comment surprises me. To me, that's like saying "I dislike the way
> you can't switch off breathing" -- readline is almost indispensible. The
> REPL experience without line editing (apart from backspace) and history
> is *horrible*. Why would you want to switch it off?

The Windows default command line editing experience is a lot better
(IMO) than the (non-readline) Unix default, and it's common throughout
all interactive prompts (Python's REPL included). As a result, when
readline is installed (pyreadline on Windows, which used to be needed
for IPython) it disrupts the "normal" editing experience. It's
possible that with a bit of configuration and practice I could get
used to the readline experience, but then I get a different experience
when in a venv where I don't have pyreadline installed.

The idea that simply having a module called "readline" available,
changes the REPL behaviour, with no way to configure that, seems
incredibly hostile to me. Of course it's arguably pyreadline's fault
for reusing a stdlib name, but nevertheless it's not something I agree
with.

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/