Re: syntax difference

[Steven D'Aprano]

On Sun, 24 Jun 2018 21:21:57 +0100, Bart wrote:

> I've had half a dozen users

Come back when you've had *half a million users* then we'll take your 
experiences seriously.

https://blog.pythonanywhere.com/67/

https://stackoverflow.blog/2017/09/06/incredible-growth-python/

For a language which does everything wrong, it must be doing something 
right.


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: Quick survey: locals in comprehensions (Python 3 only)

[Ben Finney]

Paul Moore  writes:

> On 24 June 2018 at 06:03, Steven D'Aprano
>  wrote:
> > Given this function:
> >
> > def test():
> > a = 1
> > b = 2
> > result = [value for key, value in locals().items()]
> > return result
> >
> > what would you expect the result of calling test() to be? […]

> I'm aware of the background for this question. Is there any equivalent
> question that doesn't use locals()? The reason I ask is that I see
> locals() as "digging into implementation stuff" and sort of expect it
> to act oddly in situations like this...

My understanding of Steven's question is to give an unambiguous way to:

* Express the question “which name bindings do you expect to exist in
  this local function scope, by the time of the ‘return’ statement?”.

* Avoid prejudicing the reader to expect any particular binding to be
  active.

One way to do the first, at the cost of losing the second, might be
this::

def test():
a = 1
b = 2
[value for key, value in dict().items()]
print(a)
print(b)
print(key)
print(value)

and then ask “Which of those statements do you expect to fail with
NameError?”.

But I may have misunderstood some nuance of what is being asked, which
is to be expected because Steven was deliberately trying to avoid having
the reader second-guess what the purpose of the code is.

-- 
 \ “I wish there was a knob on the TV to turn up the intelligence. |
  `\  There's a knob called ‘brightness’ but it doesn't work.” |
_o__) —Eugene P. Gallagher |
Ben Finney

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

Re: Anyone here on Python-Dev mailing list?

[Ben Finney]

Steven D'Aprano  writes:

> Anyone on the Python-Dev mailing list, are you getting private emails
> containing nothing but stream of consciousness word-salad from
> somebody (some bot?) calling himself "Chanel Marvin" with a gmail
> address?

I am on that forum (via Gmane), and am not receiving anything like that.

-- 
 \ “Today, I was — no, that wasn't me.” —Steven Wright |
  `\   |
_o__)  |
Ben Finney

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

Re: Package directory question

[Ben Finney]

Robert Latest via Python-list  writes:

> Because the main.py script needs to import the tables.py module from
> backend, I put this at the top if main.py:
>
>sys.path.append('../..')
>import jobwatch.backend.tables as tables
>
> My question is: Is this the way it should be done? It looks fishy. The
> only alternative I could come up with is to put a symlink to tables.py
> into the frontend directory, which also seems fishy.

Your fish-sense is working correctly. Both of those are hard-coding the
path, when the Python import mechanism is designed so you don't do that.

Instead, to run the package, first install the package.

To install the package, use the Pip tool. This comes standard when you
install Python 3.

By installing your code, you make it available to be discovered by
Python's normal import mechanism.

So, choose how you want to install the package:

* To install for normal use, ‘python3 -m pip install …’.

* To install for use only by the current user, add the ‘--user’ option.

* To install for use while also developing, add the ‘--editable’ option.

See the ‘python3 -m pip --help’ document for details about what all that
does.

-- 
 \“Telling pious lies to trusting children is a form of abuse, |
  `\plain and simple.” —Daniel Dennett, 2010-01-12 |
_o__)  |
Ben Finney

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

Re: Quick survey: locals in comprehensions (Python 3 only)

[Paul Moore]

On 24 June 2018 at 06:03, Steven D'Aprano
 wrote:
> I'd like to run a quick survey. There is no right or wrong answer, since
> this is about your EXPECTATIONS, not what Python actually does.
>
> Given this function:
>
>
> def test():
> a = 1
> b = 2
> result = [value for key, value in locals().items()]
> return result
>
> what would you expect the result of calling test() to be? Is that the
> result you think is most useful? In your opinion, is this a useful
> feature, a misfeature, a bug, or "whatever"?
>
> I'm only looking for answers for Python 3. (The results in Python 2 are
> genuinely weird :-)

My immediate reaction was "that's not something I'd want to do, so I
don't care (but I've a feeling it would be weird). On thinking some
more, I decided that [1, 2] made sense (but I still didn't actually
care). After reading Chris Angelico's analysis, I went back to my
first opinion (that I don't care, but I suspect it might be weird).

I'm aware of the background for this question. Is there any equivalent
question that doesn't use locals()? The reason I ask is that I see
locals() as "digging into implementation stuff" and sort of expect it
to act oddly in situations like this...

Paul
-- 
https://mail.python.org/mailman/listinfo/python-list

[ANN] pdfposter 0.7

[Hartmut Goebel]

I'm pleased to announce pdftools.pdfposter 0.7, a tool to scale and
tile PDF images/pages to print on multiple pages.

:Homepage: https://pdfposter.readthedocs.io/
:Author:   Hartmut Goebel 
:Licence:  GNU Public Licence v3 (GPLv3)

:Quick Installation:
    pip install -U pdftools.pdfposter

:Tarballs:  https://pypi.org/project/pdftools.pdfposter/#files


What is pdfposter?


Scale and tile PDF images/pages to print on multiple pages.

``Pdfposter`` can be used to create a large poster by building it from
multiple pages and/or printing it on large media. It expects as input a
PDF file, normally printing on a single page. The output is again a
PDF file, maybe containing multiple pages together building the
poster.
The input page will be scaled to obtain the desired size.

This is much like ``poster`` does for Postscript files, but working
with PDF. Since sometimes poster does not like your files converted
from PDF. :-) Indeed ``pdfposter`` was inspired by ``poster``.

For more information please refer to the manpage or visit
the `project homepage `_.


What's new in version 0.7
---

* Incompatible change: `DIN lang` and `Envelope No. 10` are now defined as
  landscape formats.

* New options ``-f``/``--first`` and ``-l``/``--last`` for specifying the
  first resp. last page to convert

* Reduce the size of the output file a lot. Now the output file is
  nearly the same size as the input file. While this behaviour was
  intended from the beginning, it was not yet implemented for two
  reasons: The content was a) copied for each print-page and b) not
  compressed.

* Make the content of each page appear only once in the output file.
  This vastly reduces the size of the output file.

* Compress page content. Now the output file is nearly the same size
  as the input file in much more cases. I thought, the underlying
  library will do this automatically, but it does not.

* Fix bug in PDF code used for clipping the page content. Many thanks
  to Johannes Brödel for reporting this bug.

* Add support for Python 3.

* Use `PyPFDF2` instead of the unmaintained `pyPDF`.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

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

Re: syntax difference

[Bart]

On 24/06/2018 20:02, Steven D'Aprano wrote:

On Sun, 24 Jun 2018 19:37:33 +0100, Bart wrote:


I want to program in /my/ style


Python is not Java, and Java is not Python either. Nor is it "Bart's
Language", or C, or Forth, or Lisp, or bash.

https://dirtsimple.org/2004/12/python-is-not-java.html

https://dirtsimple.org/2004/12/java-is-not-python-either.html


To get the best out of any language, you should try to program to its
strengths, in the idioms that work, not insist on writing FooLanguage
code in BarLanguage.


I like to write in clear code in a manner that anyone can follow 
(although I'm mainly thinking about myself). That means not using idioms 
specific to a language and hard to translate to anything else.


Why might someone want to use something like Python rather than, for 
example, C? Here are some reasons:


* Clearer syntax less full of punctuation
* Simpler for-loops
* Module import system
* Much faster edit-run cycle
* Dynamic types to eliminate most variable declarations
* No need for forward declarations for functions
* First class string handling
* First class list handling
* Flexible arrays/lists (not strings as they are immutable)
* Namespaces
* Default and keyword parameters
* Can forget about using pointers

That would be plenty to get started with, and enough to make it 
worthwhile to use the dynamic language provided its libraries and its 
performance are suitable for the task.


But so far it has not been necessary to explicitly use a Pythonic style 
of coding or any of its esoteric features.



You'd probably be pretty frustrated if one of your users (ahem) insisted
on duplicating the form and structure of their bash scripts in your
language, and complaining bitterly about how your language sucks because
it isn't bash.


I've had half a dozen users and I don't recall any particular problems 
nor any complaints. The language, although cruder then, must still have 
been sweeter to use than what was typically available at the time.


--
bart
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Abdur-Rahmaan Janhangeer]

naaa it was not meant to be python ^^

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ


>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: translating foreign data

[Stefan Ram]

  To: Richard Damon
From: r...@zedat.fu-berlin.de (Stefan Ram)

Richard Damon  writes:
>Now, if I have a parser that doesn't use the locale, but some other rule
>base than I just need to provide it with the right rules, which is
>basically just defining the right locale.

  Here's an example C++ program I wrote. It uses the class s
  to provide rules for an ad hoc locale which then is used to
  imbue a temporary string stream which then can parse numbers
  using the thousands separator given by s.

  main.cpp

#include 
#include 
#include 
#include 
#include 

using namespace ::std::literals;

struct s : ::std::numpunct< char >
{ char do_thousands_sep() const override { return ','; }
  ::std::string do_grouping() const override { return "\3"; }};

static double double_value_of( ::std::string const & string ) {
::std::stringstream source { string };
  source.imbue( ::std::locale( source.getloc(), new s ));
  double number; source >> number; return number; }

int main()
{ ::std::cout << double_value_of( "4,800.1"s )<< '\n';
  ::std::cout << double_value_of( "3,334.5e9"s )<< '\n'; }

  transcript

4800.1
3.3345e+012

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: translating foreign data

[Peter J. Holzer]

From: "Peter J. Holzer" 


--b2wbudmypdkmv7il
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2018-06-23 12:11:34 -0400, Richard Damon wrote:
> On 6/23/18 10:05 AM, Peter J. Holzer wrote:
> > On 2018-06-23 08:41:38 -0400, Richard Damon wrote:
> >> Once you open the Locale can of worms, EVERYTHING has a locale, to say
> >> you aren't using a locale is to say you are writing
> >> something unintelligible, as you can thing of the locale as the set of
> >> rules to interpret
> > I don't think that's a useful way to look at it. "Locale" in
> > (non-technical) English means "place" or "site". The idea behind the
> > locale concept is that some conventions (e.g. how to write numbers or
> > how to write strings) depend on the place where the program runs (or
> > maybe where the user is sitting or grew up or maybe where a file was
> > produced).
> >
> > For stuff which doesn't depend on the place (e.g. how a Python program
> > should be parsed), the locale concept doesn't apply.
> >
> The Locale should NOT be the place the computer is running in (at least
> not anymore), but where the data and the user are from (which can be
> different).

Yes, it can be different, but for some *very* common cases (PCs, smartphones
most of the time) it isn't. More imporantly for the concept, when the concept
was developed (in the late 1980's) is was very common (probably more common
than 10 years earlier).

> Do your really mean that when I travel to a place that uses
> . as the thousands separator and , as the decimal separator (instead of
> my normal environment when they are the other way around) all my
> programs should immediately change how they read all my data files and
> how I need to enter data? I hope not.

Sometimes, yes. If you want to work with your colleagues at that place they
might thank you to use the local conventions.

> I want my computer to use the Locale of where "I" came from (not
> current am) to talk to me,

That's why I wrote "or grew up".

> and to be able to set the Locale to interpret data to match the rules
> the person who generated them used to generate them,

And that's why I wrote "where a file was produced".

So many words to repeat what I already wrote ...


> so if they swap . and , compared to me, I can tell the program that.
> Your last parenthetical comment in the first paragraph is my key
> point,

I think it is the weakest point. The locale is useful for interactive use
(input and output) and also for output intended for human users. For parsing
files it is woefully inadequate (also for generating files intended to be
parsed).

> the locale used to read data should match the locale used to generate
> it, and that can easily be different than the locale being used to
> interact with the user.

Which is basically why "locale" is a rather useless concept with files. When I
get a CSV file, I don't want to say "use locale en_US.cp437", because the
location "US" is almost completely irrelevant, the language "English" is
somewhat relevant but much too specific", and the list separator isn't there at
 all. I want to tell it: Decode using CP437, a decimal point, tabs as a list
separator, CRLF as the record separator, no quoting.

> If a program doesn't care about the locale it is running in, like a
> Python compiler, the either it needs to use routines that totally ignore
> the locale or it needs to set the locale to one that matches the rules
> it wants.

The former. Because locales are in general opaque, so you can never be sure
that a given locale will use the rules you want ("C" is the exception, but not
very useful).

hp

--=20
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 

--b2wbudmypdkmv7il
Content-Type: application/pgp-signature; name="signature.asc"

-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAlsujL8ACgkQ8g5IURL+
KF0dVxAAryd5Ew15J/aco4xdLAa+EGzIwFKoPQjIb90C4vbIXCbmrVwVYmbJN/yK
J9AhrnUoyipGbK2IMamCUpCp7XVfkCgnMvGmf8ZFeflwaw5NCJLvv42JqAgl+lUP
I1H/hEz/RoR8NFRWGseXGmTSt6KMwAUJjdDzK5eQru25U0vxTPkGmXLXE8wqmynA
lft/CbsPy374Dda99033UJpG9QDZubmhfnt8j4xuHX0u8ZJmY7LJWGQ+zt06RtP1
RA7m+IxyKRRLlRiVSoS5XslRMKSEGfUhqt+jYjVASE5nOgtPPmQswjpKb3fzTJ13
wVCQJGKTu9mOO7xPwhxms8bKBegxjDbrGF0G8FJYW/ty/brItUkhhtb+Z7Pkj1iq
d4xKRBQmux0tz5/kdFFUkz0u9CpFfB0+pzHGfK1edsAGh+lwzN2KgNcBff6H+5FL
er+FZ1HbicXecq2XgTgpq8UYdHeANQI5yMEPjrCiHG4ybZ9T+bVanayji1vC2xqC
DNZ7cWGTFz5AtSDC1fgRupG6ZX5BK/kZjdQz8Hx0AdgW1i4fKu28/giz6mbB+NnC
XgcyXRjj1Jr3aCThjaZ7bq5dYwLzZKNLRQ3shnJE+Tfm3HfvDjvw5Wqf3lOIkcaQ
Wf40K7bivvEZfdZzy/QkmtHjevVutrMZclj/e3NXPevBTWle6eI=
=W2Ut
-END PGP SIGNATURE-

--b2wbudmypdkmv7il--

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[MRAB]

From: MRAB 

On 2018-06-23 05:16, Chris Angelico wrote:
> On Sat, Jun 23, 2018 at 1:51 PM, Steven D'Aprano
>  wrote:
>> On Wed, 20 Jun 2018 14:18:19 +1000, Chris Angelico wrote:
>>
>>> Ah. Yeah, that would be a plausible feature to add to Python. But in C,
>>> a static variable is basically the same thing as a global variable,
>>> except that its name is scoped to the function. There is only one of it.
>>> What happens in Python? For instance:
>>>
>>> def f():
>>> def g():
>>> static x = 0
>>> x += 1
>>> return x
>>> return g
>>>
>>> Does the static variable exist once for each instance of g()? If so,
>>> it'll behave like a closure variable; if not, it'll behave like a
>>> global. Either way, I'm pretty much certain that people will expect the
>>> other.
>>
>> Yes, but given the normal execution model of Python, only one solution is
>> valid. Since the function g is created fresh each time f is called, each
>> one gets a fresh static x.
>>
>> If you want all the g's to share the same x, you would write:
>>
>> def f():
>> static x = 0
>> def g():
>> x += 1
>> return x
>> return g
>>
>>
>> In this case, every invocation of f shares the same static x, and all the
>> g's refer to that same x, using the ordinary closure mechanism. In the
>> earlier case, each invocation of f creates a brand new g with its own x.
>>
>> Simple and elegant.
>>
>> This could at last get rid of that useful but ugly idiom:
>>
>> def function(real, arguments, len=len, int=int, str=str):
>> ...
>>
>> if we allowed the "static" declaration to access the values from the
>> surrounding scope:
>>
>> def function(real, arguments):
>> static len=len, int=int, str=str
>>
>> But I think nicer than that would be a decorator:
>>
>> @static(len=len, int=int, str=str)
>> def function(real, arguments):
>> ...
>>
>> which adds local variables len, int, str to the function, with the given
>> values, and transforms all the bytecode LOAD_NAME len to LOAD_FAST len
>> (or whatever).
>>
>> (We might need a new bytecode to SET_STATIC.)
>>
>> That would be a nice bytecode hack to prove the usefulness of the concept!
>>
>
> Okay, that makes sense. So in a way, static variables would be like
> closure variables with an invisible outer function. These would be
> roughly equivalent:
>
 > def f():
 >  static x = 0
 >  x += 1
 >  return x
 >
You can already do something similar like this:

def f():
  f.x += 1
  return f.x
f.x = 0

[snip]

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Bart]

  To: Stefan Ram
From: Bart 

On 23/06/2018 14:32, Stefan Ram wrote:
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>> def f():
>> def g():
>> g.x += 1
>> return g.x
>> g.x = 0
>> return g
>
>Or, "for all g to share the same x":
>
>main.py
>
> def f():
>  def g():
>  f.x += 1
>  return f.x
>  return g
> f.x = 0

OK, problem solved: we just use attributes of function objects rather than
locally static variables (I didn't even know that was possible). These
apparently can be created, accessed and modified from anywhere in the program.

The only provisos are that functions with 'static' must be written as nested
functions and the name of the function must be returned via the enclosing
function in some setup code.

The initialising of the static is showed as happening in global space in your
example, but may be possible to move that to the enclosing function. (For
example, when the static data is a local table.)

However, here's a reminder of what the feature looks like implemented properly:

 def g()
 static x = 0
 x += 1
 return x

 print (g())

No set up of g needed. 'static' can be added to any existing function without
changing how its used. And it can be removed without having to dismantled all
the extra machinery.

/And/ the access to x inside g() can be a fast local lookup not an
attribute lookup (unless implemented on top of global variables).

--
bart

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: translating foreign data

[Richard Damon]

From: Richard Damon 

On 6/23/18 11:44 AM, Steven D'Aprano wrote:
> On Sat, 23 Jun 2018 08:12:52 -0400, Richard Damon wrote:
>
>> On 6/23/18 7:46 AM, Steven D'Aprano wrote:
>>> On Sat, 23 Jun 2018 06:26:22 -0400, Richard Damon wrote:
>>>
 If you know the Locale, then you do know what the decimal separator
 is, as that is part of what a locale defines.
>>> A locale defines a set of common cultural conventions. It doesn't
>>> mandate the actual conventions in use in any specific document.
>>>
>>> If I'm in Australia, using the en-AU locale, nevertheless I can
>>> generate a file using , as a decimal separator. Try and stop me :-)
>> yes, you can MIS-use the en-AU locale and write 1,000 to mean the number
>> One, just as you can misuse the language and write cat when you mean a
>> member of the Canine group,
> How about if I write "le chien" or "der Hund" or "╤ⁿD1D▒D░D║D░"? Is that also
a
> misuse of the locale because I choose to write in a foreign language,
> using foreign conventions for spelling, grammar and syntax?
>
>
>> but then the misinterpretation is on the
>> creator of the document, not on the program that was told how the
>> document is to be read.
> You're assuming that there will be a misinterpretation. That's an absurd
> assumption to make. There might be, of course, but the documentation for
> my document might be clear that comma is to be used for decimal
> separators. Or it might include numbers like
>
> 1.234.567,012345678
>
> which is understandable to anyone who is aware of the possibility that
> comma may mean decimal separator and period the thousands separator.
>
Then I shouldn't be using en-AU to decode the file. If I use a locale based
parser, I need to give it the right locale.

Now, if I have a parser that doesn't use the locale, but some other rule base
than I just need to provide it with the right rules, which is basically just
defining the right locale.

--
Richard Damon

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: translating foreign data

[Richard Damon]

From: Richard Damon 

On 6/23/18 10:05 AM, Peter J. Holzer wrote:
> On 2018-06-23 08:41:38 -0400, Richard Damon wrote:
>> On 6/23/18 8:28 AM, Peter J. Holzer wrote:
>>> On 2018-06-23 08:12:52 -0400, Richard Damon wrote:
 On 6/23/18 7:46 AM, Steven D'Aprano wrote:
> If I'm in Australia, using the en-AU locale, nevertheless I can generate
> a file using , as a decimal separator. Try and stop me :-)
 yes, you can MIS-use the en-AU locale and write 1,000 to mean the number
 One, just as you can misuse the language and write cat when you mean a
 member of the Canine group, but then the misinterpretation is on the
 creator of the document, not on the program that was told how the
 document is to be read.
>>> How would he mis-use the en-AU locale to write 1 as "1,000"? I think
>>> to do that he would simply NOT use the locale.
>> Once you open the Locale can of worms, EVERYTHING has a locale, to say
>> you aren't using a locale is to say you are writing
>> something unintelligible, as you can thing of the locale as the set of
>> rules to interpret
> I don't think that's a useful way to look at it. "Locale" in
> (non-technical) English means "place" or "site". The idea behind the
> locale concept is that some conventions (e.g. how to write numbers or
> how to write strings) depend on the place where the program runs (or
> maybe where the user is sitting or grew up or maybe where a file was
> produced).
>
> For stuff which doesn't depend on the place (e.g. how a Python program
> should be parsed), the locale concept doesn't apply.
>
The Locale should NOT be the place the computer is running in (at least not
anymore), but where the data and the user are from (which can be different). Do
 your really mean that when I travel to a place that uses . as the thousands
separator and , as the decimal separator (instead of my normal environment when
 they are the other way around) all my programs should immediately change how
they read all my data files and how I need to enter data? I hope not. I want my
 computer to use the Locale of where "I" came from (not current am) to talk to
me, and to be able to set the Locale to interpret data to match the rules the
person who generated them used to generate them, so if they swap . and ,
compared to me, I can tell the program that. Your last parenthetical comment in
 the first paragraph is my key point, the locale used to read data should match
 the locale used to generate it, and that can easily be different than the
locale being used to interact with the user.

If a program doesn't care about the locale it is running in, like a Python
compiler, the either it needs to use routines that totally ignore the locale or
 it needs to set the locale to one that matches the rules it wants.

--
Richard Damon

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: translating foreign data

[Peter J. Holzer]

From: "Peter J. Holzer" 


--ngg56dmsr6vcxzs5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2018-06-23 12:41:33 -0400, Richard Damon wrote:
> On 6/23/18 11:44 AM, Steven D'Aprano wrote:
> > You're assuming that there will be a misinterpretation. That's an absur=
d=20
> > assumption to make. There might be, of course, but the documentation fo=
r=20
> > my document might be clear that comma is to be used for decimal=20
> > separators. Or it might include numbers like
> >
> > 1.234.567,012345678
> >
> > which is understandable to anyone who is aware of the possibility that=
=20
> > comma may mean decimal separator and period the thousands separator.
> >
> Then I shouldn't be using en-AU to decode the file.

Quite right, You shouldn't.

> Now, if I have a parser that doesn't use the locale, but some other rule
> base than I just need to provide it with the right rules, which is
> basically just defining the right locale.

Nope. The right rules for almost any file format are much more than the locale.

hp

--=20
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 

--ngg56dmsr6vcxzs5
Content-Type: application/pgp-signature; name="signature.asc"

-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAlsujY4ACgkQ8g5IURL+
KF1J7Q/+K7QhbxqE/4Q1jiCCFrU2OezQMwBAD7WXX60rk5gUzB2ubmz/X5VkUxVl
E9dwfQTIYzfT2e3rCif75jxjWEi1i8J6diNSJdl4SZWrLOngCLtxKC/Ns9JB54wG
NBUPwKwVMO+dYkXmiGz0RTQGfnQEqaPeHsWRj5uKLc7iFFQFHvSznasIUnhwRhLF
/DDzEQW7tFM0eLJ8XKCydL0BInbXNMdhnQ9WSo/N287Fio2dbVpgjVd4bVBaMhJR
5UrrP3Nim9ZWsvN0uRk75lgRzQhID/unxCC3d6J54+83ma4nNpOoBOMyHcaeU9d0
pSSE5LOeQB3QwUKOBo7kzvcxm/abK+qwaZ9D54ex170DY5O54FWrmeo/3kEU+xMX
BGXvn4DSfK4f6OcDExSWd6N0W1B5fxXxHqDiaDGPsDvlXT3Jc3OSD79FYc1LEh7z
6TAOy3VgOVmbF7M5DnSNPzEn2OTCGkIANf5C7zVS7GX/izki8H1Rk654yuhoZlBj
F0ixIQb2mSxsiJnOyYUT8dTFuQYhXcbgRWUM24oTUb51QEdD3DragY+J5Fai+WJH
QAZS4ryWjiQfvKtzhGYuAExHFA9IPpUS+qT2tLSpqY8sboow/jLt6oAzf8MNUl7j
CB+A2jxMgrvGjfgCOPkP4Ruwix1jJ62O6AvSePOmQxta+svmydQ=
=nEaJ
-END PGP SIGNATURE-

--ngg56dmsr6vcxzs5--

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Rick Johnson]

From: Rick Johnson 

On Sunday, May 20, 2018 at 5:29:11 PM UTC-5, Mikhail V wrote:

> What against PDF?

I'm not a big fan of PDF either. Adobe Reader is one the most bloated POS
software i have ever had the misfortune of hosting on my computers, and i
absolutely refuse to host that crapware any longer. And while there are smaller
 more sane PDF viewers and editors, i find the whole experience of PDF to be
annoying.

I would suggest sticking with HTML or raw text. Every computer worth its salt
has a web browser, but not every computer needs (yet another) special purpose
document format (PUKE!). And I refuse to participate in the propagation of the
PDF file format.

> Anyway, I have reloaded files with most recent corrections in various
formats:
>
> PDF
> https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf
>
> TXT
> https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.txt
>
> HTML(direct preview link)
> http://htmlpreview.github.io/?https://raw.githubusercontent.com/Mikhail22/Doc
uments/master/data-blocks-v01.html

Thanks for providing the last two "sane" formats.

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: translating foreign data

[Dennis Lee Bieber]

From: Dennis Lee Bieber 

On Sat, 23 Jun 2018 15:44:14 + (UTC), Steven D'Aprano
 declaimed the following:

>1.234.567,012345678
>
>which is understandable to anyone who is aware of the possibility that
>comma may mean decimal separator and period the thousands separator.
>
Or it is an oddly marked local (7-digit) telephone number (though
typically for US, a leading "1" implies long-distance and should be followed by
 a 10-digit phone number) followed by a 9-digit (US) postal zip-code.



--
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: translating foreign data

[Steven D'Aprano]

From: Steven D'Aprano 

On Sat, 23 Jun 2018 08:12:52 -0400, Richard Damon wrote:

> On 6/23/18 7:46 AM, Steven D'Aprano wrote:
>> On Sat, 23 Jun 2018 06:26:22 -0400, Richard Damon wrote:
>>
>>> If you know the Locale, then you do know what the decimal separator
>>> is, as that is part of what a locale defines.
>> A locale defines a set of common cultural conventions. It doesn't
>> mandate the actual conventions in use in any specific document.
>>
>> If I'm in Australia, using the en-AU locale, nevertheless I can
>> generate a file using , as a decimal separator. Try and stop me :-)
>
> yes, you can MIS-use the en-AU locale and write 1,000 to mean the number
> One, just as you can misuse the language and write cat when you mean a
> member of the Canine group,

How about if I write "le chien" or "der Hund" or "╤ⁿD1D▒D░D║D░"? Is that also a
 misuse of the locale because I choose to write in a foreign language, using
foreign conventions for spelling, grammar and syntax?


> but then the misinterpretation is on the
> creator of the document, not on the program that was told how the
> document is to be read.

You're assuming that there will be a misinterpretation. That's an absurd
assumption to make. There might be, of course, but the documentation for my
document might be clear that comma is to be used for decimal separators. Or it
might include numbers like

1.234.567,012345678

which is understandable to anyone who is aware of the possibility that comma
may mean decimal separator and period the thousands separator.




--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing it everywhere."
 -- Jon Ronson

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: translating foreign data

[Steven D'Aprano]

From: Steven D'Aprano 

On Sat, 23 Jun 2018 09:42:29 -0400, Richard Damon wrote:

> On 6/23/18 9:05 AM, Marko Rauhamaa wrote:

>> Ok. Here's a value for you:
>>
>> 100ΓΘ¼
>>
>> I see '1', '0', '0', 'ΓΘ¼'. What do you see in your locale (LC_MONETARY)?
>
> If I processed that on my system I would either get $100, or an error of
> wrong currency symbol depending on the error checking.

Then your system is so unbelievably broken that it should be nuked from orbit,
just to be sure.

The data you were given was 100 Euros. If your system is incapable of reading
that as 100 Euros, and errors out, then at least to know that it is
brain-damaged and useless.

But if instead it silently changes the data to $100 (US dollars? Australian
dollars? Zimbabwe dollars? the gods only know what a system that broken might
do...) then it is not only broken but *dangerously* broken.



[...]
> Locale predates UCS-2, it was the early attempt to provide
> internationalization to C code so even programmers who didn't think
> about it could add the line setlocale(LC_ALL, "") and make their code
> work at least mostly right in more places. A single global was quick and
> simple, and since threads didn't exist, not an issue.

Threads were first used in 1967, five years before C even existed.

https://en.wikipedia.org/wiki/Thread_%28computing%29#History




--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing it everywhere."
 -- Jon Ronson

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Abdur-Rahmaan Janhangeer]

From: Abdur-Rahmaan Janhangeer 

the tab separated idea is used in :

e.g. see last section of files

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ


>
>

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: translating foreign data

[Peter J. Holzer]

From: "Peter J. Holzer" 


--p4u6dkqn7e5fhtwt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2018-06-23 08:41:38 -0400, Richard Damon wrote:
> On 6/23/18 8:28 AM, Peter J. Holzer wrote:
> > On 2018-06-23 08:12:52 -0400, Richard Damon wrote:
> >> On 6/23/18 7:46 AM, Steven D'Aprano wrote:
> >>> If I'm in Australia, using the en-AU locale, nevertheless I can gener=
ate=20
> >>> a file using , as a decimal separator. Try and stop me :-)
> >> yes, you can MIS-use the en-AU locale and write 1,000 to mean the numb=
er
> >> One, just as you can misuse the language and write cat when you mean a
> >> member of the Canine group, but then the misinterpretation is on the
> >> creator of the document, not on the program that was told how the
> >> document is to be read.
> > How would he mis-use the en-AU locale to write 1 as "1,000"? I think
> > to do that he would simply NOT use the locale.
> Once you open the Locale can of worms, EVERYTHING has a locale, to say
> you aren't using a locale is to say you are writing
> something unintelligible, as you can thing of the locale as the set of
> rules to interpret

I don't think that's a useful way to look at it. "Locale" in (non-technical)
English means "place" or "site". The idea behind the locale concept is that
some conventions (e.g. how to write numbers or how to write strings) depend on
the place where the program runs (or maybe where the user is sitting or grew up
 or maybe where a file was produced).

For stuff which doesn't depend on the place (e.g. how a Python program should
be parsed), the locale concept doesn't apply.


> > You two also seem to be writing about different things when you write
> > "THE locale". Steven seems to mean the global settings a user has
> > chosen, you seem to mean the specidic settings appropriate for parsing a
> > specific file.

While I was writing this paragraph I realized that I had also used "the locale"
 in a specific meaning in the previous paragraph. I decided to let it stand and
 see whether anyone would call me out it.

> You have THE locale for a given piece of data.

Well, you didn't. Even though I quite obviously used "the locale" in Steven's
meaning, you didn't react to that at all and just continue as if your
definition is the only possible one.

hp

--=20
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 

--p4u6dkqn7e5fhtwt
Content-Type: application/pgp-signature; name="signature.asc"

-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAlsuU7kACgkQ8g5IURL+
KF308BAAkxEOzzNfnaRez6RwpTWGI7CbWb5HK8B8mmn+AoAo788Cj+yQYE0CEUbG
HBM0UPtc44ZqSrvIcyXlmL6xjUzkuPOYUZbtxVunWQm3NLgaViHf3b+1uSqsapYT
jqQo+LbQiENqPrroSjqWmOKpo3B5T9m7howPuvGMCBRV7B/CriOnVwYjrolo02JL
gcdcLPPyN4tGHhWFvMN6xycLS5m/bC4do8yRz/GPzRT/IoEI4gmKbk/10pzEK7iH
s3V+P74uznvR8B4PxCPNCWiI9LJD61K+u1qhdrmg+7XPHHqr/04GiPFZ2JHSthhG
joRP0UdlbTs+esELjUhrN7Xcd+Z1qlA9N86ULXv5QA0YaDCUXNhjOEkLAzOpx9Af
XWcmnVfaHePxhqIKHvo5tsx/eEdLRttiScw11UoAvyNmFHW9oiVZhP0za6GgiiHr
jXNOcC5uDTpisi3TsR8jV/MhBwGc01up6JMkVnCIXArGneZAeTDVocQrp99IDg4z
bGLoSeSafqH0Xxzv+f0UomOrvTlCV011Tst/rn94EkI3SonNq6/0TxLVO5da/Jj+
626iYqQcqk7vzF5cL8umtYDe78oRdycvJcxMmfheORuCiLTWLbYYi+0nHmo3q35F
/bfsla74h5ysvuJAyNLNCBoamziZvK/b35j9CQzLLN86QQNntdI=
=HQTI
-END PGP SIGNATURE-

--p4u6dkqn7e5fhtwt--

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: translating foreign data

[Peter J. Holzer]

From: "Peter J. Holzer" 


--jbhqoow7s7225t6e
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2018-06-23 16:05:49 +0200, Peter J. Holzer wrote:
> I don't think that's a useful way to look at it. "Locale" in
> (non-technical) English means "place" or "site". The idea behind the
> locale concept is that some conventions (e.g. how to write numbers or
> how to write strings) depend on the place where the program runs

Sorry, I meant "how to *sort* strings.

hp

--=20
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 

--jbhqoow7s7225t6e
Content-Type: application/pgp-signature; name="signature.asc"

-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAlsuV/UACgkQ8g5IURL+
KF33DQ//aHNtdu5IitrWXN2+HIiyjN6I2Pepd6Uw59rIItHOTqSbO0quv0SEIYqp
pA/MBmVFVkCnzImOEY4/vP7CbZREnqDoSrjpK0UOTzm8rowi7Ovgr94b1eNYdfCv
B8fJxh4EJ7d852afVb3UM6SMrqJnGk2LZd4Ck0ViCTQg0AFI3BlGSGvvqwLt1tJ5
sN4J1pMR+Y6wlCZ3D7ElF/qEwnJTdSllteNWZA2egAtrvoFP+sk2spb+8PC9KaeU
cvhYILaQLI0Tqqfud6J4qNDGztWN9NtGYnoPcbwG6siXTwMIKniihKcogeGtNA8m
ynn3MES2BuSZ0tnxyCtdQcmN4bRkrtWM+2DALs6dnRizRgmH2WAn+PWb1t609oXV
9uegyyloaOtUDNwLkhMI0+W7VmE7yraUYpvXqOZIeNK+Aorbh0rsDtEcQyxc4TwJ
oPfW4ExQyV75d9n+IiFerDj/lKNQN5nIWrBzCf4ue29sxfAuABdDBudrgQ6HMM3K
w4kmUgzfvKqk+srnmFeMG+aCmglsUvZKQvzb+7W+yRx6zQkie/uzjFS5j4r8pOP/
Kk43L2oH3OMjZMBkky6WoRZkKMKexD7MfEpS1UaISkat2NQYeVIyal7Er9k3s4ZV
VXO/G77ac+qysAr2PPJXxrtVRcX/7/s2/p/P3bNxElUqk/oqE6s=
=lwIj
-END PGP SIGNATURE-

--jbhqoow7s7225t6e--

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Stefan Ram]

  To: Steven D'Aprano
From: r...@zedat.fu-berlin.de (Stefan Ram)

Steven D'Aprano  writes:
>def f():
>static x = 0
>def g():
>x += 1
>return x
>return g

  What one can do today:

  main.py

def g():
g.x += 1
return g.x
g.x = 0

print( g() )
print( g() )
print( g() )

  transcript

1
2
3

  main.py

def f():
def g():
g.x += 1
return g.x
g.x = 0
return g

g = f()
print( g() )
print( g() )
print( g() )

  transcript

1
2
3

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Ed Kellett]

From: Ed Kellett 

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Xw5fa1GFtucLPGBT1sLtLtUpmbraGkiYl
Content-Type: multipart/mixed; boundary="lDyl22ZCUIEM3fl5YMnfJ3B8O9bwBCY9r";
 protected-headers="v1"
From: Ed Kellett 
To: python-list@python.org
Message-ID: <98ecd8c1-13b7-8317-8177-6a3592171...@kellett.im>
Subject: Re: Static variables [was Re: syntax difference]
References: <72edc16a-69e0-41a2-bec3-290083f6e...@googlegroups.com>
 
 
 
 <01092eb6-172f-5ee0-91fb-4e3e1df99...@gmail.com>
 
 
 <6eUVC.491716$Qg7.378011@fx08.am4> 
 
 
 
 
 
 
 <2937f981-e2dc-41d6-9d89-373496cb5...@googlegroups.com>
 
 
 
 
 
 
In-Reply-To: 

--lDyl22ZCUIEM3fl5YMnfJ3B8O9bwBCY9r
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 2018-06-23 06:21, Chris Angelico wrote:
> Let's start finding all the edge cases that don't work, so I can work
> on fixing them :)

Very long functions (or, more specifically, functions with a very large number
of consts) will likely prove annoying.


--lDyl22ZCUIEM3fl5YMnfJ3B8O9bwBCY9r--

--Xw5fa1GFtucLPGBT1sLtLtUpmbraGkiYl
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEECzNSP7n340AYaHPmcC7hJ3E8yBAFAlsuRkYACgkQcC7hJ3E8
yBBYbQf/fqEhdZWJoA/1Zq2x9dV0LgDTTAU0T8ze6jjMoq/Wxj/kzovLSgWODD8u
63tJgR9c2twEVdfILiWmgKD1BSzyLGXN/LOEjieFu62tqYVfDJOf6g0/pBzG5Ih3
rsGt9e1tx8S60xUR7pnEtbSrMtKruclUaUQQXnpJG4mHKwaLKgpQDSknTKyHzOec
ulf+iQxWb5v9pG8fwsygdrKYsObKdQJrCUI3ggeDFYkSJK/sDBYitIlpSaHNNaV+
QZQFaf0j9ACLttVIhOJxWxnlxmbbNQ7P5Z4QdznI1y5xUnEIAgNKPTMjjgsb1h5Y
Q8gx7MxYB6+reNHQNl7V2b5UxAWYwQ==
=rmC2
-END PGP SIGNATURE-

--Xw5fa1GFtucLPGBT1sLtLtUpmbraGkiYl--

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: translating foreign data

[Marko Rauhamaa]

  To: Richard Damon
From: Marko Rauhamaa 

Richard Damon :

> On 6/23/18 9:05 AM, Marko Rauhamaa wrote:
>> Richard Damon :
>>
>>> On 6/23/18 8:03 AM, Marko Rauhamaa wrote:
 I always know my locale. The locale is tied to the human user.
>>> No, it should be tied to the data you are processing.
>>In computing, a locale is a set of parameters that defines the user's
>>language, region and any special variant preferences that the user
>>wants to see in their user interface.
>>
>>https://en.wikipedia.org/wiki/Locale_(computer_software)>
>>
>> The data should not depend on the locale.
> So no one foreign ever gives you data?

Never in my decades in computer programming have I found any use for locales.

In particular, they have never helped me decode "foreign" data, whether in
ASCII, Latin-1, Latin-3, Latin-9, JIS or UTF-8.

> Note, that wikipedia article is focused on the SYSTEM locale, which
> yes, that should reflect the what the user wants in his interface.

I don't think locales have anything to do with anything else.


>>> If an English user is feeding a program Chinese documents, while
>>> processing those documents the program should be using the
>>> appropriate Chinese Locale.
>> Not true.
> How else is the program going to understand the Chinese data?

If someone gives me a file, they had better indicate the file format.

> The fact that locale issues leak into data is the reason that the
> single immutable global locale doesn't work.

Locales don't work. Period.

> You really want to imbue into data streams what locale their data
> represents (and use that in some of the later processing of data from
> that stream).

Can you refer to a standard for that kind of imbuement?

Of course, you have document types, schema definitions and other implicit and
explicit format indicators. You shouldn't call them locales, though.

>>> Data presented to the user should normally use his locale (unless he
>>> has specified something different).
>> Ok. Here's a value for you:
>>
>> 100ΓΘ¼
>>
>> I see '1', '0', '0', 'ΓΘ¼'. What do you see in your locale (LC_MONETARY)?
> If I processed that on my system I would either get $100, or an error of
> wrong currency symbol depending on the error checking.

Don't forget to convert the amount as well...

>> The single global is due to what the locale was introduced for. It
>> came about around the time when Unix applications were being made
>> "8-bit clean." Along with UCS-2 and XML, it's one of those things you
>> wish you'd never have to deal with.
>
> Locale predates UCS-2, it was the early attempt to provide
> internationalization to C code so even programmers who didn't think
> about it could add the line setlocale(LC_ALL, "") and make their code
> work at least mostly right in more places. A single global was quick
> and simple, and since threads didn't exist, not an issue.
>
> In many ways it was the first attempt that should have been thrown
> away, but got too intertwined. C++ made a significant improvement to
> it by having streams remember their own locale.

Noone should breathe any new life into locales.

And yes, add C++ to the list of things you wish you'd never have to deal
with...


Marko

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: translating foreign data

[Richard Damon]

From: Richard Damon 

On 6/23/18 9:05 AM, Marko Rauhamaa wrote:
> Richard Damon :
>
>> On 6/23/18 8:03 AM, Marko Rauhamaa wrote:
>>> I always know my locale. The locale is tied to the human user.
>> No, it should be tied to the data you are processing.
>In computing, a locale is a set of parameters that defines the user's
>language, region and any special variant preferences that the user
>wants to see in their user interface.
>
>https://en.wikipedia.org/wiki/Locale_(computer_software)>
>
> The data should not depend on the locale.
So no one foreign ever gives you data? Note, that wikipedia article is focused
on the SYSTEM locale, which yes, that should reflect the what the user wants in
 his interface.
>
>> If an English user is feeding a program Chinese documents, while
>> processing those documents the program should be using the appropriate
>> Chinese Locale.
> Not true.
How else is the program going to understand the Chinese data?
>
>> Again, no, a locale is tied to the data, not the user (unless you want
>> to require the user to translate all data to his locale conventions
>> (without using a program that can use locale information) before
>> providing it to a program. Yes, the default for the interpretation
>> should be the users default/current locale, but you really want them
>> to be able to say I got this file from someone whose locale was
>> different than mine.
> The locale is not directly related to data or data formats. Of course,
> locales leak into data and create the sorry mess we are talking about.
The fact that locale issues leak into data is the reason that the single
immutable global locale doesn't work. You really want to imbue into data
streams what locale their data represents (and use that in some of the later
processing of data from that stream).
>
>> Data presented to the user should normally use his locale (unless he
>> has specified something different).
> Ok. Here's a value for you:
>
> 100ΓΘ¼
>
> I see '1', '0', '0', 'ΓΘ¼'. What do you see in your locale (LC_MONETARY)?
If I processed that on my system I would either get $100, or an error of wrong
currency symbol depending on the error checking.
>
>>> BTW, I think the locale is a terrible invention.
>> The locale is a lot better than the alternative, where every
>> application that needs to deal with internationalization need to
>> recreate (and debub) all of the mechanism. I agree it isn't perfect,
>> and for small simple programs it would be nice to be able to say "I
>> don't want all this stuff, make it go away".
> The locale doesn't solve a single problem in practice and often trips up
> programs. For example, a customer-visible bug was once caused by:
>
>sort 
> producing different results on different customers' machines.
>
> Mental note: *always* prefix GNU textutils commands with LANG=C.
Yes, one issue is that systems currently don't naturally tag data with the
locale to use (you can't even know for sure character set a file is in, so your
 example above might be 100 some funny character(s). It is starting be true
that you can often assume UTF-8 (at least on Linux, on Windows it is much less
so), and validating that it is valid UTF-8 is a pretty good sign that it is.
>
>> Python took its locale (at least initially) from C, which was a single
>> global which does have more issues because of this.
> The single global is due to what the locale was introduced for. It came
> about around the time when Unix applications were being made "8-bit
> clean." Along with UCS-2 and XML, it's one of those things you wish
> you'd never have to deal with.
>
>
> Marko

Locale predates UCS-2, it was the early attempt to provide internationalization
 to C code so even programmers who didn't think about it could add the line
setlocale(LC_ALL, "") and make their code work at least mostly right in more
places. A single global was quick and simple, and since threads didn't exist,
not an issue.

In many ways it was the first attempt that should have been thrown away, but
got too intertwined. C++ made a significant improvement to it by having streams
 remember their own locale.

--
Richard Damon

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: translating foreign data

[Richard Damon]

From: Richard Damon 

On 6/23/18 8:03 AM, Marko Rauhamaa wrote:
> Richard Damon :
>> If you know the Locale, then you do know what the decimal separator
>> is, as that is part of what a locale defines.
> I don't know what that sentence means.
When you set the locale
>
>> The issue is that if you just know the encoding, you don't necessarily
>> know the locale.
> I always know my locale. The locale is tied to the human user.
No, it should be tied to the data you are processing. If an English user is
feeding a program Chinese documents, while processing those documents the
program should be using the appropriate Chinese Locale. When generating output
to the user, it should switch (back) to the appropriate English Locale (likely
the system locale that the user set).
>
>> He also commented that he didn't want to set the locale in the
>> routine, as that sets it globally for the full application (but
>> perhaps that latter could be fixed by first doing a
>> locale.getlocale(), then setlocale for the files locale, and then at
>> the end of reading and processing restore back the old locale.
> Setting a locale application-wise is
>
>  * not in accordance with the idea of a locale (the locale should be
>constant within a user session)
Again, no, a locale is tied to the data, not the user (unless you want to
require the user to translate all data to his locale conventions (without using
 a program that can use locale information) before providing it to a program.
Yes, the default for the interpretation should be the users default/current
locale, but you really want them to be able to say I got this file from someone
 whose locale was different than mine.

Data presented to the user should normally use his locale (unless he has
specified something different).
>
>  * not easily possible (the locale is seen by all threads
>simultaneously)
That is an implementation error. It should be possible to create a thread
specific locale, and it is really useful to create a local locale that can be
used by the various conversion operators to say for this conversion use this
specific locale as that is what this data indicated how it is to be
interpreted.
>
>
> BTW, I think the locale is a terrible invention.
>
>
> Marko

The locale is a lot better than the alternative, where every application that
needs to deal with internationalization need to recreate (and debub) all of the
 mechanism. I agree it isn't perfect, and for small simple programs it would be
 nice to be able to say "I don't want all this stuff, make it go away".

Python took its locale (at least initially) from C, which was a single global
which does have more issues because of this. C++ objectified the locale and
allows the programmer to imbue a specific locale into different parts of his
program (in particular, each I/O Stream knows what locale its data is to be
processed with). Perhaps (maybe it has) it could be good to adopt the object
based locale concept of C++ (but that does come at a significant cost for
things like CPython) where streams know their locale, and other operations can
be optionally passed a locale to use.

--
Richard Damon

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: translating foreign data

[Richard Damon]

From: Richard Damon 

On 6/23/18 7:46 AM, Steven D'Aprano wrote:
> On Sat, 23 Jun 2018 06:26:22 -0400, Richard Damon wrote:
>
>> If you know the Locale, then you do know what the decimal separator is,
>> as that is part of what a locale defines.
> A locale defines a set of common cultural conventions. It doesn't mandate
> the actual conventions in use in any specific document.
>
> If I'm in Australia, using the en-AU locale, nevertheless I can generate
> a file using , as a decimal separator. Try and stop me :-)
yes, you can MIS-use the en-AU locale and write 1,000 to mean the number One,
just as you can misuse the language and write cat when you mean a member of the
 Canine group, but then the misinterpretation is on the creator of the
document, not on the program that was told how the document is to be read.
>
> But your point is taken -- I misread Ethan saying that he knew the locale
> and it wasn't helping, when in fact he was reluctant to change the locale
> as that's a process-wide global change.
>
>> The issue is that if you just
>> know the encoding, you don't necessarily know the locale. He also
>> commented that he didn't want to set the locale in the routine, as that
>> sets it globally for the full application (but perhaps that latter could
>> be fixed by first doing a locale.getlocale(), then setlocale for the
>> files locale, and then at the end of reading and processing restore back
>> the old locale.
> Indeed.
>
>

--
Richard Damon

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Stefan Ram]

  To: Stefan Ram
From: r...@zedat.fu-berlin.de (Stefan Ram)

r...@zedat.fu-berlin.de (Stefan Ram) writes:
>def f():
>def g():
>g.x += 1
>return g.x
>g.x = 0
>return g

  Or, "for all g to share the same x":

  main.py

def f():
def g():
f.x += 1
return f.x
return g
f.x = 0

g = f()
print( g() )
print( g() )
print( g() )

g1 = f()
print( g1() )
print( g1() )
print( g1() )

  transcript

1
2
3
4
5
6

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: translating foreign data

[Steven D'Aprano]

From: Steven D'Aprano 

On Sat, 23 Jun 2018 06:26:22 -0400, Richard Damon wrote:

> If you know the Locale, then you do know what the decimal separator is,
> as that is part of what a locale defines.

A locale defines a set of common cultural conventions. It doesn't mandate the
actual conventions in use in any specific document.

If I'm in Australia, using the en-AU locale, nevertheless I can generate a file
 using , as a decimal separator. Try and stop me :-)

But your point is taken -- I misread Ethan saying that he knew the locale and
it wasn't helping, when in fact he was reluctant to change the locale as that's
 a process-wide global change.

> The issue is that if you just
> know the encoding, you don't necessarily know the locale. He also
> commented that he didn't want to set the locale in the routine, as that
> sets it globally for the full application (but perhaps that latter could
> be fixed by first doing a locale.getlocale(), then setlocale for the
> files locale, and then at the end of reading and processing restore back
> the old locale.

Indeed.


--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing it everywhere."
 -- Jon Ronson

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: translating foreign data

[Marko Rauhamaa]

  To: Richard Damon
From: Marko Rauhamaa 

Richard Damon :

> On 6/23/18 8:03 AM, Marko Rauhamaa wrote:
>> I always know my locale. The locale is tied to the human user.
> No, it should be tied to the data you are processing.

   In computing, a locale is a set of parameters that defines the user's
   language, region and any special variant preferences that the user
   wants to see in their user interface.

   https://en.wikipedia.org/wiki/Locale_(computer_software)>

The data should not depend on the locale.

> If an English user is feeding a program Chinese documents, while
> processing those documents the program should be using the appropriate
> Chinese Locale.

Not true.

> Again, no, a locale is tied to the data, not the user (unless you want
> to require the user to translate all data to his locale conventions
> (without using a program that can use locale information) before
> providing it to a program. Yes, the default for the interpretation
> should be the users default/current locale, but you really want them
> to be able to say I got this file from someone whose locale was
> different than mine.

The locale is not directly related to data or data formats. Of course, locales
leak into data and create the sorry mess we are talking about.

> Data presented to the user should normally use his locale (unless he
> has specified something different).

Ok. Here's a value for you:

100ΓΘ¼

I see '1', '0', '0', 'ΓΘ¼'. What do you see in your locale (LC_MONETARY)?

>> BTW, I think the locale is a terrible invention.
>
> The locale is a lot better than the alternative, where every
> application that needs to deal with internationalization need to
> recreate (and debub) all of the mechanism. I agree it isn't perfect,
> and for small simple programs it would be nice to be able to say "I
> don't want all this stuff, make it go away".

The locale doesn't solve a single problem in practice and often trips up
programs. For example, a customer-visible bug was once caused by:

   sort  Python took its locale (at least initially) from C, which was a single
> global which does have more issues because of this.

The single global is due to what the locale was introduced for. It came about
around the time when Unix applications were being made "8-bit clean." Along
with UCS-2 and XML, it's one of those things you wish you'd never have to deal
with.


Marko

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ironpython not support py3.6

[Peter J. Holzer]

From: "Peter J. Holzer" 


--prnws536gtytpj5v
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2018-06-22 17:20:29 -0700, denis.akhiya...@gmail.com wrote:
> Either wait for IronPython 3.6, use COM interop, pythonnet,
> subprocess, or things like gRPC. Based on PyPy experience, it is
> probably 1-2 years of sponsored development to get a working
> IronPython 3.6.

What is the current state of IronPython 3? The website is very uninformative
(there's a 4 year old blog post saying "we started a repository", but that's
it). The repository gets commits every now and then (so it's obviously not dead
 yet), but neither the readme nor the wiki give a hint beyond "not ready yet".

hp

--=20
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 

--prnws536gtytpj5v
Content-Type: application/pgp-signature; name="signature.asc"

-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAlsuAsMACgkQ8g5IURL+
KF3tZRAArjij8tON0JDZA9HW2eC3hjLEQVR5xk8qvsKOsuLfSZ4vpzF9DyAq+mSy
R+poIBfJwQglBeHs3yMOhxzsynZHD8sdoO6BtdAAZHNlgl8aCAzRQqxxJxOSi9RY
A0VfL1IGt8M7FiT//nttpxGKknSaDVNy37H/fPSertJOD7QIvh7OjOD1wpnfFpg7
JO4B5Q1R4J2HBVwqszcsJgoBJtQLTKg4peZVqyLrKZeF6nr8YyPmtx4pHLGLYTtX
gH1K25dERjWpv0soISd0GI6aCJvr7Pmm6OmxNK8Qw+wB1maDxAkI/tVCs3HZRIsf
q6BW+mWC/WCmNJg+A8QenC8ISp/pBhOaM3WIln0g/FcWEfOOwut9vnQJcyLrFYYW
GXTHhVpJQm5KwcfTTEXh5Czorr6bfIa9IvTOnhZukgRdc0lSDT2JMykmeo97bS9M
rC6GJqk0qVEVw66+M0vbVmaKbzugqH0rsYSGoHiTaAYFyFuq5T+G8etl8phGmpXN
sRw9jRzBj5eoA3toYK4XDRB7hm8JzQjCxJdSjoP3hgmqa7jmozor70pm22nUy8ql
e7ZE9E3cuUyKLe1zAfZ07W8dUo1WcNB9h0zedR53jx29m5W/ouixGZ1VhQN6DcRY
XUYAR66l1Xk4AZxXrKWmYAfxlC2PION/oHykev2nR5sCgFrF1Xw=
=dC9K
-END PGP SIGNATURE-

--prnws536gtytpj5v--

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: translating foreign data

[Richard Damon]

From: Richard Damon 

On 6/23/18 8:28 AM, Peter J. Holzer wrote:
> On 2018-06-23 08:12:52 -0400, Richard Damon wrote:
>> On 6/23/18 7:46 AM, Steven D'Aprano wrote:
>>> On Sat, 23 Jun 2018 06:26:22 -0400, Richard Damon wrote:
 If you know the Locale, then you do know what the decimal separator is,
 as that is part of what a locale defines.
>>> A locale defines a set of common cultural conventions. It doesn't mandate
>>> the actual conventions in use in any specific document.
>>>
>>> If I'm in Australia, using the en-AU locale, nevertheless I can generate
>>> a file using , as a decimal separator. Try and stop me :-)
>> yes, you can MIS-use the en-AU locale and write 1,000 to mean the number
>> One, just as you can misuse the language and write cat when you mean a
>> member of the Canine group, but then the misinterpretation is on the
>> creator of the document, not on the program that was told how the
>> document is to be read.
> How would he mis-use the en-AU locale to write 1 as "1,000"? I think
> to do that he would simply NOT use the locale.
Once you open the Locale can of worms, EVERYTHING has a locale, to say you
aren't using a locale is to say you are writing something unintelligible, as
you can thing of the locale as the set of rules to interpret
>
> I think there are very good reasons to ignore the locale for specific
> purposes. For example, a Python interpreter should not use the locale
> when parsing Python, and a program producing Python should also ignore
> the locale.
Python, like many languages, define the formatting of things, so Python
programs should be interpreted according to the "Python" locale (which may
actually be named "C").
>
> You two also seem to be writing about different things when you write
> "THE locale". Steven seems to mean the global settings a user has
> chosen, you seem to mean the specidic settings appropriate for parsing a
> specific file.
>
> hp
>
You have THE locale for a given piece of data. My point is that Python has
adopted the C method of a single global locale for a program, so in the program
 there is a 'THE Locale' which may actually need to be different when
processing different information, leading to some of the issues.

--
Richard Damon

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ironpython not support py3.6

[wxjmfauth]

  To: Steven D'Aprano
From: wxjmfa...@gmail.com

Le vendredi 22 juin 2018 11:07:15 UTC+2, Steven D'Aprano a ─CcritΓ :
>
> C# <--> IronPython 2.7 <--> CPython 3.6
>

C# <--> IronPython 2.7.

It will not work. Coding of characters ! Try with IronPython 2.7.8.

PS Yes, I know, it is based on .NET !!!

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Bart]

  To: Steven D'Aprano
From: Bart 

On 23/06/2018 04:51, Steven D'Aprano wrote:
> On Wed, 20 Jun 2018 14:18:19 +1000, Chris Angelico wrote:
>
>> Ah. Yeah, that would be a plausible feature to add to Python. But in C,
>> a static variable is basically the same thing as a global variable,
>> except that its name is scoped to the function. There is only one of it.
>> What happens in Python? For instance:
>>
>> def f():
>>  def g():
>>  static x = 0
>>  x += 1
>>  return x
>>  return g
>>
>> Does the static variable exist once for each instance of g()? If so,
>> it'll behave like a closure variable; if not, it'll behave like a
>> global. Either way, I'm pretty much certain that people will expect the
>> other.
>
> Yes, but given the normal execution model of Python, only one solution is
> valid. Since the function g is created fresh each time f is called, each
> one gets a fresh static x.
>
> If you want all the g's to share the same x, you would write:
>
> def f():
>  static x = 0
>  def g():
>  x += 1
>  return x
>  return g
>
>
> In this case, every invocation of f shares the same static x, and all the
> g's refer to that same x, using the ordinary closure mechanism. In the
> earlier case, each invocation of f creates a brand new g with its own x.
>
> Simple and elegant.
>
> This could at last get rid of that useful but ugly idiom:
>
>  def function(real, arguments, len=len, int=int, str=str):
>  ...
>
> if we allowed the "static" declaration to access the values from the
> surrounding scope:
>
>  def function(real, arguments):
>  static len=len, int=int, str=str
>
> But I think nicer than that would be a decorator:
>
>  @static(len=len, int=int, str=str)
>  def function(real, arguments):
>  ...
>
> which adds local variables len, int, str to the function, with the given
> values, and transforms all the bytecode LOAD_NAME len to LOAD_FAST len
> (or whatever).
>
> (We might need a new bytecode to SET_STATIC.)
>
> That would be a nice bytecode hack to prove the usefulness of the concept!

This is an example of a simple concept getting so out of hand that it will
either never be implemented, or the resulting implementation becomes
impractical to use.

This is what we're trying to do:

 def nextx():
 static x = 0
 x += 1
 return x

And this is the simplest equivalent code in current Python that will cater for
99% of uses:

 _nextx_x = 0

 def nextx():
 global _nextx_x
 _nextx_x += 1
 return _nextx_x

No nested functions. No generating new instances of functions complete with a
new set of statics each time you happen to refer to the name. (Which sounds to
me as useful as creating a new instance of an import when you copy its name,
complete with a separate set of its globals. Isn't this stuff what classes are
for?)

(At what point would that happen anyway; if you do this:

 g = nextx  # hypothetical version would static

it will create a new instance of 'nextx'. But it won't create one here, just
before () is applied:

 nextx() # ?

Or how about here:

 listoffunctions = (nextx1, nextx2, nextx3)

 listoffunctions[i]() # ?

)

--
bartc

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Chris Angelico]

From: Chris Angelico 

On Sat, Jun 23, 2018 at 1:51 PM, Steven D'Aprano
 wrote:
> On Wed, 20 Jun 2018 14:18:19 +1000, Chris Angelico wrote:
>
>> Ah. Yeah, that would be a plausible feature to add to Python. But in C,
>> a static variable is basically the same thing as a global variable,
>> except that its name is scoped to the function. There is only one of it.
>> What happens in Python? For instance:
>>
>> def f():
>> def g():
>> static x = 0
>> x += 1
>> return x
>> return g
>>
>> Does the static variable exist once for each instance of g()? If so,
>> it'll behave like a closure variable; if not, it'll behave like a
>> global. Either way, I'm pretty much certain that people will expect the
>> other.
>
> Yes, but given the normal execution model of Python, only one solution is
> valid. Since the function g is created fresh each time f is called, each
> one gets a fresh static x.
>
> If you want all the g's to share the same x, you would write:
>
> def f():
> static x = 0
> def g():
> x += 1
> return x
> return g
>
>
> In this case, every invocation of f shares the same static x, and all the
> g's refer to that same x, using the ordinary closure mechanism. In the
> earlier case, each invocation of f creates a brand new g with its own x.
>
> Simple and elegant.
>
> This could at last get rid of that useful but ugly idiom:
>
> def function(real, arguments, len=len, int=int, str=str):
> ...
>
> if we allowed the "static" declaration to access the values from the
> surrounding scope:
>
> def function(real, arguments):
> static len=len, int=int, str=str
>
> But I think nicer than that would be a decorator:
>
> @static(len=len, int=int, str=str)
> def function(real, arguments):
> ...
>
> which adds local variables len, int, str to the function, with the given
> values, and transforms all the bytecode LOAD_NAME len to LOAD_FAST len
> (or whatever).
>
> (We might need a new bytecode to SET_STATIC.)
>
> That would be a nice bytecode hack to prove the usefulness of the concept!
>

Okay, that makes sense. So in a way, static variables would be like closure
variables with an invisible outer function. These would be roughly equivalent:

def f():
static x = 0
x += 1
return x

def make_f():
x = 0
def f():
nonlocal x
x += 1
return x
return f
f = make_f()

I don't think LOAD_FAST is appropriate (those cells get disposed of when the
function returns), but transforming those lookups into closure lookups would be
 a reasonable way to do it I think.

For getting rid of the "len=len" trick, though, I would REALLY like to
transform those into LOAD_CONST. That'd be a fun bytecode hack all on its own.
In fact, I'm gonna have a shot at that. An "early bind these names" decorator.

ChrisA

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: translating foreign data

[Peter J. Holzer]

From: "Peter J. Holzer" 


--drblskvcly73v23o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2018-06-23 08:12:52 -0400, Richard Damon wrote:
> On 6/23/18 7:46 AM, Steven D'Aprano wrote:
> > On Sat, 23 Jun 2018 06:26:22 -0400, Richard Damon wrote:
> >> If you know the Locale, then you do know what the decimal separator is,
> >> as that is part of what a locale defines.
> > A locale defines a set of common cultural conventions. It doesn't manda=
te=20
> > the actual conventions in use in any specific document.
> >
> > If I'm in Australia, using the en-AU locale, nevertheless I can generat=
e=20
> > a file using , as a decimal separator. Try and stop me :-)
> yes, you can MIS-use the en-AU locale and write 1,000 to mean the number
> One, just as you can misuse the language and write cat when you mean a
> member of the Canine group, but then the misinterpretation is on the
> creator of the document, not on the program that was told how the
> document is to be read.

How would he mis-use the en-AU locale to write 1 as "1,000"? I think to do that
 he would simply NOT use the locale.

I think there are very good reasons to ignore the locale for specific purposes.
 For example, a Python interpreter should not use the locale when parsing
Python, and a program producing Python should also ignore the locale.

You two also seem to be writing about different things when you write "THE
locale". Steven seems to mean the global settings a user has chosen, you seem
to mean the specidic settings appropriate for parsing a specific file.

hp

--=20
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 

--drblskvcly73v23o
Content-Type: application/pgp-signature; name="signature.asc"

-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAlsuPOoACgkQ8g5IURL+
KF3nWw//T34BviAcOezJAU59Fkp7i6gcaTJ4meYOkvvXaipB3QQGIVKZck1T/6VE
UcNJQipftT1/g3Uf4C9VRlrGwe2vq7QbeP220jBEECztmoqCBzpOgaVxOlpiP0gD
YiPDdk69KZYzjtt6kTO6kwAVLRereyYh4kPeq2zrpSe0tmx53jg9RrmztQz9SFtk
kU8klPFb1jzmgG8RLqrcB9FuUrBzfDxEXSsbHEqVqckAT9rYMLUtuqQPPZbi2zkC
ncXXVvBVA061CcYwvnIxfp8jWvAlXwKwC1mv7DFkOtSgnoo85STmWcGryybJsTID
cgCY90hnWfWM6rqLCS9eoeMMYOUItsxu0/uOAhsRMipt4lMI2Ebzhk5Udv87RFme
CmJEcSEHwYD4iB2Zw2BE8DksSyfciNbuWYS7GHiMz/fiO25upVikCoNZEPk1Xu/C
6wJ+H6fsSv4GGdQls25ykyyt73b+OXGvbIr8hp3Mcup/Fn5P0BCc2vZehDxNaC4p
alzqhRLfql2Hhr1TyPdapuxixBuD55PeRYOpKrpZmeQ0/O2m3Zube2Z3CrhPmQvH
JNdI5suWRyV52QVvDQXV/3bUVywehe8C/kmPtWl0FeDaZPjcO/yHOgQK2abGYfAs
t9vAMldEpQmBixh/hOqeGs5y9xLwQgf7liyvAV1ak2gIr9ntgdI=
=XB3R
-END PGP SIGNATURE-

--drblskvcly73v23o--

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: translating foreign data

[Marko Rauhamaa]

  To: Richard Damon
From: Marko Rauhamaa 

Richard Damon :
> If you know the Locale, then you do know what the decimal separator
> is, as that is part of what a locale defines.

I don't know what that sentence means.

> The issue is that if you just know the encoding, you don't necessarily
> know the locale.

I always know my locale. The locale is tied to the human user.

> He also commented that he didn't want to set the locale in the
> routine, as that sets it globally for the full application (but
> perhaps that latter could be fixed by first doing a
> locale.getlocale(), then setlocale for the files locale, and then at
> the end of reading and processing restore back the old locale.

Setting a locale application-wise is

 * not in accordance with the idea of a locale (the locale should be
   constant within a user session)

 * not easily possible (the locale is seen by all threads
   simultaneously)


BTW, I think the locale is a terrible invention.


Marko

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Static variables [was Re: syntax difference]

[Steven D'Aprano]

From: Steven D'Aprano 

On Wed, 20 Jun 2018 14:18:19 +1000, Chris Angelico wrote:

> Ah. Yeah, that would be a plausible feature to add to Python. But in C,
> a static variable is basically the same thing as a global variable,
> except that its name is scoped to the function. There is only one of it.
> What happens in Python? For instance:
>
> def f():
> def g():
> static x = 0
> x += 1
> return x
> return g
>
> Does the static variable exist once for each instance of g()? If so,
> it'll behave like a closure variable; if not, it'll behave like a
> global. Either way, I'm pretty much certain that people will expect the
> other.

Yes, but given the normal execution model of Python, only one solution is
valid. Since the function g is created fresh each time f is called, each one
gets a fresh static x.

If you want all the g's to share the same x, you would write:

def f():
static x = 0
def g():
x += 1
return x
return g


In this case, every invocation of f shares the same static x, and all the g's
refer to that same x, using the ordinary closure mechanism. In the earlier
case, each invocation of f creates a brand new g with its own x.

Simple and elegant.

This could at last get rid of that useful but ugly idiom:

def function(real, arguments, len=len, int=int, str=str):
...

if we allowed the "static" declaration to access the values from the
surrounding scope:

def function(real, arguments):
static len=len, int=int, str=str

But I think nicer than that would be a decorator:

@static(len=len, int=int, str=str)
def function(real, arguments):
...

which adds local variables len, int, str to the function, with the given
values, and transforms all the bytecode LOAD_NAME len to LOAD_FAST len (or
whatever).

(We might need a new bytecode to SET_STATIC.)

That would be a nice bytecode hack to prove the usefulness of the concept!


--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing it everywhere."
 -- Jon Ronson

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: translating foreign data

[Steven D'Aprano]

From: Steven D'Aprano 

On Fri, 22 Jun 2018 20:06:35 +0100, Ben Bacarisse wrote:

> Steven D'Aprano  writes:
>
>> On Fri, 22 Jun 2018 11:14:59 +0100, Ben Bacarisse wrote:
>>
> The code page remark is curious.  Will some "code pages" have digits
> that are not ASCII digits?

 Good question.  I have no idea.
>>>
>>> It's much more of an open question than I thought.
>>
>> Nah, Python already solves that for you:
>
> My understanding was that the OP does not (reliably) know the encoding,
> though that was a guess based on a turn of phrase.

I took it the other way: that Ethan *does* know the encoding, and his problem
is that knowing the encoding and/or locale is not enough to recognise whether
to use a period or comma as the decimal separator.

Which it isn't.

If he doesn't know the encoding, he has bigger problems than just converting
strings into floats. Without knowing the encoding, he cannot even reliably
detect non-ASCII digits at all.


> Another guess is that the OP does not have Unicode data.  The term "code
> page" hints at an 8-bit encoding or at least a pre-Unicode one.

Assuming he is using Python 3, or using Python 2 sensibly, once he has
specified the encoding and read the data from the file, he has Unicode.

Unicode is a superset of (ideally) all code pages. Once you have decoded the
data using the appropriate code page, you have a Unicode string, and Python
doesn't care where it came from.

The point is, once Ethan can get the intended characters out of the file into
Python, it doesn't matter what code page they came from. They're now
full-fledged Unicode characters, and Python's float() and int() functions can
easily deal with non-ASCII digits. So long as he has digits in the first place,
 float() and int() will deal with them correctly.


--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing it everywhere."
 -- Jon Ronson

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: translating foreign data

[Richard Damon]

From: Richard Damon 

On 6/22/18 11:21 PM, Steven D'Aprano wrote:
> On Fri, 22 Jun 2018 20:06:35 +0100, Ben Bacarisse wrote:
>
>> Steven D'Aprano  writes:
>>
>>> On Fri, 22 Jun 2018 11:14:59 +0100, Ben Bacarisse wrote:
>>>
>> The code page remark is curious.  Will some "code pages" have digits
>> that are not ASCII digits?
> Good question.  I have no idea.
 It's much more of an open question than I thought.
>>> Nah, Python already solves that for you:
>> My understanding was that the OP does not (reliably) know the encoding,
>> though that was a guess based on a turn of phrase.
> I took it the other way: that Ethan *does* know the encoding, and his
> problem is that knowing the encoding and/or locale is not enough to
> recognise whether to use a period or comma as the decimal separator.
>
> Which it isn't.
If you know the Locale, then you do know what the decimal separator is, as that
 is part of what a locale defines. The issue is that if you just know the
encoding, you don't necessarily know the locale. He also commented that he
didn't want to set the locale in the routine, as that sets it globally for the
full application (but perhaps that latter could be fixed by first doing a
locale.getlocale(), then setlocale for the files locale, and then at the end of
 reading and processing restore back the old locale.
>
> If he doesn't know the encoding, he has bigger problems than just
> converting strings into floats. Without knowing the encoding, he cannot
> even reliably detect non-ASCII digits at all.
>
>
>> Another guess is that the OP does not have Unicode data.  The term "code
>> page" hints at an 8-bit encoding or at least a pre-Unicode one.
> Assuming he is using Python 3, or using Python 2 sensibly, once he has
> specified the encoding and read the data from the file, he has Unicode.
>
> Unicode is a superset of (ideally) all code pages. Once you have decoded
> the data using the appropriate code page, you have a Unicode string, and
> Python doesn't care where it came from.
>
> The point is, once Ethan can get the intended characters out of the file
> into Python, it doesn't matter what code page they came from. They're now
> full-fledged Unicode characters, and Python's float() and int() functions
> can easily deal with non-ASCII digits. So long as he has digits in the
> first place, float() and int() will deal with them correctly.
>
>

--
Richard Damon

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Chris Angelico]

From: Chris Angelico 

On Sat, Jun 23, 2018 at 2:16 PM, Chris Angelico  wrote:
> For getting rid of the "len=len" trick, though, I would REALLY like to
> transform those into LOAD_CONST. That'd be a fun bytecode hack all on
> its own. In fact, I'm gonna have a shot at that. An "early bind these
> names" decorator.

Well, that was easier than I expected. Which almost certainly means I haven't
properly solved the problem.

https://github.com/Rosuav/shed/blob/master/consts.py

Let's start finding all the edge cases that don't work, so I can work on fixing
 them :)

ChrisA

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: ironpython not support py3.6

[denis akhiyarov]

  To: Schachner, Joseph
From: denis.akhiya...@gmail.com

Either wait for IronPython 3.6, use COM interop, pythonnet, subprocess, or
things like gRPC. Based on PyPy experience, it is probably 1-2 years of
sponsored development to get a working IronPython 3.6.

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Feeding the trolls

[mm0fmf]

  To: Steven D'Aprano
From: mm0fmf 

On 22/06/2018 00:51, Steven D'Aprano wrote:
> On Thu, 21 Jun 2018 21:49:15 +0100, mm0fmf wrote:
>
> [snip unnecessary quoting]
>> Design requirements for python newsreader client:
>>
>> 1. Block all top posters
>
> I think it would be far more useful to block bottom-posters who don't
> snip irrelevant quoted text.
>
>
>
But the irony of being just as bad a post by quoting all the redundant text
would be lost if that was cut and it just bitched about top posting.

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: translating foreign data

[Ben Bacarisse]

  To: Steven D'Aprano
From: Ben Bacarisse 

Steven D'Aprano  writes:

> On Fri, 22 Jun 2018 11:14:59 +0100, Ben Bacarisse wrote:
>
 The code page remark is curious.  Will some "code pages" have digits
 that are not ASCII digits?
>>>
>>> Good question.  I have no idea.
>>
>> It's much more of an open question than I thought.
>
> Nah, Python already solves that for you:

My understanding was that the OP does not (reliably) know the encoding, though
that was a guess based on a turn of phrase.

Another guess is that the OP does not have Unicode data.  The term "code page"
hints at an 8-bit encoding or at least a pre-Unicode one.


--
Ben.

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: translating foreign data

[Richard Damon]

On 6/23/18 10:44 PM, Steven D'Aprano wrote:
> On Sat, 23 Jun 2018 17:52:55 -0400, Richard Damon wrote:
>
>> If you have more than just a number representing a value in the locale
>> currency, you can't ask the locale how to present/accept it.
> You're the only one saying that it has to be handled by the locale.
>
>
Actually, it was part of the problem statement by Marko, since he said
to use LC_MONETARY, which is the part of the Locale machinery dealing
with monetary quantities (and can ONLY handle the currency defined by
the Locale). What would you think of providing a program in say, Java,
to a problem statement that said to write a Python program.

I suppose he could have just meant use the number, which would be like
asking to interpret the value of 100 euros using math.pi

Or it could have been just a bad question like how heavy is blue. (Since
by definition a locale only knows how to handle a single type of
currency, assuming any value is of that type).

My answer was in part to point out the problem with the problem
statement (and people seem to want to jump on me for pointing out the
strengths and weaknesses of the locale system.

This also goes back to the very original question at the beginning of
the thread, the OP had a bunch of data with numbers using varying locale
conventions (he didn't use the words), but had various decimal
separators and some people asked about non-'arabic' numbers  (0-9).

This also goes back to some of the comments about file formats. Most
file formats are designed to be 'Machine Read' (even if they use text
formatting) and as such do NOT use localization facilities, so when
processing them you want the I/O processing system to be in a
non-localized mode (typically numbers always use . as the decimal
separator, and usually nothing as the thousands separator). While the
text format files might be opened in a text editor, the file format
doesn't cater to making things pretty for the user. Some programs will
create input/output/storage files where it is expected that the user
WILL open them, look at them and maybe even edit them. Numbers will use
the locale convention of currency and decimal/thousands separators. If
you have such a system, changing the locale rules for these files may
cause misinterpreting the values.

If you are bringing such files from a 'foreign' system, you need to be
able to indicate what locale to use when reading that file. This sounds
very much like the category of problem that the OP was dealing with.
They have apparently a large number files, presumably organized in some
consistent manner that the values in them make sense, but the numbers
are written in different local conventions, and this was causing the
simplistic processing to fail.

-- 
Richard Damon

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

Re: syntax difference

[Richard Damon]

On 6/24/18 3:02 PM, Steven D'Aprano wrote:
> On Sun, 24 Jun 2018 19:37:33 +0100, Bart wrote:
>
>> I want to program in /my/ style
> Python is not Java, and Java is not Python either. Nor is it "Bart's 
> Language", or C, or Forth, or Lisp, or bash.
>
> https://dirtsimple.org/2004/12/python-is-not-java.html
>
> https://dirtsimple.org/2004/12/java-is-not-python-either.html
>
>
> To get the best out of any language, you should try to program to its 
> strengths, in the idioms that work, not insist on writing FooLanguage 
> code in BarLanguage.
>
> Hammers are great tools. So are screwdrivers. But you wouldn't use a 
> screwdriver to hammer nails, or hammer screws, would you?
>
> You'd probably be pretty frustrated if one of your users (ahem) insisted 
> on duplicating the form and structure of their bash scripts in your 
> language, and complaining bitterly about how your language sucks because 
> it isn't bash.
>
>From what I have seen from Bart in other groups, Bart want to write in
'Bart' using existing languages and is frustrated that no one (but him)
has written a language exactly to his specs.

-- 
Richard Damon

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

Re: syntax difference

[Steven D'Aprano]

On Sun, 24 Jun 2018 19:37:33 +0100, Bart wrote:

> I want to program in /my/ style

Python is not Java, and Java is not Python either. Nor is it "Bart's 
Language", or C, or Forth, or Lisp, or bash.

https://dirtsimple.org/2004/12/python-is-not-java.html

https://dirtsimple.org/2004/12/java-is-not-python-either.html


To get the best out of any language, you should try to program to its 
strengths, in the idioms that work, not insist on writing FooLanguage 
code in BarLanguage.

Hammers are great tools. So are screwdrivers. But you wouldn't use a 
screwdriver to hammer nails, or hammer screws, would you?

You'd probably be pretty frustrated if one of your users (ahem) insisted 
on duplicating the form and structure of their bash scripts in your 
language, and complaining bitterly about how your language sucks because 
it isn't bash.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: Python for beginners or not? [was Re: syntax difference]

[Bart]

On 24/06/2018 19:36, Abdur-Rahmaan Janhangeer wrote:

see for example

https://en.m.wikipedia.org/wiki/Bresenham%27s_line_algorithm

see the pseudocode, i was implementing some raster algos when i found
myself aux anges

so close to py. i guess it was written in prehistoric times with the author
trying to simplify stuffs


I'm sorry, but that kind of code is a mish-mash of old 
Algol/Pascal-style languages. I doubt it was meant to be Python.


Python doesn't have a monopoly on clear syntax.

This is the first example from that link (I've taken out comments):

 function line(x0, y0, x1, y1)
 real deltax := x1 - x0
 real deltay := y1 - y0
 real deltaerr := abs(deltay / deltax)
 real error := 0.0
 int y := y0
 for x from x0 to x1
 plot(x,y)
 error := error + deltaerr
 while error ≥ 0.5 then
 y := y + sign(deltay) * 1
 error := error - 1.0

This has some problems: it's using 'function' when it doesn't return a 
value (those languages used 'proc' or 'procedure' in that case). It 
doesn't give a type for the parameters, and it uses while/then rather 
than the usual while/do.


So it's rather sloppy even for pseudo code. The only similarity with 
Python is the lack of block delimiters, but then with later examples 
they /are/ used, for if-else-endif.


Below, the first block is that code tweaked to a static language of 
mine. The second is the same code tweaked to Python.


It was less work to adapt it my syntax rather than Python. All versions 
however use a decidedly un-Pythonic style, which means the difference 
between the two below isn't that great, even though they are different 
languages. But imagine trying to adapt Pythonic code to work in the 
other language; it would be much harder (apart from one being dynamic 
and the other not).


-
 proc line(int x0, y0, x1, y1)=
 real deltax := x1 - x0
 real deltay := y1 - y0
 real deltaerr := abs(deltay / deltax)
 real error := 0.0
 int y := y0
 int x
 for x := x0 to x1 do
 plot(x,y)
 error := error + deltaerr
 while error = 0.5 do
 y := y + sign(deltay) * 1
 error := error - 1.0
 end
 end
 end
--
def line(x0, y0, x1, y1):
 deltax = x1 - x0
 deltay = y1 - y0
 deltaerr = abs(deltay / deltax)
 error = 0.0
 y = y0
 for x in range(x0,x1+1):
 plot(x,y)
 error = error + deltaerr
 while error == 0.5:
 y = y + sign(deltay) * 1
 error = error - 1.0


--
bart
--
https://mail.python.org/mailman/listinfo/python-list

Re: Anyone here on Python-Dev mailing list?

[Terry Reedy]

On 6/24/2018 12:07 PM, Steven D'Aprano wrote:

Anyone on the Python-Dev mailing list, are you getting private emails
containing nothing but stream of consciousness word-salad from somebody
(some bot?) calling himself "Chanel Marvin" with a gmail address?

Typical example:

 "I refuse to create my environment on a computer. Stalls and static
 and it always looks fake unless I can afford all the cool fast stuff
 like Prometheus speed but for dummies in plain white english"

in reply to an email I posted to the list.

I don't want to ask there, yet, in case it isn't a bot but some nutter
with an attitude emailing me privately.


I recently got a request for help from a stranger, but it was more 
coherent than the above.


--
Terry Jan Reedy

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

Re: syntax difference

[Terry Reedy]

On 6/24/2018 11:39 AM, Bart wrote:

Bart, I agree that people should not dogpile onto you.  As with Rick, I 
read your posts or not, depending on whether I feel like being 
entertained at the moment, and usually move on without comment.



I know I'm going to get flak for bringing this up this old issue,


"Getting flak" is apparently your goal.  This is called trolling.

remember when you used to write a for-loop and it involved creating an 
actual list of N integers from 0 to N-1 in order to iterate through 
them? Crazy.


Yep.  We first fixed it in a backward compatible way, then in a code 
breaking way.  The second fix got some rough and rude flak: "This is the 
end of Python!!!"



But that has long been fixed - or so I thought.


You thought right.


When I wrote, today:


using an ancient version of Python,


    for i in range(1): pass  # 100 million

on Python 2, it used up 1.8GB, up to the limit of my RAM, and it took 
several minutes to regain control of my machine (and it never did 
finish).

 > You don't expect that in 2018 when executing a simple empty loop.

And you don't get that when you use a 2018 version of Python, or even 
the newer 2008 version (3.0.0).  Are you really unaware of that?

On Py 2 you have to use xrange for large ranges - that was the fix.


Yep. This was the backward compatible fix.  So what is your point?

Somebody however must have had to gently and tactfully point out the 
issue. 


For all I know, the craziness of the original design may have prompted 
some rough and rude comments *BEFORE IT WAS FIXED*.  Possibly ditto for 
the clutziness of the fix -- *BEFORE THE FIX WAS FIXED*.



I'm afraid I'm not very tactful.


The above seems politely worded to me.  It is just 20 and 10 years too 
late, and completely pointless, unless 'flak' is your goal.


--
Terry Jan Reedy


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

Re: syntax difference

[Bart]

On 24/06/2018 16:37, boB Stepp wrote:

On Sun, Jun 24, 2018 at 5:21 AM Bart  wrote:



"... And of course, you would have to know how to use Python properly in
idiomatic style.


No. I want to program in /my/ style, one more like the pseudo-code that 
was mentioned elsewhere, and that is universally understood. Even if 
people here don't think much of it.


(eg. https://pastebin.com/0EygJzFR, raw 
text:https://pastebin.com/raw/0EygJzFR)


  Why not choose this positive approach?  I think it

would be a win-win for both you and Python."

Just show you genuinely care about the language and the community.
Use and understand the language as well as you can before jumping into
criticisms.  Adopt the path of the humble learner, who does not know
everything about Python.  Is this too much to ask?


Sorry, I tried a few replies but they all got too long and too much 
about me. So I'll have to leave it.


I think people know enough about my ideas by now anyway.

--
bart
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Abdur-Rahmaan Janhangeer]

see for example

https://en.m.wikipedia.org/wiki/Bresenham%27s_line_algorithm

see the pseudocode, i was implementing some raster algos when i found
myself aux anges

so close to py. i guess it was written in prehistoric times with the author
trying to simplify stuffs

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ


>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python for beginners or not? [was Re: syntax difference]

[Chris Angelico]

On Mon, Jun 25, 2018 at 2:23 AM, Abdur-Rahmaan Janhangeer
 wrote:
> Python is rightly called executable pseudocode. i appreciated the fact that
> you can go on wikipaedia, find the pseudocode of algorithms remove curly
> braces and replace by py's more powerful  syntax and poof, suddenly it
> becomes too easy.

My pseudocode and Python code look extremely similar, but that's
partly *because* I know Python. But I do periodically have JavaScript
students ask me "Is that Python?" when what I've written is
pseudocode.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Anyone here on Python-Dev mailing list?

[Abdur-Rahmaan Janhangeer]

i follow the dev list so far no

but that particular mail might be related to pythan rather than random
messages

over the times i've talked to users of other langs (academics) one of the
fault they find with python is the virtual env setup, too boring a task.

environment in that case may refer to python environment

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ


>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Anyone here on Python-Dev mailing list?

[Steven D'Aprano]

On Mon, 25 Jun 2018 02:15:42 +1000, Chris Angelico wrote:

> On Mon, Jun 25, 2018 at 2:07 AM, Steven D'Aprano
>  wrote:
>> Anyone on the Python-Dev mailing list, are you getting private emails
>> containing nothing but stream of consciousness word-salad from somebody
>> (some bot?) calling himself "Chanel Marvin" with a gmail address?
>>
>> Typical example:
>>
>> "I refuse to create my environment on a computer. Stalls and static
>> and it always looks fake unless I can afford all the cool fast
>> stuff like Prometheus speed but for dummies in plain white english"
>>
>> in reply to an email I posted to the list.
>>
>> I don't want to ask there, yet, in case it isn't a bot but some nutter
>> with an attitude emailing me privately.
>>
>>
> Yeah, I got one of those. I'm pretty sure it's a Markov chainer.

Only one? So far I've had seven.

I get spam bots trying to flush out suckers. I don't get bots that send 
out random messages to random people. Why?



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: syntax difference

[Steven D'Aprano]

On Sun, 24 Jun 2018 16:39:19 +0100, Bart wrote:

> More like utter disbelief at how it works. Surely it cannot work like
> that because it would be too inefficient? Apparently, yes it can...

Apparently, no it doesn't, because the fact that Python is used by tens 
of thousands of programmers for some mighty big, performance-critical, 
projects proves that it isn't "too inefficient". Its efficient enough.

You want C, and all the headaches and buffer overflows and seg faults it 
gives, you know where to find it.


> I know I'm going to get flak for bringing this up this old issue,

And yet you're going to do it anyway.

> but
> remember when you used to write a for-loop and it involved creating an
> actual list of N integers from 0 to N-1 in order to iterate through
> them? Crazy.

That's nothing, there are languages where the standard way to write a for 
loop is to call an external program that generates a stream of numeric 
strings separated by spaces in a subprocess, and read the strings from 
standard input as text.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: Python for beginners or not? [was Re: syntax difference]

[Abdur-Rahmaan Janhangeer]

Python is rightly called executable pseudocode. i appreciated the fact that
you can go on wikipaedia, find the pseudocode of algorithms remove curly
braces and replace by py's more powerful  syntax and poof, suddenly it
becomes too easy.

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Anyone here on Python-Dev mailing list?

[Chris Angelico]

On Mon, Jun 25, 2018 at 2:07 AM, Steven D'Aprano
 wrote:
> Anyone on the Python-Dev mailing list, are you getting private emails
> containing nothing but stream of consciousness word-salad from somebody
> (some bot?) calling himself "Chanel Marvin" with a gmail address?
>
> Typical example:
>
> "I refuse to create my environment on a computer. Stalls and static
> and it always looks fake unless I can afford all the cool fast stuff
> like Prometheus speed but for dummies in plain white english"
>
> in reply to an email I posted to the list.
>
> I don't want to ask there, yet, in case it isn't a bot but some nutter
> with an attitude emailing me privately.
>

Yeah, I got one of those. I'm pretty sure it's a Markov chainer.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Anyone here on Python-Dev mailing list?

[Steven D'Aprano]

Anyone on the Python-Dev mailing list, are you getting private emails 
containing nothing but stream of consciousness word-salad from somebody 
(some bot?) calling himself "Chanel Marvin" with a gmail address?

Typical example:

"I refuse to create my environment on a computer. Stalls and static
and it always looks fake unless I can afford all the cool fast stuff
like Prometheus speed but for dummies in plain white english"

in reply to an email I posted to the list.

I don't want to ask there, yet, in case it isn't a bot but some nutter 
with an attitude emailing me privately.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: Introducing Coconut

[Abdur-Rahmaan Janhangeer]

hum syntactic coating exists even in py. nice!

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ


>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Chris Angelico]

On Mon, Jun 25, 2018 at 1:02 AM, Steven D'Aprano
 wrote:
> On Mon, 25 Jun 2018 00:46:00 +1000, Chris Angelico wrote:
>
>> On Sun, Jun 24, 2018 at 8:40 PM, Steven D'Aprano
>>  wrote:
>>> On Sun, 24 Jun 2018 11:18:37 +0100, Bart wrote:
>>>
 I wonder why it is just me that constantly needs to justify his
 existence in this group?
>>>
>>> Because its just you who spends 90% of his time here complaining about
>>> how Python does it wrong.
>>
>> ... and spends 95% of that time demonstrating his utter lack of
>> understanding of how Python does it at all. It's wrong even though you
>> don't understand how it actually works.
>
> Be fair. It's more like 50% of the time.
>
> Let's not dogpile onto Bart. He asked a question, I answered it, we don't
> all need to sink the boot in as well.

Fair. Still, it does seem that most of the criticisms are based on
ignorance, not reasoned disagreement. For instance, I could argue that
Python's model of "variables are local if written to, otherwise
they're looked up globally" is a poor choice, because I have
extensively used Python AND other (C-like) models. Or I could argue
that Python really ought to support "foo bar baz"/" " as a syntax for
string splitting, because I've used Python's way of doing things, and
have also used something that works differently. But I cannot argue
that Python should have mutable strings, because I've never used a
modern language that has them, so I don't know what the tradeoffs are.
Thus you don't hear me pushing for it.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Bart]

On 24/06/2018 15:46, Chris Angelico wrote:

On Sun, Jun 24, 2018 at 8:40 PM, Steven D'Aprano
 wrote:

On Sun, 24 Jun 2018 11:18:37 +0100, Bart wrote:


I wonder why it is just me that constantly needs to justify his
existence in this group?


Because its just you who spends 90% of his time here complaining about
how Python does it wrong.


... and spends 95% of that time demonstrating his utter lack of
understanding of how Python does it at all. It's wrong even though you
don't understand how it actually works.


More like utter disbelief at how it works. Surely it cannot work like 
that because it would be too inefficient? Apparently, yes it can...


And all to support extreme dynamism which is only really needed a tiny 
proportion of the time (feel free to correct me).


I know I'm going to get flak for bringing this up this old issue, but 
remember when you used to write a for-loop and it involved creating an 
actual list of N integers from 0 to N-1 in order to iterate through 
them? Crazy.


But that has long been fixed - or so I thought. When I wrote, today:

   for i in range(1): pass  # 100 million

on Python 2, it used up 1.8GB, up to the limit of my RAM, and it took 
several minutes to regain control of my machine (and it never did 
finish). You don't expect that in 2018 when executing a simple empty loop.


On Py 2 you have to use xrange for large ranges - that was the fix.

Somebody however must have had to gently and tactfully point out the 
issue. I'm afraid I'm not very tactful.


--
bart

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

Re: syntax difference

[boB Stepp]

On Sun, Jun 24, 2018 at 5:21 AM Bart  wrote:
>
> On 24/06/2018 00:44, boB Stepp wrote:
> > On Sat, Jun 23, 2018 at 5:35 PM Bart  wrote:
>
> >> I'm not a user...
> >
> > Then I am truly puzzled, Bart.  Why do you even bother to hang out on
> > this list?  If you do not want to use Python and you do not want to
> > improve Python's design and implementation, what is your point of
> > being here?
>
> I wonder why it is just me that constantly needs to justify his
> existence in this group?

You snipped the unpleasant part of my paragraph:
"... You *do* seem to generate a lot of ill will, I hope
unintentionally..."

> Does someone need to be that much of a user of a language in order
> to discuss its design or its features or its efficiency, or how it
> compares with any other? You can do that from without as well as
> from within.

I don't dispute this.  But there are good ways to do this and there
are bad ways to do this.  You seem to fall into the latter category
enough that at a minimum you irritate people who care very deeply
about Python, and, at worst, outright enrage some.



> As for why Python, it's the dynamic language I'm most familiar
> with, and I've been following it since the 1990s.

And this gets to the crux of the matter.  If this is so, why is it
that you repeatedly demonstrate a lack of understanding of the very
things you are critiquing?  I cannot recall how many times you have
been called out on this point, but it is certainly not an uncommon
event.  It is one thing to have demonstrable technical understanding
of one or more concepts, and critique those concepts with valid, or at
least, interesting points, but it is entirely another thing to be
criticizing (How you are often perceived.) something in Python while
at the same time demonstrating you don't really understand the
particular Pythonic implementation or usage you are criticizing.
Don't you see the difference?  Don't you see what it is that so riles
people?  But things do not have to be this way!  As I said later in my
paragraph I have been referencing:

"... But why not take a different, more helpful tack?
You seem to have a lot of ideas.  If you really think they are
applicable to improving the Python language, why not take your ideas,
one at a time, and have serious discussion, perhaps better on
Python-Ideas, on how Python can be meaningfully made better?  That
would be a helpful approach which I think, if done with the intention
of helping Python to be the best language it can be (Within the
constraints it has to operate within in practice.), then I would hope
your potential contributions would be positively received by the
community..."

And:

"... And of course, you would have to know how to use Python properly in
idiomatic style.  Why not choose this positive approach?  I think it
would be a win-win for both you and Python."

Just show you genuinely care about the language and the community.
Use and understand the language as well as you can before jumping into
criticisms.  Adopt the path of the humble learner, who does not know
everything about Python.  Is this too much to ask?



-- 
boB
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Steven D'Aprano]

On Mon, 25 Jun 2018 00:46:00 +1000, Chris Angelico wrote:

> On Sun, Jun 24, 2018 at 8:40 PM, Steven D'Aprano
>  wrote:
>> On Sun, 24 Jun 2018 11:18:37 +0100, Bart wrote:
>>
>>> I wonder why it is just me that constantly needs to justify his
>>> existence in this group?
>>
>> Because its just you who spends 90% of his time here complaining about
>> how Python does it wrong.
> 
> ... and spends 95% of that time demonstrating his utter lack of
> understanding of how Python does it at all. It's wrong even though you
> don't understand how it actually works.

Be fair. It's more like 50% of the time.

Let's not dogpile onto Bart. He asked a question, I answered it, we don't 
all need to sink the boot in as well.

Nobody expects Bart to love Python, but if he wants to fit in here, in a 
Python group, he ought to either at least make an effort to understand 
the reasons Python is what it is (and not just idiocy and bloat) and 
appreciate it for what it is, not for what it isn't. Or at least avoid 
trying to lecture us on why we're doing it wrong.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: Introducing Coconut

[justin walters]

On Sun, Jun 24, 2018 at 5:51 AM, Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info> wrote:

> Coconut, the functional programming language which compiles to Python:
>
> http://coconut.readthedocs.io/en/master/FAQ.html
>
> http://coconut-lang.org/
>
> (Its not my language. I just think its cool.)
>
>
> --
> Steven D'Aprano
> "Ever since I learned about confirmation bias, I've been seeing
> it everywhere." -- Jon Ronson
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>


As someone who has been studying Elixir and Phoenix lately, This is pretty
neat.

There have definitely been some pieces of my Python projects that could
have benefited from a
Functional structure.

I don't think writing an entire project in Cocounut would be worth while.
At that point, why not use an actual FP language?
However, I do think it sounds useful for when certain parts of a project
could be cleaned up
or optimized with functional code. Almost like a better `functools`.

All that said though, I am interested to see performance metrics for the
transpiled python.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Chris Angelico]

On Sun, Jun 24, 2018 at 8:40 PM, Steven D'Aprano
 wrote:
> On Sun, 24 Jun 2018 11:18:37 +0100, Bart wrote:
>
>> I wonder why it is just me that constantly needs to justify his
>> existence in this group?
>
> Because its just you who spends 90% of his time here complaining about
> how Python does it wrong.

... and spends 95% of that time demonstrating his utter lack of
understanding of how Python does it at all. It's wrong even though you
don't understand how it actually works.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Package directory question

[Robert Latest via Python-list]

Hello,

I'm building an application which consists of two largely distinct
parts, a frontend and a backend. The directory layout is like this:

|-- jobwatch
|   |-- backend
|   |   |-- backend.py
|   |   |-- __init__.py
|   |   `-- tables.py
|   |-- frontend
|   |   |-- __init__.py
|   |   |-- main.py
|   `-- __init__.py
`-- setup.py

Because the main.py script needs to import the tables.py module from
backend, I put this at the top if main.py:

   sys.path.append('../..')
   import jobwatch.backend.tables as tables

My question is: Is this the way it should be done? It looks fishy. The
only alternative I could come up with is to put a symlink to tables.py
into the frontend directory, which also seems fishy. Eventually I want
to package all this up neatly to be able to use only little wrapper
scripts for the backend (running as a service) and the frontend (a wsgi
app).

Any thoughts?

Thanks
robert
-- 
https://mail.python.org/mailman/listinfo/python-list

Introducing Coconut

[Steven D'Aprano]

Coconut, the functional programming language which compiles to Python:

http://coconut.readthedocs.io/en/master/FAQ.html

http://coconut-lang.org/

(Its not my language. I just think its cool.)


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Python for beginners or not? [was Re: syntax difference]

[Steven D'Aprano]

On Sat, 23 Jun 2018 14:52:24 -0500, boB Stepp wrote:

[...]
>> There is a place for various levels of programming language. I'm saying
>> that Python which is always touted as a 'simple' language suitable for
>> beginners, is missing a surprising number of basics.
> 
> I still feel like a rank beginner, but on the Tutor list some disagree.

It has been a long, long time since Python has been a "simple" language 
suitable for rank beginners, if it ever was. Python is not Scratch.

https://scratch.mit.edu/


Right from version 1.0, Python has included some advanced features, even 
mind-blowing features (metaclasses, a.k.a. "the killer joke"). We're now 
up to version 3.6 (in production) and 3.7 (in beta) and Python includes 
some very advanced modern[1] features, like syntactic support for 
asynchronous programming, decorators, generators, coroutines and more.

Better to say that Python is *accessible* to beginners: you can do a lot 
of good work in Python using simple constructs and imperative scripts, 
and most importantly, the syntax generally doesn't get in your way. 
There's relatively little boilterplate needed and a gentle learning curve.

Compare "Hello World" in Java and Python:

public class HelloWorld {
public static void main(String[] args) {
// Prints "Hello, World" to the terminal window.
System.out.println("Hello, World");
}
}


versus:

print("Hello, World")

The Python example requires the programmer to learn effectively three 
things (print, parentheses, strings), compared to over a dozen for Java:

- classes; braces; parentheses; strings; methods;
  attribute access using dot; "public" declarations;
  "static" declarations; "void" declarations; 
  type declarations; the existence of System; 
  System.out; System.out.println; semicolons;
  the implicit calling of main.


Aside: there's an extensive, and yet still incomplete, list of Hello 
World programs here http://helloworldcollection.de/ with some impressive 
examples. Enjoy!


[...]
> As an aside we just had another round of software, OS and hardware
> upgrades.  Now I can use Python 2.7!

Yay! Welcome to the 2000s! Hope you will catch up to Python 3 by the 
2020s :-)


> Because I read and study about new things as I take them up, I soon
> learned that I had only so far scratched the surface of Python's depths.
>  But despite knowing that Python had many more features to explore, both
> in the core language and the standard library, this never hindered me in
> writing my beginner-level programs.  I got things done, and I got them
> done fairly easily, and never felt burdened by all the "other stuff"
> that Python had to offer.

Indeed. That's one of the beauties of Python -- even when there's an 
advanced way to do it, there's generally a simple way too.






[1] I say "modern", but in fact very little in computer science wasn't 
invented by Lisp in the 1950s, or if not Lisp, by CLU in the 1970s.

-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: Static variables [was Re: syntax difference]

[Steven D'Aprano]

On Sun, 24 Jun 2018 11:23:12 +0100, Bart wrote:

> On 24/06/2018 01:53, Ben Bacarisse wrote:
>> Bart  writes:
> 
>>> Wow. (Just think of all the times you write a function containing a
>>> neat bunch of local functions, every time it's called it has to create
>>> a new function instances for each of those functions, even if they are
>>> not used.)
>> 
>> I am surprised that this surprises you, and equally surprised that you
>> seem to think it's going to be in some way grossly inefficient.
> 
> Steven D'Aprano's reply suggests there /is/ some inefficiency which is
> why [according to him] nested functions are rarely used that way.

Building functions is cheap. Cheap is not free.

Inner functions that aren't exposed to the outside cannot be tested in 
isolation, you can't access them through help() interactively. Given the 
choice between:


# can't test eggs, can't re-use it
def func():
def eggs():
...
...

and:

# can test it, can re-use it
def _eggs():
...

def func():
...


most people go for the later simply because it is better development 
practice. The very small performance penalty hardly comes into it.

For what its worth, the cost of assembling a basic function is comparable 
to creating an empty dict:

[steve@ando ~]$ python3.5 -m timeit "lambda: None"
1000 loops, best of 3: 0.195 usec per loop
[steve@ando ~]$ python3.5 -m timeit "{}"
100 loops, best of 3: 0.212 usec per loop


so not expensive, but not free either. If using an inner function has no 
advantages to you, why pay that tiny cost for no benefit?


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: syntax difference

[Steven D'Aprano]

On Sun, 24 Jun 2018 11:18:37 +0100, Bart wrote:

> I wonder why it is just me that constantly needs to justify his
> existence in this group?

Because its just you who spends 90% of his time here complaining about 
how Python does it wrong.


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: nltk related issue

[Glenn Hutchings]

On 21/06/18 04:40, Sharan Basappa wrote:
> Folks,
>
> I am trying to run a simple example associated with nltk.
> I get some error and I don't know what the issue is.
> I need some guidance please.
>

[...]

> LookupError:
> **
>Resource u'tokenizers/punkt/english.pickle' not found.  Please
>use the NLTK Downloader to obtain the resource:  >>>
>nltk.download()
>Searched in:
>  - 'D:\\Users\\sharanb/nltk_data'
>  - 'C:\\nltk_data'
>  - 'D:\\nltk_data'
>  - 'E:\\nltk_data'
>  - 
'D:\\Users\\sharanb\\AppData\\Local\\Enthought\\Canopy\\edm\\envs\\User\\nltk_data'
>  - 
'D:\\Users\\sharanb\\AppData\\Local\\Enthought\\Canopy\\edm\\envs\\User\\lib\\nltk_data'

>  - 'D:\\Users\\sharanb\\AppData\\Roaming\\nltk_data'
>  - u''
> **
>

As the error message says, you need to do a one-time installation of the 
NLTK data.  See http://www.nltk.org/data.html for more info.


Glenn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Static variables [was Re: syntax difference]

[Bart]

On 24/06/2018 01:53, Ben Bacarisse wrote:

Bart  writes:



Wow. (Just think of all the times you write a function containing a
neat bunch of local functions, every time it's called it has to create
a new function instances for each of those functions, even if they are
not used.)


I am surprised that this surprises you, and equally surprised that you
seem to think it's going to be in some way grossly inefficient.


Steven D'Aprano's reply suggests there /is/ some inefficiency which is 
why [according to him] nested functions are rarely used that way.


--
bartc


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

Re: syntax difference

[Bart]

On 24/06/2018 00:44, boB Stepp wrote:

On Sat, Jun 23, 2018 at 5:35 PM Bart  wrote:



I'm not a user...


Then I am truly puzzled, Bart.  Why do you even bother to hang out on
this list?  If you do not want to use Python and you do not want to
improve Python's design and implementation, what is your point of
being here?


I wonder why it is just me that constantly needs to justify his
existence in this group?

Does someone need to be that much of a user of a language in order
to discuss its design or its features or its efficiency, or how it
compares with any other? You can do that from without as well as
from within.

Anyway I'm not here that often, I pop in from time to time when
something interesting comes that I feel I can comment about. And
yes I sometimes do that as a diversion because I enjoy this
discussing this stuff. Why, is that allowed?

As for why Python, it's the dynamic language I'm most familiar
with, and I've been following it since the 1990s.

Here's a small selection of threads I've posted in:

 Why not allow empty code blocks

 Python and the need for speed

 Building CPython

 What is a function parameter =[] for

 Considering migrating to Python from Visual Basic...

 How to read from a file to an arbitrary delimiter efficiently

 Python 2.x or 3.x, which is faster?

 The cost of Dynamism

 Case Statements  [15-Mar-2016]

The last is interesting. The OP there follows up with:

 "You have apparently mistaken me for someone who's worried.
 I don't use Python, I was just curious as to why a construct
 that is found, not only to be useful in 95% of other languages,
 but is generally considered more flexible and readable than the
 if-elif, was missing in Python.  (your link 'Switch Statement
 Code Smell' not withstanding)"

Many of the posters are explaining why Python doesn't have it, why
they think the feature is so poor, and ways to get around the lack
of it. Mine defend the feature.

You're saying I shouldn't be allowed to put an alternative point of
view because I don't use Python enough? I would say that because I
/implement/ such features all the time in other languages, that my
opinion is worthwhile.

But people do seem to like to wind me up, and I like to defend my 
corner, so posts tend to proliferate.


--
bart.

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