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@
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.
>> If we chose "Always use UTF-8 for fs encoding", I think
>> PYTHONFSENCODING envvar should be
>> added again. (It should be used from startup: decoding command line
>> argument).
>
> Last time I implemented PYTHONFSENCODING, I had many major issues:
> https://mail.python.org/pipermail/python-de
On Fri, Jan 13, 2017 at 11:40 AM, Stephen J. Turnbull
wrote:
> 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 repeat
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 wi
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
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, mean
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 i
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 -- y
>>
>> 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 p
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
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 w
> 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
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
real
> On Jan 12, 2017, at 2:26 PM, Terry Reedy wrote:
>
>
> Start a new thread for 'Add x to pathlib'.
>
And do take some time to see if a given suggestion has already been
discussed first.
-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://
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
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
On 12/01/17 19:51, Todd wrote:
On Thu, Jan 12, 2017 at 2:33 PM, Sven R. Kunze mailto:srku...@mail.de>> 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
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 m
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
_
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
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, y
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.
On Wed, 11 Jan 2017 at 20:56 Simon Lovell wrote:
> I feel I have to respond to this one.
>
And as list admin I feel I now have to reply to this to help explain why
people reacted the way they have.
>
>
> More than half of what I suggested could have and should be implemented.
>
It's this sort
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.getpr
On 1/12/2017 2:11 PM, Todd wrote:
On Thu, Jan 12, 2017 at 11:17 AM, Chris Barker - NOAA Federal
mailto: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
On 12 January 2017 at 20:09, Todd wrote:
>
> 4. I think either adding a bit more detail about the rationale for the
> decisions,
>
Would be nice. But then someone must tinker with it.
7. I am not sure what "Python will not use ``$`` as syntax." means. Are
> you referring to a particular commo
On 12 January 2017 at 19:33, Sven R. Kunze wrote:
> This a very absolute-sounding title. Maybe inserting a "(most likely)"
> between "that" and "won't" will give it the right nudge.
Well, the whole point of the document is to stop people falsely hoping
that they can "persuade" people to change th
On Thu, Jan 12, 2017 at 2:33 PM, Sven R. Kunze wrote:
> 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
On 1/12/17, Todd wrote:
> 5. "and" and "or" are short-circuiting operations that return one of the
> two values given. They will never be non-short-circuiting and they will
> never coerce returned values to boolean.
This one bring question how deep this PEP could be because we could
show what
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
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.pyth
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 t
Frequently Addressed Criticisms would solve both issues, imo
Alex
On 2017-01-12 12:18 PM, Chris Barker wrote:
> On Wed, Jan 11, 2017 at 10:48 PM, Greg Ewing
> mailto:greg.ew...@canterbury.ac.nz>> wrote:
>
> Chris Barker wrote:
>
> Frequently Asked Criticisms
>
>
> Doesn't quite ma
On Thu, Jan 12, 2017 at 01:04:43PM -0500, Random832
wrote:
> On Thu, Jan 12, 2017, at 12:10, 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 t
On Thu, Jan 12, 2017, at 12:10, 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
On Wed, Jan 11, 2017 at 10:48 PM, Greg Ewing
wrote:
> Chris Barker wrote:
>
>> Frequently Asked Criticisms
>>
>
> Doesn't quite make sense -- one doesn't "ask" criticisms.
>
I know, but I like that you can pronounce it the same a "FAQ"
> FCLAP - Frequent Criticisms Levelled Against Python
Su
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
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, i
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 en
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'
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 thi
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
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
> > regres
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_C
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, f
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 rem
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 tha
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 i
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
2017-01-12 9:45 GMT+01:00 INADA Naoki :
> As I described in other thread, LC_COLLATE may cause unintentional performance
> regression and behavior changes.
Since Python 3 uses mostly text, not bytes, LC_COLLATE should not
really impact Python applications. Locales set by setlocale() are not
inheri
On Thu, Jan 12, 2017, at 06:20, Paul Moore wrote:
> 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
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-consum
Thank You, Terry
George
2017-01-12 14:50 GMT+01:00 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. Co
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
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
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 pana
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 transpile
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. D
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 sort
On 12 January 2017 at 12:07, Nick Coghlan wrote:
> 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 y
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 tes
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 le
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 th
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
seman
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 Pytho
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
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
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 mo
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 f
On 12 January 2017 at 09: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
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 c
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,
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 whic
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
> 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 th
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.pyth
77 matches
Mail list logo
