Re: [Tutor] Broadcasting using sockets over adhoc wifi

[Cameron Simpson]

On 11Jun2019 10:35, John Hoeksema  wrote:

Summer researcher using Raspbian and Python 3.5.

I'm trying to use a Raspberry Pi 3 B+ to broadcast a message using the
sockets library to other Pis (same model) over their shared ad-hoc network.
All of the Pis can ping the others over the ad hoc network. The Pis can
also communicate using pretty standard client-server code and the python
socket library . However,
when I try to *broadcast* a message, the Pis give a "Network is
unreachable" message (full error down below). A grad student I'm working
with said that the script he provided me expects the server to be run in
infrastructure mode, and configuration for ad-hoc mode is required to make
it work correctly. This is confirmed, as I have successfully run the code
on a desktop. I have poured over man pages and stackoverflow, and can't
seem to find resources for how to configure socket broadcasts for ad-hoc
networks. Any thoughts?


I would start by debugging a bit outside of Python first. And I've never 
used an ad hoc wifi network, but after setup I _imagine_ that it looks 
like a normal local network: an IP address and a network mask, so 
"braodcast" is the usual notion of the IP address with all 1s in the 
local part.


So 1:

Does a manual command line "ping" of the broadcast address work? Eg, if 
the local network were 192.168.3.x/24 and I went:


 ping 192.168.3.255

(or on Linux):

 ping -b 192.168.3.255

I'm assuming your '' below is an actualy broadcast address?  
Or is it a special string? If so, what happens if you hand construct a 
broadcast IP like the *.255 above? Any different?


Does tcpdump show anything useful, either locally or on one of the other 
Pis? Though given "Network is unreachable" I'd guess no packets get sent 
at all.


I repeat my disclaimer: I've not used an ad hoc wifi network.

Cheers,
Cameron Simpson 
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running Lib/test/test_shutil.py

[Mats Wichmann]

On 6/13/19 12:19 PM, Peter Otten wrote:
> Tom Hale wrote:
> 
>> Hi all,
>>
>> I hope this is the best place to ask (please let me know if there is a
>> more appropriate list):
>>
>> Checking out CPython v3.8.0b1, I'm trying to run:
>>
>>% python Lib/test/test_shutil.py
> 
> Are you sure 
> 
> % python
> 
> invokes the 3.8 interpreter? 
> 
>> I'm getting:
>>
>> Traceback (most recent call last):
>>File "Lib/test/test_shutil.py", line 19, in 
>>  from shutil import (make_archive,
>> ImportError: cannot import name '_GiveupOnFastCopy' from 'shutil'
>> (/usr/lib/python3.7/shutil.py)
>>
> 
> The traceback suggests that it may be 3.7.

and indeed _GiveupOnFastCopy is a 3.8-only thing (an exception, it turns
out), so this must be the deal.

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running Lib/test/test_shutil.py

[Peter Otten]

Tom Hale wrote:

> Hi all,
> 
> I hope this is the best place to ask (please let me know if there is a
> more appropriate list):
> 
> Checking out CPython v3.8.0b1, I'm trying to run:
> 
>% python Lib/test/test_shutil.py

Are you sure 

% python

invokes the 3.8 interpreter? 

> I'm getting:
> 
> Traceback (most recent call last):
>File "Lib/test/test_shutil.py", line 19, in 
>  from shutil import (make_archive,
> ImportError: cannot import name '_GiveupOnFastCopy' from 'shutil'
> (/usr/lib/python3.7/shutil.py)
> 

The traceback suggests that it may be 3.7.

Try

% ./python Lib/test/test_shutil.py

or, if you have installed python3.8

% python3.8 Lib/test/test_shutil.py

If you still get an error with a path into the /usr/lib/python3.7 stdlib
have a look at the PYTHONPATH environment variable.

> Am I trying to run the test file in the right way?
> 
> Context: I'm proposing to add /shutil.(sym)?link/ and want to start
> writing my tests with running the existing tests :)
> 
> Is there a doc that I've missed?
> 
> Cheers!
> 


___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Tutor] Running Lib/test/test_shutil.py

[Tom Hale]

Hi all,

I hope this is the best place to ask (please let me know if there is a 
more appropriate list):


Checking out CPython v3.8.0b1, I'm trying to run:

  % python Lib/test/test_shutil.py

I'm getting:

Traceback (most recent call last):
  File "Lib/test/test_shutil.py", line 19, in 
from shutil import (make_archive,
ImportError: cannot import name '_GiveupOnFastCopy' from 'shutil' 
(/usr/lib/python3.7/shutil.py)


Am I trying to run the test file in the right way?

Context: I'm proposing to add /shutil.(sym)?link/ and want to start 
writing my tests with running the existing tests :)


Is there a doc that I've missed?

Cheers!

--
Tom Hale
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Where to store test-code?

[Mats Wichmann]

On 6/13/19 2:22 AM, Thomas Güttler wrote:
> Up to now I use this structure:
> 
> src/myapp/setup.py
> src/myapp/myapp/real_code.py
> 
> Now I want to write a test for a method which is implemented real_code.py.
> 
> Where should I write store the file which contains the unittest?
> 
> Is there a guideline for the directory structure of tests?
> 
> I know that there are several ways. I know that all these ways work.
> Nevertheless
> it would be great to have a sane default. If there is a guideline IDEs
> could assist
> to create new tests at a common location.

This question gets asked all the time, and it's hard to answer.

Other than the general requirement that the placement of the test should
not make it hard to find the code to be tested, *your* answer will be
determined by the scope of the project and by preferences.

You can put tests inline in the docstring, if you want to use doctest.
People dismiss this as a viable alternative, but the Python standard
library does this in some places - you don't get to write exhaustive
unit tests this way, but you can have something that serves as an
example and a quick test at the same time.  For some examples, try this:

pydoc difflib

(hopefully you're not on Windows where that's probably not in the search
path)

If using pytest or unittest, you can put your tests in the same
directory as the code to be tested, naming the test file for foo.py as
test_foo.py, that way they're picked up automatically. For your example,
in src/myapp/myapp.

If you want separation of your app/module code and the tests , you can
put them a level up, thus src/myapp.

If you will have a lot of "source" files, you'll probably want a
parallel directory (probably simplifies deploy, if you intend to deploy
the code without the tests), thus src/myapp/tests (which is what it
sounds like what you're angling for us to tell you :) ).  If you do that
though, there's a complication - tests will now have a harder time
finding the module code which is to be imported in running the tests,
and you'll have to take a few extra steps to make that work right.

If this were a TV courtroom drama someone would have risen to say
"objection, calls for speculation" - these things don't have an absolute
answer.

Anyway, the pytest project has some commentary on this that will likely
be more well thought out than my ramblings:

https://docs.pytest.org/en/latest/goodpractices.html

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Tutor] Where to store test-code?

[Thomas Güttler]

Up to now I use this structure:

src/myapp/setup.py
src/myapp/myapp/real_code.py

Now I want to write a test for a method which is implemented real_code.py.

Where should I write store the file which contains the unittest?

Is there a guideline for the directory structure of tests?

I know that there are several ways. I know that all these ways work. 
Nevertheless
it would be great to have a sane default. If there is a guideline IDEs could 
assist
to create new tests at a common location.

Related: https://youtrack.jetbrains.com/issue/JT-53069

Regards,
  Thomas



--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor