#207 Hacer una captura del HTML desde el "inspeccionar elemento" no vale, porque no muestra el HTML original, si no el HTML que el navegador ha interpretado después de ejecutar todos los scripts.
#108 Si te refieres al agrupar con intetación en vez de llaves, es una característica del lenguaje, como los $ en Perl, los #DEFINE en C, etc. El lenguaje es así.
Si te refieres a cuestiones de estilo (espaciados, formas de nombrar las variables, funciones, etc), están muy bien argumentados aquí: www.python.org/dev/peps/pep-0008/
No es obligatorio, pero lo ha escrito gente que sabe mucho, deben existir poderosas razones para no seguir estas recomendaciones.
#107 No sé qué experiencia tienes en estas cosas. Lo habitual es que cuando llegas a un proyecto ya esté mucho código escrito. Puede que los que lo empezaron decidieran la convención A o B, da igual, lo importante es que i) exista una convención y ii) todos la utilicen. El último tendrá que adaptarse, no hay más remedio.
Si tú eres el único desarrollador de algo, o tú eres el que lo empieza, puedes elegir la convención que te de la gana, pero cuando gente que lleva un porrón de años recomienda usar una convención "X" es por algo, probablemente tengan buenas razones. En el caso de Python, se recomienda tabular con 4 espacios, es un buen compromiso entre código compacto (no te vas mucho más allá de la columna 80, importante si editas en una terminal remota) y separación de bloques lógicos.
#95 > Pero se acuerda entre TODOS los participantes en el proyecto, no el deseo personal del programador de Python
Llega nuevo a un proyecto y les dices a todos que tabulen a 8 espacios que a ti te agobia verlo todo tan apretado cuando se tabula a 4 espacios, que es la convención que siguen en ese proyecto/empresa/loquesea.
> ¿Por qué tengo que llevar yo la ropa que le gusta a otra persona? ¿Como la combinación "traje+corbata+cero joyas+pelo corto" que se imponía por la fuerza antes y aún se sigue intentando imponer?
> A mi es que esto me recuerda a cuando se les dice a los zurdos que usen siempre la mano derecha. Creerán que usan la izquierda por capricho.
Espero que no tenga que trabajar con un ser tan libre, sensible y especial como tú en ningún proyecto. Vamos, no jodas, ni que te estuviesen obligando a hacer un sobreesfuerzo cognitivo o cuestionando tus principios morales. Estamos hablando de convenciones, cosas como poner una llave en la misma línea de la declaración o en línea nueva, tabular con 8 o 4 espacios, usar nombres CamelCase o con_guiones,... vamos, tampoco veo tan difícil ni traumático adaptarse a eso, digo yo.
(Si tienes algún tipo de disfuncionalidad te pido disculpas, en ese caso sí que entiendo que tengas unas necesidades especiales).
> pues que tiene varias versiones incompatibles entre sí.
¿Y? Si es un proyecto "legacy", usas la versión 2.*, si no, pues la 3. Punto. Fin del problema.
Si tienes que migrar código... pues usas 2to3 o te mantienes en la versión 2.*, que tendrá soporte y actualizaciones unos cuantos años más.
> La causa de que me parezca una mierda es que saber
> en que formato me estaban volviendo las cosas x ejemplo
> de una consulta sql era a prueba y error.
#95 Python te fuerza a agrupar con espaciado consistente. Si quieres usar tabuladores, 4 espacios, 8 espacios o 20 espacios es cosa tuya... y de tu jefe de proyecto.
Desde Python.org aconsejan y evangelizan una serie de convenciones porque llevan programando con el lenguaje muuuuucho tiempo y saben de qué hablan, por eso conviene seguir las convenciones de un lenguaje. Las suelen establecer personas sabias y expertas, y no en base a ningún capricho, si no a la experiencia.
Otra cosa es que no te guste la sintaxis del lenguaje. A mi sí, y como llevo programando muchos años con muchos lenguajes y entornos, afirmo con conocimiento de causa que Python es uno de los lenguajes más legibles.
#82 Llevo 15 años programando con todo tipo de lenguajes, y, con diferencia, tras una breve adaptación inicial, el más legible es Python.
Siempre hay algún gracioso que se hace el original con las llaves, espaciados, etc... con Python la claridad de escritura es obligatoria. Se pueden escribir burradas, por supuesto, pero son burradas más claras.
(One-liners originales/ofuscados escritos en Python debajo de la raya )
------------------------------------
#83
> ¿Y porqué hay que estandarizar nada? ¿Por qué tengo que llevar yo la ropa que le gusta a otra persona?
Cuando llegas a un proyecto de miles de línea de código, es muy bueno saber dónde estará cada cosa y saber que algo llamado NosequéController es eso, un controlador, que algo que está bajo models/ representará una entidad en la base de datos, etc.
También viene muy bien tener un código consistente, y no que cada uno use el lenguaje como le pete: aMiMeGustaCamelCase, pero_a_mi_guiones, IPreferUseEnglishAndLongVariableNames, min_style_is_preferido....
Unos ponen la llave al final, otros al principio de cada línea, unos tabulan con TAB, otros con 4 espacios...
Para tus proyectos personales, programa como te de la gana. Para trabajar con otros, esta aproximación de "mi propio estilo" no funciona en absoluto. Hay que acordar un estándar y usarlo sacrificando preferencias personales en bien de todos.
#70 Quizás esté anticuado, no sé. Sigo viendo lagunas en este modelo. Si usas un MVC en un escritorio HTML... ¿quién es el controllador que va modificando el estado del HTML? ¿Un Apache o servidor web embebido? ¿O tiras de HTMLs predefinidos y vas pasando de uno a otro?
Me encantaría ver algún programa o proyecto hecho así (y que no sea FirefoxOS).
#65 Perfecto, pero no me pongas un componente webkit-gtk, por ejemplo, a interpretar CSS para pintar las transparencias, que el toolkit directamente sea estilable por CSS (como ya se hace).
Cualquier toolkit decente hoy en día permite definir componentes en base a un layout y el motor ya pinta el componente, no se necesita HTML para eso.
Lo siento, no veo el HTML haciendo desktop. Como parte de componentes, sí, pero como base del escritorio no. Ni por rendimiento ni por tiempo de desarrollo.
Voy a dejar este hilo de comentarios porque me estoy poniendo de mala leche. Si este es el nivel que tenemos... no me extraña que nos vaya como nos va. La de sandeces que he leído en un rato.
#56 Precisamente, Angular, Ember, Metor... eso son frameworks o conjuntos de utilidades, yo hablo del lenguaje en sí mismo. Tu respuesta me reafirma en lo que pienso. Hablas a alguien de un lenguaje y te responde mencionando frameworks sobre ese lenguaje. Como hace unos años que la gente se te presentaba diciendo "se programar en jQuery"
#55 Ah, claro, los componentes/toolkits nativos no pueden ser atractivos ni son cross-platform. Entiendo. En realidad, ¿para qué queremos un desktop?. Que toda nuestra pantalla sea un canvas webkit y ya. Sería el ideal según lo que propones
¿Afirmas que se puede desarrollar muchísimo más rápido una "interfaz atractiva" (define 'interfaz atractiva') en HTML/CSS/JS que funcione en todos los entornos/resoluciones antes que con un toolkit multiplataforma (QT, WX,...)? Es una generalización tan burda que me asusta. Si estás haciendo un cliente de Twitter, todavía, pero vamos, a poco que tengas que interaccionar con el SO... me suena a que estás diciendo una barbaridad.
#50 ¿En qué sentido le dan mil vueltas, como afirmas? ¿Puedes ser más específico? En eficiencia, lo dudo, desde que el mismo "intérprete" de html/css/js es un componente basado en el toolkit nativo (webkit-gkt/webkit-qt, etc), ya estás metiendo una capa entre medias, y podrías estar "pintando" contenido directamente en el toolkit nativo en vez de en un canvas html.
#33 Pues fíjate, yo opino lo contrario, y conozco bien los dos lenguajes. Python es más ordenado, desde los mismos desarrolladores se anima a que se haga código elegante, fácil de leer, mantenible, etc. Se puede guarrear, pero ya solo el que te fuercen a indetar el código ayuda mucho.
Solo se ha tomado en serio a Javascript desde hace poco tiempo, antes era una especie de VisualBasic para la web. Desde mi punto de vista de desarrollador veterano (>15 años picando código), a JS lo que le hace falta ahora es que se estandarice un estilo, una forma de hacer las cosas y sobre todo, que la gente que programe JS lo haga con una cierta base.
Esto parece el Barrapunto de hace unos años. Qué manía de mezclar churras con merinas.
Poner Node/JS al lado de C es incorrecto e inapropiado por dos razones:
a) Node es un intérprete de un lenguaje, JS. C es un lenguaje que se traduce a código nativo. Son dos cosas totalmente diferentes y no comparables.
b) Un camión es más lento que un fórmula uno. ¿Qué sentido tiene comparar JS/Node con C, cuando su ámbito de aplicación es totalmente diferente? Nadie programaría un controlador en JS/Node y nadie programaría una API REST con C, al igual que nadie haría el reparto de mercancía en un fórmula uno o iría a un circuito con un camión de reparto.
#21#11 Tk es residual, aunque sigue siendo el toolkit de referencia en muchos proyectos (ej: gitk).
Qt en desktop se usa muchísimo: KDE, clientes de escritorio de todo tipo (se me viene Skype a la cabeza, VirtualBox,...)
El día que se implante definitivamente en el desktop el paradigma HTML+JS+CSS, vuelvo a la terminal para siempre, no me jodas. Hay buenas ideas por ahí, como en GTK estilar los constroles con una especie de CSS, o poder poner widgets HTML en el escritorio, o "scriptear" el escritorio con JS, pero de ahí a que el escritorio en sí sea HTML+JS+CSS... que mis ojos no lo vean, por favor.
#4 --494581-- 
)
