Betriebssystem-und Python-versions feld.
Es muss ja gernicht OpenSource werden, man könnte es dem deutschen py-forum auch zum testen geben
the more they change the more they stay the same
Dav1d: und dann kracht es, Datenbanken werden beschädigt und Datensätze können nicht wiederhergestellt werden. Dann muss nach Hilfe gefragt werden; darauf ist das webteam von inyoka aber einfach nicht vorbereitet, weil sie andere Sorgen / Prioritäten haben.
@derdon: Ich bin sicher, Du kennst die Bedeutung des Wortes „Testen“, und ich glaube, Du hältst die hiesigen Administratoren auch nicht für so dumm, eine neue und erkennbar instabile (es ist ja nicht so, als würde ubuntuusers.de wirklich stabil laufen) Software auf Produktivdaten loszulassen.
Außerdem weißt Du genauso gut wie alle anderen hier, dass wir uns in einem Python-Forum befinden (das ist ja nicht zu übersehen), und das einige der Anwesenden durchaus die Kompetenz besitzen, sich in fremden Python-Quelltext einzuarbeiten, und somit fähig sind, zumindest kleinere Fehler auch ohne Hilfe der Entwickler zu korrigieren.
Was also wolltest Du jetzt mit diesem Beitrag sagen?
Außerdem weißt Du genauso gut wie alle anderen hier, dass wir uns in einem Python-Forum befinden (das ist ja nicht zu übersehen), und das einige der Anwesenden durchaus die Kompetenz besitzen, sich in fremden Python-Quelltext einzuarbeiten, und somit fähig sind, zumindest kleinere Fehler auch ohne Hilfe der Entwickler zu korrigieren.
Was also wolltest Du jetzt mit diesem Beitrag sagen?
Ich möchte mir natürlich keine Moderatorenstellung zum Thema "Inyoka" herausnehmen, aber die zwei Parteien lassen sich wohl wie folgt in ihrer Meinung zusammenfassen:
Partei 1 sind die Entwickler und Unterstützer des Kurses der Entwickler: 1. Code sollte nicht veröffentlicht werden, da zu speziell. Es existiert zudem keine Doku, usw. 2. Auch würde eine Veröffentlichung Support-Anfragen bedeuten. Man würde vermutlich schrittweise genau zu dem gedrängt werden, was man vermeiden will, da man in der Vergangenheit schlechte Erfahrungen damit gemacht hat, solch ein Projekt öffentlich einsehbar zu machen. 3. Den Anfragenden scheint es mehr oder weniger um's Prinzip zu gehen. Sie haben eh kein Interesse am produktiven Einsatz, schon gar nicht daran, sich selbst am Projekt zu beteiligen. Sie wollen teilweise einfach nur ein kostenloses und idealerweise fertiges Produkt vorgesetzt bekommen (übertrieben gesagt).
Partei 2 sind die Kritiker an der Entscheidung: 1. Codeveröffentlichung bedeutet einen Lerneffekt - einfach mal hinter die Kulissen schauen zu können, selbst wenn es nicht allgemein anwendbar ist. 2. Mit diesem Bewusstsen geht auch einher, dass man sich auf fehlende Doku - sprich: Lernen aus dem Quelltext - einstellt und auch keinen Support verlangt. 3. Die Entwickler verstoßen mit ihrer Haltung gegen bewährte Prinzipien, die eben auch das ausmachen, was von der Plattform behandelt wird: Linux bzw Ubuntu mit der entsprechenden Philosohpie. Das ganze hätte schon gewissermaßen etwas properietäres an sich. 4. Potenzielle Helfer würden vergrault und hätten niemals eine Chance, zu entscheiden, inwiefern sie helfen können, da sie den Code nicht kennen.
Insbesondere zum letzten Punkt 4 kommt dann das Angebot, dem Webteam beizutreten, wodurch die Forderungen erfüllt würden. Und genau hier verstehe ich die Kritiker ehrlich gesagt nicht: Warum nörgelt man rum, anstatt einfach mal dieses Angebot wahrzunehmen? Geht es vielleicht am Ende doch nur um's Prinzip? Bedeutet Freie Software letztlich, dass man Code, über den man einmal berichtet hat oder ihn gar zur Anwendung freigegeben hat, zwingend veröffentlichen muss, egal in welchem Status? Ist diese Denke/Anforderung dann wirklich noch als "frei" zu bezeichnen?
Ich greife an dieser Stelle nochmal Dinge auf, die bereits in der Diskussion (vornehmlich auf uu.de) angesprochen wurden: Wieviel bringt es einem Projekt gemessen an Beispielen aus der Praxis, wenn es Open Source wird? Insbesondere: Wieviel bringt es einem vermutlich noch recht unstrukturiertem Projekt? Man kennt von hier im Forum ja durchaus all die gutgemeinten (und an sich auch sinnvollen) Ratschläge in Bezug auf PEP 8 usw. Einerseits bedeuten sie eine konstruktive Kritik an der Herangehensweise, andererseits wird auch gerne bemängelt und selten eine Alternative vorgeschlagen (ok, bei PEP 8 reicht die Verlinkung, aber es gibt genügend andere Beispiele). Anders gesagt: Wieviel verwertbaren Input bringt einem sowas, um das Projekt nach vorn zu bringen? (Immer im Hinterkopf behaltend, was ohne eine Veröffentlichung wäre) Hält es nicht am Ende sogar die Entwicklung eher auf als dass es sie fördert?
Dann gibt es wiederum ein imho sehr gutes Argument *für* die Veröffentlichung: Der halbgare Code könnte von Freiwilligen dokumentiert werden. Man könnte außerdem einen Fork kreieren, der allgemein verwendbar ist. Da dies nicht passiert, ist m.E. die Vermutung, dass es gewissen etablierten Entwicklern ein bißchen peinlich ist, den Code zu veröffentlichen, nicht ganz aus der Luft gegriffen; auch wenn dies nicht mehr als Mutmaßungen sind.
Mein Fazit ist daher: Kritik (z.B. auch meine) sollte als Denkanstoß dienen, sofern sie human geäußert wird. Letztlich sollte aber die Entscheidung der Entwickler akzeptiert werden. So wie ich eine Lizenz aussuchen kann, muss ich auch entscheiden dürfen, wann ich wieviel Code veröffentliche. Ich selbst entwickle ja auch (wohl mehr schlecht als recht) an verschiedenen privaten Hobby-Projekten und würde euch - ganz offen gesprochen - dem Mittefinger zeigen, wenn jemand ankäme und verlangen würde, dass ich das, was ich bis jetzt habe, doch gefälligst als Release 0.1 (oder was weiß ich) veröffentlichen soll.
Code wird genau dann veröffentlicht, wenn man der Meinung ist, dass er als Basis dienen kann, die sich auch so schnell nicht verändern wird. Und gerade diese Veränderung passiert im Anfangsstadium ja noch recht häufig. Nichts hasse ich mehr als eine Roadmap oder Forderungen, die in die besagte Richtung einer Veröffentlichung gehen. Sicher, für den Anwender ist das super, weil er sich auf etwas greifbares - festterminiertes - einstellen kann. Wir wissen aber alle, dass termingerechte Releases häufig auch nicht so das gelbe vom Ei sind.
Von daher finde ich bei all der verständlichen Ungeduld, insbesondere für's Python-Forum, dass man Inyoka solange reifen lassen sollte, wie es nötig ist. Mir will doch wohl keiner ernsthaft erzählen, dass er sich nach Veröffentlichung der "pre-Alpha" von Inyoka ernsthaft an eine Portierung setzen wird. Wir werden halt weiterhin bei PHP bleiben müssen, außer jemand mit Ahnung und der nötigen Zeit nimmt das in die Hand, was aber derzeit nicht absehbar ist.
Partei 1 sind die Entwickler und Unterstützer des Kurses der Entwickler: 1. Code sollte nicht veröffentlicht werden, da zu speziell. Es existiert zudem keine Doku, usw. 2. Auch würde eine Veröffentlichung Support-Anfragen bedeuten. Man würde vermutlich schrittweise genau zu dem gedrängt werden, was man vermeiden will, da man in der Vergangenheit schlechte Erfahrungen damit gemacht hat, solch ein Projekt öffentlich einsehbar zu machen. 3. Den Anfragenden scheint es mehr oder weniger um's Prinzip zu gehen. Sie haben eh kein Interesse am produktiven Einsatz, schon gar nicht daran, sich selbst am Projekt zu beteiligen. Sie wollen teilweise einfach nur ein kostenloses und idealerweise fertiges Produkt vorgesetzt bekommen (übertrieben gesagt).
Partei 2 sind die Kritiker an der Entscheidung: 1. Codeveröffentlichung bedeutet einen Lerneffekt - einfach mal hinter die Kulissen schauen zu können, selbst wenn es nicht allgemein anwendbar ist. 2. Mit diesem Bewusstsen geht auch einher, dass man sich auf fehlende Doku - sprich: Lernen aus dem Quelltext - einstellt und auch keinen Support verlangt. 3. Die Entwickler verstoßen mit ihrer Haltung gegen bewährte Prinzipien, die eben auch das ausmachen, was von der Plattform behandelt wird: Linux bzw Ubuntu mit der entsprechenden Philosohpie. Das ganze hätte schon gewissermaßen etwas properietäres an sich. 4. Potenzielle Helfer würden vergrault und hätten niemals eine Chance, zu entscheiden, inwiefern sie helfen können, da sie den Code nicht kennen.
Insbesondere zum letzten Punkt 4 kommt dann das Angebot, dem Webteam beizutreten, wodurch die Forderungen erfüllt würden. Und genau hier verstehe ich die Kritiker ehrlich gesagt nicht: Warum nörgelt man rum, anstatt einfach mal dieses Angebot wahrzunehmen? Geht es vielleicht am Ende doch nur um's Prinzip? Bedeutet Freie Software letztlich, dass man Code, über den man einmal berichtet hat oder ihn gar zur Anwendung freigegeben hat, zwingend veröffentlichen muss, egal in welchem Status? Ist diese Denke/Anforderung dann wirklich noch als "frei" zu bezeichnen?
Ich greife an dieser Stelle nochmal Dinge auf, die bereits in der Diskussion (vornehmlich auf uu.de) angesprochen wurden: Wieviel bringt es einem Projekt gemessen an Beispielen aus der Praxis, wenn es Open Source wird? Insbesondere: Wieviel bringt es einem vermutlich noch recht unstrukturiertem Projekt? Man kennt von hier im Forum ja durchaus all die gutgemeinten (und an sich auch sinnvollen) Ratschläge in Bezug auf PEP 8 usw. Einerseits bedeuten sie eine konstruktive Kritik an der Herangehensweise, andererseits wird auch gerne bemängelt und selten eine Alternative vorgeschlagen (ok, bei PEP 8 reicht die Verlinkung, aber es gibt genügend andere Beispiele). Anders gesagt: Wieviel verwertbaren Input bringt einem sowas, um das Projekt nach vorn zu bringen? (Immer im Hinterkopf behaltend, was ohne eine Veröffentlichung wäre) Hält es nicht am Ende sogar die Entwicklung eher auf als dass es sie fördert?
Dann gibt es wiederum ein imho sehr gutes Argument *für* die Veröffentlichung: Der halbgare Code könnte von Freiwilligen dokumentiert werden. Man könnte außerdem einen Fork kreieren, der allgemein verwendbar ist. Da dies nicht passiert, ist m.E. die Vermutung, dass es gewissen etablierten Entwicklern ein bißchen peinlich ist, den Code zu veröffentlichen, nicht ganz aus der Luft gegriffen; auch wenn dies nicht mehr als Mutmaßungen sind.
Mein Fazit ist daher: Kritik (z.B. auch meine) sollte als Denkanstoß dienen, sofern sie human geäußert wird. Letztlich sollte aber die Entscheidung der Entwickler akzeptiert werden. So wie ich eine Lizenz aussuchen kann, muss ich auch entscheiden dürfen, wann ich wieviel Code veröffentliche. Ich selbst entwickle ja auch (wohl mehr schlecht als recht) an verschiedenen privaten Hobby-Projekten und würde euch - ganz offen gesprochen - dem Mittefinger zeigen, wenn jemand ankäme und verlangen würde, dass ich das, was ich bis jetzt habe, doch gefälligst als Release 0.1 (oder was weiß ich) veröffentlichen soll.
Code wird genau dann veröffentlicht, wenn man der Meinung ist, dass er als Basis dienen kann, die sich auch so schnell nicht verändern wird. Und gerade diese Veränderung passiert im Anfangsstadium ja noch recht häufig. Nichts hasse ich mehr als eine Roadmap oder Forderungen, die in die besagte Richtung einer Veröffentlichung gehen. Sicher, für den Anwender ist das super, weil er sich auf etwas greifbares - festterminiertes - einstellen kann. Wir wissen aber alle, dass termingerechte Releases häufig auch nicht so das gelbe vom Ei sind.
Von daher finde ich bei all der verständlichen Ungeduld, insbesondere für's Python-Forum, dass man Inyoka solange reifen lassen sollte, wie es nötig ist. Mir will doch wohl keiner ernsthaft erzählen, dass er sich nach Veröffentlichung der "pre-Alpha" von Inyoka ernsthaft an eine Portierung setzen wird. Wir werden halt weiterhin bei PHP bleiben müssen, außer jemand mit Ahnung und der nötigen Zeit nimmt das in die Hand, was aber derzeit nicht absehbar ist.
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Auch wenn ich mich wiederhole: Zumindest ich habe keine Lust meine wenige Freie Zeit mit einem de-facto nicht OpenSource Projekt zu widmen. Kann mir vorstellen, andere Denken ähnlich...snafu hat geschrieben:Insbesondere zum letzten Punkt 4 kommt dann das Angebot, dem Webteam beizutreten, wodurch die Forderungen erfüllt würden. Und genau hier verstehe ich die Kritiker ehrlich gesagt nicht: Warum nörgelt man rum, anstatt einfach mal dieses Angebot wahrzunehmen?
Soll ich ins Webteam "eintreten" nur um mal zu sehen, ob ich damit was anfangen kann? Ob ich mithelfen möchte?
Es kommt darauf an, ob man es mit großem tatarata veröffentlicht oder einfach nur den Sourcecode öffentlich zugänglich macht.snafu hat geschrieben:Code wird genau dann veröffentlicht, wenn man der Meinung ist, dass er als Basis dienen kann, die sich auch so schnell nicht verändern wird. Und gerade diese Veränderung passiert im Anfangsstadium ja noch recht häufig. Nichts hasse ich mehr als eine Roadmap oder Forderungen, die in die besagte Richtung einer Veröffentlichung gehen.
Erstellt man eine Webseite und erzählt was von der "ultimative Community Plattform." oder stellt einfach die Sourcen auf gihub und macht ansonsten nix weiter, schreibt sogar dabei: "nicht nutzbar", "Keine Dokumentation", "kein Support"
Ich hab auch einen Haufen Code einfach auf github gepackt: http://github.com/jedie/python-code-snippets
Mit dabei ist uralter Mist, der eigentlich für niemanden nutzbar sein dürfte, aber was solls?
@snafu: So einfach ist es nicht, das Angebot, dem Projekt beizutreten, kann die Möglichkeit, den Quelltext unverbindlich einzusehen, nicht unbedingt ersetzen.
Der Beitritt zu einem Projekt impliziert eine gewisse Verpflichtung, tatsächlich größeres Engagement für dieses Projekt zu zeigen, wichtige Beiträge zu leisten, und letztlich die eigene Freizeit zu opfern. Im Falle Inyokas kann man aber vorher gar nicht feststellen, ob Projekt und Quelltext überhaupt dieses Engagement wert sind. Inyoka verwehrt Entwicklern die übliche schrittweise Beteiligung von anfänglichen, kleinen und unverbindlichen Patches bis hin zum späteren Beitritt, sondern fängt gleich beim Beitritt an. Vom Entwickler verlangt das einen ordentlichen Vorschuss an Vertrauen und Interesse, den aufzubringen nicht jeder bereit ist.
inyoka ist eben wie ein Blind Date ... und so nötig habe ich es nicht. Meine begrenzte Freizeit investiere ich (wenn überhaupt) lieber in Projekte mit geringeren Hürden. So unzufrieden bin ich mit phpbb in diesem Forum auch nicht. Das nur als Erklärung, warum es für meinen Teil eben nicht dasselbe ist ...
Der Beitritt zu einem Projekt impliziert eine gewisse Verpflichtung, tatsächlich größeres Engagement für dieses Projekt zu zeigen, wichtige Beiträge zu leisten, und letztlich die eigene Freizeit zu opfern. Im Falle Inyokas kann man aber vorher gar nicht feststellen, ob Projekt und Quelltext überhaupt dieses Engagement wert sind. Inyoka verwehrt Entwicklern die übliche schrittweise Beteiligung von anfänglichen, kleinen und unverbindlichen Patches bis hin zum späteren Beitritt, sondern fängt gleich beim Beitritt an. Vom Entwickler verlangt das einen ordentlichen Vorschuss an Vertrauen und Interesse, den aufzubringen nicht jeder bereit ist.
inyoka ist eben wie ein Blind Date ... und so nötig habe ich es nicht. Meine begrenzte Freizeit investiere ich (wenn überhaupt) lieber in Projekte mit geringeren Hürden. So unzufrieden bin ich mit phpbb in diesem Forum auch nicht. Das nur als Erklärung, warum es für meinen Teil eben nicht dasselbe ist ...
Kann ich fast nur zustimmen.lunar hat geschrieben:@snafu: So einfach ist es nicht, das Angebot, dem Projekt beizutreten, kann die Möglichkeit, den Quelltext unverbindlich einzusehen, nicht unbedingt ersetzen.
Der Beitritt zu einem Projekt impliziert eine gewisse Verpflichtung, tatsächlich größeres Engagement für dieses Projekt zu zeigen, wichtige Beiträge zu leisten, und letztlich die eigene Freizeit zu opfern. Im Falle Inyokas kann man aber vorher gar nicht feststellen, ob Projekt und Quelltext überhaupt dieses Engagement wert sind. Inyoka verwehrt Entwicklern die übliche schrittweise Beteiligung von anfänglichen, kleinen und unverbindlichen Patches bis hin zum späteren Beitritt, sondern fängt gleich beim Beitritt an. Vom Entwickler verlangt das einen ordentlichen Vorschuss an Vertrauen und Interesse, den aufzubringen nicht jeder bereit ist.
Zudem: Die Aussichtstellung auf einen Release, den es ja gab, weckt einfach große Erwartungen.
[url=http://wiki.python-forum.de/PEP%208%20%28%C3%9Cbersetzung%29]PEP 8[/url] - Quak!
[url=http://tutorial.pocoo.org/index.html]Tutorial in Deutsch[/url]
[url=http://tutorial.pocoo.org/index.html]Tutorial in Deutsch[/url]
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Man sollte den Entwicklern jedoch zu gute halten, dass sie für uu.de eine schöne Lösung implementiert haben; zumindest für den Benutzer wirkt das ganze recht rund und durchdacht. Ob die Lösung nun extrem speziell ist oder nicht, vermag man eben ohne Einblick in den Quellcode nicht abzuschätzen.
Prinzipiell würde ich denken, dass es vor allem an fehlenden Templates, Style-Dateien usw. liegt, denn an "speziellem" Code. Ich würde da den Entwicklern mal genügend Erfahrung attestieren, dass es in der Software selber keinen "ubuntu"-String gibt
Für uns Python Begeisterte ist inyoka im jetzigen Zustand ehrlich gesagt fast ein Hemmschuh, eben weil es so gut wirkt, aber leider für uns nicht nutzbar ist. Ohne inyoka könnte es evtl. genügend Leute geben, die an einer Eigenentwicklung Interesse hätten; mit inyoka als eine Art positives Damoklesschwert sieht es damit eben leider mau aus.
Eigentlich schade, gab es hier doch schon einige tolle Ideen hinsichtlich der Funktionalität... ich erinnere mich da an ein Posting von sma, in dem er ein einfaches und dennoch effizientes Datenmodell beschrieben hatte, welches universell für Forenpostings, Artikel und Blogeinträge gültig sein kann und nur durch "Views" bzw. den Kontext entsprechend interpretiert wird. Das ganze kombiniert mit einer No-SQL DB a la Mongodb oder Couchdb und den entsprechenden "Web"-Libs (z.B. flask / werkzeug, wtforms, jquery, pygments, ...) und man könnte da schon was hübsches kreieren
Nuja, auch im Fiat kann man zu Audi zur Arbeit fahren; dennoch mag es den ein oder anderen "Verkauf" erschweren, wenn man mit fremden Technologien unterwegs ist.
Prinzipiell würde ich denken, dass es vor allem an fehlenden Templates, Style-Dateien usw. liegt, denn an "speziellem" Code. Ich würde da den Entwicklern mal genügend Erfahrung attestieren, dass es in der Software selber keinen "ubuntu"-String gibt
Für uns Python Begeisterte ist inyoka im jetzigen Zustand ehrlich gesagt fast ein Hemmschuh, eben weil es so gut wirkt, aber leider für uns nicht nutzbar ist. Ohne inyoka könnte es evtl. genügend Leute geben, die an einer Eigenentwicklung Interesse hätten; mit inyoka als eine Art positives Damoklesschwert sieht es damit eben leider mau aus.
Eigentlich schade, gab es hier doch schon einige tolle Ideen hinsichtlich der Funktionalität... ich erinnere mich da an ein Posting von sma, in dem er ein einfaches und dennoch effizientes Datenmodell beschrieben hatte, welches universell für Forenpostings, Artikel und Blogeinträge gültig sein kann und nur durch "Views" bzw. den Kontext entsprechend interpretiert wird. Das ganze kombiniert mit einer No-SQL DB a la Mongodb oder Couchdb und den entsprechenden "Web"-Libs (z.B. flask / werkzeug, wtforms, jquery, pygments, ...) und man könnte da schon was hübsches kreieren
Nuja, auch im Fiat kann man zu Audi zur Arbeit fahren; dennoch mag es den ein oder anderen "Verkauf" erschweren, wenn man mit fremden Technologien unterwegs ist.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Und weiter geht's in Endlosschleife: Kommentar zum Thema „Inyoka und das Open Source Release” #2
Das ist IMHO auch interessant: onli blogging - Ubuntuusers: Ein Team in Geiselhaft?
Das ist IMHO auch interessant: onli blogging - Ubuntuusers: Ein Team in Geiselhaft?
@jens: Ich finde diesen Artikel nicht interessant, sondern reichlich lächerlich. Es ist mir vollkommen unverständlich, wie man sich über eine solche Kleinigkeit wie die Implementierung von Zeilenumbrüchen derartig echauffieren kann, dass man mit der Waffe des eigenen Austritts drohen muss.
Den Kommentar vom Webteam habe ich ehrlich gesagt gar nicht vollständig gelesen, den den ersten Absätzen nach zu urteilen, arbeitet er sich nur wieder an den ewig gleichen Argumenten ab.
Den Kommentar vom Webteam habe ich ehrlich gesagt gar nicht vollständig gelesen, den den ersten Absätzen nach zu urteilen, arbeitet er sich nur wieder an den ewig gleichen Argumenten ab.
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Auch wenn's abgegrabbelt ist werfe ich mal das Stichwort "Inaterface-Nazis" rein. Manchmal muss man den Benutzern auch mal etwas zutrauen bzw. ihm abverlangen dürfen. Das scheint der OP so nicht zu sehen...lunar hat geschrieben:@jens: Ich finde diesen Artikel nicht interessant, sondern reichlich lächerlich. Es ist mir vollkommen unverständlich, wie man sich über eine solche Kleinigkeit wie die Implementierung von Zeilenumbrüchen derartig echauffieren kann, dass man mit der Waffe des eigenen Austritts drohen muss.
Leider ja.Den Kommentar vom Webteam habe ich ehrlich gesagt gar nicht vollständig gelesen, den den ersten Absätzen nach zu urteilen, arbeitet er sich nur wieder an den ewig gleichen Argumenten ab.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
@Hyperion: Es geht dabei wohl weniger um echte Überzeugung – eine „Ideologie“ auf Basis von Zeilenumbrüchen muss doch jedem einigermaßen lächerlich erscheinen –, sondern vor allem um allerlei persönliche Befindlichkeiten.
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Ja, ist so ein wenig "Grund oder Anlass" oder auch "Henne-Ei". Mag schon sein, dass es mehr Deckmantel ist, als Überzeugung; ich kenne mich mit den Interna im uu-Team nicht aus und kann den OP auch nicht einschätzen. Diese Vermischung der Kritik an der Nicht-Veröffentlichung zusammen mit einer technisch und sozialen Entscheidung gemixt mit persönlichen Konsequenzen empfand ich auch als eher lächerlichlunar hat geschrieben:@Hyperion: Es geht dabei wohl weniger um echte Überzeugung – eine „Ideologie“ auf Basis von Zeilenumbrüchen muss doch jedem einigermaßen lächerlich erscheinen –, sondern vor allem um allerlei persönliche Befindlichkeiten.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
Sollen sie doch offen mit dem Thema umgehen: "Wir hatten nie ein richtiges Konzept und haben je nach Notwendigkeit etwas zusammengestrickt. Jetzt passt alles hinten und vorne nicht zusammen und die Dokumentation sieht damit auch entsprechend miserabel aus. Das wollen wir im Moment wirklich keinem zeigen."lunar hat geschrieben:Den Kommentar vom Webteam habe ich ehrlich gesagt gar nicht vollständig gelesen, den den ersten Absätzen nach zu urteilen, arbeitet er sich nur wieder an den ewig gleichen Argumenten ab.
Das ist zumindest das, was ich daraus lese und die Begründung würde ich sogar verstehen.
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Aber auch wenn es einen Haufen Müll ist. Was soll's. Sie sollten es dennoch auf github packen und fertig. Dann kann sich jeder selbst ein Bild von machen...
Das "Support-Anfragen" kommen werden, ist klar. Die kann man aber genauso Abbügeln, wie die jetzige immer wieder kehrende Frage, nach der Veröffentlichung der Sourcen...
Das "Support-Anfragen" kommen werden, ist klar. Die kann man aber genauso Abbügeln, wie die jetzige immer wieder kehrende Frage, nach der Veröffentlichung der Sourcen...
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Also ich finde
dieses Zeilenumbruch-Problem
echt nervig und kann verstehen
dass die Inyoka-Entwicker das
gerne abstellen würden.
Aber warum diskutiere ich hier eigentlich? Das ist doch wieder so eine Zeitsenke ohne dass dabei was rauskommt. Leute, in der Zeit wie über Inyoka diskutiert wurde, könnte man ein akzeptables Forum selbst schreiben. Ich jedenfalls werd nicht auf Inyoka warten. Wenn es kommt, gut, wenn nicht dann egal. Da hatte Y0Gi ganz recht, als er sein eigenes Forum implementiert hat.
dieses Zeilenumbruch-Problem
echt nervig und kann verstehen
dass die Inyoka-Entwicker das
gerne abstellen würden.
Aber warum diskutiere ich hier eigentlich? Das ist doch wieder so eine Zeitsenke ohne dass dabei was rauskommt. Leute, in der Zeit wie über Inyoka diskutiert wurde, könnte man ein akzeptables Forum selbst schreiben. Ich jedenfalls werd nicht auf Inyoka warten. Wenn es kommt, gut, wenn nicht dann egal. Da hatte Y0Gi ganz recht, als er sein eigenes Forum implementiert hat.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Kannst Du dazu mal einen Link posten bzw. das konkretisieren? Würde mich ja mal interessierenLeonidas hat geschrieben:Da hatte Y0Gi ganz recht, als er sein eigenes Forum implementiert hat.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
ich wollte es gerade mal suchen:
http://www.python-forum.de/search.php?k ... bmit=Suche
http://www.python-forum.de/search.php?k ... bmit=Suche
Die folgenden Wörter deiner Suchanfrage wurden ignoriert, da sie zu häufig vorkommen: forum.
Du musst mindestens ein Wort angeben, nach dem gesucht werden soll. Jedes Wort muss aus mindestens 3 Buchstaben bestehen und darf ohne Platzhalter nicht mehr als 14 Buchstaben haben.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Er hat ja mal ein (zurzeit auch nicht öffentliches) Forensystem, Palaver geschrieben. Aber was daraus geworden ist weiß ich selbst grad nicht, genauso wie Y0Gi selbst. Schade eigentlich.Hyperion hat geschrieben:Kannst Du dazu mal einen Link posten bzw. das konkretisieren? Würde mich ja mal interessierenLeonidas hat geschrieben:Da hatte Y0Gi ganz recht, als er sein eigenes Forum implementiert hat.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
btw. alleine in Django gibt es ein paar Implementierungen eines Forums, siehe: http://code.djangoproject.com/wiki/ForumAppsComparison oder http://djangopackages.com/grids/g/forums/