Re: python3 regex?
On Saturday, September 10, 2016 at 4:12:17 AM UTC+1, Doug OLeary wrote:
> Hey;
>
> Long term perl ahderent finally making the leap to python. From my reading,
> python, for the most part, uses perl regex.. except, I can't seem to make it
> work...
>
> I have a txt file from which I can grab specific titles via a perl one-liner:
>
> $ perl -ne 'print if (m{^("?)[1-9]*\.})' tables
> 1. ${title1}
> 2. ${title2}
> "3. ${title3}",,,
> 4. one more title
> 5. nuther title
> 6. and so on...,,
> ...
> 25. last title
>
> I can't seem to get the same titles to appear using python:
>
>
> $ python -V
> Python 3.5.2
> $ python
> Python 3.5.2 (default, Jul 5 2016, 12:43:10)
> [GCC 5.4.0 20160609] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import os
> >>> import re
> >>> with open('tables','rt') as f:
> data = f.read()
>
> printing data results in the output I would expect..
>
> Trying to compile a regex and display the results does not show the same
> results I get from perl.
>
> >>> regex = r'^("?)[1-9]*\.'
> >>> re.search(regex, data)
> >>>
>
> >>> p = re.compile(r'^("?)[1-9]*\.')
> >>> p
> re.compile('^("?)[1-9]*\\.')
> >>> p.findall(data)
>
> I've tried any number of options shown on the net all with the same result.
> Can someone point out what I'm messing up?
>
> Thanks
>
> Doug
I'm no regex expert but would this third party module
https://pypi.python.org/pypi/regex help?
Kindest regards.
Mark Lawrence.
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to diagnose CERTIFICATE_VERIFY_FAILED on Windows for websites working in browsers?
Chi Hsuan Yen writes: > ... > I found that OpenSSL provides an X509 callback hook that allows clients to > know why the verification process fails. For a long time, Python 2 (unlike Python 3) did not perform certificate validation at all. As a consequence, some developpers provided the functionality in external packages. Maybe, one of those exposes the callback you have found. I never used one of those packages and cannot provide more information that what I said above. You might also look at "PyOpenSSL" (--> "PyPI"). Apparently, it supports callbacks written in Python. Again, I have not myself used this package. -- https://mail.python.org/mailman/listinfo/python-list
Re: Mysterious Logging Handlers
Josh English writes:
> I have a Python script that imports a utility script. Both scripts use
> logging, but the logs don't work as advertised. I'm getting logging output
> from the utility script but none from the main file. Worse, the format of the
> utility script's logs don't match anything I define.
>
> The utility script is called xlreader.py. It has the following lines:
>
> -- begin snippet --
> import logging
> XLOGGER = logging.getLogger('XLREADER')
> -- end snippet --
>
> And it calls XLOGGER.debug(), XLOGGER.error() and XLOGGER.info() but it never
> defines a handler.
> ...
Python's logging system is quite complex. Among others, it has a logger
hierarchy where loggers on a lower level can delegate to their parent.
Usually, most configuration happens at the so called "root logger"
and is used by all loggers which have not overridden certains aspects.
In your special case, the handlers likely come from the "root logger".
--
https://mail.python.org/mailman/listinfo/python-list
Re: Extend unicodedata with a name/pattern/regex search for character entity references?
Veek 'this_is_not_my_name' M wrote: > Rustom Mody wrote: > >> On Saturday, September 3, 2016 at 5:25:48 PM UTC+5:30, Veek. M wrote: >>> https://mail.python.org/pipermail//python-ideas/2014-October/029630.htm >>> >>> Wanted to know if the above link idea, had been implemented and if >>> there's a module that accepts a pattern like 'cap' and give you all >>> the instances of unicode 'CAP' characters. >>> ⋂ \bigcap >>> ⊓ \sqcap >>> ∩ \cap >>> ♑ \capricornus >>> ⪸ \succapprox >>> ⪷ \precapprox >>> >>> (above's from tex) >>> >>> I found two useful modules in this regard: unicode_tex, unicodedata >>> but unicodedata is a builtin which does not do globs, regexs - so >>> it's kind of limiting in nature. >>> >>> Would be nice if you could search html/xml character entity >>> references as well. >> >> [Not exactly an answer] >> >> I use a number of things for such >> 1. Google >> 2. Xah Lee’s excellent pages which often fit my brain better than >> wikipedia: >>http://xahlee.info/comp/unicode_index.html >> 3. emacs’ function ucs-insert recently renamed to insert-char >>ie [In emacs] Type Alt-x insert-char >>After that some kind of TAB-globbing (case-insensitive) works >>I wont try with Cap (because the number of *CAPITAL* is in >>thousands!) eg alphaTAB gives nothing. However *alphaTAB gives a >>bunch. Narrow to "greek alpha"TAB and you get a bunch >> >> >> The fact that we should have a series of levels for char-input from >> most general and unergonomic (google) to most specific and ergonomic >> (special purpose keyboard) Ive tried to talk of as 7 levels near end >> of http://blog.languager.org/2015/01/unicode-and-universe.html > > > got dengu - i'm dead sorry false alarm, but i was sick enough to be awol -- https://mail.python.org/mailman/listinfo/python-list
Re: Extend unicodedata with a name/pattern/regex search for character entity references?
On 10/09/2016 11:26, Veek 'this_is_not_my_name' M wrote: Veek 'this_is_not_my_name' M wrote: /me claps TJG -- https://mail.python.org/mailman/listinfo/python-list
Re: Extend unicodedata with a name/pattern/regex search for character entity references?
On Saturday, September 10, 2016 at 3:56:37 PM UTC+5:30, Veek 'this_is_not_my_name' M wrote: > Veek 'this_is_not_my_name' M wrote: Recursion… Self-Reference…Inversion Heh! On the way to becoming another Gödel/Turing?? You may be interested in this collection of some evidence(s) of recursion being one of the most central ideas in computer science see: http://blog.languager.org/2012/05/recursion-pervasive-in-cs.html > > > Rustom Mody wrote: > > > >> On Saturday, September 3, 2016 at 5:25:48 PM UTC+5:30, Veek. M wrote: > >>> https://mail.python.org/pipermail//python-ideas/2014-October/029630.htm > >>> > >>> Wanted to know if the above link idea, had been implemented and if > >>> there's a module that accepts a pattern like 'cap' and give you all > >>> the instances of unicode 'CAP' characters. > >>> ⋂ \bigcap > >>> ⊓ \sqcap > >>> ∩ \cap > >>> ♑ \capricornus > >>> ⪸ \succapprox > >>> ⪷ \precapprox > >>> > >>> (above's from tex) > >>> > >>> I found two useful modules in this regard: unicode_tex, unicodedata > >>> but unicodedata is a builtin which does not do globs, regexs - so > >>> it's kind of limiting in nature. > >>> > >>> Would be nice if you could search html/xml character entity > >>> references as well. > >> > >> [Not exactly an answer] > >> > >> I use a number of things for such > >> 1. Google > >> 2. Xah Lee’s excellent pages which often fit my brain better than > >> wikipedia: > >>http://xahlee.info/comp/unicode_index.html > >> 3. emacs’ function ucs-insert recently renamed to insert-char > >>ie [In emacs] Type Alt-x insert-char > >>After that some kind of TAB-globbing (case-insensitive) works > >>I wont try with Cap (because the number of *CAPITAL* is in > >>thousands!) eg alphaTAB gives nothing. However *alphaTAB gives a > >>bunch. Narrow to "greek alpha"TAB and you get a bunch > >> > >> > >> The fact that we should have a series of levels for char-input from > >> most general and unergonomic (google) to most specific and ergonomic > >> (special purpose keyboard) Ive tried to talk of as 7 levels near end > >> of http://blog.languager.org/2015/01/unicode-and-universe.html > > > > > > got dengu - i'm dead > sorry false alarm, but i was sick enough to be awol Given that >>> "dengue" == "dengu" False you should be fine ;-) -- https://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] Inconsistencies (was: Shuffled)
Redirecting to python-list as I don't believe this belongs on -ideas. On Sat, Sep 10, 2016 at 10:09 PM, Sven R. Kunze wrote: >> On 08.09.2016 04:00, Steven D'Aprano wrote: >> >> On Wed, Sep 07, 2016 at 11:43:59PM +0200, Sven R. Kunze wrote: >> >>> BUT experienced devs also need to recognize and respect the fact that >>> younger/unexperienced developers are just better in detecting >>> inconsistencies and bloody work-arounds. >> >> That is not a fact. It is the opposite of a fact >> > > You might have heard of: "There are no such things as facts, just opinions. > Everything, we see is a perspective not the truth." See below, why this > applies here as well. Yes, I've heard that. It is false. Some things are absolute hard facts. There is no way in which 1 will ever be greater than 2, ergo "1 is less than 2" is strictly true, and not a matter of opinion. If you hear someone trying to claim otherwise, would you let him have his opinion, or would you treat it as incorrect? >> -- inexperienced >> developers are WORSE at spotting inconsistencies, because they don't >> recognise deep consistencies. > > > Your example (default arguments) might make sense when going one or two > level deeper. However: > > > Is going deep really necessary at all? > > > People program for different reasons, to have fun, to create value for > others, to educate, or for reasons we both cannot even think of. Why should > they leave their level? Because of you or me? Because they need to know what > Turing-completeness means? What calling conventions are? I don't think so. > They wanna solve problems and get things done whether or not they know every > single bit of the language they use. If they decide to go deeper, that's > wonderful, but if they don't, don't force them. > > So, an inconsistency at level 1 might be a **result of a consistency at > level 0** BUT it nevertheless is and stays an inconsistency at level 1 no > matter how sophisticated the consistency at level 0 is. > > > And please note, some even want to go on level up, so inconsistencies at > level 1 just plain suck then. People then simply don't care about how the > current flows at cpu level or about your carefully handcrafted bits and > pieces on level 0 which you are so proud of and which are so consistent > there. There is some merit in this. For instance, Python 2 had a lower-level consistency in the division operator than Python 3 has. According to Py2, integers and floats are fundamentally different beasts, and when you divide an int by an int, you get an int, not a float. Py3 says "well, you probably REALLY meant to divide a number by a number", so it gives you a float back, unless you explicitly ask for floor division. Py2 is more consistent on a lower level of abstraction. Py3 is more consistent on a higher level of abstraction (modulo the oddities at extremely large numbers). Both have merit, but in a high level language, the Py3 way is usually [1] better. But the consistency of call-by-object-reference is at the same high level as the consistency of call-by-value or call-by-name. I can explain Python's assignment model to someone fairly easily, using pencil and paper, without any reference to "low level" or "high level" concepts. And Python is extremely internally consistent; *every* assignment behaves the exact same way. How does "import x" compare with "from x import y"? Easy: the former is "x = some_module_object", and the latter is "y = some_module_object.y", and either way, it's regular assignment. How does parameter passing work? You take the value of the argument as evaluated in the caller, and assign it to the parameter in the function. What about default arguments? They're evaluated when the function's defined, and assigned to the parameter when it's called. Function definition itself is the same thing - it's assigning a function object to a name. Python handles every one of them the same way. I don't care one iota about how voltages inside a CPU operate. I don't generally even care about machine code - let other people worry about that, people more expert than I am. Discussions about how the core dev and the novice see Python's consistencies are nothing to do with those levels. To go back to your original point, that a newbie is better at recognizing inconsistencies... maybe, in a sense, but they also get a lot of false positives. Ultimately, "consistent" means that there's a single pattern that explains everything; if you're unaware of that pattern, you won't know that it's consistent. ChrisA [1] Even in Python, there are places where low-level consistency is better, because Python is a glue language. But in general, it's better for Python to be consistent with humans than with C APIs. -- https://mail.python.org/mailman/listinfo/python-list
Re: python3 regex?
Hey, all; thanks for the replies - reading data in one slurp vs line by line was the issue. In my perl programs, when reading files, I generally do it all in one swell foop and will probably end up doing so again in this case due to the layout of the text; but, that's my issue. Thanks again. I appreciate the tip. Doug O'Leary -- https://mail.python.org/mailman/listinfo/python-list
Python source repo
I ran hg fetch to update the CPython repo. It has been stuck on "adding changesets" for half an hour. I don't know if that's because the process has locked up, or because there really are that many new changesets and it will simply take a long time to process them. (With the 3.6 beta just around the corner, there have been a LOT of changesets.) Is there some way to tell if hg is still processing or if it is locked up? I don't want to kill the process and have to go through the whole thing again if I don't have to. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python source repo
On Sun, 11 Sep 2016 01:04 am, Steve D'Aprano wrote: > I ran hg fetch to update the CPython repo. > > It has been stuck on "adding changesets" for half an hour. I don't know if > that's because the process has locked up, or because there really are that > many new changesets and it will simply take a long time to process them. Never mind. I got bored and frustrated and Ctrl-C'ed the process and ran it again. This time it took about 15 seconds to complete. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
collect2: ld returned 1 exit status when building from source
I'm trying to build from source using: ./configure --with-pydebug && make -s -j2 At first the output is okay, then I get a whole heap of similar errors: Python/dtrace_stubs.o: In function `PyDTrace_LINE': /home/steve/python/python-dev/cpython/Include/pydtrace.h:25: multiple definition of `PyDTrace_LINE' Python/ceval.o:/home/steve/python/python-dev/cpython/Include/pydtrace.h:25: first defined here Python/dtrace_stubs.o: In function `PyDTrace_FUNCTION_ENTRY': /home/steve/python/python-dev/cpython/Include/pydtrace.h:26: multiple definition of `PyDTrace_FUNCTION_ENTRY' Python/ceval.o:/home/steve/python/python-dev/cpython/Include/pydtrace.h:26: first defined here [ ... many, many, many more PyDTrace_* multiple definitions ... ] collect2: ld returned 1 exit status make: *** [Programs/_freeze_importlib] Error 1 Any suggestions for fixing this? -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] Inconsistencies (was: Shuffled)
On Saturday, September 10, 2016 at 6:30:47 PM UTC+5:30, Chris Angelico wrote:
> Redirecting to python-list as I don't believe this belongs on -ideas.
>
> On Sat, Sep 10, 2016 at 10:09 PM, Sven R. Kunze wrote:
> >> On 08.09.2016 04:00, Steven D'Aprano wrote:
> >>
> >> On Wed, Sep 07, 2016 at 11:43:59PM +0200, Sven R. Kunze wrote:
> >>
> >>> BUT experienced devs also need to recognize and respect the fact that
> >>> younger/unexperienced developers are just better in detecting
> >>> inconsistencies and bloody work-arounds.
> >>
> >> That is not a fact. It is the opposite of a fact
> >>
> >
> > You might have heard of: "There are no such things as facts, just opinions.
> > Everything, we see is a perspective not the truth." See below, why this
> > applies here as well.
>
> Yes, I've heard that. It is false.
>
> Some things are absolute hard facts. There is no way in which 1 will
> ever be greater than 2, ergo "1 is less than 2" is strictly true, and
> not a matter of opinion. If you hear someone trying to claim
> otherwise, would you let him have his opinion, or would you treat it
> as incorrect?
You are confusing analytic and synthetic truths, an old philosophic distinction
with a new special place in CS
http://blog.languager.org/2015/07/cs-history-2.html
Analytic truths have a tautologous feel that makes them sound strangely
irrelevant (as an observation) eg.
“What is is”
“Something is the case or is not the case”
More informally:
“Time is irreversible”
“We all die”
etc
All true but nothing is communicated by saying it
Mathematical truths like 1 < 2
are in the same category as “triangles are 3-sided figures”
same as “triangles are triangular”
True... and tautologus
When people commonly talk of ‘facts’ they are typically synthetic
Acceleration due to gravity is 9.8 m/s²
Planets move in elliptic orbits round the sun
All these *scientific* truths as Karl Popper pointed out are scientific exactly
BECAUSE they are falsifiable.
Unlike say: “God created the world”
And to say that they are falsifiable is exactly what Sven is saying:
They are the dominant opinion of the scientific establishment
And will change when the fashions change
As for shuffle vs shuffled I am very much in the shuffled camp.
It irks me that
- sort and sorted are named backwards — should have been dosort and sort
- tuples are less 1st class than lists (why no tuple comprehensions?)
- what you get from writing a comprehension inside a {} is a set not a frozenset
- set and frozenset are named backwards; should have been mutableset and set
- there are no frozendicts (though dict comprehensions are niftier in python
than in most functional languages
- etc etc
Which I guess you can summarize as (me saying that) functional programming is
natural and imperative programming is a stone-age relic.
[And BTW in the other thread in which the closeness or not of asyncio, threads,
processes is being debated it is so clear to those who have seen radically
different paradigms like Erlang that the problem is not the specifics of
async/threads/processes but the general situation that python is stuck in
imperative-land
]
--
https://mail.python.org/mailman/listinfo/python-list
Re: collect2: ld returned 1 exit status when building from source
On Sep 10, 2016 09:56, "Steve D'Aprano" wrote: > > I'm trying to build from source using: > > ./configure --with-pydebug && make -s -j2 > > > At first the output is okay, then I get a whole heap of similar errors: > > Python/dtrace_stubs.o: In function `PyDTrace_LINE': > /home/steve/python/python-dev/cpython/Include/pydtrace.h:25: multiple > definition of `PyDTrace_LINE' > Python/ceval.o:/home/steve/python/python-dev/cpython/Include/pydtrace.h:25: > first defined here > Python/dtrace_stubs.o: In function `PyDTrace_FUNCTION_ENTRY': > /home/steve/python/python-dev/cpython/Include/pydtrace.h:26: multiple > definition of `PyDTrace_FUNCTION_ENTRY' > Python/ceval.o:/home/steve/python/python-dev/cpython/Include/pydtrace.h:26: > first defined here > > [ ... many, many, many more PyDTrace_* multiple definitions ... ] > > collect2: ld returned 1 exit status > make: *** [Programs/_freeze_importlib] Error 1 > > > Any suggestions for fixing this? Try make distclean, then configure and build again. If that fails, try another make distclean, then configure, do 'make touch', then build again. -- Zach (On a phone) -- https://mail.python.org/mailman/listinfo/python-list
Re: collect2: ld returned 1 exit status when building from source
On Sun, 11 Sep 2016 03:34 am, Zachary Ware wrote: > On Sep 10, 2016 09:56, "Steve D'Aprano" > wrote: >> >> I'm trying to build from source using: >> >> ./configure --with-pydebug && make -s -j2 [...] >> Any suggestions for fixing this? > > Try make distclean, then configure and build again. Same error. > If that fails, try > another make distclean, then configure, do 'make touch', then build again. make touch fails. [steve@ando cpython]$ make touch cd .; \ hg --config extensions.touch=Tools/hg/hgtouch.py touch -v *** failed to import extension touch from Tools/hg/hgtouch.py: invalid syntax (hgtouch.py, line 22) hg: unknown command 'touch' Mercurial Distributed SCM basic commands: add add the specified files on the next commit [...] viewstart interactive history viewer use "hg help" for the full list of commands or "hg -v" for details make: *** [touch] Error 255 And *that* error is because the hgtouch.py uses `with`, which fails because my hg runs under Python 2.4. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: collect2: ld returned 1 exit status when building from source
On Sun, 11 Sep 2016 03:34 am, Zachary Ware wrote: > Try make distclean, then configure and build again. If that fails, try > another make distclean, then configure, do 'make touch', then build again. I worked around the failed hg touch by running it manually: python2.7 /usr/bin/hg --config extensions.touch=Tools/hg/hgtouch.py touch -v which printed a few warnings and then (apparently) succeeded: /usr/lib/python2.4/site-packages/mercurial/demandimport.py:58: RuntimeWarning: Python C API version mismatch for module osutil: This Python has API version 1013, module osutil has version 1012. mod = _origimport(head, globals, locals) /usr/lib/python2.4/site-packages/mercurial/demandimport.py:58: RuntimeWarning: Python C API version mismatch for module parsers: This Python has API version 1013, module parsers has version 1012. mod = _origimport(head, globals, locals) Touching Python/Python-ast.c but the build still fails, with the same errors: Python/dtrace_stubs.o: In function `PyDTrace_LINE': /home/steve/python/python-dev/cpython/Include/pydtrace.h:25: multiple definition of `PyDTrace_LINE' Python/ceval.o:/home/steve/python/python-dev/cpython/Include/pydtrace.h:25: first defined here [ ... many, many, many more similar errors ... ] collect2: ld returned 1 exit status make: *** [Programs/_freeze_importlib] Error 1 -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
generator function - Called and accepts XML attributes- Python 3.5
Hi I want to create a generator function that supplies my calling function a file, how though do I get the generator to accept attributes in the argument when called? This works not as a generator for filename in sorted(file_list): with open(dir_path + filename) as fd: doc = xmltodict.parse(fd.read()) for item in doc['meeting']['race']: for detail in item['nomination']: print(item['@id'] + "\t" + detail['@id'] + "\t" + detail['@number'] + "\t" + detail['@horse']) And what I want to do is simplify for detail in item['nomination']: print(item['@id'] + "\t" + detail['@id'] + "\t" + detail['@number'] + "\t" + detail['@horse']) As I will have several implementations to do and would like to be able to neatly handoff to sqlalchemy. I have it as something like this but am not quite creating it correctly. def return_files(file_list): """ Take a list of files and return file when called Calling function to supply attributes """ for filename in sorted(file_list, *attribs): with open(dir_path + filename) as fd: doc = xmltodict.parse(fd.read()) for item in doc([attribs]): yield item Thanks Sayth -- https://mail.python.org/mailman/listinfo/python-list
Re: generator function - Called and accepts XML attributes- Python 3.5
On Sun, Sep 11, 2016 at 10:46 AM, Sayth Renshaw wrote: > Hi > > I want to create a generator function that supplies my calling function a > file, how though do I get the generator to accept attributes in the argument > when called? > > This works not as a generator The way I'm reading your code, it's not the generator that's the difference here. Consider these lines: > for item in doc['meeting']['race']: > > def return_files(file_list): > for filename in sorted(file_list, *attribs): > for item in doc([attribs]): Firstly, did you mean for *attribs to be part of the signature of return_files? As it is, it's being given to sorted(), which won't work (the other args to sorted are keyword-only). Assuming that to be the case, what you're trying to do is subscript an object with a variable set of attributes: return_files(files, "meeting", "race') That can best be done with a little loop: def return_files(file_list, *attribs): ... for attr in attribs: doc = doc[attr] for item in doc: If that's not what you want, can you further clarify the question? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: generator function - Called and accepts XML attributes- Python 3.5
> The way I'm reading your code, it's not the generator that's the > difference here. Consider these lines: > > > for item in doc['meeting']['race']: > > > > def return_files(file_list): > > for filename in sorted(file_list, *attribs): > > for item in doc([attribs]): > > Firstly, did you mean for *attribs to be part of the signature of > return_files? As it is, it's being given to sorted(), which won't work > (the other args to sorted are keyword-only). > > Assuming that to be the case, what you're trying to do is subscript an > object with a variable set of attributes: > > return_files(files, "meeting", "race') > > That can best be done with a little loop: > > def return_files(file_list, *attribs): > ... > for attr in attribs: > doc = doc[attr] > for item in doc: > > If that's not what you want, can you further clarify the question? > > ChrisA Thanks ChrisA, what I am wanting to do is to create a generator for my file input to only pull the file when the last has processed. Then have my separate functions to process the files as required as each will have different attribute combinations and processing. My thinking is that having been reading SQLAlchemy I will be creating the models to represent the tables and the relationships. Therefore if I had 3 tables for name and people attributes, another for location(meeting) details and a central table for event details, then if the generator pulls a file I can parse it with each function. Each function would update the model and then call back to the generator for another file. My concern is that as some process in each table will be longish it is better to keep that separate and just call them from a main function. Maybe the generator should just stop at parsing the file at the root XML level so that each calling function can then hook up from its node. Is that clear or a massive brain dump? Sayth -- https://mail.python.org/mailman/listinfo/python-list
Re: generator function - Called and accepts XML attributes- Python 3.5
This seems to work as a starter. def return_files(file_list): """ Take a list of files and return file when called Calling function to supply attributes """ for filename in sorted(file_list): with open(dir_path + filename) as fd: doc = xmltodict.parse(fd.read()) for item in doc['meeting']['race']: yield item my_generator = return_files(file_list) def gets_id(): for value in my_generator: for asset in value['nomination']: print(asset['@id']) gets_id() Cheers Sayth -- https://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] Inconsistencies (was: Shuffled)
On Saturday, September 10, 2016 at 6:30:47 PM UTC+5:30, Chris Angelico wrote: > Redirecting to python-list as I don't believe this belongs on -ideas. > > On Sat, Sep 10, 2016 at 10:09 PM, Sven R. Kunze wrote: > > You might have heard of: "There are no such things as facts, just opinions. > > Everything, we see is a perspective not the truth." See below, why this > > applies here as well. > > Yes, I've heard that. It is false. > > Some things are absolute hard facts. There is no way in which 1 will > ever be greater than 2, ergo "1 is less than 2" is strictly true, and > not a matter of opinion. If you hear someone trying to claim > otherwise, would you let him have his opinion, or would you treat it > as incorrect? Just saw this [No its not exactly consistent with my earlier view!] “How much is 2 and 2?” Everyone gave the answer except the accountant. When everyone left, he dimmed the light and whispered in my ear “How much do you want?” -- https://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] Inconsistencies (was: Shuffled)
On Sun, Sep 11, 2016 at 2:27 PM, Rustom Mody wrote: > On Saturday, September 10, 2016 at 6:30:47 PM UTC+5:30, Chris Angelico wrote: >> Redirecting to python-list as I don't believe this belongs on -ideas. >> >> On Sat, Sep 10, 2016 at 10:09 PM, Sven R. Kunze wrote: >> > You might have heard of: "There are no such things as facts, just opinions. >> > Everything, we see is a perspective not the truth." See below, why this >> > applies here as well. >> >> Yes, I've heard that. It is false. >> >> Some things are absolute hard facts. There is no way in which 1 will >> ever be greater than 2, ergo "1 is less than 2" is strictly true, and >> not a matter of opinion. If you hear someone trying to claim >> otherwise, would you let him have his opinion, or would you treat it >> as incorrect? > > Just saw this [No its not exactly consistent with my earlier view!] > > “How much is 2 and 2?” > Everyone gave the answer except the accountant. > When everyone left, he dimmed the light and whispered in my ear “How much do > you want?” And we laugh, because the accountant is offering to flat-out lie. We know full well that he's not telling the truth. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] Inconsistencies (was: Shuffled)
On Sunday, September 11, 2016 at 1:00:47 AM UTC+12, Chris Angelico wrote: > > On Sat, Sep 10, 2016 at 10:09 PM, Sven R. Kunze wrote: >> You might have heard of: "There are no such things as facts, just opinions. > > Yes, I've heard that. It is false. It’s very easy to see why: start by asking whether the statement is a fact or an opinion. The conclusion follows logically from that. -- https://mail.python.org/mailman/listinfo/python-list
