JNLP File download and run
Hi, Can someone give me pseudo code to download and JNLP file from a URL and run it? Looks like a advance concept in python Regards -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On 20/05/16 00:51, Gregory Ewing wrote: It's not so bad with "else" because you need to look back to find out what condition the "else" refers to anyway. With my tongue only slightly in my cheek, if it was desirable to "fix"/clarify this syntax then I would suggest adding some optional (existing) trailing keywords to 'else' in this context that spells it out: for item in seq: if foo(item): break else if not break: nomatch() I would rule out "elif not break" - this is just about adding additional trailing words to existing syntax to spell it out (which might be a good teaching aid as well as turn into personal preferred style). I guess that it _could_ be a syntax error to reference "break" if the for/while loop does not contain the keyword in its body - this could actually address one of the "confusing" things mentioned in this thread, like: seq = [] for item in seq: pass else if not break: pass # Syntax error - "break" referenced in "for/else" clause but not present in loop body. Someone also pointed out that there are other flow control mechanisms that could prevent the 'else' from being executed: "return" and "raise". One could extend the above to allow one or more of those to be specified: else if not break or return or raise: That looks like a lot of noise, but again it could help make code more explicit (both to the human reader, and to a compile-time check): for item in seq: if foo(item): break if bar(item): return else if not return: pass # Syntax error - extended "for/else" clause does not reference "break", which exists in loop body. I would _not_ suggest that the above should ever mean "if it doesn't return, this code is executed regardless of whether 'break' happened" - one would remove the 'else' clause altogether for that. "raise" is more problematic as an exception can always be raised by pretty much _anything_ in the body without the keyword being present. Perhaps "or raise" is just a completely benign, optional keyword for the completists. Or perhaps it's simply not mentioned at all and is always implied (as is true of exceptions in other constructs such as plain "if/else", and just generally). The additional keywords would effectively just be a static checked filter - the original bare "else" would effectively mean "else if not any_flow_control_out_of_the_loop" (which is what it means today). In summary: Adding the "if not" extension is the suggestion, with "break" as the filter. "return" as an additional filter is a possibility which may add something, "raise" as an additional filter is a possibility which probably doesn't add anything (and may actually be distracting). I'm not entirely sure if _I_ like this yet (there are some things I've suggested that I like and some I'm not sure about and some I don't like but I've mentioned them anyway) - I'm just throwing it out there ;) E. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python script reading from sys.stdin and debugger
On Thursday, May 19, 2016 at 5:10:08 PM UTC-4, Fillmore wrote: > Hello PyMasters! > > Long story short: > > cat myfile.txt | python -m pdb myscript.py > > doens't work (pdb hijacking stdin?). > > Google indicates that someone has fixed this with named pipes, but, call > me stupid, I don't understand how I need to set up those pipes, how I > need to modify my script and, above all, how I now need to invoke the > program. > > Help and suggestions appreciated. I am using Python 3.4 on Cygwin and > Ubuntu. > > Thanks The debugger trepan3k follows the gdb command set so it gdb's "source" command. See http://python2-trepan.readthedocs.io/en/latest/commands/support/source.html or type "help source" inside the debugger. To install trepan3k "easy_install trepan3k" (I'm not totally sure pip install works yet). See https://pypi.python.org/pypi/trepan3k/ for mor details. -- https://mail.python.org/mailman/listinfo/python-list
Call to Python backtrace listing packages - show the exact location
A little while ago I wrote uncompyle6 which can deparse Python C bytecode. Currently it runs on 2.6-2.7 and 3.2 and up. I think an underused part of that is that you can at runtime give it a bytecode offset and it will show you where inside a line you are at. It also can show the surrounding expression/statement of the parent context. I think it would be neat if those packages which show backtraces offered the ability to also show the expression at the point of error as well. My trepan debuggers in fact use this in their "deparse" statement. http://python2-trepan.readthedocs.io/en/latest/commands/data/deparse.html Pypy package https://pypi.python.org/pypi?name=uncompyle6 -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On 2016-05-20, Steven D'Aprano wrote:
> On Fri, 20 May 2016 03:55 am, Jon Ribbens wrote:
>> I guess we should thank our lucky stars that you don't have a time
>> machine then, since that change would very much be one for the worse
>> in my opinion. for...else is perfectly straightforward and clearly
>> the right keywords to use. for...then would be entirely wrong.
>
> "Entirely" wrong? "Clearly" the right keyword? "Perfectly" straightforward?
>
> They are extremely strong words given the posts where *even the defenders*
> of "else" have admitted that it is a hard keyword to understand. But that's
> okay. Maybe you've thought of something the rest of us haven't, and have an
> entire consistent mental model of for...else that is easy to understand and
> makes it "perfectly straightforward and clearly the right keyword".
>
> Can you explain your model which makes "else" appropriate?
Certainly. "else:" is (almost?) invariably used in the situation where
you are iterating through something in order to find a value which
matches a certain condition. So the "for:" block means "find this
value" and the "else:" means "else do this".
> In my experience, some people (including me) misunderstand "for...else" to
> mean that the else block runs if the for block *doesn't*. It took me the
> longest time to understand why this didn't work as I expected:
>
> for x in seq:
> pass
> else:
> print("seq is empty")
>
> because like many people, my mental model was "the for block runs, OR ELSE
> the else block runs". This *incorrect* model seems like it works: if you
> set seq=[], say, it prints "seq is empty" as expected.
>
> But its wrong: set seq=[1, 2, 3], and it *still* prints "seq is empty". My
> model of what was going on was faulty.
The problem there is that the mental model is *completely* wrong.
"else:" has nothing at all to do with the number of values in the
iterated sequence.
> I never would have thought of that model if it had been called "then":
>
> for x in seq:
> pass
> then:
> print("executes after the for block completes")
I would find that very confusing. "then:" makes it sound like
executing that block is the usual case, when in practice it is
usually the exception - the fallback code if the expected value
was not found.
--
https://mail.python.org/mailman/listinfo/python-list
EuroPython 2016 Keynote: Jameson Rollins
We are pleased to introduce our second keynote speaker for EuroPython 2016: *** Jameson Rollins *** About Jameson Rollins - Jameson is a staff scientist in the LIGO project, based at the California Institute of Technology: "I have worked on many aspects of gravitational wave detection over the years, from laser light sources, to algorithms for low-latency data analysis. I’m currently interested in problems of detector control, and am the developer of the LIGO automation system. I have a B.S. in physics from the University of Michigan, and a Ph.D. in physics from Columbia University in the City of New York." The Keynote: LIGO - The Dawn of Gravitational Wave Astronomy Scientists have been searching for the elusive gravitational wave for more than half a century. On September 14, 2015, the Laser Interferometer Gravitational-wave Observatory (LIGO) finally observed the gravitational wave signature from the merger of two black holes. * https://www.ligo.caltech.edu/detection This detection marks the dawn of a new age of gravitational wave astronomy, where we routinely hear the sounds emanating from deep within the most energetic events in the Universe. * https://en.wikipedia.org/wiki/Gravitational-wave_astronomy This talk will cover the events leading up to one of the most important discoveries of the last century, and the myriad of ways in which Python enabled the effort. With gravitational regards, -- EuroPython 2016 Team http://ep2016.europython.eu/ http://www.europython-society.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Wanted Python programmer to join team
On Tuesday, May 17, 2016 at 12:20:53 AM UTC-5, Steven D'Aprano wrote: > On Tuesday 17 May 2016 12:56, Chris Angelico wrote: > > > On Tue, May 17, 2016 at 12:37 PM, Steven D'Aprano <> > > wrote: > >> On Tue, 17 May 2016 09:07 am, Chris Angelico wrote: > >> > >>> I'm not overly bothered by the use of GMail for a business address, > >> > >> It's 2016. Using a gmail address for your business (unless you're a really > >> small business, like a sole trader or something) is equivalent to a postal > >> address of "Leave mail with the lady in the milk bar on the corner". > >> > >> It's not hard to run your own mail server. *I* can do it. At the very > >> least, > >> register a domain and tell Gmail to use that, and *pretend* you're running > >> your own mail server. > > > > And a lot of job postings do come from that sort of really small > > business, trying to expand a bit. Plus, some of them want some > > anonymity (why, I don't know, but there are plenty of jobs posted > > without too much in the way of company details) > > That probably means the job advert is coming from a recruiter. They don't > want > people to contact the company directly, and they want to hide the fact that > they are a recruiter. > > Personally, I think that advertising a job position without saying who you > are, > what you do, and offering at least an indicative salary range, are > *astonishingly* rude (to say nothing of counter-productive). If I see a job > for > (let's say) Blackwater[1], paying $900,000 a year, then I know that (1) I > don't > want to work for them, and (2) even if I did, I wouldn't be qualified; so I > don't waste either my time or theirs applying. But when I see a job for some > unnamed company with an unknown salary doing something often couched in the > vaguest possible terms, I end up wasting everyone's time. +1 I have had recruiters from within Company A bug me about their company, but when I asked about a salary range, they said that they wouldn't discuss that until a later stage but that I would be happy with it. How would they know? They don't know what I make or what would make me happy! I ignored them after that even though I was interested in working for Company A. They do a lot of weird things. Frankly the ones that look like they spam everyone provide more information than the more professional recruiters. - Mike -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On Thu, May 19, 2016 at 1:04 PM Ian Kelly wrote: > On Thu, May 19, 2016 at 10:31 AM, Herkermer Sherwood > wrote: > > Most keywords in Python make linguistic sense, but using "else" in for > and > > while structures is kludgy and misleading. I am under the assumption that > > this was just utilizing an already existing keyword. Adding another like > > "andthen" would not be good. > > "else" makes sense from a certain point of view, but I think that > logic may not be communicated well. At the start of each loop > iteration, the loop construct makes a test for whether the loop should > continue or not. If that test ever fails (i.e. if the condition of the > while loop is false), the else block is executed instead. So you can > think of it as a repeated if-else where the else block has the > additional effect of exiting the loop. > > > But there is already a reserved keyword that would work great here. > > "finally". It is already a known keyword used in try blocks, but would > work > > perfectly here. Best of all, it would actually make sense. > > > > Unfortunately, it wouldn't follow the semantics of > try/except/else/finally. > > "finally" in exception handling denotes a block that is *always* > executed. Using it for a block that is only sometimes executed would > dilute that meaning. > It's unfortunate that so many people responded so quickly, since Ian's explanation was so clear (I thought). For further clarity, I'll write out the implicit if-statement that Ian described, though in my case it'd be at the end of the block, somewhat like a do-while: IF keep_looping() THEN GOTO LOOP_START ELSE GOTO LOOP_COMPLETED Also, Nick Coghlan has a good post about this ( http://python-notes.curiousefficiency.org/en/latest/python_concepts/break_else.html ) -- https://mail.python.org/mailman/listinfo/python-list
Re: JNLP File download and run
On 05/20/2016 01:30 AM, Robert Clove wrote: > Hi, > > Can someone give me pseudo code to download and JNLP file from a URL and > run it? > > Looks like a advance concept in python You could use the urllib module to download the file, then use the subprocess module to spawn the javaws executable and pass it the location of the jnlp file as a parameter. https://docs.python.org/3.6/howto/urllib2.html https://docs.python.org/3.6/library/subprocess.html There are other ways besides launching javaws directly, such as asking cmd.exe to invoke "start" and the jnlp file so that the default javaws executable will run. On Mac there's the "open" binary that can do the same thing, and on Linux, xdg-open. -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On Fri, May 20, 2016 at 3:09 AM, Erik wrote: > On 20/05/16 00:51, Gregory Ewing wrote: >> >> It's not so bad with "else" because you need to look back >> to find out what condition the "else" refers to anyway. > > > With my tongue only slightly in my cheek, if it was desirable to > "fix"/clarify this syntax then I would suggest adding some optional > (existing) trailing keywords to 'else' in this context that spells it out: > > for item in seq: > if foo(item): > break > else if not break: > nomatch() With tongue firmly cheeked, you can always use the special `:#` operator: for item in seq: if foo(item): break else:# if no break: nomatch() This has the benefit that you can use whatever syntax you like after the `:#`, and use it in any version of Python you want. -- Zach -- https://mail.python.org/mailman/listinfo/python-list
How do I subclass the @property setter method?
Greetings, My chess engine has a Piece class with the following methods that use the @property decorator to read and write the position value. @property def position(self): return self._position @position.setter def position(self, position): if self._first_move: self._first_move = False self._position = position Blank is a subclass of the Piece class that represents an empty space on the board and is a placeholder in the Board class _state dict. Since Blank is a placeholder and not a playable game piece, I want to make @position.setter non-operational (i.e, make no changes to the position value). @Piece.position.setter def position(self, position): pass This code works and the corresponding unit test blows up because I haven't changed it yet, but the PyCharm IDE complains that the Blank.position signature doesn't match the Piece.position signature. Never mind that I copy and paste the identical declaration from the Piece class. This code does work, blows up the unit test, and keeps PyCharm happy. @property def position(self): return super().position @position.setter def position(self, position): pass Re-declaring @property and calling super seems redundant. Not sure if I found a bug with the PyCharm hint feature or I'm not subclassing the @property setter correctly. Which is it? Thank you, Chris R. -- https://mail.python.org/mailman/listinfo/python-list
Re: How do I subclass the @property setter method?
On 5/20/2016 11:50 AM, Christopher Reimer wrote: This code does work, blows up the unit test, and keeps PyCharm happy. @property def position(self): return super().position @position.setter def position(self, position): pass Re-declaring @property and calling super seems redundant. Not sure if I found a bug with the PyCharm hint feature or I'm not subclassing the @property setter correctly. Which is it? Never mind. This is a known bug for PyCharm IDE. https://youtrack.jetbrains.com/issue/PY-12803 I sent a separate email to technical support to inquire if this bug and similar bugs will ever get fixed. This issue was initially reported three years ago. Not sure if I should post my own bug report. Thank you, Chris R. -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On 5/20/2016 8:59 AM, Zachary Ware wrote: On Fri, May 20, 2016 at 3:09 AM, Erik wrote: On 20/05/16 00:51, Gregory Ewing wrote: It's not so bad with "else" because you need to look back to find out what condition the "else" refers to anyway. With my tongue only slightly in my cheek, if it was desirable to "fix"/clarify this syntax then I would suggest adding some optional (existing) trailing keywords to 'else' in this context that spells it out: for item in seq: if foo(item): break else if not break: nomatch() With tongue firmly cheeked, you can always use the special `:#` operator: for item in seq: if foo(item): break else:# if no break: nomatch() This has the benefit that you can use whatever syntax you like after the `:#`, and use it in any version of Python you want. According to "Effective Python: 59 Specific Ways to Write Better Python" by Brett Slatkin, Item 12 recommends against using the else block after for and while loops (see page 25): "Avoid using else blocks after loops because their behavior isn't intuitive and can be confusing." Until I read the book, I wasn't aware of this feature (or bug). Doesn't seem like a feature I would use since it's not commonly found in other programming languages. As the author demonstrates in his book, I would probably write a helper function instead. Item 13 does recommend using the else block for try/except/else/finally in exception handling. :) Thank you, Chris R. -- https://mail.python.org/mailman/listinfo/python-list
errors with QGIS API USING PYTHON
i want to use python API from the QGIS in my python idle out from QGIS program , but i have some errors if i try to import qgis.core in my idle. i have python 2.7 64 bit (my version) and i install QGIS via OSGeo4W64. first i try to set two PATHS PYTHONPATH = C:\OSGeo4W64\apps\qgis\pythonPYTHONPATH(because there is the python python) and set PATH=C:\OSGeo4W64\apps\qgis\binPATH(because there is the python modules modules).now if i try to import qgis.core then show me error message no module name siperror in idle after this error i try to import paths inside the idle via sys.path.extend import sys sys.path.extend([r"C:\OSGeo4W64\apps\qgis\python", r"C:\OSGeo4W64\apps\qgis\bin", r"C:\OSGeo4W64\bin", r"C:\OSGeo4W64\apps\qgis\bin", r"C:\OSGeo4W64\apps\qgis\python", r"C:\OSGeo4W64\apps\Python27", r"C:\OSGeo4W64\apps\Python27\Scripts", r"C:\OSGeo4W64\apps\Python27\sip", r"C:\OSGeo4W64\apps\Python27\sip\Qt", r"C:\OSGeo4W64\apps\Python27\sip\QtCore", r"C:\OSGeo4W64\apps\Python27\sip\Qwt5", r"C:\OSGeo4W64\apps\Python27\sip\QtScriptTools", r"C:\OSGeo4W64\apps\Python27\DLLs", r"C:\OSGeo4W64\apps\Python27\Lib", r"C:\OSGeo4W64\apps\Python27\Lib\site-packages", r"C:\OSGeo4W64\apps\Python27\Tools\Scripts", r"C:\OSGeo4W64\apps\qgis\plugins", r"C:\OSGeo4W64\apps\qgis\python\qsci_apis", r"C:\OSGeo4W64\apps\qgis\python\qgis", r"C:\OSGeo4W64\apps\qgis\python\qgis\core", r"C:\OSGeo4W64\apps\qgis\python\qgis\analysis", r"C:\OSGeo4W64\apps\qgis\python\PyQt", r"C:\OSGeo4W64\apps\qgis\python\PyQt4", r"C:\OSGeo4W64\apps\qgis\python\PyQt4\uic\widget-plugins", r"C:\OSGeo4W64\apps\qgis\bin", r"C:\Python27", r"C:\Python27\Scripts", r"C:\OSGeo4W64\apps\qgis\python"]) i use more paths for sure but now show me DLL error load failed error 2 finaly i try other method from this bat file(question). my bat file. set PYTHONPATH=C:\OSGeo4W64\apps\qgis\python set PATH=C:\OSGeo4W64\apps\qgis\bin;C:\OSGeo4W64\bin;C:\OSGeo4W64\apps\qgis\bin;C:\OSGeo4W64\apps\qgis\python;C:\OSGeo4W64\apps\Python27;C:\OSGeo4W64\apps\Python27\Scripts;C:\OSGeo4W64\apps\Python27\sip;C:\OSGeo4W64\apps\Python27\sip\Qt;C:\OSGeo4W64\apps\Python27\sip\QtCore;C:\OSGeo4W64\apps\Python27\sip\Qwt5;C:\OSGeo4W64\apps\Python27\sip\QtScriptTools;C:\OSGeo4W64\apps\Python27\DLLs;C:\OSGeo4W64\apps\Python27\Lib;C:\OSGeo4W64\apps\Python27\Lib\site-packages;C:\OSGeo4W64\apps\Python27\Tools\Scripts;C:\OSGeo4W64\apps\qgis\plugins;C:\OSGeo4W64\apps\qgis\python\qsci_apis;C:\OSGeo4W64\apps\qgis\python\qgis;C:\OSGeo4W64\apps\qgis\python\qgis\core;C:\OSGeo4W64\apps\qgis\python\qgis\analysis;C:\OSGeo4W64\apps\qgis\python\PyQt;C:\OSGeo4W64\apps\qgis\python\PyQt4;C:\OSGeo4W64\apps\qgis\python\PyQt4\uic\widget-plugins;C:\OSGeo4W64\apps\qgis\bin;C:\Python27\;C:\Python27\Scripts if i run this bat file in the OSGeo4w shell work but only in the shell shell image. but not work again in my idle again show me error no module name SIPerror sip why?any idea how to fix that? the problem is the paths sure but i dont know how to fix that.err -- https://mail.python.org/mailman/listinfo/python-list
python for complte program ?
hello i want to ask if a python is a good for to do it a complete program(.exe)? with user interface,module interface,background scripts where compile if the users calls some scripts,windows with interaction with the users? how can i do that with the python? how can libs need for this ? some tutorial for complete programs ? -- https://mail.python.org/mailman/listinfo/python-list
Re: python for complte program ?
On Fri, May 20, 2016 at 5:39 PM, Xristos Xristoou wrote: > hello i want to ask if a python is a good for to do it a complete > program(.exe)? > with user interface,module interface,background scripts where compile if > the users calls some scripts,windows with interaction with the users? > how can i do that with the python? > how can libs need for this ? > some tutorial for complete programs ? > -- > https://mail.python.org/mailman/listinfo/python-list There are some tools that will let you package your program with python, but if your user has python on his system, you may not need to do this -- Joel Goldstick http://joelgoldstick.com/blog http://cc-baseballstats.info/stats/birthdays -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On Sat, 21 May 2016 05:20 am, Christopher Reimer wrote: > According to "Effective Python: 59 Specific Ways to Write Better Python" > by Brett Slatkin, Item 12 recommends against using the else block after > for and while loops (see page 25): "Avoid using else blocks after loops > because their behavior isn't intuitive and can be confusing." By that logic, we ought to: - avoid using floats because their behaviour isn't intuitive and can be confusing; - avoid using lists because their behaviour isn't intuitive and can be confusing; - avoid using classes because their behaviour isn't intuitive and can be confusing; - avoid any form of asynchronous functions because their behaviour isn't intuitive and can be confusing; and so on. I can give examples of unintuitive and confusing behaviour for all of those things, and more, except the last. And the reason I can't give examples for async programming is because it confuses me and I don't understand it well enough to give even a minimal example. Just about the only things in Python which are intuitive and not confusing to somebody are None and ints. Or, we can *learn how to use the features* and stop thinking that programming is a matter of intuition. And most importantly, stop thinking that features need to be judged entirely by the least knowledgeable programmers. > Until I read the book, I wasn't aware of this feature (or bug). Doesn't > seem like a feature I would use since it's not commonly found in other > programming languages. As the author demonstrates in his book, I would > probably write a helper function instead. Sorry, was that called "Ineffective Python"? There is absolutely nothing effective about re-inventing the wheel badly or writing unnecessary code. Are you programming in those other languages or in Python? If you're programming in, say, Javascript, I can completely understand you deciding to limit yourself to features available in Javascript. Indeed to try to use Python language features in Javascript would be an exercise in frustration. Likewise using Ruby language features in Python is nothing but SyntaxError after SyntaxError, it makes it hard to get work done. But the idea that you should avoid a Python feature while programming in Python because Javascript doesn't have it, or Ruby, or C, is surely the height of muddleheaded thinking. You're not programming Javascript, Ruby or C, you're programming in Python. The whole point of picking one language over another is to get access to the tools and features that language offers. Otherwise you're just wasting your time. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
You seem to have missed the point. Nobody is suggesting, I don't believe, that all of a language should be intuitive. Rather that if any part of it is unnecessarily counter-intuitive, it may be worth looking for a better solution. Python is a very well designed language when it comes to in linguistic presentation. In this case however, it is not only unintuitive but counter-intuitive. The original question was simply, "Is it better to follow the semantics used elsewhere in the language, or have the language itself make sense semantically?" So, it is better to leave counter-intuitive constructs so they are consistent across the language or try to make each keyword make semantic sense where it is used? On Friday, May 20, 2016 at 3:43:58 PM UTC-7, Steven D'Aprano wrote: > On Sat, 21 May 2016 05:20 am, Christopher Reimer wrote: > > > According to "Effective Python: 59 Specific Ways to Write Better Python" > > by Brett Slatkin, Item 12 recommends against using the else block after > > for and while loops (see page 25): "Avoid using else blocks after loops > > because their behavior isn't intuitive and can be confusing." > > By that logic, we ought to: > > - avoid using floats because their behaviour isn't intuitive and > can be confusing; > - avoid using lists because their behaviour isn't intuitive and > can be confusing; > - avoid using classes because their behaviour isn't intuitive and > can be confusing; > - avoid any form of asynchronous functions because their behaviour > isn't intuitive and can be confusing; > > and so on. I can give examples of unintuitive and confusing behaviour for > all of those things, and more, except the last. And the reason I can't give > examples for async programming is because it confuses me and I don't > understand it well enough to give even a minimal example. > > Just about the only things in Python which are intuitive and not confusing > to somebody are None and ints. > > Or, we can *learn how to use the features* and stop thinking that > programming is a matter of intuition. And most importantly, stop thinking > that features need to be judged entirely by the least knowledgeable > programmers. > > > > Until I read the book, I wasn't aware of this feature (or bug). Doesn't > > seem like a feature I would use since it's not commonly found in other > > programming languages. As the author demonstrates in his book, I would > > probably write a helper function instead. > > Sorry, was that called "Ineffective Python"? > > There is absolutely nothing effective about re-inventing the wheel badly or > writing unnecessary code. > > Are you programming in those other languages or in Python? If you're > programming in, say, Javascript, I can completely understand you deciding > to limit yourself to features available in Javascript. Indeed to try to use > Python language features in Javascript would be an exercise in frustration. > Likewise using Ruby language features in Python is nothing but SyntaxError > after SyntaxError, it makes it hard to get work done. > > But the idea that you should avoid a Python feature while programming in > Python because Javascript doesn't have it, or Ruby, or C, is surely the > height of muddleheaded thinking. You're not programming Javascript, Ruby or > C, you're programming in Python. The whole point of picking one language > over another is to get access to the tools and features that language > offers. Otherwise you're just wasting your time. > > > > -- > Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On 05/20/2016 04:55 AM, Jon Ribbens wrote:
On 2016-05-20, Steven D'Aprano wrote:
On Fri, 20 May 2016 03:55 am, Jon Ribbens wrote:
I guess we should thank our lucky stars that you don't have a time
machine then, since that change would very much be one for the worse
in my opinion. for...else is perfectly straightforward and clearly
the right keywords to use. for...then would be entirely wrong.
"Entirely" wrong? "Clearly" the right keyword? "Perfectly" straightforward?
They are extremely strong words given the posts where *even the defenders*
of "else" have admitted that it is a hard keyword to understand. But that's
okay. Maybe you've thought of something the rest of us haven't, and have an
entire consistent mental model of for...else that is easy to understand and
makes it "perfectly straightforward and clearly the right keyword".
Can you explain your model which makes "else" appropriate?
Certainly. "else:" is (almost?) invariably used in the situation where
you are iterating through something in order to find a value which
matches a certain condition. So the "for:" block means "find this
value" and the "else:" means "else do this".
I'm happy that you have a working mental model for for/else (seriously,
I am) but please don't discount the confusion and consternation for the
many folks who don't start with that mental model.
The number of times I have /wanted/ to use the for/else structure for
searching is small (and I remember them both ;) -- every other time what
I wanted was an _else_ that ran iff the iterable was already empty when
the _for_ encountered it.
because like many people, my mental model was "the for block runs, OR ELSE
the else block runs". This *incorrect* model seems like it works: if you
set seq=[], say, it prints "seq is empty" as expected.
The problem there is that the mental model is *completely* wrong.
D'oh. Completely wrong, but easy to guess because of the similarity
with if/else.
I never would have thought of that model if it had been called "then":
for x in seq:
pass
then:
print("executes after the for block completes")
I would find that very confusing. "then:" makes it sound like
executing that block is the usual case, when in practice it is
usually the exception - the fallback code if the expected value
was not found.
If you don't take the extra step of _break_ it is the usual case. Most
of my for loops always run all the way through, so why have an else?
Two possible reasons:
- the loop didn't run at all
- the loop didn't run all the way
Guido picked the one that was obvious to him (him being Dutch and all ;) .
I just read Nick's post about it, and while it helps, I think the
syntactic similarity between try/else and for/else (did the block run
without error) is dwarfed by the semantic difference: a try/else else
block runs if nothing /bad/ happened whereas a for/else else block runs
if something bad /did/ happen; to wit, the thing you were looking for
was not found (or your loop didn't run at all ;) .
But as others have said, this isn't going to change now, and I'm okay
with that. But, please, be a bit more understanding of those who don't
immediately grok the for/else and while/else loops.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
Steven D'Aprano writes: > Just about the only things in Python which are intuitive and not > confusing to somebody are None and ints. I'll go even further: * The behaviour of ‘int’ is confusing to some. For example, to those who expect integers to produce fractions when divided. * The behaviour of ‘None’ is confusing to some. For example, to those who expect it to be a non-value, with no type. Examples of both those have appeared in this very forum in recent years. So, I think we can assert with confidence: if “avoid bevause it is unintuitive and confusing to some newcomers” were a good reason to avoid a Python feature, *all* Python features would be subject to oblivion. > Or, we can *learn how to use the features* and stop thinking that > programming is a matter of intuition. And most importantly, stop > thinking that features need to be judged entirely by the least > knowledgeable programmers. Yes. Appeals to intuition are irrelevant in talking about language features, IMO. The intuitions of newcomers should weigh heavily in language design. That is *not* the same as appealing to intuition: intuition gives you none of the essential and difficult concepts necessary to programming. > But the idea that you should avoid a Python feature while programming > in Python because Javascript doesn't have it, or Ruby, or C, is surely > the height of muddleheaded thinking. You're not programming > Javascript, Ruby or C, you're programming in Python. This is not to say that every Python feature can be used without concern. Steven is not arguing that avoidance of a feature is never justified. Rather, he's demonstrating that *that particular justification* is void. There may be a good reason to avoid Python behaviour Foo, but “because JavaScript/Ruby/Lisp/BASIC/INTERCAL doesn't have behaviour Foo” is not a valid justification. The case must be argued on other merits, if any. -- \ “Special today: no ice cream.” —mountain inn, Switzerland | `\ | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On 2016-05-20, Ethan Furman wrote: > On 05/20/2016 04:55 AM, Jon Ribbens wrote: >> Certainly. "else:" is (almost?) invariably used in the situation where >> you are iterating through something in order to find a value which >> matches a certain condition. So the "for:" block means "find this >> value" and the "else:" means "else do this". > > I'm happy that you have a working mental model for for/else (seriously, > I am) but please don't discount the confusion and consternation for the > many folks who don't start with that mental model. > > The number of times I have /wanted/ to use the for/else structure for > searching is small (and I remember them both ;) -- every other time what > I wanted was an _else_ that ran iff the iterable was already empty when > the _for_ encountered it. Well that's not a circumstance that's appropriate for the construct. Saying you want a different construct entirely is an entirely different argument. >> I would find that very confusing. "then:" makes it sound like >> executing that block is the usual case, when in practice it is >> usually the exception - the fallback code if the expected value >> was not found. > > If you don't take the extra step of _break_ it is the usual case. Having an "for: else:" clause without a "break" would be so unusual that it's literally nonexistent, because it would always be a bug. So no, it isn't the usual case for "for: else:". > But as others have said, this isn't going to change now, and I'm okay > with that. But, please, be a bit more understanding of those who don't > immediately grok the for/else and while/else loops. You're misunderstanding me. I'm not saying that the meaning of "for: else:" is 100% intuitively obvious. I'm saying that it's *more* obvious than it would be if it used any of the other existing keywords. I suppose I'm also saying that there isn't any other obvious word that could be made into a keyword that would be better than "else" (even if we assumed that adding a new keyword was a cost-free exercise). -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On 2016-05-20, Steven D'Aprano wrote:
> By that logic, we ought to:
>
> - avoid using floats because their behaviour isn't intuitive and
> can be confusing;
To be fair, I'm very sympathetic to that argument. I think programming
languages should never magically produce floats out of nowhere unless
the programmer has explicitly done "import float" or "float('3.23')"
or somesuch. They're misunderstood so often that any convenience
they provide is outweighed by the danger they bring.
"(1/10) * (1/10) * 10 != (1/10)" anyone? I was distinctly unhappy with
the Python 3 "2/3 ~= 0." thing and regard it as a very retrograde
change.
--
https://mail.python.org/mailman/listinfo/python-list
How to memory dump an object?
Is there any tools which can do the memory dump of an object so I can view their content or implementation? For example, >>> s1 = '\x80abc' >>> b1 = b'\x80abc' What are exactly stored in memory for each of them? Is their content really the same? This kind of tool should be helpful "for me" to learn the inner detail of Python. --Jach -- https://mail.python.org/mailman/listinfo/python-list
Graceful exit from Python + multiprocessing daemons
Hello,
Greetings!
I would like to get your advice wrt following situation:
I have a Linux daemon written in python (version 2.7) using the python-daemon
(https://pypi.python.org/pypi/python-daemon) module. The objective of using
python daemon is to run as an init.d script in Linux. This gets instantiated
and started using a main function.
The main function also creates a Driver object. That object in turn creates two
daemon processes (multiprocessing.Process with daemon flag set to True) a
producer and a consumer. The producer puts data in a multiprocessing.Queue and
the consumer reads those data items and processes them.
I have two challenges. Please advise how these can be handled:
1. When the program is stopped, I would like to preserve all the elements in
the Queue so it can be processed later. (So that data in the Queue is not
lost.) However, when I call the finalize function, it says the Queue is empty
even though elements are in the Queue. One thing I noticed is when the finalize
function is called, the parent ID changes to the calling process from 1.
2. When the daemon (python App stop) is stopped, I get an assertion error as
follows:
Terminating on signal 15
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
File "/usr/lib/python2.7/atexit.py", line 24, in _run_exitfuncs
func(*targs, **kargs)
File "/usr/lib/python2.7/multiprocessing/util.py", line 325, in _exit_function
p.join()
File "/usr/lib/python2.7/multiprocessing/process.py", line 143, in join
assert self._parent_pid == os.getpid(), 'can only join a child process'
AssertionError: can only join a child process
I am including the skeletal structure of the code for your review and advice.
---
class Producer(object):
def run():
self.data_queue.put(new_item)
def finalize(self):
dump_file = open('/tmp/dumper', 'wb')
while not self.data_queue.empty():
record = self.data_queue.get()
pickle.dump(record, dump_file)
dump_file.close()
class Consumer(object):
def run():
next_item = self.data_queue.get()
process_item(next_item)
def finalize(self):
dump_file = open('/tmp/dumper', 'wb')
while not self.data_queue.empty():
record = self.data_queue.get()
pickle.dump(record, dump_file)
dump_file.close()
class Driver(object)
def run_task(self, task, dummy):
while not self.stop_event.is_set():
task.run()
task.finalize()
self.logger.debug('Exiting task')
def __create_workers__(self):
task1 = Producer(data_queue)
self.task_list.append(task1)
p1 = multiprocessing.Process(target=self.run_task, name='T1',
args=(task1, 1))
self.worker_list.append(p1)
task2 = Consumer(data_queue)
self.task_list.append(task2)
p2 = multiprocessing.Process(target=self.run_task, name='T2',
args=(task2, 2))
self.worker_list.append(p2)
def run(self):
self.__create_workers__()
for worker in self.worker_list:
worker.daemon = True
worker.start()
def finalize(self):
for task in self.task_list:
self.logger.debug('finalizing ')
task.finalize()
if __name__ == "__main__":
the_driver = Driver(app_logger=logger)
the_driver.run()
# the following is a python-daemon object
the_daemon_object = Damien(logger)
daemon_runner.do_action()
---
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to memory dump an object?
On Friday, May 20, 2016 at 9:05:51 PM UTC-4, [email protected] wrote: > Is there any tools which can do the memory dump of an object so I can view > their content or implementation? For example, > > >>> s1 = '\x80abc' > >>> b1 = b'\x80abc' > > What are exactly stored in memory for each of them? Is their content really > the same? This kind of tool should be helpful "for me" to learn the inner > detail of Python. I don't know of a tool that will do that, other than running CPython under the gdb debugger, and examining memory that way. In Python 2, those two objects are the same, because '...' is a byte string, and b'...' is a byte string. I should say, those objects' memory starts out exactly the same. Objects have reference counts which change as names come and go: >>> s1 = '\x80abc' >>> b1 = b'\x80abc' >>> b2 = b1 Now the first string has a reference count of 1, and b1 has a reference count of 2. Those counts are in the objects' memory, so now their memory contents are different. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On Sat, May 21, 2016 at 10:35 AM, Jon Ribbens
wrote:
> On 2016-05-20, Steven D'Aprano wrote:
>> By that logic, we ought to:
>>
>> - avoid using floats because their behaviour isn't intuitive and
>> can be confusing;
>
> To be fair, I'm very sympathetic to that argument. I think programming
> languages should never magically produce floats out of nowhere unless
> the programmer has explicitly done "import float" or "float('3.23')"
> or somesuch. They're misunderstood so often that any convenience
> they provide is outweighed by the danger they bring.
>
> "(1/10) * (1/10) * 10 != (1/10)" anyone? I was distinctly unhappy with
> the Python 3 "2/3 ~= 0." thing and regard it as a very retrograde
> change.
The trouble is, what SHOULD 2/3 return?
* An integer? Makes a lot of sense to a C programmer. Not so much to
someone who is expecting a nonzero value. This isn't terrible (hey,
Python 2 managed with it no problem), but will definitely confuse a
number of people.
* A float? That's what we currently have. Not perfect, but it's going
to confuse less people than 0 will.
* A decimal.Decimal? That has its own issues (for instance, (x+y)/2
can return a value that isn't between x and y), and it still can't
represent two thirds properly.
* A fractions.Fraction? Well, at least that can perfectly represent a
ratio of integers. But it plays REALLY badly with other non-integer
types, and other operations than basic arithmetic (ever tried to take
the square root of a fraction?), so it's really only suited to
situations where you're working exclusively with fractions.
* Something else?
You say that Py3 making 1/10 => 0.1 was a "very retrograde change".
Why? Yes, now you're seeing floats; but would you be less surprised by
the Py2 version? Sure, Py2 has your little toy example working:
>>> (1/10) * (1/10) * 10 == (1/10)
True
but that's because 1/10 is zero, not because it's been represented
accurately! The biggest advantage of having integer division yield an
integer is that it forces people to think about their data types; but
since Python's float has a standing (core language support) that
Decimal and Fraction don't have, I don't think it's a problem. It's
the same with the complex type:
>>> 2 ** 0.5
1.4142135623730951
>>> (-2) ** 0.5
(8.659560562354934e-17+1.4142135623730951j)
Core data types will migrate between themselves as needed. (And this
proves some of the inherent inaccuracies in floating point arithmetic;
real number arithmetic says that the square root of -2 has a zero real
part.)
Interestingly, fractions.Fraction doesn't handle non-integer
exponentiation, and punts to float:
>>> fractions.Fraction(4) ** fractions.Fraction(2)
Fraction(16, 1)
>>> fractions.Fraction(4) ** fractions.Fraction(2, 3)
2.5198420997897464
>>> fractions.Fraction(4) ** fractions.Fraction(3, 2)
8.0
>>> fractions.Fraction(-4) ** fractions.Fraction(1, 2)
(1.2246467991473532e-16+2j)
Some data types just aren't well suited to certain operations.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On 2016-05-20, Steven D'Aprano wrote: > On Sat, 21 May 2016 05:20 am, Christopher Reimer wrote: > >> According to "Effective Python: 59 Specific Ways to Write Better Python" >> by Brett Slatkin, Item 12 recommends against using the else block after >> for and while loops (see page 25): "Avoid using else blocks after loops >> because their behavior isn't intuitive and can be confusing." > > By that logic, we ought to: > > - avoid using floats because their behaviour isn't intuitive and > can be confusing; Well, a lot of people probably should avoid floats. I've often said that anybody who hasn't taken a numerical methods class shouldn't be allowed to use floating point. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On 5/20/2016 3:43 PM, Steven D'Aprano wrote: But the idea that you should avoid a Python feature while programming in Python because Javascript doesn't have it, or Ruby, or C, is surely the height of muddleheaded thinking. You're not programming Javascript, Ruby or C, you're programming in Python. The whole point of picking one language over another is to get access to the tools and features that language offers. Otherwise you're just wasting your time. For many years I have resisted specializing in a programming language, as I can easily write any program in pseudo code and figure out the syntax for a particular language. Now it does help that most languages have derived from C and share a common feature set (i.e., string, integer, float, if/else, while, for, etc.). From my perspective, tacking on an else block to the end of a for or while loop looks like a bug or a not very well thought out feature. If I was translating a Python program with for/else or while/else statements into a different language, those statements will have to be rewritten anyway. Thank you, Chris R. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to memory dump an object?
On Sat, May 21, 2016 at 11:05 AM, wrote: > Is there any tools which can do the memory dump of an object so I can view > their content or implementation? For example, > s1 = '\x80abc' b1 = b'\x80abc' > > What are exactly stored in memory for each of them? Is their content really > the same? This kind of tool should be helpful "for me" to learn the inner > detail of Python. > MASSIVE CAVEAT: This is *not* anything that the Python language specifies. You can mess around with this in one interpreter (say, CPython 3.5) and get one result, but in a different interpreter (Jython, IronPython, MicroPython, Brython), or a different version of the same interpreter (CPython 3.2), or even the exact same interpreter on different platforms (32-bit vs 64-bit, Linux vs Windows vs Mac OS vs other, or different CPUs), you may get completely different results. And some language implementations (eg PyPy) don't necessarily even keep the object in memory at all times. But if you're curious about how things are stored, there are ways you can mess around and find stuff out. The easiest way to explore CPython's internals would probably be ctypes. In CPython, an object's identity is based on its address in memory, so you can cast that to a pointer. >>> import ctypes >>> s1 = "\x80abc" >>> ctypes.cast(id(s1), ctypes.c_voidp) c_void_p(140180250548144) >>> import sys >>> sys.getsizeof(s1) # See how much space it takes up in RAM 77 You can mess around with pointers to your heart's content: >>> ptr = ctypes.cast(id(s1), ctypes.POINTER(ctypes.c_uint8)) >>> bytes([ptr[i] for i in range(77)]) b'\x01\x00\x00\x00\x00\x00\x00\x00\x00\x04\x88\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x15!\xbc\x99y\xc4A]\xa43XB~\x7f\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x80abc\x00' Hey look, there it is! For more info on how CPython 3.3+ stores Unicode text, check out this document: https://www.python.org/dev/peps/pep-0393/ It's pretty smart :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On Sat, May 21, 2016 at 11:23 AM, Christopher Reimer wrote: > On 5/20/2016 3:43 PM, Steven D'Aprano wrote: > >> But the idea that you should avoid a Python feature while programming in >> Python because Javascript doesn't have it, or Ruby, or C, is surely the >> height of muddleheaded thinking. You're not programming Javascript, Ruby >> or >> C, you're programming in Python. The whole point of picking one language >> over another is to get access to the tools and features that language >> offers. Otherwise you're just wasting your time. > > > For many years I have resisted specializing in a programming language, as I > can easily write any program in pseudo code and figure out the syntax for a > particular language. Now it does help that most languages have derived from > C and share a common feature set (i.e., string, integer, float, if/else, > while, for, etc.). From my perspective, tacking on an else block to the end > of a for or while loop looks like a bug or a not very well thought out > feature. If I was translating a Python program with for/else or while/else > statements into a different language, those statements will have to be > rewritten anyway. That's fine, as long as you (a) restrict your programming languages to those derived from C, and (b) restrict your programming style to the common subset of them all. Trouble is, that "common subset" is actually pretty small. Strings behave very differently in C and high level languages, and for loops are *very* different in different languages. So you'd be throwing out a large amount of expressiveness, plus you're completely unable to use languages built on some other model (eg LISP, or DeScribe Macro Language, or APL). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Summing/combining tuples
On Wed, 18 May 2016 20:59:55 -0400, DFS wrote:
> Have aList = [
> ('x','Name1', 1, 85),
> ('x','Name2', 3, 219),
> ('x','Name2', 1, 21),
> ('x','Name3', 6, 169)
> ]
>
> want
>
> aList = [
> ('Name1', 1, 85),
> ('Name2', 4, 240),
> ('Name3', 6, 169)
> ]
[snip]
> Is there something shorter and sweeter for the summation?
from itertools import groupby
from operator import itemgetter
result = [(k,
sum(map(itemgetter(2), v)),
sum(map(itemgetter(3), v)))
for (k, v) in [(k, list(v))
for (k, v)
in groupby(aList, itemgetter(1))]])
Shorter? In terms of number of expressions, yes. In terms of
characters typed, no.
Sweeter? YMMV.
HTH,
Dan
--
https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On 5/20/2016 7:31 PM, Chris Angelico wrote: On Sat, May 21, 2016 at 11:23 AM, Christopher Reimer wrote: On 5/20/2016 3:43 PM, Steven D'Aprano wrote: But the idea that you should avoid a Python feature while programming in Python because Javascript doesn't have it, or Ruby, or C, is surely the height of muddleheaded thinking. You're not programming Javascript, Ruby or C, you're programming in Python. The whole point of picking one language over another is to get access to the tools and features that language offers. Otherwise you're just wasting your time. For many years I have resisted specializing in a programming language, as I can easily write any program in pseudo code and figure out the syntax for a particular language. Now it does help that most languages have derived from C and share a common feature set (i.e., string, integer, float, if/else, while, for, etc.). From my perspective, tacking on an else block to the end of a for or while loop looks like a bug or a not very well thought out feature. If I was translating a Python program with for/else or while/else statements into a different language, those statements will have to be rewritten anyway. That's fine, as long as you (a) restrict your programming languages to those derived from C, and (b) restrict your programming style to the common subset of them all. Trouble is, that "common subset" is actually pretty small. Strings behave very differently in C and high level languages, and for loops are *very* different in different languages. So you'd be throwing out a large amount of expressiveness, plus you're completely unable to use languages built on some other model (eg LISP, or DeScribe Macro Language, or APL). I don't have a problem with (a) because the majority of the programming languages I've been exposed to have derived from the C language. No offense to the LISPers, but LISP is a historical curiosity that I might blow the dust off and take a look at someday. I'll probably learn assembly language before I ever look at LISP. :) But I disagree with (b) on restricting myself to a common subset of ALL the programming languages. Pseudo code allows me to describe a program in very general details. Implementing a program in a programming language requires getting into very specific details. Of course, there are major and minor differences from language to language. If an oddball feature gets the job done, I'll use that. Or maybe not. If I'm uncertain about something, I'll keep going back and forth until I'm satisfied one way or another. The else block tacked on to for and while loops in Python seems very oddball-ish to me. I've always strive to follow best practice whenever possible. The one book I've read -- and so far, the only book on that feature -- recommends not using it. Based on my previous experience, I don't disagree with that author's opinion. If I have a compelling reason to use it, I'll use it. Or I'll simplify it to use helper functions. If I wanted to write portable code, I would have stayed with... Java. O_o Thank you, Chris R. -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On Sat, 21 May 2016 10:24 am, Jon Ribbens wrote:
> On 2016-05-20, Ethan Furman wrote:
>> If you don't take the extra step of _break_ it is the usual case.
>
> Having an "for: else:" clause without a "break" would be so unusual
> that it's literally nonexistent, because it would always be a bug.
> So no, it isn't the usual case for "for: else:".
What do you mean? A for...else without a break is perfectly legal code, and
does *EXACTLY* what it is documented as doing:
- first the "for" block runs, looping as appropriate;
- THEN the "else" block runs, *once*.
How is this "always a bug"?
Would you classify the second line here:
print("Hello World!")
pass
as a bug? What exactly would your bug report be? "pass statement does
nothing, as expected. It should do nothing. Please fix."
>> But as others have said, this isn't going to change now, and I'm okay
>> with that. But, please, be a bit more understanding of those who don't
>> immediately grok the for/else and while/else loops.
>
> You're misunderstanding me. I'm not saying that the meaning of
> "for: else:" is 100% intuitively obvious.
I should hope not, because as it stands with the horribly misleading
keyword "else" it is counter-intuitive and confusing. Which is a crying
shame, because it is a useful feature that actually does make a lot of
sense, if only the keyword were better!
> I'm saying that it's
> *more* obvious than it would be if it used any of the other existing
> keywords. I suppose I'm also saying that there isn't any other
> obvious word that could be made into a keyword that would be better
> than "else" (even if we assumed that adding a new keyword was a
> cost-free exercise).
Well, that's a matter of opinion. And you know what they same about
opinions... there are always two, the foolish, pig-ignorant one, and mine.
:-)
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Extract the middle N chars of a string
On Wed, May 18, 2016 at 10:47 AM, Steven D'Aprano wrote: > Getting the middle N seems like it ought to be easy: > > s[N//2:-N//2] > > but that is wrong. It's not even the right length! > > py> s = 'aardvark' > py> s[5//2:-5//2] > 'rdv' > > > So after spending a ridiculous amount of time on what seemed like it ought > to be a trivial function, and an embarrassingly large number of off-by-one > and off-by-I-don't-even errors, I eventually came up with this: > > def mid(string, n): > """Return middle n chars of string.""" > L = len(string) > if n <= 0: > return '' > elif n < L: > Lr = L % 2 > a, ar = divmod(L-n, 2) > b, br = divmod(L+n, 2) > a += Lr*ar > b += Lr*br > string = string[a:b] > return string As some of you know, I usually post on the Tutor list while attempting to learn Python as time permits. I had to try my hand at this problem as a learning opportunity. I hope you don't mind if I explain how I got to my solution and welcome your critiques, so I may improve. I chose to cheat my answers to the right; I did not think about the possibility of alternating the sides to allot the extra character (when needed) to average things out until I read everyone's answers after getting my own. I started considering two strings, s_even = '0123456789' and s_odd = '123456789', with trial values of n = 4 and n = 5 for how many characters to extract. This gave me the following four desired outputs to replicate: 1) s_even with n = 5. Desired output: '34567' (Cheating right.) => Slice s_even[3:8] 2) s_even with n = 4. Desired output: '3456' (Exact.) => Slice s_even[3:7] 3) s_odd with n = 5. Desired output: '34567' (Exact.) => Slice s_odd[2:7] 4) s_odd with n = 4. Desired output: '4567' (Cheating right.) => Slice s_odd[3:7] Starting to generalize to get the desired indices for each case: 1) (len(s_even)//2 - n//2):(len(s_even)//2 + n//2 + 1) 2) (len(s_even)//2 - n//2):(len(s_even)//2 + n//2) 3) (len(s_odd)//2 - n//2):(len(s_odd)//2 + n//2 + 1) 4) (len(s_odd)//2 + 1 - n//2):(len(s_odd)//2 + n//2 + 1) Looking at the starting index for each case, I had an extra 1 for case (4), which, in table form: n evenn odd s_even0 0 s_odd 1 0 To duplicate this I came up with the expression: (len(s)%2) * (1 - n%2) Similarly, for the ending slice index, all cases have an extra "+ 1" except for case (2), with the following table: n evenn odd s_even0 1 s_odd 1 1 And the expression: 1 - ((len(s) + 1)%2 * (n +1)%2) All this was scribbled onto scratch paper, so I hope I did not make any typos! This led me to the following code: py3: def mid(s, n): ... index0_offset = (len(s)%2) * (1 - n%2) ... index1_offset = 1 - ((len(s) + 1)%2) * ((n + 1)%2) ... index0 = len(s)//2 - n//2 + index0_offset ... index1 = len(s)//2 + n//2 + index1_offset ... return s[index0:index1] ... py3: s = '0123456789' py3: n = 5 py3: mid(s, n) '34567' py3: n = 4 py3: mid(s, n) '3456' py3: s = '123456789' py3: n = 5 py3: mid(s, n) '34567' py3: n = 4 py3: mid(s, n) '4567' py3: s = 'aardvark' py3: n = 5 py3: mid(s, n) 'rdvar' This also returns an empty string for values of n <= 0. As far as I can tell, my solution works (Given cheating right.). I ran it on all of Steve's examples, and I got what I expected given that I am consistently cheating right. But I am not sure my code adequately conveys an understanding of what I am doing to the casual reader. Thoughts? TIA! boB -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On Sat, May 21, 2016 at 1:50 PM, Steven D'Aprano wrote:
> On Sat, 21 May 2016 10:24 am, Jon Ribbens wrote:
>
>> On 2016-05-20, Ethan Furman wrote:
>
>>> If you don't take the extra step of _break_ it is the usual case.
>>
>> Having an "for: else:" clause without a "break" would be so unusual
>> that it's literally nonexistent, because it would always be a bug.
>> So no, it isn't the usual case for "for: else:".
>
>
> What do you mean? A for...else without a break is perfectly legal code, and
> does *EXACTLY* what it is documented as doing:
>
> - first the "for" block runs, looping as appropriate;
> - THEN the "else" block runs, *once*.
>
> How is this "always a bug"?
>
> Would you classify the second line here:
>
> print("Hello World!")
> pass
>
>
> as a bug? What exactly would your bug report be? "pass statement does
> nothing, as expected. It should do nothing. Please fix."
>
Yes, I would. It's not a bug in Python or CPython - it's a bug in the
second line of code there. It implies something that isn't the case.
It's like having this code:
if True:
pass
elif False:
pass
else:
assert True
It's well-defined code. You know exactly what Python should do. But is
it good code, or is it the sort of thing that gets posted here:
http://thedailywtf.com/articles/a-spiritual-journey
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to memory dump an object?
Sorry, forget to mention that I am working on version 3.4 Following the steps given in Chris's reply, I get the result from bytes string: >>> b1 = b'\x80abc' >>> ctypes.cast(id(b1), ctypes.c_voidp) c_void_p(35495992) >>> sys.getsizeof(b1) 21 >>> b1ptr = ctypes.cast(id(b1), ctypes.POINTER(ctypes.c_uint8)) >>> bytes([b1ptr[i] for i in range(21)]) b'\x01\x00\x00\x00X\xa1e^\x04\x00\x00\x00\x04\xff\x04&\x80abc\x00' >>> It obviously has the same "content" as the s1 string has and the object's structure are much different as expected (77 vs 21 bytes:-) If I do this as Ned suggested: >>> b2 = b1 I get: >>> bytes([b1ptr[i] for i in range(21)]) b'\x02\x00\x00\x00X\xa1e^\x04\x00\x00\x00\x04\xff\x04&\x80abc\x00' >>> So, at least, we know where the reference count was stored:-) It's amazing the "tool" is so simple. Actually I feel a little embarrassed that I do know every statements in it but just no idea of combining them together. Thanks a lot, Chris. --Jach -- https://mail.python.org/mailman/listinfo/python-list
Re: How to memory dump an object?
On Sat, 21 May 2016 11:05 am, [email protected] wrote: > Is there any tools which can do the memory dump of an object so I can view > their content or implementation? No standard tool. There may be third-party tools, but they would be implementation-specific. > For example, > s1 = '\x80abc' b1 = b'\x80abc' > > What are exactly stored in memory for each of them? That will depend on the version and implementation of the Python interpreter you are looking at. Strings especially are implemented in many different ways. Before Python 3.3, CPython used two different implementations, which you choose when compiling the interpreter from source: - "narrow builds" use two-bytes per character, and have difficulty with Unicode codepoints after U+; - "wide builds" use four-bytes per character, and can cope with the entire Unicode range up to U+10; - I think that Jython uses the Java string implementation; - and that IronPython uses the .Net string implementation. Starting at Python 3.3, the CPython implementation will dynamically choose a one-byte, two-byte or four-byte per character implementation, as needed. > Is their content really the same? The first is the Unicode string with four code points: LATIN SMALL LETTER A LATIN SMALL LETTER B LATIN SMALL LETTER C the other contains a byte-string with four bytes: \x80 \x61 (ASCII 'a') \x62 (ASCII 'b') \x63 (ASCII 'c') So in *some* sense they are the same content, but only in the sense that this list: [128, 97, 98, 99] *also* has the same content. Instead of a low-level memory dump, which isn't actually terribly useful (for many objects, such as lists, all it would show is a bunch of pointers), there are other high-level introspection tools available in the `inspect` module. You can also use: sys.getsizeof to see how much memory is used by an object. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: How to memory dump an object?
On Sat, May 21, 2016 at 2:47 PM, wrote: > It's amazing the "tool" is so simple. Actually I feel a little embarrassed > that I do know every statements in it but just no idea of combining them > together. Thanks a lot, Chris. > It's a pretty complicated tool, actually - but you're using it in a simple way here. If you're curious, you can poke around in the CPython sources to track down the data structures involved - as you noted, the refcount is at the beginning of every object, and after that you'll find some neat info like a pointer to its type. You can even change some of this stuff, but be aware that you can EASILY segfault Python like this :D ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Summing/combining tuples
On Sat, 21 May 2016 03:19:49 +, Dan Sommers wrote: >> Is there something shorter and sweeter for the summation? > > from itertools import groupby > from operator import itemgetter > > result = [(k, >sum(map(itemgetter(2), v)), >sum(map(itemgetter(3), v))) > for (k, v) in [(k, list(v)) > for (k, v) > in groupby(aList, itemgetter(1))]]) Or even: from itertools import groupby from operator import itemgetter from functools import reduce result = [(k, *reduce(lambda acc, item: (acc[0] + item[2], acc[1] + item[3]), v, (0, 0))) for (k, v) in groupby(aList, itemgetter(1))] -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On Saturday, May 21, 2016 at 1:51:19 AM UTC+5:30, Christopher Reimer wrote: > On 5/20/2016 8:59 AM, Zachary Ware wrote: > > > On Fri, May 20, 2016 at 3:09 AM, Erik wrote: > >> On 20/05/16 00:51, Gregory Ewing wrote: > >>> It's not so bad with "else" because you need to look back > >>> to find out what condition the "else" refers to anyway. > >> > >> With my tongue only slightly in my cheek, if it was desirable to > >> "fix"/clarify this syntax then I would suggest adding some optional > >> (existing) trailing keywords to 'else' in this context that spells it out: > >> > >> for item in seq: > >> if foo(item): > >> break > >> else if not break: > >> nomatch() > > With tongue firmly cheeked, you can always use the special `:#` operator: > > > > for item in seq: > > if foo(item): > > break > > else:# if no break: > > nomatch() > > > > This has the benefit that you can use whatever syntax you like after > > the `:#`, and use it in any version of Python you want. > > According to "Effective Python: 59 Specific Ways to Write Better Python" > by Brett Slatkin, Item 12 recommends against using the else block after > for and while loops (see page 25): "Avoid using else blocks after loops > because their behavior isn't intuitive and can be confusing." > > Until I read the book, I wasn't aware of this feature (or bug). Doesn't > seem like a feature I would use since it's not commonly found in other > programming languages. As the author demonstrates in his book, I would > probably write a helper function instead. > > Item 13 does recommend using the else block for try/except/else/finally > in exception handling. :) Firstly: let me say that for the specific case of loop-else I am in violent agreement: I find it so confusing that I dont even know what/how it works Coming to the more general attitude expressed above, this view can be eminently sensible or dangerously retrogressive depending... It is a sound and sane view because the field of computer science exists and legitimately so. Which means that, even though when we look around at the field of programming languages what we are struck by is a bedlam of - advertising - fanboyism - latest and bestest koolaid - holy (cow) wars And a corresponding deficit of anything really conceptual, real advances, real understanding; in short truckloads of BS. OTOH the fact that the field of CS exists and is not (only) BS is a good thing. IOW sticking to the well-established canonical core is sound policy compared to jumping onto the latest loud-rattling bandwagon. And yet... Human beings have the propensity of sticking to the norm rather than deviating even when the norm is grievously in error. The following lists some amazingly long lasting errors: http://blog.languager.org/2016/01/how-long.html This is related to the pedagogic principle called "Law of Primacy": | Things learned first create a strong impression in the mind that is difficult | to erase. For the instructor, this means that what is taught must be right | the first time. Given that for the most part, most of us are horribly uneducated [ http://www.creativitypost.com/education/9_elephants_in_the_classroom_that_should_unsettle_us ] how do we go about correcting our wrong primacies? Given that you imagine Lisp is a historical curiosity (have you heard of clojure?) And java (and presumably OOP) is relevant [see Stepanov on OOP: https://en.wikipedia.org/wiki/Object-oriented_programming#Criticism ] I suggest you start with: http://blog.languager.org/2016/01/primacy.html -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
[email protected]: > You seem to have missed the point. Nobody is suggesting, I don't > believe, that all of a language should be intuitive. Rather that if > any part of it is unnecessarily counter-intuitive, it may be worth > looking for a better solution. Python is a very well designed language > when it comes to in linguistic presentation. In this case however, it > is not only unintuitive but counter-intuitive. The for-else construct is a highly practical feature. It is in no way inherently counter-intuitive. As any new thing, it needs to be learned and used to be appreciated. Marko -- https://mail.python.org/mailman/listinfo/python-list
