|
What do you mean? Could you hint me clearly? Thanks.
|
|
|
|
|
It could not be any clearer, what do you not understand?
|
|
|
|
|
Seriously?
You cannot have two statements on the same line!
|
|
|
|
|
def ListOfLists(list):
'''
This function receives a list, which can contain elements that are themselves lists and
returns those items separately in a single list.
If the parameter is not of type list, it must return null.
Receive an argument:
list: The list that can contain other lists and is converted to a
list of unique or non-iterable elements.
Ex:
ListOfLists([1,2,['a','b'],[10]]) should return [1,2,'a','b',10]
ListOfLists(108) should return null.
ListOfLists([[1,2,[3]],[4]]) should return [1,2,3,4]
|
|
|
|
|
|
A tad late to the party but a recursive approach seems to work.
def Collapse(lst):
result = []
for item in lst:
if type(item) == list:
result.extend(Collapse(item))
else:
result.append(item)
return result
a = [1, [2, 3, [3.1, 3.2]], 4]
b = Collapse(a)
print(a)
print(b)
|
|
|
|
|
We're curious. A virtual environment can use system wide resources, but can a virtual environment lean on an existing venv and only have the extra bits, or overide bits, that are specific to that new venv?
cheers
Chris Maunder
|
|
|
|
|
I'm curious: Is any VM implementation programmed in Python? (Recursive virtualization or not!)
|
|
|
|
|
The virtual environment just puts itself (i.e its version of Python and associated libraries) at the front of the search path. So anything called after you run activate, will load first from the .venv locations, before looking at the system folders. I guess that if you then activate another .venv then the search path would be venv2 -> venv1 -> system installation. Which could be fun.
|
|
|
|
|
I guess I could do this manually, since it's only really the site-packages I'm worried about. Something like
Suppose I have two apps that have different and potentially conflicting packages. I'd create a venv with the python interpreter in /app/bin/python and the common packages in /app/bin/python/site-packages-common. I'd then install specific packages for app A and B in different folders:
/app/bin/python
/app/bin/python/site-packages-common
/app/bin/python/site-packages-A
/app/bin/python/site-packages-B
then in app A I could do
sys.path.insert(0, "/app/bin/python/site-packages-common")
sys.path.insert(0, "/app/bin/python/site-packages-A")
and in app B I could do
sys.path.insert(0, "/app/bin/python/site-packages-common")
sys.path.insert(0, "/app/bin/python/site-packages-B")
I would have to specify the target folder when running pip to install the packages (no drama).
My big concern is if we have the following:
pip install common-package -target /app/bin/python/site-packages-common
pip install package-a -target /app/bin/python/site-packages-A
pip install package-b -target /app/bin/python/site-packages-B
What if package-a relies on v1 of common-package, and package-b relies on v2 of common-package?
I'm actually assuming pip will install all dependent packages anyway, so while we might end up with repeated installs of dependant packages, there are certainly some 'common' packages that won't necessarily be dependencies of anything and so will only be installed once in the common folder
cheers
Chris Maunder
|
|
|
|
|
I've never come across a situation which would need A and B to co-exist in that way, so it's difficult to give a useful answer. But unless you are running A and B at (more or less) the same time in the same shell, do you really need to share between them?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
