Re: Textwrap doesn't honour NO-BREAK SPACE
On Fri, 29 Sep 2017 03:55 pm, Terry Reedy wrote: >> Expected result: >> >> >> Lorum ipsum dolor sit amet, consectetur adipiscing elit >> ZZZ ZZZ sed do euismod tempor incididunt ut labore et >> dolore magna aliqua. > > On Windows 10, I get this on 2.7, 3.5, 3.6, 3.7. > >> Actual result in Python 3.5 and older: >> >> Lorum ipsum dolor sit amet, consectetur adipiscing elit ZZZ >> ZZZ sed do euismod tempor incididunt ut labore et dolore >> magna aliqua. Sorry Terry, it isn't clear to me which result (expected, or actual) is "this" in your comment. I wonder if the behaviour is platform specific? On Linux, I've tried Python 2.7 (after adjusting for a Unicode string rather than byte string), 3.3 and 3.5 and it breaks on the NO-BREAK SPACE on all three. -- 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: Beginners and experts (Batchelder blog post)
On Fri, Sep 29, 2017 at 3:28 PM, Gregory Ewing wrote: > Chris Angelico wrote: >> >> finding the bug is basically searching >> through a problem space of all things that could potentially cause >> this symptom. A novice could accidentally stumble onto the right >> solution to a tricky bug, or an expert could search a thousand other >> things and only get to the true cause after a long time. > > > What I think is more important than how *long* it takes is > *how* they go about finding the bug. > > A novice will make wild guesses about what might be wrong > and make random changes to the program in the hope of > making it work. An experienced programmer will conduct > a series of carefully-designed experiments to narrow > down the cause. > > A result of this is that a true expert will never have > to try a thousand possibilities. He will be able to > search a space of N possible causes in O(log N) operations. > > This doesn't necessarily translate into time, because > in some situations the experiments can be very time- > consuming to perform. But other things being equal, > the expert's bug-finding algorithm is faster than the > novice's. This is very true, which is part of why I said that in programming, it takes one to know one - to observe a candidate and determine his/her experimental technique, you basically need to yourself be a programmer. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Textwrap doesn't honour NO-BREAK SPACE
On 9/29/2017 1:25 AM, Steve D'Aprano wrote:
I don't have Python 3.6 installed, can somebody check to see whether or not it
shows the same (wrong) behaviour?
import textwrap
text = ('Lorum ipsum dolor sit amet, consectetur adipiscing'
' elit ZZZ\xa0ZZZ sed do euismod tempor incididunt'
' ut labore et dolore magna aliqua.')
print(textwrap.fill(text, 59))
Expected result:
Lorum ipsum dolor sit amet, consectetur adipiscing elit
ZZZ ZZZ sed do euismod tempor incididunt ut labore et
dolore magna aliqua.
On Windows 10, I get this on 2.7, 3.5, 3.6, 3.7.
Actual result in Python 3.5 and older:
Lorum ipsum dolor sit amet, consectetur adipiscing elit ZZZ
ZZZ sed do euismod tempor incididunt ut labore et dolore
magna aliqua.
I'm pretty sure this is a bug.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Textwrap doesn't honour NO-BREAK SPACE
"Steve D'Aprano" wrote in message
news:59cdd938$0$14933$b1db1813$d948b...@news.astraweb.com...
I don't have Python 3.6 installed, can somebody check to see whether or not
it
shows the same (wrong) behaviour?
[...]
C:\Users\User>python
Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 08:06:12) [MSC v.1900 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
import textwrap
text = ('Lorum ipsum dolor sit amet, consectetur adipiscing'
... ' elit ZZZ\xa0ZZZ sed do euismod tempor incididunt'
... ' ut labore et dolore magna aliqua.')
print(textwrap.fill(text, 59))
Lorum ipsum dolor sit amet, consectetur adipiscing elit
ZZZ ZZZ sed do euismod tempor incididunt ut labore et
dolore magna aliqua.
It seems to have been fixed.
Frank Millman
--
https://mail.python.org/mailman/listinfo/python-list
Re: Spacing conventions
Steve D'Aprano wrote: On Thu, 28 Sep 2017 03:56 pm, Bill wrote: I worked in maintenance programming. You got the hand you were dealt! And you weren't allowed to "improve" the code unless the customer contracted you to do so. How do you tell the difference between a bug fix and an code improvement, if the behaviour of the program remains the same? They ran the Unix command "diff" to double-check that nothing unaccounted for got added to the source code as they did new builds. The "rule" was you could "fix" the code if you were already there, in the immediate vicinity. In retrospect, this certainly helped to keep "human error" from sneaking in. I maintained for-loops (containing for-loops)... hundreds of lines long. Would you be searching for break or continue? : ) It depends on whether it was relevant to the bug or not. I've never felt the urge to search for some arbitrary keyword when debugging. Why search for break or continue? How do you know the bug has anything to do with one of them? I would start with narrowing down where the bug occurs. Hopefully the stacktrace or error gives a line number. Then work backwards from there. I certainly wouldn't say "Oh, the code crashed on line 587. I'll do a quick search for the closest break statement and start working from there." What do you do? -- https://mail.python.org/mailman/listinfo/python-list
Re: Beginners and experts (Batchelder blog post)
Chris Angelico wrote: finding the bug is basically searching through a problem space of all things that could potentially cause this symptom. A novice could accidentally stumble onto the right solution to a tricky bug, or an expert could search a thousand other things and only get to the true cause after a long time. What I think is more important than how *long* it takes is *how* they go about finding the bug. A novice will make wild guesses about what might be wrong and make random changes to the program in the hope of making it work. An experienced programmer will conduct a series of carefully-designed experiments to narrow down the cause. A result of this is that a true expert will never have to try a thousand possibilities. He will be able to search a space of N possible causes in O(log N) operations. This doesn't necessarily translate into time, because in some situations the experiments can be very time- consuming to perform. But other things being equal, the expert's bug-finding algorithm is faster than the novice's. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Textwrap doesn't honour NO-BREAK SPACE
I don't have Python 3.6 installed, can somebody check to see whether or not it
shows the same (wrong) behaviour?
import textwrap
text = ('Lorum ipsum dolor sit amet, consectetur adipiscing'
' elit ZZZ\xa0ZZZ sed do euismod tempor incididunt'
' ut labore et dolore magna aliqua.')
print(textwrap.fill(text, 59))
Expected result:
Lorum ipsum dolor sit amet, consectetur adipiscing elit
ZZZ ZZZ sed do euismod tempor incididunt ut labore et
dolore magna aliqua.
Actual result in Python 3.5 and older:
Lorum ipsum dolor sit amet, consectetur adipiscing elit ZZZ
ZZZ sed do euismod tempor incididunt ut labore et dolore
magna aliqua.
I'm pretty sure this is a bug.
--
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: Spacing conventions
On Fri, Sep 29, 2017 at 2:38 PM, Steve D'Aprano wrote: > On Thu, 28 Sep 2017 03:56 pm, Bill wrote: > >> I worked in maintenance programming. You got the hand you were dealt! >> And you weren't allowed to "improve" the code unless the customer >> contracted you to do so. > > How do you tell the difference between a bug fix and an code improvement, if > the > behaviour of the program remains the same? If the behaviour remains *exactly* the same, then it's a code improvement (aka a refactoring), not a bug fix. Or, looking at it another way: if there is absolutely no change to behaviour, how could you tell that there was a bug in it? And yes, trying to convince a customer that it's worth paying for improvements that don't change anything visible is hard. Which is why a lot of companies end up merely paying interest on their technical debt, and never paying off any of the capital. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Spacing conventions
On Thu, 28 Sep 2017 03:56 pm, Bill wrote: > I worked in maintenance programming. You got the hand you were dealt! > And you weren't allowed to "improve" the code unless the customer > contracted you to do so. How do you tell the difference between a bug fix and an code improvement, if the behaviour of the program remains the same? > I maintained for-loops (containing > for-loops)... hundreds of lines long. Would you be searching for break or > continue? : ) It depends on whether it was relevant to the bug or not. I've never felt the urge to search for some arbitrary keyword when debugging. Why search for break or continue? How do you know the bug has anything to do with one of them? I would start with narrowing down where the bug occurs. Hopefully the stacktrace or error gives a line number. Then work backwards from there. I certainly wouldn't say "Oh, the code crashed on line 587. I'll do a quick search for the closest break statement and start working from there." What do you do? -- 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: Case Solution: ENOVE Business Strategy in a Transitioning Economy by Maciek Nowak, Alexander Stoll
On Friday, August 4, 2017 at 5:08:20 PM UTC-5, Case Solution & Analysis wrote: > Case Solution and Analysis of ENOVE: Business Strategy in a Transitioning > Economy by Maciek Nowak, Alexander Stoll is available at a lowest price, send > email to casesolutionscentre(at)gmail(dot)com if you want to order the Case > Solution. > > Case Study ID: 9B16M013 / W16035 > > Get Case Study Solution and Analysis of ENOVE: Business Strategy in a > Transitioning Economy in a FAIR PRICE!! > > Our e-mail address is CASESOLUTIONSCENTRE (AT) GMAIL (DOT) COM. Please > replace (at) by @ and (dot) by . > > YOU MUST WRITE THE FOLLOWING WHILE PLACING YOUR ORDER: > Complete Case Study ENOVE Business Strategy in a Transitioning Economy > Authors by Maciek Nowak, Alexander Stoll > Case Study ID 9B16M013 / W16035 > Publisher of Case Study Havard Business Review > Your Requirements Case Study for International Business / Case Questions > Don't know haven't read the article yet. > > Note: Do not REPLY to this post because we do not reply to posts here. If you > need any Case Solution please send us an email. We can help you to get it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Beginners and experts (Batchelder blog post)
On Thu, Sep 28, 2017 at 5:08 PM, Chris Angelico wrote: > Yep. Pick anyone on this list that you believe is an expert, and ask > him/her for a story of a long debug session that ended up finding a > tiny problem. I can pretty much guarantee that every expert programmer > will have multiple such experiences, and it's just a matter of > remembering one with enough detail to share the story. The software development process can be summed up thusly: I can’t fix this Crisis of confidence Questions career Questions life Oh it was a typo, cool -- https://mail.python.org/mailman/listinfo/python-list
Re: Beginners and experts (Batchelder blog post)
On Fri, Sep 29, 2017 at 7:47 AM, Bill wrote: > I won't claim to be any sort of "expert". But one memorable problem, for > me, was ultimately accounted for by the "inherent problem" of the floating > point variables x0 and xo coexisting in the same module. It's sort of funny > if you think about it just right. FWIW, my job was to fix the problem, I > didn't create it! Today I helped one of my students debug an issue that was exacerbated by a flawed shuffle function that, while capable of returning any permutation of the input, had a bit of a tendency to leave things early if they started early - it was about 8% more likely to pick the first element than the last. Doesn't sound like much, but it increased the chances of a collision pretty significantly. Now THAT was fun to debug. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Beginners and experts (Batchelder blog post)
Chris Angelico wrote: On Fri, Sep 29, 2017 at 6:59 AM, Bill wrote: Chris Angelico wrote: Be careful with this one. For anything other than trivial errors (and even for some trivial errors), finding the bug is basically searching through a problem space of all things that could potentially cause this symptom. A novice could accidentally stumble onto the right solution to a tricky bug, or an expert could search a thousand other things and only get to the true cause after a long time. some "expert"! ; ) Yep. Pick anyone on this list that you believe is an expert, and ask him/her for a story of a long debug session that ended up finding a tiny problem. I can pretty much guarantee that every expert programmer will have multiple such experiences, and it's just a matter of remembering one with enough detail to share the story. ChrisA I won't claim to be any sort of "expert". But one memorable problem, for me, was ultimately accounted for by the "inherent problem" of the floating point variables x0 and xo coexisting in the same module. It's sort of funny if you think about it just right. FWIW, my job was to fix the problem, I didn't create it! Bill -- https://mail.python.org/mailman/listinfo/python-list
Re: Beginners and experts (Batchelder blog post)
On Fri, Sep 29, 2017 at 6:59 AM, Bill wrote: > Chris Angelico wrote: >> >> Be careful with this one. For anything other than trivial errors (and >> even for some trivial errors), finding the bug is basically searching >> through a problem space of all things that could potentially cause >> this symptom. A novice could accidentally stumble onto the right >> solution to a tricky bug, or an expert could search a thousand other >> things and only get to the true cause after a long time. > > some "expert"! ; ) > Yep. Pick anyone on this list that you believe is an expert, and ask him/her for a story of a long debug session that ended up finding a tiny problem. I can pretty much guarantee that every expert programmer will have multiple such experiences, and it's just a matter of remembering one with enough detail to share the story. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: EuroPython 2017: Videos for Monday available online
On 9/28/2017 12:33 PM, M.-A. Lemburg wrote: """ In the coming weeks, we will release the other videos, in batches of one conference day per week. """ It was not obvious to me that 'private video' meant 'non-existent, not yet added video'. It usually means a video that is present but not public. Perhaps we ought to remove them from the playlist to not cause confusion. This doesn't appear to be easily possible due to changes in the YT UI. We've now set the playlist order to show the private videos at the end as work-around. That would make it easier to see what is available not. I gave up trying to scroll through the list. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Beginners and experts (Batchelder blog post)
Chris Angelico wrote: On Fri, Sep 29, 2017 at 5:45 AM, Bill wrote: Paul Moore wrote: On 27 September 2017 at 17:41, leam hall wrote: Hehe...I've been trying to figure out how to phrase a question. Knowing I'm not the only one who gets frustrated really helps. I'm trying to learn to be a programmer. I can look at a book and read basic code in a few languages but it would be unfair to hire myself out as a programmer. I'm just not yet worth what it costs to pay my bills. You're already ahead of the game in wanting to be useful, rather than just knowing the jargon :-) However, I've always found that the biggest asset a programmer can have is the simple willingness to learn. I basically agree with what has been posted. I just wanted to mention a couple things that separates beginners and non-beginners. One is "how long it takes to identify and fix an error"--even a syntax error. And that is a skill which is acquired with some practice, maybe more "some" than anyone likes. Be careful with this one. For anything other than trivial errors (and even for some trivial errors), finding the bug is basically searching through a problem space of all things that could potentially cause this symptom. A novice could accidentally stumble onto the right solution to a tricky bug, or an expert could search a thousand other things and only get to the true cause after a long time. some "expert"! ; ) So while you're partly correct in saying "how long", you can't just put someone on the clock and say "if you find the bug in less than five minutes, you're hired". Ultimately, the only person who can truly evaluate a programmer's skill is another programmer, usually by watching the candidate go through this sort of debugging work. But yeah, broadly speaking, an experienced programmer can usually debug something more quickly than a novice can. On average. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Spacing conventions
Steve D'Aprano schreef op 28/09/2017 3:45: One of Raymond Hettinger's videos talks about writing beautiful Python code, and how slavishly obeying PEP 8 is not really productive. I'll try to find a link later and post it. That would be Raymond Hettinger - Beyond PEP 8 -- Best practices for beautiful intelligible code - PyCon 2015 https://www.youtube.com/watch?v=wf-BqAjZb8M probably. Or otherwise maybe Transforming Code into Beautiful, Idiomatic Python https://www.youtube.com/watch?v=OSGv2VnC0go Both very interesting, though I enjoyed the first one more. -- The saddest aspect of life right now is that science gathers knowledge faster than society gathers wisdom. -- Isaac Asimov Roel Schroeven -- https://mail.python.org/mailman/listinfo/python-list
Re: Beginners and experts (Batchelder blog post)
On Fri, Sep 29, 2017 at 5:45 AM, Bill wrote: > Paul Moore wrote: >> >> On 27 September 2017 at 17:41, leam hall wrote: >>> >>> Hehe...I've been trying to figure out how to phrase a question. Knowing >>> I'm >>> not the only one who gets frustrated really helps. >>> >>> I'm trying to learn to be a programmer. I can look at a book and read >>> basic >>> code in a few languages but it would be unfair to hire myself out as a >>> programmer. I'm just not yet worth what it costs to pay my bills. >> >> You're already ahead of the game in wanting to be useful, rather than >> just knowing the jargon :-) However, I've always found that the >> biggest asset a programmer can have is the simple willingness to >> learn. > > > I basically agree with what has been posted. I just wanted to mention a > couple things that separates beginners and non-beginners. One is "how long > it takes to identify and fix an error"--even a syntax error. And that is a > skill which is acquired with some practice, maybe more "some" than anyone > likes. Be careful with this one. For anything other than trivial errors (and even for some trivial errors), finding the bug is basically searching through a problem space of all things that could potentially cause this symptom. A novice could accidentally stumble onto the right solution to a tricky bug, or an expert could search a thousand other things and only get to the true cause after a long time. So while you're partly correct in saying "how long", you can't just put someone on the clock and say "if you find the bug in less than five minutes, you're hired". Ultimately, the only person who can truly evaluate a programmer's skill is another programmer, usually by watching the candidate go through this sort of debugging work. But yeah, broadly speaking, an experienced programmer can usually debug something more quickly than a novice can. On average. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Beginners and experts (Batchelder blog post)
Paul Moore wrote: On 27 September 2017 at 17:41, leam hall wrote: Hehe...I've been trying to figure out how to phrase a question. Knowing I'm not the only one who gets frustrated really helps. I'm trying to learn to be a programmer. I can look at a book and read basic code in a few languages but it would be unfair to hire myself out as a programmer. I'm just not yet worth what it costs to pay my bills. You're already ahead of the game in wanting to be useful, rather than just knowing the jargon :-) However, I've always found that the biggest asset a programmer can have is the simple willingness to learn. I basically agree with what has been posted. I just wanted to mention a couple things that separates beginners and non-beginners. One is "how long it takes to identify and fix an error"--even a syntax error. And that is a skill which is acquired with some practice, maybe more "some" than anyone likes. Another critical skill is the ability to write good documentation--from program requirements, on down. Another is to know what is means to "test". Another is to have some familiarity with the UML. Skills in 3 of these 4 area might be assisted by reading about software engineering. So after you have those skills, then, perhaps, you can think about "interviewing"--of course a degree will help. As always, your mileage may vary... It IS True that you don't have to wait until you "know everything"--most of use will never get there. -- https://mail.python.org/mailman/listinfo/python-list
Re: Beginners and experts (Batchelder blog post)
On 09/28/2017 04:15 AM, Paul Moore wrote: With Python, I'd say that an appreciation of the available libraries is key - both what's in the stdlib, and what's available from PyPI. That's not to say you should memorise the standard library, but rather cultivate an approach of "hmm, I'm pretty sure I remember there being a library for that" and going to look. The best way of getting this is to actually work with code - you can start with doing coding projects of your own (it's *always* a good exercise to have a problem that interests you, and work on coding it - no matter what it is, you'll learn more about understanding requirements, testing, bug fixing, and practical programming by working on a project you care about than you'll ever get reading books) and/or you can look at existing open source projects that you're interested in, and offer help (there's always a bug tracker, and typically some simpler items - and you'll learn a lot from interacting with a larger project). When I first started in Unix/Linux there was a group called SAGE. They had a list of tasks a system admin was expected to be able to do and they sorted the list by "Junior", "Senior", or somesuch. I started at the bottom of the list and worked my way up. One useful thing was to make a sorted list of commands in /usr/bin, /bin, /usr/sbin, and /sbin, and then read the first bit of the man page that showed what the command did. Fun stuff. Leam -- https://mail.python.org/mailman/listinfo/python-list
Re: auto installing dependencies with pip to run a python zip application ?
On 09/28/2017 09:40 AM, Paul Moore wrote: > Are you aware of pipsi? If you do `pipsi install somepackage` it > creates a new virtualenv in ~/.local/.venvs, populates it with > somepackage and its dependencies, and then puts the entry point > scripts for somepackage into ~/.local/bin. It may be a useful way of > delivering your program, rather than building the virtualenv > management in yourself. No I wasn't aware of this tool, thanks for sharing. It's not what I am looking for but it's always nice to know of some alternatives Irmen -- https://mail.python.org/mailman/listinfo/python-list
Re: Beginners and experts (Batchelder blog post)
On 09/28/2017 07:35 AM, Stefan Ram wrote: But remember that paid programmers usually do not "code", in the sense of "write a program from scratch". Most of the work is maintenance programming, where an important part of the job is to read and understand a piece of code. Coding from scratch also happens, it just less common. (So that would be a reasonable interview test: Being able to understand a piece of given code and do some requested modification to it.) Another Perl story. I used to love Perl and then got to the point where trying to code in it made me physically nauseous. Not sure why. Guy had written a perl based time tracker for our contractor team. We'd enter tasks done and it would give a text based output to send to mgmt. Of course the guy hadn't planned on leaving after a few months and his program stored data by date but didn't separate by year. So I had to go figure out what it was doing since he was using a perl specific data archiver. Eventually just wound up blowing away the data store so each year was new. Told others how to handle it as I didn't want to do more perl and wasn't good enough at anything to replicate it all myself. Leam -- https://mail.python.org/mailman/listinfo/python-list
Re: Beginners and experts (Batchelder blog post)
My question has received several helpful responses, thanks!
On 09/28/2017 01:01 PM, Dennis Lee Bieber wrote:
On Wed, 27 Sep 2017 12:41:24 -0400, leam hall
declaimed the following:
"Programmer"... or "Software Engineer"?
I haven't kept up on "job titles" but for my history, "programmer" is
an entry level position, just a few steps up from "data entry operator"
(aka "keypunch operator" -- to show my age)
"Person who automates routine tasks".
I used to get asked for MAC addresses. I was playing with TCL at the
time and it had a built in webserver sort of thing. The boxes were
Solaris. Made a cron job to run Explorer on the servers and another to
collate them to a node with the TCL webserver. Gave the Network team the
URL.
I'll show my age; 5 bit ASCII punched tape and actual ferrite core
memory. :P
As a "programmer" (in my archaic world): be fluent in the language and
core of the runtime (though perhaps not a master -- I still don't get
Python's decorators and meta-class concepts; my uses haven't needed them).
Be able to read language agnostic requirement/design documentation and
translate to the language in question. At this level, knowledge of the
problem domain is probably not needed. At the higher levels, the language
begins to be irrelevant, but more knowledge of the problem domain becomes
important -- the difference between designing/coding a web-based
store-front (HTTP/HTML, database, security) vs number-crunching image
streams from space probes...
Afraid I've likely just tossed it back to you -- what really is your
goal?
As an introvert with a speech impediment I live by "Don't call me, I
won't call you."
Well, okay, yes. I did to Toastmasters and can shine at an interview.
Still, day to day I prefer to create solutions that solve problems and
answer questions before they are asked so no one asks me. I know a
little Networking, Database, Systems Engineering, Project Management,
Security, large datacenter, and other cool buzzwords to easily find a
job doing Linux system admin. What I want to move away from is doing now
what I was doing 10-15 years ago.
A couple years ago I was back into C. A RHEL bug came up and management
needed to understand the severity of the issue. I was able to read the
reports, dig through the kernel code, and explain the issues and risks
to MBA and PM types. I'm not about to represent myself as a C programmer
but I can follow #include files.
One place brought on Unix people and your first day was split between
the Eng team lead and the Ops team lead. They would decide which you
were more suited for. The Eng team lead wrote Perl and asked me to
explain some of their code. I did and also pointed out a bug. Seems I
was a better fit for the Ops team. :P
My short term goals are to use Python to get better at OOP coding and to
automate in Python stuff that might work in shell/awk but are more fun
in python. To that end I'm reading Booch, just ordered an old copy of
the Python Cookbook, and am coding a game/fiction tool to help me keep
track of characters.
It is often said to learn a language you grab the basics and then join a
project. I'm happy to contribute to open source projects but the
learning curve to "useful" has always been steep for me. There's gap
between reading "Learning {language}" and contributing code.
Python is very useful because all my RHEL boxes have it installed. If I
build a tool I know it will be able to run. While I enjoy Ruby more,
it's not on the servers and it ain't going on the servers. I need to be
useful to keep getting paid. Due to developer count the ability to
instigate a python project is easier than a non-rails ruby project so I
can build my "software engineering team" skills as well.
I appreciate your guidance and feedback; keep it coming!
Leam
--
https://mail.python.org/mailman/listinfo/python-list
Re: Hatch - A modern project, package, and virtual env manager
Hatch 0.20.0 features easy cross-platform Conda installation and interactive project creation! https://github.com/ofek/hatch/blob/master/HISTORY.rst#0200 -- https://mail.python.org/mailman/listinfo/python-list
Re: Real Programmers Write Docs
On 09/27/2017 04:15 PM, Ned Batchelder wrote: On 9/27/17 6:55 PM, Rob Gaddi wrote: Anyone have any good references on using Sphinx to generate a mix of autogenerated API docs and hand-written "Yeah, but this is what you DO with it" docs? Free is good but I'm happy to drop money on books if they're worthwhile. I can offer you an example: the coverage.py docs are in Sphinx, and use both auto-generated and hand-written pages: https://github.com/nedbat/coveragepy/tree/master/doc I'm not sure what information you are looking for, maybe this will help? --Ned. Helps quite a bit, thanks Ned. Basically I'm looking for a good example on structuring this sort of thing to keep it from spiraling out of control. Looks like the big trick is to rely on hand-written structure around autoclass calls rather than letting automodule generate big walls of text. PySerial was my other example, and has gone much the same route. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix. -- https://mail.python.org/mailman/listinfo/python-list
Re: EuroPython 2017: Videos for Monday available online
On 28.09.2017 18:25, M.-A. Lemburg wrote: > On 28.09.2017 18:11, Terry Reedy wrote: >> On 9/28/2017 8:15 AM, M.-A. Lemburg wrote: >>> We are pleased to announce the first batch of cut videos for EuroPython >>> 2017. >>> >>> To see the videos, please head over to our EuroPython YouTube channel >>> and select the “EuroPython 2017″ playlist: >>> >>> >>> * EuroPython 2017 Videos * >>> >>> http://europython.tv/ >> >> Mark-Andre, I clicked the link, which forwards to >> https://www.youtube.com/c/EuroPythonConference >> and clicked the EuroPython 2017 playlist, and 90% of the 163 videos are >> unviewable [Private video]s. > > Yes... we will publish them one conference day at a time over next > few weeks :-) > > """ > In the coming weeks, we will release the other videos, in batches of > one conference day per week. > """ > > Perhaps we ought to remove them from the playlist to not cause > confusion. This doesn't appear to be easily possible due to changes in the YT UI. We've now set the playlist order to show the private videos at the end as work-around. Next time, we'll add the video only when releasing them. Thanks, -- Marc-Andre Lemburg EuroPython Society Chair http://www.europython-society.org/ http://www.malemburg.com/ -- https://mail.python.org/mailman/listinfo/python-list
Re: EuroPython 2017: Videos for Monday available online
On 28.09.2017 18:11, Terry Reedy wrote: > On 9/28/2017 8:15 AM, M.-A. Lemburg wrote: >> We are pleased to announce the first batch of cut videos for EuroPython >> 2017. >> >> To see the videos, please head over to our EuroPython YouTube channel >> and select the “EuroPython 2017″ playlist: >> >> >> * EuroPython 2017 Videos * >> >> http://europython.tv/ > > Mark-Andre, I clicked the link, which forwards to > https://www.youtube.com/c/EuroPythonConference > and clicked the EuroPython 2017 playlist, and 90% of the 163 videos are > unviewable [Private video]s. Yes... we will publish them one conference day at a time over next few weeks :-) """ In the coming weeks, we will release the other videos, in batches of one conference day per week. """ Perhaps we ought to remove them from the playlist to not cause confusion. Thanks, -- Marc-Andre Lemburg EuroPython Society Chair http://www.europython-society.org/ http://www.malemburg.com/ -- https://mail.python.org/mailman/listinfo/python-list
Re: EuroPython 2017: Videos for Monday available online
On 9/28/2017 8:15 AM, M.-A. Lemburg wrote: We are pleased to announce the first batch of cut videos for EuroPython 2017. To see the videos, please head over to our EuroPython YouTube channel and select the “EuroPython 2017″ playlist: * EuroPython 2017 Videos * http://europython.tv/ Mark-Andre, I clicked the link, which forwards to https://www.youtube.com/c/EuroPythonConference and clicked the EuroPython 2017 playlist, and 90% of the 163 videos are unviewable [Private video]s. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Beginners and experts (Batchelder blog post)
On 2017-09-28, bartc wrote: > On 28/09/2017 12:31, Steve D'Aprano wrote: >> Until now, I thought that people who wrote crappy code did so >> because they didn't know any better. This is the first time >> I've seen somebody state publicly that they have no interest >> in writing clean code. > > I meant I have no interest in reading books about it or someone > else's opinion. I have my own ideas of what is clean code and > what isn't. The world contains many programmers with more experience than one's-self, and some of them are good at explaining what they know in a comprehensible and entertaining way. I believe you will benefit from and even enjoy some of the literature. Here's a recent favorite: "The Pragmatic Programmer", Andrew Hunt and David Thomas. ISBN-13: 978-0201616224 -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: Beginners and experts (Batchelder blog post)
On 28/09/2017 12:31, Steve D'Aprano wrote: On Thu, 28 Sep 2017 09:12 pm, bartc wrote: And I have little interest in most of this lot (my eyes glaze over just reading some of these): > - how to use operating systems You've never used a system call? Written to a file? Moved the mouse? Wasn't that more this option: - how to program operating systems via system calls Which was in my first group. Using an OS, I just do the minimum necessary and don't get involved in much else. (In my first phase as a programmer, there were personnel whose job it was to do that. In the next phase, with microprocessors, there /was/ no operating system! Bliss. That phase didn't last long, but fortunately those OSes (MSDOS and the like) didn't do much so didn't get in the way either.) > - how to use an editor well (e.g., vim or emacs) You have no interest in using your editor well? I use my own editor as much as possible. That doesn't have any elaborate features that it is necessary to 'learn'. > - style (e.g. "Clean Code" by Robert Martin, pep 8, ...) Until now, I thought that people who wrote crappy code did so because they didn't know any better. This is the first time I've seen somebody state publicly that they have no interest in writing clean code. I meant I have no interest in reading books about it or someone else's opinion. I have my own ideas of what is clean code and what isn't. > - test (e.g., unit test), TDD You don't test your code? I assume this meant formal methods of testing. I suppose that makes it a lot easier to program. Just mash down on the keyboard with both hands, and say that the code is done and working correctly, and move on to the next project. *wink* Actually I used to like using random methods (Monte Carlo) to solve problems. That doesn't scale well however, at some point you have to properly think through a solution. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Beginners and experts (Batchelder blog post)
On Wed, 27 Sep 2017 18:18:10 -0700, Larry Hudson wrote: > On 09/27/2017 09:41 AM, leam hall wrote: >> On Sat, Sep 23, 2017 at 5:26 PM, Ned Batchelder >> wrote: > [snip] >> >> The question is, what should a person "know" when hiring out as a >> programmer? What is 'know" and what should be "known"? Specifically >> with Python. >> >> > Hopefully NOT like this person... > (Source: http://rinkworks.com/stupid/cs_misc.shtml There is no direct > link to this item, it's about 2/3 the way down in a long web page...) > > > Since I teach nights at a local community college, I get a lot of > professional programmers in my classes upgrading their education. One > student, who was one such person, attended every lecture and smiled and > nodded and took notes. But he only turned in his first assignment. The > results of his first test were horrid. Out of curiosity, I asked my > wife, who barely knew how to turn a computer on much less program one, > to take the test (which was mostly true/false and multiple choice > questions). My wife scored higher than this guy. > > The semester's end came, and he flubbed his final, too. A few weeks > later, I got a call from him complaining about his 'F'. I pointed out he > hadn't turned in any of his assignments, and those counted 75% of the > grade. > > "Did you hear me say something besides what the other students heard?" I > asked. > > "Well, I thought my test grades would carry me," he replied. > > It had turned out his company had paid for him to take the course. Since > he failed, it suddenly came to the attention of his employer that he > didn't know how to program, and now his job was in jeopardy. As I hung > up the phone, I mused that his company shouldn't fire him. It was a > perfect match: a programmer who couldn't program and a company that > couldn't figure out sooner that he couldn't. > the whole page seems to be full of "look how dumb this user is because they do no automatically know things that I had to learn" -- After they got rid of capital punishment, they had to hang twice as many people as before. -- https://mail.python.org/mailman/listinfo/python-list
EuroPython 2017: Videos for Monday available online
We are pleased to announce the first batch of cut videos for EuroPython 2017. To see the videos, please head over to our EuroPython YouTube channel and select the “EuroPython 2017″ playlist: * EuroPython 2017 Videos * http://europython.tv/ You'll also find our brand new teaser video for the conference: https://www.youtube.com/watch?v=OCHrzW-R3QI In the coming weeks, we will release the other videos, in batches of one conference day per week. Enjoy, -- EuroPython 2017 Team http://ep2017.europython.eu/ http://www.europython-society.org/ PS: Please forward or retweet to help us reach all interested parties: https://twitter.com/europython/status/913375334950690816 Thanks. -- https://mail.python.org/mailman/listinfo/python-list
OT: Drain specialist Was: Beginners and experts
On 2017-09-28, Dan Sommers wrote: > If I'm hiring myself out as a plumber, I should know how to unclog > drains; OT: I recommend hiring a drain specialist, *not* a plumber for this particular job. Asking a plumber to clear a drain would be kinda like hiring a whiz-bang C programmer to configure your email server--it isn't that he or she *can't* do it... -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: Printing a Chunk Of Words
On 26/09/2017 01:15, Cai Gengyang wrote:
"""
Boolean Operators
True and True is True
True and False is False
False and True is False
False and False is False
True or True is True
True or False is True
False or True is True
False or False is False
Not True is False
Not False is True
"""
If I simply want to print a chunk of words and a paragraph like the above, what
command should I use ?
If you are looking for quiet mode code I suggest you stick to the answer
given by Chris Angelico earlier.
If you want verbose aka Steven D'Aprano :) mode code how about:-
from operator import and_, or_
from itertools import product
print('''
Boolean Operators
''', end='')
l = {and_: 'and', or_: 'or'}
bools = (True, False)
for logic in (and_, or_):
for a, b in product(bools, repeat=2):
ans = logic(a, b)
print(f'{a} {l[logic]} {b} is {ans}')
print()
for b in bools:
print(f'Not {b} is {not b}')
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
---
This email has been checked for viruses by AVG.
http://www.avg.com
--
https://mail.python.org/mailman/listinfo/python-list
Re: Boolean Expressions
On Wed, Sep 27, 2017 at 5:21 AM, Cai Gengyang wrote: > On Wednesday, September 27, 2017 at 1:01:50 PM UTC+8, Cameron Simpson > wrote: > > On 26Sep2017 20:55, Cai Gengyang wrote: > > >On Wednesday, September 27, 2017 at 6:45:00 AM UTC+8, Cameron Simpson > wrote: > > >> On 26Sep2017 14:43, Cai Gengyang wrote: > > >> >C) Set bool_three equal to the result of > > >> >19 % 4 != 300 / 10 / 10 and False > > >> > > > >> 19 % 4 = 3 which is equal to 300 / 10 / 10 = 3, hence the first term > is > > >> False. Entire expression is then equal to True, because False and > False = > > >> True > > >> > > >> Entire expression is False because the left hand side is False. > > > > > >Am I missing something here ? 19 % 4 = 19 modulo 4 equals to 3 right ? > which > > >equals the right hand side , hence first term is True > > > > But the test is for "!=", not "==". So False. > > > > Cheers, > > Cameron Simpson (formerly c...@zip.com.au) > > Right ... I didn't see the ' =! ' > -- > You didn't see the '!=' -- Joel Goldstick http://joelgoldstick.com/blog http://cc-baseballstats.info/stats/birthdays -- https://mail.python.org/mailman/listinfo/python-list
Re: Beginners and experts (Batchelder blog post)
On Thu, 28 Sep 2017 09:12 pm, bartc wrote: > And I have little interest in most of this lot (my eyes glaze over just > reading some of these): > > > - how to use operating systems You've never used a system call? Written to a file? Moved the mouse? > > - how to use an editor well (e.g., vim or emacs) You have no interest in using your editor well? > > - style (e.g. "Clean Code" by Robert Martin, pep 8, ...) Until now, I thought that people who wrote crappy code did so because they didn't know any better. This is the first time I've seen somebody state publicly that they have no interest in writing clean code. > > - test (e.g., unit test), TDD You don't test your code? I suppose that makes it a lot easier to program. Just mash down on the keyboard with both hands, and say that the code is done and working correctly, and move on to the next project. *wink* -- 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: Beginners and experts (Batchelder blog post)
On 28/09/2017 03:33, Stefan Ram wrote: Larry Hudson writes: Hopefully NOT like this person... Since I teach nights at a local community college a programmer who couldn't program It is not clear what »this person« refers to: Do you hope one is not like that teacher who publicly is shaming one of his students, though without actually giving the name of the student. Or do you hope one is not like that student who did not turn in the assignments? The fact that programmers can't program is known since the invention of the "FizzBuzz" programmer test. But in the case of the student, one actually can't know for sure whether he only had problems with the /upgrade/ of his education, but still can program in his everyday job. So, what was the question? Quoted from earlier in the same thread: |The question is, what should a person "know" when hiring out |as a programmer? What is 'know" and what should be "known"? |Specifically with Python. Some areas of knowledge follow, a programmer should not be ignorant in all of them: I can probably manage the following, even if I hate some of it or some might be advanced: - writing FizzBuzz - writing GUI software [My own] (Writing a GUI system or using one? I've done both and try and avoid GUI completely if possible.) - writing software to analyze text files - writing software to generate images from data - writing software to analyze images - how to program operating systems via system calls - algorithms and datastructures - numerical mathematics - how to write a recursive descent parser - maths (how to transform to polar coordinates or what the use of a fourier transformation is) And I have little interest in most of this lot (my eyes glaze over just reading some of these): > - writing GUI software [Other people's] > - writing software to analyze data bases > - writing user interfaces for data bases > - how to use operating systems > - how to administer a computer > - how to use the command languages of operating systems > - how to use an editor well (e.g., vim or emacs) > - how to use UN*X tools (grep, uniq, sed, ...) > - regular expressions > - a source management tool (like git) > - design patterns > - design by contract > - OOA/OOD > - the most important libraries for Python (standard and other) > - data base design / normalization > - style (e.g. "Clean Code" by Robert Martin, pep 8, ...) > - refactors > - software engineering > - being able to read and write EBNF > - software-project managemet (e.g. Agile, "Scrum") > - computer science (complexity, NP, grammars, ...) > - test (e.g., unit test), TDD > - programming interviews (there are many books about this topic!) > - Using a real Newsreader (not Google Groups) > - common algorithms/heuristics for global optimization > - common types of statistical analyses and neural networks It seems the first group is more pure coding (and fun, a lot of it), and the second is the usual lot of tools and technologies that programmers seems to have to know about these days (and not so much fun). -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: None is None but not working
Thank you it was data["RaceDay"] that was needed.
ata = r.json()
if data["RaceDay"] is None:
print("Nothing here")
else:
print(data["RaceDay"])
Nothing here
Nothing here
Nothing here
{'MeetingDate': '2017-01-11T00:00:00', .
Thanks
Sayth
--
https://mail.python.org/mailman/listinfo/python-list
Re: Spacing conventions
On 28 September 2017 at 06:56, Bill wrote: > Steve D'Aprano wrote: >> >> >> Similarly for break and continue. >> >>> I can still see their >>> use causing potential trouble in (really-long) real-world code. >> >> How so? >> >> Besides, if your code is "really long", you probably should factorise it >> into >> smaller, meaningful chunks. >> > > I worked in maintenance programming. You got the hand you were dealt! And > you weren't allowed to "improve" the code unless the customer contracted you > to do so. I maintained for-loops (containing for-loops)... hundreds of > lines long. Would you be searching for break or > continue? : ) I also work in maintenance. Agreed 100% that the sort of code you deal with is a nightmare. But the problem with that code is *not* break/continue, but the lack of structure and the fact that the code isn't properly broken into meaningful subunits. I'd rather not search for break/continue in such code, sure, but that's missing the point entirely. "Don't use break/continue in appallingly bad code" doesn't generalise to "don't use break/continue", but rather to "don't write appallingly bad code" :-) Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Beginners and experts (Batchelder blog post)
On 27 September 2017 at 17:41, leam hall wrote: > Hehe...I've been trying to figure out how to phrase a question. Knowing I'm > not the only one who gets frustrated really helps. > > I'm trying to learn to be a programmer. I can look at a book and read basic > code in a few languages but it would be unfair to hire myself out as a > programmer. I'm just not yet worth what it costs to pay my bills. You're already ahead of the game in wanting to be useful, rather than just knowing the jargon :-) However, I've always found that the biggest asset a programmer can have is the simple willingness to learn. "Programming" is far too broad a subject for anyone to know all about it, so being able (and willing!) to find things out, to look for and follow good practices, and to keep learning, is far more important than knowing the specifics of how to code a class definition. Most programmers work in teams, so you will likely be working with an existing code base for reference (even if you're not doing actual maintenance coding), so you'll have examples to work from anyway. > To move forward takes a plan and time bound goals. At least for us old > folks; we only have so much time left. I want to avoid retirement and just > work well until I keel over. > > I don't come from a CS background but as a Linux sysadmin. My current push > is OOP. Grady Booch's book on Analysis and Design is great and I've got the > GoF for right after that. I've been doing more testing but need to write > more tests. Writing code and starting to work with others on that code as > well. I haven't read Booch, but I've heard good things about it. The GoF is good, but a lot of the problem's it's addressing aren't really issues in Python. So be prepared to find that the solutions look a bit over-engineered from a Python perspective. The ideas are really useful, though. Keep in mind that in Python, OOP is just one option of many - it's a very useful approach for many problems, but it's not as all-embracing as people with a Java or C# background imply. In particular, Python uses a lot less subclassing than those languages (because duck typing is often more flexible). > The question is, what should a person "know" when hiring out as a > programmer? What is 'know" and what should be "known"? Specifically with > Python. With Python, I'd say that an appreciation of the available libraries is key - both what's in the stdlib, and what's available from PyPI. That's not to say you should memorise the standard library, but rather cultivate an approach of "hmm, I'm pretty sure I remember there being a library for that" and going to look. The best way of getting this is to actually work with code - you can start with doing coding projects of your own (it's *always* a good exercise to have a problem that interests you, and work on coding it - no matter what it is, you'll learn more about understanding requirements, testing, bug fixing, and practical programming by working on a project you care about than you'll ever get reading books) and/or you can look at existing open source projects that you're interested in, and offer help (there's always a bug tracker, and typically some simpler items - and you'll learn a lot from interacting with a larger project). Hope this helps, Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: auto installing dependencies with pip to run a python zip application ?
Are you aware of pipsi? If you do `pipsi install somepackage` it creates a new virtualenv in ~/.local/.venvs, populates it with somepackage and its dependencies, and then puts the entry point scripts for somepackage into ~/.local/bin. It may be a useful way of delivering your program, rather than building the virtualenv management in yourself. (On the other hand "download this file and run it" is a much easier installation process than "install pipsi, do pipsi install myprogram, then run the program", so it may not suit your use case...) Paul On 27 September 2017 at 19:03, Irmen de Jong wrote: > On 09/27/2017 09:50 AM, Paul Moore wrote: > What you could do is pip install your binary dependencies into a directory in $TEMP using --target, then add that directory to sys.path. Probably easier than building a full virtualenv. Bundle pip with your app if you can't assume your users will have pip available. >>> >>> Interesting idea, although like this wouldn't I have to download the >>> dependencies every time I launch my game? (unless I re-use the same >>> temporary directory every time) >> >> Ah, I'd assumed that's what you were doing with the virtualenv, I >> hadn't realised you were talking about a one-off setup step. Yeah, >> re-using a temporary directory doesn't buy you much compared to using >> a virtualenv (particularly if you can target versions of Python that >> have the built in venv module). > > Well, I was planning on using a fixed name/location for the virtualenv. > That way when you request pip to install the dependencies again at next > launch, it will detect them already satisfied and not download/reinstall > everything. I could even test for their existence first myself in my > application (which is what I'm already doing now, to give the user a > clear error message) and only invoke pip when a dependency is missing. > > > -irmen > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
