string format sorgen mit { }

[monaid]

hallo liebe mitforisten,

mir ist bekannt sind folgende möglichkeiten zu string formatiertung mit variabeln bekannt:

Code: Alles auswählen

foo = "bar"
s1 =  f"hier steht {foo}"
s2 = "hier steht auch {} ".format(foo)
s3 = "und hier ? {foo}".format(foo=foo) 

nun habe ich aber einen Sring:

Code: Alles auswählen

text :str ="""
folgendes dict kann gesetzt werden:

name: Dict[str,str] = {
"surname":  {vorname},
"lastname": {nachnahme}
}

""" 
### und möchte diesen mit daten füllen.
d : Dict[str, str]= {'surname' : "foo", 'lastname' : "bar"}

###denke ich geht einfach.
txt.fomat(**d)

geht es aber nicht, weil nach dict ein "{ " und folglich diese variabel auch ersetzt erden will.
da weiss ich nun nicht so recht weiter.

ich bedanke mich fürTips und Anregungen

[pillmuncher]

Code: Alles auswählen

>>> d = {'foo': 123, 'bar': 456}
>>> s = 'foo = {v[foo]}, bar = {v[bar]}'
>>> s.format(v=d)
'foo = 123, bar = 456'
>>> f'foo = {d["foo"]}, bar = {d["bar"]}'
'foo = 123, bar = 456'

[monaid]

danke für deine schnelle antwort,
allerdings sind das nicht meine sorgen

just to clear it:

Code: Alles auswählen

d = {'foo': 123, 'bar': 456}
s = 'foo = {foo}, bar = {bar}'
s.format(**d)

works !

Code: Alles auswählen

s = 'foo = {v[foo]}, b{a}r = {v[bar]}'
d = {'foo': 123, 'bar': 456}
s.format(v=d)

not works !

Code: Alles auswählen

s = """

dic = {{

 "foo" : {bar}

}}

"""
 d = {
    "bar" : "baz"
    
    }

 print (s.format(**d))
 
 
 

works
hab gestern stunden gesucht uns nichts brauchbares gefunden, komisch -
kann geschlossen werden

[monaid]

nochmal schnell mit deinem Konstruct:

Code: Alles auswählen

##  strings

### wrong
s = 'foo = { {v[foo]} : bar = {v[bar]} }'
### right
s = 'foo = {{ {v[foo]} : bar = {v[bar]} }}'

### dict
d = {'foo': 123, 'bar': 456}

## format
s.format(v=d)

[Sirius3]

@monaid: Dass `text` vom Typ `str` ist, sieht man schon daran, dass der Variable ein String zugewiesen wird. Da ist die Typannotation ziemlich unsinnig.

Dein String sieht so aus, als ob Du Python-Code zusammenbauen möchtest. Das ist im Allgemeinen keine gute Idee, und im Speziellen, was möchtest Du eigentlich damit machen?

[monaid]

@monaid: Dass `text` vom Typ `str` ist, sieht man schon daran, dass der Variable ein String zugewiesen wird. Da ist die Typannotation ziemlich unsinnig.

Dein String sieht so aus, als ob Du Python-Code zusammenbauen möchtest. Das ist im Allgemeinen keine gute Idee, und im Speziellen, was möchtest Du eigentlich damit machen?

danke für den Tip, ist alles ziemlich neu für mich.
ich schreibe eine datei, diese datei ist leider eine python datei, die setup.py :
https://packaging.python.org/en/latest/ ... g-metadata
das selbe problem kann aber auch beim scheiben von json etc auftreten oder auch, wenn in der datei code stücke vorkommen.

[Sirius3]

Warum willst Du eine setup.py-Datei per Programm schreiben?

Das selbe Problem tritt bei JSON auch nicht auf, weil man zum Schreiben von JSON-Dateien das json-Modul verwendet und nicht versucht, selbst was mit Format zu basteln.

[__blackjack__]

@monaid: Nein, beim schreiben von JSON kann das Problem nicht auftreten, denn JSON bastelt man nicht als Zeichenkette zusammen. Dafür gibt es das `json`-Modul.

Und das eigentliche zu lösende Problem hast Du noch nicht wirklich verraten, denn die ``setup.py`` generiert man ja nicht. Die verwendet man ja gerade dann wenn man dynamischen Code haben möchte der eben *nicht* statisch generierte Daten enthält, weil die ``setup.py`` sich die ja selbst erstellen kann.

[monaid]

@monaid: Nein, beim schreiben von JSON kann das Problem nicht auftreten, denn JSON bastelt man nicht als Zeichenkette zusammen. Dafür gibt es das `json`-Modul.

Und das eigentliche zu lösende Problem hast Du noch nicht wirklich verraten, denn die ``setup.py`` generiert man ja nicht. Die verwendet man ja gerade dann wenn man dynamischen Code haben möchte der eben *nicht* statisch generierte Daten enthält, weil die ``setup.py`` sich die ja selbst erstellen kann.

beim schreiben von json meinte ich keine json datei, sondern in einer txt, md oder sonstwas datei ein json block

setup.py is the build script for setuptools. It tells setuptools about your package (such as the name and version) as well as which code files to include.

Open setup.py and enter the following content. Change the name to include your username; this ensures that you have a unique package name and that your package doesn’t conflict with packages uploaded by other people following this tutorial.

ich habe vor die seup.py dynamisch zu schreiben und nutze folgendes tempate:

Code: Alles auswählen

setup_py_tpl :str = """
import setuptools

with open("README.md", "r", encoding="utf-8") as fh:
    long_description = fh.read()

setuptools.setup(
    name="{project}-{githubname}",
    version="{version}",
    author="{author}",
    author_email="{email}",
    description="{description}",
    long_description=long_description,
    long_description_content_type="text/markdown",
    url="https://github.com/{githubname}/{project}",
    project_urls={{
        "Bug Tracker": "https://github.com/{githubname}/{project}/issues",
    }},
    classifiers=[
        "Programming Language :: Python :: 3",
        "License :: OSI Approved :: {license}",
        "Operating System :: OS Independent",
    ],
    package_dir={{"": "src"}},
    packages=setuptools.find_packages(where="src"),
    python_requires=">={pythonversion}",
)   
"""

es mag durch eien ide automatisch generiert werden, oder auch ein bullet proofed python package dafür geben,
ich bastle mir gerade ein script zusammen, das mir die für ein packaet notwenigen verzeichnisse und datein dynamisch schreibt, qusai als fingerübung.

[Sirius3]

txt-, md- oder sonstwas-Dateien werden ja auch nicht per Programm erstellt und auch dort wird json per json-Modul generiert.
Und auch bei Deinem setup.py-Template hast Du noch Probleme, weil Strings nicht richtig escaped werden.

[__blackjack__]

@monaid: Den JSON-Block würde man auch mit dem `json`-Modul erstellen und nicht mit Zeichenkettenoperationen zusammenbasteln.

Was Du da vorhast macht mal halt nicht. Da würde der Code in der ``setup.py`` stehen der die Daten dynamisch erstellt. Dafür ist die ja da.

Und gewöhn Dir unsinnige Typannotationen ab. Jeder weiss/sieht, dass `setup_py_tpl` eine Zeichenkette ist. Jeder menschliche Leser und auch jede statische Typprüfung wird das für nichts anderes als eine Zeichenkette halten. Für solche trivialen, offensichtlichen Sachen, die selbst die allerdümmste „type inference“-Implementierung auf die Kette bekommt, ist das nicht gedacht und ist an der Stelle einfach nur unsinniges Rauschen und keine sinnvolle Information für irgendwen. Früher hätte ich ja gesagt wechsel zu Java, wenn Du so was unbedingt willst, aber selbst bei Java würde man da heute keinen Typ mehr angeben müssen.

[monaid]

txt-, md- oder sonstwas-Dateien werden ja auch nicht per Programm erstellt und auch dort wird json per json-Modul generiert.
Und auch bei Deinem setup.py-Template hast Du noch Probleme, weil Strings nicht richtig escaped werden.

welche string wie escaped ?
raus kommt bspw:
und ja, die version ist so nonsence

Code: Alles auswählen

 
import setuptools

with open("README.md", "r", encoding="utf-8") as fh:
    long_description = fh.read()

setuptools.setup(
    name="example_project-monaid",
    version="0.0.1",
    author="monaid",
    author_email="None",
    description="sample project",
    long_description=long_description,
    long_description_content_type="text/markdown",
    url="https://github.com/monaid/example_project",
    project_urls={
        "Bug Tracker": "https://github.com/monaid/example_project/issues",
    },
    classifiers=[
        "Programming Language :: Python :: 3",
        "License :: OSI Approved :: None",
        "Operating System :: OS Independent",
    ],
    package_dir={"": "src"},
    packages=setuptools.find_packages(where="src"),
    python_requires=">=3-7-3-final-0",
)   

[monaid]

@monaid: Den JSON-Block würde man auch mit dem `json`-Modul erstellen und nicht mit Zeichenkettenoperationen zusammenbasteln.

Was Du da vorhast macht mal halt nicht. Da würde der Code in der ``setup.py`` stehen der die Daten dynamisch erstellt. Dafür ist die ja da.

Und gewöhn Dir unsinnige Typannotationen ab. Jeder weiss/sieht, dass `setup_py_tpl` eine Zeichenkette ist. Jeder menschliche Leser und auch jede statische Typprüfung wird das für nichts anderes als eine Zeichenkette halten. Für solche trivialen, offensichtlichen Sachen, die selbst die allerdümmste „type inference“-Implementierung auf die Kette bekommt, ist das nicht gedacht und ist an der Stelle einfach nur unsinniges Rauschen und keine sinnvolle Information für irgendwen. Früher hätte ich ja gesagt wechsel zu Java, wenn Du so was unbedingt willst, aber selbst bei Java würde man da heute keinen Typ mehr angeben müssen.

gut ich gewöhne mir unnötige noatationen ab, mypy hat bei sovielgemekert, da hab ich halte versucht alle mögliche anzugeben.
ok, man macht das nicht, aber wie dann ?
über die setup.cfg ?

[__blackjack__]

@monaid: Das ist eine der Gefahren bei Typannotationen, dass versucht wird einfach nur die Typprüfung irgendwie ruhig zu stellen, statt sich tatsächlich Gedanken über die Typen zu machen und wo welcher in welcher Schärfe nötig und sinnvoll ist. Zum Beispiel ist `Dict` ja auch ”falsch”, denn an der Stelle hätte die Eigenschaft `typing.Mapping` wahrscheinlich vollkommen ausgereicht.

Der Code der jetzt das Template füllt würde einfach in der ``setup.py`` selbst stehen.

[monaid]

Der Code der jetzt das Template füllt würde einfach in der ``setup.py`` selbst stehen.

bis auf die konkertisierung von email, packetname etc pp ?

Zum Beispiel ist `Dict` ja auch ”falsch”, denn an der Stelle hätte die Eigenschaft `typing.Mapping` wahrscheinlich vollkommen ausgereicht.

danke, werde ich so versuchen.
ich wäre ja auch mit Typing bei functionen komplett zufrieden, mypy --strict nicht

[__blackjack__]

Man muss ``mypy`` auch gar nicht benutzen, nicht mal ohne ``--strict``; einfach weg lassen, genau wie die Typannotationen. Ging jahrzehntelang ohne und für nicht wenige war „keine Typen deklarieren müssen“ einer *der* Gründe für Python statt eine statisch typisierte Sprachen zu verwenden.