Re: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 10442: character maps to

[Peter Otten]

bellcanada...@gmail.com wrote:

> On Thursday, 29 January 2009 12:09:29 UTC-5, Anjanesh Lekshminarayanan 
> wrote:
>> > It does auto-detect it as cp1252- look at the files in the traceback
>> > and you'll see lib\encodings\cp1252.py. Since cp1252 seems to be the
>> > wrong encoding, try opening it as utf-8 or latin1 and see if that fixes
>> > it.
>> 
>> Thanks a lot ! utf-8 and latin1 were accepted !
> 
> hello i am having same issue..i believe the code is written in python 2
> and i am running python 3.6..i tried at the interpreter..f =
> open(filename, encoding="utf-8" and also latin-1..but then when i run my
> file i still get the error...also my line is at 7414..how do you find this
> line??...is it better to try to run the file .py in python 2??..thnxz

open(filename, encoding="latin-1") will succeed with *every* file -- the 
characters may be nonsensical, but you will *not* get a UnicodeDecodeError.

> ...is it better to try to run the file .py in python 2?

Not "better", but perhaps easier. If the code works with Python 2 then I 
recommend that you use that.

If you want help to debug it you need to provide some of the relevant source 
code and -- first and foremost -- the traceback.

> my line is at 7414..how do you find this line?

Read the traceback carefully. It should contain both filename and line.

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

Re: what does := means simply?

[Peter J. Holzer]

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 with them for 40 years.
> 
> 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. Perl and Python) can
convert just about any character encoding and any newline convention to
a canonical representation with a single parameter to open.

When the "textmode" in the C library was invented (it wasn't just C,
though: Wirth's Modula-2 book describes a remarkably similar mechanism)
the situation was a lot more complicated: Many operating systems didn't
have a newline character (or character sequence). They had fixed length
records or a length indicator at the start of each line or even more
complicated schemes. The textmode removes these differences - you always
get lines terminated by \n. Without a textmode, you would have to deal
with all those different file formats if you wanted to write a portable
version of even a simple program like cat. The world has become simpler
in this regard.


> > > However if you have an actual EBCDIC system and would to read .ppm files,
> > > then you will have trouble reading the numeric parameters as they are
> > > expressed using sequences of ASCII digits.
> 
> > I think the simplest way would be perform the calculation by hand
> > (new_value = old_value * 10 + next_byte - 0x30). At least in a language
> > which lets me process individual bytes easily. That would even work on
> > both ASCII and EBCDIC based systems (and on every other platform, too).
> 
> /The/ simplest? Don't forget the numbers can be several digits each. Here's
> how I read them (NOT Python):
> 
> readln @f, width, height
> 
> Would it work in an EBCDIC based system? Probably not. But, who cares?

The premise in your previous message was that you are on an EBCDIC based
system (and a quite limited at that which doesn't even have a character
set conversion library, so you would have to program the character set
conversion yourself). So you can't cop out with "I don't care about
EBCDIC based systems".

(Your single readln wouldn't work reliably on ASCII systems either,
since - as others have already pointed out - the header format of a PPM
file isn't quite as simple as you imagine).

> (Perhaps someone who has access to an EBCDIC system can try a .PPM reader to
> see what happens. I suspect that won't work either.)

A PPM reader for an EBCDIC system will certainly be able to read PPM
files on an EBCDIC system. Why would anybody write and release software
which doesn't work on the intended target system?

hp

-- 
   _  | 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 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: what does := means simply?

[bartc]

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 downloaded viewer needs a new line after
the first group. My own viewer, which I only threw together the other
day to test that benchmark, also expects the newlines. Otherwise I might
need to do 5 minutes' coding to fix it.)


IrfanView had no problem opening my file, where the only  was the
one after the maxval field. Between that as an example, and the
documentation of the format, one could decree that any reader that
/requires/ s at various points is erroneous or incomplete.


I think that's the wrong approach. You need to work to the lowest common 
denominator, not the highest. (Within reason anyway.)


If you tested half a dozen viewers, and two of them don't need any 
newlines between groups, and the rest need at least one, or between all 
groups, what does this tell you about how you should be generating your 
file?


You may not know what viewer or reader is to be used.

I have a suspicion (although I will have to test more) that newlines 
between groups is more universally accepted.


(I tried to get irfanview but it tells me I need Windows 10, which is an 
odd requirement for an image viewer. So I'll have to try it later.)


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

Re: what does := means simply?

[bartc]

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. Perl and Python) can
convert just about any character encoding and any newline convention to
a canonical representation with a single parameter to open.


And I quite like the fact that I have complete control over what is 
being read or written. And if there is some obscure bug, that the actual 
contents of a file aren't hidden behind some protocols in library.



When the "textmode" in the C library was invented (it wasn't just C,
though: Wirth's Modula-2 book describes a remarkably similar mechanism)


I also like the way that the single '\n' character in a source file 
conveniently matches the single '\n' character used by Unix. So no 
translation of any kind is needed, and you can assume that if you write 
1000 empty lines the output file will be 1000 bytes long.


The complications are in all the other operating systems. And the bugs 
when someone assumes that one '\n' in a program equals one 10 byte in a 
file, will only occur on those other systems.



The premise in your previous message was that you are on an EBCDIC based
system (and a quite limited at that which doesn't even have a character
set conversion library, so you would have to program the character set
conversion yourself). So you can't cop out with "I don't care about
EBCDIC based systems".


I think it was Steven D'Aprano who brought up EBCDIC. And not seriously.


(Your single readln wouldn't work reliably on ASCII systems either,
since - as others have already pointed out - the header format of a PPM
file isn't quite as simple as you imagine).


The line-reading has to be in a loop in order to skip comments, which I 
didn't show because the bigger obstacle in Python appeared to be reading 
the numbers (and is not needed for those specific Mandelbrot images). 
It's something like this: repeat ... until width.isint



A PPM reader for an EBCDIC system will certainly be able to read PPM
files on an EBCDIC system. Why would anybody write and release software
which doesn't work on the intended target system?


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 ppm file downloaded from the internet.


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

Re: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 10442: character maps to

[bellcanadardp]

On Saturday, 19 May 2018 19:48:20 UTC-4, Skip Montanaro  wrote:
> As Chris indicated, you'll have to figure out the correct encoding. You
> might want to check out the chardet module (available on PyPI, I believe)
> and see if it can come up with a better guess. I imagine there are other
> encoding guessers out there. That's just one I'm familiar with.
> 
> Skip

hello Skip
thank you for the reply, but how exactly am i supposed to find oout what is the 
correct encodeing??

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

Re: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 10442: character maps to

[bellcanadardp]

On Saturday, 19 May 2018 19:03:09 UTC-4, Chris Angelico  wrote:
> On Sun, May 20, 2018 at 8:58 AM,   wrote:
> > On Thursday, 29 January 2009 12:09:29 UTC-5, Anjanesh Lekshminarayanan  
> > wrote:
> >> > It does auto-detect it as cp1252- look at the files in the traceback and
> >> > you'll see lib\encodings\cp1252.py. Since cp1252 seems to be the wrong
> >> > encoding, try opening it as utf-8 or latin1 and see if that fixes it.
> >>
> >> Thanks a lot ! utf-8 and latin1 were accepted !
> >
> > hello i am having same issue..i believe the code is written in python 2 and 
> > i am running python 3.6..i tried at the interpreter..f =
> > open(filename, encoding="utf-8" and also latin-1..but then when i run my 
> > file i still get the error...also my line is at 7414..how do you find this 
> > line??...is it better to try to run the file .py in python 2??..thnxz
> 
> You're responding to something from 2009.
> 
> Your file is apparently not encoded the way you think it is. You'll
> have to figure out what it ACTUALLY is.
> 
> ChrisA


hello Chris
thank you for the reply, but how exactly am i supposed to find oout what is the 
correct encodeing??
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 10442: character maps to

[Richard Damon]

On 5/20/18 7:59 AM, bellcanada...@gmail.com wrote:
> On Saturday, 19 May 2018 19:03:09 UTC-4, Chris Angelico  wrote:
>> On Sun, May 20, 2018 at 8:58 AM,   wrote:
>>> On Thursday, 29 January 2009 12:09:29 UTC-5, Anjanesh Lekshminarayanan  
>>> wrote:
> It does auto-detect it as cp1252- look at the files in the traceback and
> you'll see lib\encodings\cp1252.py. Since cp1252 seems to be the wrong
> encoding, try opening it as utf-8 or latin1 and see if that fixes it.
 Thanks a lot ! utf-8 and latin1 were accepted !
>>> hello i am having same issue..i believe the code is written in python 2 and 
>>> i am running python 3.6..i tried at the interpreter..f =
>>> open(filename, encoding="utf-8" and also latin-1..but then when i run my 
>>> file i still get the error...also my line is at 7414..how do you find this 
>>> line??...is it better to try to run the file .py in python 2??..thnxz
>> You're responding to something from 2009.
>>
>> Your file is apparently not encoded the way you think it is. You'll
>> have to figure out what it ACTUALLY is.
>>
>> ChrisA
>
> hello Chris
> thank you for the reply, but how exactly am i supposed to find oout what is 
> the correct encodeing??

Basically, you need to know it from some other source to be totally
certain. This is part of the 'disaster' of 8 bit code pages.

There are a few guesses that can be done that often get you close.
utf-8, IF it validates is almost always what the file is (unless it is
just ASCII, where you generally never even notice the issue).

There are programs that will look at some heuristics in the file and try
to guess. Another option is to open the file in a text editor which will
be more forgiving and show the bad character as an error symbol, and see
if  you can recognize what 'language' (human) the user seems to have
been using, and guess the character encoding from that (or just remove
the bad characters if they are just in comments/unimportant strings.)

-- 
Richard Damon

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

Re: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 10442: character maps to

[Skip Montanaro]

> how exactly am i supposed to find oout what is the correct encodeing?

It seems you are a Python beginner. Rather than just tell you how to use
this one module, I'll point you at some of the ways to get help through
Python.

* On pypi.org, search for "chardet" and see if the author provided online
documentation links.

* At the shell prompt, you might well have a "pydoc" command. Try "pydoc
chardet" after installing it.

* At the Python ">>> " prompt, import the chardet module, then use the
help() function to get some basic help gleaned from the module itself.
(This is basically what the pydoc command does.)

>>> import chardet
>>> help(chardet)
...

* Even more abbreviated than the help() function, the dir() function will
just tell you what attributes an object (not just a module) has.

* Go to docs.python.org and do some tutorial/beginner reading.

* Finally, try searching for "how to get help in python" in your favorite
search engine. There are plenty of useful websites/blogs/articles devoted
to this topic.

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

Re: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 10442: character maps to

[Karsten Hilbert]

On Sun, May 20, 2018 at 04:59:12AM -0700, bellcanada...@gmail.com wrote:

> On Saturday, 19 May 2018 19:48:20 UTC-4, Skip Montanaro  wrote:
> > As Chris indicated, you'll have to figure out the correct encoding. You
> > might want to check out the chardet module (available on PyPI, I believe)
> > and see if it can come up with a better guess. I imagine there are other
> > encoding guessers out there. That's just one I'm familiar with.
> 
> thank you for the reply, but how exactly am i supposed to find oout what is 
> the correct encodeing??

One CAN NOT.

The best you can do is to go ask the canonical source of the
file what encoding the file is _supposed_ to be in.

Then go from there and allow for errors.

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

Re: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 10442: character maps to

[bellcanadardp]

On Sunday, 20 May 2018 08:58:32 UTC-4, Richard Damon  wrote:
> On 5/20/18 7:59 AM, bellcanada...@gmail.com wrote:
> > On Saturday, 19 May 2018 19:03:09 UTC-4, Chris Angelico  wrote:
> >> On Sun, May 20, 2018 at 8:58 AM,   wrote:
> >>> On Thursday, 29 January 2009 12:09:29 UTC-5, Anjanesh Lekshminarayanan  
> >>> wrote:
> > It does auto-detect it as cp1252- look at the files in the traceback and
> > you'll see lib\encodings\cp1252.py. Since cp1252 seems to be the wrong
> > encoding, try opening it as utf-8 or latin1 and see if that fixes it.
>  Thanks a lot ! utf-8 and latin1 were accepted !
> >>> hello i am having same issue..i believe the code is written in python 2 
> >>> and i am running python 3.6..i tried at the interpreter..f =
> >>> open(filename, encoding="utf-8" and also latin-1..but then when i run my 
> >>> file i still get the error...also my line is at 7414..how do you find 
> >>> this line??...is it better to try to run the file .py in python 2??..thnxz
> >> You're responding to something from 2009.
> >>
> >> Your file is apparently not encoded the way you think it is. You'll
> >> have to figure out what it ACTUALLY is.
> >>
> >> ChrisA
> >
> > hello Chris
> > thank you for the reply, but how exactly am i supposed to find oout what is 
> > the correct encodeing??
> 
> Basically, you need to know it from some other source to be totally
> certain. This is part of the 'disaster' of 8 bit code pages.
> 
> There are a few guesses that can be done that often get you close.
> utf-8, IF it validates is almost always what the file is (unless it is
> just ASCII, where you generally never even notice the issue).
> 
> There are programs that will look at some heuristics in the file and try
> to guess. Another option is to open the file in a text editor which will
> be more forgiving and show the bad character as an error symbol, and see
> if  you can recognize what 'language' (human) the user seems to have
> been using, and guess the character encoding from that (or just remove
> the bad characters if they are just in comments/unimportant strings.)
> 
> -- 
> Richard Damon

thank you for the email reply Richard Damon
i will study all your great  guidelines

i actually got my script to function by running it in python 2.7
thanx for your kind suggestions very much

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

Proper email etiquette

[D'Arcy Cain]

On 2018-05-18 06:24 PM, José María Mateos wrote:
> And another one I learned recently on a similar conversation on another 
> mailing list (that of the e-mail client I'm using right now): it is very 
> useful for searches. Every e-mail contains just the right amount of text 
> necessary to be properly read, as opposed to a more or less complete 
> copy of the current thread.
Another good idea is to change the subject when the topic changes.

-- 
D'Arcy J.M. Cain
Vybe Networks Inc.
http://www.VybeNetworks.com/
IM:da...@vex.net VoIP: sip:da...@vybenetworks.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Numpy array

[Gary Herron]

The "indexing" page of the documentation might help you with this:

https://docs.scipy.org/doc/numpy-1.14.0/reference/arrays.indexing.html


On 05/18/2018 09:50 PM, sharan.basa...@gmail.com wrote:

This is regarding numpy array. I am a bit confused how parts of the array are 
being accessed in the example below.

1 import scipy as sp
2 data = sp.genfromtxt("web_traffic.tsv", delimiter="\t")
3 print(data[:10])
4 x = data[:,0]
5 y = data[:,1]

Apparently, line 3 prints the first 10 entries in the array
line 4 & 5 is to extract all rows but only 1st and second columns alone for x 
and y respectively.

I am confused as to how data[:10] gives the first 10 rows while data[:,0] gives 
all rows



--
Dr. Gary Herron
Professor of Computer Science
DigiPen Institute of Technology
(425) 895-4418

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

Re: what does := means simply?

[bartc]

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...)

It successfully processed the PPM file my prior writing code
generated...

-=-=-=-=-=-
import struct

class PPM(object):

...


-=-=-=-=-=-
Type: b'P6' Width: 3Height: 3   MaxVal: 255
[(0, 255, 0), (128, 128, 128), (255, 0, 0), (128, 128, 128), (255, 255,
255), (128, 128, 128), (0, 0, 255), (128, 128, 128), (0, 0, 0)]


Yes, that appears to work. (But I think it has a bug when there are two 
successive #-comment lines.)


Meanwhile I've given up my campaign to have only line-oriented headers, 
and spent the five minutes needed to allow for free-format headers, and 
actually it's now simpler:


  readln @f,sig
  width  := readnextint(f)  # a 6-line function returning 0 on error
  height := readnextint(f)
  maxval := readnextint(f)  # (for some file types)

However I don't think this works properly when a comment follows (on the 
same line) the last format item, as a well-formed header will have an 
extra white-space character to be skipped. I believe your program might 
have the same problem; it will read the header OK, but not start reading 
the data at the right place.


(A rather poor specification I think which could have been tightened up.)

--
bartc

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

Python 3.6 causes error, python 3.5 does not.

[Jim]

Mint 18
Libreoffice 5.1.6.2
Python 3.6.5 in one virtual environment
Python 3.5.2 in another

I am writing a script that uses pyautogui to get some data and paste it 
into a Libreoffice calc file, there by bypassing the complexity of uno.


The problem is it runs fine if I use python 3.5. If I use python 3.6 it 
opens the calc file then pops up a dialog saying "std::bad_alloc". There 
are no relevant errors in the terminal. At this point I must reload the 
file and let calc recover it. I googled "std::bad_alloc" but didn'


This is the portion of the code that causes the error:

import pyautogui
import subprocess
import threading
import time

LONG_ENOUGH = 5

class LO():
'''Manipulate libreoffice not using UNO'''
def __init__(self):
self.filename = 
'/home/jfb/Documents/Financial/Investing/Stocks.ods'
opener = threading.Thread(target=self.open_it, 
args=(self.filename,))

opener.start()
time.sleep(5) #LONG_ENOUGH)
#self.manipulate_LO()

#Open and work with libreoffice
def open_it(self, filename):
#subprocess.call(["libreoffice", filename])
subprocess.run(["libreoffice", filename])

lo = LO()

To complicate matters not all .ods files show this problem. I ran some 
tests. Two of my .ods files are effected but a couple of others are not. 
A new test file I created is not effected.


I don't know if I have a Libreoffice problem, file corruption or a 
Python problem. The fact that 3.6 gives an error but 3.5 does not is the 
reason I decided to ask here first.


Regards,  Jim

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

best way to remove leading zeros from a tuple like string

[bruceg113355]

Lets say I have the following tuple like string.
  (128, 020, 008, 255)

What is the best way to to remove leading zeroes and end up with the following.
  (128, 20, 8, 255)-- I do not care about spaces

This is the solution I came up with
s = "(128, 020, 008, 255)"
v = s.replace ("(", "")
v = v.replace (")", "")
vv = ",".join([str(int(i)) for i in v.split(",")])
final = "(" + vv + ")"


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

Re: what does := means simply?

[Richard Damon]

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 permitted variations documented in a
> specification, then that reader is erroneous, and bug report should be
> filed for it.
>
>> If you tested half a dozen viewers, and two of them don't need any 
>> newlines between groups, and the rest need at least one, or between all 
>> groups, what does this tell you about how you should be generating your 
>> file?
>>
>   Nothing about how /I/ should generate the file -- it tells me those
> readers are non-conformant with the specification.
>
>   The specification document drives the requirements for reading and
> writing, the requirements drive the implementation. If a program does not
> implement the requirements derived from the specification, that program is
> incomplete and/or in error.
>
>   That most implementations are using a  convention when
> /writing/ a PPM file does not negate the fact that the specification
> permits for no  at all (barring the need for one at the end of a
> comment), and a conformant /reader/ program shall accept those variations.
>
>
There are 3 basic ways to write something to a spec like this.

1) Write exactly to the specification, choosing options for generation
based on what is the easiest for you, and if other tools can't read
this, insist on writing bug reports.

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 implementation generates something not quite to the
standard, try to make it so you can accept that output too.

3) Decide to be a perverse implementation and choose strange ((or
random) combinations for generation choices to come up with files to
stress test other implementations, and be totally picky about the input
format, reporting the slightest deviation from the spec.


The second option is the best to choose if you really want to make your
application as useful as possible (except as a stress test).

-- 
Richard Damon

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

Re: best way to remove leading zeros from a tuple like string

[Michael F. Stemper]

On 2018-05-20 14:54, bruceg113...@gmail.com wrote:

Lets say I have the following tuple like string.
   (128, 020, 008, 255)

What is the best way to to remove leading zeroes and end up with the following.
   (128, 20, 8, 255)-- I do not care about spaces



I'd use a few regular expressions:

>>> from re import sub
>>> tuple = '(0128, 020, 008,012, 255)'
>>> sub( " 0*", " ", tuple ) # leading zeroes following space(s)
'(0128, 20, 8,012, 255)'
>>> sub( ",0*", ",", tuple ) # leading zeroes following comma
'(0128, 020, 008,12, 255)'
>>> sub( "\(0*", "(", tuple ) # leading zeroes after opening parend
'(128, 020, 008,012, 255)'

Each step could be written as "tuple = sub( ..."

>>> tuple = sub( " 0*", " ", tuple ) # following space(s)
>>> tuple = sub( ",0*", ",", tuple ) # following comma
>>> tuple = sub( "\(0*", "(", tuple ) # after opening parend
>>> tuple
'(128, 20, 8,12, 255)'
>>>


Or, if you like to make your code hard to read and maintain, you could
combine them all into a single expression:

>>> sub( " 0*", " ", sub( ",0*", ",", sub( "\(0*", "(", tuple ) ) )
'(128, 20, 8,12, 255)'
>>>

--
Michael F. Stemper
What happens if you play John Cage's "4'33" at a slower tempo?
--
https://mail.python.org/mailman/listinfo/python-list

Re: best way to remove leading zeros from a tuple like string

[bruceg113355]

On Sunday, May 20, 2018 at 5:01:08 PM UTC-4, Michael F. Stemper wrote:
> On 2018-05-20 14:54, bruceg113...@gmail.com wrote:
> > Lets say I have the following tuple like string.
> >(128, 020, 008, 255)
> > 
> > What is the best way to to remove leading zeroes and end up with the 
> > following.
> >(128, 20, 8, 255)-- I do not care about spaces
> 
> 
> I'd use a few regular expressions:
> 
>  >>> from re import sub
>  >>> tuple = '(0128, 020, 008,012, 255)'
>  >>> sub( " 0*", " ", tuple ) # leading zeroes following space(s)
> '(0128, 20, 8,012, 255)'
>  >>> sub( ",0*", ",", tuple ) # leading zeroes following comma
> '(0128, 020, 008,12, 255)'
>  >>> sub( "\(0*", "(", tuple ) # leading zeroes after opening parend
> '(128, 020, 008,012, 255)'
> 
> Each step could be written as "tuple = sub( ..."
> 
>  >>> tuple = sub( " 0*", " ", tuple ) # following space(s)
>  >>> tuple = sub( ",0*", ",", tuple ) # following comma
>  >>> tuple = sub( "\(0*", "(", tuple ) # after opening parend
>  >>> tuple
> '(128, 20, 8,12, 255)'
>  >>>
> 
> 
> Or, if you like to make your code hard to read and maintain, you could
> combine them all into a single expression:
> 
>  >>> sub( " 0*", " ", sub( ",0*", ",", sub( "\(0*", "(", tuple ) ) )
> '(128, 20, 8,12, 255)'
>  >>>
> 
> -- 
> Michael F. Stemper
> What happens if you play John Cage's "4'33" at a slower tempo?



I did not think about using regular expressions.
After your response, I looked into regular expressions and also found  
Regex.Replace
After thinking about my question, I said why not use a replace statement.
This works for me: mytuplestring.replace("0","")

Thanks for a good starting point:)
Bruce
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: best way to remove leading zeros from a tuple like string

[Paul]

>
>
> This works for me: mytuplestring.replace("0","")
>
> Your regex will also eliminate  non-leading zeros.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: best way to remove leading zeros from a tuple like string

[Paul]

On Sun, May 20, 2018, 5:53 PM Paul  wrote:

> This works for me: mytuplestring.replace("0","")
>
>>
>>> Your regex will also eliminate  non-leading zeros.
>>
>>
> If you Google
>
> regex tester
>
> you will find several useful sites where you can test regexes.  Regex
> errors are very common, even after you have experience with them.
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: best way to remove leading zeros from a tuple like string

[bruceg113355]

On Sunday, May 20, 2018 at 5:32:32 PM UTC-4, Paul wrote:
> >
> >
> > This works for me: mytuplestring.replace("0","")
> >
> > Your regex will also eliminate  non-leading zeros.


Your right, what was I thinking?
-- 
https://mail.python.org/mailman/listinfo/python-list

"Data blocks" syntax specification draft

[Mikhail V]

> >
> > Comments, suggestions are welcome.
> >
>
> One comment.
>
> I'm not interested in downloading a PDF. Can you rework your document
> to be in a more textual format like Markdown or reStructuredText?
> Since you're hosting on GitHub anyway, the rendering can be done
> automatically.
>
> ChrisA


What against PDF?
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/Documents/master/data-blocks-v01.html


"Markdown" is too vague - there dozens of markdown styles and
also they include subsets of HTML. It is just plain text with tags -
it cannot represent syntax in civilized form (unless I embed images
for every source example - but then it is too inconvenient for editing).
Source examples on Github will force a crappy font and replace tabs.

I suggest you just view HTML or PDF - it looks better and if you need
source - just download TXT - it has tabs preserved at least.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: best way to remove leading zeros from a tuple like string

[Peter Otten]

bruceg113...@gmail.com wrote:

> Lets say I have the following tuple like string.
>   (128, 020, 008, 255)
> 
> What is the best way to to remove leading zeroes and end up with the
> following.
>   (128, 20, 8, 255)-- I do not care about spaces
> 
> This is the solution I came up with
> s = "(128, 020, 008, 255)"
> v = s.replace ("(", "")
> v = v.replace (")", "")
> vv = ",".join([str(int(i)) for i in v.split(",")])
> final = "(" + vv + ")"

Two more:

>>> s = "(128, 020, 008, 255, -1203,01,-000, -0123)"

>>> str(tuple(map(int, s[1:-1].split(","
'(128, 20, 8, 255, -1203, 1, 0, -123)'

>>> re.sub(r"\b0+\B", "", s)
'(128, 20, 8, 255, -1203,1,-0, -123)'


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

Re: "Data blocks" syntax specification draft

[Ian Kelly]

On Sun, May 20, 2018 at 4:28 PM, Mikhail V  wrote:
> "Markdown" is too vague - there dozens of markdown styles and
> also they include subsets of HTML. It is just plain text with tags

The whole point of Markdown is that it's readable as plain text
precisely because it *doesn't* use obvious tags like HTML.

> it cannot represent syntax in civilized form (unless I embed images
> for every source example - but then it is too inconvenient for editing).

Why would you need images to represent syntax? What's wrong with code blocks?

> Source examples on Github will force a crappy font and replace tabs.

Has it occurred to you that this will also be a problem for anybody
else trying to create examples using this syntax on Github?

> I suggest you just view HTML or PDF - it looks better and if you need
> source - just download TXT - it has tabs preserved at least.

You know, if you're serious about this proposal, then eventually you
will have to write a PEP for it. And that PEP has a required style and
format. And that format is reStructuredText.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Chris Angelico]

On Mon, May 21, 2018 at 8:28 AM, Mikhail V  wrote:
>> >
>> > Comments, suggestions are welcome.
>> >
>>
>> One comment.
>>
>> I'm not interested in downloading a PDF. Can you rework your document
>> to be in a more textual format like Markdown or reStructuredText?
>> Since you're hosting on GitHub anyway, the rendering can be done
>> automatically.
>>
>> ChrisA
>
>
> What against PDF?
> Anyway, I have reloaded files with most recent corrections in various formats:

The very best way to put your proposal is right here in the body of
the email, as plain Unicode (and primarily ASCII) text, no images, no
external links, no side dependencies.

The second best way is to have a simple link that anyone can click on
to read your proposal. It's an external dependency, but you're
depending on a web browser and a basic internet connection, and
nothing more.

Forcing us to download a PDF and then read it? Well, it's your
decision. My decision is that I cannot be bothered going to THAT much
effort to figure out what you're saying. The PDF link you give is not
viewable on the web, and the text file looks like source code for your
PDF, but isn't very readable either.

As Ian says, reStructuredText is the only supported format [1] for
PEPs, so you may as well just start using it straight away. GitHub
automatically renders it if you use a ".rst" extension on your file,
so the rendered form would be visible on the web. Consider:

https://github.com/python/peps/blob/master/pep-0562.rst

I'm not going to read your proposal if you force me to go to heaps of
effort for it. The onus is on YOU to gather support, not on everyone
else to refute it, so it's up to you to publish it accessibly.

ChrisA

[1] Technically plain text is also supported, but not for new PEPs.
-- 
https://mail.python.org/mailman/listinfo/python-list

Poor corporate communication culture - was Re: syntax oddities

[Michael Torrie]

On 05/18/2018 06:25 AM, Paul Moore wrote:
> There are two completely independent cultures here. In "Corporate"
> cultures like where I work (where IT and business functions interact a
> lot, and business users typically use tools like Outlook) top-posting
> is common, conventional, and frankly, effective. 

I beg to differ with you.  I find communication in corporate culture to
be horrible and generally ineffective.  Many times I've written an email
and got a terse, top-posted reply that didn't address my question or
point at all, requiring several emails to finally get the point across.
If the other person had simply trimmed my post to quote my question, and
then replied below it, he'd have got it right the first time, as he'd
have to actually read what I wrote while doing this.  I know I
comprehend much better when I selectively quote.

Nine times out of ten, a top posted reply from a manager is a sure sign
he hasn't bothered to read anything of what I actually wrote. Instead he
just answers the question he thought I asked.

You must work for corporations that are pretty amazing compared to the
average American one.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 3:02 AM, Ian Kelly  wrote:
> On Sun, May 20, 2018 at 4:28 PM, Mikhail V  wrote:
>> "Markdown" is too vague - there dozens of markdown styles and
>> also they include subsets of HTML. It is just plain text with tags
>
> The whole point of Markdown is that it's readable as plain text
> precisely because it *doesn't* use obvious tags like HTML.
>
>> it cannot represent syntax in civilized form (unless I embed images
>> for every source example - but then it is too inconvenient for editing).
>
> Why would you need images to represent syntax? What's wrong with code blocks?

Code blocks where? In what software/webkit it is supposed to be
rendered?
How do you imagine a serious proposal with such syntax comparisons
without ability to make more or less precise presentation in various
fonts?
To speak about significant syntax change seriously you need many samples
in at least 2-3 modern quality fonts. Modulo a pair of reasonable color schemes.
Modern editors (and users) are far beyond type-writer fonts.

>> I suggest you just view HTML or PDF - it looks better and if you need
>> source - just download TXT - it has tabs preserved at least.
>
> You know, if you're serious about this proposal, then eventually you
> will have to write a PEP for it. And that PEP has a required style and
> format. And that format is reStructuredText.

Making reStructuredText is not a problem, but as said - it is not
serious to speak of syntax without good samples. IOW besides a
Markdown PEP such proposal requires a lot of supplementary material.
The best method is to create images of code snippets in addition to
text. Main advantage of images that it will be independent of browser/OS
but it requires some extra job.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Chris Angelico]

On Mon, May 21, 2018 at 2:00 PM, Mikhail V  wrote:
>> The second best way is to have a simple link that anyone can click on
>> to read your proposal. It's an external dependency, but you're
>> depending on a web browser and a basic internet connection, and
>> nothing more.
>>
>> Forcing us to download a PDF and then read it? Well, it's your
>> decision. My decision is that I cannot be bothered going to THAT much
>> effort to figure out what you're saying.
>
> THAT much effort to click two times instead of one - and get a
> formatted document instead of plain bw text. o-kaay..

Two clicks? No, that isn't how it happened for me. I clicked on it and
then I couldn't see the content. What second click am I supposed to do
that shows me the page?

>> As Ian says, reStructuredText is the only supported format [1] for
>> PEPs, so you may as well just start using it straight away. GitHub
>> automatically renders it if you use a ".rst" extension on your file,
>> so the rendered form would be visible on the web.
>
> Ok. How is about images? this proposal will require a lot of images
> - otherwise people who read it are forced to copy-paste snippets
> into their code editors to understand how it may look in reality.

If you're proposing syntax for Python, it's ultimately going to have
to be text. You cannot say "and every text editor has to render it
like this". If you can't demonstrate it using plain text, you have a
major problem on your hands.

>> I'm not going to read your proposal if you force me to go to heaps of
>> effort for it.
>
> heaps! oh come on, youre making up again.

No, I'm not making it up. Just because the PDF works perfectly for
you, you assume that it'll work perfectly for everyone. That is not
the case, and that isn't my problem - it's your problem.

Suppose someone posted a Microsoft Word document, claiming that
Internet Explorer will display it perfectly. Would you accept that,
and say that we should all switch to IE? Would you moan that it's so
easy, and we're just complainers for not wanting to play your games?
Or would we just drop the thread and ignore you thereafter?

I'm not going to debate this with you. If you want people to read your
content, you need to make it accessible; it's much easier for me to
just assume that a proposal that requires a PDF and a bunch of images
simply isn't worth reading.

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

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 5:20 AM, Chris Angelico  wrote:
> On Mon, May 21, 2018 at 8:28 AM, Mikhail V  wrote:
>>> >
>>> > Comments, suggestions are welcome.
>>> >
>>>
>>> One comment.
>>>
>>> I'm not interested in downloading a PDF. Can you rework your document
>>> to be in a more textual format like Markdown or reStructuredText?
>>> Since you're hosting on GitHub anyway, the rendering can be done
>>> automatically.
>>>
>>> ChrisA
>>
>>
>> What against PDF?
>> Anyway, I have reloaded files with most recent corrections in various 
>> formats:
>
> The very best way to put your proposal is right here in the body of
> the email, as plain Unicode (and primarily ASCII) text, no images, no
> external links, no side dependencies.

Well that's the easiest way for me, but - if the document changes constantly
then it is more convenient to have a web link for a document.

> The second best way is to have a simple link that anyone can click on
> to read your proposal. It's an external dependency, but you're
> depending on a web browser and a basic internet connection, and
> nothing more.
>
> Forcing us to download a PDF and then read it? Well, it's your
> decision. My decision is that I cannot be bothered going to THAT much
> effort to figure out what you're saying.

THAT much effort to click two times instead of one - and get a
formatted document instead of plain bw text. o-kaay..

> The PDF link you give is not viewable on the web

Dunno, works for me - I click it and see immediately my PDF in
the browser. But I (and many people) prefer to download anyway.
Also I provided a link to HTML - also works per click and looks even
better than PDF.

> As Ian says, reStructuredText is the only supported format [1] for
> PEPs, so you may as well just start using it straight away. GitHub
> automatically renders it if you use a ".rst" extension on your file,
> so the rendered form would be visible on the web.

Ok. How is about images? this proposal will require a lot of images
- otherwise people who read it are forced to copy-paste snippets
into their code editors to understand how it may look in reality.

> I'm not going to read your proposal if you force me to go to heaps of
> effort for it.

heaps! oh come on, youre making up again.
-- 
https://mail.python.org/mailman/listinfo/python-list