Re: Friday finking: TDD and EAFP
On 6/11/19 8:01 AM, Barry Scott wrote: On 1 Nov 2019, at 05:40, DL Neil via Python-list wrote: Is the practice of TDD fundamentally, if not philosophically, somewhat contrary to Python's EAFP approach? The practice of TDD* is that one writes test routines to prove a unit of code, eg method or function; BEFORE actually writing said function. The rationale is that TDD encourages proper identification and consideration of the routine's specification, and attempts to ensure that exceptions and "edge-cases" are not quietly forgotten. (in a broad-brush, nut-shell) The practice of creating software is a social activity where those involved have foibles. Managing all the social interactions and foibles is what the methodologies are trying to help with. Any methodology that is easier to follow then avoid will tend to be taken up and provide a benefit. We all know that tests are a must have, but often those tests that we all know are a must have do not get written. It can often seem like a chore, after all the code works right? By starting with the tests the social engineering means that you make having the tests the easy part of the process. Methodologies like Agile address other foibles. Given a far off dead line the tendency is to delay getting the bulk of the work done until at the last moment. So is TDD contrary to EAFP? Not as such its two sorts of social engineering. TDD helps get the tests, EAPF give permission to take risks, necessary to innovate. +1 -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Friday finking: TDD and EAFP
Apologies for lateness - stuff happened...
On 4/11/19 9:44 AM, Peter J. Holzer wrote:
On 2019-11-04 07:41:32 +1300, DL Neil via Python-list wrote:
On 3/11/19 6:30 AM, Bev In TX wrote:
On Nov 1, 2019, at 12:40 AM, DL Neil via Python-list
mailto:python-list@python.org>> wrote:
Is the practice of TDD fundamentally, if not philosophically,
somewhat contrary to Python's EAFP approach?
Agreed: (in theory) TDD is independent of language or style. However, I'm
wondering if (in practice) it creates a mode of thinking that pushes one
into an EAFP way of thinking?
This is exactly the opposite of what you proposed in your first mail,
and I think it is closer to the truth:
It is a while ago, and I cannot honesty remember if I was attempting to
provoke discussion/debate/illustration by switching things around, or if
I simply confused the abbreviations.
TDD does in my opinion encourage EAFP thinking.
The TDD is usually:
1 Write a test
2 Write the minimal amount of code that makes the test pass
3 If you think you have covered the whole spec, stop, else repeat
from 1
This is often (e.g. in [1]) exaggerated for pedagogic and humoristic
reasons. For example, your first test for a sqrt function might be
assert(sqrt(4) == 2)
and then of course the minimal implementation is
def sqrt(x):
return 2
I have seen this sort of thing in spreadsheet training - someone
pulling-out a calculator, summing a column of numbers, and typing 'the
answer' in the "Total" cell (instead of using the Sigma button or @SUM() ).
However, I've never seen anyone attempt to pass-off this sort of code
outside of desperate (and likely, far too late) floundering during a 101
assignment - FAILED!
Who would begin to believe that such code implements sqrt, or that it
meets with the function's objectives as laid-out in the spec AND the
docstring? So, anyone can prove anything - if they leave reality/reason
far-enough behind.
Unfortunately the phrase "test pass" (as above) can be misused?abused in
this way; but nowhere in your or my descriptions of TDD did *we* feel it
necessary to point-out that the/any/every test should be true to the
spec. It's unnecessary.
Great joke, but its proponents are delaying a proper consideration of
TDD. Perhaps they are hiding behind something?
Which just means that we don't have enough test cases yet. But the point
is that a test suite can only check a finite (and usually rather small)
number of cases, while most interesting programs accept a very large (if
not really infinite) number of inputs, so the test suite will always be
incomplete. At some point you will have to decide thet the test suite is
good enough and ship the code - and hope that the customer will forgive
you if you have (inevitably) forgotten an important case.
Which highlights a difference between the description (above) and the
approach I described: I tend to write 'all' the tests first - which, now
that I type it, really does sound LBYL!
Why? Because testing is what we might call a diagnostic mode of thinking
- what is happening here and why? Well, nothing is actually happening in
terms of the application's code; but I'm trying to think-ahead and
imagine the cases where things might not go according to plan.
Later, I shift to (what?) code-authoring/creative mode (yes, someone's
going to point-out the apparent dichotomy in these words - please
go-ahead) and 'bend the computer to my will'. It is the tests which
(hopefully) prove the success or otherwise of my output. I'm not coding
to the test(s) - sometimes I deliberately take a meal-break or
overnight-break between writing tests and writing code.
Why not follow 'the letter of the law'? Because it seems to me that they
require different ways of looking (at the same problem). My fear of
doing them one-at-a-time is that I'll conclude (too early) exactly as
you say - that's enough testing, 'it works'!
Returning to my possible re-interpretation/misuse of the TDD paradigm:
I'm only officially 'testing' one test at a time, but if 'this iteration
of the code' passes two or more of the next tests in the series, well...
("oh what a good boy am I"!) In practice, I'll review this iteration's
test and its motivation(s) to ensure that the code hasn't passed 'by
accident' (or should that be, by "bi-product").
Now, reviewing the: write one (useful/meaningful) test, then write the
code until it passes (this and all previous tests), then re-factor
(tests and application code), rinse-and-repeat. The question is: might
the 'diagnostic' mode of thought 'infect' the 'creative' and thereby
encourage writing more "defensive code" than is EAFP/pythonic?
There is very little emphasis in TDD on verifying that the code is
correct - only that it passes the tests.
Relationship of both to spec, discussed above.
Agreed, that the spec must be held in the mind(s) of the test and code
writer(s)! Also agreed that code h
Re: Funny behavior of IDLE 3.7.0
On Wed, Nov 13, 2019 at 11:00 AM Terry Reedy wrote:
>
> On 11/12/2019 12:00 PM, Chris Angelico wrote:
> > On Wed, Nov 13, 2019 at 3:57 AM Terry Reedy wrote:
> >>
> >> On 11/12/2019 8:29 AM, Chris Angelico wrote:
> >>
> >>> The OP said that the equals sign in the *first* line was flagged as
> >>> invalid syntax. Implication being that the error is being reported on
> >>> the line "i = 4", not on the print at the end. And in fact, I can
> >>> confirm this. Run | Check Module reports an error where i is assigned
> >>> to. Here's how it looks in command-line Python:
> >>>
> >>> $ python3.7 demo.py
> >>> File "", line 1
> >>> (i=)
> >>> ^
> >>> SyntaxError: invalid syntax
> >>>
> >>> Newer Pythons are happy with this example, but if you replace the
> >>> error with something else - say, f'{i+}' - then the same phenomenon
> >>> occurs. Command-line Python reports the error on line 1 of
> >>> "", and Idle misinterprets that as line 1 of the original
> >>> file.
> >>>
> >>> This looks like an error reporting flaw in f-string handling.
> >>
> >> Can you open a bug issue (if not one already) and nosy me?
> >> This is awful for any IDE that processes error messages.
> >>
> >> Replacing {} with () is a secondary bug. The actual code
> >> {i=}
> >> would be clearer, and make it easier for an IDE to search for the real
> >> line.
> >>
> >
> > I can do that, but I actually think the correct fix isn't inside Idle.
>
> Right. I meant a bug report against core Python.
>
> If the real bug is not fixed, I might do a workaround for IDLE, but I
> would prefer not.
>
Gotcha!
Turns out there is actually an open bug:
https://bugs.python.org/issue34364
But it cites a GitHub PR that has been merged already:
https://github.com/python/cpython/pull/10021
So I'm not sure what status actually is, since the current master
branch still has the problem.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Trouble trying to get started with pygame
On 11/12/2019 2:32 PM, originallmo...@gmail.com wrote: I'm curious: I've been seeing people having multiple pygame programs open at once (Where each one is a component of a main program, obviously). Multiple programs open at once on modern machines is normal. Do you mean multiple windows for one program? As is possible with IDLE? -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Funny behavior of IDLE 3.7.0
On 11/12/2019 12:00 PM, Chris Angelico wrote:
On Wed, Nov 13, 2019 at 3:57 AM Terry Reedy wrote:
On 11/12/2019 8:29 AM, Chris Angelico wrote:
The OP said that the equals sign in the *first* line was flagged as
invalid syntax. Implication being that the error is being reported on
the line "i = 4", not on the print at the end. And in fact, I can
confirm this. Run | Check Module reports an error where i is assigned
to. Here's how it looks in command-line Python:
$ python3.7 demo.py
File "", line 1
(i=)
^
SyntaxError: invalid syntax
Newer Pythons are happy with this example, but if you replace the
error with something else - say, f'{i+}' - then the same phenomenon
occurs. Command-line Python reports the error on line 1 of
"", and Idle misinterprets that as line 1 of the original
file.
This looks like an error reporting flaw in f-string handling.
Can you open a bug issue (if not one already) and nosy me?
This is awful for any IDE that processes error messages.
Replacing {} with () is a secondary bug. The actual code
{i=}
would be clearer, and make it easier for an IDE to search for the real line.
I can do that, but I actually think the correct fix isn't inside Idle.
Right. I meant a bug report against core Python.
If the real bug is not fixed, I might do a workaround for IDLE, but I
would prefer not.
See the followup regarding the difference between SyntaxError and
NameError; in the latter case, the error is more usefully reported.
ChrisA
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Hi there! We are here to answer any questions you have about Udacit...
On 12/11/19 9:48 PM, joseph pareti wrote: great, thank you so much for the advice. In fact, I sent this mail to the python mailing list by mistake, but now I am glad I did ... There's plenty of over-lap between lists - PyTutor is another. Meantime I've received email from IBM about their ML/AI video series, which may also interest you. Today/tomorrow they are offering a web-cast: An Introduction to Visual Recognition. https://developer.ibm.com/events/an-introduction-to-visual-recognition-11-13-2019/ This invitation came from one of their email subscriptions to which you could also subscribe. Undoubtedly their bias is towards "Watson". Some activities enable free access to a Watson cloud... -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Launching a Script on the Linux Platform
On Tue, 12 Nov 2019 18:39:38 +, Rhodri James wrote: > On 12/11/2019 18:25, Rob Gaddi wrote: >> On 11/12/19 10:06 AM, Wildman wrote: >>> What is the best approach for launching a Python GUI program >>> on a Linux platform. The program will be distributed in .deb >>> format. So the .deb will contain a menu file as well as a >>> .desktop file. The post install script will update the system >>> menu. >>> >>> My question is how should the program be executed? Here are >>> two choices for the "command=" entry in the menu file... >>> >>> command="/path/to/program.py" >>> >>> In this case the hash-bang would have to be included in the >>> program script... #!/usr/bin/env python3 >>> >>> The other choice is this... >>> >>> command="python3 /path/to/program.py" >>> >>> (Of course, the Exec command in the .desktop file should match.) >>> >>> Is one method better than the other or does it acutally matter? >>> >> >> I will note that without the shebang (and setting the execute bit), the >> program is only executable from the GUI menu, not the command prompt. I >> personally start even GUI programs far more often from a prompt. >> >> To follow Linux conventions you'd put the shebang, make the file >> executable, and put the executable somewhere on the PATH. I'd stick to >> those conventions barring a particular reason not to. > > Wildman is talking about launching his program from a menu, so putting > it on the PATH is unnecessary. It may even be a bad idea, depending on > exactly what he's done :-) Yes, that is correct. My program would be installed using a deb package manager such as apt and an entry placed in the desktop menu to launch the program. Thank you for the reply Rob. > As to the original question, there shouldn't really be much of a > difference. The original idea of the shebang line invoking env, as far > I recall, was that you'd get the "proper" system python3 wherever it had > been put rather than something random and possibly malicious. I guess > that means to go for your first option. Shebang! Yea, that is the correct term. All I could think of was hashbang. I knew that wasn't quite right. Yes, I prefer to envoke env in the shebang line instead of depending on the path. Paths can change especially in a multi-user system but env will always know where to find the executable. Thank you for your input. Shebang is the logical answer with all else being equal. -- GNU/Linux user #557453 "Setting a good example is a far better way to spread ideals than through force of arms." -Ron Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Trouble trying to get started with pygame
I'm curious: I've been seeing people having multiple pygame programs open at once (Where each one is a component of a main program, obviously). If I'm making a larger game, do I NEED to do that? I'm assuming I'd need a Visual Studio extension for Python in order to do that. -- https://mail.python.org/mailman/listinfo/python-list
Re: Launching a Script on the Linux Platform
On 12/11/2019 18:25, Rob Gaddi wrote: On 11/12/19 10:06 AM, Wildman wrote: What is the best approach for launching a Python GUI program on a Linux platform. The program will be distributed in .deb format. So the .deb will contain a menu file as well as a .desktop file. The post install script will update the system menu. My question is how should the program be executed? Here are two choices for the "command=" entry in the menu file... command="/path/to/program.py" In this case the hash-bang would have to be included in the program script... #!/usr/bin/env python3 The other choice is this... command="python3 /path/to/program.py" (Of course, the Exec command in the .desktop file should match.) Is one method better than the other or does it acutally matter? I will note that without the shebang (and setting the execute bit), the program is only executable from the GUI menu, not the command prompt. I personally start even GUI programs far more often from a prompt. To follow Linux conventions you'd put the shebang, make the file executable, and put the executable somewhere on the PATH. I'd stick to those conventions barring a particular reason not to. Wildman is talking about launching his program from a menu, so putting it on the PATH is unnecessary. It may even be a bad idea, depending on exactly what he's done :-) As to the original question, there shouldn't really be much of a difference. The original idea of the shebang line invoking env, as far I recall, was that you'd get the "proper" system python3 wherever it had been put rather than something random and possibly malicious. I guess that means to go for your first option. -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list
Re: Launching a Script on the Linux Platform
On 11/12/19 10:06 AM, Wildman wrote: What is the best approach for launching a Python GUI program on a Linux platform. The program will be distributed in .deb format. So the .deb will contain a menu file as well as a .desktop file. The post install script will update the system menu. My question is how should the program be executed? Here are two choices for the "command=" entry in the menu file... command="/path/to/program.py" In this case the hash-bang would have to be included in the program script... #!/usr/bin/env python3 The other choice is this... command="python3 /path/to/program.py" (Of course, the Exec command in the .desktop file should match.) Is one method better than the other or does it acutally matter? I will note that without the shebang (and setting the execute bit), the program is only executable from the GUI menu, not the command prompt. I personally start even GUI programs far more often from a prompt. To follow Linux conventions you'd put the shebang, make the file executable, and put the executable somewhere on the PATH. I'd stick to those conventions barring a particular reason not to. -- 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
Launching a Script on the Linux Platform
What is the best approach for launching a Python GUI program on a Linux platform. The program will be distributed in .deb format. So the .deb will contain a menu file as well as a .desktop file. The post install script will update the system menu. My question is how should the program be executed? Here are two choices for the "command=" entry in the menu file... command="/path/to/program.py" In this case the hash-bang would have to be included in the program script... #!/usr/bin/env python3 The other choice is this... command="python3 /path/to/program.py" (Of course, the Exec command in the .desktop file should match.) Is one method better than the other or does it acutally matter? -- GNU/Linux user #557453 "There are only 10 types of people in the world... those who understand Binary and those who don't." -Spike -- https://mail.python.org/mailman/listinfo/python-list
Re: Funny behavior of IDLE 3.7.0
On Wed, Nov 13, 2019 at 3:57 AM Terry Reedy wrote:
>
> On 11/12/2019 8:29 AM, Chris Angelico wrote:
>
> > The OP said that the equals sign in the *first* line was flagged as
> > invalid syntax. Implication being that the error is being reported on
> > the line "i = 4", not on the print at the end. And in fact, I can
> > confirm this. Run | Check Module reports an error where i is assigned
> > to. Here's how it looks in command-line Python:
> >
> > $ python3.7 demo.py
> >File "", line 1
> > (i=)
> >^
> > SyntaxError: invalid syntax
> >
> > Newer Pythons are happy with this example, but if you replace the
> > error with something else - say, f'{i+}' - then the same phenomenon
> > occurs. Command-line Python reports the error on line 1 of
> > "", and Idle misinterprets that as line 1 of the original
> > file.
> >
> > This looks like an error reporting flaw in f-string handling.
>
> Can you open a bug issue (if not one already) and nosy me?
> This is awful for any IDE that processes error messages.
>
> Replacing {} with () is a secondary bug. The actual code
>{i=}
> would be clearer, and make it easier for an IDE to search for the real line.
>
I can do that, but I actually think the correct fix isn't inside Idle.
See the followup regarding the difference between SyntaxError and
NameError; in the latter case, the error is more usefully reported.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Funny behavior of IDLE 3.7.0
On 11/12/2019 8:29 AM, Chris Angelico wrote:
The OP said that the equals sign in the *first* line was flagged as
invalid syntax. Implication being that the error is being reported on
the line "i = 4", not on the print at the end. And in fact, I can
confirm this. Run | Check Module reports an error where i is assigned
to. Here's how it looks in command-line Python:
$ python3.7 demo.py
File "", line 1
(i=)
^
SyntaxError: invalid syntax
Newer Pythons are happy with this example, but if you replace the
error with something else - say, f'{i+}' - then the same phenomenon
occurs. Command-line Python reports the error on line 1 of
"", and Idle misinterprets that as line 1 of the original
file.
This looks like an error reporting flaw in f-string handling.
Can you open a bug issue (if not one already) and nosy me?
This is awful for any IDE that processes error messages.
Replacing {} with () is a secondary bug. The actual code
{i=}
would be clearer, and make it easier for an IDE to search for the real line.
IMO it
should just count the entire f-string as being at the line and file
that the f-string starts; when working with triple-quoted f-strings, I
was only able to get line numbers above 1 by having a multi-line
braced expression, and that's not something we should be encouraging.
This is also consistent with the way other errors in triple-quoted
strings are handled:
print('''hello
world
\N{ASDF}
asdf
qwer''')
File "/home/rosuav/tmp/demo.py", line 1
print('''hello
^
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes
in position 12-19: unknown Unicode character name
If it can find the position of the specific braced expression within
the string, great! But at very least, it should report the location of
the string in its original file.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Logistic Regression Define X and Y for Prediction
Hi All,
I have the below code.
X = df.iloc[:, [4, 403]].values
y = df.iloc[:, 404].values
Dummy Data looks like:
host Mnemonic
12.234.13.6 start
22.22.44.67 something
23.44.44.14 begin
When I define the X and Y values for prediction in the train and test data,
should I capture all the columns that has been "OneHotEncoded" (that is all
columns with 0 and 1) for the X and Y values???
import numpyas np
import pandas as pd
import os
import matplotlib as mpl
mpl.rcParams['figure.dpi'] = 400
import matplotlib.pyplotas plt
# Importing the df
# Importing the df
os.chdir('c:\directory\data')# Location of data files
df = pd.read_csv('blahblahfile.csv')
from sklearn.preprocessing import LabelEncoder
hostip = LabelEncoder()
mnemonic = LabelEncoder()
df['host_encoded'] = hostip.fit_transform(df.reported_hostname)
df['mnemonic_encoded'] = mnemonic.fit_transform(df.mnemonic)
from sklearn.preprocessing import OneHotEncoder
hostip_ohe = OneHotEncoder()
mnemonic_ohe = OneHotEncoder()
X = hostip_ohe.fit_transform(df.host_encoded.values.reshape(-1,1)).toarray()
Y =
mnemonic_ohe.fit_transform(df.mnemonic_encoded.values.reshape(-1,1)).toarray()
## Add back X and Y into the original dataframe
dfOneHot = pd.DataFrame(X, columns = ["host_"+str(int(i)) for i in
range(X.shape[1])])
df = pd.concat([df, dfOneHot], axis=1)
dfOneHot = pd.DataFrame(Y, columns = ["mnemonic_encoded"+str(int(i)) for i in
range(Y.shape[1])])
df = pd.concat([df, dfOneHot], axis=1)
here is where I am not sure if all "host_" and "mnemonic_encoded"
values assigned to X and Y
X = df.iloc[:, [4, 403]].values
y = df.iloc[:, 404].values
# Splitting the dataset into the Training set and Test set
from sklearn.model_selection import train_test_split
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size = 0.25,
random_state = 0)
# Feature Scaling
from sklearn.preprocessing import StandardScaler
sc = StandardScaler()
X_train = sc.fit_transform(X_train)
X_test = sc.transform(X_test)
# Fitting Logistic Regression to the Training set
from sklearn.linear_model import LogisticRegression
classifier = LogisticRegression(random_state = 0)
classifier.fit(X_train, y_train)
# Predicting the Test set results
y_pred = classifier.predict(X_test)
# Making the Confusion Matrix
from sklearn.metrics import confusion_matrix
cm = confusion_matrix(y_test, y_pred)
# Visualising the Training set results
from matplotlib.colors import ListedColormap
X_set, y_set = X_train, y_train
X1, X2 = np.meshgrid(np.arange(start = X_set[:, 0].min() - 1, stop = X_set[:,
0].max() + 1, step = 0.01),
np.arange(start = X_set[:, 1].min() - 1, stop = X_set[:,
1].max() + 1, step = 0.01))
plt.contourf(X1, X2, classifier.predict(np.array([X1.ravel(),
X2.ravel()]).T).reshape(X1.shape),
alpha = 0.75, cmap = ListedColormap(('red', 'green')))
plt.xlim(X1.min(), X1.max())
plt.ylim(X2.min(), X2.max())
for i, j in enumerate(np.unique(y_set)):
plt.scatter(X_set[y_set == j, 0], X_set[y_set == j, 1],
c = ListedColormap(('red', 'green'))(i), label = j)
plt.title('Logistic Regression (Training set)')
plt.xlabel('Age')
plt.ylabel('Estimated Salary')
plt.legend()
plt.show()
# Visualising the Test set results
from matplotlib.colors import ListedColormap
X_set, y_set = X_test, y_test
X1, X2 = np.meshgrid(np.arange(start = X_set[:, 0].min() - 1, stop = X_set[:,
0].max() + 1, step = 0.01),
np.arange(start = X_set[:, 1].min() - 1, stop = X_set[:,
1].max() + 1, step = 0.01))
plt.contourf(X1, X2, classifier.predict(np.array([X1.ravel(),
X2.ravel()]).T).reshape(X1.shape),
alpha = 0.75, cmap = ListedColormap(('red', 'green')))
plt.xlim(X1.min(), X1.max())
plt.ylim(X2.min(), X2.max())
for i, j in enumerate(np.unique(y_set)):
plt.scatter(X_set[y_set == j, 0], X_set[y_set == j, 1],
c = ListedColormap(('red', 'green'))(i), label = j)
plt.title('Logistic Regression (Test set)')
plt.xlabel('Host IP')
plt.ylabel('Mnemonic')
plt.legend()
plt.show()
--
https://mail.python.org/mailman/listinfo/python-list
Re: Help!
As always, keep your messages on the mailing list so others can benefit. On 11/12/19 7:02 AM, Jack Gilbert wrote: > > . how do I get the PY program onto my desktop? Not quite sure what you mean. Python programs are saved into text files which you can store anywhere you want. Save them to the location you want them to be from your text editor. > . where might the idle be located If Idle is installed, a shortcut to it will be in your Windows start menu, just like most programs that are installed. It's been many years since I last used windows, but there's usually a list of programs installed, called "All Programs". > > I have no idea what I just did, but the python shell just appeared on my > desktop?? > I pinned the shell to the taskbar.. A shortcut to the python shell, or the shell itself running in a window? Finally, it's most likely you'll find the best beginner help at the python-tutor mailing list[1]. [1] https://mail.python.org/mailman/listinfo/tutor -- https://mail.python.org/mailman/listinfo/python-list
Re: Using Makefiles in Python projects
Rhodri James :
> On 11/11/2019 19:05, Bill Deegan wrote:
>> You could use SCons (native python... )
>
> I could. But I'd have to learn how to first, and particularly for
> complex cross-platform working that involves learning a lot of stuff I
> already know how to do in Make. The time investment has never seemed
> that worthwhile.
SCons can be learned by reading its man page in a single afternoon.
That's how I learned it.
The toughest part is to decide *how* to use it as SCons entices you with
a plugin architecture. The temptation is to create a sentient monster
out of your build specification.
I have successfully applied a minimalistic style that is plain to a
random bystander who doesn't know either Python or SCons.
Here's a synopsis...
At the root of your repository, you write a (Python) file called
"SConstruct". In each source directory, you write a (Python) file called
"SConscript". The SConstruct uses SCons primitives to call the
individual SConscript files.
The SCons primitives in the SCons* files don't execute build commands.
Rather, they construct a dependency graph between all source and target
files across the repository. (I favor a non-globbing style where every
file is specified explicitly.)
Each SConscript file starts with the command:
Import('env')
where "env" is short for "environment". An "environment" does *not*
refer to environment variables but to a collection of build parameters
(include paths, libraries, compilation flags etc).
The SConscript file might contain this line:
env.Program("hello", [ "hello.c", "world.c" ])
meaning:
Using the build parameters stored in "env", compile the executable
program "hello" out of two C source code files.
SCons has builtin knowledge of some programming languages. So SCons
knows how to preprocess the source files and can deduct the
dependencies.
Note that the above "env.Program()" command does not yet execute
anything; it simply specifies a build node with associated explicit and
implicit dependencies.
Ad-hoc build rules are expressed using "env.Command()":
env.Command("productivity.txt", [ "hello.c", "world.c" ],
r"""cat $SOURCES | wc -l >$TARGET""")
The tricky part is writing SConstruct. At its simplest, it could be
something like this:
def construct():
env = Environment()
SConscript("src/SConscript", exports="env")
if __name__ == "SCons.Script":
construct()
In my experience, all kinds of cross-compilation and variant-directory
logic is placed in SConstruct.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: Funny behavior of IDLE 3.7.0
On Wed, Nov 13, 2019 at 12:29 AM Chris Angelico wrote: > If it can find the position of the specific braced expression within > the string, great! But at very least, it should report the location of > the string in its original file. Further to this: If a runtime (non-syntax) error occurs, it is correctly reported. This is handled by fstring_fix_node_location in ast.c, which adjusts the reported locations so future error handling gets things right. But that happens *after* any syntax errors get reported, which happens in pythonrun.c inside err_input(), I think. That doesn't get adjusted to the main file's locations, so it gets reported as "" line 1. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Funny behavior of IDLE 3.7.0
On Wed, Nov 13, 2019 at 12:14 AM Heinrich Kruger wrote:
>
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, November 12, 2019 12:39 PM, Pieter van Oostrum
> wrote:
>
> > r...@zedat.fu-berlin.de">--protonsignature--...@zedat.fu-berlin.de (Stefan
> > Ram) writes:
> >
> > > When I enter
> > > i = 4
> > > x = 2.3
> > > s = 'abc'
> > > print( f'{i=}' )
> > > into a file window of IDLE 3.7.0, it marks the '='
> > > sign in the /first/ line and says 'invalid syntax'.
> > > Remove the »f«, and the error will disappear.
> >
> > I did this in IDLE 3.7.5, and it gives a syntax error on the last line.
> > This is correct, because the f-string is in error. Between the curly
> > braces there should be an expression, possibly followed by a conversion
> > (!...) and/or a format specification (:...). {i=} is not a correct
> > expression. When you remove the »f«, it becomes a normal string, where
> > the {} don't have a special meaning.
>
> What the OP was trying to do is valid in python 3.8 (see
> https://docs.python.org/3/whatsnew/3.8.html#f-strings-support-for-self-documenting-expressions-and-debugging)
> but not in older versions. To achieve the same result in python 3.7, you
> have to do something like
>
> print(f'i={i}')
>
The OP said that the equals sign in the *first* line was flagged as
invalid syntax. Implication being that the error is being reported on
the line "i = 4", not on the print at the end. And in fact, I can
confirm this. Run | Check Module reports an error where i is assigned
to. Here's how it looks in command-line Python:
$ python3.7 demo.py
File "", line 1
(i=)
^
SyntaxError: invalid syntax
Newer Pythons are happy with this example, but if you replace the
error with something else - say, f'{i+}' - then the same phenomenon
occurs. Command-line Python reports the error on line 1 of
"", and Idle misinterprets that as line 1 of the original
file.
This looks like an error reporting flaw in f-string handling. IMO it
should just count the entire f-string as being at the line and file
that the f-string starts; when working with triple-quoted f-strings, I
was only able to get line numbers above 1 by having a multi-line
braced expression, and that's not something we should be encouraging.
This is also consistent with the way other errors in triple-quoted
strings are handled:
print('''hello
world
\N{ASDF}
asdf
qwer''')
File "/home/rosuav/tmp/demo.py", line 1
print('''hello
^
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes
in position 12-19: unknown Unicode character name
If it can find the position of the specific braced expression within
the string, great! But at very least, it should report the location of
the string in its original file.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Funny behavior of IDLE 3.7.0
‐‐‐ Original Message ‐‐‐
On Tuesday, November 12, 2019 12:39 PM, Pieter van Oostrum
wrote:
> r...@zedat.fu-berlin.de">--protonsignature--...@zedat.fu-berlin.de (Stefan
> Ram) writes:
>
> > When I enter
> > i = 4
> > x = 2.3
> > s = 'abc'
> > print( f'{i=}' )
> > into a file window of IDLE 3.7.0, it marks the '='
> > sign in the /first/ line and says 'invalid syntax'.
> > Remove the »f«, and the error will disappear.
>
> I did this in IDLE 3.7.5, and it gives a syntax error on the last line.
> This is correct, because the f-string is in error. Between the curly
> braces there should be an expression, possibly followed by a conversion
> (!...) and/or a format specification (:...). {i=} is not a correct
> expression. When you remove the »f«, it becomes a normal string, where
> the {} don't have a special meaning.
What the OP was trying to do is valid in python 3.8 (see
https://docs.python.org/3/whatsnew/3.8.html#f-strings-support-for-self-documenting-expressions-and-debugging)
but not in older versions. To achieve the same result in python 3.7, you have
to do something like
print(f'i={i}')
--
Heinrich Kruger
--
https://mail.python.org/mailman/listinfo/python-list
Re: Funny behavior of IDLE 3.7.0
r...@zedat.fu-berlin.de (Stefan Ram) writes:
> When I enter
>
> i = 4
> x = 2.3
> s = 'abc'
> print( f'{i=}' )
>
> into a file window of IDLE 3.7.0, it marks the '='
> sign in the /first/ line and says 'invalid syntax'.
>
> Remove the »f«, and the error will disappear.
I did this in IDLE 3.7.5, and it gives a syntax error on the last line.
This is correct, because the f-string is in error. Between the curly
braces there should be an expression, possibly followed by a conversion
(!...) and/or a format specification (:...). {i=} is not a correct
expression. When you remove the »f«, it becomes a normal string, where
the {} don't have a special meaning.
--
Pieter van Oostrum
WWW: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]
--
https://mail.python.org/mailman/listinfo/python-list
Re: Using Makefiles in Python projects
On 11/11/2019 19:05, Bill Deegan wrote: You could use SCons (native python... ) I could. But I'd have to learn how to first, and particularly for complex cross-platform working that involves learning a lot of stuff I already know how to do in Make. The time investment has never seemed that worthwhile. -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list
Re: Can we use Python for hacking?
>> Someone requested my answer to the question: "Can we use Python for >> hacking?" > Sigh. I suppose it's a lost battle to reclaim that word. So true. I still remember the ESR article that I used to share twenty years ago. -- Pankaj Jangid -- https://mail.python.org/mailman/listinfo/python-list
