Re: [Python-ideas] RFC: PEP 540 version 3 (Add a new UTF-8 mode)

[Stephen J. Turnbull]

INADA Naoki writes:

 > No.  C locale doesn't forbid using UTF-8.

I'm sorry, but I believe you are completely misunderstanding what this
discussion is about.  I don't have time to deal with it any more.








___
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] Things that won't change (proposed PEP)

[Nick Coghlan]

On 13 January 2017 at 12:43, Stephen J. Turnbull
 wrote:
> Mark E. Haase writes:
>
>  > I don't think an informational PEP would make threads like Python Review
>  > shorter and/or more productive. The OP clearly didn't do much research, so
>  > it seems unlikely he would read an informational PEP.
>
> But just saying "do your research" (which is quite reasonable without
> the informational PEP) is much less friendly than including the URL to
> the informational PEP in the kind of "canned response" you suggest.
> That's what Steven is aiming at.
>
> I'm not sure that a PEP is the best format, as the normal PEP process is
> not a good match for something that is likely to need to be updated as
> "good syntax" is discovered for ideas formerly considered un-Pythonic
> and other languages come up with neat new ideas that don't have
> obvious Pythonic syntax.  Andrew Barnert's blog post (thanks, Chris!)
> http://stupidpythonideas.blogspot.com/2015/05/why-following-idioms-matters.html
> is a good start, and Nick Coghlan's "Curious Efficiency" blog has
> related material, I think.  Perhaps pointers to those would be good.

Expanding on https://docs.python.org/devguide/langchanges.html would
likely be a more useful format than an informational PEP.

As a starting point,
https://docs.python.org/devguide/faq.html#suggesting-changes should
likely be consolidated into that page, and the FAQ entry simplified
into a link to a new subsection on that page.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] Things that won't change (proposed PEP)

[Stephen J. Turnbull]

Mark E. Haase writes:

 > I don't think an informational PEP would make threads like Python Review
 > shorter and/or more productive. The OP clearly didn't do much research, so
 > it seems unlikely he would read an informational PEP.

But just saying "do your research" (which is quite reasonable without
the informational PEP) is much less friendly than including the URL to
the informational PEP in the kind of "canned response" you suggest.
That's what Steven is aiming at.

I'm not sure that a PEP is the best format, as the normal PEP process is
not a good match for something that is likely to need to be updated as
"good syntax" is discovered for ideas formerly considered un-Pythonic
and other languages come up with neat new ideas that don't have
obvious Pythonic syntax.  Andrew Barnert's blog post (thanks, Chris!)
http://stupidpythonideas.blogspot.com/2015/05/why-following-idioms-matters.html
is a good start, and Nick Coghlan's "Curious Efficiency" blog has
related material, I think.  Perhaps pointers to those would be good.

 > Moreover, the bikeshedding about what goes into this PEP will
 > inevitably lead to a troll who isn't satisfied with the explanation
 > of a particular item, or notices that a particular item isn't
 > included in the PEP, and then we're right back to the same problem:
 > litigating Python complaints that have already been discussed many
 > times on this list.

I don't see why that has to be the case.  The canned response here is
"Thank you for your suggestion.  The issue tracker is right over
that-a-way."

A suggestion for your canned response:

 > Hi, this appears to be your first post to python-ideas.

Unfortunately, there are a number of folks around who enjoy discussing
non-starters to death.  That's insulting to them, and therefore
against the spirit of the CoC.  I'd remove that, and write

 > This purpose of this list is to discuss speculative language ideas
 > for Python. If an idea gains traction, it can then be discussed and
 > honed into a detailed proposal.

followed by

Your post does not present a clear, coherent proposal.

and

 > Your post does not fit with the purpose of the list, either because
 > it is too broad or because it doesn't contain enough technical
 > details about your proposal. You may wish to improve your proposal
 > by focusing on a single subject, researching historical
 > conversations on that subject, and adding more technical
 > details. Alternatively, you may wish to post on python-list[1]
 > instead, which is a general purpose list that does not have the
 > same constraints as this list.

Of course this presentation is broken, the grammar can be improved
easily.

 > Stack Overflow does something similar, where they have canned
 > responses to low-quality questions. This makes it easy for the
 > community to self-moderate in a respectful manner.

We have a few of those already.  This would be a useful addition.

___
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] Settable defaulting to decimal instead of float

[Stephen J. Turnbull]

Chris Barker - NOAA Federal writes:

 > However: (thank you Chris and Stephen) --

I think you mean "Stephan". :-)


___
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] How to respond to trolling (Guido van Rossum)

[Stephen J. Turnbull]

Guido van Rossum writes:

 > AFAIK the term comes from a piece by Andrew Kuchling titled "Python warts".
 > The topic now has its own wiki page:
 > https://wiki.python.org/moin/PythonWarts
 > 
 > I believe that most of the warts are not even design missteps -- they are
 > emergent misfeatures, meaning nobody could have predicted how things would
 > work out.

More like surgical scars than warts, as I see 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] RFC: PEP 540 version 3 (Add a new UTF-8 mode)

[Stephen J. Turnbull]

INADA Naoki writes:

 > But it's not a problem, because changing LC_CTYPE from C to C.UTF-8
 > doesn't break anything.  It's broken at start.
 > Use UTF-8 everywhere, anytime is best way to avoid mojibake.

Please stop repeating this; it is invalid as an argument.  Everybody
using Python 3 (which is the only topic for this list) already knows
that use of a common universal encoding -- in practice, UTF-8 -- is
the way forward (and Windows users also know that the Windows API is a
major exception, which proves the rule by being a different *Unicode*
transformation format).  It is not part of this discussion.

The problem is that not everybody does this yet, even today (in fact,
that's the source of the problem on containers, people are using the C
locale, not C.utf-8!), and some of us have to use or interoperate with
systems that don't, even if our own systems do.

If your position really is "Screw them, they're stupid -- let them fix
their broken systems, it's not our problem", I can understand that but
we'll have to agree to disagree.  My position is that we need to

(1) determine if this change actually can cause problems for Python
users on such systems or interoperating with such systems
(2) determine how serious the problems are with the "force UTF-8 in
certain situations" approach vs. the status quo
(3) compare the damage both ways,
(4) if there is a conflict, consider whether a modified proposal would
work as well or better in more circumstances.

I think that is consistent with past Python practice on encoding
issues.
___
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] RFC: PEP 540 version 3 (Add a new UTF-8 mode)

[Oleg Broytman]

On Fri, Jan 13, 2017 at 11:10:44AM +0900, INADA Naoki  
wrote:
> Use UTF-8 everywhere, anytime is best way to avoid mojibake.

   When you're alone in the Universe -- yes, it helps. But if other
people, protocols and data formats use different encodings it doesn't
matter which encoding you use -- you'll have mojibake anyway.

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
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] RFC: PEP 540 version 3 (Add a new UTF-8 mode)

[INADA Naoki]

>>
>> My question is more when A and B encodings are not compatible.
>>
>> Ah yes, date, thank you for the example. Here is my example using
>> LC_TIME locale to format a date and LC_CTYPE to decode a byte string:
>
> Time and messages seem to behave differently - everything I tested
> (including python 2 os.strerror) seems to ignore the LC_MESSAGES
> encoding and use the LC_CTYPE encoding, including resulting in a bunch
> of question marks when it's "C".
> ___

For date command, it only sees LC_TIME.
LC_CTYPE=en_US.UTF-8 LC_TIME=ja_JP.eucjp date shows mojibake.

But it's not a problem, because changing LC_CTYPE from C to C.UTF-8
doesn't break anything.  It's broken at start.
Use UTF-8 everywhere, anytime is best way to avoid mojibake.
___
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] PEP 540: Add a new UTF-8 mode

[INADA Naoki]

On Fri, Jan 13, 2017 at 12:12 AM, Victor Stinner
 wrote:
> 2017-01-12 1:23 GMT+01:00 INADA Naoki :
>> I'm ±0 to surrogateescape by default.  I feel +1 for stdout and -1 for stdin.
>
> The use case is to be able to write a Python 3 program which works
> work UNIX pipes without failing with encoding errors:
> https://www.python.org/dev/peps/pep-0540/#producer-consumer-model-using-pipes
>
> If you want something stricter, there is the UTF-8 Strict mode which
> prevent mojibake everywhere. I'm not sure that the UTF-8 Strict mode
> is really useful. When I implemented it, I quickly understood that
> using strict *everywhere* is just a deadend: it would fail in too many
> places.
> https://www.python.org/dev/peps/pep-0540/#use-the-strict-error-handler-for-operating-system-data
>
> I'm not even sure yet that a Python 3 with stdin using strict is "usable".
>

I want http://bugs.python.org/issue15216 is merged in 3.7.
It allows application select error handler by straightforward API.
So, the problem is "which should be default"?

* Program like `ls` can opt-in surrogateescape.
* Program want to output valid UTF-8 can opt-out surrogateescape.

And I feel former is better, regarding to Python's Zen.
But it's not a strong opinion.

>
>> In output case, surrogateescape is weaker than strict, but it only allows
>> surrgateescaped binary.  If program carefully use surrogateescaped decode,
>> surrogateescape on stdout is safe enough.
>
> What do you mean that "carefully use surrogateescaped decode"?
>
> The rationale for using surrogateescape on stdout is to support this use case:
> https://www.python.org/dev/peps/pep-0540/#list-a-directory-into-stdout

Application which is intended to output surrogateescaped data (filenames) should
use surrogateescape, surely.

But some application is intended to live in UTF-8 world.
For example, think about application reads UTF-8 CSV, and insert it
into database.

When there is CSV encoded by Shift_JIS accidentally, and it is passed to stdin,
error is better than insert it into database silently.

>
>> On the other hand, surrogateescape is very weak for input.  It accepts
>> arbitrary bytes.
>> It should be used carefully.
>
> In my experience with the Python bug tracker, almost nobody
> understands Unicode and locales. For the "Producer-consumer model
> using pipes" use case, encoding issues of Python 3.6 can be a blocker
> issue. Some developers may prefer a different programming language
> which doesn't bother them with Unicode: basicall, *all* other
> programming languages, no?
>

I agree.  Some developer prefer other language (or Python 2) to Python 3,
because of "Unicode by default doesn't fit to POSIX".

Both of "strict by default" and "weak by default" have downside.


>
>> But I agree different encoding handler between stdin/stdout is not beautiful.
>> That's why I'm ±0.
>
> That's why there are two modes: UTF-8 and UTF-8 Strict. But I'm not
> 100% sure yet, on which encodings and error handlers should be used
> ;-) I started to play with my PEP 540 implementation. I already had to
> update the PEP 540 and its implementation for Windows. On Windows,
> os.fsdecode/fsencode now uses surrogatepass, not surrogateescape
> (Python 3.5 uses strict on Windows).
>
> Victor
___
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] How to respond to trolling (Guido van Rossum)

[Guido van Rossum]

AFAIK the term comes from a piece by Andrew Kuchling titled "Python warts".
The topic now has its own wiki page:
https://wiki.python.org/moin/PythonWarts

I believe that most of the warts are not even design missteps -- they are
emergent misfeatures, meaning nobody could have predicted how things would
work out.

On Thu, Jan 12, 2017 at 5:09 PM, Brett Cannon  wrote:

>
>
> On Thu, 12 Jan 2017 at 15:22 Random832  wrote:
>
>> On Thu, Jan 12, 2017, at 17:39, Brett Cannon wrote:
>> > On Wed, 11 Jan 2017 at 20:56 Simon Lovell 
>> wrote:
>> > > I don't know what is meant by some insults having been thrown in.
>> > > Calling truthiness of non boolean data "Ugly" is an insult? It is
>> ugly.
>> >
>> > Now *that *is insulting to me. Once again, you are allowed to disagree
>> > and
>> > say you don't like how truthiness is handled in Python, but you flat-out
>> > stating something is ugly insults all the time and effort that me and
>> the
>> > other core developers have put into Python to try and make it the best
>> > language we can with the constraints we have to work within.
>>
>> Just out of curiosity... in your estimation, what is a "wart", and why
>> is the term "wart" used for it?
>
>
> That term has been used since before I got involved in Python so I don't
> know its history. To me, a "wart" is a design misstep; there were reasons
> at the time for the design but it has not held up as necessarily the best
> decision. So to me "wart" is not as bad as "ugly" as it tacitly
> acknowledges circumstances were quite possibly different back then and
> 20/20 hindsight is not something we have when making a decision. As a
> community we have collectively agreed some things are warts in Python
> because enough people over time have shared the opinion that something was
> a design misstep.
>
>
>> I mean, this is an accepted term that
>> the Python community uses to refer to things, that is not generally
>> regarded to be cause for an accusation of personally insulting anyone,
>> right? I haven't stepped into an alternate universe?
>
>
> You're focusing on the word and not how the word was presented. The fact
> that Simon started his email with a blanket statement basically saying his
> ideas were great and right automatically shows arrogance. And then
> continuing to say that something is ugly matter-of-factly just continued on
> that theme. I can normally mentally insert an "I think" phrase for people
> when they make a blanket statement like that when the rest of the email was
> reasonable, but the posturing of the email as a whole just didn't all for
> that.
>
> We can argue what adjective or noun could have been used forever, but the
> fact that it was delivered as if in judgment over those who put the time
> and effort to make the decision all those years ago doesn't ever feel good
> to the people being judged and ridiculed (and I know this can seem small,
> but as one of the people being judged regularly I can attest that the
> constant ridicule contributes to burnout).
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
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] Things that won't change (proposed PEP)

[Chris Barker - NOAA Federal]

> By saying that "these are things that will not change",

I agree -- these are not exactly " things that will not change" as they are:

"Things that have been discussed (often ad nausium) and considered and
definitively rejected"

And many of them are:

"Part of what makes Python Python"

I think some wordsmithing is in order to make that clear.

-CHB
___
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] Things that won't change (proposed PEP)

[Guido van Rossum]

I've not followed this discussion closely, but I would assume that for most
things on the "will never change" list the explanation is simply that the
cost of changing it while maintaining backward compatibility is too high
compared to the benefit of fixing the problem (regardless of whether it
really is a problem).

People who come in with enthusiastic proposals to fix some pet peeve
usually don't have the experience needed to appreciate the difficulty in
maintaining backwards compatibility. (A really weird disconnect from
reality happens when this is mentioned in the same breath as "please fix
the Python 2 vs. 3 problem". :-)

I would also guess that for things that are actually controversial (meaning
some people hate a feature that other people love), it's much easier to
explain why it's too late to change than it is to provide an objective
argument for why the status quo is better. Often the status quo is not
better per se, it's just better because it's the status quo.

from __future__ import no_colons  # :-)

On Thu, Jan 12, 2017 at 4:57 PM, Erik  wrote:

> On 12/01/17 19:51, Todd wrote:
>
>>
>> On Thu, Jan 12, 2017 at 2:33 PM, Sven R. Kunze > > wrote:
>> First of all, I am anti-censor and pro-change.
>>
>
> There is no "censorship" or "banning thoughts" going on here.  Even with
>> this PEP, people are free to think about and talk about how Python could
>> work differently all they want.  What this PEP does is tell them that
>> certain decisions have been made about how the Python language is going
>> to work, so they should be aware that such talk isn't going to actually
>> result in any changes to the language.
>>
>
> By saying that "these are things that will not change", then you _are_
> sort of banning talk about them (if, as you assert, "such talk isn't going
> to actually result in any changes to the language" then you are saying
> don't waste your breath, we won't even consider your arguments).
>
> I think I get Sven's point. A long time ago, someone probably said "Python
> will never have any sort of type declarations.". But now there is type
> hinting. It's not the same thing, I know, but such a declaration in a PEP
> might have prevented people from even spending time considering hinting.
>
> Instead, if the PEP collected - for each 'frequently' suggested change - a
> summary of the reasons WHY each aspect is designed the way it is (with
> links to archived discussions or whatever) then that IMO that would be a
> good resource to cite in a canned response to such suggestions.
>
> It's not that "these things will never change", it's more of a "you need
> to provide a solid argument why your suggestion is different to, and better
> than, the cited suggestions that have already been rejected".
>
> Probably a lot of work to gather all the references though. But it could
> start out with one or two and grow from there. Add to it as and when people
> bring up the same old stuff next time.
>
> E.
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
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] PEP 540: Add a new UTF-8 mode

[Chris Barker]

On Thu, Jan 12, 2017 at 7:50 AM, Stephen J. Turnbull  wrote:

>  > So I see no downside to using utf-8 when the C locale is defined.
>
> You don't have much incentive to look for one, and I doubt you have
> the experience of the edge cases (if you do, please correct me), so
> that does not surprise me.
>

that's correct. I left out a sentence:

This is a good time for others' with experience with the ugly edge cases to
speak up!

The real challenge is that "output" has three (at least :-) ) use cases:

1) Passing on data the came from input from the same system: Victors' "Unix
pipe style". In that case, if a supposedly ASCII-based system has non ascii
data, most users would want it to get passed through unchanged. They not
likely to expect their python program to enforce their locale (unless it
was a program designed to do that - but then it could be explicit about
things).

2) The program generating data itself: the mentioned "outputting boxes to
the console" example. I think that folks writing these programs should
consider whether they really need non-ascii output -- but if they do do
this -- I"d image most folks would rather see weird characters in the
console than have the program crash.

So these both point to utf-8 (with surrogateescape)

3) A program getting input from a user, or a data file, or..  (like a
filename, etc). This may be a program intended to be able to handle unicode
filenames, etc. (this is my use-case :-) ) -- what should it do when run on
an ASCII-only system?

This is the tough one -- if the C-locale indicated "non configured", then
users would likely want the _something_ written to the FS, rather than a
program crash: so utf-8.

However, if the system really is properly configured to be ASCII only, then
they may want a program to never write non-ascii to the filesystem.
However, ultimately, I think it's up to the application developer, rather
than to Python itself (Or the sysadmin for the OS that it's running on) to
know whether the app is supposed to support non-ascii filenames, etc. i.e.
one should expect that running a unicode-aware app on an ascii-only
filesystem is going to lead to problems anyway.

So I think the "never crash" option is the better one in this imperfect
trade-off.

-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] RFC: PEP 540 version 3 (Add a new UTF-8 mode)

[Oleg Broytman]

On Thu, Jan 12, 2017 at 06:14:58PM -0500, Random832  
wrote:
> On Thu, Jan 12, 2017, at 13:13, Oleg Broytman wrote:
> >Works for me as expected:
> > 
> > $ echo $LC_CTYPE
> > ru_RU.KOI8-R
> > 
> > $ LC_MESSAGES=ru_RU.KOI8-R mc
> > 
> >mc speaks to me in Russian...
> > 
> > $ LC_MESSAGES=C mc
> 
> I meant LC_CTYPE=C. Or, for that matter, UTF-8 etc.

$ LC_CTYPE=C LC_MESSAGES=ru_RU.KOI8-R mc

   Brouhaha! mc tries to talk in Russian but converts Russian texts to
ascii. Everything is "?" :-D

$ echo $LC_CTYPE
ru_RU.UTF-8
$ LC_MESSAGES=ru_RU.UTF-8 mc

   Russian in utf-8, no problem. What did you expect? I think I did it not
the way you wanted.

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
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] Things that won't change (proposed PEP)

[Greg Ewing]

Stephen J. Turnbull wrote:

Greg Ewing writes:



 > FCLAP - Frequent Criticisms Levelled Against Python

It reads better if you don't insist that they be frequent.  (This may
only play in America.)


Criticisms Frequently Levelled Against Python would be
another possibility...

--
Greg

___
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] How to respond to trolling (Guido van Rossum)

[Ethan Furman]

On 01/12/2017 03:21 PM, Random832 wrote:


Just out of curiosity... in your estimation, what is a "wart", and why
is the term "wart" used for it? I mean, this is an accepted term that
the Python community uses to refer to things [...]


I do not see any difference between calling something a "wart" and calling something 
"ugly".

The sticking point in this case is highlighted by your statement, "an accepted term 
*by the Python community*" [emphasis added].

In other words, it is equally offensive for a stranger to come in and start 
branding this or that as warts as it is for that same stranger to come in and 
start declaring this or that as ugly.

--
~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] RFC: PEP 540 version 3 (Add a new UTF-8 mode)

[Random832]

On Thu, Jan 12, 2017, at 13:13, Oleg Broytman wrote:
>Works for me as expected:
> 
> $ echo $LC_CTYPE
> ru_RU.KOI8-R
> 
> $ LC_MESSAGES=ru_RU.KOI8-R mc
> 
>mc speaks to me in Russian...
> 
> $ LC_MESSAGES=C mc

I meant LC_CTYPE=C. Or, for that matter, UTF-8 etc.
___
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] RFC: PEP 540 version 3 (Add a new UTF-8 mode)

[Terry Reedy]

On 1/12/2017 12:10 PM, Victor Stinner wrote:


Ah yes, date, thank you for the example. Here is my example using
LC_TIME locale to format a date and LC_CTYPE to decode a byte string:

date.py:
---
import locale, time
locale.setlocale(locale.LC_ALL, "")
b = time.strftime("%a")
encoding=locale.getpreferredencoding()
try:
u = b.decode(encoding)
except UnicodeError:
u = ''
else:
u = repr(u)
print("bytes: %r, text: %s, encoding: %r" % (b, u, encoding))


Since b is a string, b.decode is an AttributeError on 3.x.  What am I 
missing?  Was this for 2.x only?


--
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] Things that won't change (proposed PEP)

[Sven R. Kunze]

Good evening to everybody,

On 12.01.2017 03:37, Steven D'Aprano wrote:

I have a proposal for an Informational PEP that lists things which will

not change in Python. If accepted, it could be linked to from the signup

page for the mailing list, and be the one obvious place to point

newcomers to if they propose the same old cliches.



Thoughts?



Let me first express my general thoughts on this topic.

First of all, I am anti-censor and pro-change.

So you can imagine that I am not overly excited to see such a document 
form for Python in general. If it's just to prevent spam on this mailing 
list and to reduce the signal/noise ratio here, I tend to agree with you 
if this document were to be attached to this mailing list only.


I don't think Python as the umbrella term for a language, an ecosystem, 
etc. will benefit from preventing change and from banning thoughts no 
matter how strange they may seem first and to some people.



Alright, after that's sorted out, I took my time to go through the list 
below in case the document will be accepted or made official in any form.
So, please find my comment inserted there and some general thoughts at 
the very end.




PEP: XXX

Title: Things that won't change in Python


This a very absolute-sounding title. Maybe inserting a "(most likely)" 
between "that" and "won't" will give it the right nudge.




Version: $Revision$

Last-Modified: $Date$

Author: Steven D'Aprano 

Status: Draft

Type: Informational

Content-Type: text/x-rst

Created: 11-Jan-2017

Post-History: 12-Jan-2017





Abstract





This PEP documents things which will not change in future versions of Python.


Same "(most likely)" here.







Rationale

=



This PEP hopes to reduce the noise on `Python-Ideas 
`_

and other mailing lists.  If you have a proposal for future Python

development, and it requires changing one of the things listed here, it

is dead in the water and has **no chance of being accepted**, either because

the benefit is too little, the cost of changing the language (including

backwards compatibility) is too high, or simply because it goes against

the design preferred by the BDFL.



Many of these things are already listed in the `FAQs 
`_.

You should be familiar with both Python and the FAQs before proposing

changes to the language.



Just because something is not listed here does not necessarily mean that

it will be changed.  Each proposal will be weighed on its merits, costs

compared to benefits.  Sometimes the decision will come down to a matter

of subjective taste, in which case the BDFL has the final say.



I like these paragraphs.





Language Direction

==



Python 3





This shouldn't need saying, but Python 3 will not be abandoned.




Don't think this section is necessary. It's more like a project 
management decision not a real change.





Python 2.8

--



There will be `no official Python 2.8 
`_ ,

although third parties are welcome to fork the language, backport Python

3 features, and maintain the hybrid themselves.  Just don't call it

"Python 2.8", or any other name which gives the impression that it

is maintained by the official Python core developers.



Same here.


Type checking

-
[...]


Okay.


Syntax

==



Braces

--

[...]


Okay but a bit long. Especially the loophole description plays against 
the intention of the document; which is natural because we talk about 
change here. So, nobody knows; and neither do the authors of this 
document. Not saying, the loophole description should be removed. It's a 
perfect summary of the current situation but shifts the focus of the 
document and dilutes its core message.



Colons after statements that introduce a block

--



[...]


Okay.


End statements

--

[...]


Okay.


Explicit self

-

[...]


Okay.


Print function

--

[...]


Works for me, although the newbies I know of definitely disagree here. ;-)


Significant indentation

---

[...]


Okay.


Other syntax



[...]


Okay.


Built-in Functions And Types



Strings

---


[...]


Okay.


Bools

-

[...]


Okay.


Built-in functions

--



Python is an object-oriented language, but it is not *purely*

object-oriented. Not everything needs to be `a method of some object  
`_,

and functions have their advantages.  See the

`FAQ 
`_

for more detail.


This is about questioning built-in functions in general, right? 

Re: [Python-ideas] OS related file operations (copy, move, delete, rename...) should be placed into one module

[Todd]

On Thu, Jan 12, 2017 at 11:17 AM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:

> I agree that this has been a bit of a wart for a long time.
>
> While the old “let’s treat strings as paths” modules are split up like you
> said, pathlib can do what they do and more: https://docs.python.org/
> 3/library/pathlib.html
>
>
> Exactly -- this is The Solution. It combines paths themselves with things
> you are likely to do with paths.
>
> It may well lack some nice features. If so, suggestions for that would be
> the way to go.
>

Can such suggestions go here or should someone start a new thread?
___
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] Things that won't change (proposed PEP)

[Todd]

On Wed, Jan 11, 2017 at 9:37 PM, Steven D'Aprano 
wrote:

> I have a proposal for an Informational PEP that lists things which will
>
> not change in Python. If accepted, it could be linked to from the signup
>
> page for the mailing list, and be the one obvious place to point
>
> newcomers to if they propose the same old cliches.
>
>
>
> Thoughts?
>
>
>
>
>
>
>
>
>
> * * * * * * * * * *
>
>
>
>
>
> PEP: XXX
>
> Title: Things that won't change in Python
>
> Version: $Revision$
>
> Last-Modified: $Date$
>
> Author: Steven D'Aprano 
>
> Status: Draft
>
> Type: Informational
>
> Content-Type: text/x-rst
>
> Created: 11-Jan-2017
>
> Post-History: 12-Jan-2017
>
>
>
>
>
> Abstract
>
> 
>
>
>
> This PEP documents things which will not change in future versions of
> Python.
>
>
>
>
>
> Rationale
>
> =
>
>
>
> This PEP hopes to reduce the noise on `Python-Ideas <
> https://mail.python.org/mailman/listinfo/python-ideas>`_
>
> and other mailing lists.  If you have a proposal for future Python
>
> development, and it requires changing one of the things listed here, it
>
> is dead in the water and has **no chance of being accepted**, either
> because
>
> the benefit is too little, the cost of changing the language (including
>
> backwards compatibility) is too high, or simply because it goes against
>
> the design preferred by the BDFL.
>
>
>
> Many of these things are already listed in the `FAQs <
> https://docs.python.org/3/faq/design.html>`_.
>
> You should be familiar with both Python and the FAQs before proposing
>
> changes to the language.
>
>
>
> Just because something is not listed here does not necessarily mean that
>
> it will be changed.  Each proposal will be weighed on its merits, costs
>
> compared to benefits.  Sometimes the decision will come down to a matter
>
> of subjective taste, in which case the BDFL has the final say.
>
>
>
>
>
> Language Direction
>
> ==
>
>
>
> Python 3
>
> 
>
>
>
> This shouldn't need saying, but Python 3 will not be abandoned.
>
>
>
>
>
> Python 2.8
>
> --
>
>
>
> There will be `no official Python 2.8  peps/pep-0404/>`_ ,
>
> although third parties are welcome to fork the language, backport Python
>
> 3 features, and maintain the hybrid themselves.  Just don't call it
>
> "Python 2.8", or any other name which gives the impression that it
>
> is maintained by the official Python core developers.
>
>
>
>
>
> Type checking
>
> -
>
>
>
> Duck-typing remains a fundamental part of Python and `type checking <
> https://www.python.org/dev/peps/pep-0484/#non-goals>`_
>
> will not be mandatory.  Even if the Python interpreter someday gains a
>
> built-in type checker, it will remain optional.
>
>
>
>
>
> Syntax
>
> ==
>
>
>
> Braces
>
> --
>
>
>
> It doesn't matter whether optional or mandatory, whether spelled ``{ }``
>
> like in C, or ``BEGIN END`` like in Pascal, braces to delimit code blocks
>
> are not going to happen.
>
>
>
> For another perspective on this, try running ``from __future__ import
> braces``
>
> at the interactive interpreter.
>
>
>
> (There is a *tiny* loophole here: multi-statement lambda, or Ruby-like code
>
> blocks have not been ruled out.  Such a feature may require some sort of
>
> block delimiter -- but it won't be braces, as they clash with the syntax
>
> for dicts and sets.)
>
>
>
>
>
> Colons after statements that introduce a block
>
> --
>
>
>
> Statements which introduce a code block, such as ``class``, ``def``, or
>
> ``if``, require a colon.  Colons have been found to increase readability.
>
> See the `FAQ  colons-required-for-the-if-while-def-class-statements>`_
>
> for more detail.
>
>
>
>
>
> End statements
>
> --
>
>
>
> Python does not use ``END`` statements following blocks.  Given significant
>
> indentation, they are redundant and add noise to the source code.  If you
>
> really want end markers, use a comment ``# end``.
>
>
>
>
>
> Explicit self
>
> -
>
>
>
> Explicit ``self`` is a feature, not a bug.  See the
>
> `FAQ  be-used-explicitly-in-method-definitions-and-calls>`_
>
> for more detail.
>
>
>
>
>
> Print function
>
> --
>
>
>
> The ``print`` statement in Python 1 and 2 was a mistake that Guido long
>
> regretted.  Now that it has been corrected in Python 3, it will not be
>
> reverted back to a statement.  See `PEP 3105  peps/pep-3105/>`_
>
> for more details.
>
>
>
>
>
> Significant indentation
>
> ---
>
>
>
> `Significant indentation  faq/design.html#why-does-python-use-indentation-for-grouping-of-statements
> >`_
>
> is a core feature of Python.
>
>
>
>
>
> Other syntax
>
> 
>
>
>
> Python will not use ``$`` as 

Re: [Python-ideas] RFC: PEP 540 version 3 (Add a new UTF-8 mode)

[Oleg Broytman]

On Thu, Jan 12, 2017 at 06:10:35PM +0100, Victor Stinner 
 wrote:
> 2017-01-12 17:10 GMT+01:00 Oleg Broytman :
> >> Does it work to use a locale with encoding A for LC_CTYPE and a locale
> >> with encoding B for LC_MESSAGES (and others)? Is there a risk of
> >
> >It does when B is a subset of A (ascii and koi8; ascii and utf8, e.g.)
> 
> My question is more when A and B encodings are not compatible.
[skip time example]
> Well, since we are talking about the POSIX locale which usually uses
> ASCII, it shouldn't be an issue in practice for the PEP 538. I was
> just curious :-)

   Of course you get mojibake. You can get mojibake even with compatible
encodings:

$ echo $LC_CTYPE
ru_RU.KOI8-R
$ LC_TIME=ru_RU.UTF-8 date
п╖я┌ я▐п╫п╡ 12 20:14:08 MSK 2017
^ mojibake!

$ echo $LC_CTYPE
ru_RU.UTF-8
$ LC_TIME=ru_RU.KOI8-R date
?? ??? 12 20:15:20 MSK 2017
^^ mojibake!

> Victor

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
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] Settable defaulting to decimal instead of float

[Chris Barker - NOAA Federal]

While I think some variation of:

from __optional__ import decimal_literal

Might be reasonable, I'd probably rather see something like:

X = 1.1D

However: (thank you Chris and Stephen) --

Decimal is NOT a panacea, nor any more "accurate" than binary floating point.

It is still floating point, it is still imprecise, it still can't
represent all rational numbers, even within a range.

The ONLY advantage is that it gives people the warm and fuzzies
because they are used to being able to represent 1/10 exactly, while
not representing 1/3 exactly. But 1/10 is only special BECAUSE of
Decimal representation itself.

I actually think that the Decimal docs over-sell its usefulness.

For instance, it really isn't more suitable for money than binary
floating point if you round your outputs.

Decimal does provide variable precision, which does help. With a 64
bit float, you lose cent precision around a trillion dollars. But
that's a precision issue, not a binary vs Decimal issue. And a
float128 would work fine for more money than I'll ever have to deal
with!

If you really want to do money right, you should use a money type that
is exact and follows the appropriate accounting rules for rounding.
Probably fixed point.

(There are a couple money packages on pypi -- no idea if they are any good)

In short:

I'm wary of the idea that most people would be better off with
Decimal. It's really a special purpose type, and I think it's better
if the issues with floating point precision make themselves obvious
sooner than later.

-CHB

Sorry for the top-post -- I hate this phone email client

Sent from my iPhone

> On Jan 12, 2017, at 7:49 AM, Paul Moore  wrote:
>
>> On 12 January 2017 at 15:34, Victor Stinner  wrote:
>> 2017-01-12 13:13 GMT+01:00 Stephan Houben :
>>> Something like:
>>> from __syntax__ import decimal_literal
>>
>> IMHO you can already implement that with a third party library, see for 
>> example:
>> https://github.com/lihaoyi/macropy
>>
>> It also reminds me my PEP 511 which would open the gate for any kind
>> of Python preprocessor :-)
>> https://www.python.org/dev/peps/pep-0511/
>
> PEP 302 (import hooks) pretty much did that years ago :-) Just write
> your own processor to translate a new filetype into bytecode, and
> register it as an import hook. There was a web framework that did that
> for templates not long after PEP 302 got implemented (can't recall the
> name any more).
>
> 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] Things that won't change (proposed PEP)

[Mark E. Haase]

I don't think an informational PEP would make threads like Python Review
shorter and/or more productive. The OP clearly didn't do much research, so
it seems unlikely he would read an informational PEP. Moreover, the
bikeshedding about what goes into this PEP will inevitably lead to a troll
who isn't satisfied with the explanation of a particular item, or notices
that a particular item isn't included in the PEP, and then we're right back
to the same problem: litigating Python complaints that have already been
discussed many times on this list.

We can't change everybody on the internet, but we might be able to change
our own behavior.
In that spirit, maybe we just need a canned reply that can be used when a
thread has indicators of low quality:

> Hi, this appears to be your first post to python-ideas. This purpose of
this list is to discuss speculative language ideas for Python. If an idea
gains traction, it can then be discussed and honed into a detailed
proposal. Your post does not fit with the purpose of the list, either
because it is too broad or because it doesn't contain enough technical
details about your proposal. You may wish to improve your proposal by
focusing on a single subject, researching historical conversations on that
subject, and adding more technical details. Alternatively, you may wish to
post on python-list[1] instead, which is a general purpose list that does
not have the same constraints as this list.
>
> As a reminder to other list users, please do not encourage low-quality
posts by engaging with them.
>
> 1. https://mail.python.org/mailman/listinfo/python-list

Stack Overflow does something similar, where they have canned responses to
low-quality questions. This makes it easy for the community to
self-moderate in a respectful manner.


On Thu, Jan 12, 2017 at 11:16 AM, Eric Fahlgren 
wrote:

>
>
> On Wed, Jan 11, 2017 at 8:28 PM, Chris Barker 
> wrote:
>
>> Many of the things people (newbies, mostly) complain about are simply
>> taste, or legacy that isn't worth changing.
>>
>
> ​A lot of that sort of thing is idiomatic, so I point people here and say
> "just do it that way and you'll be happier in the long run."​
>
> ​http://stupidpythonideas.blogspot.com/2015/05/why-
> following-idioms-matters.html
>
>
> ___
> 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] OS related file operations (copy, move, delete, rename...) should be placed into one module

[Chris Barker - NOAA Federal]

I agree that this has been a bit of a wart for a long time.

While the old “let’s treat strings as paths” modules are split up like you
said, pathlib can do what they do and more:
https://docs.python.org/3/library/pathlib.html


Exactly -- this is The Solution. It combines paths themselves with things
you are likely to do with paths.

It may well lack some nice features. If so, suggestions for that would be
the way to go.

The usefulness of pathlib has been hampered by the fact that path objects
couldn't be used in many stdlib functions. However, that has been remedied
in 3.6:


   - A new file system path protocol
    has been
   implemented to support path-like objects
   . All
   standard library functions operating on paths have been updated to work
   with the new protocol.

So we have a nice way forward.

-CHB




It’s also prettier and easier to use, especially when using autocompletion
(just type “path.is” and see what you can test the path for)

Best, Philipp

George Fischhof  schrieb am Do., 12. Jan. 2017 um
10:06 Uhr:

> Hi There,
>
> OS related file operations (copy, move, delete, rename...) should be
> placed into one module...
> As it quite confusing that they are in two moduls (os and shutil).
>
> I have read that one is higher level than other, but actually to use them
> I have to think which function can be found in which module.
>
> It is confuse for beginners, and makes the usage more complex instead of
> make it more simple (as Zen of Python says ;-) )
>
> An alias could good, not to cause incompatibility.
>
> Best regards,
> George
> ___
> 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 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] Things that won't change (proposed PEP)

[Eric Fahlgren]

On Wed, Jan 11, 2017 at 8:28 PM, Chris Barker  wrote:

> Many of the things people (newbies, mostly) complain about are simply
> taste, or legacy that isn't worth changing.
>

​A lot of that sort of thing is idiomatic, so I point people here and say
"just do it that way and you'll be happier in the long run."​

​
http://stupidpythonideas.blogspot.com/2015/05/why-following-idioms-matters.html
___
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] RFC: PEP 540 version 3 (Add a new UTF-8 mode)

[Oleg Broytman]

On Thu, Jan 12, 2017 at 04:25:56PM +0100, Victor Stinner 
 wrote:
> 2017-01-12 9:45 GMT+01:00 INADA Naoki :
> > When using en_US.UTF-8 as fallback, pleas override only LC_CTYPE,
> > instead of LC_ALL.
> > As I described in other thread, LC_COLLATE may cause unintentional 
> > performance
> > regression and behavior changes.
> 
> Does it work to use a locale with encoding A for LC_CTYPE and a locale
> with encoding B for LC_MESSAGES (and others)? Is there a risk of

   It does when B is a subset of A (ascii and koi8; ascii and utf8, e.g.)

> mojibake? Or do we expect that the POSIX locale speaks ASCII, and so
> it should work for use UTF-8 for LC_CTYPE since UTF-8 is able to
> decode messages encoded ASCII?

   That works for me:

$ echo $LC_CTYPE
ru_RU.UTF-8
$ echo $LC_COLLATE
ru_RU.UTF-8
$ echo $LANG
C
$ date
Thu Jan 12 19:06:13 MSK 2017

> Victor

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
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] RFC: PEP 540 version 3 (Add a new UTF-8 mode)

[Victor Stinner]

2017-01-12 9:45 GMT+01:00 INADA Naoki :
> When using en_US.UTF-8 as fallback, pleas override only LC_CTYPE,
> instead of LC_ALL.
> As I described in other thread, LC_COLLATE may cause unintentional performance
> regression and behavior changes.

Does it work to use a locale with encoding A for LC_CTYPE and a locale
with encoding B for LC_MESSAGES (and others)? Is there a risk of
mojibake? Or do we expect that the POSIX locale speaks ASCII, and so
it should work for use UTF-8 for LC_CTYPE since UTF-8 is able to
decode messages encoded ASCII?

Victor
___
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] PEP 540: Add a new UTF-8 mode

[Stephen J. Turnbull]

Chris Barker writes:

 > 2) There are non-ascii file names, etc. on this supposedly ASCII system. In
 > which case, do folks expect their Python programs to find these issues and
 > raise errors? They may well expect that their Python program will not let
 > them try to save a non ASCII filename, for instance.

Actually, IME, just like you, they expect it to DTRT, which for *them*
is to save it in Shift-JIS or Alternativj or UTF-totally-whacked as
their other programs do.

 > So I see no downside to using utf-8 when the C locale is defined.

You don't have much incentive to look for one, and I doubt you have
the experience of the edge cases (if you do, please correct me), so
that does not surprise me.

I'm not saying there are such cases here, I just want a little time to
look harder.

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] Settable defaulting to decimal instead of float

[Paul Moore]

On 12 January 2017 at 15:34, Victor Stinner  wrote:
> 2017-01-12 13:13 GMT+01:00 Stephan Houben :
>> Something like:
>> from __syntax__ import decimal_literal
>
> IMHO you can already implement that with a third party library, see for 
> example:
> https://github.com/lihaoyi/macropy
>
> It also reminds me my PEP 511 which would open the gate for any kind
> of Python preprocessor :-)
> https://www.python.org/dev/peps/pep-0511/

PEP 302 (import hooks) pretty much did that years ago :-) Just write
your own processor to translate a new filetype into bytecode, and
register it as an import hook. There was a web framework that did that
for templates not long after PEP 302 got implemented (can't recall the
name any more).

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/

Re: [Python-ideas] PEP 540: Add a new UTF-8 mode

[Stephen J. Turnbull]

Stephan Houben writes:

 > I think this may be a minor concern ultimately, but it would be
 > nice if we had some API to at least reliable answer the question
 > "can I safely output non-ASCII myself?"

You can't; stdout might be a TTY, pipe, or socket in which case you
have no way to determine that.

___
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] Things that won't change (proposed PEP)

[Stephen J. Turnbull]

Greg Ewing writes:
 > Chris Barker wrote:
 > > Frequently Asked Criticisms
 > 
 > Doesn't quite make sense -- one doesn't "ask" criticisms.
 > 
 > How about:
 > 
 > FCLAP - Frequent Criticisms Levelled Against Python

It reads better if you don't insist that they be frequent.  (This may
only play in America.)

___
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] PEP 540: Add a new UTF-8 mode

[Victor Stinner]

2017-01-12 1:23 GMT+01:00 INADA Naoki :
> I'm ±0 to surrogateescape by default.  I feel +1 for stdout and -1 for stdin.

The use case is to be able to write a Python 3 program which works
work UNIX pipes without failing with encoding errors:
https://www.python.org/dev/peps/pep-0540/#producer-consumer-model-using-pipes

If you want something stricter, there is the UTF-8 Strict mode which
prevent mojibake everywhere. I'm not sure that the UTF-8 Strict mode
is really useful. When I implemented it, I quickly understood that
using strict *everywhere* is just a deadend: it would fail in too many
places.
https://www.python.org/dev/peps/pep-0540/#use-the-strict-error-handler-for-operating-system-data

I'm not even sure yet that a Python 3 with stdin using strict is "usable".


> In output case, surrogateescape is weaker than strict, but it only allows
> surrgateescaped binary.  If program carefully use surrogateescaped decode,
> surrogateescape on stdout is safe enough.

What do you mean that "carefully use surrogateescaped decode"?

The rationale for using surrogateescape on stdout is to support this use case:
https://www.python.org/dev/peps/pep-0540/#list-a-directory-into-stdout


> On the other hand, surrogateescape is very weak for input.  It accepts
> arbitrary bytes.
> It should be used carefully.

In my experience with the Python bug tracker, almost nobody
understands Unicode and locales. For the "Producer-consumer model
using pipes" use case, encoding issues of Python 3.6 can be a blocker
issue. Some developers may prefer a different programming language
which doesn't bother them with Unicode: basicall, *all* other
programming languages, no?


> But I agree different encoding handler between stdin/stdout is not beautiful.
> That's why I'm ±0.

That's why there are two modes: UTF-8 and UTF-8 Strict. But I'm not
100% sure yet, on which encodings and error handlers should be used
;-) I started to play with my PEP 540 implementation. I already had to
update the PEP 540 and its implementation for Windows. On Windows,
os.fsdecode/fsencode now uses surrogatepass, not surrogateescape
(Python 3.5 uses strict on Windows).

Victor
___
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] Settable defaulting to decimal instead of float

[Terry Reedy]

On 1/12/2017 8:09 AM, George Fischhof wrote:


And if it is mentioned, I would like to ask why binary floating point is
"better". It is faster, I agree, but why "better"?


Binary numbers are more evenly spread out.  Consider successive two 
diget numbers .99, 1.0, 1.1.  The difference betweem the first two is 
.01 and that between the next pair is .1, 10 times as large.  This 
remains true for .999, 1.00, 1.01 or any other fixed number of digits. 
For binary floats, the gap size only doubles.  When I used slide rules, 
which have about 3 digits of accuracy, some decades ago, this defect of 
decimal numbers was readily apparent.


--
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] Settable defaulting to decimal instead of float

[Chris Angelico]

On Fri, Jan 13, 2017 at 12:09 AM, George Fischhof  wrote:
> from __future__  import use_decimal_instead_of_float
> or any other import would be very good.
> The most important thing in my point of view is that I do not want to
> convert every variable every time to decimal.
> Accuracy is important for me (yes, 0.1 + 0.2 should equal to 0.3 , no more,
> no less ;-) )
>
> And if it is mentioned, I would like to ask why binary floating point is
> "better". It is faster, I agree, but why "better"?
>
> Actually I create test automation (I am a senior QA eng), the fastest test
> case runs for about 1-2 minutes. I do not know the exact time difference
> between binary and decimal arithmetic, but I do not care with this. My test
> would run some microseconds faster. It does not matter at a minute range.
>
> In the tests I calculate with numbers with 4 decimal digits, and I need
> exact match. ;-)
>
> Actually I have a new colleague, they did image analysis, and the calculated
> much calculations, and they used a library (not python) that is accurate as
> well. Becasue accuracy was more important for them as well.

Sounds like you want integer arithmetic. When you're working with
something that goes to a known number of decimal places (eg money),
it's often easiest and safest to redefine your unit (eg cents rather
than dollars, or millimeters instead of meters) so you can use
integers everywhere. Accurate AND fast!

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/

Re: [Python-ideas] Settable defaulting to decimal instead of float

[Chris Angelico]

On Thu, Jan 12, 2017 at 11:50 PM, Stephan Houben  wrote:
> 2017-01-12 13:17 GMT+01:00 Chris Angelico :
>>
>> Most of the time one of my students talks to me about decimal vs
>> binary, they're thinking that a decimal literal (or converting the
>> default non-integer literal to be decimal) is a panacea to the "0.1 +
>> 0.2 != 0.3" problem.
>
>
> Indeed. Decimal also doesn't solve the
> 1/3
> issue.
>
> I don't understand why people always talk about Decimal,
> if you want math to work "right" you probably want fractions.
>
> (With the understanding that this is for still limited value of "right".)

My usual go-to response is that if you want perfect arithmetic with no
rounding errors, your *ONLY* option is symbolic math, where sqrt(8)
returns 2√2. It's pretty obvious that this gets unwieldy really fast,
and rounding errors are a fact of life :) Rationals have their own
problems (eg it's nearly impossible to eyeball them for size once they
get big), and still don't solve everything else.

>> Perhaps the real solution is a written-up
>> explanation of why binary floating point is actually a good thing, and
>> not just a backward-compatibility requirement?
>
>
> I have sometimes considered writing up "Why the aliens of Epsilon Eridani,
> whose computers use 13-valued logic, still use floating point numbers
> with base 2."
>
> (Short overview: analysis form first principles shows that the base should
> be:
> 1. an integral number > 1 and
> 2. as small as possible (to minmax the relative rounding error))
>
> The list of candidate bases satisfying these criteria is: 2.
>

That's exactly the sort of thing I'm talking about. Among other
things, only binary floating point guarantees that x <= (x+y)/2 <= y
for any x <= y. (At least, I think only binary - I know decimal can't
ensure that, and I haven't tested everything in between.) You're way
more an expert on this than I am - my skill consists of reading what
other people have written and echoing it to people :)

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/

Re: [Python-ideas] Settable defaulting to decimal instead of float

[George Fischhof]

2017-01-12 13:13 GMT+01:00 Stephan Houben :

> Something like:
>
> from __syntax__ import decimal_literal
>
> which would feed the rest of the file through the "decimal_literal"
> transpiler.
> (and not influence anything in other files).
>
> Not sure if you would want to support multiple transpilers per file.
>
> Note that Racket has something similar with their initial "#lang ..."
> directive.
> That only allows a single "language". Possibly wisely so.
>
> Stephan
>
>
> 2017-01-12 12:59 GMT+01:00 אלעזר :
>
>> I think such proposals are special cases of a general theme: a compiler
>> pragma, similar to "from __future__", to make Python support
>> domain-specific syntax in the current file. Whether it's decimal literals
>> or matrix/vector literals etc.
>>
>> I think it will be nice to make some tool, external to Python, that will
>> allow defining such "sibling languages" (transpiled into Python) easily and
>> uniformly.
>>
>> Elazar
>>
>> בתאריך יום ה׳, 12 בינו' 2017, 13:21, מאת Paul Moore ‏> >:
>>
>>> On 12 January 2017 at 10:28, Victor Stinner 
>>> wrote:
>>> > George requested this feature on the bug tracker:
>>> > http://bugs.python.org/issue29223
>>> >
>>> > George was asked to start a discusson on this list. I posted the
>>> > following comment before closing the issue:
>>> >
>>> > You are not the first one to propose the idea.
>>>
>>> OK, but without additional detail (for example, how would the proposed
>>> flag work, if the main module imports module A, then would float
>>> literals in A be decimal or binary? Both could be what the user wants)
>>> it's hard to comment. And as you say, most of this has been discussed
>>> before, so I'd like to see references back to the previous discussions
>>> in any proposal, with explanations of how the new proposal addresses
>>> the objections raised previously.
>>>
>>> Paul
>>
>>

Most of the time one of my students talks to me about decimal vs
> binary, they're thinking that a decimal literal (or converting the
> default non-integer literal to be decimal) is a panacea to the "0.1 +
> 0.2 != 0.3" problem. Perhaps the real solution is a written-up
> explanation of why binary floating point is actually a good thing, and
> not just a backward-compatibility requirement?
>
> ChrisA




from __future__  import use_decimal_instead_of_float
or any other import would be very good.
The most important thing in my point of view is that I do not want to
convert every variable every time to decimal.
Accuracy is important for me (yes, 0.1 + 0.2 should equal to 0.3 , no more,
no less ;-) )

And if it is mentioned, I would like to ask why binary floating point is
"better". It is faster, I agree, but why "better"?

Actually I create test automation (I am a senior QA eng), the fastest test
case runs for about 1-2 minutes. I do not know the exact time difference
between binary and decimal arithmetic, but I do not care with this. My test
would run some microseconds faster. It does not matter at a minute range.

In the tests I calculate with numbers with 4 decimal digits, and I need
exact match. ;-)

Actually I have a new colleague, they did image analysis, and the
calculated much calculations, and they used a library (not python) that is
accurate as well. Becasue accuracy was more important for them as well.

BR
George
___
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] Settable defaulting to decimal instead of float

[Stephan Houben]

Hi Chris,

2017-01-12 13:17 GMT+01:00 Chris Angelico :
>
> Most of the time one of my students talks to me about decimal vs
> binary, they're thinking that a decimal literal (or converting the
> default non-integer literal to be decimal) is a panacea to the "0.1 +
> 0.2 != 0.3" problem.


Indeed. Decimal also doesn't solve the
1/3
issue.

I don't understand why people always talk about Decimal,
if you want math to work "right" you probably want fractions.

(With the understanding that this is for still limited value of "right".)


> Perhaps the real solution is a written-up
> explanation of why binary floating point is actually a good thing, and
> not just a backward-compatibility requirement?
>

I have sometimes considered writing up "Why the aliens of Epsilon Eridani,
whose computers use 13-valued logic, still use floating point numbers
with base 2."

(Short overview: analysis form first principles shows that the base should
be:
1. an integral number > 1 and
2. as small as possible (to minmax the relative rounding error))

The list of candidate bases satisfying these criteria is: 2.

Stephan


>
> 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 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] PEP 540: Add a new UTF-8 mode

[Stephan Houben]

Hi Petr,

2017-01-11 12:22 GMT+01:00 Petr Viktorin :
>
> For example, this may mean that a built-in Python string sort will give you
>> a different ordering than invoking the external "sort" command.
>> I have been bitten by this kind of issues, leading to spurious "diffs" if
>> you try to use sorting to put strings into a canonical order.
>>
>
> AFAIK, this would not be a problem under PEP 538, which effectively treats
> the "C" locale as "C.UTF-8". Strings of Unicode codepoints and the
> corresponding UTF-8-encoded bytes sort the same way.
>

...and this is also something new I learned.


>
> Is that wrong, or do you have a better example of trouble with using
> "C.UTF-8" instead of "C"?



After long deliberation, it seems I cannot find any source of trouble. +1

So my feeling is that people are ultimately not being helped by
>> Python trying to be "nice", since they will be bitten by locale issues
>> anyway. IMHO ultimately better to educate them to configure the locale.
>> (I realise that people may reasonably disagree with this assessment ;-) )
>>
>> I would then recommend to set to en_US.UTF-8, which is slower and
>> less elegant but at least more widely supported.
>>
>
> What about the spurious diffs you'd get when switching from "C" to
> "en_US.UTF-8"?
>

That taught me to explicitly invoke "sort" using
LANG=en_US.UTF-8 sort


>
> I believe the main problem is that the "C" locale really means two very
> different things:
>
> a) Text is encoded as 7-bit ASCII; higher codepoints are an error
> b) No encoding was specified
>
> In both cases, treating "C" as "C.UTF-8" is not bad:
> a) For 7-bit "text", there's no real difference between these locales
> b) UTF-8 is a much better default than ASCII
>
>
A "C" locale also means that a program should not *output* non-ASCII
characters,
unless when explicitly being fed in (like in the case of "cat" or "sort" or
the "ls" equivalent from PEP-540).

So for example, a program might want to print fancy Unicode box characters
to show
progress, and check sys.stderr.encoding to see if it can do so.
However, under a "C" locale it should not do so since for example the
terminal
is unlikely to display the fancy box characters properly.

Note that the current PEP 540 proposal would be that sys.stderr is in UTF-8
/backslashreplace encoding
under the "C" locale.

I think this may be a minor concern ultimately, but it would be nice if we
had some API to
at least reliable answer the question "can I safely output non-ASCII
myself?"

Stephan
___
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] OS related file operations (copy, move, delete, rename...) should be placed into one module

[Philipp A.]

Hi George,

While the old “let’s treat strings as paths” modules are split up like you
said, pathlib can do what they do and more:
https://docs.python.org/3/library/pathlib.html

It’s also prettier and easier to use, especially when using autocompletion
(just type “path.is” and see what you can test the path for)

Best, Philipp

George Fischhof  schrieb am Do., 12. Jan. 2017 um
10:06 Uhr:

> Hi There,
>
> OS related file operations (copy, move, delete, rename...) should be
> placed into one module...
> As it quite confusing that they are in two moduls (os and shutil).
>
> I have read that one is higher level than other, but actually to use them
> I have to think which function can be found in which module.
>
> It is confuse for beginners, and makes the usage more complex instead of
> make it more simple (as Zen of Python says ;-) )
>
> An alias could good, not to cause incompatibility.
>
> Best regards,
> George
> ___
> 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] Settable defaulting to decimal instead of float

[Chris Angelico]

On Thu, Jan 12, 2017 at 11:07 PM, Nick Coghlan  wrote:
> As far as I know the main barrier to that approach is simply the lack
> of folks with the time, interest, and expertise needed to implement,
> review, and document it, rather than it being an objectionable
> proposal at the language design level. (There would be some concerns
> around potential confusion between when to use the default binary
> literals and when to use the decimal literals, but those concerns
> arise anyway - the discrepancies between binary and decimal arithmetic
> are just one of those unfortunate facts of computing at this point)

Most of the time one of my students talks to me about decimal vs
binary, they're thinking that a decimal literal (or converting the
default non-integer literal to be decimal) is a panacea to the "0.1 +
0.2 != 0.3" problem. Perhaps the real solution is a written-up
explanation of why binary floating point is actually a good thing, and
not just a backward-compatibility requirement?

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/

Re: [Python-ideas] Settable defaulting to decimal instead of float

[Nick Coghlan]

On 12 January 2017 at 20:30, Paul Moore  wrote:
> It's unlikely that there's a practical suggestion here that hasn't
> been discussed before and rejected

There's one practical decimal-literal-related suggestion which hasn't
been rejected yet: adding a true decimal literal based on decimal128
semantics *without* configurable context support (so compile time
constant folding can work normally rather than all operations needing
to be deferred to runtime).

Folks that wanted to fiddle with the context settings would still need
to use decimal.Decimal objects, but there'd also be a readily
available builtin base10 counterpart to the binary "float" type.

As far as I know the main barrier to that approach is simply the lack
of folks with the time, interest, and expertise needed to implement,
review, and document it, rather than it being an objectionable
proposal at the language design level. (There would be some concerns
around potential confusion between when to use the default binary
literals and when to use the decimal literals, but those concerns
arise anyway - the discrepancies between binary and decimal arithmetic
are just one of those unfortunate facts of computing at this point)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] Settable defaulting to decimal instead of float

[אלעזר]

I think such proposals are special cases of a general theme: a compiler
pragma, similar to "from __future__", to make Python support
domain-specific syntax in the current file. Whether it's decimal literals
or matrix/vector literals etc.

I think it will be nice to make some tool, external to Python, that will
allow defining such "sibling languages" (transpiled into Python) easily and
uniformly.

Elazar

בתאריך יום ה׳, 12 בינו' 2017, 13:21, מאת Paul Moore ‏:

> On 12 January 2017 at 10:28, Victor Stinner 
> wrote:
> > George requested this feature on the bug tracker:
> > http://bugs.python.org/issue29223
> >
> > George was asked to start a discusson on this list. I posted the
> > following comment before closing the issue:
> >
> > You are not the first one to propose the idea.
>
> OK, but without additional detail (for example, how would the proposed
> flag work, if the main module imports module A, then would float
> literals in A be decimal or binary? Both could be what the user wants)
> it's hard to comment. And as you say, most of this has been discussed
> before, so I'd like to see references back to the previous discussions
> in any proposal, with explanations of how the new proposal addresses
> the objections raised previously.
>
> 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] RFC: PEP 540 version 3 (Add a new UTF-8 mode)

[Nick Coghlan]

On 12 January 2017 at 18:45, INADA Naoki  wrote:
>> Thanks Victor, I really like this version, and the next time I update
>> PEP 538 I'm going to replace the en_US.UTF-8 fallback in the current
>> proposal with a dependency on this PEP.
>
> When using en_US.UTF-8 as fallback, pleas override only LC_CTYPE,
> instead of LC_ALL.

Yep, "LC_CTYPE=en_US.UTF-8" is what the current version of PEP 538 has
as a fallback if neither C.UTF-8 nor C.utf8 is available.

However, that's also the part of PEP 538 that I think can just be
dropped entirely and replaced with PEP 540's "assume UTF-8" behaviour
instead.

I was already considering that as an option when I last updated the
PEP (see https://www.python.org/dev/peps/pep-0538/#relationship-with-other-peps
), and now that Victor actually has a working reference implementation
for the PEP 540 approach, I think it's the right way to go.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] Settable defaulting to decimal instead of float

[Paul Moore]

On 12 January 2017 at 10:28, Victor Stinner  wrote:
> George requested this feature on the bug tracker:
> http://bugs.python.org/issue29223
>
> George was asked to start a discusson on this list. I posted the
> following comment before closing the issue:
>
> You are not the first one to propose the idea.

OK, but without additional detail (for example, how would the proposed
flag work, if the main module imports module A, then would float
literals in A be decimal or binary? Both could be what the user wants)
it's hard to comment. And as you say, most of this has been discussed
before, so I'd like to see references back to the previous discussions
in any proposal, with explanations of how the new proposal addresses
the objections raised previously.

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/

Re: [Python-ideas] Settable defaulting to decimal instead of float

[M.-A. Lemburg]

On 12.01.2017 10:04, George Fischhof wrote:
> Hi There,
> 
> Settable defaulting to decimal instead of float
> 
> It would be good to be able to use decimal automatically instead of float
> if there is a setting. For example an environment variable or a flag file.
> 
> Where and when accuracy is more important than speed, the user could set
> this flag, and calculate with decimal numbers as learned in the school.
> 
> I think several people would use this function

I don't think having this configurable is a good idea.
Too much code would break as a result and become unusable
for people wanting to use such functionality, so it would
be of limited value.

The above is similar to what we had in Python 2 for enabling
Unicode literals everywhere (the -U option). It was added as
experiment at the time. No one used it due to the massive
breakage it caused in the stdlib.

Why not explicitly code for your use case ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jan 12 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] Settable defaulting to decimal instead of float

[Victor Stinner]

George requested this feature on the bug tracker:
http://bugs.python.org/issue29223

George was asked to start a discusson on this list. I posted the
following comment before closing the issue:

You are not the first one to propose the idea.

2012: "make decimal the default non-integer instead of float?"
https://mail.python.org/pipermail/python-ideas/2012-September/016250.html

2014: "Python Numbers as Human Concept Decimal System"
https://mail.python.org/pipermail/python-ideas/2014-March/026436.html


Related discussions:

2008: "Decimal literal?"
https://mail.python.org/pipermail/python-ideas/2008-December/002379.html

2015: "Python Float Update"
https://mail.python.org/pipermail/python-ideas/2015-June/033787.html

PEP 240 "Adding a Rational Literal to Python".

Victor
___
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] Settable defaulting to decimal instead of float

[George Fischhof]

Hi There,

Settable defaulting to decimal instead of float

It would be good to be able to use decimal automatically instead of float
if there is a setting. For example an environment variable or a flag file.

Where and when accuracy is more important than speed, the user could set
this flag, and calculate with decimal numbers as learned in the school.

I think several people would use this function

Best regards,
George
___
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] Simon's ideas [Was: How to respond to trolling (Guido van Rossum)]

[Guyzmo via Python-ideas]

Hello Simon,

I'm mostly lurking this mailing list and this is my first post, so
hello everybody .

On Thu, Jan 12, 2017 at 12:13:03PM +0800, Simon Lovell wrote:
> I feel I have to respond to this one.

This discussion hasn't much to do on this mailing list and it's only
generating noise. Please, would be kind enough to keep discussing this
on python-list (aka comp.lang.python) where it belongs?

And eventually, once discussion settles on realistic changes that /can/ be
added to python you might want to submit a PEP:

http://legacy.python.org/dev/peps/pep-0001/

To quote the above linked document, I believe this applies to your
situation:

> Asking the Python community first if an idea is original helps prevent
> too much time being spent on something that is guaranteed to be
> rejected based on prior discussions (searching the internet does not
> always do the trick). It also helps to make sure the idea is
> applicable to the entire community and not just the author.

And read 5 times the following part before posting here again:

> Just because an idea sounds good to the author does not mean it will
> work for most people in most areas where Python is used.

Even though I can only believe this is not your intent, in the end it
looks pretty clear that many people, including myself, are being annoyed
by these threads making the signal/noise ratio of this list very low.

As I've read the original mail I knew it would end up in a low
signal/noise ratio discussion because even I wanted to lecture you,
Simon, about languages, grammar and compilers. Instead I killed the
original thread (plonk!), as I find little interest in this discussion,
but it keeps on respawning as some posters are breaking the threads.

So please, be kind and have some netiquette. 

Thank you,

-- 
Bernard `Guyzmo` Pratz
___
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] OS related file operations (copy, move, delete, rename...) should be placed into one module

[George Fischhof]

Hi There,

OS related file operations (copy, move, delete, rename...) should be placed
into one module...
As it quite confusing that they are in two moduls (os and shutil).

I have read that one is higher level than other, but actually to use them I
have to think which function can be found in which module.

It is confuse for beginners, and makes the usage more complex instead of
make it more simple (as Zen of Python says ;-) )

An alias could good, not to cause incompatibility.

Best regards,
George
___
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] Things that won't change (proposed PEP)

[Paul Moore]

On 12 January 2017 at 04:39, Mikhail V  wrote:
> And my first though is about "will not change". Like: never ever change or
> like: will not change in 10 years or 20 years.

Like: "Please don't waste people's time trying to start a discussion
about them". In 10 or 20 years, if opinions have changed, the PEP can
be updated.

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/

Re: [Python-ideas] RFC: PEP 540 version 3 (Add a new UTF-8 mode)

[INADA Naoki]

> Thanks Victor, I really like this version, and the next time I update
> PEP 538 I'm going to replace the en_US.UTF-8 fallback in the current
> proposal with a dependency on this PEP.
>

When using en_US.UTF-8 as fallback, pleas override only LC_CTYPE,
instead of LC_ALL.
As I described in other thread, LC_COLLATE may cause unintentional performance
regression and behavior changes.
___
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] Things that won't change (proposed PEP)

[Greg Ewing]

Chris Barker wrote:

Frequently Asked Criticisms


Doesn't quite make sense -- one doesn't "ask" criticisms.

How about:

FCLAP - Frequent Criticisms Levelled Against Python

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