Re: question about xrange performance
> One might wonder why you are even writing code to test for existence > "in" a range list, when "blee <= blah < bloo" is obviously going to > outperform this kind of code. > -- Paul the reason is simply the idiomacy and convenience. i use (x)xranges to implement unicode blocks and similar things. it is natural to write `if cid in latin_1` and so on. i always assumed it would be about the fastest and memory-efficient to use xrange for this. i stumbled against a first wall, tho, when i realized that `xrange` does not accept long integers. so i wrote the class above to get an xrange-like object that would accept them. stepping was not of concern---i recall few times that i was in need of a third argument to xrange at all. i then added iteration when i needed it; shows that iteration over xxranges is outperformed by xrange by a factor of over twenty: class xxrange( object ): def __iter__( self ): i = self.start while i < self.stop: yield i i += 1 containment xxrange0.027 CPU seconds xrange90.365 CPU seconds set0.002 CPU seconds iteration xxrange0.262 CPU seconds xrange 0.019 CPU seconds set0.031 CPU seconds # iterated sorted list; tested as `for x in sorted(my_set)` however, these numbers also show still an incredible and unexpected ratio in favor of xxrange for containment; they also show that a set is (with 200'000 integer numbers) 10 times as fast for containment and are only 1.6 times slower than xxranges for iteration. this means that an optimized implemtation of x/range should choose between different implementations depending on size of collection, memory available, and purpose if they want to achieve better efficiency. the least of changes could be class xrange( object ): def __old_contains__: ... def __contains__( self ): if self step != 1: return self.__old_contains__() return ( x == int( x ) ) and self.start <= x < self.stop the `( x == int( x ) )` is not easily being done away with if emulation of present x/range behavior is desired (x.0 floats are in, all others are out). frankly speaking, i would like to say that finding out whether xrange is a good solution for containment tests will cause some time of reading or, of course, dedicated profiling; making Python make that choice might be a better idea. my guess would be that most xranges are in fact used with step 1, so even sorting out that single bottleneck would have noticable effect. now that xrange has taken over range in py3k people will get some bumps on the transition way anyhow. i for one submit to my fancy xxranges for the time. cheers and thanks for the explanations! -- http://mail.python.org/mailman/listinfo/python-list
Re: question about xrange performance
> [soapbox] > Speaking about idiomacy, ... > [end soapbox] soapbox] I ALREADY STEPPED DOWN FROM SOAPBOX (on this topic) [end soapbox] thanks for the comment anyhow. that an efficient `x in y` implementation used to be there and is gone now is gross. guess i'll just have to live with my own makeshift implementation. gross. cheers -- http://mail.python.org/mailman/listinfo/python-list
"Advanced" Python programming book?
I've just finished reading a sort of beginner Python book, and I know quite a bit now but I'm looking for a book that can teach me advanced aspects of Python - code optimisation, threading, etc. Any recommendations? Cheers. -- http://mail.python.org/mailman/listinfo/python-list
Re: "Advanced" Python programming book?
Cheers guys - I'll check the books out :) Thanks very much. -- http://mail.python.org/mailman/listinfo/python-list
(A Possible Solution) Re: preferred way to set encoding for print
On Sep 16, 7:16 am, "Mark Tolonen" wrote:
> Setting PYTHONIOENCODING overrides the encoding used for stdin/stdout/stderr
> (See the Python help for details), but if your terminal doesn't support the
> encoding that won't help.
thx for these two tips. of course, that was a bit misleading by me to
complain that a cp850 terminal can't display chinese characters from
pythonit cannot do it all, of course.
i've gone on to experiment. what i do not want is python to stop
execution when an encoding error occurs on printing and perhaps
logging. so far, i used to do this by convincing python to use utf-8
in any and all cases, and then live with the amount garbish that
appears on screen when using cp850 and cp1252 terminals.
what has changed in python is that they now somehow find out about the
terminal's encoding, and then put that encoding into place and defend
it with teeth and claws. it is simply not easy to take control of that
setting.
this is in itself unfortunate; i believe that users should have a
right to determine what to do in case of stdout encoding problems.
these are a little different from i-wrote-to-that-file-and-boom
experiences. *there* the encoding exception is fully warranted, and
could be easily fixed by allowing a less-than-strict encoding mode.
but print is different, and of all situations where encoding errors
can occur, this is the hardest to take hold of. and much more so in
python3 it seems than in python2.
printing to the screen is often purely meta-informative in nature, a
side-effect e.g. of a webserver really doing web pages. i don't want
to bring my entire system down just because some output into some
terminal in the back orifice produced a some amount of grabish. maybe
only a single chinese character amongst thousands of done this done
that red tape.
i think web browsers are a good example here. i don't know whether it
was a good idea to let clients reassemble broken web pages in an order
as they see fit, but the policy to just output broken encoding
character instances instead of terminating the browser process with a
lengthy stacktrace was probably somehow good for the poopularity of
the web as we know it.
my current patch looks like this:
class Stdout_writer_with ncrs( object ):
def write( self, p ):
"""See to it that all write encodings are done using numerical
character references (NCRs) that
circumvents Python’s default behavior of raising an exception
whenever it encounters an
unrepresentable character while printing."""
enc = sys.__stdout__.encoding
p = p if isinstance( p, str ) else str( p )
p = p.encode( enc, 'xmlcharrefreplace' ).decode( enc )
sys.__stdout__.write( p )
sys.stdout = Stdout_writer_with ncrs()
this method picks up anything to be printed, makes sure it is a text,
and then encodes it to the terminal encoding using numerical character
references (NCRs), then decodes it again since the underlying wrapper
class wants to do encodings itself and refuses bytes in place of
strings to be sent (again, this is not nice: an array of byte values
sent to the print method is a clear request to send exactly those
bytes, verbatim, one by one, to the terminal. no mucking around with
my bytes, pls! maybe i can implement that in the code above, too.)
of course, this simplistic scaffold will break if anyone uses
sys.stdout for anything but issue sys.stdout.write(), but so far it
has worked fine despite of being a defective, tiny shim. maybe
inheriting from sys.stdout.__class__ would help.
> "_wolf" wrote in message
>
> news:22991c72-d00f-45cd-9bf7-0b80fc431...@k26g2000vbp.googlegroups.com...
>
>
>
> > hi folks,
>
> > i am doing my first steps in the wonderful world of python 3.
>
> > some things are good.
> > some things have to be relearned.
> > some things drive me crazy.
>
> > sadly, i'm working on a windows box. which, in germany, entails that
> > python thinks it to be a good idea to take cp1252 as the default
> > encoding.
>
> > so just coz i got my box in germany means i can never print out a
> > chinese character? say what?
>
> > i have no troubles with people configuring their python installation
> > to use any encoding in the world, but wouldn't it have been less of a
> > surprise to just assume utf-8 for any file in/output? after all, it is
> > already the default for python source files as far as i understand.
> > someone might think they're clever to sniff into the system and make
> > the somehwat educated guess that this dude's using cp1252 for his
> > files. but they would be wrong.
>
> > so: how can i tell python, in a configuration or using a setting in
> > sitecustomize.py, or similar, to use utf-8 as a default encoding?
> > there used to be a trick to say `reload(sys);sys.setdefaultencoding
> > ('utf-8')`, but that has no effect in py3.0.1. also, i cannot set
> > `sys.stdout.encoding`; is there a way to re-open that stream with a
> > different encoding?
>
> > in all, i belie
excel (multiple sheets) to yml file for each sheet
Hi, I have excel file with multiple sheets and need output as yml file for each sheet. could someone help me with python code? following is an example: aep sheet: aepaep_description infra_vlan test_AEP test aepno aeps_to_domain sheet: aep domaindomain_type test_AEPtest_PHY_DOMphys test1_AEP test1_PHY_DOM l3dom scription should output two files: aeps-vars.yml: aeps: - aep: test_AEP aep_description: test aep infra_vlan: no aeps_to_domain-vars.yml: aeps_to_domain: - aep: test_AEP domain: test_PHY_DOM domain_type: phys - aep: test_AEP domain: test_L3O_DOM domain_type: l3dom -- https://mail.python.org/mailman/listinfo/python-list
Re: excel (multiple sheets) to yml file for each sheet
help please. On Thursday, July 16, 2020 at 10:38:23 PM UTC-4, stack flow wrote: > Hi, > > I have excel file with multiple sheets and need output as yml file for each > sheet. could someone help me with python code? following is an example: > > aep sheet: > > aepaep_description infra_vlan > test_AEP test aepno > > aeps_to_domain sheet: > > aep domaindomain_type > test_AEP test_PHY_DOMphys > test1_AEP test1_PHY_DOM l3dom > > > scription should output two files: > > aeps-vars.yml: > > aeps: > - aep: test_AEP > aep_description: test aep > infra_vlan: no > > > aeps_to_domain-vars.yml: > > aeps_to_domain: > - aep: test_AEP > domain: test_PHY_DOM > domain_type: phys > - aep: test_AEP > domain: test_L3O_DOM > domain_type: l3dom -- https://mail.python.org/mailman/listinfo/python-list
Re: [perl-python] 20050127 traverse a dir
Xah Lee, Do you want to be taken seriously? First, stop posting. Second, learn perl. Third, learn python. -- http://mail.python.org/mailman/listinfo/python-list
Re: [perl-python] 20050127 traverse a dir
Sorry about that... (I forgot what he was trying to teach) Thanks for the clarification -- The Flow -- http://mail.python.org/mailman/listinfo/python-list
