Re: How to print out html tags excluding the attributes

[Rhodri James]

On 21/07/2019 02:04, sum abiut wrote:

I want to use regular expression to print out the HTML tags excluding the
attributes.


That's a very good way of creating hard-to-read code and introducing 
subtle bugs and unexpected behaviours.  Try using an HTML parser like 
BeautifulSoup instead.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Cool Mailing List For Article Writers

[Abdur-Rahmaan Janhangeer]

Greetings all,

There is a really nice list for people writing about Python. Share your
latest articles and get reviews ^^_

Link:
https://mail.python.org/mailman/listinfo/python-authors

Abdur-Rahmaan Janhangeer
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list

asyncio, transports, protocols, etc.

[Hugh Sasse]

Hello,

I'm trying to get my head around asyncio, and I think I'm mostly there 
now, (but expect to be proved wrong :-)!).  It appears to be about the 
newest of the PEPs according to my searches, including PEP 0, so I don't 
expect a huge amount of supporting documentation out there yet.


Looking at:

https://docs.python.org/3/library/asyncio-protocol.html#tcp-echo-server

I know the page introduces the relationships between protocols, 
transports and the servers/clients that use them.  When I read this code 
it took me longer than I would wish :-) to realise that the example 
defining the Echo server was doing this through the protocol, (yes, it 
says it *right there* :-)!) and not a Server class, so for some time I 
was puzzled about where 'transport' was being defined.  Given these 
concepts are new on this page, at least ostensibly, would it make sense 
to introduce this example with something like:


"""
  Create a TCP echo server using the loop.create_server() method, send
  back received data.  This is done by defining the Protocol, which gets
  the transport from the server when it is created by asyncio.
"""

just to refresh the connection between the things in the mind of the reader?

Also, according to my reading of RFC 862, I don't think the Echo server 
should be closing the connection just after echoing:


"""
TCP Based Echo Service

   One echo service is defined as a connection based application on TCP.
   A server listens for TCP connections on TCP port 7.  Once a
   connection is established any data received is sent back.  This
   continues until the calling user terminates the connection.

"""

I could have missed something here though. (If it is this protocol that
is under discussion here, then a link might be useful, as well?)

Why does this matter?  Because it was not clear to me whether the 
closing of the connection was something that had to happen, as part of 
the functionality of the echo service or of asyncio itself.  If I'm 
implementing something that does something based on the cmd or cmd2 
module, interpreting commands, then having some kind of dialogue with 
the server matters.


Writing documentation so that everyone will understand it and NOT get 
the wrong end of the stick is difficult.  I don't know if this would 
make things more confusing for others, or even if it might have helped 
me. At the moment, I think it might be in the right direction, though.


Thank you,

Hugh


--
--
Dr. Hugh Sasse, BSc(Hons), PhD
Computer Systems Electronic Engineer
School of Engineering and Sustainable Development
DE MONTFORT UNIVERSITY



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

Re: Proper shebang for python3

[Tim Daneliuk]

On 7/20/19 4:28 PM, Brian Oney wrote:
> Why not make a compromise? What would be a potential pitfall of the
> following spitbang?
> 
> #!python

Not sure this really changes the discussion.
-- 
https://mail.python.org/mailman/listinfo/python-list

Google Search results pointing to Python 2 (most of the time)

[Santiago Basulto]

Hello community, this is my first email to this list. Sorry if this sounds
dumb, but anytime I do a google search I notice that the first result is
from Python 2 docs. I always have to remind my students about it, and
sometimes I even trip myself.

[image: image.png]

With the deprecation of Py2 so close, wouldn't it be preferable to try
having Python 3 ranking first? I'm not a SEO expert, by maybe adding a
warning title with a link to the corresponding Py3 document might help.
Here's an example:

[image: image.png]

This might require a little bit more thought and some research with someone
that knows about SEO. I just want to start the discussion.

Thanks!

-- 
Santiago Basulto.-
Up!
-- 
https://mail.python.org/mailman/listinfo/python-list

List comprehension strangeness

[Nicholas Cole]

I was profiling a slow function in an application last week, and came
across something that I still can’t explain. Inside a loop that was being
called 4 times, inside a for loop that ran for a few dozen times there was
a list compression of the form:

[x.id for x in some_function()]

According to the profiler, some_function was being called 52,000 times —
many, many times more than the few dozen it should have been. And sure
enough, removing the comprehension did indeed speed up the function.

It is very strange and feels like a possible bug in python. Has anyone ever
encountered anything similar?

Best wishes,

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

Re: List comprehension strangeness

[Calvin Spealman]

It is impossible to diagnose without seeing more context. Specifically,
you'll need to share the code around this line. The whole function,
preferably.

On Mon, Jul 22, 2019 at 9:31 AM Nicholas Cole 
wrote:

> I was profiling a slow function in an application last week, and came
> across something that I still can’t explain. Inside a loop that was being
> called 4 times, inside a for loop that ran for a few dozen times there was
> a list compression of the form:
>
> [x.id for x in some_function()]
>
> According to the profiler, some_function was being called 52,000 times —
> many, many times more than the few dozen it should have been. And sure
> enough, removing the comprehension did indeed speed up the function.
>
> It is very strange and feels like a possible bug in python. Has anyone ever
> encountered anything similar?
>
> Best wishes,
>
> Nicholas
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

cspea...@redhat.com  M: +1.336.210.5107
[image: https://red.ht/sig] 
TRIED. TESTED. TRUSTED. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: List comprehension strangeness

[Bob Gailer]

The function IMHO must be returning a generator. I would look for a problem
in the generator code.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: List comprehension strangeness

[Chris Angelico]

On Mon, Jul 22, 2019 at 11:33 PM Nicholas Cole  wrote:
>
> I was profiling a slow function in an application last week, and came
> across something that I still can’t explain. Inside a loop that was being
> called 4 times, inside a for loop that ran for a few dozen times there was
> a list compression of the form:
>
> [x.id for x in some_function()]
>
> According to the profiler, some_function was being called 52,000 times —
> many, many times more than the few dozen it should have been. And sure
> enough, removing the comprehension did indeed speed up the function.
>

Was it actually being CALLED that many times, or was some part of it
being RUN that many times? Try adding an actual counter to the top of
some_function to see how many times it's being invoked.

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

Re: Embedding Python in C

[Jesse Ibarra]

On Saturday, July 20, 2019 at 1:11:51 PM UTC-6, Stefan Behnel wrote:
> Jesse Ibarra schrieb am 20.07.19 um 04:12:
> > Sorry, I am not understanding. Smalltlak VW 8.3 does not support Python.
> > I can only call Pyhton code through C/Python API.
> 
> Ok, but that doesn't mean you need to write code that uses the C-API of
> Python. All you need to do is:
> 
> 1) Start up a CPython runtime from Smalltalk (see the embedding example I
> posted) and make it import an extension module that you write (e.g. using
> the "inittab" mechanism [1]).
> 
> 2) Use Cython to implement this extension module to provide an interface
> between your Smalltalk code and your Python code. Use the Smalltalk C-API
> from your Cython code to call into Smalltalk and exchange data with it.
> 
> Now you can execute Python code inside of Python and make it call back and
> forth into your Smalltalk code, through the interface module. And there is
> no need to use the Python C-API for anything beyond step 1), which is about
> 5 lines of Python C-API code if you write it yourself. Everything else can
> be implemented in Cython and Python.
> 
> Stefan
> 
> 
> [1]
> https://docs.python.org/3/extending/embedding.html?highlight=PyImport_appendinittab#extending-embedded-python

This cleared so much @Stefan, thank you. I just need some clarification if you 
don't mind.
 
In (1), when you say  "import an extension module that you write",  do you mean 
the Python library that was created "import emb"? Is that gonna be written in 
Cython or standalone .C file?

in (2), what do to mean when you said "Use the Smalltalk C-API from your Cython 
code to call into Smalltalk and exchange data with it."? 

Please advise,

Thank you so much for your help.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: List comprehension strangeness

[Bob Gailer]

The length of the list produced by the comprehension also give you good
information.
-- 
https://mail.python.org/mailman/listinfo/python-list

Transfer Image from Raspberry Pi (Python) to Android app (Java)

[rkartunova--- via Python-list]

Hi everyone! I need help transferring an image via TCP from a python program on 
my raspberry pi to an android application.

I have set up a client-server architecture such that my raspberry pi 3 records 
audio, performs some analysis on it, and then sends the data (via TCP) to the 
android app to display on the app screen. The recording and analysis is done 
and I am able to make the connection and transfer string data that displays on 
the app with no problem. However, I have been unsuccessful in transferring an 
image from rpi to android app. So basically, the image is stored on the rpi and 
I an attempting to transfer the image to the app to display it. I have been 
working on this for over a week with no luck so any help would be greatly 
appreciated!

My current implementation (code snippets provided below):

On rpi (python): Like I said, sending strings and displaying them on the 
android app is done without any problem. When I am sending the image portion of 
the audio analysis, I send a string first that says "?start" so that the 
android side knows that an image instead of a string is about to be sent (and 
will wait to update the GUI until it receives the entire image). Then, I open 
the image stored on rpi and read the entire image as a byte array (typically 
about 40-50k bytes). I get the length of the byte array and send that as a 
string to android app. Finally, I send the byte array to the android and it 
waits for an OK message from the app. All of this works without reporting any 
errors.

On android app (java): When the app receives the "?start" string, it then uses 
a Buffered Reader (which is what I used to read the string data I had 
transferred to the app successfully earlier) to read the size of the image byte 
array. Then, I create 2 buffers, msg_buff and img_buff. msg_buff will read in 
1024 bytes at a time while img_buff will hold the entire byte array of the 
image. In the infinite while loop, I have a DataInputStream, called in, read 
bytes into msg_buff and returns the number of bytes read. Then, I concatenate 
the copied contents of msg_buff into img_buff. Once the bytes read from in is 
-1 or the img_offset (which is just the total number of bytes read) is greater 
than or equal to the size of the image bytes array, the while loop is broken. 
Then, I would attempt to save the image to android internal storage and then 
load it later to an imageView to display it. This code does successfully read 
in the bytes until there are around 2000-3000 bytes left to be read and
  then it seems to freeze on the int bytes_read = in.read(msg_buff, 0, 
msg_buff.length) line. I have not been able to get past that point so I do not 
know if saving the image to internal storage and then loading it to imageview 
that way will work either.

I have also tried using base64 encoding/decoding but that also kept producing 
errors. I have tried rpi only sending 1024 bytes of the image at a time but 
that also did not work. I have tried several implementations of this approach 
but nothing has worked so far. If anyone sees anything wrong or has another 
approach, I am all ears!

Android Studio (app side):

//receives the message which the server sends back 
  InputStream sin = socket.getInputStream(); 
  OutputStream sout = socket.getOutputStream(); 
  DataInputStream in = new DataInputStream(sin);  
  mBufferIn = new BufferedReader(new
  InputStreamReader(socket.getInputStream()));   

//in this while the client listens for the messages sent by the server 
while (mRun) {  
 mServerMessage = mBufferIn.readLine();  
 if (mServerMessage != null && mMessageListener != null) {  
  //Check if data is image 
  if(mServerMessage.equals("?start")) {  
   // Get length of image byte array 
   int size = Integer.parseInt(mBufferIn.readLine());   
 
   // Create buffers 
   byte[] msg_buff = new byte[1024]; 
   byte[] img_buff = new byte[size];
   int img_offset = 0; 

   while(true){ 
int bytes_read = in.read(msg_buff, 0, msg_buff.length);  
if(bytes_read == -1){ break; }  

//copy bytes into img_buff 
System.arraycopy(msg_buff, 0, img_buff, img_offset, 
bytes_read); 
img_offset += bytes_read;   
if( img_offset >= size) { break; } 
   }  
   ContextWrapper cw = new 
ContextWrapper(ApplicationContextProvider.getContext());  
   File directory = cw.getDir("imageDir", Context.MODE_PRIVATE); 
   File mypath = new File(directory, "signal.jpeg");  
   Bitmap bitmap = BitmapFactory.decodeByteArray(img_buff, 0, 
img_buff.length); 
   FileOutputStream fos = null;  
   try{  
fos = new FileOutputStream(mypath);  

Re: Extendable Enum like Type?

[Ethan Furman]

On 07/19/2019 01:23 AM, Antoon Pardon wrote:


I don't seem to have made myself clear. The grammar with its Terminals
and NonTerminals is read in from a file. The program doesn't know what
they will be.

For the moment what I am thinking about is something as follows:

grammar = LoadGrammer(GrammarFile)
EnumList = ['class NonTerminal(Enum):\n']
for Index, NonTerminal in enumerate(grammar.NonTerminals):
 EnumList.append('%s = %d\n' % (NonTerminal, Index))
exec(''.join(EnumList), ..., ...)

The problem with this approach is that I can't use these values until
the whole grammer is loaded. I would prefer some way to add values
during the loading of the grammar.


Ah, you want `extend_enum` from the aenum library:

class NonTerminal(Enum):
pass

while reading_grammar:
non_terminal = 
index = 
extend_enum(NonTerminal, non_terminal, index)


See also:
- https://stackoverflow.com/a/33680929/208880
- https://stackoverflow.com/a/35899963/208880
- https://stackoverflow.com/a/36918171/208880
- https://stackoverflow.com/a/43004033/208880

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

Creating time stamps

[Michael F. Stemper]

I have some code that generates a time-stamp as follows:

  from datetime import datetime
  tt = datetime.now()
  timestamp = "%4d-%02d-%02d %02d:%02d" % \
(tt.year, tt.month, tt.day, tt.hour, tt.minute)

I later realized that I could have written it as:

  from datetime import datetime
  from time import strftime
  timestamp = datetime.now().strftime( "%Y-%m-%d %H:%M" )

The first seems a little clunky with its accessing of multiple
attributes, but the second has an additional import. Is there
any reason to prefer one over the other?

-- 
Michael F. Stemper
There's no "me" in "team". There's no "us" in "team", either.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Creating time stamps

[Chris Angelico]

On Tue, Jul 23, 2019 at 6:34 AM Michael F. Stemper
 wrote:
>
> I have some code that generates a time-stamp as follows:
>
>   from datetime import datetime
>   tt = datetime.now()
>   timestamp = "%4d-%02d-%02d %02d:%02d" % \
> (tt.year, tt.month, tt.day, tt.hour, tt.minute)
>
> I later realized that I could have written it as:
>
>   from datetime import datetime
>   from time import strftime
>   timestamp = datetime.now().strftime( "%Y-%m-%d %H:%M" )
>
> The first seems a little clunky with its accessing of multiple
> attributes, but the second has an additional import. Is there
> any reason to prefer one over the other?
>

What's the second import doing though? You never use strftime. I'd go
with the second one, but with just a single import.

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

Re: Creating time stamps

[Skip Montanaro]

Assuming you're using Python 3, why not use an f-string?

>>> dt = datetime.datetime.now()
>>> dt.strftime("%Y-%m-%d %H:%M")
'2019-07-22 16:10'
>>> f"{dt:%Y-%m-%d %H:%M}"
'2019-07-22 16:10'

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

Re: Proper shebang for python3

[Eli the Bearded]

In comp.lang.python, Tim Daneliuk   wrote:
> On 7/20/19 1:20 PM, Chris Angelico wrote:
> > On Sun, Jul 21, 2019 at 4:13 AM Michael Speer  wrote:
> >> You may want to use `#!/usr/bin/env python3` instead.

I no longer have one to verify, but I recall Solaris boxen used /bin/env
not /usr/bin/env.

> So, no, do NOT encode the hard location - ever.  Always use env to
> discover the one that the user has specified. 

But wait, you just hard coded the location of env...

>The only exception is
> /bin/sh which - for a variety of reasons - can reliably counted upon.

B! Fully half of my work porting trn4 to my cellphone was fixing all
the places that ancient build system believed /bin/sh was the name of
sh. In that environment (Termux shell on an Android phone) the location
is /data/data/com.termux/files/usr/bin/sh (and env is also in
/data/data/com.termux/files/usr/bin hahaha).

Even on more traditional environments -cough-Solaris-cough- /bin/sh may
exist but be so ancient as to break things that work elsewhere. "^" as
a synonym for "|", is a noteworthy gotcha.

Figuring out where things are on the user's path is a laudable goal, but
do it only at install time, not run time, for consistent runs.

Elijah
--
pathological edge cases -r- us
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Proper shebang for python3

[אורי]

We are using `#!/usr/bin/env python`, for example on
https://github.com/speedy-net/speedy-net/blob/master/speedy/core/manage.py

For bash we are using `#!/usr/bin/env bash`. I don't know if those are the
best but they work.

אורי
u...@speedy.net


On Sat, Jul 20, 2019 at 9:12 PM Michael Speer  wrote:

> You may want to use `#!/usr/bin/env python3` instead.
>
> There is a concept in python called the virtual environment. This used to
> be done with a tool called virtualenv in python2, and is now done mainly
> through a venv module in python3.
>
> A virtual environment goes into a directory of your choosing and will have
> its own python3 executable, and pip3 executable, and when you add
> dependencies, they are also placed into the directory structure under your
> chosen directory.
>
> When you do a `. /bin/activate` the included source will places
> the virtual environment's bin/ folder at the beginning of your PATH
> environment variable, making it the default python3 when you type it
> without a full path.
>
> This allows you to run scripts that need different, or even conflicting,
> sets of dependencies without bothering with the underlying linux
> distribution's python installation's modules.
>
> If you use `#!/usr/bin/python3`, it will always use exactly the system
> version that is installed, and the system's installed modules.
>
> Your scripts will still default to the system installation if a virtual
> environment is not activated. So you lose nothing by doing it this way, but
> gain a little control from it.
>
>
> On Sat, Jul 20, 2019 at 1:41 PM Manfred Lotz  wrote:
>
> > Hi there,
> > Pretty new to python I've got a question regarding the proper shebang
> > for Python 3.
> >
> > I use
> >#!/usr/bin/python3
> >
> > which works fine.
> >
> > Today I saw
> >#!/usr/bin/python3 -tt
> >
> > and was wondering what -tt means.
> >
> > Being on Fedora 30, Python 3.7.3 the man page of python3 doesn't even
> > mention -t.
> >
> > python 2 man page mentions
> >
> >-t Issue a warning when a source file mixes tabs and spaces
> >for indentation in a way that makes  it  depend  on  the worth
> >of a tab expressed in spaces.  Issue an error when the option is
> >given twice.
> >
> > I guess that -t has the same meaning with python 3.7.3.
> >
> >
> > My questions:
> >
> > 1. Is my guess correct?
> >
> > 2. Is it a bug that it is not mentioned? python3 --help doesn't mention
> > it either.
> >
> >
> > --
> > Manfred
> >
> >
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> >
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Creating time stamps

[Albert-Jan Roskam]

On 22 Jul 2019 23:12, Skip Montanaro  wrote:

Assuming you're using Python 3, why not use an f-string?

>>> dt = datetime.datetime.now()
>>> dt.strftime("%Y-%m-%d %H:%M")
'2019-07-22 16:10'
>>> f"{dt:%Y-%m-%d %H:%M}"
'2019-07-22 16:10'

===》》 Or if you're running < Python 3.6 (no f strings): format(datetime.now(), 
"%Y-%m-%d %H:%M")
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Creating time stamps

[Michael F. Stemper]

On 22/07/2019 15.58, Chris Angelico wrote:
> On Tue, Jul 23, 2019 at 6:34 AM Michael F. Stemper
>  wrote:
>>
>> I have some code that generates a time-stamp as follows:
>>
>>   from datetime import datetime
>>   tt = datetime.now()
>>   timestamp = "%4d-%02d-%02d %02d:%02d" % \
>> (tt.year, tt.month, tt.day, tt.hour, tt.minute)
>>
>> I later realized that I could have written it as:
>>
>>   from datetime import datetime
>>   from time import strftime
>>   timestamp = datetime.now().strftime( "%Y-%m-%d %H:%M" )
>>
>> The first seems a little clunky with its accessing of multiple
>> attributes, but the second has an additional import. Is there
>> any reason to prefer one over the other?
> 
> What's the second import doing though? You never use strftime.

Cleaned my contacts, cleaned my readers. Still see strftime() in the
third line. Tried to run the code without the second line. It ran
without complaint.

Apparently, the strftime() in that last line is not the one that I
explicitly imported, but a method of datetime.now(). Did I get that
right?


>   I'd go
> with the second one, but with just a single import.

Sounds like a winner to me. Thanks.


-- 
Michael F. Stemper
87.3% of all statistics are made up by the person giving them.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Creating time stamps

[Grant Edwards]

On 2019-07-22, Michael F. Stemper  wrote:

>>>   from datetime import datetime
>>>   from time import strftime
>>>   timestamp = datetime.now().strftime( "%Y-%m-%d %H:%M" )
[...]
> Apparently, the strftime() in that last line is not the one that I
> explicitly imported, but a method of datetime.now(). Did I get that
> right?

Exactly.

-- 
Grant Edwards   grant.b.edwardsYow! TONY RANDALL!  Is YOUR
  at   life a PATIO of FUN??
  gmail.com

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

Re: Creating time stamps

[MRAB]

On 2019-07-22 22:41, Grant Edwards wrote:

On 2019-07-22, Michael F. Stemper  wrote:


  from datetime import datetime
  from time import strftime
  timestamp = datetime.now().strftime( "%Y-%m-%d %H:%M" )

[...]

Apparently, the strftime() in that last line is not the one that I
explicitly imported, but a method of datetime.now(). Did I get that
right?


Exactly.


You can tell that it's a method because it's:

something.strftime(...)

If it was using the imported 'strftime' then it would be:

timestamp = strftime(...)
--
https://mail.python.org/mailman/listinfo/python-list

Re: Creating time stamps

[Michael F. Stemper]

On 22/07/2019 16.00, Stefan Ram wrote:
> "Michael F. Stemper"  writes:
>> The first seems a little clunky with its accessing of multiple
>> attributes, but the second has an additional import. Is there
>> any reason to prefer one over the other?
> 
> |>>> import datetime
> |>>> datetime.datetime.now().replace(microsecond=0).isoformat()
> |'2019-07-22T21:59:58'

Yeah, if I'd wanted that format, isoformat() would have been simpler.
Since I did not want seconds, or the letter "T", I had to go for a
home-brewed solution.

-- 
Michael F. Stemper
No animals were harmed in the composition of this message.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: List comprehension strangeness

[Gregory Ewing]

Nicholas Cole wrote:
 [x.id for x in some_function()]


According to the profiler, some_function was being called 52,000 times


Is some_function recursive, by any chance?

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

Re: Namespaces: memory vs 'pollution'

[Ethan Furman]

On 07/20/2019 05:02 PM, DL Neil wrote:


Upon closer inspection, I realised it didn't just fail; it failed badly! Some 
silly, little, boy had imported the PythonEnvironment class but failed to ALSO 
import PythonVersionError. So, the reported error was not the expected 
exception!


I don't understand the significance of not importing PythonVersionError:

- PythonEnvironment does not need it to be imported

- when PythonEnvironment raises PythonVersionError you still get 
PythonVersionError

- if your code says `except PythonVersionError` and you haven't imported it 
you'll get a NameError

So, what's the issue?

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

Re: Proper shebang for python3

[Cameron Simpson]

On 22Jul2019 21:14, Eli the Bearded <*@eli.users.panix.com> wrote:

In comp.lang.python, Tim Daneliuk   wrote:

On 7/20/19 1:20 PM, Chris Angelico wrote:
> On Sun, Jul 21, 2019 at 4:13 AM Michael Speer  wrote:
>> You may want to use `#!/usr/bin/env python3` instead.


I no longer have one to verify, but I recall Solaris boxen used /bin/env
not /usr/bin/env.


That is my recollection too. A pain point. To the point that I'd hand 
make a /usr/bin/env symlink.


Why _any_ modern system has anything other than /bin in the base install 
escapes me.  In the distant past /sbin and a distinct /usr with its own 
bin had their values, but these days? Bah!


(I'm not complaining about /usr/local/bin here - keeping added stuff 
distinct from the vendor/distributor stuff is very valuable.)



So, no, do NOT encode the hard location - ever.  Always use env to
discover the one that the user has specified.


But wait, you just hard coded the location of env...


Yeah. Too many boots, too many straps.


   The only exception is
/bin/sh which - for a variety of reasons - can reliably counted upon.


B! Fully half of my work porting trn4 to my cellphone was fixing all
the places that ancient build system believed /bin/sh was the name of
sh. In that environment (Termux shell on an Android phone) the location
is /data/data/com.termux/files/usr/bin/sh (and env is also in
/data/data/com.termux/files/usr/bin hahaha).


I'd do the symlink thing there too, if feasible. (Counterpoint: I've a 
DVR here where changes to / don't survive a reboot and there's no 
/etc/rc.local like file which survives a reboot either.)


POSIX systems have a /bin/sh. I would move heaven itself to ensure this.


Even on more traditional environments -cough-Solaris-cough- /bin/sh may
exist but be so ancient as to break things that work elsewhere. "^" as
a synonym for "|", is a noteworthy gotcha.


Aye. I still quote ^ in my scripts to this day for this reason. But 
then, I learnt shell programming on V7 UNIX, well older than Solaris.



Figuring out where things are on the user's path is a laudable goal, but
do it only at install time, not run time, for consistent runs.


Perhaps. Consistent runs require consistent environments. That often 
includes executables.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Proper shebang for python3

[Cameron Simpson]

On 23Jul2019 00:19, אורי  wrote:

We are using `#!/usr/bin/env python`, for example on
https://github.com/speedy-net/speedy-net/blob/master/speedy/core/manage.py

For bash we are using `#!/usr/bin/env bash`. I don't know if those are the
best but they work.


Worthwhile. Plenty of platforms do not install bash in /bin.

Though personally I only VERY RARELY want bash for a shell script.  
/bin/sh is portable and the extras in bash have relatively little value 
in scripting; by the time your script really wants them it is usually 
worth moving to a more expressive language. Like Python.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Transfer Image from Raspberry Pi (Python) to Android app (Java)

[Gregory Ewing]

rkartun...@yahoo.com wrote:

This
code does successfully read in the bytes until there are around 2000-3000
bytes left to be read and then it seems to freeze on the int bytes_read =
in.read(msg_buff, 0, msg_buff.length) line.


This happens because you're trying to read more bytes than the sender
is sending. The receiver is trying to read a whole bufferful and has no
way to know that there aren't any more bytes coming, so it waits forever.

Your receiver needs to read exactly the right number of bytes. Keep
track of the number of bytes left to read, and when it's less than
the buffer size, issue a read for just that number instead of a whole
bufferful.

(The code you have would work if the sender closed its end of the
connection after sending the image, but you can't do that if you
want to get an OK message back.)

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

Re: Namespaces: memory vs 'pollution'

[Thomas Jollans]

On 22/07/2019 07.06, DL Neil wrote:
>
> Current thoughts:
>
> import environment_module as em
>
> - so, even more of an abbreviation than suggested!?
> - I rarely need to write a long list of import statements, so there
> won't be many.
> - not normally using such abbreviations in my code, they will stand-out.
> - considered using upper-case, eg "EM" - it is a form of constant
> after-all


Just FYI, in the scientific Python community certain short abbreviations
are the norm. Many modules have a ‘standard’ abbreviation that most
people use, minimizing confusion.

import numpy as np
import matplotlib as mpl
from matplotlib import pyplot as plt
import pandas as pd
import xarray as xr

and so on.

As long as you're consistent and use the same abbreviation across your
entire codebase, and you put the imports at the top where people can
find them, I think using 2–4 letter abbreviations, even without any
decoration, is a fine approach.

-- Thomas


> - considered adding a single under(-line) suffix, eg "em_" (on the
> basis of "made you think"). No, don't make me think (too much)!
> - so, perhaps a two-letter abbreviation with a single under(-line), eg
> "e_m", won't be confused with other naming conventions and yet
> stands-out. (sadly, that is "stands-out" to me, but 'everyone else'
> won't know its significance...)
>
> The try...except construct is a brilliant idea because it does exactly
> what I asked - requires both the class (what I wanted to include) AND
> the custom-exception class (what it needs included).
>
> If the class does not have any related error classes, then the
> try...except can simply check for 'exists?'...
>
>
> It's a habit I'm about to adopt. Many thanks! 

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

Re: Namespaces: memory vs 'pollution'

[DL Neil]

On 23/07/19 11:00 AM, Ethan Furman wrote:

On 07/20/2019 05:02 PM, DL Neil wrote:

Upon closer inspection, I realised it didn't just fail; it failed 
badly! Some silly, little, boy had imported the PythonEnvironment 
class but failed to ALSO import PythonVersionError. So, the reported 
error was not the expected exception!


I don't understand the significance of not importing PythonVersionError:

- PythonEnvironment does not need it to be imported

- when PythonEnvironment raises PythonVersionError you still get 
PythonVersionError


- if your code says `except PythonVersionError` and you haven't imported 
it you'll get a NameError


So, what's the issue?



Have I correctly understood the question?

NameError conveys nothing to the user.
PythonVersionError is more communicative - and speaks volumes to 'us'.

The mainline code is something like:

p = PythonEnvironment()
try:
p.compatibility( ...spec... )   # eg must be Py3 not 2.n
except PythonVersionError:
print( more illuminating errmsg )

If I am 'the user' I'd be quite happy without the try...except; but mere 
mortals need/deserve something more. Accordingly, the PythonVersionError 
custom exception/class.


Yes, we could trap NameError, but that might also catch other 
name-errors (unlikely in this example, but 'just sayin'). Thus the 
greater specificity of the custom class.



NB please see alternative 'solution' proposed (for critique) as "Nesting 
Custom Errors in Classes" discussion topic.

--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Nesting Custom Errors in Classes

[DL Neil]

Do you use nested classes?

[following-on from the earlier, "Namespaces: memory vs 'pollution'" 
discussion thread, wherein a certain 'someone' remembered to from ... 
import ... as ... an 'action' class but forgot to also import the 
related custom error class! The original quest was for a wild-card 
import device. This discussion may obviate continuing the quest and/or 
needing to remember...]



Python manages nested classes.

I've NEVER seen such 'in the wild'.
(but perhaps I lead a sheltered life?)


What are proposed as use-cases for such a technique?
- other languages may not offer decent "inheritance", and this is an 
alternative method/hack

- the class is a 'class factory', generating/returning an object
? any others


Why not use it as an "encapsulation" device?
(please be gentle - reminder: I am too old to have been an OO-native!)


* stub definitions

>>> class PythonEnvironment():
... class PythonVersionError( EnvironmentError ):
... pass
... def iscompatible( self ):
''' Ensure that the Python in-use will support
all of the facilities employed by the application.
'''
... # stub to simulate failure
... raise self.PythonVersionError
...

(code would require an import or from ... import ...)
>>> pe = PythonEnvironment()


* its basic application becomes:-

>>> pe.iscompatible()
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 6, in compatibility
__main__.PythonVersionError


* somewhat more realistic use:-

>>> try:
... pe.iscompatible()
... except PythonEnvironment.PythonVersionError:
... print( "Trapped! -> informative errmsg" )
...
Trapped! -> informative errmsg


With this construct, one only has to import the 'outer' class, rather 
than both the class AND its ancillary error class!



Why haven't I seen it before? Can you see anything 'wrong' with this 
picture?

--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Namespaces: memory vs 'pollution'

[DL Neil]

On 22/07/19 9:40 PM, Thomas Jollans wrote:

On 22/07/2019 07.06, DL Neil wrote:


Current thoughts:

 import environment_module as em

- so, even more of an abbreviation than suggested!?
- I rarely need to write a long list of import statements, so there
won't be many.
- not normally using such abbreviations in my code, they will stand-out.
- considered using upper-case, eg "EM" - it is a form of constant
after-all



Just FYI, in the scientific Python community certain short abbreviations
are the norm. Many modules have a ‘standard’ abbreviation that most
people use, minimizing confusion.

import numpy as np
import matplotlib as mpl
from matplotlib import pyplot as plt
import pandas as pd
import xarray as xr

and so on.

As long as you're consistent and use the same abbreviation across your
entire codebase, and you put the imports at the top where people can
find them, I think using 2–4 letter abbreviations, even without any
decoration, is a fine approach.



+1
Thanks for this.

Wow, but my little/personal utilities are far from such 'exalted' company!

The important provision is that 'everyone' (affected) understands. As 
long as we all come from the same subject-domain, eg statisticians, then 
there's no problem with 'breaking the rules' because such abbreviations 
are easily-understood 'symbols', by definition.


After all, PEP-8 does say: "names ... [should] reflect usage"!

However, I'd never concede that to a group of 'commerce' trainees, for 
example!


The use of meaningful names is a minimum professional standard (IMHO), 
and in my experience, a virtue that pays for itself. I am ever-so 
grateful that most modern text-editors will guess/read-my-mind and save 
the typing!


--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list