modifying images in a pdf file
I'd like to modify some images in pdf files -- specifically, extract the image, process it to give it a comic strip type of coloring (using pillow), and then put it back. I see there are several pdf libraries, but a cursory examination did not reveal which, if any, had a method for extraction and replacement of embedded images. Has anyone had experience with this, or can point me in the right direction? Thanks! -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: comapring 2 sequences of DNA ouput the silent and non mutations
Disha, Before you struggle to reinvent the wheel, you might want to check out the Biopython package. http://biopython.org/wiki/Biopython I haven't used it for a few years, but the version that I did use was very comprehensive. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
On 10/29/2016 06:16 PM, BartC wrote: > An editor is either line-oriented or it isn't. Free-flowing English text > usually isn't, but most program code is. And a line-oriented editor > should have hard stops at the line ends. (IMO which apparently isn't > shared by anyone else on the planet.) ViM appears to be line-oriented, which makes sense given its ed heritage. Cursor movement will only get you to the end of the line and won't wrap around to the next line. So it seems that ViM works much as you prefer, except that you probably don't like the two modes in ViM. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
On 29/10/2016 23:21, Dennis Lee Bieber wrote: On Sat, 29 Oct 2016 22:11:31 +0100, BartC declaimed the following: (Non-line-oriented would mean it just keeps sitting there until it's read three values, damn it, no matter how many times you press Enter, and it's not going to shift until it has them! In other words, user-unfriendly. There are those of us who, if we were given a prompt that said enter three values, would want it to take three values regardless of how many blank lines you enter. Such behaviour can be programmed if it is useful for the input to be free-format where N items of input can be spread over any number of lines. But it's not a good idea where line ends are meaningful (eg. marking the end of some input), or it is necessary to stay synchronised with line beginnings. An example of such input is the command prompt in console and terminal windows. If I want to enter type 'python program.py' then it will end badly if I enter is as: >> python program.py on two lines. This is related to my big bug-bear with most text editors where keys such as left, right, backspace and delete don't stop at the ends of a line but keep going to previous or next lines.) DEC SOS died off in the early 80s. But VI might make you happy... Not sure about VIM (VI IMproved). An editor is either line-oriented or it isn't. Free-flowing English text usually isn't, but most program code is. And a line-oriented editor should have hard stops at the line ends. (IMO which apparently isn't shared by anyone else on the planet.) (Not sure what the reference to SOS means. That was a TTY editor which didn't have navigation that I recall, while backspace and delete didn't really work on printed display.) -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: comapring 2 sequences of DNA ouput the silent and non mutations
On 2016-10-29 20:38, dishaachary...@gmail.com wrote:
Code:
A = 0
B= 0
i=0
j=0
# opening the files
infile1 = open("CDSsrebf1.txt")
infile2 = open("PROsrebf1.txt")
infile3 = open("mutant.txt")
print(" 1st line of WT SREBF1 (CDS):",infile1.readline())
print ("1st line of mutant protein of SREBF1: ", infile3.readline())
print ("1st line of protein of SREBF1: ",infile2.readline())
# -
# reading the nucleotide sequence for WT SREBF1
seq1 = infile1.read()
seq1 = seq1.replace('\n', '')
len1 = len(seq1)
#
# reading the mutant file
mutant = infile3.read()
mutant = mutant.replace('\n', '')
#---
# reading the protein file
# which is used to check our codon dictionary
wtPRO = infile2.read()
wtPRO = wtPRO.replace('\n', '')
#-
# setting up the dictionary
letters = ('G', 'A', 'C', 'T')
codes = []
for a in letters :
for b in letters :
for c in letters :
codes.append(a + b + c)
aa = 'eeddrrsskknnmiiiqqhhwxccxxyyllff'
aa = aa.upper()
codons = {}
for i in range(64) :
codons[codes[i]] = aa[i]
#--
# making the protein from the WT SREBF1, which is seq1
protein = ''
for i in range(0, len(seq1), 3) :
codon = seq1[i:i+3]
aminoacid = codons[codon]
protein += aminoacid
# ---
# making the protein from the mutant SREBF1, which is mutant
mutantPRO = ''
for i in range(0, len(mutant), 3) :
codon = mutant[i:i+3]
aminoacid = codons[codon]
mutantPRO += aminoacid
# --
# quick check if WT and mutant are the same for the protein
if protein == mutantPRO :
print ('The protein sequences are the same.')
else :
print ('The protein sequences are different.')
#
# Printing the differences in the format XiY
# which means WT amino acid X at position i changed to mutant amino acid Y
print ('-')
print ('The mutations are:')
for i in range (len(protein) & len(seq1)) :
if protein[i] != mutantPRO[i] :
print (protein[i] + str(i) + mutantPRO[i])
A+= 1
else:
if seq1[i:i+3] != mutant[i:i+3]:
print(protein[i] + str(i) + mutantPRO[i] +' Silent
mutation ')
print(seq1[i:i+3] + mutant[i:i+3])
B+= 1
print("Number of non-silent mutations are: ",A)
print("Number of silent mutations are: " , B)
output
should be The mutations are:
M0I
D1D silent mutation C5T
V291L
I dont know what to print the C5T part
Thank you for helping me!
I don't understand what the expression "len(protein) & len(seq1)" is
supposed to be doing. It's a bitwise 'and' of the lengths, which just
looks wrong!
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
On Tuesday, October 25, 2016 at 11:02:47 AM UTC+1, BartC wrote:
> On 25/10/2016 07:39, Steven D'Aprano wrote:
>
> >> I gather that non-blocking keyboard input functions aren't the easiest
> >> thing
> >> to implement. They seem to depend on the operating system. Still, ease of
> >> use is a primary goal of Python, and the need for this feature must be
> >> common.
> >
> >
> > Not really. I think that lots of people think they need it, but once they
> > write
> > a little utility, they often realise that it's not that useful.
>
> > If you (generic you, not you specifically) are telling the user "press any
> > key
> > to continue", then you probably shouldn't. *Any* key may not do anything.
> > E.g.
> > if the user hits the Shift key. A much better interface is to specify a
> > specific key, and ignore anything else... in which case, why not specify the
> > Enter key?
> >
> > raw_input('Press the Enter key to continue... ')
>
> Which doesn't work on Python 3. So even here, making it easy by using
> line-input, it's not so straightforward.
>
Just get this http://pythonhosted.org/six/ or similar.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
On 29/10/2016 17:27, Dennis Lee Bieber wrote:
On Sat, 29 Oct 2016 15:32:16 +0100, BartC declaimed the
following:
I still think a beginner would much prefer something along the lines of
'readln a,b,c' (and I still think that's more intuitive).
Then I would suggest using something like REXX or a K&K-based BASIC (I
have no idea, of the top of my head, what Visual BASIC uses).
In REXX, everything is considered a string until it needs to be a
numeric type. And old BASIC would require one to put a data type code on
the variable name which would control the input parsing.
-=-=-=-=-
/* */
say "Enter three integers"
parse pull a b c
That could be workable if it was line-oriented. I strongly suspect it
isn't, because C isn't, and C seems to have lot of influence.
(Non-line-oriented would mean it just keeps sitting there until it's
read three values, damn it, no matter how many times you press Enter,
and it's not going to shift until it has them! In other words,
user-unfriendly.
This is related to my big bug-bear with most text editors where keys
such as left, right, backspace and delete don't stop at the ends of a
line but keep going to previous or next lines.)
The parse command has lots of fancy options allowing for defining fixed
column positions
parse pull 0 a 5 b 8 c
parse pull 5 a 0 b "5" 4 c "9"
That's easy string processing, you don't really need i/o system support:
get the whole line as a string then slice it for the various fields.
For many years, FORTRAN couldn't even handle variable width input from
the keyboard.
READ(5, 1100, END=50, ERR=100) A, B, C
1100FORMAT("I8, X, I8, X, I8")
I spent a year writing interactive Fortran IV, I'm fairly sure it was
possible but I couldn't tell you how.
Ada.Text_IO.Put ("Enter three integers => ");
Ada.Integer_Text_IO.Get (A);
Ada.Integer_Text_IO.Get (B);
Ada.Integer_Text_IO.Get (C);
I admire Ada in many ways, but this ...
When reading name, file and string items rather than integers, the split
method doesn't deal with embedded quotes. Probably there are bigger guns
you can bring out to deal with more elaborate input, but it starts to
get further away from beginner level.)
Typically, if doing interactive input, you ask for ONE item at a time,
and accept the entire line as the response.
You can't really draw the line like that. This sort of input can used
for live input from a keyboard, from an input file, or a input file
redirected so that it appears to come from the keyboard.
So embedded quotes aren't a
problem. OR you do your own parsing on the line if multiple items are
expected, only reading more from the console when you've run out of data.
Ad hoc parsing of user input is going to be difficult in any language.
But you wouldn't use this for that. I'd use these 'readln' methods for
reading formatted text files; I showed a PPM header example; for
text-mode images, 'read' can also be used.
Then there are text configuration files, or project description files,
or files contain lists of 3D data, or comma- or tab-separated data
files, simple command scripts
There is a huge range of possible uses for a crude read/readln feature
where verification at the i/o level is not really necessary. (If the
width, image values of a PPM out of range, then you check that at the
application level.)
Anything that is not line-oriented, or that needs very precise parsing
such as code, would just use a different approach.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
comapring 2 sequences of DNA ouput the silent and non mutations
Code:
A = 0
B= 0
i=0
j=0
# opening the files
infile1 = open("CDSsrebf1.txt")
infile2 = open("PROsrebf1.txt")
infile3 = open("mutant.txt")
print(" 1st line of WT SREBF1 (CDS):",infile1.readline())
print ("1st line of mutant protein of SREBF1: ", infile3.readline())
print ("1st line of protein of SREBF1: ",infile2.readline())
# -
# reading the nucleotide sequence for WT SREBF1
seq1 = infile1.read()
seq1 = seq1.replace('\n', '')
len1 = len(seq1)
#
# reading the mutant file
mutant = infile3.read()
mutant = mutant.replace('\n', '')
#---
# reading the protein file
# which is used to check our codon dictionary
wtPRO = infile2.read()
wtPRO = wtPRO.replace('\n', '')
#-
# setting up the dictionary
letters = ('G', 'A', 'C', 'T')
codes = []
for a in letters :
for b in letters :
for c in letters :
codes.append(a + b + c)
aa = 'eeddrrsskknnmiiiqqhhwxccxxyyllff'
aa = aa.upper()
codons = {}
for i in range(64) :
codons[codes[i]] = aa[i]
#--
# making the protein from the WT SREBF1, which is seq1
protein = ''
for i in range(0, len(seq1), 3) :
codon = seq1[i:i+3]
aminoacid = codons[codon]
protein += aminoacid
# ---
# making the protein from the mutant SREBF1, which is mutant
mutantPRO = ''
for i in range(0, len(mutant), 3) :
codon = mutant[i:i+3]
aminoacid = codons[codon]
mutantPRO += aminoacid
# --
# quick check if WT and mutant are the same for the protein
if protein == mutantPRO :
print ('The protein sequences are the same.')
else :
print ('The protein sequences are different.')
#
# Printing the differences in the format XiY
# which means WT amino acid X at position i changed to mutant amino acid Y
print ('-')
print ('The mutations are:')
for i in range (len(protein) & len(seq1)) :
if protein[i] != mutantPRO[i] :
print (protein[i] + str(i) + mutantPRO[i])
A+= 1
else:
if seq1[i:i+3] != mutant[i:i+3]:
print(protein[i] + str(i) + mutantPRO[i] +' Silent
mutation ')
print(seq1[i:i+3] + mutant[i:i+3])
B+= 1
print("Number of non-silent mutations are: ",A)
print("Number of silent mutations are: " , B)
output
should be The mutations are:
M0I
D1D silent mutation C5T
V291L
I dont know what to print the C5T part
Thank you for helping me!
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
On 29/10/2016 15:53, Chris Angelico wrote: On Sun, Oct 30, 2016 at 1:32 AM, BartC wrote: BTW the functionality of my 'readln a,b,c' differs from the above. Separators can be anything reasonable. When eol is encountered, it will read zeros. And errors are not handled: any non-numeric will yield zero. People will disagree as to what is "correct behaviour" in that kind of situation. If someone disagrees with Steve's function, s/he can write a different one. If someone disagrees with your language primitive s/he can write a different language? No, they use a function similar to Steve's. Or just tweak the code: read an item as a string instead of a number. Then its validity can checked. This sounds like another one of those arguments: there's no point in having a simple feature A, because it doesn't do X, Y and Z. So we won't have it. But do we instead have feature B that includes X, Y and Z? No, of course not! No matter that 90% of the time, X, Y and Z are never used... -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
On 29/10/2016 16:24, Steve D'Aprano wrote: On Sun, 30 Oct 2016 01:32 am, BartC wrote: (BTW the functionality of my 'readln a,b,c' differs from the above. Separators can be anything reasonable. When eol is encountered, it will read zeros. And errors are not handled: any non-numeric will yield zero. Ah, in other words it is a toy, utterly unsuitable for serious use by anyone who cares about data validity and error checking, only suitable for teaching bad habits to beginners. So, how does Python differ? From what I've seen, you have to /write/ the validation code (as I said in my last post). ANY language can do that too! And the eol-handling behaviour is deliberate. If you want to read UP TO three numbers but only two are entered on a line, some languages will keep pestering you until you've entered that third number. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
Am 29.10.16 um 16:32 schrieb BartC: I still think a beginner would much prefer something along the lines of 'readln a,b,c' (and I still think that's more intuitive). (The first programming exercises I ever did involved typing in integers from the user, and sorting them or working out if they made a triangle or whatever. Yes, and that's exactly why they learn to produce such horrible interfaces which do not work for a serious program. Instead, teach them how to use the *environment* for I/O. That is, as a beginner put your function into a file, e.g. def is_triangle(a, b, c): if abs(a)+abs(b) > abs(c): print "Triangle!" else: print "Not a triangle" ..and then use IPython: %run triangle.py >>> is_triangle(1,1.7, 2) Triangle! >>> is_triangle(1,1.7, 8) Not a triangle >>> (I know the prog is incomplete, but that's not the point) This way you can concentrate on the algorithm and leave the I/O thing to python. Due to the built-in readline, you can recall previous arguments, edit them when you make mistakes, save the result (if there were any), much more than your readln function can accomplish. Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
On 29/10/2016 15:19, Steve D'Aprano wrote:
On Sat, 29 Oct 2016 10:53 pm, BartC wrote:
But I'd like to see Python running on a 64KB system
(Micropython doesn't count!).
Hmmm. So tell me... how do you expect Python to run on tiny systems by
*adding* new features?
Regardless of how "small" this feature is, it is not negative size. The
implementation is at least 1 byte. The documentation is at least 1 byte.
The tests are at least 1 byte. If you think Python is too big now, then
adding this feature will make it at least 3 bytes bigger.
The /effective/ size could well be negative! If someone really needs the
feature they might need to drag in 'curses' or require 'tkinter',
substantial add-ons even though they only need one minor feature.
print as a statement was always an anomaly, and yes, it got pretty weird:
print >>sys.stderr, spam, eggs
So much nicer now that it is a function that takes proper keyword arguments.
I guess ">>" is what I used "#" or "@" for. But what does it look like
in function form?
Functions are great for adding general-purpose utility but their syntax
is limited; sometimes dedicated syntax is better for things you use all
the time.
> What I said
looked weird was your syntax:
read a:"h", b:"r", c:"s"
If you're going to introduce special syntax for types, why make the types
strings rather than symbols?
(I can't remember where that came from. The colon syntax I think was
from Pascal. I used strings for the Print counterpart as there can be
other stuff in there: x:"z8hs'" might display x as "0001'E800".
Read formats could have been single unquoted characters I suppose (they
were once). But a string means the format can be dynamic: read a:fmt,b:fmt.
But this is a detail. The main thing is trivially just listing the
things you want to read in a similar manner to print.)
BTW what does reading three integers from the user look like in Python?
for i in range(3):
n = int(input(""))
OK, one per line. Just so each input line corresponds to exactly one
integer! (I can do this too but I write it as:
n := strtoval(sreadln()) # int default
x := strtoval(sreadln(),"r") # floating point ('real') )
You want a prompt? Change the empty string to your prompt.
You want to assign to three different variables? Unroll the loop:
n = int(input(""))
p = int(input(""))
q = int(input(""))
If the user types something that isn't an integer, you want to try again?
The idea of read and print statements, in my languages at least, are for
simple or throwaway programs, or when dealing with known file formats:
r := "r"
readln @file, x:r, y:r, z:r
It's not /meant/ to be sophisticated. Just convenient.
Write a loop. If you're sensible, of course you will put it into a helper
function:
_SENTINEL = object()
def read_int_with_all_the_trimmings(
prompt1='Enter an int: ',
prompt2='Invalid value for an int; please try again: ',
prompt3='Value out of range; please try again: ',
max_times=2**31,
low=None,
high=None,
default=_SENTINEL):
msg = prompt1
for attempt in range(max_times):
s = input(msg)
try:
n = int(s)
except ValueError:
msg = prompt2
else:
out_of_range = (low is not None and n < low) or (
high is not None and n > high)
if out_of_range:
msg = prompt3
else:
return n
if default is _SENTINEL:
raise ValueError('not a valid int')
return default
Does your `read` statement do all that? Why not?
I don't understand your point. No, it doesn't, but neither does Python
(it doesn't have 'read' for a start). You've had to write it; I can too.
And that example still reads one number per line!
Suppose you have to read a ppm file which might start like this:
P6
600 800
255
I can read this using 'read': (checking and comment-skipping code omitted):
readln @f, sig:"s"
readln @f, width, height
readln @f, maxpix
It doesn't need anything fancy and you don't want to bother with parsing
the input lines and converting text to numbers.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
On Sun, 30 Oct 2016 01:32 am, BartC wrote: > (BTW the functionality of my 'readln a,b,c' differs from the above. > Separators can be anything reasonable. When eol is encountered, it will > read zeros. And errors are not handled: any non-numeric will yield zero. Ah, in other words it is a toy, utterly unsuitable for serious use by anyone who cares about data validity and error checking, only suitable for teaching bad habits to beginners. -- 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: what does type(subprocess.Popen)== mean?
On Sun, 30 Oct 2016 01:55 am, oyster wrote: > why does not type(subprocess.Popen)==? Thanks Because Popen is not a module. Why do you expect it to be a module? py> type(int) py> type(float) py> type(str) py> class X(object): ... pass ... py> type(X) type(subprocess.Popen) > Popen is a class, also known as a "type". import os type(os.path) > os.path is a module, just like os. Inside the os module, you will find code that looks something like this: if the operating system is Windows: import ntpath as path elif the operating system is Unix: import posixpath as path else: import genericpath as path So os.path is a module. -- 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
EuroPython 2017 will be held in Rimini, Italy
After carefully reviewing all proposals we had received and intense discussions with the teams, the EuroPython Society (EPS) is happy to announce the decision to accept the proposal from the Italian on-site team, backed by the Python Italia APS, to hold EuroPython 2017 in Rimini, Italy. The EPS would like to thank all teams who have entered bids for our Call for Interest (CFI): * Python Italia APS: Milan/Como/Genoa/Rimini, Italy * The local Czech Python community: Brno, the Czech Republic * Python San Sebastian Society (ACPySS): Bilbao, Basque Country, Spain The conference will be held at the Rimini PalaCongressi in July 2017. The exact dates are still subject to negotiations with the venue. We’ll announce them as soon as they are finalized. Until then, here’s the official EuroPython 2017 URL for you to bookmark, where we’ll open up the website in January 2017: *** EuroPython 2017 Pre-launch Website *** http://ep2017.europython.eu/ Sponsoring EuroPython - Companies who would like to signup as EuroPython 2017 sponsor are encouraged to contact the sponsor workgroup at sponsor...@europython.eu. Until we have the 2017 sponsor brochure in place, please have a look at our 2016 brochure: https://ep2016.europython.eu/media/conference/sponsor/brochure/ep2016_sponsor_brochure.pdf We will be preparing the launch of the website in January 2017. If you’d like to sign up early as launch sponsor, please contact us in the next two months. As with the past conferences, we will try to make EuroPython 2017 as effective as possible for sponsors by offering more booth space and sponsors slots than ever before. This is your chance to reach out to more than 1.100 enthusiastic and highly motivated EuroPython attendees ! EuroPython Workgroups - Organizing a EuroPython event is a lot of work and with the workgroup concept, we have opened up much of the organization for remote participation. If you want to help, please apply for one or more workgroups which you feel match your interests and experience. If you’d like to help, but don’t have enough experience, yet are willing to learn, please apply as well. The application process is described on our workgroups page: http://www.europython-society.org/workgroups Enjoy, -- EuroPython Society http://www.europython-society.org/ -- https://mail.python.org/mailman/listinfo/python-list
what does type(subprocess.Popen)== mean?
why does not type(subprocess.Popen)==? Thanks [quote] Python 3.4.4 |Anaconda 2.3.0 (64-bit)| (default, Feb 16 2016, 09:54:04) [MSC v.1 600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import subprocess >>> type(subprocess.Popen) >>> import os >>> type(os.path) [/quote] -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
On Sun, Oct 30, 2016 at 1:32 AM, BartC wrote: > BTW the functionality of my 'readln a,b,c' differs from the above. > Separators can be anything reasonable. When eol is encountered, it will read > zeros. And errors are not handled: any non-numeric will yield zero. People will disagree as to what is "correct behaviour" in that kind of situation. If someone disagrees with Steve's function, s/he can write a different one. If someone disagrees with your language primitive s/he can write a different language? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
On 29/10/2016 14:51, Dennis Lee Bieber wrote:
On Sat, 29 Oct 2016 12:53:35 +0100, BartC declaimed the
following:
BTW what does reading three integers from the user look like in Python?
On one line, or on three lines?
(Python 2.7)
ln = raw_input("Enter three integers separated by spaces: ")
ints = []
for i, wd in enumerate(ln.split()):
try:
anInt = int(wd)
except: #yes, I know -- the horrible bare except clause
print ("* item %s: '%s' could not be converted to integer"
% (i, wd) )
anInt = None
ints.append(anInt)
Yes, that's the sort of thing I was expecting, that's why I asked.
I still think a beginner would much prefer something along the lines of
'readln a,b,c' (and I still think that's more intuitive).
(The first programming exercises I ever did involved typing in integers
from the user, and sorting them or working out if they made a triangle
or whatever.
But in Python someone would first need to master for-loops, enumeration,
string-processing, numeric conversion, exceptions and, your second
example, functions. That's quite a steep learning curve! (And that
second example starts to involve re-inventing things.)
(BTW the functionality of my 'readln a,b,c' differs from the above.
Separators can be anything reasonable. When eol is encountered, it will
read zeros. And errors are not handled: any non-numeric will yield zero.
When reading name, file and string items rather than integers, the split
method doesn't deal with embedded quotes. Probably there are bigger guns
you can bring out to deal with more elaborate input, but it starts to
get further away from beginner level.)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't Python include non-blocking keyboard input function?
On Sat, 29 Oct 2016 10:53 pm, BartC wrote:
> On 29/10/2016 02:04, Steve D'Aprano wrote:
>> On Fri, 28 Oct 2016 05:09 am, BartC wrote:
>
>>> For years I've had discussions in comp.lang.c about things that C should
>>> or should not have.
>
>> Bart, don't be naive. The C language isn't going to "acquire a slick new
>> enhancement" based on a few emails on compl.lang.c. C is an ISO-standard.
>> Stability of the language,
>
> C is a supposedly ultra-portable and apparently simple language.
I'm not sure if C *ever* was simple, but it certainly hasn't been simple for
the last quarter of a century.
The most recent version of the standard has a draft of 701 pages:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
The draft for the previous standard, C99, was 552 pages:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
See also:
http://www.open-std.org/jtc1/sc22/wg14/www/standards
http://stackoverflow.com/questions/81656/where-do-i-find-the-current-c-or-c-standard-documents
Here's a draft of ANSI C (C89):
http://flash-gordon.me.uk/ansi.c.txt
My browser formats that to 290 pages. So even in 1989, C was significantly
complex.
[...]
> The language and the way it's used have a few problems - why shouldn't
> someone talk about them?
Nobody is stopping you from discussing C's problems in the appropriate
forum. But unlike you and your hand-made compilers, with a user-base of
exactly 1 user (you), there are dozens of implementations of C, with tens
of thousands of users or more, and an ISO standard defining what is and
isn't C.
> the fact that you have a known set of
>> functionality, is precisely why it was made a standard in the first
>> place: to discourage the sort of "wouldn't it be cool if..." pile up of
>> features and bloat and ever-changing language specs.
>
> Most of the enhancements I talked about were trivial. The language is
> unlikely to change because of me but it would be nice for someone to
> acknowledge them rather than defend one of C's crazy quirks or lack of a
> feature to the death.
You won't get any defence of C's crazy quirks from me.
[...]
> But I'd like to see Python running on a 64KB system
> (Micropython doesn't count!).
Hmmm. So tell me... how do you expect Python to run on tiny systems by
*adding* new features?
Regardless of how "small" this feature is, it is not negative size. The
implementation is at least 1 byte. The documentation is at least 1 byte.
The tests are at least 1 byte. If you think Python is too big now, then
adding this feature will make it at least 3 bytes bigger.
>>> I think this came up when someone wanted to switch from Visual Basic to
>>> Python. The above is not a very sophisticated approach but it is very
>>> simple and intuitive.
>>
>> Intuitive to whom? To me, it just looks weird.
>
> 'read a,b,c' is weird and unintuitive compared with its counterpart
> 'print a,b,c'. OK
print as a statement was always an anomaly, and yes, it got pretty weird:
print >>sys.stderr, spam, eggs
So much nicer now that it is a function that takes proper keyword arguments.
In any case, I wasn't specifically talking about
read a, b, c
Yes, it is a bit (actually a lot) unusual to assign a value to a variable by
way of a statement other than assignment, it is not unprecedented in
Python. We have at least three other binding statements:
import name
for name in ...
del name
even though one of them is actually an *unbinding* statement. What I said
looked weird was your syntax:
read a:"h", b:"r", c:"s"
If you're going to introduce special syntax for types, why make the types
strings rather than symbols?
> BTW what does reading three integers from the user look like in Python?
for i in range(3):
n = int(input(""))
You want a prompt? Change the empty string to your prompt.
You want to assign to three different variables? Unroll the loop:
n = int(input(""))
p = int(input(""))
q = int(input(""))
If the user types something that isn't an integer, you want to try again?
Write a loop. If you're sensible, of course you will put it into a helper
function:
_SENTINEL = object()
def read_int_with_all_the_trimmings(
prompt1='Enter an int: ',
prompt2='Invalid value for an int; please try again: ',
prompt3='Value out of range; please try again: ',
max_times=2**31,
low=None,
high=None,
default=_SENTINEL):
msg = prompt1
for attempt in range(max_times):
s = input(msg)
try:
n = int(s)
except ValueError:
msg = prompt2
else:
out_of_range = (low is not None and n < low) or (
high is not None and n > high)
if out_of_range:
msg = prompt3
else:
return n
if default is _SENTINEL:
raise ValueError('not a valid int')
return default
Does your `read` statement do all that? Why not?
--
Steve
“C
Re: Why doesn't Python include non-blocking keyboard input function?
On 29/10/2016 02:04, Steve D'Aprano wrote: On Fri, 28 Oct 2016 05:09 am, BartC wrote: For years I've had discussions in comp.lang.c about things that C should or should not have. Bart, don't be naive. The C language isn't going to "acquire a slick new enhancement" based on a few emails on compl.lang.c. C is an ISO-standard. Stability of the language, C is a supposedly ultra-portable and apparently simple language. But take an application like CPython - you can't just grab the nearest C compiler and build it. You need to blindly run tens of thousands of lines of scripts and assorted utilities, and compile with /gcc/, and hope it works. And that's in Linux; on Windows it's different yet again. And take C compilers such as gcc and MSVC - they're monsters (how long would it take either of them to build itself? Now see below.) The language and the way it's used have a few problems - why shouldn't someone talk about them? the fact that you have a known set of functionality, is precisely why it was made a standard in the first place: to discourage the sort of "wouldn't it be cool if..." pile up of features and bloat and ever-changing language specs. Most of the enhancements I talked about were trivial. The language is unlikely to change because of me but it would be nice for someone to acknowledge them rather than defend one of C's crazy quirks or lack of a feature to the death. (I use my own implementation language in place of C, which fixes most of those annoyances. Yesterday I was able to compile it entirely from scratch in 0.016 seconds. And I haven't misplaced a decimal point! More info: http://pastebin.com/yFKzs2eF) You are *incredibly* privileged to do all your work on your own custom programming languages, These days anyone (any coder) can do that if they wish. Apparently most people don't. I don't blame them. The size of Python isn't important to *you* on your fancy PC with entire gigabytes of hard drive, but to people interested in running Python on embedded hardware and micro-computers, every kilobyte counts. The subject is about a feature that was available on any 1980s microcomputer with memory measured in KB. Anyway I know about small systems, and the ones I create are pretty small (they will still fit on a floppy disk), but they will no longer run on tiny systems. But I'd like to see Python running on a 64KB system (Micropython doesn't count!). I think this came up when someone wanted to switch from Visual Basic to Python. The above is not a very sophisticated approach but it is very simple and intuitive. Intuitive to whom? To me, it just looks weird. 'read a,b,c' is weird and unintuitive compared with its counterpart 'print a,b,c'. OK BTW what does reading three integers from the user look like in Python? -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: distributed development methodology
On 10/29/2016 12:31 AM, Adam Jensen wrote: > On 10/28/2016 11:59 PM, Cameron Simpson wrote: >> Sync the virtualenv prerequisites file with your DVCS. Have a tiny >> script to update the local virtualenv prereq file and run its update >> command to honour any new prereqs. > > Cool. I didn't mention that I am a python n00b, did I? What/where is the > "virtualenv prerequisites file" and what would the "update command" look > like? :) > For posterity: pip freeze > requirements.txt pip install -r requirements.txt https://pip.pypa.io/en/latest/user_guide/#requirements-files -- https://mail.python.org/mailman/listinfo/python-list
Re: Need help in python program
id_1, clk, val = foo_function() id_2, key, units, delay = bar_function() if id_1 == id_2: print id_1, clk, val, key, units, delay -- https://mail.python.org/mailman/listinfo/python-list
Re: distributed development methodology
Adam Jensen writes: > So what are some of the more successful distributed. multi-platform, > development models? Use an orchestration program to keep the systems in sync: I use ansible (ansible.com) which is written in Python and fairly simple once you get used to it, but there are lots of other programs in that space and everyone has their own preferences. If stuff doesn't change too often, you could also use Docker or whatever the current hotness is to make a container image and deploy it to your fleet. -- https://mail.python.org/mailman/listinfo/python-list
Re: distributed development methodology
On 29Oct2016 00:11, Adam Jensen wrote: On 10/28/2016 11:59 PM, Cameron Simpson wrote: Sync the virtualenv prerequisites file with your DVCS. Have a tiny script to update the local virtualenv prereq file and run its update command to honour any new prereqs. Cool. I didn't mention that I am a python n00b, did I? What/where is the "virtualenv prerequisites file" and what would the "update command" look like? :) Have a read of this: https://www.dabapps.com/blog/introduction-to-pip-and-virtualenv-python/ and then this: https://pip.pypa.io/en/latest/user_guide/#requirements-files Then come back with specific questions :-) Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
