Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| | Eu cada vez uso mais o XML, realmente é um mundo. Uso mais para guardar informação em ficheiros, crio idiomas XML que me permitem ter ficheiros de configuração complexos, ou até ficheiros simples. Sendo que, com ficheiros simples e, aliando o XML à serialização de objectos, consigo ter uma forma muito rápida, prática e eficaz de os ler para memória(isto do ponto de vista do desenvolvimento). O problema do XML, é que a extensibilidade e o facto de podermos fazer tudo o que quisermos não vem de borla. Parece-me pesado ter uma árvore DOM em memória, mais pesado ainda fazer buscas. XPath, XQuery, são coisas lentas, XSLT idem. Contudo, cada vez estamos com mais poder de processamento, por isso talvez este ponto não seja assim tão importante. Como sempre, tem de se ver caso a caso. Para mim, o XML é tem o seu lugar mais acentuado é no transporte de informação(ou representação de informação), e em ficheiros de configuração. E realmente, dá mesmo muito jeito para essas coisas. Acho que neste momento que não sabe o que é XML e Schemas e etc está a perder um pouco da tecnologia de hoje em dia, pois isto fala-se em todo o lado... E convém conhecer todas as ferramentas que temos à mão, para que possamos fazer uma melhor aplicação do que queremos. _____________________ Pedro Santos :: psantos.net :: blog |
| |
|
| | e em ficheiros de configuração Eu não concordo com esta utilização do XML, torna os ficheiros de configuração demasiado pesados para serem editados à mão, mas mesmo assim melhores que aquela aberração do m4 que usa o sendmail...
-- Carlos Rodrigues |
| |
| | GDM, e as conf do gnome, se não estou em erro, estão todas formatadas por xml Cumps- Gass |
| |
| | só uma aparte, secalhar o uso disto: http://java.sun.com/xml/jaxb/ é capaz de ser mais interessante que a serialização.
Java Architecture for XML Binding (JAXB) provides a convenient way to bind an XML schema to a representation in Java code. This makes it easy for you to incorporate XML data and processing functions in applications based on Java technology without having to know much about XML itself |
| |
| | hmm é impressão minha, ou para isto o melhor seria usar o RMI? Tens de ter conhecimento da definição das classes dos dois lados, tal como no RMI. Tens algo que serializa e "desserializa" um objecto, tal como no RMI... porque é que não usas o RMI??? yet, este JAXB também pode ser utilizado para persistir o estado de uma classe num ficheiro de texto... mas, o Java só por si já tem estas ferramentas (que são usadas pelo RMI). A única diferença assim de repente que vejo, é que um usa um stream de texto e outro um stream de binário... NMO, QSF o texto, não traz qualquer vantagem adicional :)
--- Este espaço pode ser seu! |
| |
| | Estas a confundir as coisas -- o JAXB e' apenas um meio de mapeares objectos XML directamente num conjunto de classes Java -- nao tem nada a ver com serializacao (embora possa ser usado para isso) nem com invocacao de metodos remotamente. I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | Tal como o leitao disse, penso que estas a confundir as coisas. A questão de fundo, a que deu uma sugestão de resolução no meu post é a da passagem de uma estrutura representada em xml para uma estrutura de dados que possa ser manipulavel por um programa, neste contexto a serialização era uma maneira de resolver este problema. O jaxb é uma ferramenta que faz o mapeamento directo de um ficheiro xml para uma estrutura de objectos em java, para isso apenas precisas de ter o ficheiro xml com os dados, e um xml schema com a defenição de estrutura desse ficheiro, o resto do código vem de borla! A implementação de rmi (remoted method invocation) do java realemnte algures vai ter que lidar com o problema da serialização dos objectos, mas como disse a serialização era apenas uma maneira de resolver a questão. |
| |
XML (Pontos:0, Redundante) |
| | É um standard para facilitar a interligação de informação e que como todas as coisas do mundo tem um lado positivo e negativo. Quando começa a ser usado sem se considerar todos os factores, poderemos estar a iniciar um problema. É uma revolução , que não se pode parar , mas o seu uso indiscriminado e massivo, traz em certos casos problemas de performance e carga que podiam ser evitados, se o pessoal , especialmente em projectos internos, atinasse um pouco. Ainda não li os artigos referidos, mas vou fazê-lo
Todas as coisas começam pequenas e simples, e depois, evoluem... |
| |
XML (Pontos:3, Informativo) |
| | Comecei a usar o XML assiduamente desde há 2 anos atrás e já caí num perigoso erro, que é tentar usar o XML em tudo, o que é errado. Errado, porque fazer o parsing XML é bem mais lento do que ler um ficheiro ASCII para, por exemplo, guardar nomes e idades de uma pessoa, no caso do ficheiro ser intransmissível. O que me sucedeu a mim, sucedeu-se a muito mais gente pelo que tenho reparado: usar XML em tudo, o que trás problemas de eficiência. O XML é um standard human-readable o que é muito bom para troca de ficheiros entre terceiros. Agora, não percam tempo a implementar em XML em situações que não há necessidade para tal! Um exemplo onde o XML é muito bem aplicado é a gravar um ficheiro do OO.org: na verdade, aquilo é um ficheiro comprimido com ficheiros XML. É sempre bom, pois mesmo não tendo o OO.org, podemos recuperar o conteúdo e, caso o nosso destinatário não tenha o OO.org, pode facilmente escrever um programa que faça parsing, ignore a formatação, e retire apenas o conteúdo :-) Welcome to the wonderful world of XML, but use it wisely!
Dominus vobiscum |
| |
|
Re:XML (Pontos:3, Informativo) |
| | um ficheiro do OO.org: na verdade, aquilo é um ficheiro comprimido com ficheiros XML Na verdade na verdade, até é mesmo um zip renomeado (tal como os .jar etc...): [rms@roque rms]$ unzip -l Carta_aviso_prrt.sxw Archive: Carta_aviso_prrt.sxw Length Date Time Name -------- ---- ---- ---- 30 06-11-04 11:53 mimetype 18 06-11-04 11:53 layout-cache 7906 06-11-04 11:53 content.xml 9969 06-11-04 11:53 styles.xml 1121 06-11-04 11:53 meta.xml 7443 06-11-04 11:53 settings.xml 850 06-11-04 11:53 META-INF/manifest.xml -------- ------- 27337 7 files |
| |
| | ...usar XML em tudo, o que trás problemas de eficiência... Até de gramática, pelo que vejo. |
| |
| | Errata: traz. Obrigado pela correcção, escapou-me, seems I'm an human too! :-)
Dominus vobiscum |
| |
| | Desculpa .. mas para quem usa o XML à dois anos, disseste algumas barbaridades. Uso o XML à também aproximadamente 2 anos e não entrei nessa euforia. Iniciamente a euforia do XML era a substituição das ASP (Windows). Até se criaram grupos de trabalho onde se discutia as diferenças do uso do XML/XSL e o ASP. Já nessa altura achei que eram estupidas essas discussões, pois, tem âmbito de uso diferentes. Agora usa-se o XML onde eu acho que realmente faz algum sentido, que é precisamente na interligação entre sistemas heterogéneos. A grande vantagem do XML nesta área em relação ao ficheiros de Texto é o facto de a cada campo podermos associar o seu nome, tipo de dados, tamanho, etc., como fazemos com uma base de dados. É verdade que desta forma estamos a inserir mais informação nos ficheiros que fazem a ponte entre os sistemas, mas, com essa informação não necessitamos de extensos manuais a explicar como se deserializa a informação. Outro ponto, segundos os meus testes, contraria o que dizes, tem precisamente a haver com a velocidade de leitura de um file em XML. O exemplo que aqui vou expor foi desenvolvido usando a plataforma .NET da Micro$fot. Tenho um ficheiro com aproximadamente 17.000 registos escritos de uma forma tabular separados por "pipes" (|). A leitura deste ficheiro e consequente inserção numa base de dados SQLServer demorou cerca de 7minutos. O ficheiro tinha aproximadamente 800K. A mesma informação num ficheiro XML, com nomes dos campos extensos prefazia um total de 4.8Mbytes e um outro com os nomes dos campos com 3 caracteres prefazia aproximadamente 3Mbytes. Em qualquer um das versões em XML da mesma informação demorou o mesmo tempo a deserializar e inserir o seu conteúdo na base de dados e demorou em média mais 20 segundos que no ficheiro original. Com base nestes testes, foi adptado o XML como plataforma de criação do ficheiro de importação de informação.
Não digo que temos que usar o XML em tudo, pois, não é em tudo que podemos tirar o maior partido dele, mas, quando o acesso random à informação não é necessária e o que prevalece é o acesso sequencial, estou totalmente de acordo que o XML é melhor, mais rápido, Human-Readable e mais fácil de desenvolver interfaces.
(()) Esqueleto ------------------------------ Visit me in: http://www.tusofona.com/esqueleto |
| |
| | disseste algumas barbaridades. Importaste de ser mais explícito? Enumerar para eu perceber quais as barbaridades que disse... Agora usa-se o XML onde eu acho que realmente faz algum sentido, que é precisamente na interligação entre sistemas heterogéneos. Obviamente e eu nunca disse o contrário. Tu leste foi o meu post na diagonal. Eu refiro é que, para utilização interna, por exemplo de ficheiros ASCII com nomes e idades, é supérfluo usar XML. Se eu mantenho, num programa apenas meu, uma lista para manipulação interna, para quê complicar e perder tempo com parsers XML? Outro ponto, segundos os meus testes, contraria o que dizes, tem precisamente a haver com a velocidade de leitura de um file em XML. O que é lento são os parsers e a verificação constante dos XSchemas ou DTDs, onde se perde muito tempo. Mas claro, se fizeres como o Zé da Esquina que escreve um parser só para evitar os erros de validação, então já não deves sofrer de grandes problemas! Outro caso flagrante onde o XML é muito importante é para armazenar as informações dos Content Managers de qualquer GUI em Java, Python, whatever, pois permite, muito facilmente, fazer internacionalizações i18n.
Dominus vobiscum |
| |
| | Estou em desacordo com esta afirmação: porque fazer o parsing XML é bem mais lento do que ler um ficheiro ASCII Como já disse ... uso XML com a plataforma .NET e nesta plataforma o acesso a um file XML, mesmo que 5x maior que o ficheiro tabular em Text-Pain é praticamente idênfico, provando assim que a leitura do XML está muito mais optimizada do que a leitura sequencial de um ficheiro de texto. Penso também que te deslumbraste com o uso do XML O que me sucedeu a mim, sucedeu-se a muito mais gente pelo que tenho reparado E esse foi o teu erro e de muitas pessoas que acharam que o XML era a "pilula" que iria resolver todos os problemas da informática, mas, isso não é verdade como pudeste resolver. Se calhar fui demasiado duro nas minhas palavras, mas não li o teu post da diagnonal. Da forma que interpretei, pensei que tinhas deixado de usar po XML porque ele não servia para nada, ou pelo menos n servia para as necessidades dos comuns dos mortais apesar de ter algumas coisas boas. Foi simplesmente uma interpretação pessimista das tuas palavras. Desculpa (()) Esqueleto ------------------------------ Visit me in: http://www.tusofona.com/esqueleto |
| |
| | Como já disse ... uso XML com a plataforma .NET e nesta plataforma o acesso a um file XML, mesmo que 5x maior que o ficheiro tabular em Text-Pain é praticamente idênfico, provando assim que a leitura do XML está muito mais optimizada do que a leitura sequencial de um ficheiro de texto. O que você diz depõe contra a .NET e não à favor do XML... :-P Não tenho nada contra o XML, pelo contrário. Ainda pior, confesso que sou é fã do SGML e do DocBook (que são, por sinal, ainda mais pesados que o XML). Mas é uma insanidade afirmar que ler e parsear um arquivo CSV (comma separated values) em ASCII e fazer o mesmo num arquivo XML (que por sinal ainda pode estar em UNICODE) possuem esforço computacional equivalente... Eu não tenho a mínima idéia de como a .NET pôde destruir de tal forma o algoritmo de leitura de um arquivo ASCII seqüencial à ponto dele se comportar desta forma... Existe ainda outra possibilidade : o que tá pegando no seu sistema é I/O ou o processamento dos dados lidos. Em míudos : o seu sistema fica tanto tempo esperando por I/O (por problemas de latência, já que a largura de banda parece ser suficiente), ou os cálculos que seus dados alimentam são tão pesados, que o overhead da leitura XML não é sentido.
[]s, Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| |
| | Errata: para quem usa o XML há dois anos. Francisco «flip» Colaço
Em Portugal nada se conclui acerca da existência de vida inteligente no Planeta Terra. |
| |
| | escapou-te o "prefazer". na realidade o verbo é "perfazer" Grumpy B) |
| |
| | Lembro-me que nos idos de 91 foi por causa de não ter detectado um erro que não tive 100% na prova geral de acesso. O FLIP anda a falhar. Francisco Colaço
Em Portugal nada se conclui acerca da existência de vida inteligente no Planeta Terra. |
| |
| | De um formato de serialização de dados ....wrong! O XML não é um formato de serialização de dados. Pensar nele dessa forma é um erro crasso. O XML é um formato (markup language) que permite definir multiplos formatos/markup languages. Se o seu uso mais obvio e simplorio é a substituicao de ficheiros ASCII (ou a serializacao), a sua importancia é mto maior no q diz respeito 'a definição de dados q incluem informacao sobre si proprios (metadata) ou 'a possibilidade de definir estruturas de dados hierarquicas (por oposicao a estruturas tabulares) mto mais adequadas a um paradigma OO. Cumprimentos Mario Valente |
| |
|
| | ...o seu uso mais obvio e simplorio é a substituicao de ficheiros ASCII... Ora, para quem está a tentar corrigir, bem que um bocadinho mais de atenção ao que diz, não faria mal nenhum. ASCII é um acrónimo para American Standard Code for Information Interchange, e representa uma codificação da linguagem natural de forma a ser percebida pela máquina. Falar numa coisa como "substituição de ficheiros ASCII" faz tanto sentido como dizer "substituição de ficheiros UTF-16". Sim, o princípio do XML é o de definir estrutras, e é precisamente esse poder que não o limita somente ao "uso simplório de substituição de ficheiros", visto que tem a possibilidade de representar a informação de uma forma muito mais rica do que, por exemplo, o formato .ini. Concordo com o que foi dito por ti, e estou certo que já sabes o que quero dizer, mas não queria deixar que passem ideias incorrectas a algum leitor menos atento. |
| |
| | a sua importancia é mto maior no q diz respeito 'a definição de dados q incluem informacao sobre si proprios (metadata) Algo que um dos artigos indica como o mau caminho que o XML leva.
-- Carlos Rodrigues |
| |
XML... (Pontos:2, Esclarecedor) |
| | Eu acho que o XML é muito mal usado. Na maior parte das vezes qualqer feicheiro de ASCII faria muito melhor trabalho que um ficheiro de XML. O XML é realmente muito usado mas quase sempre a baixo das suas reais capacidades. Vivemos a febre do XML e quando essa febre passar pode ser que se passe a usar o XML onde realmente faz falta.
... Ou então não. |
| |
|
| | Concordo! Por vezes uma simples lista ascii tipo ---------------------------- #isto é um comentário nomeA prop1 ... propN ... nomeB prop1 ... propM ---------------------------- é muito mais fácil de tratar! awk, sed e/ou grep e voilá |
| |
| | Oh, mas é muito mais leet mostrar ao patrão que usou DOM ou então um SAX parser... Ainda sofremos desse mal: fazer as coisas para Inglês vêr, em detrimento de eficiência e eficácia.
Dominus vobiscum |
| |
| | awk, sed e/ou grep e voilá Mostra aqui por favor (code...) como consegues do ficheiro q referes extrair uma lista de nomes. Cumprimentos Mario Valente |
| |
| | cat ficheiro.txt | tr -s ' ' | cut -f 1 -d ' ' Easy.
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong. |
| |
| | não não... mostra isso em C ou Java :)
--- Este espaço pode ser seu! |
| |
| | system("cat ficheiro.txt | tr -s ' ' | cut -f 1 -d ' '"); |
| |
| | Em Java não faz sentido fazer chamadas ao sistema, pois o intuíto do Java é ser uma linguagem portável e duvido que todos tenham bash ou outra unix shell a correrem em windows!
Dominus vobiscum |
| |
| | Pronto, la' vem este mandar uns bitaites... Fazer "chamadas ao sistema" (que neste caso e' executar uma linha de comando) nao e' portavel seja em que linguagem for -- seja Perl, Python, C, LISP ou Ada. A falta de portabilidade neste caso e' o facto de utilizares a linha de comando, nao tem nada a ver com o facto de ser Java ou seja la' o que for. I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | Mas eu disse isso? És impressionante a deturpar o conteúdo. O que eu disse foi que no caso do Java, que é uma linguagem para ser portável, não convém fazer chamadas ao sistema. Se eu vou desenvolver um programa em C, cuja portabilidade é muito menor do que Java e que exige, quase sempre, alteração de código para ficar compatível entre sistemas, não tem qualquer problema fazer uma chamada ao sistema. Acho que as tuas deturpações advêm de falta de clareza mental. Desiludes-me cada vez mais, eu que achava que primavas pela inteligência, certamente daí não vem nada!
Dominus vobiscum |
| |
| | Se eu vou desenvolver um programa em C, cuja portabilidade é muito menor do que Java e que exige, quase sempre, alteração de código para ficar compatível entre sistemas, não tem qualquer problema fazer uma chamada ao sistema. Voltas a bater na mesma tecla -- a escolha da linguagem e' apenas marginalmente importante quando toca a portabilidade. E como qualquer programador Java te pode dizer, o uso de Java nem sempre implica portabilidade automatica (ou raramente) -- nem que seja porque raramente o software funciona num vacuo. Acho que as tuas deturpações advêm de falta de clareza mental. Desiludes-me cada vez mais, eu que achava que primavas pela inteligência, certamente daí não vem nada! Nunca ninguem te explicou que no Real World (TM) "deturpacoes" sao o pao do dia a dia ? Ou achas que aplicar as coisas a preto e branco e' o que faz funcionar as coisas ? I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | O meu salva-vidas: UnxUntils Port de algumas das mais uteis GNU/Utils para win32 nativo ( dependentes apenas da c-runtime do windows). cat, egrep, gawk, sed, diff... maravilha! Cumps, floWS |
| |
| | LOL tá lindo :D Pela discussão que houve por aqui há algum tempo, estás mais que capaz para te juntar à equipa de desenvolvimento de uma distribuição de Linux... Disclaimer: eu pessoalmente não vejo mal nenhum em usar este tipo de comandos.
--- Este espaço pode ser seu! |
| |
| | cat ficheiro.txt | tr -s ' ' | cut -f 1 -d ' ' Nao. Nao funciona... Pus no ficheiro a linha Mario Valente 234 345 456 ... e só apareceu Mario. Next try... Cumprimentos Mario Valente |
| |
| | dataFile = open('ficheiro.txt') nameList = [name[:-1] for name in dataFile.xreadlines()] Que tal este? ;) Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
| | Nao funciona. Next... Cumprimentos Mario Valente |
| |
| | Chato! :p
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
| | Nao funcionou porque a tua especificacao foi da treta -- da proxima documenta os teus requerimentos como deve ser que obtens melhores resultados. Mas ok, por esta nao te cobro nada ;-) I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | Nesta não tens razão, criaste foi uma solução para um problema que não era este, não soubeste foi ouvir o cliente ;o)
"There is no reason for any individual to have a computer in his home." - Kenneth H. Olson , President of DEC, Convention of the World Future Society, 1977 |
| |
| | Eiiiiaa, será que foi por isso que aquele projecto onde ele esteve, onde se gastou milhões de pounds, mas depois foi pró canudo?
"No comments" |
| |
| | Não sejas mau, ou ingénuo... "There is no reason for any individual to have a computer in his home." - Kenneth H. Olson , President of DEC, Convention of the World Future Society, 1977 |
| |
| | Tu por apenas meia dúzia de palavras, vês se uma pessoa é ou não ingénua.. a telepatia faz milagres!
I'm a lost soul in this lost world... |
| |
| | Eu sou assim... não, e não é nenhum dom telepático, e ele pode sempre desmentir se não for o caso... ;o)
"There is no reason for any individual to have a computer in his home." - Kenneth H. Olson , President of DEC, Convention of the World Future Society, 1977 |
| |
| | Em que ficámos?
"No comments" |
| |
| | Eu fiz um comentário brincalhão, o teu pareceu-me na onda lança-chamas ;o) mas volto a frisar pareceu-me, só tu o podes confirmar ;o)
"There is no reason for any individual to have a computer in his home." - Kenneth H. Olson , President of DEC, Convention of the World Future Society, 1977 |
| |
| | Posso dizer-te que os 2 foram em tom de brincadeira, só que já não tenho pachorra para por :-) ou um aviso a dizer "atenção é a brincar..." P.S. Mas aquele "ingénuo" não foi lá muito a brincar, ora diz lá...
"No comments" |
| |
| | Era salvaguardar a hipótese de nunca teres participado em grandes projectos, ou de não perceberes porque falham os projectos, não quero com isto dizer que a culpa de não teres essa experiência fosse tua, e por esse motivo não pode ser considerado depreciativo...
"There is no reason for any individual to have a computer in his home." - Kenneth H. Olson , President of DEC, Convention of the World Future Society, 1977 |
| |
| | Eu NUNCA tomo a iniciativa de provocar ninguém...
"There is no reason for any individual to have a computer in his home." - Kenneth H. Olson , President of DEC, Convention of the World Future Society, 1977 |
| |
| | Nao funcionou porque a tua especificacao foi da treta Nao funcionou pq tu julgaste q eras um programador mais esperto do q o analista. O analista qd pediu codigo especifico era para demonstrar q de facto com as especificacoes usadas (usando o espaço em branco como separador) nunca iria funcionar. Cumprimentos Mario Valente |
| |
| | O analista qd pediu codigo especifico era para demonstrar q de facto com as especificacoes usadas (usando o espaço em branco como separador) nunca iria funcionar. Sim, ja' tive clientes assim... normalmente acabam por ir 'a falencia. ;-) I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | O que? Mario Valente 234 345 456 A isto chamo escolher exemplos para chatear... usa um separador de campos :P, por exemplo ":" Mario valente:234 345 456 depois é só fazer cat lista.txt | awk -F : '{ print $1 }' compara o overhead disto de do equivalente xml e depois diz qualquer coisa... :) |
| |
| | "Exemplos para chatear" sao os q existem em 99% dos casos no mundo real. Usar um separador diferente de espaços em branco de facto resolve o problema. Mas a ideia original de q era facil com sed,grep,etc obter uma lista de nomes é falsa. E isso é demonstrativo do problema dos ficheiros ASCII simples e da vantagem do XML. Quanto ao formato "Mario valente:234 345 456": imagina q em vez disso te mando um ficheiro com linhas do tipo "a:b;c,d|e-f". Faz-me o parse disto por favor... Qd perceberes pq é q nao consegues, percebes qual a vantagem do XML. Cumprimentos Mario Valente |
| |
| | Leva lá a bicicleta! :P Eu tenho-me safade extremamente bem com nested lists à la Tcl/Tk para além dos já referidos Unix Utils... Cumps, Sputtnik
|
| |
| | Tens aqui um exemplo em PHP, tb serve? :P Acho que com Perl / Shell Script se poderá usar algo para fazer aquilo na boinha. Acho que não é preciso andarem aqui a provar seja o que for... <?php $str="nomeA prop1 ... propN"; for ($i=0;$i<strlen($str);$i++) { if ($str[$i]!=" ") printf("%s",$str[$i]); else printf("<br>"); } ?>
I'm a lost soul in this lost world... |
| |
| | Nao funciona. Next.... Cumprimentos Mario Valente |
| |
| | Mario, gostas de Python??? :) vê lá se esta linha em python não faz tudo o que é preciso???
[line.split(' ') for line in open("teste.txt").readlines()]
... Ou então não. |
| |
| | Nao funciona. Venha o proximo candidato... Cumprimentos Mario Valente PS - Dica: enquanto o separador for o espaço em branco, NUNCA vai funcionar. |
| |
| | Funciona porque eu testei. Agora se queres algo mais eficiente e que apanhe nomes com espaços, o ficheiro tem que ser diferente e consequentemente o codigo tambem mas isso são coisas pequenas demais para estar a falar aqui.
ficheiro 'Mario Valente' '234' '345' '456' (garantir que todas linhas iguais a esta acabam com um \n) ;)
codigo [line[1:-3].split("' '") for line in open("teste.txt").readlines()]
... Ou então não. |
| |
| | Funciona porque eu testei. Pelos vistos nao testaste com nomes com espaços (ie nomes completos). Grandes testes os teus... Pois, usando delimitadores diferentes já se consegue resolver o problema. O ficheiro e' diferente e o código já nao é tao simples; isto nao são "coisas pequenas": sao coisas grandes q precisamente o XML resolve. P.ex.: "garantir que todas linhas iguais a esta acabam com um \n)". Isto, na vida real, é para rir. Assim como colocar as plicas ('') E já agora: o teu codigo novo falha se houver mais do q 3 campos adicionais. Mais uma vez, problemas dos files ASCII resolvidos com o uso de XML. Cumprimentos Mario Valente |
| |
| | [line[1:-3].split("\t") for line in open("teste.txt").readlines()]
"Para mim a tecnologia é como as tangerinas, na medida em que não consigo fazer uma analogia decente sobre nenhuma das duas neste momento" Scott Adams |
| |
| | No python 2.3 já podes fazer: line[1:-3].split("\t") for line in file("teste.txt")] |
| |
| | Pois, usando delimitadores diferentes já se consegue resolver o problema. O ficheiro e' diferente e o código já nao é tao simples; isto nao são "coisas pequenas": sao coisas grandes q precisamente o XML resolve. Entendi seu ponto de vista, mas usar XML para resolver este problema é terrivelmente ineficaz. O problema específico a que vc se refere pode ser facilmente resolvido com TSF (Tab Separated Fields). Lógico que vc pode argumentar que o caractere de controle ASCII 9 (o Tab) pode ser necessário como dado em algum campo, mas aí também já é forçar a barra, concorda? Se o seu problema é armazenar, transmitir e recuperar tuplas em formato legível por humanos, até VSAM resolve (ok, agora quem forçou fui eu). Mas se o seu problema é armazenar, transmitir e recuperar dados semi-estruturados, aí então XML rulez. Sem dúvida que um fuzil para matar elefantes dá cabo de um cachorro doente. Mas ainda é um fuzil para matar elefantes...
[]s, Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| |
| | eu agora até já jogo em XML xD. ps: eu ainda sou do tempo em que se usava ';' para separar valores entre si (aka csv) |
| |
|
| | CSV e' ",", nao ";" :) I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | Dificilmente podes chamar csv a um ficheiro em que o separador não é uma "," (coma).
"Para mim a tecnologia é como as tangerinas, na medida em que não consigo fazer uma analogia decente sobre nenhuma das duas neste momento" Scott Adams |
| |
| | Esse é um scsv.
Em Portugal nada se conclui acerca da existência de vida inteligente no Planeta Terra. |
| |