On 2018-05-20 16:36:12 -0400, Richard Damon wrote:
> 2) Try to maximize portability by not only looking at the specs, but
> also common implementations, and choosing the options that maximize the
> acceptability of your output to tools that don't fully meet the specs.
> Also, if a common implementa
On 2018-05-20 11:37:14 -0400, Dennis Lee Bieber wrote:
> On Sun, 20 May 2018 12:38:59 +0100, bartc declaimed the
> following:
> >Then the /same software/ probably wouldn't work anywhere else. I mean
> >taking source which doesn't know or care about what system its on, and
> >that operates on a p
On 5/20/18 11:52 AM, Dennis Lee Bieber wrote:
> On Sun, 20 May 2018 12:11:34 +0100, bartc declaimed the
> following:
>
>> I think that's the wrong approach. You need to work to the lowest common
>> denominator, not the highest. (Within reason anyway.)
>>
> If a reader can not handle permitt
On 20/05/2018 16:37, Dennis Lee Bieber wrote:
On Sun, 20 May 2018 12:38:59 +0100, bartc declaimed the
Just for giggles, I decided to write the start of a PPM reader (it only
handles P6 binary, doesn't have the code for the other styles, and doesn't
incorporate PPM writer functions but
On 20/05/2018 10:19, Peter J. Holzer wrote:
On 2018-05-19 13:43:14 +0100, bartc wrote:
Text files, yes. Not 'text mode' which is something inflicted on us by the C
library.
I very much enjoy the fact that the programming languages I've used to
process text files in the last 15 years (i.e. Pe
On 20/05/2018 02:58, Dennis Lee Bieber wrote:
On Sun, 20 May 2018 02:13:01 +0100, bartc declaimed the
following:
I think if you are going to be generating ppm, then the best choice of
format, for the widest acceptance, is to separate the header groups with
a newline. (As I mentioned my downloa
On 2018-05-19 13:43:14 +0100, bartc wrote:
> On 19/05/2018 12:33, Peter J. Holzer wrote:
> > On 2018-05-19 11:33:26 +0100, bartc wrote:
>
> > > Not you understand why some of us don't bother with 'text mode' files.
> >
> > "Not" or "Now"?
>
> Now.
>
> > Yesterday you claimed that you worked wit
On 20/05/2018 01:39, Dennis Lee Bieber wrote:
On Sat, 19 May 2018 23:14:08 +0100, bartc declaimed the
following:
The comments and examples here:
https://en.wikipedia.org/wiki/Netpbm_format, and all actual ppm files
I've come across, suggest the 3 parts of the header (2 parts for P1/P4)
are on
On 19/05/2018 20:47, Dennis Lee Bieber wrote:
On Sat, 19 May 2018 13:28:41 +0100, bartc declaimed the
following:
Out of interest, how would Python handle the headers for binary file
formats P4, P5, P6? I'd have a go but I don't want to waste half the day
trying to get past the language.
On 2018-05-19 13:28, bartc wrote:
On 19/05/2018 12:38, Chris Angelico wrote:
On Sat, May 19, 2018 at 8:33 PM, bartc wrote:
But then you are acknowledging the file is, in fact, ASCII.
Cool! So what happens if you acknowledge that a file is ASCII, and
then it starts with a byte value of E3 ?
On 19/05/2018 12:33, Peter J. Holzer wrote:
On 2018-05-19 11:33:26 +0100, bartc wrote:
Not you understand why some of us don't bother with 'text mode' files.
"Not" or "Now"?
Now.
Yesterday you claimed that you worked with them for 40 years.
Text files, yes. Not 'text mode' which is som
On 19/05/2018 12:38, Chris Angelico wrote:
On Sat, May 19, 2018 at 8:33 PM, bartc wrote:
But then you are acknowledging the file is, in fact, ASCII.
Cool! So what happens if you acknowledge that a file is ASCII, and
then it starts with a byte value of E3 ?
It depends.
If this is a .ppm f
On Sat, May 19, 2018 at 8:33 PM, bartc wrote:
> On 19/05/2018 02:26, Chris Angelico wrote:
>>
>> On Sat, May 19, 2018 at 11:10 AM, bartc wrote:
>
>
>>> The .ppm (really .pbm) file which was the subject of this sub-thread has
>>> its
>>> header defined using ASCII. I don't think an EBCDIC 'P4' etc
On 2018-05-19 11:33:26 +0100, bartc wrote:
> On 19/05/2018 02:26, Chris Angelico wrote:
> > On Sat, May 19, 2018 at 11:10 AM, bartc wrote:
> > > The .ppm (really .pbm) file which was the subject of this sub-thread has
> > > its
> > > header defined using ASCII. I don't think an EBCDIC 'P4' etc wi
On 19/05/2018 02:26, Chris Angelico wrote:
On Sat, May 19, 2018 at 11:10 AM, bartc wrote:
The .ppm (really .pbm) file which was the subject of this sub-thread has its
header defined using ASCII. I don't think an EBCDIC 'P4' etc will work.
"Defined using ASCII" is a tricky concept. There ar
On Sat, May 19, 2018 at 11:10 AM, bartc wrote:
> On 19/05/2018 02:00, Steven D'Aprano wrote:
>>
>> On Fri, 18 May 2018 20:42:05 -0400, Dennis Lee Bieber wrote:
>>
>>> Unfortunately -- in the current era, "text" means "a defined
>>
>> encoding",
>>
>> Text has ALWAYS meant "a defined encodi
On 19/05/2018 02:00, Steven D'Aprano wrote:
On Fri, 18 May 2018 20:42:05 -0400, Dennis Lee Bieber wrote:
Unfortunately -- in the current era, "text" means "a defined
encoding",
Text has ALWAYS meant "a defined encoding". It is just that for a long
time, people could get away with assu
On 19/05/2018 01:42, Dennis Lee Bieber wrote:
On Fri, 18 May 2018 22:53:06 +0100, bartc declaimed the
following:
I've worked with text files for 40 years. Now Python is telling me I've
been doing it wrong all that time!
Look at the original code I posted from which this Python was based.
Tha
On Fri, 18 May 2018 20:42:05 -0400, Dennis Lee Bieber wrote:
> Unfortunately -- in the current era, "text" means "a defined
encoding",
Text has ALWAYS meant "a defined encoding". It is just that for a long
time, people could get away with assuming that the encoding they used was
the *onl
On 19/05/2018 01:00, Chris Angelico wrote:
On Sat, May 19, 2018 at 7:53 AM, bartc wrote:
I've worked with text files for 40 years. Now Python is telling me I've been
doing it wrong all that time!
Look at the original code I posted from which this Python was based. That
creates a file - just a
On Fri, 18 May 2018 22:53:06 +0100, bartc wrote:
> I've worked with text files for 40 years. Now Python is telling me I've
> been doing it wrong all that time!
Welcome to the 20th Century! We interchange text and data with
people from all over the world now, and one or two of them use
characters
On Sat, May 19, 2018 at 7:53 AM, bartc wrote:
> I've worked with text files for 40 years. Now Python is telling me I've been
> doing it wrong all that time!
>
> Look at the original code I posted from which this Python was based. That
> creates a file - just a file - without worrying about whether
On 18/05/2018 19:57, Chris Angelico wrote:
On Sat, May 19, 2018 at 4:48 AM, bartc wrote:
The translation was straightforward, EXCEPT that I wasted an hour trying to
figure out to write /a single byte/ to a file. The following eventually
worked, using a binary file as a text one had Unicode prob
On 18/05/2018 20:15, Alexandre Brault wrote:
On 2018-05-18 02:48 PM, bartc wrote:
Note this version doesn't use any imports at all.
Except your version doesn't read its parameter from the command line
args and doesn't output to standard output, which all of the others do.
That's why the other
On 2018-05-18 02:48 PM, bartc wrote:
> On 18/05/2018 18:27, bartc wrote:
>
>> (BTW here's a port of that benchmark based on the Lua code:
>>
>> https://pastebin.com/raw/ivDaKudX
>
> And here's the payoff: I was able to use this version to port it to
> Python. One which works better the the origi
On Sat, May 19, 2018 at 4:53 AM, bartc wrote:
> On 18/05/2018 19:36, Chris Angelico wrote:
>>
>> On Sat, May 19, 2018 at 3:27 AM, bartc wrote:
>
>
>> Once again, you're confusing *porting* with *emulating*.
>
>
> This is the point. Those libraries are specific to Python and cannot be
> ported.
>
On Sat, May 19, 2018 at 4:48 AM, bartc wrote:
> The translation was straightforward, EXCEPT that I wasted an hour trying to
> figure out to write /a single byte/ to a file. The following eventually
> worked, using a binary file as a text one had Unicode problems, but it's
> still hacky.
You can't
On 18/05/2018 19:36, Chris Angelico wrote:
On Sat, May 19, 2018 at 3:27 AM, bartc wrote:
Once again, you're confusing *porting* with *emulating*.
This is the point. Those libraries are specific to Python and cannot be
ported.
And very often they don't just provide general support that ca
On 18/05/2018 18:27, bartc wrote:
(BTW here's a port of that benchmark based on the Lua code:
https://pastebin.com/raw/ivDaKudX
And here's the payoff: I was able to use this version to port it to
Python. One which works better the the originals, as they wrote output
to the screen (/binar
On Sat, May 19, 2018 at 3:27 AM, bartc wrote:
> On 18/05/2018 15:47, Chris Angelico wrote:
>>
>> On Sat, May 19, 2018 at 12:37 AM, bartc wrote:
>>>
>>> Have a look at some of the implementations here (to test some Mandelbrot
>>> benchmark):
>>>
>>>
>>> https://benchmarksgame-team.pages.debian.net
On 18/05/2018 15:47, Chris Angelico wrote:
On Sat, May 19, 2018 at 12:37 AM, bartc wrote:
Have a look at some of the implementations here (to test some Mandelbrot
benchmark):
https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html
The three Python examples all
On Sat, May 19, 2018 at 12:37 AM, bartc wrote:
> Have a look at some of the implementations here (to test some Mandelbrot
> benchmark):
>
> https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html
>
> The three Python examples all use 'import sys' and 'import multipr
On 18/05/2018 13:29, Steven D'Aprano wrote:
On Fri, 18 May 2018 12:09:02 +0100, bartc wrote:
On 18/05/2018 02:45, Steven D'Aprano wrote:
On Fri, 18 May 2018 02:17:39 +0100, bartc wrote:
Normally you'd use the source code as a start point. In the case of
Python, that means Python source code.
On Fri, 18 May 2018 12:09:02 +0100, bartc wrote:
> On 18/05/2018 02:45, Steven D'Aprano wrote:
>> On Fri, 18 May 2018 02:17:39 +0100, bartc wrote:
>>
>>> Normally you'd use the source code as a start point. In the case of
>>> Python, that means Python source code. But you will quickly run into
>>
On 5/18/18 7:09 AM, bartc wrote:
On 18/05/2018 02:45, Steven D'Aprano wrote:
On Fri, 18 May 2018 02:17:39 +0100, bartc wrote:
Normally you'd use the source code as a start point. In the case of
Python, that means Python source code. But you will quickly run into
problems because you will often
On 18/05/2018 02:45, Steven D'Aprano wrote:
On Fri, 18 May 2018 02:17:39 +0100, bartc wrote:
Normally you'd use the source code as a start point. In the case of
Python, that means Python source code. But you will quickly run into
problems because you will often see 'import lib' and be unable to
On 18/05/18 02:45, Steven D'Aprano wrote:
To successful port anything but the most trivial code, you actually have
to understand *both* languages -- including the syntax, semantics, built-
in language features, AND libraries.
A point that was once made to me about translating human languages is
On Thu, May 17, 2018, 8:45 PM Ben Finney,
wrote:
> Steven D'Aprano writes:
>
> > If you want to *really* see code that is hard to port, you should try
> > porting an Inform 7 program to another language. Any other language.
>
> Does porting Inform 7 code to Inform 6 count? They are very differen
Steven D'Aprano writes:
> If you want to *really* see code that is hard to port, you should try
> porting an Inform 7 program to another language. Any other language.
Does porting Inform 7 code to Inform 6 count? They are very different
languages :-)
--
\ “Puritanism: The haunting fear t
On Thu, May 17, 2018, 7:50 PM Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info> wrote:
>
> If you want to *really* see code that is hard to port, you should try
> porting an Inform 7 program to another language. Any other language.
>
How about Z-code?
*ducks*
>
--
https://mail.python.org
On Fri, 18 May 2018 02:17:39 +0100, bartc wrote:
> Normally you'd use the source code as a start point. In the case of
> Python, that means Python source code. But you will quickly run into
> problems because you will often see 'import lib' and be unable to find
> lib.py anywhere.
Seriously? Ther
On 17/05/2018 18:19, Steven D'Aprano wrote:
On Thu, 17 May 2018 15:50:17 +0100, bartc wrote:
Of course, full-on Python code is pretty much impossible to port
anywhere else anyway.
*rolls eyes*
Any pair of languages will have code that is hard to port from one to the
other without jumping
On Fri, May 18, 2018 at 3:48 AM, Steven D'Aprano
wrote:
> On Fri, 18 May 2018 03:44:25 +1000, Chris Angelico wrote:
>
>> I'm morbidly curious as to what "half-on Python code" would look like.
>
> Writing Java in Python. Or C in Python. Or Lisp in Python. Or ...
>
Ah. I was wondering if this was m
On Fri, 18 May 2018 03:44:25 +1000, Chris Angelico wrote:
> I'm morbidly curious as to what "half-on Python code" would look like.
Writing Java in Python. Or C in Python. Or Lisp in Python. Or ...
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
On Fri, May 18, 2018 at 3:34 AM, Steven D'Aprano
wrote:
> On Thu, 17 May 2018 15:50:17 +0100, bartc wrote:
>
>> Of course, full-on Python code is pretty much impossible to port
>> anywhere else anyway.
>
> Oh, I forgot to mention... given that Python is frequently used to
> prototype applications
On Thu, 17 May 2018 15:50:17 +0100, bartc wrote:
> Of course, full-on Python code is pretty much impossible to port
> anywhere else anyway.
Oh, I forgot to mention... given that Python is frequently used to
prototype applications before the production-ready application is written
in C, C++ or J
On Thu, 17 May 2018 17:50:22 +0300, Marko Rauhamaa wrote:
> bartc :
>> Anyway, try this:
>>
>> def showarg(x): print(x)
>>
>> def dummy(*args,**kwargs): pass
>>
>> dummy(a=showarg(1),*[showarg(2),showarg(3)])
>>
>> This displays 2,3,1 showing that evaluation is not left to right.
>
>
On Thu, 17 May 2018 15:50:17 +0100, bartc wrote:
> On 17/05/2018 15:03, Chris Angelico wrote:
>> On Thu, May 17, 2018 at 9:58 PM, bartc wrote:
>>> On 17/05/2018 04:54, Steven D'Aprano wrote:
On Thu, 17 May 2018 05:33:38 +0400, Abdur-Rahmaan Janhangeer wrote:
> what does := prop
On Fri, May 18, 2018 at 1:27 AM, Ian Kelly wrote:
> This raises a new issue for me w.r.t. PEP 572. The spelling of :=
> makes it unlikely to accidentally use in place of ==, but what about
> := and = confusion? For example, say I mean to write this:
>
> foo(a := 42, b, c)
>
> but accidentally
On Thu, May 17, 2018 at 9:06 AM, Chris Angelico wrote:
> On Fri, May 18, 2018 at 12:30 AM, bartc wrote:
>> Anyway, try this:
>>
>> def showarg(x): print(x)
>>
>> def dummy(*args,**kwargs): pass
>>
>> dummy(a=showarg(1),*[showarg(2),showarg(3)])
>>
>> This displays 2,3,1 showing that e
On Fri, May 18, 2018 at 12:30 AM, bartc wrote:
> Anyway, try this:
>
> def showarg(x): print(x)
>
> def dummy(*args,**kwargs): pass
>
> dummy(a=showarg(1),*[showarg(2),showarg(3)])
>
> This displays 2,3,1 showing that evaluation is not left to right.
>
Keyword args are evaluated after
On 17/05/2018 15:03, Chris Angelico wrote:
On Thu, May 17, 2018 at 9:58 PM, bartc wrote:
On 17/05/2018 04:54, Steven D'Aprano wrote:
On Thu, 17 May 2018 05:33:38 +0400, Abdur-Rahmaan Janhangeer wrote:
what does := proposes to do?
A simple example (not necessarily a GOOD example, but a S
bartc :
> Anyway, try this:
>
> def showarg(x): print(x)
>
> def dummy(*args,**kwargs): pass
>
> dummy(a=showarg(1),*[showarg(2),showarg(3)])
>
> This displays 2,3,1 showing that evaluation is not left to right.
Nice one!
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On 17/05/2018 14:32, Steven D'Aprano wrote:
On Thu, 17 May 2018 12:58:43 +0100, bartc wrote:
On 17/05/2018 04:54, Steven D'Aprano wrote:
On Thu, 17 May 2018 05:33:38 +0400, Abdur-Rahmaan Janhangeer wrote:
what does := proposes to do?
A simple example (not necessarily a GOOD example, but a
On 05/16/2018 08:54 PM, Steven D'Aprano wrote:
On Thu, 17 May 2018 05:33:38 +0400, Abdur-Rahmaan Janhangeer wrote:
what does := proposes to do?
Simply, it proposes to add a new operator := for assignment (or binding)
as an expression, as an addition to the = assignment operator which
operates
On Thu, May 17, 2018 at 9:58 PM, bartc wrote:
> On 17/05/2018 04:54, Steven D'Aprano wrote:
>>
>> On Thu, 17 May 2018 05:33:38 +0400, Abdur-Rahmaan Janhangeer wrote:
>>
>>> what does := proposes to do?
>
>
>> A simple example (not necessarily a GOOD example, but a SIMPLE one):
>>
>> print(x := 100
On Thu, May 17, 2018 at 11:34 PM, Steven D'Aprano
wrote:
> On Thu, 17 May 2018 14:56:32 +0200, Antoon Pardon wrote:
>
>> On 17-05-18 03:44, Chris Angelico wrote:
>
>>> https://www.python.org/dev/peps/pep-0572/
>
>> Just wondering, but in discussing this PEP has one considered making the
>> ';' int
On Thu, 17 May 2018 15:54:27 +0300, Serhiy Storchaka wrote:
> 17.05.18 15:07, Paul Moore пише:
>> It's a good example, because it makes it clear that the benefits of :=
>> are at least in some cases, somewhat dependent on the fact that Python
>> evaluates arguments left to right :-)
>
> Unless it
Antoon Pardon :
> On 17-05-18 03:44, Chris Angelico wrote:
> I just ask because sometimes I have a loop that now often is written
> as follows:
>
> while True:
> a = prepare_a()
> b = prepare_b()
> if not condition(a, b):
> break
> Do other stuff
>
>
On Thu, 17 May 2018 14:56:32 +0200, Antoon Pardon wrote:
> On 17-05-18 03:44, Chris Angelico wrote:
>> https://www.python.org/dev/peps/pep-0572/
> Just wondering, but in discussing this PEP has one considered making the
> ';' into an expression too, with the value being the value of the last
> e
On Thu, 17 May 2018 12:58:43 +0100, bartc wrote:
> On 17/05/2018 04:54, Steven D'Aprano wrote:
>> On Thu, 17 May 2018 05:33:38 +0400, Abdur-Rahmaan Janhangeer wrote:
>>
>>> what does := proposes to do?
>
>> A simple example (not necessarily a GOOD example, but a SIMPLE one):
>>
>> print(x := 10
On 17-05-18 03:44, Chris Angelico wrote:
> On Thu, May 17, 2018 at 11:33 AM, Abdur-Rahmaan Janhangeer
> wrote:
>> what does := proposes to do?
>>
>> pep572
>>
> If you read the PEP, you'll find an answer to your question.
>
> https://www.python.org/dev/peps/pep-0572/
>
> ChrisA
Just wondering, bu
17.05.18 15:07, Paul Moore пише:
It's a good example, because it makes it clear that the benefits of :=
are at least in some cases, somewhat dependent on the fact that Python
evaluates arguments left to right :-)
Unless it evaluates them in other order.
--
https://mail.python.org/mailman/listi
On 17 May 2018 at 12:58, bartc wrote:
> On 17/05/2018 04:54, Steven D'Aprano wrote:
>>
>> On Thu, 17 May 2018 05:33:38 +0400, Abdur-Rahmaan Janhangeer wrote:
>>
>>> what does := proposes to do?
>
>> A simple example (not necessarily a GOOD example, but a SIMPLE one):
>>
>> print(x := 100, x+1, x*2
On 17/05/2018 04:54, Steven D'Aprano wrote:
On Thu, 17 May 2018 05:33:38 +0400, Abdur-Rahmaan Janhangeer wrote:
what does := proposes to do?
A simple example (not necessarily a GOOD example, but a SIMPLE one):
print(x := 100, x+1, x*2, x**3)
It's also not a good example because it assumes
thank you very much @steve
i guess it will make py fly more than ever !
Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ
On Thu, 17 May 2018, 07:57 Steven D'Aprano, <
steve+comp.lang.pyt...@pearwood.info> wrote:
> On Thu, 17 May 2018 05:33:38 +0400, Abdur-Rahmaan Janhangeer wrote:
>
>
On Thu, 17 May 2018 05:33:38 +0400, Abdur-Rahmaan Janhangeer wrote:
> what does := proposes to do?
Simply, it proposes to add a new operator := for assignment (or binding)
as an expression, as an addition to the = assignment operator which
operates only as a statement. The syntax is:
name
meaning that's precisely what i'm asking for
Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ
On Thu, 17 May 2018, 05:45 Chris Angelico, wrote:
> On Thu, May 17, 2018 at 11:33 AM, Abdur-Rahmaan Janhangeer
> wrote:
> > what does := proposes to do?
> >
> > pep572
> >
>
> If you read th
On Thu, May 17, 2018 at 11:33 AM, Abdur-Rahmaan Janhangeer
wrote:
> what does := proposes to do?
>
> pep572
>
If you read the PEP, you'll find an answer to your question.
https://www.python.org/dev/peps/pep-0572/
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
what does := proposes to do?
pep572
Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ
--
https://mail.python.org/mailman/listinfo/python-list
70 matches
Mail list logo
