How keep Python 3 moving forward

[Rustom Mody]

I thought this was a moderated list. What exactly are the moderators doing?

Your unicode is mojibaked Ethan! Voil�.
You are hereby banished to a lonely island with python 1.5 and jmf for company

 

[Roy Smith]

Ubuntu provides a (partial) Py3 port of boto.

As long as the part that's ported includes all the bits of boto we
currently need, plus all the bits of boto we haven't yet discovered we
need, but will sometime in the future, we're good

And I don't really see why you would consider fabric a dependency
that keeps you from switching to Py3. In many cases, you can just
keep running it in Py2 as you did before.

In theory, that's possible. In practice, it would mean having to
maintain two different versions of Python, and test everything against
both. That adds a lot of complexity, for very little value.

 

[Steven D'Aprano]

Your unicode is mojibaked Ethan! Voil�. You are hereby banished to a
lonely island with python 1.5 and jmf for company

Nope, it's you. Ethan's post is fine. He correctly quotes JMF stating
"Voilà" (that's LATIN SMALL LETTER A WITH GRAVE), and Ethan's post
correctly gives an encoding header:

Content-Type: text/plain; charset=iso-8859-1; format=flowed

(although, boo to Thunderbird for using a legacy encoding instead of
UTF-8). So his post is fine. Whatever the problem is, it's at your end.

 

[Ethan Furman]

Your unicode is mojibaked Ethan! Voil�.
You are hereby banished to a lonely island with python 1.5 and jmf for company

1.5 I could live with. Surely the company would count as cruel and
unusual punishment?

 

[Tim Chase]

Nope, it's you. Ethan's post is fine. He correctly quotes JMF
stating "Voilà" (that's LATIN SMALL LETTER A WITH GRAVE), and
Ethan's post correctly gives an encoding header:

Content-Type: text/plain; charset=iso-8859-1; format=flowed

I corroborate Steven's findings, that Ethan's post was correctly
encoded & displayed.

(although, boo to Thunderbird for using a legacy encoding instead
of UTF-8). So his post is fine. Whatever the problem is, it's at
your end.

Thunderbird does offer the ability to change default character
encodings (Edit -> Preferences -> Display -> Formatting tab ->
Advanced...) for sending and receiving, but you have to go out of your
way to change them to something like UTF-8. On the same preferences
screen TB provides the option to "when possible, use the default
character encoding in replies".

-tkc

 

[Ethan Furman]

Thunderbird does offer the ability to change default character
encodings (Edit -> Preferences -> Display -> Formatting tab ->
Advanced...) for sending and receiving, but you have to go out of your
way to change them to something like UTF-8. On the same preferences
screen TB provides the option to "when possible, use the default
character encoding in replies".

Thanks, fixed.

 

[Mark Lawrence]

1.5 I could live with. Surely the company would count as cruel and
unusual punishment?

The latter is definitely true, but does being king make up for it, on
the grounds that he's clearly blind?

 

[Dennis Lee Bieber]

I thought this was a moderated list. What exactly are the moderators doing?

Not only is it not moderated, but it's "sourced" from three places:
comp.lang.python (non-moderated Usenet newsgroup -- which is contaminated
by peering with GoogleGroups) -- which cross-links with: a Python-specific
mailing list -- which is then accessible as an NNTP group at
gmane.comp.python.general. c.l.p is definitely not moderated, the mailing
list and gmane group may have some spam filters in place but no real
moderation.

 

[Dennis Lee Bieber]

1.5 I could live with. Surely the company would count as cruel and
unusual punishment?

"company"... Or emergency rations?

 

[Mark Lawrence]

"company"... Or emergency rations?

I suspect that chewing razor blades would be preferable to listening to
the permanent rant about what's wrong with the FSR.

 

[Chris Angelico]

"company"... Or emergency rations?

Unfortunately not as effective as these guys:

http://gatherer.wizards.com/Pages/Card/Details.aspx?multiverseid=46017

ChrisA

 

[Ethan Furman]

"company"... Or emergency rations?

Well, the thought had crossed my mind... I guess the deciding factor
would have to be if I had any ketchup.

 

[Terry Reedy]

the mailing
list and gmane group may have some spam filters in place but no real
moderation.

They *do* have spam, structure, and source filters. Please do not
mis-inform people that they post most anything to python-list without
consequence.

 

[Roy Smith]

Why would using Fabric – a build tool – require you to “maintain two
different versions of Python� You only need to maintain the build
scripts, not Python itself.

Because to run these tools, we need have both versions installed on
every machine. So, we don't need to maintain Python in the sense of
building it from source, but we do need to have our deployment scripts
install it everyplace it's needed (or, at least, make sure it's
installed as part of some base deployment package)

That makes even less sense. The build system runs under whatever version
of Python it needs, and your code runs under whatever version of Python
you like. The two don't affect each other at run time, and don't affect
each other's testing dependencies.

The are tightly integrated, and share code.

At least one of us seems to be misunderstanding what is required.

Yes

When you start working with large systems, reducing complexity becomes
important. Every time you add a component, it comes with its own set of
dependencies and constraints. Those things come back to bite you when
you least expect it.

 

[wxjmfauth]

Le lundi 26 mai 2014 01:09:31 UTC+2, Mark Lawrence a écrit :

I suspect that chewing razor blades would be preferable to listening to

the permanent rant about what's wrong with the FSR.



--

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

what you can do for our language.

===========
===========

It's just a mathematical absurdity.
(No problems, to explain this to some
other people, who are agreeing).

jmf

 

[Steven D'Aprano]

The are tightly integrated, and share code.

Well there's your problem, right there. Tight coupling is a *bad* thing,
you're supposed to minimize it, not maximize it

I'm having trouble understanding why your build system should be
integrated with your production code. You should, in principle, be able
to replace your build system with one written in Perl or bash without
having to touch a single line of your application. If what you say is
correct, your design tends towards the sort of perplexing errors like "We
added extra debugging code to the build script, and now the application
won't print!"

The programmer's attitude towards tightly coupled code ought to be like
Batman's attitude towards crime: something to be stamped out, at any
cost, unless it is absolutely for the purpose of a higher cause.

In Batman's case that higher cause is justice and the good of Gotham
City. What's your higher cause?

 

[Steven D'Aprano]

Oh, I was a bit trigger-happy with my earlier post.

The are tightly integrated, and share code.
[...]

When you start working with large systems, reducing complexity becomes
important. Every time you add a component, it comes with its own set of
dependencies and constraints. Those things come back to bite you when
you least expect it.

How ironic that you have now got *more* constraints, *stronger*
dependencies and *more* complexity than if you had written a less tightly
coupled system.

Complexity is not, in and of itself, the most serious problem. But
coupling is. You're now constrained that you cannot make changes to your
application without simultaneously changing your build system. Although
you have *fewer* dependencies, they've locked you in to a single course
of action even more tightly than if you had more.

At least that's the impression that you have given.

 

[Rustom Mody]

Well there's your problem, right there. Tight coupling is a *bad* thing,

you're supposed to minimize it, not maximize it



I'm having trouble understanding why your build system should be
integrated with your production code. You should, in principle, be able
to replace your build system with one written in Perl or bash without
having to touch a single line of your application. If what you say is

In theory, theory and practice are the same. In practice, they are not. s/theory/principle

[Whether thats Einsten or Yogi Berra I am not sure. I guess they
are the same in principle ]

Somewhat more seriously, I see this as a problem with all the super-kewl languages. I know it most closely with python and haskell but I think its true across the board. It goes something like this:
- Language L is super-kewl
- Its so kewl it spawns its own ecosystem
- The ecosystem grows
- World domination is almost in sight -- everything to be done with
language L
- Unfortunately super-kewl ≠ omnipotent
- Things start crumbling at the edges

Case(s) in point: debian's apt is a mishmash of perl,shell etc
However it is more powerful than python's pip or Haskell's cabal.