Python arguments

Original post here:

Arguments are passed by assignment. The rationale behind this is twofold:

  1. the parameter passed in is actually a reference to an object (but the reference is passed by value)
  2. some data types are mutable, but others aren’t

So:

  • If you pass a mutable object into a method, the method gets a reference to that same object and you can mutate it to your heart’s delight, but if you rebind the reference in the method, the outer scope will know nothing about it, and after you’re done, the outer reference will still point at the original object.
  • If you pass an immutable object to a method, you still can’t rebind the outer reference, and you can’t even mutate the object.

To make it even more clear, let’s have some examples.

List – a mutable type

Let’s try to modify the list that was passed to a method:

def try_to_change_list_contents(the_list):
    print('got', the_list)
    the_list.append('four')
    print('changed to', the_list)

outer_list = ['one', 'two', 'three']

print('before, outer_list =', outer_list)
try_to_change_list_contents(outer_list)
print('after, outer_list =', outer_list)

Output:

before, outer_list = ['one', 'two', 'three']
got ['one', 'two', 'three']
changed to ['one', 'two', 'three', 'four']
after, outer_list = ['one', 'two', 'three', 'four']

Since the parameter passed in is a reference to outer_list, not a copy of it, we can use the mutating list methods to change it and have the changes reflected in the outer scope.

Now let’s see what happens when we try to change the reference that was passed in as a parameter:

def try_to_change_list_reference(the_list):
    print('got', the_list)
    the_list = ['and', 'we', 'can', 'not', 'lie']
    print('set to', the_list)

outer_list = ['we', 'like', 'proper', 'English']

print('before, outer_list =', outer_list)
try_to_change_list_reference(outer_list)
print('after, outer_list =', outer_list)

Output:

before, outer_list = ['we', 'like', 'proper', 'English']
got ['we', 'like', 'proper', 'English']
set to ['and', 'we', 'can', 'not', 'lie']
after, outer_list = ['we', 'like', 'proper', 'English']

Since the the_list parameter was passed by value, assigning a new list to it had no effect that the code outside the method could see. The the_list was a copy of the outer_list reference, and we had the_list point to a new list, but there was no way to change where outer_listpointed.

String – an immutable type

It’s immutable, so there’s nothing we can do to change the contents of the string

Now, let’s try to change the reference

def try_to_change_string_reference(the_string):
    print('got', the_string)
    the_string = 'In a kingdom by the sea'
    print('set to', the_string)

outer_string = 'It was many and many a year ago'

print('before, outer_string =', outer_string)
try_to_change_string_reference(outer_string)
print('after, outer_string =', outer_string)

Output:

before, outer_string = It was many and many a year ago
got It was many and many a year ago
set to In a kingdom by the sea
after, outer_string = It was many and many a year ago

Again, since the the_string parameter was passed by value, assigning a new string to it had no effect that the code outside the method could see. The the_string was a copy of the outer_string reference, and we had the_string point to a new string, but there was no way to change where outer_string pointed.

I hope this clears things up a little.

EDIT: It’s been noted that this doesn’t answer the question that @David originally asked, “Is there something I can do to pass the variable by actual reference?”. Let’s work on that.

How do we get around this?

As @Andrea’s answer shows, you could return the new value. This doesn’t change the way things are passed in, but does let you get the information you want back out:

def return_a_whole_new_string(the_string):
    new_string = something_to_do_with_the_old_string(the_string)
    return new_string

# then you could call it like
my_string = return_a_whole_new_string(my_string)

If you really wanted to avoid using a return value, you could create a class to hold your value and pass it into the function or use an existing class, like a list:

def use_a_wrapper_to_simulate_pass_by_reference(stuff_to_change):
    new_string = something_to_do_with_the_old_string(stuff_to_change[0])
    stuff_to_change[0] = new_string

# then you could call it like
wrapper = [my_string]
use_a_wrapper_to_simulate_pass_by_reference(wrapper)

do_something_with(wrapper[0])

Although this seems a little cumbersome.

ARP request

ARP requests are never forwarded to reach the end host in IP-routed networks. [original post]

“There will never be an ARP request from “the internet” asking about the address for one of your hosts. IP addresses are used for end-to-end routing. Hardware addresses are used only for single hops. So if some host on the internet sends a ping, every router along the way will look at the destination IP address, consult its routing table for the next hop (IP address) in the right direction, and send the packet to the next hop host or router. To do that very last step (forward the packet to the next hop), the router needs to know the hardware address of the next hop. But it does not need to know the hardware address of the destination host. This means that arp requests are never forwarded. They are only generated for IP addresses that are directly attached to the router that is sending the request. So no router except yours will ever send an arp request for the hosts that are serviced by your router.”

ARP request for address 0.0.0.0 means that each host which receives the request must reply. [original post]

“The address ‘0.0.0.0’ is the ‘any’ address. That means, ‘any’ host should answer that request.”

Compiling error of hping: “DBYTE_ORDER_(BIG|LITTLE)_ENDIAN”

Taken from the original post.
Symptom:

[root@localhost hping3]#./configure

bytesex.h:22:3: error: #error can not find the byte order for this architecture, fix bytesex.h

In file included from rapd.c:11:
 ars.h:190:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)_ENDIAN"
 ars.h:254:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)_ENDIAN"
 ars.h:323:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)_ENDIAN"
 In file included from ars.h:20,
 from split.c:11:
 bytesex.h:22:3: error: #error can not find the byte order for this architecture, fix bytesex.h
 In file included from split.c:11:
 ars.h:190:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)_ENDIAN"
 ars.h:254:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)_ENDIAN"
 ars.h:323:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)_ENDIAN"
 now you can try `make'

To resolve:

Since this was a x86_64 architecture, and it was not in the bytesex.h you just need to add in a line as below  and ./configure again.
[root@localhost hping3-20051105]# cat bytesex.h
/* Original code from the Linux C library */

/* Copyright (C) 2000,2001 Salvatore Sanfilippo

 * This code is under the original GNU C library license (GPL) */

/* $Id: bytesex.h,v 1.1.1.1 2003/08/31 17:23:48 antirez Exp $ */

#ifndef ARS_BYTESEX_H
#define ARS_BYTESEX_H

#if     defined(__i386__) \
        || defined(__alpha__) \
        || defined(__x86_64__) \
        || (defined(__mips__) && (defined(MIPSEL) || defined (__MIPSEL__)))
#define BYTE_ORDER_LITTLE_ENDIAN

#elif   defined(__mc68000__) \
        || defined (__sparc__) \
        || defined (__sparc) \
        || defined (__PPC__) \
        || defined (__BIG_ENDIAN__) \
        || (defined(__mips__) && (defined(MIPSEB) || defined (__MIPSEB__)))

#define BYTE_ORDER_BIG_ENDIAN

#else

# error can not find the byte order for this architecture, fix bytesex.h

#endif


#endif /* ARS_BYTESEX_H */

How to connect OpenFlow switches to multiple controllers (Mininet)

Original post is here.

#!/usr/bin/python

from mininet.net import Mininet
from mininet.node import Controller, RemoteController
from mininet.cli import CLI
from mininet.log import setLogLevel, info

def myNet():


    #OpenDayLight controller
    ODL_CONTROLLER_IP='10.0.0.4'

    #Floodlight controller
    FL_CONTROLLER_IP='10.0.0.5'

    net = Mininet( topo=None, build=False)

    # Create nodes
    h1 = net.addHost( 'h1', mac='01:00:00:00:01:00', ip='192.168.0.1/24' )
    h2 = net.addHost( 'h2', mac='01:00:00:00:02:00', ip='192.168.0.2/24' )

    # Create switches
    s1 = net.addSwitch( 's1', listenPort=6634, mac='00:00:00:00:00:01' )
    s2 = net.addSwitch( 's2', listenPort=6634, mac='00:00:00:00:00:02' )

    print "*** Creating links"
    net.addLink(h1, s1, )
    net.addLink(h2, s2, )   
    net.addLink(s1, s2, )  

    # Add Controllers
    odl_ctrl = net.addController( 'c0', controller=RemoteController, ip=ODL_CONTROLLER_IP, port=6633)

    fl_ctrl = net.addController( 'c1', controller=RemoteController, ip=FL_CONTROLLER_IP, port=6633)


    net.build()

    # Connect each switch to a different controller
    s1.start( [odl_ctrl] )
    s2.start( [fl_ctrl] )

    s1.cmdPrint('ovs-vsctl show')

    CLI( net )
    net.stop()

if __name__ == '__main__':
    setLogLevel( 'info' )
    myNet()

NETIF_F_NETNS_LOCAL

Original post here.

NETIF_F_NETNS_LOCAL a flag to indicate
a network device is local to a single network namespace and
should never be moved.  Useful for pseudo devices that we
need an instance in each network namespace (like the loopback
device) and for any device we find that cannot handle multiple
network namespaces so we may trap them in the initial network
namespace.

 

Linux Kernel Network Namespace (NETNS)

Original post here.

“So what are network namespaces? Generally speaking, an installation of Linux shares a single set of network interfaces and routing table entries. You can modify the routing table entries using policy routing (here’s an introduction I wrote and here’s a write-up on a potential use case for policy routing), but that doesn’t fundamentally change the fact that the set of network interfaces and routing tables/entries are shared across the entire OS. Network namespaces change that fundamental assumption. With network namespaces, you can have different and separate instances of network interfaces and routing tables that operate independent of each other.”