date:20160724

Yes, I said Pythons plural :-)

For those wanting to use Python on .Net or Mono, there is some good news.

Firstly, the venerable old "Python for .Net" project is still alive, and now
supports up to Python 3.5 on .Net or Mono. PythonNet, as this is known,
integrates the regular CPython interpreter with .Net or Mono.

Secondly, we can also expect that IronPython will have a new lease of life.
Continuing on the work of their predecessor, Jeff Hardy, the IronPython
project now has two tech leads who will carry it forward: Alex Earl and
Benedikt Eggers.

https://thelasttechie.com/2016/07/24/its-back-python-for-net/


IronPython is a reimplementation of Python, written in C# as managed code
for .Net. It doesn't use a GIL, and is sometimes considered a little faster
than CPython, so this is good news for the Python ecosystem.

IronPython:
http://ironpython.net/
 
Python for .Net:
https://github.com/pythonnet/pythonnet
http://pythonnet.github.io/
https://pypi.python.org/pypi/pythonnet




-- 
Steven
“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: Why not allow empty code blocks?

On Mon, 25 Jul 2016 01:20 pm, Rustom Mody wrote:

>> so ultimately, it all comes down to testing anyway.
> 
> All??

Ultimately, yes. It all comes down to testing. How else do you know that
your program to flernge the widget *actually* flernges the widget or not?

> There is a famous quote by Dijkstra:
> «Testing shows the presence, not the absence of bugs»

Correct. And as Knuth said:

"Beware of bugs in the above code; I have only proved it correct, not tried
it."

You cannot *prove* the absence of bugs in a large, complex program, because
how do you know your proof is correct? Your automatic prover is a program,
which will contain bugs. If you don't use an automatic prover, then how do
you know you didn't make a mistake in your manual proof?

Ultimately, any program beyond a certain level of complexity can only be
*suspected* to be correct.

> Or if you prefer things of a more ‘practical’ (so-called_ nature:
>
http://www.testingexcellence.com/reasons-automated-tests-fail-to-find-regression-bugs/

-- 
Steven
“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: Why not allow empty code blocks?

On Monday, July 25, 2016 at 8:59:10 AM UTC+5:30, Chris Angelico wrote:
> On Mon, Jul 25, 2016 at 1:20 PM, Rustom Mody wrote:
> >> so ultimately, it all comes down to testing anyway.
> >
> > All??
> >
> > There is a famous quote by Dijkstra:
> > «Testing shows the presence, not the absence of bugs»
> >
> > Or if you prefer things of a more ‘practical’ (so-called_ nature:
> > http://www.testingexcellence.com/reasons-automated-tests-fail-to-find-regression-bugs/
> 
> If testing won't find the bugs, what will? By "testing", I don't just
> mean automated tests, although of course that's one of the most
> efficient ways. Dogfooding is an important part of testing too.

Dijkstra made that (and such) statements towards advocating formal program
proving.

Whether we agree/disagree with that line is one thing.
The bald fact that tests are finite and the actual search space for cases for 
anything remotely non-trivial is infinite is undeniable.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?

On Mon, Jul 25, 2016 at 1:20 PM, Rustom Mody  wrote:
>> so ultimately, it all comes down to testing anyway.
>
> All??
>
> There is a famous quote by Dijkstra:
> «Testing shows the presence, not the absence of bugs»
>
> Or if you prefer things of a more ‘practical’ (so-called_ nature:
> http://www.testingexcellence.com/reasons-automated-tests-fail-to-find-regression-bugs/

If testing won't find the bugs, what will? By "testing", I don't just
mean automated tests, although of course that's one of the most
efficient ways. Dogfooding is an important part of testing too.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?

On Monday, July 25, 2016 at 8:42:21 AM UTC+5:30, Chris Angelico wrote:
> On Mon, Jul 25, 2016 at 12:48 PM, Michael Torrie wrote:
> > Far more often I'm bitten by the dynamic nature of Python (would happen
> > in any dynamic language).  I'll be using a particular member attribute
> > which I accidentally misspell somewhere and sometimes that results in
> > silent failure.  Something doesn't work, but no exception is thrown.
> > Unit tests, and perhaps lint, are required to catch these errors.  That
> > is one thing about a dynamic language: comprehensive testing is required
> > as you go along.
> >
> 
> To be quite honest, comprehensive testing is needed in more static
> languages too. There are certain categories of error which can be
> detected by a compiler/linter, and certain which cannot; a language
> that forces you to declare variables will catch variable name
> misspellings, but only if they don't land you on an existing variable,
> and still won't catch the dynamic places like dict keys (imagine
> getting a block of JSON from somewhere, converting it into a
> dictionary, and looking up stuff in it - the compiler can't know
> whether your incoming data is correct and your code wrong, or the
> other way around). A language with less dynamism might be able to
> catch more, but still not everything, 

So far — Fine!


> so ultimately, it all comes down to testing anyway.

All??

There is a famous quote by Dijkstra:
«Testing shows the presence, not the absence of bugs»

Or if you prefer things of a more ‘practical’ (so-called_ nature:
http://www.testingexcellence.com/reasons-automated-tests-fail-to-find-regression-bugs/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?

On Mon, Jul 25, 2016 at 12:48 PM, Michael Torrie  wrote:
> Far more often I'm bitten by the dynamic nature of Python (would happen
> in any dynamic language).  I'll be using a particular member attribute
> which I accidentally misspell somewhere and sometimes that results in
> silent failure.  Something doesn't work, but no exception is thrown.
> Unit tests, and perhaps lint, are required to catch these errors.  That
> is one thing about a dynamic language: comprehensive testing is required
> as you go along.
>

To be quite honest, comprehensive testing is needed in more static
languages too. There are certain categories of error which can be
detected by a compiler/linter, and certain which cannot; a language
that forces you to declare variables will catch variable name
misspellings, but only if they don't land you on an existing variable,
and still won't catch the dynamic places like dict keys (imagine
getting a block of JSON from somewhere, converting it into a
dictionary, and looking up stuff in it - the compiler can't know
whether your incoming data is correct and your code wrong, or the
other way around). A language with less dynamism might be able to
catch more, but still not everything, so ultimately, it all comes down
to testing anyway.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?

2016-07-24 Thread Michael Torrie

On 07/24/2016 07:14 PM, BartC wrote:
> I've done little Python coding but still, having to use kid gloves for 
> indents does figure quite a bit in that.
> 
> I can give some more examples but I'll probably be told that I'm using 
> the wrong tools! Which suggest there is a problem, but the effort has 
> gone into working around them using external tools. (But understandable 
> if the language design was fixed 25 years ago.)

I only code in Python these days and I simply do not find the indenting
syntax to be a problem.

Far more often I'm bitten by the dynamic nature of Python (would happen
in any dynamic language).  I'll be using a particular member attribute
which I accidentally misspell somewhere and sometimes that results in
silent failure.  Something doesn't work, but no exception is thrown.
Unit tests, and perhaps lint, are required to catch these errors.  That
is one thing about a dynamic language: comprehensive testing is required
as you go along.

> 
> For example:
> 
> if cond:
>  a
>  b
> 
> I want to comment out the if statement temporarily, but I also have to 
> fix the indents:
> 
> #if cond:
> a
> b

Good example, and I've encountered this one, but honestly fixing the
indent is best programming practice anyway.  If I want to preserve
context, copying the entire block and then commenting it out to preserve
it is what I prefer.  Anyway, I'd want to fix indenting even if I was
using braces.  Just to make the code readable and maintainable over time
as more often than not temporary becomes permanent.  If it's truly a
temporary removal, your "if 1:" idiom seems most correct to me, with the
original condition commented out.

Also there are times when I simply don't worry about commenting things
out.  I just delete them and fix the indenting and move on with life.  I
can always revert my changes if I end up barking up the wrong tree.

> 
> (Or add the comment and insert a dummy 'if 1:'.)

This is a good idea for temporarily taking out the condition.  Sounds
like good practice to me.

> 
> Or I want to add a temporary condition around:
> 
> a
> b
> 
> which again requires me to indent those statements (and unindent them 
> again later). Or I want to permanently have a commented out #if guard 
> around some code:
> 
> #if cond:
> a
> b
> 
> to be uncommented from time to time (to do with debugging). But it's not 
> as simple as just uncommenting that one line.

With a end statement you'd of course have to comment out both the if and
the end lines.  Just to nitpick.

> 
> Or I want to have a temporary print statement within a block, but it 
> needs to be at the right indentation. Not a great imposition, but it's 
> now less visible as a temporary addition.

Pretty much all print statements in my code are visible as a temporary
addition.  There is really little other reason to use it.  So every so
often I'll search for all my print statements and comment them out or
delete them once the code is operational.  But even then, using a
logging function is probably even better solution.

> Or I need to move or copy code from one location to another, but the 
> indentation levels are different. This would need fixing in other 
> languages too, but if this is part of a temporary try out which will 
> change again a few minutes later, I can dispense with the correct 
> indentation in another language, until the code is more permanent.

In venerable old ViM I just highlight the block and move it in or out.
Not having editor support would make this very painful. But you'd be
wanting to adjust the indenting anyway, in any language.  So while it
would cause an error in Python, in any other language you'd want to do
this anyway, just to make the code readable.

> In short, because correct indentation is required at all times, it's 
> less flexible when you want to do a lot of messing around.

I guess I just don't find this to be particularly problematic.  And
Python is great for doing a lot of messing around in for me.

> Now, if I was going to do a LOT of Python coding, then I would solve 
> most of those problems (by having my own tool to superimpose a more 
> amenable syntax on the language). For casual work though I have to go 
> along with the indent scheme. (And there are usually other issues with 
> Python that are more troublesome than getting the layout right.)

I tend to not have a lot of strong opinions about languages I have
little experience in.  What is it about your experience that leads to
such strong opinions about a language you do very little in?  I dislike
what I see of Ruby but I have no opinions strong enough to voice on the
Ruby lists (or even read them).  Just curious.

> I'll leave you with a code fragment that might be pasted from elsewhere 
> (it's not meant to mean anything):
> 
> if cond:
>  a
>  b
>  c
> 
> The question is: is this the whole block? We don't know, as we can't see 
> what came next. But if now I add the next line, and it was this 
> (anything actuall

Re: Can math.atan2 return INF?

On Thursday, June 30, 2016 at 1:55:18 PM UTC+5:30, Steven D'Aprano wrote:
> On Thursday 30 June 2016 12:13, Rustom Mody wrote:
> 
> > In particular the question: "Are real numbers really real?" is where it
> > starts off... http://blog.languager.org/2015/03/cs-history-0.html
> 
> The pre-history of what later became computer science is very interesting, 
> but 
> I fear that you are too focused on questions of "mysticism" and not enough on 
> what those people actually did and said.


I’ve been preparing material for some classes on Theory of Computation (ToC)

Starting from the premise that in a way Gödel is more primary to ToC than Turing

[And also been fan of Gödel-Escher-Bach from my college days]

And came across this proof (by Gödel!) that God exists  :
https://en.wikipedia.org/wiki/G%C3%B6del%27s_ontological_proof
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?

On Mon, 25 Jul 2016 08:13 am, BartC wrote:

> A solid end-of-block symbol (as you get with 'else' and 'except' because
> then you KNOW that's the end of that block) would have been welcome with
> the Python indent scheme.

A solid end-of-block symbol would have been entire redundant and
unnecessary. You know when the block ends: it ends when one of two things
happen:

- you dedent out a level;
- you reach the end of file;

whichever happens next. Requiring an otherwise pointless end of block
delimiter to protect against your cat walking over your keyboard, or clumsy
programmers who accidentally hit keys and don't notice, is not a virtue. It
doesn't make the language better. It just increases friction when writing
code.

There are approximately a million billion trillion zillion things that can
go wrong if you randomly hit keys without paying attention to what you are
doing, and regardless of whether you have a static or dynamic language,
only a tiny fraction of them can be detected ahead of time.

When you're typing plain English paragraphs like this, why don't you end
each sentence with "END", just in case you accidentally delete the
punctuation mark and don't notice? END That way, you have less fragile
text. END The reader can easily tell when you have the end of a sentence,
even if you accidentally delete the full stop, because of the special end
marker. END And two end markers could represent the end of a paragraph,
just in case you accidentally delete the break between paragraphs? END END

Actually, COMMA now that I think about it, COMMA I'm starting to come around
to your way of thinking. END We can tag other punctuation marks too, COMMA
like commas, COMMA to ensure that our language is less fragile. END No more
will you have to fear the ambiguity of accidentally dropping a comma: COLON
END END

"We invited the strippers, JFK, and Stalin."
"We invited the strippers, JFK and Stalin."

http://i.imgur.com/fycHx.jpg

Instead, COMNA the error becomes obvious: COLON EMD END

" QUOTE We invited the strippers, COMMA JFK COMMA and Stalin. END " QUOTE
END END

-- DASH DASH SPACE END END
Steven END END
“ QUOTE Cheer up, COMMA ” END they said, COMMA “ QUOTE things could be
worse. END ” QUOTE So I cheered up, COMMA and sure enough, COMMA things got
worse. END END

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?

2016-07-24 Thread Ben Finney

BartC  writes:

> On 25/07/2016 01:40, Gregory Ewing wrote:
> > What's your experience? How often has this caused you trouble, and
> > what proportion is it of all the Python programming you've done?
>
> I've done little Python coding

Then you are not in a position to make the prnouncements about Python's
effect on coding efficiency that you are pronouncing, in this and other
threads.

> I can give some more examples but I'll probably be told that I'm using
> the wrong tools!

You should gain a lot more experience using Python for productive work,
before declaring any effects on productive work inherent to the language
design.

> Which suggest there is a problem

Or that the programming tools of 25 years ago compare poorly to today's
tools.

Even tools that have existed for 25 years have benefited from the
intervening time. No-one uses Emacs *as it was 25 years ago* and expects
to be as proficient as someone using Emacs as it is today.

-- 
 \“Beware of bugs in the above code; I have only proved it |
  `\ correct, not tried it.” —Donald Knuth, 1977-03-29 |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?


On 25/07/2016 01:40, Gregory Ewing wrote:

BartC wrote:



So I still think it's fragile, meaning you have to take a lot of extra
care.


The practical experience of a very large number of Python
programmers suggests that it requires very little additional
care over and above that normally required for programming.

What's your experience? How often has this caused you trouble,
and what proportion is it of all the Python programming you've
done?



I've done little Python coding but still, having to use kid gloves for 
indents does figure quite a bit in that.


I can give some more examples but I'll probably be told that I'm using 
the wrong tools! Which suggest there is a problem, but the effort has 
gone into working around them using external tools. (But understandable 
if the language design was fixed 25 years ago.)


For example:

if cond:
a
b

I want to comment out the if statement temporarily, but I also have to 
fix the indents:


#if cond:
a
b

(Or add the comment and insert a dummy 'if 1:'.)

Or I want to add a temporary condition around:

a
b

which again requires me to indent those statements (and unindent them 
again later). Or I want to permanently have a commented out #if guard 
around some code:


#if cond:
a
b

to be uncommented from time to time (to do with debugging). But it's not 
as simple as just uncommenting that one line.


Or I want to have a temporary print statement within a block, but it 
needs to be at the right indentation. Not a great imposition, but it's 
now less visible as a temporary addition.


Or I need to move or copy code from one location to another, but the 
indentation levels are different. This would need fixing in other 
languages too, but if this is part of a temporary try out which will 
change again a few minutes later, I can dispense with the correct 
indentation in another language, until the code is more permanent.


In short, because correct indentation is required at all times, it's 
less flexible when you want to do a lot of messing around.


Now, if I was going to do a LOT of Python coding, then I would solve 
most of those problems (by having my own tool to superimpose a more 
amenable syntax on the language). For casual work though I have to go 
along with the indent scheme. (And there are usually other issues with 
Python that are more troublesome than getting the layout right.)


I'll leave you with a code fragment that might be pasted from elsewhere 
(it's not meant to mean anything):


if cond:
a
b
c

The question is: is this the whole block? We don't know, as we can't see 
what came next. But if now I add the next line, and it was this 
(anything actually with one less indent):


if cond2:

then yes it was the whole block, IF we assume an indent didn't get 
clobbered in the process! But if the line happened to be:


else:

now we know for sure.


--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?

2016-07-24 Thread Gregory Ewing


BartC wrote:
(They don't need to be elaborate to start being confusing. Take 'int 
*a[]' and 'int (*a)[]'; one of these is an array of pointers, the other 
a pointer to an array. Quite different! But which is which?


Where have you seen 'int (*a)[]' used? I don't think I've
ever seen any real-life C code that used a pointer to an
array, as opposed to a pointer to the first element of the
array. Usually it would just be declared either 'int a[]'
or 'int *a'.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?

On Monday, July 25, 2016 at 1:33:48 AM UTC+5:30, BartC wrote:
> On 24/07/2016 20:00, Chris Angelico wrote:
> > On Mon, Jul 25, 2016 at 4:14 AM, BartC  wrote:
> 
> > A skilled craftsman in any field will choose to use quality tools.
> 
> Materials (ie. languages) are important too.
> 
> > So why do you use
> > "dumb editor" as a line of argument, rather than getting a smarter
> > editor?
> 
> Perhaps because I prefer to use my own languages and I don't have anyone 
> writing the specialist tools for me that would be necessary.

This language-vs-IDE divide has been recogized:
http://blog.osteele.com/posts/2004/11/ides/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?

2016-07-24 Thread Gregory Ewing


BartC wrote:

On 24/07/2016 14:24, Chris Angelico wrote:


No, it's an example of how *mixing tabs and spaces* can go wrong. And
in fact will always go wrong unless you legislate the width of a tab.


That's easy to say. How do you actually ensure that they aren't mixed? 
The software may not highlight the difference.


Python 3 will tell you immediately, since it forbids
mixing tabs and spaces.

>>> def f():
...  a
... b
  File "", line 3
b
^
TabError: inconsistent use of tabs and spaces in indentation

So I still think it's fragile, meaning you have to take a lot of extra 
care.


The practical experience of a very large number of Python
programmers suggests that it requires very little additional
care over and above that normally required for programming.

What's your experience? How often has this caused you trouble,
and what proportion is it of all the Python programming you've
done?

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: New to programming and asking about accessibility with jaws screen reader.

2016-07-24 Thread Jacob Kruger


Presume you're talking about python idle IDE?


Forget it, and, like said, I use edSharp programmers text editor, and 
work from command line/console when want to test/run my code.



Stay well


Jacob Kruger
Blind Biker
Skype: BlindZA
"Resistance is futile, but, acceptance is versatile..."

On 2016-07-25 12:14 AM, josphine said wrote:

Thanks for your care,
Downloaded it from the python download page, (86-64 bit).
It reads only the menus, when i try to write anything , readable only with the 
curser,,.

Maybe i don't know exactly how to use it,
So if possible that anyone walk with me step by step??
Sorry for that.
Thanks, god bless you all.

Sent from my iPhone


On Jul 24, 2016, at 11:52 PM, Jacob Kruger  wrote:

What part is not accessible?


Ask since while haven't really gone past 3.4 and 3.5.1, at times, I generally 
work with specific text/code editors, and the command line window, and this 
works fine for me with both NVDA, and jaws 17 at times.


Stay well


Jacob Kruger
Blind Biker
Skype: BlindZA
"Resistance is futile, but, acceptance is versatile..."


On 2016-07-24 10:04 PM, josphine said wrote:
Hello,
I have downloaded python3.6 and found it is not accessible with jaws 17.
So, is there any  skripts for jaws for that?
Or any suggestions?
Every guidance will highly appreciated.
Thanks.




--
https://mail.python.org/mailman/listinfo/python-list

Re: New to programming and asking about accessibility with jaws screen reader.

2016-07-24 Thread Jacob Kruger


What part is not accessible?

Ask since while haven't really gone past 3.4 and 3.5.1, at times, I 
generally work with specific text/code editors, and the command line 
window, and this works fine for me with both NVDA, and jaws 17 at times.


Stay well


Jacob Kruger
Blind Biker
Skype: BlindZA
"Resistance is futile, but, acceptance is versatile..."

On 2016-07-24 10:04 PM, josphine said wrote:

Hello,
I have downloaded python3.6 and found it is not accessible with jaws 17.
So, is there any  skripts for jaws for that?
Or any suggestions?
Every guidance will highly appreciated.
Thanks.


--
https://mail.python.org/mailman/listinfo/python-list

Re: Depending on enum34 from a library

2016-07-24 Thread Ben Finney

Vasiliy Faronov  writes:

> If I simply depend on enum34, it will install a module named `enum`
> even in Python 3.4+ environments, and that could shadow the stdlib
> module.

As far as I know, ‘enum34’ is intended to provide all the same features
as the latest Python 3 standard library's ‘enum’ library.

> Personally I would be very surprised if installing a library
> caused an unrelated stdlib module to be replaced with a third-party
> one, even if it's "just" a backport. However, in my environments,
> `sys.path` is such that stdlib comes before site-packages -- perhaps
> this is normal enough that I can rely on it?

I think that this is similar to using the ‘unit2’ library, which is
intended to be used in projects to allow Python 2 and Python 3 to run
the same code to import ‘unittest’ and get the features of the latest
Python 3 ‘unittest’.

That is, the existence of ‘enum34’ is intended to allow you to just
depend on that library, import ‘enum’, and your code will work correctly
in Python 2 and Python 3 unchanged.

You are then using a Python 3 feature, just ported to an external
library. The advantage is that when eventually you stop supporting
Python 2, you can drop the external library, and your code keeps on
importing ‘enum’ and works.

Now, you may not trust that will work as seamlessly as described! That's
reasonable, and it is your choice whether the risk is worth it.

Consider the maintainer of the library, consider what they say about how
the library is expected to be used now and in the future, and choose
which risk to take.

-- 
 \“If one tells the truth, one is sure, sooner or later, to be |
  `\   found out.” —Oscar Wilde, _Phrases and Philosophies for the Use |
_o__)  of the Young_, 1894 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?


On 24/07/2016 22:08, Chris Angelico wrote:

On Mon, Jul 25, 2016 at 6:03 AM, BartC  wrote:



Perhaps because I prefer to use my own languages and I don't have anyone
writing the specialist tools for me that would be necessary.


So because you've chosen to use your own languages, you are frustrated
at Python because you're not using a decent editor?


My point is that with a bit more thought into the design of a language, 
clever tools would be less important. A language should stand by itself 
and not lean on specialist tools to be make it more usable.


A solid end-of-block symbol (as you get with 'else' and 'except' because 
then you KNOW that's the end of that block) would have been welcome with 
the Python indent scheme.



Get yourself
something nice and configurable, so that when you open a Python file
it gives you the features you need. I use SciTE,


I have one big problem with most editors (including SciTE): they are not 
properly line-oriented. If you hold down Backspace in the middle of a 
line, it won't just delete until it hits the beginning of the line; it 
keeps going! I can't live with that: editing would be like walking on 
eggshells. I need hard line stops. (I can't touch type; I need to look 
at the keyboard a lot.)


(And SciTE won't support a custom language for highlighting and stuff. 
Maybe it's configurable, but there seems to be a lexer module that needs 
to be provided. Suddenly it seems a lot of work to do.)



Why is this such a problem? Why is it so hard?


Who says it's a problem? I'm quite happy with the screen editors I use 
that are little changed since the early 80s (and before that I used line 
editors; now those /were/ horrible).



You might know that type declarations in C, as soon as you go beyond the
basics, become completely impossible and convoluted.



When do you get those uber-convoluted declarations in C?


(They don't need to be elaborate to start being confusing. Take 'int 
*a[]' and 'int (*a)[]'; one of these is an array of pointers, the other 
a pointer to an array. Quite different! But which is which?


And when you start dealing with pointers to functions, now you're 
talking! And yes C++ takes this to a whole new dimension. What a 
language...)



And for block delimiting, it uses neither tabbed indents or braces!)


Sure. You're most welcome to use that. But it doesn't mean that Python
is unusable.


It's not unusable. Just a minor nuisance (working with Python using my 
editor). And troublesome pasting Python code from elsewhere which is 
always full of spaces rather than tabs. (Sometimes uneven mixes of 
spaces too.)


The Python indent thing isn't a big deal. But having 'end' after each 
(final) block would have made life just a bit simpler.


The whole topic is a trivial point of syntax. (My only issue with 'pass' 
is that, for some inexplicable reason, my fingers always type it is 
'#pass'.)



Plus, I'd much rather trust Python in production than something
custom-made, even by me. The performance, reliability, and security of
a well-respected language far outstrip anything I could build.


Well, performance is where I usually have an edge at the minute (with my 
own interpreted language). But if I had to recommend a language, it 
would have to be Python (I can't be dealing with users and support and 
all that...)


--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: New to programming and asking about accessibility with jaws screen reader.

On Mon, Jul 25, 2016 at 6:04 AM, josphine said
 wrote:
> I have downloaded python3.6 and found it is not accessible with jaws 17.
> So, is there any  skripts for jaws for that?

Exactly what did you download, and where from?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?

On Mon, Jul 25, 2016 at 6:03 AM, BartC  wrote:
> On 24/07/2016 20:00, Chris Angelico wrote:
>>
>> On Mon, Jul 25, 2016 at 4:14 AM, BartC  wrote:
>
>
>> A skilled craftsman in any field will choose to use quality tools.
>
> Materials (ie. languages) are important too.

Materials, tools, same difference. (Not sure I could even draw the
line in software, and ultimately, my line of argument applies equally
to both.)

>> So why do you use
>> "dumb editor" as a line of argument, rather than getting a smarter
>> editor?
>
>
> Perhaps because I prefer to use my own languages and I don't have anyone
> writing the specialist tools for me that would be necessary.

So because you've chosen to use your own languages, you are frustrated
at Python because you're not using a decent editor? Get yourself
something nice and configurable, so that when you open a Python file
it gives you the features you need. I use SciTE, and it quite happily
is currently working with text, Pike, Pike Module, reStructuredText,
HTML, SRT, and Python files, and that's counting only the ones that I
have loaded in it right at this instant. Had some C files up recently
(both .c and .h - was editing CPython), and various other things.
SciTE doesn't recognize .srt files, so it treats them as plain text -
as in, like a dumb editor would. Even if your own language can't be
parsed using any existing parser (adding language support usually
isn't that hard, if the same parser can be reused), you can still make
use of smart editor features for all other languages you work with.
Why is this such a problem? Why is it so hard?

>> I don't have a lot of sympathy for people who use suboptimal tools and
>> expect everything to work for them. Sure, sometimes you're forced to
>> use something less than ideal (maybe you're stuck on someone else's
>> Windows box and good tools simply aren't there, and you can't go
>> installing a ton of stuff just to get started), but then you KNOW
>> you're working in bad conditions. You don't make that your normal
>> life.
>
> Some of us are used to working with minimalist tools and can be extremely
> productive with them.

And then you complain that the language is "fragile" or in some way
frustrating to you. Because you've restricted yourself to minimalist
tools. Go ahead! Be productive. I'm sure there are people out there
saying "I'm used to working with C and can be extremely productive
with it". Let 'em. Me, I'll use high level languages and be even more
productive. Thanks.

> But since you used some C, let me give an example of poor design from that
> language (there are plenty; I've written up quite a big collection of them).
>
> You might know that type declarations in C, as soon as you go beyond the
> basics, become completely impossible and convoluted. I've never managed to
> get my head around them.
>
> There are utilities such as 'Cdecl' that are used to convert a C declaration
> to English, and vice versa. That's how good a feature they are!
>
> So what would have been a better solution here: to have fixed the language,
> or to have grafted on a simpler type declaration scheme that could co-exist
> with the old one; or to have ignored the problem and depended on using
> external tools?
>
> Or just insisted that everyone learns that arcane aspect of C, despite it
> being unreadable and error-prone.

When do you get those uber-convoluted declarations in C? Sure, they
come up in C++ (which is why the language grew some features to manage
that complexity), but outside of demonstration code, when do you get
actual declarations of massively-nested constructs? I've literally
*never* seen them - not rarely, NEVER - in production code.

> (My own solution is that I use a home-made language in place of C, which has
> fixed most such problems. So my main 'tool' is a custom-made language.
>
> And for block delimiting, it uses neither tabbed indents or braces!)

Sure. You're most welcome to use that. But it doesn't mean that Python
is unusable.

Plus, I'd much rather trust Python in production than something
custom-made, even by me. The performance, reliability, and security of
a well-respected language far outstrip anything I could build.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: New to programming and asking about accessibility with jaws screen reader.

2016-07-24 Thread Joseph Lee

Hi,
How are you running Python - via Command Prompt, perhaps? It might be better
to ask a list like program-l (a dedicated programming list for blind devs).
Cheers,
Joseph

-Original Message-
From: Python-list
[mailto:python-list-bounces+joseph.lee22590=gmail@python.org] On Behalf
Of josphine said
Sent: Sunday, July 24, 2016 1:04 PM
To: python-list@python.org
Subject: New to programming and asking about accessibility with jaws screen
reader.

Hello,
I have downloaded python3.6 and found it is not accessible with jaws 17.
So, is there any  skripts for jaws for that? 
Or any suggestions?
Every guidance will highly appreciated.
Thanks.
-- 
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Depending on enum34 from a library

2016-07-24 Thread Vasiliy Faronov

Hi all,

I'm building a Python library where I want to use Python 3.4-style
enums. Because I need to support Python 2.7, I'm considering using
enum34 [1]. But I'm not sure how to do this:

If I simply depend on enum34, it will install a module named `enum`
even in Python 3.4+ environments, and that could shadow the stdlib
module. Personally I would be very surprised if installing a library
caused an unrelated stdlib module to be replaced with a third-party
one, even if it's "just" a backport. However, in my environments,
`sys.path` is such that stdlib comes before site-packages -- perhaps
this is normal enough that I can rely on it?

Or I could change my setup.py to include enum34 in `install_requires`
only if running on Python 2.7. But that will make my distribution's
metadata dynamic, which doesn't sound like a good idea [2]. At the
very least, I think it will prevent me from building a universal
wheel.

So, what's the best current practice here?

[1] https://pypi.python.org/pypi/enum34
[2] https://mail.python.org/pipermail/distutils-sig/2009-July/012826.html


-- 
Vasiliy
-- 
https://mail.python.org/mailman/listinfo/python-list

New to programming and asking about accessibility with jaws screen reader.

2016-07-24 Thread josphine said

Hello,
I have downloaded python3.6 and found it is not accessible with jaws 17.
So, is there any  skripts for jaws for that? 
Or any suggestions?
Every guidance will highly appreciated.
Thanks.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?

2016-07-24 Thread GIOVANNI ZIBORDI COBRAF MODENA via Python-list


On 24/07/2016 20:00, Chris Angelico wrote:

On Mon, Jul 25, 2016 at 4:14 AM, BartC  wrote:



A skilled craftsman in any field will choose to use quality tools.


Materials (ie. languages) are important too.


So why do you use
"dumb editor" as a line of argument, rather than getting a smarter
editor?


Perhaps because I prefer to use my own languages and I don't have anyone 
writing the specialist tools for me that would be necessary.



I don't have a lot of sympathy for people who use suboptimal tools and
expect everything to work for them. Sure, sometimes you're forced to
use something less than ideal (maybe you're stuck on someone else's
Windows box and good tools simply aren't there, and you can't go
installing a ton of stuff just to get started), but then you KNOW
you're working in bad conditions. You don't make that your normal
life.


Some of us are used to working with minimalist tools and can be 
extremely productive with them.


But since you used some C, let me give an example of poor design from 
that language (there are plenty; I've written up quite a big collection 
of them).


You might know that type declarations in C, as soon as you go beyond the 
basics, become completely impossible and convoluted. I've never managed 
to get my head around them.


There are utilities such as 'Cdecl' that are used to convert a C 
declaration to English, and vice versa. That's how good a feature they are!


So what would have been a better solution here: to have fixed the 
language, or to have grafted on a simpler type declaration scheme that 
could co-exist with the old one; or to have ignored the problem and 
depended on using external tools?


Or just insisted that everyone learns that arcane aspect of C, despite 
it being unreadable and error-prone.


(My own solution is that I use a home-made language in place of C, which 
has fixed most such problems. So my main 'tool' is a custom-made language.


And for block delimiting, it uses neither tabbed indents or braces!)

--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

BASTARD NAZIST MAFIOSO SALVATORE SAL GALATIOTO WANTS TO GET MILAN OUT OF EXTREMELY KILLING CASH FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE) + COLOMBIAN & ITALIAN AMERICAN MAFIA. THESE ARE " THE MISTERI

BASTARD NAZIST MAFIOSO SALVATORE SAL GALATIOTO WANTS TO GET MILAN OUT OF
EXTREMELY KILLING CASH FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE) + COLOMBIAN &
ITALIAN AMERICAN MAFIA. THESE ARE " THE MISTERIOUS CHINESE FUNDS" HE IS BRAYING
HE HAS FOR MILAN!

I'M A VERY HIGH DEGREE FREEMASON AND I CAN SUPER ULTRA EXTRA ENSURE YOU THAT
"THE FAMOUS MYSTERIOUS MASONIC SECRET CHINESE FUNDS" WHO MAY WANT TO BUY AC
MILAN, ARE ACTUALLY RUSSIAN MAFIA ( NAZIFASCIST DESPOTS, MEGA PRINCIPAL OF
MURDERS AND SLAUGHTERS, SEXUALLY PERVERT VLADIMIR PUTIN AND SILVIO BERLUSCONI,
ARE VERY UNITED BY MEGA MAFIA MONEY LAUNDERING, SILVIO BERLUSCONI DOES, SINCE
DECADES, FOR RUSSIAN MAFIA, UNDER BLOODTHIRSTY DICTATOR VLADIMIR PUTIN'S
PROTECTION AND SUPERVISION). TRIADE: SO CHINESE MAFIA. AS MUCH AS COLOMBIAN
MAFIA, PANAMANIAN MAFIA (WHERE STINKY FELONIOUS WORM RICARDO MARTINELLI,
ANOTHER EXTREMELY CRIMINAL AND BRIBED COLLAR CLOSE TO BERLUSCONI, IS KING). AND
RUMANIAN MAFIA. AND MOROCCAN MAFIA. AND ITALIAN AMERICAN MAFIA. YES, ITALIAN
AMERICAN MAFIA. IF YOU DEEPLY INVESTIGATE, YOU'LL SEE THAT MEGA MAFIA MONEY
LAUNDERER SALVATORE SAL GALATIOTO FROM GALATIOTO SPORTS PARTNERS, UNITED TO
BASTARD PIG NICHOLAS GANCIKOFF FROM SOLAR INVESTMENT GROUP ( "SOLAR" IS MEANT,
OBV
IOUSLY, IRONICALLY, SARCASTCALLY.. SINCE STINKY, EXTREMELY DIRTY, SUPER EXTRA
OBSCURE MONEY "INVESTED" BY THIS REPUGNANT PORK THAT IS WELL KNOWN CRIMINAL
NICHOLAS GANCIKOFF, COME STRAIGHT FROM THE MOST CRUEL HEADSCUTTERS OF THIS
WORLD.. COME FROM TERRIFYING ASSASSINS FROM COLOMBIA, GUATEMALA, EL SALVADOR,
HONDURAS, SICILY, NAPLES, REGGIO CALABRIA) ARE CLOSE TO WORST NEW YORK KILLERS
FROM COSA NOSTRA'S FAMILIY OF GAMBINO ( WHICH HAS ALWAYS, ALSO, BEEN VERY CLOSE
TO THE BRAND NEW ADOLF HITTLER: DONALD TRUMP...
http://www.alternet.org/files/styles/story_image/public/story_images/trump_hitler.png
http://images.huffingtonpost.com/2016-02-27-1456595899-9124929-TrumpHitler-thumb.jpg
AND DONALD TRUMP IS A BEASTLY FASCIST AND MAFIOSO "BUSSINESSUZZEDDU" MAN, LIKE
SILVIO BERLUSCONI, WHO WANTS TO IMPOSE HITLERIAN DICTATORSHIPS IN POLITICS...
TO THEN, OBVIOUSLY, EXPLOIT THESE DICTATORSHIPS, TO KILL "INCOMMODIOUS, TELLING
THE TRUTH, TONGUES", AND TO MAKE, AT THE SAME TIME, HIS BANK ACCOUNTS IN
SINGAPORE, HONG KONG, CAYMAN, PANAMA AND BAHAMAS, FATTER AND FATTER OUT OF
BUILDING HIMSELF, FOR EXAMPLE, BIG HITLERIAN WALLS BETWEEN US AND MEXICO, ...
AND THAT WD BE JUST ONE LITTLE EXAMPLE OUT OF OTHER HUNDREDS WE COULD DO). FROM
COSA NOSTRA'S FAMILIES OF GENOVESE AND LUCCHESE!!! MOST LOVED BANKER BY ITALIAN
AMERICAN MAFIA, SALVATORE SAL GALATIOTO ( THIS WHEN HE WAS LEHMAN, BUT IS STILL
SO, NOW MORE THAN EVER) WAS BORN CLOSE TO TRAPANI, WHERE NUMBER ONE OF
WORLDWIDE COSA NOSTRA, MATTEO MESSINA DENARO, IS OWNER AND BOSS OF EVERYTHING.
THEY KNOW EACH OTHER EXTREMELY WELL.
https://en.wikipedia.org/wiki/Matteo_Messina_Denaro
THEY KISSED EACH OTHERS RIGHT ON THE LIPPS (MAMMASANTISSIMA'S STYLE)
https://nottecriminale.files.wordpress.com/2011/06/daniele-d-agnese.jpg?w=893&h=611
ALL THE TIMES THEY MET EACH OTHERS BY BIG NDRANGHETA'S RESTAURANT IN NEW YORK
QUEENS: "CUCINA A MODO MIO".
http://www.ibtimes.co.uk/queens-pizzeria-cucino-modo-mio-was-italian-mafia-cocaine-smuggling-operations-centre-new-york-1500126
http://www.ilfattoquotidiano.it/2015/05/08/ndrangheta-a-new-york-e-il-boss-disse-mi-sono-mangiato-un-rene-e-un-cuore/1664866/
MATTEO MESSINA DENARO IS ONE OF MAIN FUNDING OF " AL CAPONE OF FINANCE",
SALVATORE GALATIOSO'S ACTIVITY ( HE PUT IN HIS COMPANY OVER 2.5 BLNS $, THRU
THOUSANDS OF FIGUREHEADS). MORE IMPORTANT ITALIAN AMERICAN MAFIA'S BANKER,
SALVATORE SAL GALATIOTO, WAS BORN IN CASTELLAMARE DEL GOLFO: CENTRE OF MATTEO
MESSINA DENARO'S MEG-A-SSASSIN KINGDOM. PROVINCE OF TRAPANI. CASTELLAMARE DEL
GOLFO, FOR THE LAST 50 YEARS, HAS BEEN ONE OF MAIN POINTS, WHERE TONS OF DRUGS
ARRIVED FROM ASIA, TO THEN BE REFINED AND SENT TO NORTH AMERICA AND NORTH OF
EUROPE. EXTREMELY CRIMINAL "ITALIAN AMERICAN AND SICILIAN MAFIA'S CONSULTANT"
SALVATORE GALATIOTO, HAS ALWAYS BEEN VERY FULLY IMMERSED IN ASSASSIN COSA
NOSTRA'S ACTIVITY. ESPECIALLY WHEN WAS LEHMAN. BUT NOW MORE THAN EVER TOO. AS
IMMENSELY MAFIA MONEY LAUNDERERS SILVIO BERLUSCONI AND DONALD TRUMP. BOTH,
"COINCIDENTALLY", ALSO, VERY CONNECTED TO ALL COSANOSTRAS OF THIS WORLD, AND
TO "THE EVIL EMPIRE" THAT WAS LEHMAN BROTHERS.
http://www.independent.co.uk/news/world/europe/silvio-and-the-cosa-nostra-berlusconis-links-with-italian-organised-crime-confirmed-9358790.html
http://www.telegraph.co.uk/news/worldnews/europe/italy/8142948/Timeline-Silvio-Berlusconi-and-the-mafia.html
https://www.theguardian.com/world/2009/dec/04/silvio-berlusconi-linked-mafia-court
http://www.politico.com/magazine/story/2016/05/donald-trump-2016-mob-organized-crime-213910
http://www.politico.com/magazine/story/2016/05/donald-trump-2016-mob-organized-crime-213910
https://www.washingtonpost.com/politics/former-mafia-linked-figure-d

NAZIST MAFIOSO SAL GALATIOTO WANTS TO GET AC MILAN OUT OF EXTREMELY KILLING CASH FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE), COLOMBIAN & ITALIANAMERICAN MAFIA! THESE ARE "THE MISTERIOUS CHINESE FUNDS"

2016-07-24 Thread GIOVANNI ZIBORDI COBRAF MODENA via Python-list

NAZIST MAFIOSO SAL GALATIOTO WANTS TO GET AC MILAN OUT OF EXTREMELY KILLING
CASH FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE), COLOMBIAN & ITALIANAMERICAN
MAFIA! THESE ARE "THE MISTERIOUS CHINESE FUNDS" HE HAS FOR PEDOPHILE, ASSASSIN
SILVIO BERLUSCONI!

STINKY MAFIOSO SAL GALATIOTO WANTS TO GET AC MILAN OUT OF EXTREMELY KILLING CASH FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE), COLOMBIAN & ITALIANAMERICAN MAFIA! THESE ARE "THE MISTERIOUS CHINESE FUNDS"

2016-07-24 Thread GIOVANNI ZIBORDI COBRAF MODENA via Python-list

STINKY MAFIOSO SAL GALATIOTO WANTS TO GET AC MILAN OUT OF EXTREMELY KILLING
CASH FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE), COLOMBIAN & ITALIANAMERICAN
MAFIA! THESE ARE "THE MISTERIOUS CHINESE FUNDS" HE HAS FOR PEDOPHILE, ASSASSIN
SILVIO BERLUSCONI!

BASTARD MAFIOSO SALVATORE GALATIOTO WANTS TO GET MILAN OUT OF EXTREMELY KILLING CASH FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE) + ITALIANAMERICAN MAFIA! THESE ARE " THE MISTERIOUS CHINESE FUNDS" HE HA

2016-07-24 Thread GIOVANNI ZIBORDI COBRAF MODENA via Python-list

BASTARD MAFIOSO SALVATORE GALATIOTO WANTS TO GET MILAN OUT OF EXTREMELY KILLING
CASH FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE) + ITALIANAMERICAN MAFIA! THESE
ARE " THE MISTERIOUS CHINESE FUNDS" HE HAS FOR PEDOPHILE ASSASSIN NAZIST SILVIO
BERLUSCONI!

NAZIST MAFIOSO SALVATORE GALATIOTO WANTS TO GET MILAN OUT OF EXTREMELY KILLING CASH FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE) + ITALIANAMERICAN MAFIA! THESE ARE " THE MYSTERIOUS CHINESE FUNDS" HE HAS

2016-07-24 Thread GIOVANNI ZIBORDI COBRAF MODENA via Python-list

NAZIST MAFIOSO SALVATORE GALATIOTO WANTS TO GET MILAN OUT OF EXTREMELY KILLING
CASH FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE) + ITALIANAMERICAN MAFIA! THESE
ARE " THE MYSTERIOUS CHINESE FUNDS" HE HAS FOR PEDOPHILE ASSASSIN MAFIOSO
SILVIO BERLUSCONI!

BASTARD CRIMINAL SALVATORE GALATIOTO WANTS TO GET MILAN OUT OF KILLING CASH FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE) + ITALIAN AMERICAN MAFIA! THESE ARE "THE MYSTERIOUS CHINESE FUNDS" HE HAS FOR PED

2016-07-24 Thread GIOVANNI ZIBORDI COBRAF MODENA via Python-list

BASTARD CRIMINAL SALVATORE GALATIOTO WANTS TO GET MILAN OUT OF KILLING CASH
FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE) + ITALIAN AMERICAN MAFIA! THESE ARE
"THE MYSTERIOUS CHINESE FUNDS" HE HAS FOR PEDOPHILE ASSASSIN NAZIST MAFIOSO
SILVIO BERLUSCONI!!

FUCKING CRIMINAL SALVATORE GALATIOTO WANTS TO GET MILAN OUT OF KILLING CASH FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE) + ITALIAN AMERICAN MAFIA! THESE ARE "THE MYSTERIOUS CHINESE FUNDS" HE HAS FOR PED

2016-07-24 Thread GIOVANNI ZIBORDI COBRAF MODENA via Python-list

FUCKING CRIMINAL SALVATORE GALATIOTO WANTS TO GET MILAN OUT OF KILLING CASH
FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE) + ITALIAN AMERICAN MAFIA! THESE ARE
"THE MYSTERIOUS CHINESE FUNDS" HE HAS FOR PEDOPHILE ASSASSIN NAZIST MAFIOSO
SILVIO BERLUSCONI!!

BASTARD MAFIOSO NICHOLAS GANCIKOFF (SOLAR) WANTS TO GET MILAN OUT OF KILLING CASH FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE), COLOMBIAN & ITALIANAMERICAN MAFIA! THESE ARE "THE MISTERIOUS CHINESE FUNDS

2016-07-24 Thread GIOVANNI ZIBORDI COBRAF MODENA via Python-list

BASTARD MAFIOSO NICHOLAS GANCIKOFF (SOLAR) WANTS TO GET MILAN OUT OF KILLING
CASH FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE), COLOMBIAN & ITALIANAMERICAN
MAFIA! THESE ARE "THE MISTERIOUS CHINESE FUNDS" HE HAS FOR PEDOPHILE ASSASSIN
SILVIO BERLUSCONI!

FUCKING BASTARD NICHOLAS GANCIKOFF WANTS TO GET MILAN OUT OF KILLING CASH COMING FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE), COLOMBIAN & ITALIANAMERICAN MAFIA! THESE ARE " THE MYSTERIOUS CHINESE FUNDS

2016-07-24 Thread GIOVANNI ZIBORDI COBRAF MODENA via Python-list

FUCKING BASTARD NICHOLAS GANCIKOFF WANTS TO GET MILAN OUT OF KILLING CASH
COMING FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE), COLOMBIAN & ITALIANAMERICAN
MAFIA! THESE ARE " THE MYSTERIOUS CHINESE FUNDS" HE HAS FOR PEDOPHILE ASSASSIN
SILVIO BERLUSCONI!

BASTARD MAFIOSO NICHOLAS GANCIKOFF WANTS TO GET MILAN OUT OF KILLING CASH COMING FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE), COLOMBIAN & ITALIAN AMERICAN MAFIA! THESE ARE "THE MYSTERIOUS CHINESE FUNDS

2016-07-24 Thread GIOVANNI ZIBORDI COBRAF MODENA via Python-list

BASTARD MAFIOSO NICHOLAS GANCIKOFF WANTS TO GET MILAN OUT OF KILLING CASH
COMING FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE), COLOMBIAN & ITALIAN AMERICAN
MAFIA! THESE ARE "THE MYSTERIOUS CHINESE FUNDS" HE HAS FOR PEDOPHILE ASSASSIN
SILVIO BERLUSCONI!

SON OF A BITCH NICHOLAS GANCIKOFF WANTS TO GET MILAN OUT OF KILLING CASH COMING FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE), COLOMBIAN & ITALIAN AMERICAN MAFIA! THESE ARE " THE MYSTERIOUS CHINESE FUNDS

2016-07-24 Thread GIOVANNI ZIBORDI COBRAF MODENA via Python-list

SON OF A BITCH NICHOLAS GANCIKOFF WANTS TO GET MILAN OUT OF KILLING CASH COMING
FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE), COLOMBIAN & ITALIAN AMERICAN MAFIA!
THESE ARE " THE MYSTERIOUS CHINESE FUNDS" HE HAS FOR PEDOPHILE ASSASSIN SILVIO
BERLUSCONI!

SON OF A WHORE NICHOLAS GANCIKOFF WANTS TO GET MILAN OUT OF KILLING CASH COMING FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE), COLOMBIAN & ITALIAN AMERICAN MAFIA! THESE ARE " THE MYSTERIOUS CHINESE FUNDS

2016-07-24 Thread GIOVANNI ZIBORDI COBRAF MODENA via Python-list

SON OF A WHORE NICHOLAS GANCIKOFF WANTS TO GET MILAN OUT OF KILLING CASH COMING
FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE), COLOMBIAN & ITALIAN AMERICAN MAFIA!
THESE ARE " THE MYSTERIOUS CHINESE FUNDS" HE HAS FOR ASSASSIN PEDOPHILE SILVIO
BERLUSCONI!

Re: Why not allow empty code blocks?

On Mon, Jul 25, 2016 at 4:14 AM, BartC  wrote:
> OK. I understand that it is not possible to point out any kind of weakness
> of a language (any language not just Python!) because the counter-argument
> is always going to be about:
>
> Use syntax highlighting, use a smart editor, use a version control system,
> use a linter, use 'tabnanny', use tool X, Y or Z to get around the problems,
> use obscure language options..

Obscure? I guess - it's not like it's listed in the --help screen. Oh
wait. And of course, all you need to do is upgrade to Python 3 and it
becomes the default.

Wait, you lump "use a VCS" into the category of "stuff people tell you
that you're not really willing to do"? Are you saying you don't use
git, Mercurial, etc, etc, to track your projects? Then start using
one. Now. "Now-now", as Princess Anna says in the Italian dub.

> The thing is, if everyone does depend more on such tools, then it really
> doesn't matter exactly what the language does - the tools will take care of
> such details. So the language could delimit blocks using any scheme it
> likes, including use 'end', 'else' and so on.
>
> It only becomes important to people like me who use plain editors.

Yes, that's exactly right. Tell me, is this part of a linter or a
language compiler/interpreter?

rosuav@sikorsky:~$ cat 1.c
#include 
int main()
{
int months[12] = {31,28,31,30,31,30,31,31,30,31,30,31};
printf("The array is at %p.\n", months);
printf("There are %d days in December.\n", months[12]);
printf("And this is what 28 looks like: %s\n", months[1]);
}

rosuav@sikorsky:~$ gcc -Wall -O2 1.c
1.c: In function ‘main’:
1.c:7:9: warning: format ‘%s’ expects argument of type ‘char *’, but
argument 2 has type ‘int’ [-Wformat=]
  printf("And this is what 28 looks like: %s\n", months[1]);
 ^
1.c:6:2: warning: array subscript is above array bounds [-Warray-bounds]
  printf("There are %d days in December.\n", months[12]);
  ^
rosuav@sikorsky:~$

Today's C compilers emit warnings for things that yesterday's
third-party linters did. Is there virtue in running gcc with all
warnings disabled? Equally, is there a valid reason for choosing to
use a "plain editor" when you could use one that helps you?

A skilled craftsman in any field will choose to use quality tools.
They save time, and time is money. Are there any carpenters who
restrict themselves to hand tools? (Stylistic choice aside.
KirkwoodWorking has "hand tools Sunday" where he avoids all power
tools, and it's taking him months and months to finish one cabinet.
But the rest of the week, power tools win.) Would you, if given the
choice, use an ancient 80386 running MS-DOS in 4MB of RAM, or a modern
system running a modern OS in 16GB? Would you type your code on a
tablet computer or something with a real keyboard? So why do you use
"dumb editor" as a line of argument, rather than getting a smarter
editor?

I don't have a lot of sympathy for people who use suboptimal tools and
expect everything to work for them. Sure, sometimes you're forced to
use something less than ideal (maybe you're stuck on someone else's
Windows box and good tools simply aren't there, and you can't go
installing a ton of stuff just to get started), but then you KNOW
you're working in bad conditions. You don't make that your normal
life.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Convert from unsigned long long to PyLong

2016-07-24 Thread INADA Naoki

Thank you for reporting this issue.

I'll fix it in next release of mysqlclient

(MySQL-python has not been maintained for these years.  Please use mysqlclient.
It supports Python 3.)

On Fri, Jul 22, 2016 at 3:01 PM, Tian JiaLin  wrote:
> HI There,
>
> I'm using MySQLdb as the MySQL client. Recently I got a weird problem of this 
> library. After looking into it, I suspect the problem may related to the 
> conversion from unsigned long to PyLongObject.
>
> Here is the detail, If you are familiar with MySQLdb, the following snippet 
> is a way to query the data from MySQL:
>
>
> connection = MySQLdb.connect(...)
>
> connection.autocommit(True)
> try:
> cursor = connection.cursor()
> if not cursor.execute(sql, values) > 0:
> return None
> row = cursor.fetchone()
> finally:
> connection.close()
> return row[0]
>
>
> Sometimes the return value of execute method would be 18446744073709552000 
> even there is no matched data available. I checked the source code of the 
> library, the underlying implementation is 
> https://github.com/farcepest/MySQLdb1/blob/master/_mysql.c#L835,
>
> static PyObject *
> _mysql_ConnectionObject_affected_rows(
> _mysql_ConnectionObject *self,
> PyObject *args)
> {
> if (!PyArg_ParseTuple(args, "")) return NULL;
> check_connection(self);
> return 
> PyLong_FromUnsignedLongLong(mysql_affected_rows(&(self->connection)));
> }
>
> And here is the official doc for mysql_affected_rows 
> http://dev.mysql.com/doc/refman/5.7/en/mysql-affected-rows.html.
>
> Let me give a superficial understanding, please correct me if I were wrong.
>
> In a 64-bit system, the mysql_affected_rows is supposed to return a number of 
> unsigned long, which means the range should be 0 ~ 2^64 
> (18446744073709551616), How could it be possible the function 
> PyLong_FromUnsignedLongLong return a converted value larger than 2^64, that's 
> what I don't understand.
>
> Does anyone have some ideas of it?
>
>
> The versions of the components I used:
>
> Python: 2.7.6
> MySQL 5.7.11
> MySQLdb 1.2.5
>
>
> Thanks
> --
> https://mail.python.org/mailman/listinfo/python-list



-- 
INADA Naoki  
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?

2016-07-24 Thread alister

On Sun, 24 Jul 2016 19:14:10 +0100, BartC wrote:

> On 24/07/2016 15:51, Chris Angelico wrote:
>> On Mon, Jul 25, 2016 at 12:44 AM, BartC  wrote:
>>> Your attention is diverted, you're doing something on your desk, but
>>> you hit one of the keys by mistake. You might have pressed Delete or
>>> you might not. You look at the screen which has a 5000-line program
>>> open, and you see this (borrowing your example and with the cursor at
>>> "_"):
>>>
>>>  def f():
>>>  for x in seq:
>>>  do_this()
>>>  do_that()
>>>  _   do_more()
>>>
>>> Did you just unindent do_more(), or is that where it's meant to be?
>>> Undo may or may not help (or it may undo something is needed).
>>
>> Undo, redo. See what happened. Easy.
>>
>> Also, if you're regularly committing to source control, you can always
>> check the diff. Before you 'git commit', check what 'gitk' shows, or
>> before 'hg commit', have a glance at 'hg diff'. Make sure what you're
>> seeing is what you intend to change. Remember, code doesn't just
>> accidentally change; everything should have purpose, including
>> (especially) any indent/unindent.
>>
>> Source control protects you from everything other than multiple changes
>> since the last commit. So commit often. It'll save you a lot of time -
>> if not coding time, then debating-on-python-list time. :)
> 
> OK. I understand that it is not possible to point out any kind of
> weakness of a language (any language not just Python!) because the
> counter-argument is always going to be about:
> 
> Use syntax highlighting, use a smart editor, use a version control
> system, use a linter, use 'tabnanny', use tool X, Y or Z to get around
> the problems, use obscure language options..
> 
> The thing is, if everyone does depend more on such tools, then it really
> doesn't matter exactly what the language does - the tools will take care
> of such details. So the language could delimit blocks using any scheme
> it likes, including use 'end', 'else' and so on.
> 
> It only becomes important to people like me who use plain editors.
> 
> --
> Bartc

whichever language you use regardless of editor, there will have been 
design decisions made that could (by your logic) be considered flaws 
because an error made is not picked up by the compiler.

apple were recently bitten by "Goto Fail" an error that could not have 
happened in the same way with pythons indentation rules.
correct the design of your compiler for one type of error & you will find 
that you are now open to another.

IMHO typing pass to signify a deliberately empty block is a minor nuisance
(at worst) making it optional is more likely to lead to bugs 

either way my opinion is nut important because the decision has already 
been made.



-- 
I sat laughing snidely into my notebook until they showed me a PC running
Linux... And oh! It was as though the heavens opened and God handed down a
client-side OS so beautiful, so graceful, and so elegant that a million
Microsoft developers couldn't have invented it even if they had a hundred
years and a thousand crates of Jolt cola.

   -- Polly Sprenger, LAN Times
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?

2016-07-24 Thread Jonathan Hayward

I might point out something that captures something about pass: it is made
to do extra duty in web2py, which is meant to shield students from some of
the more preventable complexities of a LUM CLI, and you don't easily indent
code the way that Vim and Emacs, let alone a full IDE besides the IDE
nature of web2py, forces people to deal with. People getting up to speed
with Vim or Emacs, for anything that is usually indented, find and/or seek
out how to maintain indentation without hitting the space bar 4/8/12/...
times at the beginning of the next line.

And it works. It was probably not intended or even anticipated in the
design of Python, but my understanding is that the adapted usage works well.

And if I may put on asbestos longjohns, there is no reason I am aware of
why syntactic sugar, in the style of Python-influenced Coffeescript, could
not be modified to make "from __future__ import braces" represent a live
and active feature. The net effect of significant whitespace in Python is
that it provides one model to "say what you mean and mean what you say",
and everybody who understands the language recognizes the beginning and end
of a block, the end of a statement, a noop, etc. And this is pretty much
the job description of C-family language syntax etc. Now there are
advantages, namely no braces and no brace holy wars either, fewer Perlish
sigils as even a statement is usually ended by line break, and so on. But
Python-style and C-style syntax alike provide an unambiguous tool to
specify what you want, and an unambiguous means of interpreting what was
actually said. The non-C-style syntax was the biggest "steaming pile of
dinosaur dung" hurdle before ESR appreciated the language, but Python
syntax and C-style syntax are both adequate. They may or may not be equal,
but every instance of code which unambiguous Pythonic syntax is underscored
is an effect that should usually be equally easy to implement with C-style
syntax.

On Sun, Jul 24, 2016 at 1:14 PM, BartC  wrote:

> On 24/07/2016 15:51, Chris Angelico wrote:
>
>> On Mon, Jul 25, 2016 at 12:44 AM, BartC  wrote:
>>
>>> Your attention is diverted, you're doing something on your desk, but you
>>> hit
>>> one of the keys by mistake. You might have pressed Delete or you might
>>> not.
>>> You look at the screen which has a 5000-line program open, and you see
>>> this
>>> (borrowing your example and with the cursor at "_"):
>>>
>>>  def f():
>>>  for x in seq:
>>>  do_this()
>>>  do_that()
>>>  _   do_more()
>>>
>>> Did you just unindent do_more(), or is that where it's meant to be? Undo
>>> may
>>> or may not help (or it may undo something is needed).
>>>
>>
>> Undo, redo. See what happened. Easy.
>>
>> Also, if you're regularly committing to source control, you can always
>> check the diff. Before you 'git commit', check what 'gitk' shows, or
>> before 'hg commit', have a glance at 'hg diff'. Make sure what you're
>> seeing is what you intend to change. Remember, code doesn't just
>> accidentally change; everything should have purpose, including
>> (especially) any indent/unindent.
>>
>> Source control protects you from everything other than multiple
>> changes since the last commit. So commit often. It'll save you a lot
>> of time - if not coding time, then debating-on-python-list time. :)
>>
>
> OK. I understand that it is not possible to point out any kind of weakness
> of a language (any language not just Python!) because the counter-argument
> is always going to be about:
>
> Use syntax highlighting, use a smart editor, use a version control system,
> use a linter, use 'tabnanny', use tool X, Y or Z to get around the
> problems, use obscure language options..
>
> The thing is, if everyone does depend more on such tools, then it really
> doesn't matter exactly what the language does - the tools will take care of
> such details. So the language could delimit blocks using any scheme it
> likes, including use 'end', 'else' and so on.
>
> It only becomes important to people like me who use plain editors.
>
> --
> Bartc
>
>
> --
> Bartc
> --
> https://mail.python.org/mailman/listinfo/python-list
>

-- 
[image: Christos Jonathan Seth Hayward] 
*Jonathan Hayward*, a User Experience professional.

Email  • Flagship  Website
 • Github
 • *LinkedIn
* • Portfolio + More
 • *Recent Title
*
 • Skills 

Loads of talent and a thorough grounding in all major academic disciplines
supporting User Experience.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?

2016-07-24 Thread neceros

On Sunday, July 24, 2016 at 6:09:40 AM UTC-7, BartC wrote:
> On 24/07/2016 11:45, BartC wrote:
> > On 24/07/2016 11:35, BartC wrote:
> 
> > 'end' to terminate a block can be emulated of course:
> >
> > end=0
> >
> > def fn(a):
> > if a<=1:
> > return 1
> > else:
> > return fn(a-1)
> > end
> > end
> 
> Actually this is a good example of how tabs can go wrong (and how the 
> tab system /is/ fragile - sorry but it is).
> 
> I almost certainly wrote the above using 4 and 8 spaces for the tabs, 
> except for the 'return 1' where I must have used an actual tab by 
> mistake. (And I tested it now by doing just that, and posting in alt.test.)
> 
> So the original /looked/ correct in my Thunderbird newsreader before I 
> posted. But after I posted, that tab somehow got changed to 4 spaces, as 
> it now looks wrong.
> 
> In this instance, the result won't compile. But it's not hard to imagine 
> a much larger program where that change would go unnoticed, and the 
> result is still valid code**.
> 
> Then anyone copying and pasting the posted code, would have a program 
> with a bug in it.
> 
> Mysteriously however, Chris Angelico's reply which quoted my post, 
> showed a properly tabbed version! (Unless he fixed it manually.)
> 
> (** Where working code has been posted, then Python will have picked up 
> inconsistencies where tabs and spaces are mixed. However take this code:
> 
> def fn():
> if a:
> <8 spaces>pass
> 
> This looks fine in my editor when  is expanded to 4 spaces:
> 
> def fn():
>  if a:
>  pass
> 
> Python however doesn't like it (Python 2 doesn't anyway), because it 
> somehow assumes tabs expand to 8 spaces, so that the two indents look 
> like this to it:
> 
> def fn():
>  if a:
>  pass
> 
> So I can see a lot of problems whenever tabs are expanded differently:
> 
> a=1
> b=0
> 
> if a:
> if b:
> print ("One")
> <8 spaces>print ("Two")
> 
> In my editor with 4-space tabs, it looks like the code will print 
> nothing as the two print lines are aligned within the 'if b:' block. But 
> in Python 2, it will print "Two". Python 3 more wisely reports the 
> inconsistency.)
> 
> -- 
> Bartc

Don't use tabs. Ever. It's simple.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?

2016-07-24 Thread GIACOMO ZUCCO BITCOIN TECHNOLOGY CONSULTANT


On 24/07/2016 15:51, Chris Angelico wrote:

On Mon, Jul 25, 2016 at 12:44 AM, BartC  wrote:

Your attention is diverted, you're doing something on your desk, but you hit
one of the keys by mistake. You might have pressed Delete or you might not.
You look at the screen which has a 5000-line program open, and you see this
(borrowing your example and with the cursor at "_"):

 def f():
 for x in seq:
 do_this()
 do_that()
 _   do_more()

Did you just unindent do_more(), or is that where it's meant to be? Undo may
or may not help (or it may undo something is needed).


Undo, redo. See what happened. Easy.

Also, if you're regularly committing to source control, you can always
check the diff. Before you 'git commit', check what 'gitk' shows, or
before 'hg commit', have a glance at 'hg diff'. Make sure what you're
seeing is what you intend to change. Remember, code doesn't just
accidentally change; everything should have purpose, including
(especially) any indent/unindent.

Source control protects you from everything other than multiple
changes since the last commit. So commit often. It'll save you a lot
of time - if not coding time, then debating-on-python-list time. :)


OK. I understand that it is not possible to point out any kind of 
weakness of a language (any language not just Python!) because the 
counter-argument is always going to be about:


Use syntax highlighting, use a smart editor, use a version control 
system, use a linter, use 'tabnanny', use tool X, Y or Z to get around 
the problems, use obscure language options..


The thing is, if everyone does depend more on such tools, then it really 
doesn't matter exactly what the language does - the tools will take care 
of such details. So the language could delimit blocks using any scheme 
it likes, including use 'end', 'else' and so on.


It only becomes important to people like me who use plain editors.

--
Bartc

--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

SON OF WHORE NICHOLAS GANCIKOFF WANTS TO GET MILAN OUT OF KILLING CASH COMING FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE) COLOMBIAN & ITALIANAMERICAN MAFIA! THESE ARE "THE MYSTERIOUS CHINESE FUNDS" HE

SON OF WHORE NICHOLAS GANCIKOFF WANTS TO GET MILAN OUT OF KILLING CASH COMING
FROM RUSSIAN MAFIA, CHINESE MAFIA (TRIADE) COLOMBIAN & ITALIANAMERICAN MAFIA!
THESE ARE "THE MYSTERIOUS CHINESE FUNDS" HE HAS X ASSASSIN, PEDOPHILE, NAZI
SILVIO BERLUSCONI!

Re: Why not allow empty code blocks?

On Mon, Jul 25, 2016 at 12:44 AM, BartC  wrote:
> Your attention is diverted, you're doing something on your desk, but you hit
> one of the keys by mistake. You might have pressed Delete or you might not.
> You look at the screen which has a 5000-line program open, and you see this
> (borrowing your example and with the cursor at "_"):
>
>  def f():
>  for x in seq:
>  do_this()
>  do_that()
>  _   do_more()
>
> Did you just unindent do_more(), or is that where it's meant to be? Undo may
> or may not help (or it may undo something is needed).

Undo, redo. See what happened. Easy.

Also, if you're regularly committing to source control, you can always
check the diff. Before you 'git commit', check what 'gitk' shows, or
before 'hg commit', have a glance at 'hg diff'. Make sure what you're
seeing is what you intend to change. Remember, code doesn't just
accidentally change; everything should have purpose, including
(especially) any indent/unindent.

Source control protects you from everything other than multiple
changes since the last commit. So commit often. It'll save you a lot
of time - if not coding time, then debating-on-python-list time. :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Detecting the trivial can be non-trivial (was Why not allow empty code blocks?)

On Sunday, July 24, 2016 at 3:45:40 PM UTC+5:30, Ben Bacarisse wrote:
> Rustom Mody  writes:
> 
> > For a long time the re → dfa transformation went and was taught the 
> > laborious
> > route:
> > re → nfa-with-ε-transitions → nfa-without-ε-transitions → dfa
> >
> > https://en.wikipedia.org/wiki/Thompson's_construction
> > https://en.wikipedia.org/wiki/Powerset_construction
> >
> > Now there is a direct, straightforward method which only becomes available
> >  (thinkable) when we have a null regular expression:
> > https://drona.csa.iisc.ernet.in/~deepakd/fmcs-06/seminars/presentation.pdf
> 
> "Now" seems an odd thing to say since the technique is quite old.  It
> would be better to say that it has been re-discovered.

The “Now” was not meant time-ly!
> 
> But thanks for the link -- I was unaware of the idea.  Unfortunately the
> material is not well presented there (lower-case phi for the empty set?)
> but in trying to understand what it was saying I found:
> 
> https://www.cl.cam.ac.uk/~so294/documents/jfp09.pdf
> 
> which, in my opinion, does it very much better.


Yeah
I think the one used when I was studying was this one
http://www2.in.tum.de/hp/file?fid=571

Anyway my main point was that getting trivial cases right is damn hard
And eliding the trivial case from a notation — because its too trivial to be 
useful
is damn stupid
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?


On 24/07/2016 13:17, Steven D'Aprano wrote:

On Sun, 24 Jul 2016 08:35 pm, BartC wrote:



Given an otherwise correctly typed program that compiles with no errors,
then it is very easy (if Backspace or Delete is inadvertently pressed
for example), for an indent to disappear without your noticing,


Not really. It depends on the editor, but typically you need to have your
text insertion point somewhere in the indent.

And when you do accidentally press Delete, what happens? The high-level
structure of the code changes. Typically things will no longer align:

def f():
for x in seq:
do_this()
do_that()
do_more()

which is a SyntaxError.


Unless it happened on the do_more() line.


It requires quite the coincidence before you can
accidentally delete an indent and have the code still run.


On my editor, if I press the cursor up and down keys, the current column 
moves to the left if I pass a blank line and stays there. In Python 
code, then the cursor will often end up at the start of an indent.


 Far more likely

is that accidentally pressing delete will break the code in a way that
can't be detected until runtime:

def f():
for x in seq:
do_this()
d_that()
do_more()


Yes, I mentioned that; it will cause some exception. But moving 
do_more() out of the loop above might not do so.




Conclusion: if you're the sort of person who habitually presses the Delete
or Backspace key without paying attention, you're going to have a bad time.


It happens in all sorts of ways.

Your attention is diverted, you're doing something on your desk, but you 
hit one of the keys by mistake. You might have pressed Delete or you 
might not. You look at the screen which has a 5000-line program open, 
and you see this (borrowing your example and with the cursor at "_"):


 def f():
 for x in seq:
 do_this()
 do_that()
 _   do_more()

Did you just unindent do_more(), or is that where it's meant to be? Undo 
may or may not help (or it may undo something is needed).


If you see this however:

 def f():
 for x in seq:
 do_this()
 _o_that()
 do_more()

You can see that o_that() doesn't look like its neighbours, and you can 
verify there's no o_that() in scope.


--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?

On Mon, 25 Jul 2016 12:05 am, BartC wrote:

>> No, it's an example of how *mixing tabs and spaces* can go wrong. And
>> in fact will always go wrong unless you legislate the width of a tab.
> 
> That's easy to say. How do you actually ensure that they aren't mixed?
> The software may not highlight the difference.

(1) Use a better editor.

(2) Use a linter that checks for dodgy indentation.

(3) Run the "tabnanny" module on your script:

python -m tabnanny myscripy.py

(4) Run Python 2.7 with the -t option to warn about inconsistent 
tab usage, or -tt to raise errors.

(5) Or for that matter any version of Python going all the way
back to Python 1.5, if not older. There has been no excuse for 
getting bitten by mixed tabs/spaces since at least 1998.

(6) Or upgrade to Python 3, which will automatically enforce the 
rule about not mixing tabs and spaces.

-- 
Steven
“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: Why not allow empty code blocks?

2016-07-24 Thread Marco Sulla via Python-list

On 24 July 2016 at 14:48, Chris Angelico  wrote:
> Maybe the people who are most worried about this can enact a
> simple rule: no dedent without a blank line? That can easily be
> verified by a script, and it'd protect against most of the given
> examples. It's not too much effort (after any reasonable-sized block
> you'll probably have a blank anyway, so it's only the tiniest of loops
> that would be affected). And no language changes are needed :)

I'm incredibly in favor of such a modification, but maybe this is work
for a linter.

Honestly, I find the "pass" statement very clear and simple. There's
more misleading problems in Python syntax, like this:

someFunction(
"param1"
"param2"  # comma missed, there will be only one parameter "param1param2"
)

and this one too:

class Parent(Base):
__tablename__ = 'parent'
id = Column(Integer, primary_key=True)
children = relationship("Child"),  # comma inserted by error.
children will be a tuple and SQLAlchemy will fail with misleading
errors
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?


On 24/07/2016 14:24, Chris Angelico wrote:

On Sun, Jul 24, 2016 at 11:09 PM, BartC  wrote:

Actually this is a good example of how tabs can go wrong (and how the tab
system /is/ fragile - sorry but it is).

I almost certainly wrote the above using 4 and 8 spaces for the tabs, except
for the 'return 1' where I must have used an actual tab by mistake. (And I
tested it now by doing just that, and posting in alt.test.)



No, it's an example of how *mixing tabs and spaces* can go wrong. And
in fact will always go wrong unless you legislate the width of a tab.


That's easy to say. How do you actually ensure that they aren't mixed? 
The software may not highlight the difference.


I use 100% tabs in my editor. While in Thunderbird, I have to use 100% 
spaces otherwise it will screw up. But what stops me pressing tab out of 
habit? The code looks right, I post it, and if it then goes wrong, I 
might not notice. Nor would anyone else.


Also, sometimes you want to paste code into Thunderbird that contains 
tabs; that can be erratic too.


And very often I want to post other people's code that is full of spaces 
(notably from Thunderbird), into mine that is full of tabs. (I have the 
same problem with other languages, but there it's largely cosmetic.)


So I still think it's fragile, meaning you have to take a lot of extra care.

--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?

On Sun, Jul 24, 2016 at 11:11 PM, Marco Sulla
 wrote:
> On 24 July 2016 at 14:48, Chris Angelico  wrote:
>> Maybe the people who are most worried about this can enact a
>> simple rule: no dedent without a blank line? That can easily be
>> verified by a script, and it'd protect against most of the given
>> examples. It's not too much effort (after any reasonable-sized block
>> you'll probably have a blank anyway, so it's only the tiniest of loops
>> that would be affected). And no language changes are needed :)
>
> I'm incredibly in favor of such a modification, but maybe this is work
> for a linter.

Sorry if I wasn't clear, but I definitely did mean for this to be the
work of a linter ("verified by a script", and "no language changes are
needed").

> Honestly, I find the "pass" statement very clear and simple. There's
> more misleading problems in Python syntax, like this:
>
> someFunction(
> "param1"
> "param2"  # comma missed, there will be only one parameter "param1param2"
> )

That can also be caught by a linter; it can also be caught by a
standard habit of ALWAYS putting trailing commas on anything that gets
wrapped. It's not so common with function calls, but the equivalent
situation with list display is:

colors = [
"red",
"green"
"blue",
"yellow",
"cyan",
"magenta"
]

Same problem with the missed comma, but it's also common enough to put
one after "magenta" too, and it's a great protection. Again, you could
have your linter demand this, if you wanted to (and put the linter
into your pre-commit hook or equivalent), or you could just eyeball it
("nothing at the end of the line? really?").

> and this one too:
>
> class Parent(Base):
> __tablename__ = 'parent'
> id = Column(Integer, primary_key=True)
> children = relationship("Child"),  # comma inserted by error.
> children will be a tuple and SQLAlchemy will fail with misleading
> errors

Hmm, that's a bit harder to pin down, but since *none* of the members
will have commas here, I'd be surprised to spot one there. Though part
of the problem here is that SQLAlchemy is such a gigantic package that
its error messages tend to be a bit confusing. But that said, here's
what happened when I tried it:

rosuav@sikorsky:~$ python3
Python 3.6.0a3+ (default:bff31254a0f0, Jul 17 2016, 17:39:49)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from sqlalchemy.ext.declarative import declarative_base
>>> from sqlalchemy import Column, Integer
>>> from sqlalchemy.orm import relationship
>>> Base = declarative_base()
>>> class Parent(Base):
... __tablename__ = 'parent'
... id = Column(Integer, primary_key=True)
... children = relationship("Child"),
...
/usr/local/lib/python3.6/site-packages/sqlalchemy/ext/declarative/base.py:297:
SAWarning: Ignoring declarative-like tuple value of attribute
children: possibly a copy-and-paste error with a comma left at the end
of the line?
  "left at the end of the line?" % k)
>>> Parent

>>>
rosuav@sikorsky:~$ python3 -m pip freeze|grep -i alchemy
SQLAlchemy==1.0.11

Maybe enabling warnings is all you need, or maybe it depends on the
version of SQLAlchemy. In any case, nice spot, declarative-base!

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?

On Sun, Jul 24, 2016 at 11:09 PM, BartC  wrote:
> Actually this is a good example of how tabs can go wrong (and how the tab
> system /is/ fragile - sorry but it is).
>
> I almost certainly wrote the above using 4 and 8 spaces for the tabs, except
> for the 'return 1' where I must have used an actual tab by mistake. (And I
> tested it now by doing just that, and posting in alt.test.)
>

No, it's an example of how *mixing tabs and spaces* can go wrong. And
in fact will always go wrong unless you legislate the width of a tab.
(Recommendation: A tab is equal to 3.14159 spaces. Now you can't get
confused. Use 6.283 spaces if that's too narrow for you.) So don't mix
tabs and spaces. Ever.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?


On 24/07/2016 11:45, BartC wrote:

On 24/07/2016 11:35, BartC wrote:



'end' to terminate a block can be emulated of course:

end=0

def fn(a):
if a<=1:
return 1
else:
return fn(a-1)
end
end


Actually this is a good example of how tabs can go wrong (and how the 
tab system /is/ fragile - sorry but it is).


I almost certainly wrote the above using 4 and 8 spaces for the tabs, 
except for the 'return 1' where I must have used an actual tab by 
mistake. (And I tested it now by doing just that, and posting in alt.test.)


So the original /looked/ correct in my Thunderbird newsreader before I 
posted. But after I posted, that tab somehow got changed to 4 spaces, as 
it now looks wrong.


In this instance, the result won't compile. But it's not hard to imagine 
a much larger program where that change would go unnoticed, and the 
result is still valid code**.


Then anyone copying and pasting the posted code, would have a program 
with a bug in it.


Mysteriously however, Chris Angelico's reply which quoted my post, 
showed a properly tabbed version! (Unless he fixed it manually.)


(** Where working code has been posted, then Python will have picked up 
inconsistencies where tabs and spaces are mixed. However take this code:


def fn():
if a:
<8 spaces>pass

This looks fine in my editor when  is expanded to 4 spaces:

def fn():
if a:
pass

Python however doesn't like it (Python 2 doesn't anyway), because it 
somehow assumes tabs expand to 8 spaces, so that the two indents look 
like this to it:


def fn():
if a:
pass

So I can see a lot of problems whenever tabs are expanded differently:

a=1
b=0

if a:
if b:
print ("One")
<8 spaces>print ("Two")

In my editor with 4-space tabs, it looks like the code will print 
nothing as the two print lines are aligned within the 'if b:' block. But 
in Python 2, it will print "Two". Python 3 more wisely reports the 
inconsistency.)


--
Bartc


--
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?

On Sun, Jul 24, 2016 at 10:17 PM, Steven D'Aprano  wrote:
> (Do other professions make arguments like this? Do carpenters, say, argue
> against nail guns because "well if you accidentally hold a loaded nail gun
> to your head, then press the trigger, bad things will happen"? Or is it
> just programmers who make a common practice of arguing that the programming
> language should protect the user from sheer carelessness?)

What about "if you accidentally drop a loaded nailgun, it will fire
sharp bits of metal at high velocity in all directions"? I'd say the
only difference is that carpentry has been around longer, so they had
all these arguments a long time ago and settled on safe ways of doing
things. Why has (most of) the programming world advanced from naive
text editors to programming editors with syntax highlighting, linters,
and other features? Because we are more efficient when our tools
protect us from mistakes. Did people argue a few decades ago about the
value of syntax highlighting? Personally, I took a long while to get
from "well, it'd be nice, but I won't go to any serious effort for it"
to "it's my normal way of coding, and anything that DOESN'T have it is
for quick tweaks only". Also, why does CPython keep an eye on things
like Coverity? If the core devs are competent, they should be able to
write code that never dereferences null pointers, mismatch
INCREF/DECREF, or any of those other errors - right? But life's better
with protection.

It's a trade-off. How much effort do you want to go to? Duplicate work
in daily operation is a high price to pay, which is why Python doesn't
demand "indentation AND 'end' keywords", but protection does have
value. Maybe the people who are most worried about this can enact a
simple rule: no dedent without a blank line? That can easily be
verified by a script, and it'd protect against most of the given
examples. It's not too much effort (after any reasonable-sized block
you'll probably have a blank anyway, so it's only the tiniest of loops
that would be affected). And no language changes are needed :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?

2016-07-24 Thread Joel Goldstick

On Sun, Jul 24, 2016 at 8:17 AM, Steven D'Aprano  wrote:
> On Sun, 24 Jul 2016 08:35 pm, BartC wrote:
>
>> I didn't want to get into this subject again, but Python's indentation
>> scheme is fragile.
>
> *shrug*
>
> Okay, it's fragile. In 20 (give or take a couple) years of programming in
> Python, do you know how many times this fragility has been an *actual*
> problem? Why don't you take a guess?
>
>
>> Given an otherwise correctly typed program that compiles with no errors,
>> then it is very easy (if Backspace or Delete is inadvertently pressed
>> for example), for an indent to disappear without your noticing,
>
> Not really. It depends on the editor, but typically you need to have your
> text insertion point somewhere in the indent.
>
> And when you do accidentally press Delete, what happens? The high-level
> structure of the code changes. Typically things will no longer align:
>
> def f():
> for x in seq:
> do_this()
> do_that()
> do_more()
>
> which is a SyntaxError. It requires quite the coincidence before you can
> accidentally delete an indent and have the code still run. Far more likely
> is that accidentally pressing delete will break the code in a way that
> can't be detected until runtime:
>
> def f():
> for x in seq:
> do_this()
> d_that()
> do_more()
>
> Conclusion: if you're the sort of person who habitually presses the Delete
> or Backspace key without paying attention, you're going to have a bad time.
>
> (Do other professions make arguments like this? Do carpenters, say, argue
> against nail guns because "well if you accidentally hold a loaded nail gun
> to your head, then press the trigger, bad things will happen"? Or is it
> just programmers who make a common practice of arguing that the programming
> language should protect the user from sheer carelessness?)
>
>
>> but a
>> program still compiles. And still runs without execution errors. But
>> might now be subtly wrong.
>
> That's certainly *theoretically* possible, but its really not likely. The
> only way it could happen is:
>
> - you have a block with at least two lines;
> - your insertion point is in the indent of the last line of the block;
> - but not the actual text part;
> - your editor is configured to dedent on Delete/Backspace, not just
>   delete a single space; or you're using tabs to indent;
> - and the block isn't followed by another block (e.g. if...else...)
>
>
>
>> Deleting any other character than a leading space or tab I think is more
>> likely to result in an error that would be noticed, generate a compile
>> error, or execute error ('variable not initialised'), or that goes wrong
>> more obviously.
>
> pi = 314159  # oops accidentally hit delete
>
>
> [...]
>> But my suggestion is simply that you can write:
>>
>>   for x in sequence:
>>   end
>>
>> instead of:
>>
>>   for x in sequence:
>>   pass
>>
>> The first now allows statements to be added or removed from the body of
>> the loop without needing to change the 'end'; it wouldn't look out of
>> place as a trailing 'pass' would.
>
> You know, I suspect that you've probably spent more time talking about the
> effort required to delete and insert "pass" than the *actual* effort spent
> by a hundred programmers deleting and inserting "pass" in their code.
>
>
>> But thinking about it some more, it wouldn't work. All the blocks that
>> don't now use 'end' would look odd. I think it would either have to be
>> all or nothing. I guess nothing.
>
>
>
>
> --
> Steven
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
>
This thread is beginning to feel like a dog whistle for people who
like braces.  I've been python coding since 2009 I think, and I think
I have used pass less than a handful of times. ... and except for sets
and dicts, I can't remember using a {

-- 
Joel Goldstick
http://joelgoldstick.com/blog
http://cc-baseballstats.info/stats/birthdays
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?

On Sun, 24 Jul 2016 08:35 pm, BartC wrote:

> I didn't want to get into this subject again, but Python's indentation
> scheme is fragile.

*shrug*

Okay, it's fragile. In 20 (give or take a couple) years of programming in
Python, do you know how many times this fragility has been an *actual*
problem? Why don't you take a guess?

> Given an otherwise correctly typed program that compiles with no errors,
> then it is very easy (if Backspace or Delete is inadvertently pressed
> for example), for an indent to disappear without your noticing, 

Not really. It depends on the editor, but typically you need to have your
text insertion point somewhere in the indent.

And when you do accidentally press Delete, what happens? The high-level
structure of the code changes. Typically things will no longer align:

def f():
for x in seq:
do_this()
do_that()
do_more()

which is a SyntaxError. It requires quite the coincidence before you can
accidentally delete an indent and have the code still run. Far more likely
is that accidentally pressing delete will break the code in a way that
can't be detected until runtime:

def f():
for x in seq:
do_this()
d_that()
do_more()

Conclusion: if you're the sort of person who habitually presses the Delete
or Backspace key without paying attention, you're going to have a bad time.

(Do other professions make arguments like this? Do carpenters, say, argue
against nail guns because "well if you accidentally hold a loaded nail gun
to your head, then press the trigger, bad things will happen"? Or is it
just programmers who make a common practice of arguing that the programming
language should protect the user from sheer carelessness?)

> but a 
> program still compiles. And still runs without execution errors. But
> might now be subtly wrong.

That's certainly *theoretically* possible, but its really not likely. The
only way it could happen is:

- you have a block with at least two lines;
- your insertion point is in the indent of the last line of the block;
- but not the actual text part;
- your editor is configured to dedent on Delete/Backspace, not just 
  delete a single space; or you're using tabs to indent;
- and the block isn't followed by another block (e.g. if...else...)

> Deleting any other character than a leading space or tab I think is more
> likely to result in an error that would be noticed, generate a compile
> error, or execute error ('variable not initialised'), or that goes wrong
> more obviously.

pi = 314159  # oops accidentally hit delete

[...]
> But my suggestion is simply that you can write:
> 
>   for x in sequence:
>   end
> 
> instead of:
> 
>   for x in sequence:
>   pass
> 
> The first now allows statements to be added or removed from the body of
> the loop without needing to change the 'end'; it wouldn't look out of
> place as a trailing 'pass' would.

You know, I suspect that you've probably spent more time talking about the
effort required to delete and insert "pass" than the *actual* effort spent
by a hundred programmers deleting and inserting "pass" in their code.

> But thinking about it some more, it wouldn't work. All the blocks that
> don't now use 'end' would look odd. I think it would either have to be
> all or nothing. I guess nothing.

-- 
Steven
“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: Why not allow empty code blocks?

On Sun, Jul 24, 2016 at 8:45 PM, BartC  wrote:
> 'end' to terminate a block can be emulated of course:
>
> end=0
>
> def fn(a):
> if a<=1:
> return 1
> else:
> return fn(a-1)
> end
> end
>
> And in this example it wouldn't impact on performance as it is not
> evaluated.

Actually, they would be (you'll have a LOAD_GLOBAL followed by
POP_TOP). Much better to use Python's inbuilt hash-braces support,
available via a hash-future directive.

#from __future__ import braces

def fn(a): #{
if a <= 1: #{
return 1
#}
else: #{
return fn(a-1)
#}
#}

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?


On 24/07/2016 11:35, BartC wrote:

On 23/07/2016 16:55, Steven D'Aprano wrote:



In any case, using "end" instead of "pass" is a poor tradeoff. Instead of
needing to use "pass" (say) one time in a thousand when it is needed, you
would need to use "end" 999 times in a thousand when it *isn't* needed.


Yes, well, some of us wouldn't mind!


'end' to terminate a block can be emulated of course:

end=0

def fn(a):
if a<=1:
return 1
else:
return fn(a-1)
end
end

And in this example it wouldn't impact on performance as it is not 
evaluated.


But although it can make source code look more conventional, it would 
not be supported by the language (repeated, out of place or missing 
'end' lines are not an error). And an empty block will still need pass.


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?