This is because you’re testing the truthiness of tail.pnext as a while condition in this line:

while tail.pnext:

According to Python’s documentation of Truth Value Testing:

By default, an object is considered true unless its class defines either a __bool__() method that returns False or a __len__() method that returns zero, when called with the object.

We could use a loop:

out = {}
for item in My_list:
    if item.startswith('I'):
        out[item] = []
        current = item
    else:
        out[current].append(item)

Output:

{'I=113': ['PLAN=1', 'A=0PDFGB', 'B=23FGC', 'C=26TGFGD', 'D=19TGE', 'E=18TGA'],
 'I=120': ['PLAN=2', 'A=0PDFGB', 'B=23FGC', 'C=26TGFGD', 'D=19TGE', 'E=18TGA']}

So, turns out i found the solution. To anyone who’s struggling with this problem, the problem was (in my case at least) in one of the env variables that vscode was running wsl with. It is called PRE_NAMESPACE_PWD. If you run WSL with debug enabled (to do this just go to the wsl remote extension settings and turn on the “Remote WSL:Debug” option.) you’ll notice the “env” options in wsl command with all env variables listed there, and if you keep scrolling you’ll notice two variables: PRE_NAMESPACE_PWD and PWD. In this problem, the PRE_NAMESPACE_PWD was pointing to the windows vscode folder instead of the current workspace folder in wsl and the PWD variable was using this folder. To summarize i just exported this PRE_NAMESPACE_PWD variable with the value “${cwd}” which is a command that gets the current workspace folder in my vscode. To do this, simply add this line to your remote Settings.json file:

"terminal.integrated.env.linux": {
    "PRE_NAMESPACE_PWD": "${cwd}"
  }

And that’s it, now everytime you click on “Open with integrated terminal” your terminal is going to open in the right workspace directory.

A &str is a string slice that refers to data held elsewhere. In the case of a string literal, you have a &'static str which is a reference to data held in the binary itself. Otherwise, you typically produce a &str by taking a slice of an existing String.

If you are generating a new string at runtime, this must happen in a String. You can then dispense slices (&str) from it, but the String value must itself live at least as long as the slices. &phrase.replace("-", "") doesn’t work here because you’re taking a slice of a temporary — a value that only lives as long as the statement it’s part of. After the end of this statement, the temporary String returned by the replace method is dropped and phrase would refer to a slice that points into a string that no longer exists, and the borrow checker is correctly pointing out that this is not memory-safe. It would be like returning a reference to a value held in a local variable within the same function.

However, what you’re doing here isn’t even shadowing, you’re just trying to reassign a variable from an incompatible type. Shadowing the name phrase with a new variable of the same name will allow the new name to have a different type (such as String), so this would be valid:

pub fn abbreviate(phrase: &str) -> String {
    let mut tla = String::new();
    // phrase refers to a &str here
    let phrase = phrase.replace("-", "");
    // phrase refers to a String here

    // Return something
}

Basically, your first example only fails because you didn’t put let before the assignment.

Note also that the phrase argument doesn’t need to be mut here. let phrase introduces a new variable with the same name, effectively hiding the argument from the rest of the function. It doesn’t actually change the value held in the original name.